Group Policy Planning Issues

Group Policy Planning Issues

When designing Active Directory for Group Policy, you need to consider several issues. The planning issues that require consideration are filtering using security, inheritance modification, and optimizing Group Policy performance. For example, the user or group who is responsible for the administration of a domain or an OU might need to remain exempt from a GPO. When you filter a GPO, you are exempting a group from those settings.

Filtering Using Security

By default, all objects in a container are affected by a Group Policy that has been applied. However, in some instances you might not want all the objects to be affected by the Group Policy. In such cases, filtering can be used. Filtering is a feature that allows an administrator to exclude certain groups from being affected by a Group Policy (by limiting the scope of the policy). When you filter a GPO, you exempt a group from the settings in the policy.

GPOs are applied to containers in Active Directory. Filters, on the other hand, are applied to groups.

The Group Policies applied to a container affect all users who have read permission for the GPO. This is the default permission given to all users for a GPO, and it causes users in a container to be affected by the policy, by default. To change the scope of the GPO and exclude certain users from being affected, simply create a security group containing the users who need to be excluded and deny the group access to the GPO.

Security groups in Windows 2000 are used to assign a group of users permissions to resources on the network.

If a Group Policy is applied to the Users OU (as shown previously in Figure 6.7), you might need to limit its scope so that it does not affect the users or the group in the OU who are responsible for administration.

If the policy applies restrictions to the users' computing environment, some of the restrictions might not be required for administrative purposes. In this case, a filter can be applied to exempt those users responsible for administration of the OU from the policy.

Inheritance Modification

In some instances, a GPO applied to a parent container should not be applied to its child containers (remember, a GPO applied at the OU level is passed down from parent container to child container). Referring to Figure 6.7, a GPO applied to the Users OU will be inherited by the Clients and Employees containers. In such a case, blocking inheritance can prevent the GPO settings applied to a parent OU from being applied to a child OU.

Blocking

Using a feature called blocking , the inheritance of a GPO can be modified so that it is not passed on from parent container to child container. Any policy applied at the site, domain, or OU level can be blocked. If the Group Policy applied to the Users container should not apply to the Clients container (as shown previously in Figure 6.7), inheritance of the GPO could be blocked. The Employees container would still be affected, but not the Clients container.

The Block Policy Inheritance setting is not applied to the GPO itself but rather to the site, domain, or OU that should be exempt from the policy. All policy settings are blocked, not just those from a single GPO.

Use the following steps to block the inheritance of a GPO:

1. Open the Active Directory Users and Computers MMC snap-in.

2. Right-click the site, domain, or OU that should be exempt from the policy, and select Properties.

3. Select the Group Policy tab, and then select the Block Policy Inheritance check box, as shown in Figure 6.8.

   Figure 6.8. Checking the Block Policy Inheritance option causes this container to be exempt from any policy applied to the parent container.

   

By selecting this check box, the Clients container is no longer affected by the Group Policy linked to the Users container.

There is no way to block only certain settings in a GPO. If you require some of the settings from a GPO to apply but not all, you have to create another Group Policy.

The only time that the Block Policy Inheritance option is ignored and the policy still applied is if the No Override option is set, as discussed next .

No Override

The No Override option means exactly that: If this option is set, any Group Policies linked to a parent container are applied to the child containers, regardless of whether the Block Policy Inheritance option is set. This option prevents any other GPO from overwriting the settings contained in it, and any GPO link that has the No Override option set will not be overwritten by another policy.

To see how this option can affect inheritance of Group Policies, refer to Figure 6.9. Suppose a GPO has been linked to the Training domain and another GPO has been linked to the Users OU. Without any inheritance modification, the GPO at the domain level would be processed first, and the GPO at the OU level would be processed second, overwriting previous settings (remember also that local policies would be applied before any others). If the No Override option is set on the first GPO link at the domain level, its settings will not be overwritten when the second GPO is applied.

Figure 6.9. Setting the No Override option on the GPO link at the domain level prevents any other GPOs from overwriting its policy settings.

Use the following steps to specify the No Override option:

1. Open the Active Directory Users and Computers or the Active Directory Sites and Services MMC snap-in. If you are setting the No Override option at the site level, use the Sites and Services snap-in. Use the Users and Computers snap-in to set No Override at the domain and OU levels.

2. Right-click the site, domain, or OU to which the GPO is linked, and then select Properties.

3. Select the Group Policy tab, select the GPO to which you want the No Override option to apply, and select Options.

4. From the dialog box that appears, check the No Override check box (see Figure 6.10).

   Figure 6.10. By checking the No Override option, you can prevent other Group Policies from over riding the policy applied at this level.

   

Loopback Processing

For certain special-purpose computers, the computer configuration settings applied by Group Policy should remain in effect regardless of who logs on to that computer. In other words, the user's Group Policy settings should not override the specified settings for specific computers. Special-purpose computers can be kiosk machines located in common areas, computers configured as email terminals, or any other application where a common interface look and feel needs to be set and retained for all uses.

By default, because User Group Policy is applied at logon (whereas Computer Group Policy is applied at startup), a user's settings override the computer settings. To ensure that computer settings are retained, Loopback Processing can be selected using Group Policy for all computers in a specified container, be it a site, domain, or OU. Loopback Processing essentially reapplies the computer Group Policy instead of, or following, the application of a user's Group Policy at logon.

Loopback Processing can be configured in either Merge mode or Replace mode.

In Merge mode, the user's GPOs are processed first, in their normal order, at logon. Then, after all the user GPOs have been applied, the entire set of computer GPOs is processed. The result is that any user settings not overridden by the computer settings are retained, but whenever a conflict exists, the computer settings take precedence.

In Replace mode, user GPOs are not processed at all; only the computer Group Policy is applied when a user logs on. In this case, no user settings at all are applied during the user's sessiononly computer settings.

Optimizing Group Policy Performance

One of the overall goals when designing any network infrastructure is to optimize the performance of the network. There are some issues to keep in mind and some settings that can be configured to optimize the performance of Group Policies. When designing Active Directory for Group Policy, keep the following points in mind to ensure performance is optimized:

• Some settingsbut not allin a Group Policy can be configured to process only if sufficient bandwidth is available. For example, if applications are being published through a Group Policy, consider configuring this option to be processed only when sufficient bandwidth is available.

• If you recall from Windows NT 4.0, when a change is made to a system policy, the user must log off and then log on again for the new settings to be applied. Group Policies in Windows 2000 refresh themselves by default every 90 minutes (this means the user does not need to log off for new settings to apply). Consider increasing the refresh interval to increase performance.

• All GPOs in the Active Directory hierarchy are processed from the site level down to the OU level. To increase performance, try to limit the number of policies that are usedthe more policies you have, the busier the network will be. Also, each time a user logs on, the policies have to be processed. Therefore, the more policies you have, the longer it takes for the user to log on. Remember that less is usually best.

• The more GPOs that users are affected by, the longer it takes to process them, and in turn the longer it takes for users to log on. Consider using security groups to exempt users from policies that are not applicable to them. This way, fewer GPOs must be processed.

• If you are linking GPOs between sites and domains, consider the impact this will have on performance. Remember, linking GPOs between sites and domains increases traffic because the GPO has to be retrieved. If the physical links between them are already slow, performance will only decrease. Consider creating separate GPOs with the same settings and linking them to each site or domain so that the GPO doesn't have to be retrieved.

• Whenever possible, limit the use of inheritance blocking and override. Overuse of these two options can make tracking and troubleshooting GPO processing difficult.