Domain Controller Stickiness Prevention

Reading Time: 4 minutes

Domain Controller Stickiness is a problem which prevents Active Directory clients to be connected to the best Domain Controller they can be.

The root cause of this problem is once an Active Directory client found a Domain Controller (using DNS) it would store the name of that Domain Controller in its DC Locator cache and keep using that Domain Controller until it was given a reason not to use it. (typical examples of reasons are power outages and network failures) Only then would an Active Directory Domain Controller and stick to that Domain Controller. That's fine of course, but the client would not revert back to the Domain Controller without a reason to do so. It would continue to use the next-closest Domain Controller, when the closest became available again.

In multiple-site Active Directory environments this might result in:

  • Increased bandwidth usage between Active Directory sites
  • Performance issues on the Active Directory clients


Justin Graham, Senior Technical Product Manager Windows Server at Microsoft describes the Domain Controller Stickiness problem here, touting it a new Windows Server 2008 feature.


Previous workarounds

Restarting the Active Directory client

Although restarting the Active Directory client usually resolves these issues and point the Active Directory client to the most local Domain Controller, this might not always be a valid option. When the Active Directory client is a member server you might not want or you might not even be allowed to restart it until the next maintenance window.

Placing multiple Domain Controllers per Active Directory site

Another way to prevent Active Directory clients to attach to a next-closest Domain Controller is placing multiple Domain Controller per Active Directory site. When the Domain Controller the Active Directory client is attached to becomes unavailable the client will still use a Domain Controller in its own Active Directory site. While this admittedly might not prevent against network outages, my experience is WAN connections are usually attached to the same active networking components. When the Domain Controllers become unavailable most of the times the WAN connection is unavailable too, preventing Active Directory clients to attach to Domain Controllers in other Active Directory sites.

An extra Server Core Read-Write Active Directory Domain Controller might prove to be the most cost efficient way to make two Domain Controllers available per Active Directory site.


Running a command

True hard core Systems Administrators used the command line to fix this problem on their Active Directory clients by emptying the DC Locator cache:

nltest /dsgetdc:DomainName /force

Where DomainName needs to be replaced with the Fully Qualified Domain Name (FQDN) of your Active Directory domain.


Stickiness Prevention

The solution to this problem is the implementation of a sort of timer through Group Policy to trigger Domain Controller discovery via DNS. The Active Directory client then chooses the most local Domain Controller to attach to until the next discovery. The timer is part of the new DC Locator mechanism, introduced with Windows Vista and Windows Server 2008.

Administrators with Windows XP and Windows Server 2003 seem to be out of luck it seems, but fortunately this is not (entirely) true. The new Domain Controller Locator (DC Locator) mechanism is also available for these platforms. The new mechanism is part of the hotfix, available through Microsoft Knowledgebase article 939252.

Enabling the functionality

The Domain Controller Stickiness Prevention functionality is not enabled by default.
You can enable and control it using Group Policy and/or through the registry.

Group Policy

For Windows Server 2008-based and Windows Vista-based Active Directory clients you can set the DC Locator Rediscovery Interval through Group Policy.

The Group Policy is located under:

Computer Configuration
Administrative Templates
Net Logon
DC Locator DNS Records


The Group Policy is named Force Rediscovery Interval and is Not Configured by default. When you enable it, the default value will change to 43200 seconds (12 hours) as shown below:

You can enter any value between 3600 (1 hour) and 4294967295 (roughly 136 years).
If you set 4294967295 the Active Directory client will not perform rediscoveries, which is equivalent to disabling this Group Policy setting.


Setting the Rediscovery Interval through the registry is the preferred method to configure the DC Locator in Windows XP and Windows Server 2003 after you have applied the hotfix, available through Microsoft Knowledgebase article 939252.

You will have to create and then modify the ForceRediscoveryInterval registry entry. To do this manually, follow these steps:

  1. Click Start, click Run, type Regedit, and then click OK.
  2. Locate and then click the following registry subkey:


  1. On the Edit menu, point to New, and then click DWORD Value.
  2. Type ForceRediscoveryInterval, and then press ENTER.
  3. Right-click ForceRediscoveryInterval, and then click Modify.
  4. In the Edit DWORD Value dialog box, under Base, click Decimal.
  5. In the Value data box, type the expected value, and then click OK.
  6. Exit Registry Editor.


The ForceRediscoveryInterval registry entry specifies the number of seconds that the DsGetDcName function waits before it tries to rediscover the domain controller name.

The value of the ForceRediscoveryInterval registry entry must be between 0 and 4294967295. The default value is 43200 seconds (12 hours). If the value of the ForceRediscoveryInterval registry entry is set to 0, the client always performs rediscovery. If the value is set to 4294967295, the cache never expires.



Domain Controller Stickiness can be a real pain in the behind in multi-site Active Directory environments where clients attach to next-close Active Directory Domain Controllers. Microsoft acknowledged this problem and changed the DC Locator mechanism appropriately.

In Windows Vista / Windows Server 2008 native environments you can harness the power of Active Directory Group Policies to solve the problem. Hotfixes are available for previous versions of Windows.

Further reading

Active Directory and Windows 2008: New features you may have missed
But what about those lesser known features of windows server 2008?
Your new IT Pro Advocate, brought to you by the 2008 Launch Wave
529 Computing Tips – Boosting Business: Windows Server 2008
Microsoft Developer Network – DsGetDcName Function
939252 The domain controller locator cannot find an appropriate domain controller
314861 How Domain Controllers Are Located in Windows XP
DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 1
DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 2
DC Locator Process in W2K, W2K3(R2) and W2K8 – PART 3
Group Policy Negative DC Discovery Cache Setting

2 Responses to Domain Controller Stickiness Prevention


    Hello, I faced a similar issue last week. A Windows Server 2008 sytem which we provide remote support was stuck at "Applying Computer Settings" when checked in iLO. I understood that there was an issue contacting DC or applying group policies. After trying various troubleshooting, I just simply powered off the server for 15mins and powered back on. Then it worked!

    How do you explain this?

    If the 15 mins shutdown cleared the dc locator cache, why didn't it clear the cache when I ran chkdsk in the recovery console for hours.

    • Hi Ked,

      Domain Controller Stickiness Prevention is not enabled by default on Windows Server 2008.
      Restarting it, then, is the only way to make DCLocator invalidate its cache.


leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.