2

So I have a weird bug that pauses the netlogon service periodically on my primary domain controller. When this happens users cannot log in to the domain. I have a secondary DC offsite that is a Global Catalog and DNS server but it is reachable through an MPLS connection.

DC1 has all FSMO roles and is located with most client PCs in the 192.168.1.0/24 network. The offsite DC is fully reachable through its dns name and sits with a few clients in the 192.168.2.0/24 network.

Why wont DC2 take over log on responsibilities when DC1 is unavailable?

Jason
  • 317
  • 6
  • 17

2 Answers2

2

Can you clarify what error the clients receive when attempting to log in when DC1 is down?

Off the top though, I'll hazard a guess - is the offsite DC configured as the secondary DNS server for the client systems?

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • I'm betting this is it. – mfinni Jan 05 '12 at 01:14
  • Even if the clients don't have DC2 configured as their secondary DNS, the DNS service on DC1 is working correctly and is returning the site specific SRV records to the clients, hence their attempt to authenticate to DC1. If the clients didn't have DC2 as secondary DNS and the DNS service weren't working correctly on DC1 then they'd be getting an error that a domain controller couldn't be found. If the clients do have DC2 as secondary DNS and the DNS service on DC1 were down they'd still get the site specific SRV records for DC1. The DC locator process isn't the problem here. – joeqwerty Jan 05 '12 at 02:24
  • @joeqwerty Good point. I was just throwing something out there - I think we'll need a bit more detail on the symptoms before we can come to a good conclusion. – Shane Madden Jan 05 '12 at 02:32
  • 1
    @Shane: On a side note (and I know I've said this before), I'm 20 years older than you and I've got half the knowledge. I wish that I had started my IT career earlier and applied myself more than I have. I work harder at it now, but you certainly possess an impressive body of knowledge. Kudos. (no hyperbole, just stating it the way I see it). – joeqwerty Jan 05 '12 at 03:49
  • 1
    @joeqwerty I don't do well with flattery! ;) Seriously though, thanks man - the fact that we've got these kinds of ideas to bring to the table on a question like this is a testament to how great this community is. – Shane Madden Jan 05 '12 at 05:27
2

I could be wrong, but my guess is that it's because the Domain Controller locator process (including querying DNS) between the clients and DC1 in the DC1 site is functioning correctly (due to client affinity).

A Windows domain joined client will have an "affinity" for a particular DC (the closest DC), therefore all of the clients in the same site as DC1 will have an affinity for DC1 (by virtue of the fact that they're in the same site) and are going to continue to "home" themselves to DC1. If DC1 were down hard then clients would seek out DC2 for the logon process.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • 1
    This really isn't right. Sites and Services, if configured correctly, will return a local DC for login requests from clients (which is asking for the appropriate SRV records from DNS.) The client doesn't cache that, it's a new request every login. If AD and DNS is correctly configured, and all local DC are down, AD *should* return a non-local DC. – mfinni Jan 05 '12 at 01:17
  • Then I misunderstood client affinity. After doing some more reading and testing it looks like my answer is off track (I think). I don't believe it's related to DNS though as the DNS service on DC1 is working correctly and returning the site specific SRV records to the clients in the same site, causing them to attempt to authenticate to DC1. – joeqwerty Jan 05 '12 at 02:17