SBS - .Local versus .com or others

We seem to see a fair amount of discussion around the .local top level domain (TLD) that we have been using in the SBS world for a while now.

Some links:

• The Official SBS Blog: Geeky question of the day. . . Why .local for the default Windows SBS 2008 domain name extension?
• CanITPro Blog: Another .LOCAL post - SBS 2008, EBS 2008
• Susan Bradley: .Local Revisited
• Susan Bradley: And Another .Local

Whatever side of the fence you sit on: .local or .com, this week's fresh SBS install into a client we picked up a while back will reinforce, at least to us, the very valid reason for .local.

Qualification: That reason should never have existed in the first place.

Our client is a nonprofit. We have done sporadic support for them over the last three years or so as they have a very competent on-site person who can handle most anything. We were the ones she turned to when she ran into a wall.

Their budget came through for a new server. Working with them, and our support contact, it was decided that we would take on a more significant role in the supporting of their I.T. infrastructure to free up our contact to do other things.

Given the age of their Active Directory, and the need to restructure things accordingly, we elected to move the local desktops over the the new SBS domain, demote the existing server, and subsequently add it to the SBS domain as a member server only for the Line of Business app that ran on it.

While we took the time to look at the domain setup which was in place for a number of years prior to our contact coming on board with the organization, we never took too close of a look at it as we were dropping it all together.

The scenario:

• Existing Windows Server 2003 domain NetBIOS: Workgroup.?
• New SBS domain: NonProfit.local

Anyone want to guess what fell behind the workgroup.x?

Not taking a closer look initially was based on an assumption ... and we all know what happens when we do that right?!? ;)

Workstation #1 attempt to move to the new SBS setup:

1. Log on as old domain admin.
2. Reset local admin password.
3. Open IE and point to: http://mysbs/connectcomputer
4. IE opens: http://www.romancatholicparish.org/

Go to another workstation and the same thing happens.

Go back to the SBS box and open ISA's live query to see just what is going on and we see one IP address associated with the romancatholicparish.org (Note that the parish's name is the name of an RC Saint) and their Internet DNS servers in our SBS DNS Lookup Cache.

Huh?!?

First thought: Oh no, the DNS on this new SBS box has been poisoned or corrupted! But clarity soon ensued: Why in the chicken are we being redirected to an RC Parish and not some off the continent country infected Web site?

Just in case, the DNS patch was run on the SBS box and rebooted. We sometimes finish our patching after the SBS box has been installed on the network so WSUS picks up on the workstations in the new domain and if we are under the gun for timing as was the case here.

A deeper look into DNS pointed out to us just what was happening:

• Local W2K3 domain: workgroup.romancatholicparish.org
• WhoIs for above .org domain: Owned by an RC Parish in Kentucky!

Who ever had setup the original Server 2003 Active Directory had not registered the domain for whatever reason, and had not properly split the DNS probably assuming that the romancatholicparish.org domain would ever be registered.

Once we discovered this, the resolution was quite simple: Remove the workstations for the workgroup.romancatholicparish.org domain, and then run the mysbs/connectcomputer wizard. Note that one of the first steps on the machine was to reset the local admin password to a known quantity.

That worked!

From this experience, it is pretty easy to see why Microsoft has decided to stick with the .local TLD. The DIY or "consultant" doesn't have to understand DNS to set things up.

For those who are working with the RCx of SBS 2008, that hand holding even goes so far as to integrate Internet DNS management into the wizards to make sure that things get setup properly.

Those of us who understand the ramifications of DNS setups, .local or .com, registering the .com and splitting the DNS, and the reasons why we choose one over the other, can make sure our client's configurations are setup correctly.

However, all it takes is one DIY, or "consultant" to hose an installation on the DNS setup alone as was the case here.

Our vote goes with .local. It is a necessary "evil" in the SMB sphere to take care of the DIY that may not want to grasp DNS concepts and the "consultant" that has not taken the time to learn them ... yet.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.