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.
| SOLUTION STEPS:
- Make sure the target DC's OS and directory service are working properly.
- Make sure DNS is working properly on both the target and source DCs.
- Make sure the target DC can resolve the source DC.
- Check Kerberos and the services it depends on.
- Check firewall configurations.
|
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)
Prev. page
1
[2]
3
next page 
