Group Policy Templates Windows Server 2008

In the previous installment of our series dedicated to the most prominent Directory Services-related features available in the Windows Server 2008, we started discussing Group Policy functionality by describing its basic principles and providing an overview of innovations incorporated into its client-based components. In this article, we will shift our attention to improvements in the area of manageability, focusing on the new version of Group Policy templates.

The latest iteration of Group Policy templates offer much-improved manageability.

Starting with the Windows 2000 platform, Microsoft considerably enhanced its ability to centrally administer a variety of computer and user characteristics. Thanks to Active Directory based Group Policies, it became possible to enforce uniform settings across arbitrary collections of domain members. However, their initial implementation exhibited some undesired behavior. The majority of problems were related to the mechanism used to present registry-based settings in Group Policy editing tools, which relied on specially formatted files, known as Administrative Templates (also referred to as ADM files).

While their sole purpose was to provide a friendly interface when assigning desired registry modifications (actual changes were saved in a Registry.pol file stored in the %SystemRoot%sysvoldomainnamePoliciesPolicyGUID folder), they were also automatically copied to the same location (presumably to ensure consistent administrative experience during subsequent edits). This typically resulted in an increased volume of replication traffic and higher disk space usage on domain controllers, since each Group Policy Object that referenced registry entries defined by a template included its copy in the Adm subfolder of the GPO GUID-labeled folder under SYSVOL share. With sizes of individual ADM files reaching a few MB, negative impact in environments with large number of policies in place and slow network links was a serious consideration.

Another frequently encountered issue was caused by default behavior of Group Policy Editor, which automatically copied local (residing in the %systemroot%inf folder) version of an administrative template used during viewing or editing session, providing it was newer than the SYSVOL based one (note that such action can be prevented by enabling Turn off Automatic Update of ADM files Group Policy setting, located under Computer ConfigurationAdministrative TemplatesSystemGroup Policy node of a GPO). Reliance on timestamp (rather than version number) was commonly the source of unnecessary confusion (especially following Service Pack installation on client computers or modifications to Microsoft-supplied templates) and unexpected surge in replication traffic. Geographically distributed companies that operated in a multi-lingual environment faced an additional challenge, resulting from an inability of several, language-specific copies of a template to coexist in the same GPT folder.

Effectively, it was not unlikely for the SYSVOL to contain templates defined in different languages (depending on a location of creators of respective GPOs). Always use local ADM files for Group Policy editor Group Policy setting provided some relief to Windows XP and Server 2003 based IT staff when dealing with this issue; however, this workaround was contingent on having copies of all templates used across the enterprise on each administrative system. While this approach had its advantages (allowing you to remove ADM files from the SYSVOL share), it also introduced management overhead (forcing you to develop a methodology ensuring that consistent set of templates is maintained on all systems from which Group Policy is viewed or edited).

Leveraging ADMX templates

Vista and Windows Server 2008 help you resolve these problems by leveraging ADMX templates (the name is indicative of their new XML-based format), which offer a number of important advantages over their predecessors:

• The SYSVOL bloat caused by multiple copies of the same templates scattered across individual Group Policy Template folders is eliminated, since ADMX files are automatically loaded from a couple of designated locations. The first one is the %SystemRoot%PolicyDefinitions folder on a computer from which you intend view or edit registry-based Group Policy settings. The second one is a shared area called Central Store, corresponding to the domainPoliciesPolicyDefinitions directory under SYSVOL share, replicated across all domain controllers in the same domain (such approach minimizes volume of replication traffic and eliminates management overhead associated with maintaining set of templates on each administrative workstation).
• Unlike ADM files, their ADMX equivalents are identical, regardless of language settings of GPO creators. Elements of each template that vary depending on a language pack installed on the computer from which policies are created or viewed (such as Explain Text and the Supported strings) are stored separately in ADML resource files, residing by default in the %SystemRootPolicyDefinitionsLanguageID folder, where LanguageID represents an ISO locale identifier for a specific target language and culture (e.g. en-US designates the United States English).

These rules are a bit more complex in a mixed environment, where you encounter different versions of operating systems and template file types (as well as Group Policy Objects that were configured through their interaction). One one hand, the latest renditions of Group Policy Management Console and Group Policy Editor (present in both Vista and Windows Server 2008) will leverage the local PolicyDefinitions folder and attempt to connect to the Central Store, by checking whether the FullyQualifiedDomainNamePoliciesPolicyDefinitions folder (where FullyQualifiedDomainName designates fully qualified name of the domain where the edited GPO is hosted) resides under the SYSVOL share on a target domain controller. Note that Group Policy Editing tools connect by default to the PDC Emulator, although you have ability to point to a different one if desired via Change Domain Controller option in the Group Policy Management Console.

