Compartilhar via

Enabling Client Computers to Locate the Next Closest Domain Controller

  • Artigo

Applies To: Windows Server 2008

If you have a domain controller that runs Windows Server 2008 or Windows Server 2008 R2, you can make it possible for client computers to locate domain controllers more efficiently by enabling the TryNextClosestSite Group Policy setting. This setting improves the performance of DC Locator by helping to streamline network traffic. This functionality is available only for client computers that run Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2.

For branch office environments, you can use this setting to help control how client computers fail over to another site when the domain controller in their own site is not available. For example, suppose that you have a branch office deployment with multiple hub sites with writeable domain controllers and many branch office sites with read-only domain controllers (RODCs). When a client computer in one of the branch office sites has to fail over to a hub site because the local RODC is not available, you can use this setting to control which of the hub sites will be used for failover. Any deployment that has multiple sites with writeable domain controllers can benefit from using this setting.

By default, the TryNextClosestSite setting is not enabled to maintain the same default behavior that existing client computers use today. For more information about how this setting works, see Enabling Clients to Locate the Next Closest Domain Controller (https://go.microsoft.com/fwlink/?LinkId=145407).

Filtering sites with RODCs

By default, DC Locator uses a filter that prevents it from considering any site that contains an RODC when it determines the next closest site. (The setting is named NextClosestSiteFilter.) The default behavior is to exclude sites with RODCs because:

  • RODCs are typically deployed in branch offices, where you usually do not want client computers to fail over.

  • An RODC might be placed in a physically unsecured site, where it possibly could be compromised by an attacker. For example, if a member of the Domain Admins group logs on to a Windows Vista or Windows Server 2008 client computer in the headquarters, DC Locator should not choose the RODC to process logon scripts and Group Policy on the client computer for security reasons.

We recommend that you maintain the default setting for the NextClosestSiteFilter. This means that when DC Locator runs, it will not consider a site that has an RODC to potentially be the next closest site.

However, in special circumstances in which the RODC is trusted (that is, physically secure) you might want to include RODCs as valid domain controllers to fall back on. To do this, modify the registry setting for the NextClosestSiteFilter on Windows Server 2008 or Windows Server 2008 R2 domain controllers. (The setting applies specifically to a domain controller that has the registry setting.) The following table describes the possible values for the NextClosestSiteFilter (DWORD) registry setting under HKLM\Software\Policies\Microsoft\Netlogon\Parameters\Try Next Closest Site.

Value

Description

0

DC Locator does not apply NextClosestSiteFilter.

1

DC Locator filters sites that contain only RODCs. If an RODC is deployed in the same site as a writeable domain controller, DC Locator considers it as the possible next closest site.

2 (default)

DC Locator filters sites that contain at least one RODC. Even if a writeable domain controller is deployed in the same site as an RODC, DC Locator does not consider the site as the possible next closest site.

Forcing domain controller rediscovery

In addition to finding a domain controller in the next closest site, a new Group Policy setting in Windows Server 2008 ensures that a client computer that is running Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 finds a new domain controller that might be introduced since the last domain controller location. On domain controllers that are running Windows Server 2008 or Windows Server 2008 R2, the Force Rediscovery Interval Group Policy setting forces a new domain controller location every 12 hours (43,200 seconds) by default. You can change the time limit for rediscovery by enabling the setting and specifying a new time in seconds. This makes it possible for client computers to redistribute their load across available domain controllers every 12 hours by default, while taking into account weight and priority values that an administrator defines for domain controllers.

By default, client computers cache the last domain controller that was returned by DC Locator. On client computers that are running Windows XP or Windows Server 2003, even if the domain controller that was last located is in a distant site, DC Locator continues to return the cached domain controller on each subsequent request. The cache is updated only if the cached domain controller is unavailable or the client computer restarts.

For domain client computers that are running Windows XP and Windows Server 2003, a hotfix is available that makes the registry setting available for this Group Policy setting. For information about downloading and using this hotfix, see article ID 939252 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=122681).

Methods for applying the TryNextClosestSite setting

To apply the TryNextClosestSite setting, you can create a Group Policy object (GPO) in Group Policy and link it to the appropriate object for your organization, or you can modify the Default Domain Policy to have it affect all Windows Vista and Windows Server 2008 client computers in the domain. You can also apply this setting by modifying the registry, but you can apply the setting more efficiently by using a GPO.

Membership Enterprise Admins in the forest or Domain Admins in the domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (https://go.microsoft.com/fwlink/?LinkId=83477).

To enable client computers to locate a domain controller in the next closest site

  1. Click Start, click Administrative Tools, and then click Group Policy Management.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  3. Double-click **Forest:**forest_name, double-click Domains, and then double-click domain_name.

  4. Right-click Default Domain Policy, and then click Edit.

  5. In Group Policy Management Editor, in the console tree, go to Computer Configuration/Policies/Administrative Templates/System/Netlogon/DC Locator DNS Records.

  6. In the details pane, double-click Try Next Closest Site, click Enabled, and then click OK.

As an option, you can create the following registry entry to affect the Domain Locator (DC Locator) behavior for an individual computer that runs Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2.

Warning

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

HKLM\Software\Policies\Microsoft\Netlogon\Parameters\Try Next Closest Site

If the registry entry DWORD value is1, DC Locator will try to find the domain controller in the next closest site if it cannot find a domain controller in the client computer's site. If the value is 0, DC Locator will find any domain controller if it cannot find a domain controller in the client computer's site.

To verify the setting, type the following command:

NLTEST /DSGETDC: domain_name /WRITABLE /TRY_NEXT_CLOSEST_SITE

Or on the caller, the NETLOGON.LOG or ETW tracing in dsgetdcname indicates the domain controller in the next closest site.

With the policy enabled, site-specific DNS queries appear first for the site defined in “dynamicsitename”, then a fallback to the next closest site, and finally a siteless query.

More information:

https://msdn.microsoft.com/en-us/library/ms675983(VS.85).aspx

https://msdn.microsoft.com/en-us/library/ms675933(v=VS.85).aspx

Change History

Date Revision

Sept 12, 2011

Corrected Registry path and added verification information.