Domain Controller DCdiag error - A Global Catalog Server could not be located

Question

I've set up a replica DC in a remote location. It's connected to the main site through a VPN connection. DCdiag passes on the primary DC, but I get the following error on the replica DC:

Running enterprise tests on : mydomain.co.uk

      Starting test: LocatorCheck

         Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1355

         A Global Catalog Server could not be located - All GC's are down.

         Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1355

         A Primary Domain Controller could not be located.

         The server holding the PDC role is down.

         ......................... mydomain.co.uk failed test LocatorCheck

Is it giving this error just because it is not the global catalogue server, or is there some connectivity issue where it does not think there is one at all, as the error seems to imply? If so, it seems odd, as all other tests were passed.

What do I do about this?

Solution

Check the DNS settings on your new domain controller, in 2003 and later, you should always point to 127.0.0.1, and then secondary to another domain controller or any other DNS server with that internal DNS zone available. You should then add a "forwarder" to the DNS service itself under the DNS MMC snap-in.

Comments

[ravi yarlagadda]

How's DNS set up on the replica?

[paradroid]

@ShaneMadden: It was set up through netdom join. I assumed that was all that was needed. The DNS entries appear to have been replicated, apart from the DCs themselves (the original DC appears on both DNS databases, but the replica only appears through dig on the original, but with two entries, one being an out-of-date address).

[SpacemanSpiff]

Are you in some kind of recovery scenario? The server is doing SRV record lookups to try and find the server holding the PDC Emulator FSMO role as well as looking for a Global Catalog server. I believe Shane was referring to the DNS client settings on the NIC of the remote server.

[paradroid]

@SpacemanSpiff: I corrected the DNS discrepency I mentioned above, but I still get the error. No, it's just a new replica, not a recovery. I just checked the DNC client settings. They original DC is set to 127.0.0.1 only and the replica is set to an external public DNS server as primary and 127.0.0.1 as secondary. I'll remove the external entry, but should they also include each other as the second entry? As they have replicated DNS databases, would that even make a difference?

[SpacemanSpiff]

in 2003 and later, you should always point to 127.0.0.1, and then secondary to another domain controller or any other DNS server with that internal DNS zone available. You should then add a "forwarder" to the DNS service itself under the DNS MMC snap-in.

[paradroid]

@SpacemanSpiff: Thanks, I'll add each DC as the other's secondary DNS lookup server. However, I cannot see how this could make any difference, as they will always be able to connect to themselves as primary choice, and they both have the same replicated DNS zone anyway. Of course the DCs have Forwarder for unresolved DNS queries. Is that what you meant, or something else? Cheers.

[paradroid]

Thanks - that has resolved the problem. If you want to make an answer out of it, I will be pleased to accept it.

[SpacemanSpiff]

Take a look at the DNS zone used for your AD domain, there are SRV records and reverse entries that an outside DNS server cannot answer. This is why you point to yourself first, and then have your own server forward external lookups or use root hints to answer public queries.

[paradroid]

@SpacemanSpiff: I cannot see how your comment explained the first part of my comment, and I said that I have set up Forwarders (if I had not, I would never have had DNS resolution for external sites for all this time), so I still do not understand what I mentioned earlier.

[MDMarra]

Just a minor correction, 127.0.0.1 should always be last especially in 2003 where it was possible to create a replication island.

[SpacemanSpiff]

Seems like the tune on how best to do this changes, again, and again, and again.