Understanding group policy processing

In previous Daily Drill Downs, I’ve shown you how to prepare to use group policies and introduced you to how they work. Before you can understand the implications of group policies, however, you need to see how Windows 2000 applies them. In this Daily Drill Down, I’ll look at how Windows 2000 applies the group policies you create.
Welcome to Jim Boyce’s ongoing discussion about Windows 2000 group policies! Previously, Jim has shown you how to prepare to use group policies on your network, what they do, and how they work. If you’ve missed any of the previous parts to this series, check them out:

• “Preparing to use Windows 2000 group policies“
• “Understanding Windows 2000 group policies“

Which comes first?
Windows 2000 processes the local group policy object (GPO) first, followed by the site, domain, and applicable organizational units (OUs). The client requests a GPO list from the domain controller (DC) and then processes that list to apply the policies contained in the GPO(s). The client processes the GPOs according to the priority in the DC-supplied list. Windows 2000 processes GPOs at startup and logon and also when the GPO refresh period is reached, which by default is 90 minutes.

At the client side, a group of DLLs—referred to as client-side extensions—perform the group policy processing. Each DLL is responsible for specific policies. Table 1 lists the client-side extensions and the policies they process.

Each GPO can include policy settings for both User Configuration and Computer Configuration. The client gives precedence to the Computer Configuration policies over the User Configuration policies by processing the User Configuration policies first. In some situations, this precedence can cause unexpected results. For example, a user’s computer might reside in one OU and the user account in a different OU. So how do you determine which GPO is applied? Group policy loopback lets you control that behavior.

Understanding group policy loopback
In most cases, a user who logs on from a workstation should have his group policies applied based primarily on the settings defined by the user object in the AD rather than their computer object. A user who logs on from a computer that’s part of the server’s OU, however, should take his settings from the computer’s object location rather than the user object. There can be many other situations in which you want the computer object’s GPO(s) to take precedence over the user object, as determined by your organization’s structure, computer function, and so on.

Group policy loopback, which is supported only in pure Windows 2000 environments (Windows 2000 clients and Windows 2000 DCs), enables group policies to be applied based only on the computer from which the user logs on. Loopback provides for two processing modes:

• Merge mode: In this mode, Windows 2000 processes the group policies for the User Configuration first, followed by those for the Computer Configuration. In effect, this causes the Computer Configuration group policies to have precedence over any User Configuration settings. When the Computer Configuration object doesn’t specify a given policy, the User Configuration object defines the policy setting.
• Replace mode: In this mode, Windows 2000 processes only the Computer Configuration group policies, ignoring the User Configuration group policies.

Keep in mind that in either mode, the user might have several GPOs applied. For example, the user might be affected by a site GPO, a domain GPO, and two OU GPOs. When the client retrieves the GPO list from the DC, the contents of the list are determined by the loopback mode. With merge mode, the client requests the list normally (based on the user location in the AD) and then submits a second request based on the computer location. The result is that GPOs might actually be processed twice, as shown in Figure A.

Figure A

GPOs may sometimes be processed twice.

In this example, the initial GPO list and order of processing are GPO1, GPO2, GPO3, and GPO4. When the second request based on the computer location is fulfilled, the response is added to the list, resulting in a final GPO process list of GPO1, GPO2, GPO3, GPO4, GPO1, GPO2, GPO5, and GPO6. In the case of replace mode, the client requests the list based only on the computer location in the AD, giving the result GPO1, GPO2, GPO5, and GPO6.

Setting the loopback mode
To set the effective loopback mode, open the Active Directory Users And Computers console, right-click the container in which you want to apply the loopback setting (site, domain, or OU), and choose Properties. When the Properties window appears, click the Group Policy tab.

Select the group policy in which you want to define the loopback setting and choose Edit. Next, expand the Computer Configuration/Administrative Templates/System/Group Policy branch. Double-click User Group Policy Loopback Processing Mode, select Enabled, then select either Merge or Replace from the drop-down list. Click OK to close the dialog box, then close the Group Policy console.

GPO refresh
Windows 2000 automatically refreshes GPOs every 90 minutes by default, although it applies a randomized 30-minute offset interval to the refresh period to ensure that large groups of users don’t refresh their GPOs at the same time. Refreshing the GPOs ensures that changes to group policies are implemented in a timely manner.

You can tailor the refresh rate to your network’s needs. Increasing the refresh interval can help reduce network traffic if you seldom change policies. Decreasing the refresh interval causes group policy changes to be applied more quickly and is desirable whenever you expect to change policies more frequently or want to make sure that changes apply in a timely fashion. Decreasing the refresh interval also causes more network traffic, however, this is a factor you should consider when deciding on the refresh interval.

You can specify an interval as low as seven seconds or as high as 45 days. Obviously, high intervals such as the maximum are relatively useless, since changes should be applied much more quickly in almost all situations. Very short durations are also undesirable in most situations because of the excessive network traffic they create.

You specify the GPO refresh interval through the Default Domain Controllers GPO. To do so, open the Active Directory Users And Computers console. Right-click the domain and choose Properties. Choose Default Domain Policy and click Edit. Expand the Computer Configuration/Administrative Templates/System/Group Policy branch. Next, double-click the Group Policy Refresh Interval For Computers policy, click Enabled, and then set the interval and the offset range. Finally, click OK and close the Group Policy console.

