Order of processing settings
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Order of processing settings
This section provides details about the order in which Group Policy settings for users and computers are processed. For information about where the processing of policy settings fits into the framework of computer startup and user logon, see steps 3 and 8 in Order of events when starting up and logging on.
Group Policy settings are processed in the following order:
Local Group Policy object--Each computer has exactly one Group Policy object that is stored locally.
Site--Any Group Policy objects that have been linked to the site are processed next. Processing is synchronous and in an order that is specified by the administrator.
Domain--Processing of multiple domain-linked Group Policy objects is synchronous and in an order specified by the administrator.
Organizational units--Group Policy objects that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then Group Policy objects that are linked to its child organizational unit, and so on. Finally, the Group Policy objects that are linked to the organizational unit that contains the user or computer are processed.
At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy objects can be linked. If several Group Policy objects are linked to an organizational unit, their processing is synchronous and in an order that is specified by the administrator.
This order means that the local Group Policy object is processed first, and Group Policy objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy objects.
Exceptions to the default order
The default order for processing settings is subject to the following exceptions:
Any Group Policy object that is linked to a site, domain, or organizational unit (not a local Group Policy object) can be set to No Override with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. When more than one Group Policy object has been set to No Override, the one that is highest in the Active Directory hierarchy (or higher in the hierarchy that is specified by the administrator at each fixed level in Active Directory) takes precedence.
Note that No Override and Disabled are settings on Group Policy objects links, not on the Group Policy objects. A Group Policy object can be linked several times to the same organizational unit, and No Override and Disabled can be configured independently on each of the links. (Although multiple links from one Group Policy object to a single organizational unit are seldom useful, this capability illustrates the flexibility of the Group Policy infrastructure.)
For information about how to set links as No Override and Disabled, see Prevent a Group Policy object from being overridden and Disable a Group Policy object link.
At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as Block Policy inheritance. Group Policy object links that are set to No Override are always applied, however, and they cannot be blocked.
The Block Policy inheritance setting is applied directly to the site, domain, or organizational unit. It is not applied to Group Policy objects, nor is it applied to Group Policy object links. Block Policy inheritance deflects all Group Policy settings that would reach the site, domain, or organizational unit from above (by way of links to parents in the Active Directory hierarchy), no matter what Group Policy objects those settings originate from. However, Block Policy inheritance does not deflect Group Policy settings from Group Policy objects that are linked directly to the site, domain, or organizational unit that has Block Policy inheritance enabled.
A computer that is a member of a workgroup processes only the local Group Policy object.
Loopback is an advanced Group Policy setting that is useful on computers in certain closely managed environments, such as kiosks, laboratories, classrooms, and reception areas. For a description of loopback, click the Explain tab after you double-click User Group Policy loopback processing mode in the details pane of the Microsoft Management Console (MMC), which is located under Computer Configuration\Administrative Templates\System\Group Policy.
Loopback provides alternatives to the default method of obtaining the ordered list of Group Policy objects whose User Configuration settings affect a user. By default, a user's settings come from a Group Policy object list that depends on the user's location in Active Directory. The ordered list goes from site-linked to domain-linked to organizational unit-linked Group Policy objects, with inheritance determined by the location of the user in Active Directory and in an order that is specified by the administrator at each level.
Loopback can be set to Not Configured, Enabled, or Disabled, as can any other Group Policy setting. In the Enabled state, loopback can be set to Merge or Replace.
Loopback with Replace--In the case of Loopback with Replace, the Group Policy object list for the user is replaced in its entirety by the Group Policy object list that is already obtained for the computer at computer startup (during step 2 in Order of events when starting up and logging on). The User Configuration settings from this list are applied to the user.
Loopback with Merge--In the case of Loopback with Merge, the Group Policy object list is a concatenation. The default step 2 list for computers in Order of events when starting up and logging on is appended to the default step 7 list for users, and the user gets the User Configuration settings in the concatenated list. Note that the Group Policy object list that is obtained for the computer is applied later, and therefore it has precedence if it conflicts with settings in the user's list.