4

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?

paradroid
  • 868
  • 5
  • 15
  • 29
  • How's DNS set up on the replica? – Shane Madden Mar 16 '12 at 02:58
  • @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). – paradroid Mar 16 '12 at 03:24
  • 1
    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. – SpacemanSpiff Mar 16 '12 at 03:42
  • @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? – paradroid Mar 16 '12 at 04:05
  • 2
    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. – SpacemanSpiff Mar 16 '12 at 04:23
  • @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 Mar 16 '12 at 06:17
  • Thanks - that has resolved the problem. If you want to make an answer out of it, I will be pleased to accept it. – paradroid Mar 16 '12 at 07:07
  • 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. – SpacemanSpiff Mar 16 '12 at 12:41
  • @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. – paradroid Mar 16 '12 at 14:08

3 Answers3

4

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.

SpacemanSpiff
  • 8,753
  • 1
  • 24
  • 35
0

I have same problem on windows 2008 enterprise 32 bit server, had tried whole day, and finally i see the service one by one and started services which i think is vital and finally i restarted the Active directory services on server and my problem was solved and DNS again started working perfectly.

Shailesh Dhimar
  • 1
0

I had this problem after I had our physical server automatically restart for updates without shutting down our hyper-v VMs. After a night of troubleshooting, I found that going into services and restarting "Active Directory Domain Services", everything went back to normal and AD was able to sync with DNS. Note that numerous restarts did not fix this until I manually restarted the service.

michael g
  • 101