3

I have this exact issue Event ID 4013: “The DNS server is waiting for Active Directory Domain Services (AD DS) to signal..."

Two DC's and two DNS servers except my problems are a little more involved. So if I reboot my domain I cannot logon to my domain or access resources until BOTH DC's are fully booted and AD is able to perform initial synchronization.

This is annoying, but my problem is extended because on Server 2008 my network profile changes to "unidentified" since DNS isn't loaded and this "unidentified" profile turns on a firewall which blocks DC/DNS traffic. My network is completely inaccessible until I either reboot one of the DC/DNS servers AGAIN or disable the firewall on the profiles.

Sure, I could fix this by disabling the firewall on that profile, but is there really no other way around this problem? It seems like a huge design oversight.

Community
  • 1
nullByteMe
  • 420
  • 2
  • 5
  • 17
  • See my comment to Ryan's answer, but proceed at your own risk. As a workaround, stop and restart the DNS server and DNS client services on each DC in turn after they've rebooted. That will resolve the issue. – joeqwerty Sep 27 '13 at 19:15

2 Answers2

4

You need to configure the domain controllers such that the primary DNS resolver on DC1 is DC2, and the primary DNS resolver on DC2 is DC1, then set 127.0.0.1 as the secondary DNS resolver on both DC1 and DC2, and finally, do not reboot them at the same time. Stagger reboots.

Here is an excerpt from the Microsoft Best Practices Analyzer article regarding this matter:

The loopback IP address should be configured as one of the DNS servers on each active network adapter, but not as the first DNS server.

If the loopback IP address is the first entry in the list of DNS servers, Active Directory might be unable to find its replication partners.

The inclusion of its own IP address in the list of DNS servers improves performance and increases availability of DNS servers. However, if the DNS server is also a domain controller and it points only to itself, or points to itself first for name resolution, this can cause a delay during startup. For this reason, use caution when configuring the loopback address on an adapter if the server is also a domain controller. The loopback address should be configured only as a secondary or tertiary DNS server on a domain controller.

Yes I know that Microsoft has done some work to alleviate the replication "island" problem, yet, this remains as the best practices advice from Microsoft to this day.

Community
  • 1
Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
  • Where exactly do I change the primary DNS resolver? Are you talking about in the adapter settings or is this a setting in the actual DNS server console? – nullByteMe Sep 27 '13 at 17:02
  • I mean in the settings of the network adapter. When a domain controller boots up, it needs to see another domain controller besides itself that is up and running. Otherwise, you get long boot up times while all the AD related services time out because they can't find a domain controller. Make sense? – Ryan Ries Sep 27 '13 at 17:05
  • Interestingly, I had a phone call with a Microsoft Advisory Services engineer just this week about this very issue and here's what they told me: The PDCe should point to itself first for primary DNS and then to another DC/DNS server for secondary DNS. All other DC/DNS servers should point to the PDCe for primary DNS and then to themselves for secondary DNS. 127.0.0.1 SHOULD NOT be configured at all. - We have a planned shutdown this weekend so I'm going to find out if their recommendation works. – joeqwerty Sep 27 '13 at 19:13
  • @joeqwerty So what was his explanation for being in direct conflict with Microsoft Best Practices Analyzer? Furthermore, if my PDCe is on the other side of the world, while I have another perfectly good DC in the same datacenter, I will not be pointing to the PDCe for no good reason. Honestly, I believe the Microsoft employee was wrong. – Ryan Ries Sep 27 '13 at 19:25
  • They didn't have an explanation for it. Honestly, I think they were wrong too but I'm going to see what happens this weekend. – joeqwerty Sep 27 '13 at 19:26
1

It still surprises me that folks have issues with AD. It's been around for over thirteen years now, and its fundamental mechanics haven't changed. Sure, a few tweaks here and there, but under the hood it still requires some basics to be in place.

Yes, Microsoft have supposedly engineered out the DNS islanding issue, but for the Active Directory Domain Services service to successfully start, the service must first be able to find out which servers underpin the domain and parent forest. Unsurprisingly, the location is discovered by means of Service Location (SRV) records ... in DNS.

So, if you can't get to a pucker DNS replica, you won't be able to start AD, so you won't be able to start Active Directory Integrated DNS. Like Ryan says, point your first DNS resolver at another DC, and your second at either a third DC, or locally. Personally, I'd go with two remote DCs before pointing at yourself, as subsequent DNS server entries only get used following a non-response.

As for the PDC Emulator FSMO, I don't quite understand what's going on there. Other than down-level services, the PDCe only has a special purpose when it comes to time synchronisation. The non-PDCe DCs in a domain get their time from the PDCe, and this DC can either be configured to use a RTS, or to get its time from the root domain's PDCe.

One way to really get your head around this sort of stuff is to perform a disaster recovery exercise involving AD. I recommend trying this, as it forces you to understand things like the _msdcs zone in DNS, SYSVOL replication, AD replication monitoring (using REPADMIN), Etc.

</rant>

Simon Catlin
  • 5,232
  • 3
  • 17
  • 20
  • "So, if you can't get to a pucker DNS replica, you won't be able to start AD, so you won't be able to start Active Directory Integrated DNS." Well, after some time it *does* boot. It just takes more time. So may there not be a way to configure a DC to boot immediately? There might be small envs with just a single DC... where there is no need to wait for timeouts. – stackprotector Sep 07 '22 at 08:30