The �Group Policy domain controller selection� Group Policy setting does not work as expected

Source: Microsoft Support

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.

Windows writes Group Policy data to domain controller other than the one displayed.

Group Policy Administrators may target any domain controller regardless of the policy setting�s value.

The following scenarios may cause this problem:

��������� Using GPMC to edit Group Policy objects over high-latency or transient network connections.

��������� Incorrectly configured sites and subnets in Active Directory

�

There is no resolution at this time.

�

Best Practices:

��������� Edit Group Policy object directly on the domain controller where you want to receive changes. (NOTE: this is not ideal for delegated environments).

��������� Ensure the computer from which you edit Group Policy is in the same site as the domain controller where you want to receive changes.

��������� Do not edit Group Policy over transient or high-latency connections. Use Remote Desktop or Terminal Services and connect to a computer located in the same site as the domain controller and edit or create Group Policy on that computer.

��������� Do not leave Group Policy tools open for an extended period of time, most importantly when editing domain-based Group Policy objects. �Save changes as soon as possible.

�

User Interface behavior:

Group Policy Management Tools, at startup, attempt to locate and connect to the domain controller in the current domain that holds the Primary Domain Controller (PDC) emulator role. The �Group Policy domain controller selection� Group Policy setting enforces the initial connection to only use the domain controller defined in the policy setting. The policy setting does not prevent you from targeting another domain controller after you have loaded the Group Policy object in the appropriate editor.

�

Saving Policy Information:

Active Directory:

Group Policy editors save Group Policy object data to two locations: Active Directory and the system Volume (SYSVOL), which is hosted on all domain controllers within each domain. Group Policy editor use Directory Service Application Programming Interfaces (APIs) to locate the domain controllers. The domain controller returned by these API�s is displayed in the User Interface of the Group Policy Management tools. This is the server that receives Active Directory updates when you save a Group Policy object.

SYSVOL:

Each domain controller in the domain hosts a replicated copy of the System Volume. Group Policy stores most of the policy setting data on the sysvol, which then replicates to each domain controller.� Group Policy editors save Group Policy data to a serverless path (\\domainname.com\sysvol\policies\[guidfolder]).� Each domain supports this special named path through Distributed File System (DFS) redirection.�� The actual path \\domainname.com\sysvol� does not physically exist. The network redirector considers this a special named path and creates a list of domain controllers that host sysvol.� Entries in this list are known as link targets and included server names in the path (\\servername\sysvol).� This list is ordered differently on each client based on site configurations in Active Directory, thereby ensuring computers connecting to this path connect to the closest domain controller hosting this path.� The redirector reviews this list when a connection to \\domainnanme.com\sysvol� is requested.� The redirector chooses a link target form this list, ensures the link target is responsive, and redirect the connection \\domainname.com\sysvol to the path included in the link target, which includes a server name. This link then becomes the active link target for \\domainname.com\sysvol.� If the active link path is unavailable, the computer consults the list again and chooses the next link target in the list, ensures it is responsive, and makes it the active link target for \\domainname.com\sysvol.

Saving to Sysvol:

Domain Controllers are the only servers that host Sysvol. Therefore, the domain controller returned from the Active Directory API, in theory, should be included in the list of link targets. The Group Policy API attempts to prioritize this server as the active link target; attempting to ensure saving Group Policy data to Sysvol occurs on the same domain controller that received the saved Active Directory data.� However, it is possible the name of the domain controller returned from Active Directory is not in the link target list or that the link target may change when editing a Group Policy object.

This change is normal as \\domainname.com\sysvol is purposefully dynamic to ensure the path always resolves to working location. Then nature of redirecting sysvol allows Group Policy to save SYSVOL information to domain controller that is not listed in the Group Policy Management UI. This also prevents the �Group Policy domain controller selection� policy setting from being absolute.

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE �MATERIALS�) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.