With more than 1600 GPO settings in a typical GPO and potentially hundreds of GPOs within your Active Directory infrastructure, and with WMI filters, security filtering, blocking GPOs, enforcing GPOs, and so much more, the implementation of GPOs is bound to fail sometimes. Even with the best GPO testing and integrity checks, certain settings and configurations will cause problems on the production network. This section explores some of the most common errors that can be made in GPOs during implementation.
With so many GPO settings to choose from, settings can easily become misconfigured. The ability to quickly track down the incorrect setting and in which GPO it resides is extremely important. Here are some common situations where a GPO setting might be set incorrectly and some possible solutions.
Most of the Administrative Template GPO settings have three options when you configure them: Not Configured, Enabled, and Disabled. When you select Enabled or Disabled, you must pay close attention to the wording associated with the policy setting. In some cases, Enabled removes a feature, and in other cases it adds the feature. The same concern applies to the Disabled option. Figure 17-22 and Figure 17-23 show how Enabled removes a feature and adds a feature, respectively.
When you configure these policy settings, read the descriptions of the settings carefully. Be aware of double negatives as well as the double positives. To help you understand what each policy setting does, read the Explain tab for the setting; it typically explains the result of the policy for both the Enabled and Disabled configurations.
Tools that can help you determine what the settings are for the policy configurations include:
Resultant Set of Policy (RSoP). Runs on the client and indicates what the final setting configured on the client
GPRESULT. Similar to RSoP but runs from the command line of the client
Group Policy Modeling. Runs using the GPMC and helps determine what the final policy settings would be as well as which GPO would make the settings
Once you open up a GPO in the editor, you are faced with many decisions and policies. If you set a policy accidentally or select the incorrect check box, option button, or spin box, the result can be problems with network connectivity, resource access, Internet access, and more. These incorrect settings are hard to track down because the result is simply that the computer does not work in some fashion. You will not see any error message indicating that a GPO setting was set to make the computer fail.
In a situation like this, you must find out which GPO has the errant setting and which setting is causing the problem. This can take some time. However, plenty of tools are available that can help you locate the problem. These tools include:
Resultant Set of Policy (RSoP). Runs on the client and indicates what the final setting configured on the client
GPRESULT. Similar to RSoP but runs from the command line of the client
Group Policy Modeling. Runs using the GPMC and helps determine what the final policy settings would be as well as which GPO would make the settings
The best way to eliminate these problems is to first test and verify all GPO settings in a nonproduction environment. This is time consuming with so many GPO settings, but with good documentation, testing, and a testing lab, you can reduce errors dramatically.
Administrators often get confused about which settings in a GPO apply to computer accounts and which apply to user accounts. A GPO separates these settings clearly, as shown in Figure 17-24, but some settings appear to be for user accounts when in reality they affect computer accounts. A good example of this is the Account Policies settings, which configure user password restrictions. Because these policies relate to user passwords, administrators tend to assume that these settings apply to user accounts. However, these settings control user passwords by controlling the directory database on the computer where the accounts reside, which is why they are found under Computer Configuration instead of User Configuration.
There are limited tools for tracking down a computer-based setting that is intended to affect a user account. When a specific GPO setting is not applying as expected, you need to determine first whether the setting is a computer-based or user-based setting. Then locate the corresponding accounts within Active Directory and its OU structure. It is common for accounts to be located in the wrong OU, which prevents GPO settings from applying to them as expected.
When a GPO is created, it must be linked to an Active Directory container to apply to accounts. As we saw in Chapter 4, the design and implementation of Active Directory and the GPOs is the foundation for where these GPOs should be linked. If the design philosophy is changed or an administrator decides to start changing GPO links without understanding the ramifications, problems can occur. This section explores some common problems that can occur with regard to linking GPOs.
It is not a bad practice to create a GPO that will be linked to multiple containers within Active Directory. In fact, this is commonly done to reduce the number of GPOs that need to be created, managed, and tracked. However, sometimes administrators decide to link a GPO to a container that was not designed to be linked to that GPO causing problems with clients and servers on the network. The administrator might not be experienced enough about GPOs or Active Directory design to know the ramifications.
Errant GPO links can cause loss of data, loss of production time, and loss of money due to simple GPO settings that affect the accounts that reside in the OU where the errant GPO link is made. Without documentation, finding these errant GPO links can be difficult. The following tools can help track down all GPOs that affect an account, but unless a clear GPO naming strategy or clear documentation has been used, the tools might not be enough.
Resultant Set of Policy (RSoP). Runs on the client and indicates what the final setting configured on the client
GPRESULT. Similar to RSoP but runs from the command line of the client
Group Policy Modeling. Runs using the GPMC and helps determine what the final policy settings would be as well as which GPO would make the settings
When you administer GPOs from within the GPMC, it is a good idea to determine where the GPO is linked before you modify any policies in the GPO. You know that modifications in a GPO will affect a subset of accounts within Active Directory, but the change might also affect other accounts located in other areas of Active Directory where the GPO is also linked.
You should follow two best practices when updating GPO settings within GPOs that are linked to more than one Active Directory container. First, work with the GPO from under the Group Policy Objects node within the GPMC. This ensures that you do not narrow your focus to just one GPO link—instead, you have to think about the entire Active Directory structure and the fact that the GPO might be linked to more than one container. Second, before making any changes to the GPO, you should investigate all of the containers where the GPO is linked. You can do this by viewing the Scope tab when you click on the GPO in the GPMC, as shown in Figure 17-25. You can see a list of all of the containers that have a link to this GPO.
OUs are designed to house computer and user accounts. If an account is not placed in the proper OU, the appropriate GPOs won’t apply to it. We’ll look next at common scenarios in which accounts are in the incorrect OU to receive GPO settings.
If an account is placed in the incorrect OU, the GPO settings will not apply to the account. By following proper change management procedures, you can generally avoid such simple oversights. However, even with the most sophisticated change management procedures, accounts can still sometimes be misplaced in the Active Directory structure. Here are some common reasons that accounts get misplaced in wrong OUs:
The newly created computer or user account was not moved to the correct OU.
The computer or user account was not moved from the Computers or Users container after the OU structure was implemented.
The OU design was modified, but accounts were not relocated.
The Active Directory object representing the employee or his computer was not moved to the new OU after the computer or employee changed departments.
A new OU structure was implemented, but some computer or user accounts were not moved into the proper OU.
GPO settings can apply to a computer account or a user account. As we mentioned earlier, it can sometimes be confusing as to whether a particular GPO setting is targeting a computer or user. If the administrator thinks that a GPO setting is designed to target a computer account when in reality it is designed to target a user account, the result will usually be that the policy will not be applied as expected.
To resolve such problems, you should verify whether the GPO settings you want to apply are computer-based or user-based, and then ensure that the correct account type is located in the OU where the GPO is linked.
Since the days of Windows NT 4.0 System Policy, administrators have sometimes been confused about how to apply GPOs to group accounts. System Policies could target computer and user accounts based on group membership, so some administrators have tried this within an Active Directory environment, but to no avail. Here are some tips to help you avoid trying to apply GPOs to groups.
A common error is to link GPOs to OUs that contain only group accounts. The assumption is that the user accounts with membership in these groups will receive the GPO settings, but this procedure fails because GPOs apply only to computer and user accounts, not to groups.
All of the tools that help you track the GPOs that are applied to a computer or user account will confirm this foundational GPO application concept. Tools such as RSoP, GPRESULT, and Group Policy Modeling all omit the GPOs that are attempting to affect computer and user accounts via group membership.
This restriction still baffles some administrators, but there is a simple way to remind yourself that GPOs affect only computer and user accounts: when you open up a GPO in the editor, you see only two sections: Computer Configuration and User Configuration. There is no section named Group Configuration! In this way, you can remind yourself that GPOs do not affect groups or their members.
Sometimes administrators try to modify a GPO’s ACL so the GPO settings affect the members of a group. This will, of course, fall short of the desired outcome. If we look at the default configuration of the GPO ACL, we can see why this approach cannot work.
All computer and user accounts receive GPO settings by default through the Authenticated Users group, via permissions of the ACL. All computer and user accounts have membership in this group once they authenticate to Active Directory. When an administrator attempts to add another group to the ACL, in hopes of having the GPO settings apply to the members of this group, this action duplicates the permissions already in place.
The bottom line is that the computer or user account must be located in the OU where the GPO is linked. (The account can be located in a child OU, below where the GPO is linked to receive the GPO settings.)
Most Group Policy implementations include more than a single GPO affecting the target accounts. In some cases, you might have numerous GPOs that affect a single target account. When the final GPO settings are applied to the account, it can be difficult to track down where one setting conflicts with another one.
Having conflicting settings in different GPOs is not a problem. But if the conflicting setting does not resolve itself correctly to properly apply to the account, the computer or user will not have a particular feature, security setting, application, network configuration, etc. This will cause down time and force you to track down where the conflicting setting resides.
Many tools can help you in this situation. The following tools from Microsoft are geared toward finding and fixing these problems. They require that you know which settings are causing the problem, but once you know, the tools can help you track down where the setting conflicts exist.
Resultant Set of Policy (RSoP). Runs on the client and indicates what the final setting configured on the client
GPRESULT. Similar to RSoP but runs from the command line of the client
Group Policy Modeling. Runs using the GPMC and helps determine what the final policy settings would be as well as which GPO would make the settings
The default GPO inheritance takes the GPOs from the local computer down through sites, the domain, and OUs to determine the resultant set of policy. As a best practice, you should leverage this default inheritance and GPO application wherever possible throughout the Active Directory implementation and avoid modifying default GPO processing unless necessary. If you maintain the default inheritance, the only potential problems are those described in earlier sections. However, altering the default inheritance can cause problems if you are not careful. The next section describes the most common ways to alter GPO inheritance and how to investigate problems that might arise.
Enforcement of GPOs pushes the settings in a GPO down through the Active Directory structure. Nothing can stop a GPO setting that is set to Enforced. Chapter 4 explains that in some instances setting a GPO to Enforced is a best practice. However, if you overuse this setting, the end result can be undesirable.
If you think that your GPO settings are not working properly due to other GPOs that are set to Enforced, you can use a couple of tools to track down the setting:
Resultant Set of Policy (RSoP). Runs on the client and indicates what the final setting configured on the client
GPRESULT. Similar to RSoP but runs from the command line of the client
Group Policy Modeling. Runs using the GPMC and helps determine what the final policy settings would be as well as which GPO would make the settings
GPMC interface. Lets you see whether a GPO linked to a container is set to
Enforced by the icon on the GPO link. When the setting is Enforced, the icon has a lock symbol attached to it, as shown in Figure 17-26.
GPO settings are appended to one another as the operating system processes them from the local computer, sites, the domain, and OUs. In some special instances, you might not want all of the GPO settings from the sites, the domain, and some OUs to apply to some accounts. You can use the Block Policy Inheritance configuration on the domain or at an OU to negate the GPO settings that have lower priority. You should use this setting only rarely because of the complexity of implementing the policies and troubleshooting the problems that can occur from using this configuration.
Block Policy Inheritance is configured at the domain or OU level, so you can go to these containers within the GPMC to see if the configuration is set. This is similar to the Enforced setting, described previously. When a container is set to Block Policy Inheritance, the icon changes to include a blue exclamation point on the container, as shown in Figure 17-27. Other tools that can also help you track down where Block Policy Inheritance is configured include:
Resultant Set of Policy (RSoP). Runs on the client and indicates the final setting configured on the client
GPRESULT. Similar to RSoP but runs from the command line of the client
Group Policy Modeling. Runs using the GPMC and helps determine what the final policy settings would be as well as which GPO would make the settings
When you have computer and user accounts located in a single OU for administration purposes, not all of the accounts will necessarily need to receive the same GPOs. In this instance, using security filtering is a good solution (although a good Active Directory and OU design will also solve most of these kinds of problems).
When security filtering is used, it can cause problems with application of GPOs to all of the desired accounts. You must then track down where the security filtering is being used and fix the configuration of the ACL to correct the application of the GPO settings.
The same tools we just looked at for the enforcement and blocking of GPO inheritance can also be used for tracking down security filtering issues. They include:
Resultant Set of Policy (RSoP). Runs on the client and indicates the final setting configured on the client
GPRESULT. Similar to RSoP but runs from the command line of the client
Group Policy Modeling. Runs using the GPMC and helps determine what the final policy settings would be as well as which GPO would make the settings
GPMC interface. Lets you see the ACL of the GPO, which is located on the Security tab, as shown in Figure 17-28.
