7.4 Distributing Policies

Computers that operate as standalone machines depend solely on local policy files for their policy settings. Networked computers, however, have the chore of obtaining policy files from the Domain Controller and merging them into their Registry. These downloaded policies contain the policies of the sites, domains, and organizational units that the computer and users are members of.

When you run the Group Policy snap-in, you're required to select the Group Policy Object for the settings you wish to modify. This can be a GPO associated with an Active Directory object, or it may be a local or remote computer GPO. The users and computers that the policy affects, however, depends directly on which GPO is chosen. The higher the GPO is in the hierarchy, the more machines the policy file is distributed to.

7.4.1 Understanding How Effective Policies Are Calculated

I said earlier that policies are applied to the Registry in a specific order. That is: the local GPO, site GPOs, domain GPOs, and then OU GPOs from largest to smallest. Clearly, since policies are cumulative, order of application is quite important. Policies set early in the process can be overwritten by later GPOs. Since local GPO settings are applied before nonlocal GPOs, the LGPO is considered to be the least influential of all GPOs. The important policies, then, are those held by nonlocal, or Active Directory, GPOs.

The hierarchy of the Active Directory is tree-like in that an Active Directory container can accommodate multiple containers beneath it. Each of those containers, in turn, can itself hold multiple containers. This continues down to the lowest-level OU container that actually houses actual users and machines. As the nonlocal policies are applied in the order described previously, each new policy file is merged into the Registry. This means that policy settings for site GPOs cover all domains, organizational units, users and machines within it. Settings for a domain GPO fan out to all the organizational units, users, and machines below the domain. Next, high-level organizational unit policies take effect and envelop all subordinate OUs. Policies of low-level OUs, while they are not as broadly applied as the higher nodes, are most likely to be applied, since they overwrite all conflicting policies previously merged into the Registry. Since policies are applied top-down in a single direction, policy settings applied at lower levels, such as subordinate OUs, don't affect higher group policy objects, such as site and domain GPOs.

7.4.2 Policy Inheritance

In the scheme of calculating effective policies, there are some basic rules that need to be understood about how policies are inherited. For the sake of clarity, let's discuss this in terms of parent and children GPOs, where a parent is any Active Directory Container, and a child is one of the containers directly beneath it in the Active Directory hierarchy.

First, you know from the previous discussion about editing policies that policies can be enabled, disabled, or not configured. Child containers don't inherit policies that aren't configured from their parent GPOs. This extends to the users and computers in those containers. Disabled policies are, however, inherited as disabled. Enabled policies, of course, are inherited as such. Furthermore, policy settings that are configured for a parent OU (that is, either enabled or disabled) and not configured for a child OU are inherited by the child. As an example, consider a desktop policy that hides the Internet Explorer icon on the desktop. A child OU inherits this policy if it's enabled or disabled for the parent OU. The child doesn't inherit it if it's not configured for the parent OU.

Inheritance additionally depends upon the compatibility of policy settings; that is, whether the intent of a setting inherently conflict with that of another policy setting. When a policy of a parent OU is incompatible with a policy of a child OU, the child doesn't inherit the parent's policy setting. Instead, the child's policy takes precedence and is applied. When a policy configured for a parent is compatible with the child's policy, both policies are used. The parent's policy is inherited and applied along with the child's policy; in this case, the effective policy is the sum of the parts of those two policies.

In some cases, an administrator may wish to keep a child GPO from inheriting policies from its parent and instead rely solely on the child's own policies. A third basic rule of policy inheritance allows child GPOs to block inheritance. If this option is set for a GPO, the GPO doesn't inherit any policy settings from its parent. This is useful when a parent GPO has general policies it wants to enforce on most of its child GPOs. Yet, there might be a child GPO that's exempt from these settings and should maintain its own set of policies. Blocking inheritance allows the subordinate unit to create its own policies without interference from its parent. Following the previous example, a child OU can disable or not configure the policy to hide the Internet Explorer icon while blocking inheritance from the parent OU. In this case, even if the hide icon policy is enabled for the parent OU, the effective child policy doesn't reflect that.

Lastly, there's an option for parent GPOs that give them the ability to set mandatory inheritance. By setting the No Override option on a parent GPO, all children GPOs must inherit all configured policies from that parent, regardless of compatibility or inheritance blocking on the child GPO. This can be used for parent GPOs that want their policy decisions to be unconditionally respected. This option also provides a means of making sure that incompatible settings don't keep child GPOs from inheriting parent GPO policies. Supposing that No Override is set for a parent OU that also enabled the hide Internet Explorer icon policy, its child OU unconditionally inherits that policy.

7.4.3 Managing Dispersal Through Group Policy Policies

The system administrative template includes a number of policies that define more concretely how and when Group Policies are retrieved and applied. These policies are found in both the computer and user sections of the system.adm file. To view the computer-specific policies in Group Policies, make sure system.adm is included as a current policy template. Under the Computer Configuration\Administrative Templates branch, the System category contains a subcategory for Group Policy. The following list describes some of these policies and what they mean:

Disable background refresh of group policy

Keeps group policy from being updated while a user is logged on. Not enabling it allows policy to be updated whether a user is logged on or not. When not enabled, update frequency is tied to the Group Policy refresh intervals for users and computers.

Apply group policy for computers asynchronously during startup

Allows the system to display the login prompt before the computer Group Policy is finished updating.

Apply group policy for users asynchronously during startup

Lets the system display the Windows desktop before the user Group Policy is finished updating.

Group Policy refresh interval for computers

Allows customization of policy update frequency. The policy's parts allow you to specify how often Group Policy is applied to computers. The default is 90 minutes.

There is an additional user-specific policy found under User Configuration/Administrative Templates in the System category and Group Policy subcategory. It works much like its computer-specific sibling:

Group Policy refresh interval for users

Like the computer refresh interval policy, this policy allows you to specify how often Group Policy is applied to users. The default is 90 minutes.

7.4.4 Setting Single Computer Group Policies

When you start Group Policy as a standalone MMC snap-in, a Select Group Policy Object dialog appears that allows you to choose the GPO to modify. The GPO for the Local Computer is entered as the default. You can browse for another GPO by selecting the Browse button. The subsequent browse dialog contains four tabs: Domains/OUs, Sites, Computers, and All. GPOs stored on local computers are found on the Computers tab. The radio buttons on this dialog allow you to toggle between the computer you're currently on and another computer, as shown in Figure 7.7.

Figure 7.7. Browse for Group Policy Object dialog

To modify the LGPO of another computer, type in the computer name or browse and select.

7.4.5 Setting Nonlocal Group Policies

You use the same dialog as shown in Figure 7.7 to select Active Directory Container GPOs to configure. These GPOs are divided into two groups, Domains/OUs and Sites. The Domains/OUs tab features a dropdown list to choose a container to look in as well as a list of GPOs in that container and their associated domain.

Similarly, you can specify a Site GPO on the Site tab. Again, a dropdown list contains the available sites to look in. To view all available GPOs in a certain domain, use the All tab and select the domain to look in. All GPOs in the selected domain will appear for easy pickings.