Active Directory 2008 : Implementing Group Policy (part 4) - Registry Policies in the Administrative Templates Node

With thousands of policies to choose from, it can be difficult to locate exactly the setting you want to configure. The GPME introduced in Windows Server 2008 solves this problem for Administrative Template settings: You can now create filters to locate specific policy settings.

To create a filter:

Figure 5. Filtering the Administrative Templates policy settings

In the top section of the Filter Options dialog box shown in Figure 5, you can filter the view to show only policy settings that are configured. This can help you locate and modify settings that are already specified in the GPO.

You can also filter for Group Policy settings that apply to specific versions of Windows, Internet Explorer, and other Windows components.

Unfortunately, the filter applies only to settings in the Administrative Templates nodes.

There is a nuance to the registry policy settings configured by the Administrative Templates node that is important to understand: the difference between managed and unmanaged policy settings.

A managed policy setting has the following characteristics:

 A managed policy setting causes a configuration change of some kind when the setting is applied by a GPO. When the user or computer is no longer within the scope of the GPO, the configuration is released automatically.

For example, if a GPO prevents access to registry editing tools, and then the GPO is deleted, disabled, or scoped so that it no longer applies to users, those users regain access to registry editing tools at the next policy refresh (which is Windows’ default behavior) unless you have implemented a restriction at some other level.

In contrast, an unmanaged policy setting makes a change that is persistent in the registry. If the GPO no longer applies, the setting remains. This is often called tattooing the registry—making a permanent change. To reverse the effect of the policy setting, you must deploy a change that reverts the configuration to the desired state. Additionally, an unmanaged policy setting does not lock the UI for that setting.

By default, the GPME hides unmanaged policy settings to discourage you from implementing a configuration that is difficult to revert. However, you can make many useful changes with unmanaged policy settings, particularly for custom administrative templates to manage configuration for applications.

To control which policy settings are visible, right-click Administrative Templates and choose Filter Options. Make a selection from the Managed drop-down list, shown in Figure 5.

When a change is made by a preference, the change tattoos the system. However, some preferences include an option to remove the preference when it no longer applies to the user or computer. This is not the same as a managed policy setting, which is released and often returned to its original value. Instead, when a preference is removed, the setting is actually deleted entirely.

Why are these nodes of the GPME labeled as “Administrative Templates”? An administrative template is a text file that specifies the registry change to be made and that generates the user interface to configure the Administrative Templates policy settings in the GPME. Figure 2 shows the properties dialog box for the Prevent Access To Registry Editing Tools policy setting. The fact that the setting exists, and that it provides a drop-down list with which to disable Regedit.exe from running silently, is determined in an administrative template. The registry setting that is made based on how you configure the policy is also defined in the administrative template.

You can add administrative templates to the GPME by right-clicking the Administrative Templates node and choosing Add/Remove Templates. Some software vendors provide administrative templates as a mechanism to manage the configuration of their application centrally. For example, you can obtain administrative templates for all recent versions of Microsoft Office from the Microsoft Download Center. You can also create your own custom administrative templates. A tutorial on creating custom administrative templates is beyond the scope of this training kit.

In versions of Windows prior to Windows Vista, an administrative template had an .adm extension. ADM files have several drawbacks. First, all localization must be performed within the ADM file. That is, if you want to create an ADM file to help deploy configuration in a multilingual organization, you need separate ADM files for each language to provide a user interface for administrators who speak that language. If you were to decide later to make a modification related to the registry settings managed by the templates, you would need to make the change to each ADM file.

The second problem with ADM files is the way they are stored. An ADM file is stored as part of the GPT in the SYSVOL. If an ADM file is used in multiple GPOs, it is stored multiple times, contributing to SYSVOL bloat. Maintaining version control over ADM files also presented challenges.

To add classic administrative templates to the GPME, right-click the Administrative Templates node and then click Add/Remove Templates.

In Windows Vista, Windows Server 2008, and later versions of Windows, an administrative template is a pair of XML files, one with an .admx extension that specifies changes to be made to the registry, and the other with an .adml extension that provides a language-specific user interface in the GPME. When changes must be made to settings managed by the administrative template, they can be made to the single ADMX file. Any administrator who modifies a GPO that uses the template accesses the same ADMX file and calls the appropriate ADML file to populate the user interface.

To add ADMX/ADML administrative templates to the GPME, copy the ADMX file into the %SystemRoot%\PolicyDefinitions folder on your client, or in the central store. Copy the ADML file into the language-and-region-specific subfolder, such as en-us, of %SystemRoot%\PolicyDefinitions on your client, or in the central store. The central store is discussed in the next section.

As previously stated, ADM files are stored as part of the GPO itself, in the GPT. When you edit a GPO that uses administrative templates in the ADM format, the GPME loads the ADM from the GPT to produce the user interface. When ADMX/ADML files are used as administrative templates, the GPO contains only the data that the client needs for processing Group Policy, and when you edit the GPO, the GPME pulls the ADMX and ADML files from the local workstation.

This works well for smaller organizations, but for complex environments that include custom administrative templates or require more centralized control, Windows Server 2008 and Windows Vista introduced Central Store. Central Store is a single folder in SYSVOL that holds all the ADMX and ADML files that are required. After you have set up Central Store, the GPME recognizes it and loads all administrative templates from Central Store instead of from the local computer.

To create a central store:

After you have copied all ADMX and ADML files, the PolicyDefinitions folder on the domain controller should contain the ADMX files and one or more folders containing language-specific ADML files.

Windows Server 2008 and later versions allow you to add comments to policy settings in the Administrative Templates node. To do so, double-click a policy setting and add a comment in the Comment box.

It is a best practice to add comments to configured policy settings to document the justification for a setting and its intended effect. You should also add comments to the GPO itself. Windows Server 2008 and later versions allow you to attach comments to a GPO. In the GPME, right-click the root node in the console tree and choose Properties, and then click the Comment tab.

You can also search and filter based on policy-setting comments.

Another Group Policy feature introduced in Windows Server 2008 is starter GPOs. A starter GPO contains Administrative Template settings. You can create a new GPO from a starter GPO, in which case the new GPO is prepopulated with a copy of the settings in the starter GPO. A starter GPO is, in effect, a template. (Unfortunately, Microsoft was already using the term template in the context of administrative templates, so another name had to be found.) When you create a new GPO, you can choose to begin with a blank GPO or select one of the preexisting starter GPOs or a custom starter GPO.

After you create a GPO from a starter GPO, there is no “link” to the starter GPO. Changes to the starter GPO do not affect the GPOs that were previously created from the starter GPO.

Starter GPOs can contain only Administrative Templates policy settings. There are two other ways to copy settings from one GPO into another, new GPO: