If you deal with Active Directory in any way, you have certainly dealt with Group Policy. One of the main components of a Group Policy Object is control over the Registry. This Registry control within Group Policy is primarily managed by the inclusion of administrative templates. These templates are beneficial, but they also come with some negatives. One of the negatives that can cause issues is with regard to controlling the management of the templates as new versions come out. There is a solution to not only this issue, but to many of the issues that surround these templates. Here, you are exposed to one solution, a repository solution, that solves many issues with administrative templates.
Administrative Template Basics
Administrative templates are text files that contain simple code that helps enable Group Policy perform custom Registry modifications. These templates are stored in files that end in .ADM, which is where the name ADM template comes from. The templates are essential for Group Policy, as they perform two different functions.
The first function that the ADM template performs is to create the policies and settings within the Group Policy Object Editor. All of the settings that are created from the ADM templates show up under the Administrative Templates nodes, as shown in Figure 1.
Figure 1: Administrative Templates nodes are formed by the ADM templates that are included in the GPO
Each ADM template contains information for both the user and computer portions in the GPO. There are keywords used in the ADM template to separate out the two sections.
The second function of the ADM template is in relation to the user and computer settings that are created within the files. The ADM templates also dictate the exact Registry path, value, and data that each setting alters. All user settings in the ADM templates will update the HKEY_CurrentUser portion of the Registry, where the computer settings update the HKEY_Local_Machine area in the Registry.
Figure 2 illustrates a typical entry in the ADM template which updates a Registry entry.
Figure 2: The ADM template syntax indicates the HKEY, path, value, and data for every setting created within the template
Default ADM Templates
For Windows Server 2003 GPOs, there are a total of 5 default ADM templates. These ADM templates are geared to control certain aspects of the Administrative Templates node in the GPO, which Table 1 specifies.
General system settings
Windows Media Player
Windows Update/Automatic Update
Table 1: Each ADM template is designed to control specific settings in the GPO
The total size of the default ADM templates is nearly 4 MB. Although the files are few in total, they take up quite a bit of space.
ADM Template Bloat
To understand ADM template bloat, you must understand how GPOs are stored. Each GPO is broken up into two parts and each part is stored in a different location on the domain controllers.
One part, called the Group Policy Container (GPC), is stored as an object in Active Directory. The main role of ths part of the GPO is to keep all of the links, locations, and paths of the different aspects of the GPO in tact. The GPC does not contain any of the settings or templates.
The second part of the GPO, called the Group Policy Template (GPT), is stored as files under the SYSVOL on domain controllers. The exact path of the GPT is c:\Windows\SYSVOL\sysvol\<domainname>\Policies\<GUID of GPO>. This portion of the GPO is 100% responsible for storing the specific settings that are configured in the GPO. Not only does the GPT store the settings in a wide variety of files, it also keeps a copy of the ADM templates there, as shown in Figure 3.
Figure 3: ADM templates are stored in each GPT
The problem with ADM bloat is that each GPT stored a copy of the ADM templates, not just one of them. Thus, if you have a multitude of ADM templates, the total space that can be taken up by them can be substantial. There are many companies that have over one thousand GPOs, which is about 4 GB of space just for the ADM templates.
In addition to taken up so much space, these ADM templates also need to be replicated to all domain controllers. The File Replication Service (now called DFS Replication in some versions of Windows) is in charge of this replication.
ADM Version Checking
One solution to the ADM template bloat issue is to simply delete the ADM templates from the GPT. This seems reasonable in theory, but the default controls of ADM templates indicate that the ADM template from the GPT should be used when editing a GPO.
To understand the process of how the system controls the ADM templates, let's track how a GPO uses the ADM templates when a GPO is edited.
- When a new GPO is first edited, the local versions of the ADM templates are copied to the ADM folder in the GPT.
- On subsequent edits of the GPO, the system will compare the date stamp of the ADM template stored in the GPT to the ADM template stored on the machine performing the administration. If the local version of the GPO has a newer date stamp, it is copied to the GPT, overwriting the older version.
- If the GPT or the computer performing the edit of the GPO does not have a copy of the ADM, then that portion of the Administrative Templates node in the GPOE will not be available. This includes the default ADM templates or any custom ADM templates.
ADM Template Tampering
These issues can cause significant problems with the overall management of Group Policy. Not only can it cause problems with replication and storage, but you can see that versions of the ADM templates can become updated quickly, and potentially with malice intent. If a rogue administrator were to update the local ADM template with an alteration to the Registry value and data being updated. With the default behavior of how ADM templates are updated, the entire array of ADM templates stored in the GPTs could be corrupted with just editing the GPOs.
Creating an ADM Repository
A solution to the updating of the ADM templates in the GPT, which will eliminate all of the negatives to the ADM templates, is to create a centralized repository for the ADM templates. There are only a few steps that need to be performed to create the central repository. I should note that the central repository is not just on one machine, but is on every machine that will perform administration of GPOs. With the way that current versions of Windows work with ADM templates, it is not possible to use a UNC path for ADM templates.
To create a centralized repository for ADM templates, follow these steps.
- Delete the ADM templates from each GPT.
- Place a copy of the latest version of every ADM template (default and customized) into the C:\Windows\Inf folder on every desktop that will administer GPOs.
- Create a GPO that will target the computers modified in step 2. In the GPO, modify the Always Use Local ADM Files for Group Policy Editor setting, which is located under Computer Configuration\Administrative Templates\System\Group Policy. The setting should be set to Enabled.
- Create a GPO that will target the user accounts that have privileges to edit GPOs. In the GPO, modify the Turn off Automatic Updates of ADM files setting, which is located under User Configuration\Administrative Templates\System\Group Policy. The setting should be set to Enabled.
Now, when a GPO is edited, it will only use the local copy of the ADM templates, which are all stored locally. The editing of a GPO will now also negate the version checking of the ADM templates in both locations, only relying on the local version.
As an option, you can also help secure the ADM templates by using a new policy setting that is available in PolicyMaker. This setting allows you to perform a file deletion, then file copy. The goal is to first remove all of the ADM templates on a GPO management computer when the computer boots up. Then, when the user logs in, the correct versions of the ADM templates will be copied down to the computer from a secured location on the network. The setting that you will want to configure is located under both the Computer Configuration and User Configuration, after you get PolicyMaker installed. Look under the Policymaker\Windows Settings node, where you will find the Files policy. Here, you will create one policy for the computer that deletes the ADM templates, and another policy under the user portion that copies the ADM templates to the computer. Ideally, you will just make the appropriate user and computer settings in the GPOs that you created above.
PolicyMaker is still available for a short time from www.desktopstandard.com. This technology will be available in the Windows Server 2008 time frame, due to the fact that Microsoft now owns PolicyMaker and will include it for use with Windows Server 2008.
ADM templates are not longer the format of default Registry settings in a GPO. Windows Vista and Windows Server 2008 use ADMX files, which are XML based. For those companies not moving to Windows Vista or Windows Server 2008, the ADM repository is a great option. ADMX files come with their own repository, which should be setup and used if you will move to these new OSs. For more information on the ADMX repository, see How to create a Central Store for Group Policy Administrative Templates in Windows Vista.
ADM template management has been an issue for quite some time. The behind the scenes processing and control of the templates is not very controllable, without using GPO settings. However, the issues with ADM templates around bloat, replication, version checking, potential malice behavior, and centralizing the ADM template management is possible with just a few tweaks within the system. Once you have the list of user accounts and computers narrowed down, you can just establish GPOs to control how these systems manage ADM templates, ensuring you now know where the ADM templates are being used from.