Networking

When troubleshooting Windows 2000, start with DNS

The biggest paradigm shift in Windows 2000 is going from WINS to DNS for name resolution. This case study reveals that in an Active Directory environment, DNS is even more critical and that Win2K troubleshooting should often begin with DNS.


One of my fellow instructors in our Microsoft Authorized Academic Training Provider program has a favorite line when troubleshooting our 600+ node network: “Cabling, cabling, cabling.” His point, of course, is to remember to check hardware connections as the first step in the troubleshooting process.

For the Windows 2000 environment, I’ve revised that mantra to: “DNS, DNS, DNS.” When the trust fails with the errorCannot Contact Domain Controller, I say, “Check your DNS.” When you try to run a DCPromo and you can’t contact the domain, I say, “Check your DNS.” In fact, as we found after four days of troubleshooting the failure of our Global Catalog services, DNS is a critical part of nearly all Active Directory operations. I will walk you through the dilemma we faced with the Global Catalog to help you get a feel for the critical role of DNS in Win2K.

The Global Catalog dilemma
It all started when the 28 students, as part of a lab assignment, began leaving our parent domain to form their own domains and forests. They soon found that Active Directory-integrated DNS zones are not effective across domains. Directory Replication takes place among domain controllers within a contiguous DNS namespace. If there is more than one domain in the site, each domain has its own version of Active Directory. If the domains are part of a forest, the Active Directory’s Global Catalog is the common denominator, not the Active Directory itself.

Until trusts are in place, the DNS service is necessary for the clients to “see” each other. Each domain has its own namespace as defined in the DNS zone. Trusts between domains are automatic only when you’re in the same forest. Otherwise, if you want to create trusts between two domains, you can configure each as the secondary DNS server for the other’s zone. For example, there are two domains, east.local and west.local, in two different forests. The domain controller in east.local will be configured as a Standard Primary DNS server in the east.local domain. The domain controller in the west.local domain will be configured as a Standard Secondary server for the east.local domain. The domain controller in the west.local domain must be the Standard Primary DNS server for a zone called west.local. The domain controller in the east.local domain must be a Standard Secondary DNS server in the west.local zone. Figure A shows the screen for selecting zone types.

Figure A
Setting DNS zone type


One of the keys to making this work is to configure each of the zones with the other zone’s DNS server so that the DNS service will share the database entries. (You will change this back after the trust is in place.) You can accomplish this by going into each DC’s TCP/IP Properties. Then, if you configure your zones to allow zone transfers, the zone entries will automatically appear in each domain controller’s DNS cache. To speed up the process, go to Start | Programs | Administrative Tools | DNS, right-click on one of the two zones, and chooseTransfer From Master.

If you have quite a bit of old information floating around in your DNS cache, you may want to run ipconfig /flushdns from the command line. This will clear out any entries in your DNS cache that might conflict with your new configuration.

To test your configuration of DNS, try an nslookup from the command line. The name servers of each domain should be the DNS servers of the other. If you still have trouble creating trusts, you may just want to apply the latest Service Pack to your servers. That application made our trusts across forests successful. Remember when you are finished with your trust to set your TCP/IP Properties back to your usual preferred DNS servers. If you don’t, you won’t be able to see resources beyond the zones available in your DNS service.

So what does all of this have to do with the Global Catalog Server? “DNS, DNS, DNS” is my answer. At some point in this major infrastructure change, the parent domain lost its Global Catalog Server. We had two domain controllers and one member server in the parent domain. After adding the second domain controller as a Global Catalog Server (which just means that we selected a check box in the NTDS Properties of the server in Active Directory Sites And Services), we tried creating new users. We received an error message saying that the Global Catalog Server could not be reached to verify the uniqueness of the usernames.

The user accounts were created and functional, but it was obvious our Global Catalog Server had a small identity crisis. The Global Catalog Server works in conjunction with the NetLogon service. So the first thing we tried to do was to stop and restart our NetLogon service to see if the service could find the Global Catalog Server and kick it back into action. That didn’t work.

Next, we ran Active Directory Replication Monitor (ReplMon), an extremely useful tool, from the Support folder of the Windows 2000 Server CD. The monitored servers were listed as not being configured as Global Catalog Servers, when they should have been operational (Figure B).

Figure B
Active Directory Replication Monitor with no results


Just to be sure that the ReplMon utility was giving us accurate information, I ran a check with another Support folder tool called Active Directory Administration Tool (see Figure C). For those programmers out there, this tool talks in Lightweight Directory Access Protocol (LDAP). This gave us our first hint of where the problem might be. At the bottom of the printout of the configuration of my server was the entryIsGlobalCatalogReady:FALSE.

Figure C
AD Admin tool when Global Catalog is ready and working


Now all we had to do was figure out how to change the FALSE to TRUE. After searching through the Naming Context and Configuration partitions in our domain via the ADSI Edit tool, we came back to our original theme: DNS. Why? Because the Global Catalog is a service. And the most important concept of the relationship of DNS, Windows 2000, and Active Directory is that DNS doesn’t just resolve host names to IP addresses. It also supports the SRV record in its Windows 2000 implementation, per RFC 2782, which states:

“Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below….If an SRV-cognizant LDAP client wants to discover an LDAP server that supports TCP protocol and provides LDAP service for the domain example.com, it does a lookup of_ldap._tcp.example.com.”

With the help of LDAP and TCP/IP, DNS can point to a service and resolve it to a host name, IP address, and service port. When we searched our DNS records, we couldn’t find a record resolving the Global Catalog Service.

When we looked for an entry for the Global Catalog Service (gc, by name), we found no record pointing to our domain controllers. One of our students examined our DNS against another forest’s DNS and discovered that the subfolder in the _msdcs folder was missing. There should have been a gc folder. That subfolder is the placeholder for the service records for the Global Catalog Server. This folder is created through DCPROMO on the first DC in the forest or when a DC is selected to be a Global Catalog Server. To add the gc subfolder with the appropriate records, we right-clicked on the _msdcs and selected the Other New Record option. This opened a Resource Record Type box. We selected theService Location Record(see Figure D) and changed the Service to LDAP. We changed the Weight to 100. We changed the Port Number to 3268 (the GC port). We changed the Host Offering This Service field to the full DNS name of the Domain Controller we wanted to be the home of the Global Catalog Service.

Figure D
Service Location fields


When we ran ReplMon, it showed our domain controllers as Global Catalog Servers, and we were able to become a fully functional network again.

Summary
Did we need to have the Global Catalog functioning? You bet! Without the Global Catalog, we could not make any changes to the structure of our domain, such as adding domain controllers, joining new computers to the domain, demoting domain controllers, or moving servers or workstations to different domains. When your network is running in native mode, the Global Catalog provides authentication for all logons.

In a learning environment such as ours, losing the functionality of the Global Catalog can really put a cramp in our style. Now we have a smooth-running network, and students can create users, new domain controllers, and even new child domains with the kind of seamless operation Microsoft advertises.

What kind of Win2K DNS issues have you encountered?
Do you have tips and solutions for Win2K issues similar to this? We look forward to getting your input and hearing about your experiences regarding this topic. Join the discussion below or send the editor an e-mail.

 

Editor's Picks

Free Newsletters, In your Inbox