Troubleshoot AD Replication

If the troubled DC can't resolve its replication partner's CNAME, it won't be able to receive updates from it. So, first you must determine Kohai's GUID-based DNS CNAME; then you need to see if Godan can resolve the CNAME. Probably the simplest way to do this is to launch Active Directory Sites and Services (dssite.msc), drill down into Godan's site (i.e., Hub, Servers container, KOHAI computer object), then right-click the NTDS Settings container and select Properties. Kohai's CNAME is in the DNS Alias field, as Figure 3 shows. Copy and paste this string into a Ping command in a command prompt on Godan, as Figure 4 shows, to determine whether the replication engine can resolve Kohai. Because DNS can't resolve Kohai via its CNAME, replication can't occur. Note that a similar query using Godan's CNAME resolves correctly.

We've determined the problem to be that Kohai's DNS CNAME is missing. Two methods exist for reregistering it. A straightforward solution is to stop and start the Netlogon service; however, this method will also temporarily disrupt communication between Kohai and its active users. Just because a DC is having replication problems doesn't necessarily mean it isn't servicing its users. A less intrusive solution is to run NetDiag /fix. The /fix parameter is specifically to reregister all necessary DNS records for a DC. After this step takes place, NetDiag runs cleanly but with a warning that the newly added CNAME will take a while to replicate to the DNS server that's specified as secondary in the network card's DNS configuration.

DNS Misconfiguration
My example shows why DNS misconfiguration is the most common root cause for AD problems. DNS configuration is complex and tightly integrated into AD's functionality; many ways exist to misconfigure DNS. If you're getting DNS lookup failures or other "can't locate"type errors for a DC, you need to check the following settings.

Verify that the IP addresses in the DC's client settings (TCP/IP properties of the local area connection) are correct. If the DC is also a DNS server, the recommended configuration is for the primary DNS entry to point to itself. (Longhorn Server will automatically configure the DNS entry to loopback—127.0.0.1—when Dcpromo runs.) The secondary DNS server should point to another DC in the same domain. For more information about the pros and cons of different kinds of DNS client configurations for DCs, see the Microsoft article "Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003" (http://support.microsoft.com/kb/825036).

A DC's primary DNS server is its only means of locating other resources on the network. Thus, you can control a DC's knowledge of other servers and domains by controlling its primary DNS entry. If you're wondering whether the DC's own DNS server is working, point the primary DNS entry to a DNS server you know is working correctly.

Make sure the DC has already registered the resource records it needs to function. Three records relate to replication. Two of these are the CNAME (discussed previously) and its A record (i.e., host name to IP address translation). You can run DCDiag /test:connectivity to confirm that these records are registered in the DC's primary DNS server, and you can use the NetDiag command to reregister the records if necessary. If the records still won't register, run DCDiag /test:Registerindomain /Dns Domain:dnsdomainname to verify that the DC is configured correctly to be able to perform the registration. The A record must also map to the correct IP address, and remember that these registrations must replicate to the DNS servers its partners use before they can find it as well. (Note that the IPConfig /RegisterDNS command doesn't register all the DNS records a DC requires.)

For child domain DCs in a domain tree configuration, you need to check a third record: the glue record. Glue records are A records of DNS servers (in other words, your DCs) for the forest's child domains, kept in the root domain's forward lookup zone. Glue records help solve a sort of catch-22 circular reference dilemma: To find a host in a child domain from outside that domain, you need to talk to a DNS server that's authoritative for the domain; however, you can't resolve that authoritative server, because its A record is in the very domain you're trying to get DNS information about! Putting a second set of A records for the child domain's DNS servers in the root domain solves this reference problem and thus "glues" the child domains to the root. The DCDiag DNS test with the /DnsDelegation option (DCDiag /test:DNS /DnsDelegation) tests for correct registration of a DC's glue records.

Access Denied
The second most common group of errors revolves around a DC's denial of access to its replication partner. Under normal circumstances access problems don't occur because all DCs' machine accounts are members of the Enterprise Domain Controllers built-in group. Thus, an Access Denied error means something has happened to invalidate the security between replication partners. One of the most common root causes is incorrect time synchronization on one of the DCs. Replication itself doesn't depend on time—but Kerberos does. Kerberos demands tight time synchronization between DCs; if their internal clocks differ by more than five minutes (by default), Kerberos will fail and you'll receive an error message that says access to the source DC was denied. The system log will have Kerberos and probably W32Time errors.

Use the Net Time /QuerySNTP command to see which time servers are configured for the DC in question. A DC is a member of a domain by definition; if a DC isn't the PDC emulator of the root domain, its time server configuration should be empty, because the default Network Time Protocol (NTP) server for a non-PDC DC is the PDC of its domain. If the DC in question is in a child domain, the PDC looks to a DC in the root domain as a time source, and these DCs in turn look to the PDC of their parent domain (usually the root domain) as the authoritative time source for the entire forest. Use the Net Time /SetSNTP: command to remove references to an explicit time server. You can then use the handy W32tm command to control the DC's NTP settings. To force the DC to locate a time source and synchronize with it, run the W32tm /Resync /Rediscover command. You could also run the W32tm /Config /Syncfromflags:DOMHIER command to sync from a DC in the domain hierarchy. To check the NTP settings on all DCs in the domain, run the W32tm /Monitor command. Watch the clock in the system tray to tell when the time changes take effect. (For more information about how Windows Time works, see the Microsoft articles "How Windows Time Service Works," http://technet2.microsoft.com/windowsserver/f/?en/library/71e7658728f4-4272-a3d7-7f44ca50c0181033.mspx, and "How to configure an authoritative time server in Windows Server 2003," http://support.microsoft.com/kb/816042)

   Previous  1  [2]  3  Next