Synchronous versus asynchronous GPO processing
By default, GPO processing is synchronous, which means that the processing of one GPO must be complete before processing of the next one begins. Computer Configuration policies apply at system startup, and User Configuration policies apply at logon and complete prior to the user interface becoming available to the user.

In most cases, you’ll want to continue to use the default synchronous behavior. You can, however, configure Windows 2000 to process policies asynchronously. With asynchronous mode, GPO processing can occur simultaneously and on multiple threads, providing better performance and faster processing. To ensure reliable application of policies—particularly where certain policies need to override policies set at lower levels—you should use synchronous mode. Use asynchronous mode only when performance is an issue, and then use it judiciously.

You configure GPO processing mode through the Default Domain Policy. To do so, open the Active Directory Users And Computers console. Right-click the domain and choose Properties. When the Properties window appears, choose Default Domain Policy and click Edit. Next, Expand the Computer Configuration/Administrative Templates/System/Group Policy branch. Double-click the Group Policy Refresh Interval For Computers policy, click Enabled, and then set the interval and the offset range. When finished, click OK and close the Group Policy console.

GPO applications over slow links
Although most users log on over a relatively high-bandwidth connection such as a LAN, remote and roaming users often log on through low-bandwidth dial-up connections. Other factors can affect connection bandwidth as well. During group policy processing, Windows 2000 uses a relatively complex method to determine the connection speed. It first attempts to ping the server, making several attempts to determine an average transmission rate. Failing the ping, Windows 2000 measures the connection speed by testing file system performance, the same method used in Windows NT. If Windows 2000 detects a slow connection, it processes the group policies as follows:

1. The security policy is processed.
2. The policies in Administrative Templates are processed.
3. The software installation is not processed.
4. The scripts are not processed.
5. The folder redirection is not processed.
6. The Internet Explorer maintenance is not processed.

You can configure the slow-link behavior through the Computer Configuration/Administrative Templates/System/Group Policy/Group Policy Slow Link Detection policy of the group policy object and for user policies through the same node of the User Configuration branch. You can configure these settings for each GPO, enabling you to apply group policies differently for each GPO across a slow link.

On-demand GPO refresh
As mentioned above, Windows 2000 updates group policies automatically based on the refresh interval you specify for group policies, with the default refresh interval being 90 minutes. You can force a group policy refresh in between automatic refreshes, if needed. You can refresh the Computer Configuration policies and User Configuration policies separately.

To refresh Computer Configuration policies, select Run from the Start Menu. In the Run dialog box, type secedit /refreshpolicy MACHINE_POLICY /enforce and click OK.

To refresh User Configuration policies, select Run from the Start menu. In the Run dialog box, type secedit /refreshpolicy USER_POLICY /enforce .

The /enforce option causes Windows 2000 to update policies for the Security and EFS extensions whether or not a policy change has occurred and has no effect for the other group policy extensions.

Specifying the target DC for group policy edits
If your network contains a single domain and a couple of DCs, and all computers are on the same network, you really don’t have to concern yourself with indicating the correct target DC when making changes to the group policy. However, if you have multiple domains, DCs, and users with the ability to change the group policy, getting the target right for group policy edits is important. In addition, you could have more than one DC receiving edits, causing edits at other DCs to be lost during replication.

You have two possibilities for specifying options for controlling DC group policy changes:

• Dynamically through the Group Policy Editor console
• Dynamically through policies defined in the Administrative Templates branch

To configure the options through the console, open the properties for the domain, click the Group Policy tab, and edit the Default Domain Policy object. Select the root of the object, then choose View | DC Options to display the Options For Domain Controller Selection dialog box, as shown in Figure B.

Figure B

You can specify options for controlling domain group policy changes.

Options you’ll find on this screen include the following:

• The One With The Operations Master Token For The PDC Emulator: This option causes Windows 2000 to use the same DC as the target for all group policy creation and editing, with all other DCs receiving updates through replication. This ensures that you don’t experience editing collisions caused by multiple concurrent policy changes on different DCs. With this option selected, the Group Policy console automatically focuses on the specified DC. Typically, the DC with the Operations Master token is the first DC created in the domain, although this can change.
• The One Used By Active Directory Snap-Ins: This option enables you to select a DC when using the Group Policy console snap-ins. As long as you select the right one, edits happen on the selected DC. Selecting the DC, however, is a conscious, manual process, inviting error. If you forget to change the focus and inadvertently make changes on the wrong DC, those edits could be lost during replication or cause other problems, so use this option with care.
• Use Any Available Domain Controller: This option allows changes to be made on any DC, making it the least desirable option. If you have only a few DCs and only one person making policy changes, then this option is acceptable.

If you prefer to establish these options through a policy (a better method as it then applies to all administrators), configure the policy settings at the domain level. Open the Default Domain Controller GPO and modify the policy User Configuration/Administrative Templates/System/Group Policy/Group Policy Domain Controller Selection as desired. The available options are the same as those discussed above.

Conclusion
At this point, you should have a relatively good understanding of what group policy objects are and how they enable you to apply policies, at least in a general sense. You also should have enough information to start planning a group policy implementation. In upcoming Daily Drill Downs, I’ll explain creating and managing group policy objects and show how you can filter them using security groups.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.