DC stickiness

Hellow there,

long time no write. As for this time, I’m not promising anything, I’m not saying that I’ll do better or that I’ll make sure I make the time to write at least once a week. I just don’t think this is realistic. Expect me to come back – but not in a regular manner :-) I have been pretty busy the last couple of weeks, everything involves a job change — so my days are quite full.

Anyway, I’d like to just write a couple of words on DC stickiness as that’s what I had to deal with today. So you probably know what the DC Locator process is, right? That’s the piece of code that make the client search for a Domain Controller nearby and use that for authentication and ticket acquisition.

So that’s a cool thing. What you need to know too is that, once it finds a DC to use, it’ll cache that DC to make sure it doesn’t have to re-iterate available DCs over and over again. That cache is valid for 15 minutes. After 15 minutes, in order to make sure that DC is still there, it’ll ping that DC and, if it’s still available, it keeps on using that. If that DC doesn’t respond, well, then it’ll kick off the DC Locator process again and find another one.

Wait a minute, now – what does that mean? In theory, that means that a client might stick to a DC it got until it is not responding any more. That means that, if the local DC goes down and the client falls back to some remote DC, when the local DC comes back again, it won’t necessarily use that local DC right-away or the next 15 minutes.

So when does the client ever re-evaluate whether the local DC is up running again? Well it does so when the DC it uses does not respond to the ping or the client is restarted (I think a reboot of the netlogon service is enough). To forcefully have the client search for a new DC, you’ll have to issue a “nltest /DSGETDC:<domainName> /FORCE”. That nltest command forces the machine to force-rediscover a “nearby” DC, discarding the cache.

Since not all machines are rebooted on a regular basis, there may be an inefficient side effect to that fail over behavior – as the clients might use a far away DC if the local DC was down for a couple of minutes.

Luckily, there was a change in Server 2008 and Windows Vista, carried forward to 2008R2 and Win7. For these OS, you can define the maximum time frame, that cached DC should be used, before it gets actually re-evaluated no matter if the current DC is still alive or not. So there’s a max lifetime of the cache. The default lifetime of that cache is, by default in these new OS, 12 hours. You can adjust that time to be as much as 1 hour or as much as up to 49 days. The corresponding GPO is: CompConf\Policies\AdmTempl\System\Net Logon\DC Locator DNS Records – “Force Rediscovery Interval”. You can also set it in the registry, but that’s less sexy: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters – “ForceRediscoveryInterval”, a DWORD that – just as the GPO – expects the number of seconds for the max cache lifetime.

The whole thing is – more or less – described in this MSDN article: http://msdn.microsoft.com/de-de/library/ms675983.aspx (search for “Notes on Domain Controller Stickiness).

So – how was that for a “welcome back” blog post? Not too bad, I hope…

4 Comments so far

  1. Alex on March 23rd, 2011

    Nice! Keep writing!


  2. Mike Kline on March 23rd, 2011

    Great welcome back post Florian!! I can’t imagine how busy it must be for you. I hear that the first six months to a year can be very busy.

    Do it for a few years then start your own company then retire :)

    Talk to you later


  3. florian on March 23rd, 2011

    Thanks Mike!

    Haha, we’ll see about the retire part. I’ve got a couple more years so I won’t plan to far from now. I just have to get rollin’.


  4. [...] Blog » DC stickiness] http://www.frickelsoft.net/blog/?p=278 Verwandte Beiträge:Einstellungen für Gruppenrichtlinien finden Und wieder ein Hinweis auf [...]