In addition, these tools are fully capable of working with either local or SYSVOL-based ADM files. More specifically, they will ignore ADM files if their ADMX-based counterparts are available, automatically load any custom ADM files residing in a target GPT folder, and allow you to add any additional ones using Add/Remove Templates... entry in the context-sensitive menu of the Administrative Templates node in the Group Policy Management Editor console. This behavior introduces an undesired side effect, causing any changes to the default ADM templates (such as Conf.adm, Inetres.adm, System.adm, Wmplayer.adm and Wuau.adm) to be missing from the Group Policy Editor interface once you start using its newer version. It would need to be incorporated into a custom template if you are planning on managing them going forward. Note that this does not impact in any way functionality of the corresponding Group Policy Object, since its registry changes are stored in Registry.pol file, not affected by your choice of templates.

On the other hand, keep in mind Windows XP and Windows Server 2003-based Group Policy management tools are not capable of editing or viewing ADMX templates, and they are not aware of the Central Store functionality. As the result, any existing registry-based GPO settings introduced via ADMX-based templates will not display correctly in the older versions of Group Policy Editor. Instead, they will appear in the “Extra Registry Settings” section of the Group Policy Management Console-based reports. Due to these limitations, you should avoid using Group Policy management tools from legacy systems in such scenarios. If this is not feasible for some reason, take advantage of the Always use local ADM files for Group Policy editor Group Policy setting we described earlier to prevent negative consequences associated with their default behavior. You must also ensure each of them has full range of templates avaialable locally.

Configuring Your Central Store

To configure the Central Store, you create a PolicyDefinitions subfolder under FullyQualifiedDomainNamePolicies folder in the SYSVOL share on an arbitrary domain controller in the target domain. You might want to start with its PDC Emulator. It is important to note that this does not have to be a domain controller running Windows Server 2008, since this feature does not have a dependency on the version of server operating system or a specific domain functional level. However, if you have not introduced any Windows Server 2008-based domain controller in your forest but want to be able to control via Group Policies some of enhancements introduced in Vista, such as wired and wireless connectivity, as well as BitLocker Drive Encryption and Trusted Platform Module functionality, you will need to extend Active Directory schema.

In the case of the former, you can follow instructions outlined in the TechNet article Active Directory Schema Extensions for Windows Vista Wireless and Wired Group Policy Enhancements. The procedure required to support the latter is also documented on TechNet site in the article BitLocker Drive Encryption Configuration Guide: Backing Up BitLocker and TPM Recovery Information to Active Directory.

Next, copy all content stored in the %SystemRoot%PolicyDefinitions (including ADMX files and language specific subfolders with ADML resource files) to the newly created folder on the domain controller. If you expect that the same set of templates will be used by administrators from other, non-U.S.-English countries, create corresponding language-specific subfolders and copy there appropriate set of ADML files. You can download them, along with Windows Server 2008 Administrative Templates, from the Microsoft Download Center. In addition, since local ADMX files (or their ADML counterparts) are no longer automatically copied to the SYSVOL share during viewing or editing domain-based Group Policy Objects, ensure that you keep the Central Store up-to-date whenever a new version of administrative templates is released (e.g., following a new Service Pack release, introduction of a new version of client or server operating system, or deployment of a feature supported via custom registry-based Group Policy settings).

Finally, include in your Central Store any custom ADM files that you have been using to configure existing Group Policy Objects. Keep in mind that you would need to repeat this procedure for each domain in your environment.

Unfortunately, even though the format of ADMX and ADML files is based on well-documented XML principles (you can find more information on this subject in the .admx and .adml File Structure Microsoft Technet and ADMX Schema MSDN articles), their creation or even direct editing is far from straightforward (incidentally, this was also one of more common complaints regarding their ADM-based predecessors).

If you are planning on switching fully to ADMX format (for consistency sake and to further limit size of SYSVOL), you might want to take advantage of utilities, which help with automating such transition, such as ADMX Migrator (created and supported by FullArmour, but available from the Microsoft DownloadCenter), which facilitates conversion via both command line and a Microsoft Management Console-based interface. The latter can also be used for for creating and modifying ADMX Administrative templates.

In the next article of our series, we will continue our discussion about the Group Policy related topics, focusing on features incorporated into a new version of Group Policy Management Console.

Follow ServerWatch on Twitter