DNS-AD Rescue

When I was in high school, I received my scuba certification.The most valuable lesson in that class: Stop, think, and doa little planning before you jump into the water. Failure to heed this warning could cause the bends, or possibly death. Ourinstructor's mantra: Plan your dive; dive your plan.

The same philosophy applies to network administrators performing large upgrades or implementing a new technology that could affect production. Too often I've seen otherwise competent technologists paint themselves into a corner because they lack a clearly defined implementation roadmap. Instead, they simply pop in the upgrade CD-ROM, double-click setup.exe, and walk through the wizard. This approach almost always leads to disaster.

This happened recently to an administrator acquaintance of minewho was trying to upgrade his Windows NT 4.0 domain to Active Directory (AD) and Windows Server 2003. He was new to network administration and didn't realize the importance of having a well-thought-outplan. Eventually, he asked for help, but by then host names weren'tresolving correctly, Group Policy didn't work, and the event logs werefull of errors.

We talked through the issues on an online forum, via email, andeventually over the phone. From what he described, it appeared thatDNS and AD weren't communicating with each other. Here I'll talkabout what we did to fix the problem (during a weekend, mind you), andin the Web-exclusive sidebar "Plan Your Dive, Dive Your Plan", I explain my tried-and true approach to planning that helps me avoid the kinds of snafus thatbefell my administrator friend.

AD-DNS Chaos
We found these AD and DNS problems (among other, less severeones):

The administrator didn't understand the importance of DNS in an ADenvironment. No DNS means no AD. Finding that the AD DNS entrieswere blank provided me a great opportunity to explain to the admin theimportance of DNS and how it worked. After we configured the correctDNS settings on each DC, we moved on to dealing with the next problem: the missing RRs.

When I looked in the DNS zone for the domain, it immediately didn'tlook right. I couldn't place my finger on the problem at first until I wentback to my test domain and compared mine with the administrator's.Then the problem stuck out like a sore thumb: His domain didn't havethe needed RRs! This adventure was getting more exciting by the minute. I had him reboot the DC, fully expecting the missing information toreappear. But rebooting didn't restore the absent RRs, so my next stepwas to have the admin cycle the Netlogon service by entering the following at the command line:

net stop netlogonnet start netlogon 

Still no RRs. Eventually, we turned to Microsoft Help and Support andfound the article "How to reinstall a dynamic DNS Active Directory integrated zone" (http://support.microsoft.com/?kbid=294328). We followed the steps in that article to totally remove DNS and reinstall itfresh. The process was straightforward and fixed the problem.

More DNS Troubles
The third issue we discovered—that DNS wasn't set to accept dynamic updates—could also explain why some of the PCs weren't resolving IP addresses correctly. The PCs had entries in DNS, yet those entries weren'tbeing updated when the PCs' IP addresses changed via DHCP. The solution was simply to configure the clients to allow DNS dynamic updates.

The last problem we found is something that I see a lot when companies migrate from NT to AD. In NT, there usually wasn't a reason to use DNS to resolve host names; we just used WINS to resolve NetBIOS names. DNS then was left to resolve Internet names for browsing in Internet explorer (IE). This process worked well in an NT environment, but it's a paradigm that needs to change when you move to AD. Client computers need their DNS to point to an internal DNS server so that AD services such as Group Policy work correctly. In Windows 200x, you live and die by DNS.

Situation Normal
It took a few days for us to straighten out all the glitches in the administrator's network, but in the end the network was spinning like a top.Although you can't foresee every network trouble that could occur whenyou perform a major OS upgrade, in my experience I've learned thathaving a carefully considered upgrade plan in place—and following thatplan—go a long way toward avoiding the type of snafus that plagued mynetwork administrator colleague.