From the initial creation of GPOs to the editing of GPOs and the management of all aspects of Group Policy, many areas of the operating system and Active Directory are involved. If any of these areas becomes corrupt, unavailable, misconfigured, or inaccessible, your access to GPOs and GPO settings can be affected.
Many aspects of administering GPOs can be affected. In essence, they fall into five general areas:
Creating GPOs
Linking GPOs
Editing GPO settings
Managing GPOs
Viewing GPO settings
Let’s look at some root problems that can prohibit you from accessing GPOs or from performing GPO administration tasks as desired.
The creation, editing, and management of GPOs takes place on a single domain controller by default. If your environment contains multiple domain controllers, it only makes sense that there is a preselected domain controller on which all Group Policy changes occur by default. The preselected domain controller is the one within the domain that also is responsible for the PDC Emulator.
If you attempt to control GPOs and the PDC Emulator is not available, you will receive an error message, as shown in Figure 17-1.
At this point, you have to decide how to proceed. You still have the option of modifying your GPOs, but it will need to be on a different domain controller than the one that contains the PDC Emulator. To make the best decision, you must understand that the PDC Emulator does not have any special features that make it a better choice than any other domain controller for managing GPOs. The PDC Emulator was selected by Microsoft as the default domain controller for managing GPOs because it is a domain controller that must always exist within an Active Directory environment.
If you choose a different domain controller, you must understand how that decision will affect application of the GPO. The main concern is where the domain controller that holds the PDC Emulator role resides physically, compared to the domain controller that you choose for updating GPOs. This affects which accounts receive the GPOs immediately and which accounts receive the GPO updates after all the domain controllers replicate and converge.
It is best to always use the same domain controller for updating GPOs. This might not be the same domain controller for each administrator, especially if the administrators work in different physical locations (which typically means different Active Directory sites). If the domain controller that you typically use for updating GPOs is not available, you should first determine why it is unavailable. Then you can decide whether the GPO changes that you need to make can wait until that domain controller comes back online or whether the changes must occur immediately on any domain controller that remains online.
If you do choose to use a different domain controller, the worse thing that can happen is that the GPO settings might not apply as quickly as you want. This lag is dictated by the replication structure and schedule that you create between the Active Directory sites.
In some cases, you will be able to access the GPO and open it in the Group Policy Editor, but not all of the settings will be visible within the editor. This might happen when you are viewing a GPO that has only the default settings, or it might happen when you have customized some Administrative Template or Security Template settings.
No matter the situation, something is causing some or all of the settings within the GPO to be unavailable for editing. Focusing on what is missing and what you expected to see will help you determine the cause of the problem. The following sections describe situations you might encounter, what you will see within the Group Policy Editor, and how to fix the problem.
As you saw in Chapter 14, you can create custom administrative templates to add new settings to the default GPOs. These custom settings you add to an administrative template modify registry paths and values. To ensure that you have followed the correct steps to get the settings to show up in the GPO, here is a brief summary:
Create a new administrative template with the file extension .adm.
In the Group Policy Editor, open the GPO that will include the custom registry settings and .adm template.
Open the GPO to the Administrative Templates node (under Computer Configuration or User Configuration).
Right-click the Administrative Templates node, and select Add/Remove Templates.
Select the .adm template you created to add it to the GPO.
If you did not complete these steps, or if you selected to view GPOs with a domain controller different than the one that you used to add the .adm template initially, verify all of the steps and the replication convergence of the GPO files to all domain controllers.
If you completed all of these steps, you still might not see your custom settings within the Group Policy Object Editor. The most likely cause of this behavior is that the Only Show Policy Settings That Can Be Fully Managed check box is selected (in the Group Policy Editor under View, Filtering), as shown in Figure 17-2.
When this setting is selected, only the GPO settings that fall under one of the four Policies registry subkeys will be displayed in the Group Policy Object Editor. Settings that don’t fall under these registry subkeys will be hidden from view. They are actually still available, but you see them only if this setting is not selected.
One key indicator that this is the solution to the problem is that the policy structure for the GPO setting will be shown but the policy setting will not (Figure 17-3).
More Info
For more information on policies that can be managed, the Policies registry subkeys, and the syntax to configure these settings in an administrative template, see Chapter 14.
There are many variations of .adm templates, based on which operating system you are using for both your domain controllers and to administer GPOs. With different service packs, operating system releases, and security updates, these .adm files have gone through considerable changes since Windows 2000 was first released. If you have a mismatch between the operating system version that is running Active Directory and the operating system version that is used to administer GPOs, you might see more strange behavior than if you use the same operating system version for both tasks. This strange behavior will include missing GPO settings when editing GPOs, overwriting of administrative templates during editing of GPOs, and errors when editing GPOs from one operating system version to another.
For this discussion, the following products are considered the same version:
Windows 2000 Server and Windows 2000 Professional
Windows Server 2003 and Windows XP Professional
Windows Server 2003 SP1 and Windows XP Professional SP2
These combinations are based on the major changes made to the Administrative Templates settings. You can accommodate the differences between these GPO settings by using the latest .adm templates when you are modifying the GPOs. The Group Policy Editor displays only what the .adm file tells it to display.
Two other settings are important with regard to the .adm templates. First, you can control whether the computer you are using to administer the GPOs will use the local .adm templates or those stored on the domain controller. This setting is located under the Computer ConfigurationAdministrative TemplatesSystemGroup Policy node. The setting is named Always Use Local .adm Files For Group Policy Object Editor. When this setting is enabled, the Group Policy Editor uses the local copy of the .adm templates; when it is disabled, the Group Policy Editor relies on the version stored on the domain controller.
Second, you can control whether the .adm template versions stored on the domain controller and local computer are compared when the GPO is being edited. By default, this comparison results in the newest .adm template being used to edit the GPO. This setting can be controlled under the User ConfigurationAdministrative TemplatesSystemGroup Policy node. The setting is named Turn Off Automatic Update Of .adm Files.
You can use the security templates to establish baseline security settings for computers. One of the most common methods of producing these security templates is to use the Security Templates snap-in through the Microsoft Management Console (MMC), as shown in Figure 17-4.
If you have used the snap-in to create the security templates, you must ensure that you deploy the security templates to the computers in some way. Multiple methods are available, but using GPOs is the best and most efficient method. To deploy the security settings that you configure in a security template using Group Policy, you must import the security template into the GPO by following these steps:
Edit the GPO that will receive the security template settings.
Expand the Administrative TemplatesWindows SettingsSecurity Settings node.
Right-click the Security Settings node, and select Import Template.
Select the correct security template file, and click OK.
This procedure imports the security template and all of its related configurations into the GPO and thereby deploys the settings to all computer accounts that the GPO affects.
Much like customizing the .adm templates, you can also customize the security settings that reside in a standard GPO. This can be done by modifying the Sceregvl.inf file, as previously explained in Chapter 15. There are many reasons that you might want to customize the security settings. Regardless of the reason, you might find that those custom settings are not showing up in the Group Policy Object Editor.
The one big difference between customizing .adm templates and security settings is in how the settings are updated so the Group Policy Object Editor can read them. As we just saw, .adm templates are imported into the GPO. When you modify the Sceregvl.inf file however, you can’t import this file into a GPO. Instead, you must reregister the DLL that is associated with this file to get the new settings to show up in the Group Policy Object Editor. To reregister the DLL, you type the following command on the computer that has the new copy of the Sceregvl.ing file and will be used to administer the GPO:
regsvr32 C:Windowssystem32scecli.dllUnless you perform this registration, the new custom security settings will not show up in the Group Policy Object Editor.
When you need to administer GPOs within the Group Policy Management Console (GPMC), you might find that some of the administration options do not appear, depending on what permissions your user account has been assigned. The GPMC is a perfect environment for controlling what each administrator of GPOs is responsible for. Five different administrative tasks can be delegated to one or more administrators within the GPMC. What appears to be a problem might simply be the result of another administrator restricting your access to the GPOs within the GPMC.
Because establishing delegation restrictions within the GPMC can be tricky, we’ll look at where you can modify these delegations within the GPMC for the five administrative tasks.
You can create GPOs within the GPMC in two ways. First, you can go to the node where the GPO will be linked, right-click the node, and select Create And Link A GPO Here, as shown in Figure 17-5.
The second way to create a GPO using the GPMC is to right-click the Group Policy Objects node and select New, as shown in Figure 17-6.
In both figures, the option to create a new GPO is unavailable. This is because the user who is administering Group Policy using the GPMC has not been delegated the ability to create GPOs in the domain.
You configure this delegation by accessing the Delegation tab, after highlighting the Group Policy Objects node in the GPMC. On the Delegation tab, you will see the list of administrators who have permission to create a new GPO, as shown in Figure 17-7. The menu options for creating GPOs are available to those administrators only.
Linking GPOs to nodes within Active Directory is an important administrative task—certainly one that should not be taken lightly. Therefore, if you go to a domain, an organizational unit (OU), or a site only to find that the option to link a GPO to the node is grayed out, don’t be alarmed. It is at the domain, OU, or site where you can link a GPO to one of these nodes. By right-clicking one of these nodes, you should see the Link An Existing GPO menu item, as shown in Figure 17-8.
If, as shown in Figure 17-8, the Link A GPO option is unavailable, you don’t have the permission to link a GPO to this node. Remember that the creation of GPOs is domain wide, while linking GPOs to containers is container-specific. Therefore, if you go to any container (domain, OU, or site), you will have a Delegation tab. On that tab, you can specify which administrators can link GPOs to this portion of Active Directory, as shown in Figure 17-9.
Management of GPOs includes editing the GPO settings, setting the security of the GPO, and deleting the GPO. If you need to accomplish one of these tasks but the task is unavailable (like the ACL settings shown in Figure 17-10), you have most likely not been delegated the permissions to manage that GPO.
The permissions to manage a GPO are configured on a GPO-by-GPO basis. To see the list of administrators who have permission to manage a GPO, follow these steps:
Open the list of GPOs under the Group Policy Objects node in the GPMC.
Click the GPO you want to investigate.
Select the Delegation tab.
Right-click the user or group to which you want to grant the ability to manage GPOs.
From here, you can assign the Edit Settings, Delete, Modify Security permissions as shown in Figure 17-11.
The ability to edit a GPO is in some ways more powerful than the ability to create or link a GPO. If a GPO is already created and linked, an administrator can go into the GPO and do any configuration she has the privilege to do. However, if you are trying to edit a GPO but do not have the privilege to do so, the option to edit the GPO will be unavailable, as shown in Figure 17-12.
The ability to edit a GPO is similar to the ability to manage a GPO, in that it is set on a GPO-by-GPO basis. To set the permissions for editing a GPO from within the GPMC, complete these steps:
Open the list of GPOs under the Group Policy Objects node in the GPMC.
Click the GPO you want to investigate.
Select the Delegation tab.
Right-click the user or group to which you want to grant the permission to edit the GPO.
From here, you can set the Edit Settings, option, as shown in Figure 17-13.
Viewing the GPO settings does not have a lot of security implications, but granting this permission unnecessarily can have vulnerabilities associated with it. For example, if a user has the ability to track down which GPO settings are affecting a server or another computer, they might discover or exploit a known vulnerability based on how the computer is configured. Of course, this vulnerability was already present, but the ability to view the settings makes the vulnerability apparent.
For this reason, you might not have access to view the GPO settings when you are in the GPMC. If you have not been granted the ability to view a GPO on the Delegation tab, you cannot see the GPO listed under the Group Policy Objects node (as shown in Figure 17-14, where Default Domain Controllers Policy is no longer visible).
The GPO itself will also show up as Inaccessible under the Active Directory container where it is linked, as shown in Figure 17-15.
The ability to view a GPO is similar to the ability to manage and edit a GPO in that it is set on a GPO-by-GPO basis. The steps to access the configuration for viewing a GPO from within the GPMC are as follows:
Open the list of GPOs under the Group Policy Objects node in the GPMC.
Click the GPO you want to investigate.
Select the Delegation tab.
Right-click the user or group to which you want to grant the ability to view the GPO.
From here, you can assign Read permission, as shown in Figure 17-16.
