Maintaining and Managing .Adm Files
Applies To: Windows Server 2003
This section provides guidance to ensure that your .adm files are properly configured for your administrative workstations.
Each domain-based GPO maintains a single folder in the Sysvol folder of each domain controller. This folder, known as the Group Policy template, contains all of the .adm files that were used in the Group Policy Object Editor when the GPOs were last created or edited.
Each Windows Server operating system includes a standard set of .adm files that are loaded by default into the Group Policy Object Editor. By default, the following .adm files are pre-loaded with a Windows 2000 or later operating system:
Windows Server 2003 and Windows XP include the following additional .adm files:
Importance of Timestamps for .Adm Files
Each administrative workstation that is used to run the Group Policy Object Editor stores its .adm files in the %windir%\Inf folder. When GPOs are created and first edited, the .adm files from this folder are copied to the Sysvol and replicated to all the domain controllers. This includes the standard .adm files and any custom .adm files that are created by the administrator.
|If you create a GPO and do not edit it, you will create a Group Policy template without any associated .adm files.|
By default, when you edit GPOs, the Group Policy Object Editor compares the timestamps of the .adm files in the workstation's %windir%\Inf folder (local .adm files) with those that are stored in the Sysvol (these are the .adm files used by the GPO that is being edited). If the local .adm files are newer, the Group Policy Object Editor copies these files to the Sysvol, overwriting any existing files of the same name. This comparison occurs whenever the Administrative Templates node (under Computer or User Configuration) is selected in the Group Policy Object Editor, regardless of whether the administrator actually edits the GPO.
|Because of the importance of timestamps on .adm file management, it is recommended that you do not edit system-supplied .adm files. If a new policy setting is required, it is highly recommended that you create a custom .adm file. This prevents the override of system-supplied .adm files whenever service packs are released.|
Duplicate CATEGORY Sections
If the .adm file that you add includes a duplicate CATEGORY to one that is used in an existing .adm file, the policy settings are merged.
An error can occur when the existing and the added .adm file contain the same CATEGORY, and both of them have a default KEYNAME specified (regardless of whether it is the same name). If these conditions are met, the following error message appears.
Key name specified more than once. Likely causes are: 1) the KEYNAME tag is defined multiple times in this category, 2) this KEYNAME is already defined in another category with the same name, 3) this KEYNAME is already defined in another category with the same name in a different .adm file.
.Adm Files Used by the Group Policy Object Editor
By default, the first time the Group Policy Object Editor is started for a specified GPO, it copies the System.adm file from the current computer's %windir%\inf\ directory to the GPO.
Subsequently, only those .adm files specified in the list are displayed. Each time you open Group Policy Object Editor, the Group Policy Object Editor also checks the listed .adm files and copies any newer versions from the local computer's %windir%\inf\ directory to the GPO.
.Adm Files Used by GPMC
By default, GPMC always uses local .adm files, regardless of their time stamp, and it never copies .adm files to Sysvol. If an .adm file is not found locally, GPMC looks for the .adm file in the Sysvol. In GPMC, you can specify an alternative location for .adm files. If an alternative location is specified, this alternative location takes precedence.
Controlling .Adm File Replication
Because .adm files are stored in the Group Policy template by default, they increase the Sysvol folder size. The File Replication Service (FRS) replicates all of the .adm files for GPOs throughout the domain. If you edit GPOs frequently, you might experience a significant amount of replication traffic. You can use a combination of the Turn off automatic updates of adm files and Always use local adm files for Group Policy Object Editor policy settings to reduce the size of the Sysvol folder and policy-related replication traffic.
Turn Off Automatic Updates of .Adm Files
The Turn off automatic updates of adm files policy setting is available under User Configuration\Administrative Templates\System\Group Policy in Windows Server 2003, Windows XP, and Windows 2000 operating systems. When this policy setting is enabled, the updating of an existing GPO remains local to the administrative workstation, and .adm files are not sent from the local computer to the Sysvol.
|In Windows 2000 operating systems, when you edit a GPO for the first time the local .adm files are uploaded to the Sysvol, without regard to how this policy setting is set. If this policy setting is enabled in Windows XP, .adm files are not uploaded when a GPO is edited for the first time. The first time that the GPO is edited might or might not be when the GPO is created.|
Always Use Local .Adm Files for Group Policy Object Editor
The Always use local ADM files for Group Policy Object Editor policy setting is available under Computer Configuration\Administrative Templates\System\Group Policy in Windows Server 2003 and Windows XP Professional. When a GPO is created, this policy setting has no immediate effect, and the .adm files on the local computer are still uploaded to the Sysvol. However, when you edit an existing GPO, any .adm files that are stored in the Sysvol are ignored, and Group Policy Object Editor uses the .adm files from the local computer only. If a policy setting has been set in the GPO, but the corresponding .adm file that describes the policy setting is not available on the local computer, Group Policy Object Editor does not display that policy setting.
|If this policy setting is enabled, the Turn off automatic updates of adm files policy setting is also implied.|
To clear the Sysvol folder of .adm files
Enable the Turn off automatic update of adm files policy setting for all Group Policy administrators who will be editing GPOs and verify that this policy has been applied.
Copy any custom .adm templates to the %windir%\Inf folder.
Edit existing GPOs, and right-click Administrative Templates, and then click Add/Remove Template to remove all .adm files from the Sysvol.
Enable the Always use local adm files for Group Policy Object Editor policy setting for administrative workstations.
Maintaining .Adm files on Administrative Workstations
When you use the Always use local adm files for Group Policy Object Editor policy setting, make sure that each workstation has the latest version of the default and custom .adm files. If all .adm files are not available locally, some policy settings that are contained in a GPO will not be visible to the administrator. Avoid this by implementing a standard operating system and service pack version for all administrators. If you cannot use a standard operating system and service pack, implement a process to distribute the latest .adm files to all administrative workstations.
|Because the workstation adm files are stored in the %windir%\Inf folder, any process that is used to distribute these files must run in the context of an account that has administrative credentials on the workstation.|
Multilanguage Administration Issues
In some environments, policy settings must be presented to the user interface in several languages. Because the GPT folder can store only one set of .adm files, you cannot use the GPT folder to store .adm files for multiple languages.
For Windows 2000 operating systems, the use of local .adm files for the Group Policy Object Editor is not supported. If you are using Windows 2000, use the Turn off automatic updates of adm files policy setting. Because this policy setting has no effect on the creation of new GPOs, the local .adm files will be uploaded to the GPT folder in Windows 2000. Creating a GPO in Windows 2000 effectively defines the language of the GPO. If the Turn off automatic updates of adm files policy setting is in effect on all computers running Windows 2000, the language of the adm files in the GPT folder will be defined by the language of the computer that is used to create the GPO.
If you are using Windows 2000 workstations, use the Turn off automatic updates of adm files policy setting for administrators, and consider the adm files in the GPT folder to be the effective language for all Windows 2000 workstations.
For administrators who are using Windows Server 2003 and Windows XP operating systems, the Always use local adm files for Group Policy Object Editor policy setting can be used. For example, this policy setting allows a French administrator to view policy settings by using the French .adm files that are installed locally, regardless of the adm file that is stored in the GPT folder. Note that when you use this policy setting, it is implied that the Turn off automatic updates of adm files policy setting is also enabled, to avoid unnecessary updates of the adm files to the GPT folder.
Consider standardizing on Windows Server 2003 for administrative workstations in a multi-language administrative environment. Configure both the Always use local adm files for Group Policy Object Editor and Turn off automatic updates of adm files policy settings.
Operating System and Service Pack Release Issues
Each operating system or service pack release includes a superset of the .adm files provided by earlier releases, including policy settings that are specific to operating systems that are different to those of the new release. For example, the .adm files that are provided with Windows Server 2003 include all policy settings for all operating systems, including those that are only relevant to Windows 2000 or Windows XP Professional. This means that only viewing a GPO from a computer with the new release of an operating system or service pack effectively upgrades the .adm files. Because later releases are typically a superset of previous .adm files this will not typically create problems, assuming that the .adm files that are being used have not been edited.
In some situations, an operating system or service pack release includes a subset of the .adm files that were provided with earlier releases. This has the potential to present an earlier subset of the .adm files, resulting in policy settings no longer being visible to administrators when they use Group Policy Object Editor. However, the policy settings will remain active in the GPO--only the visibility of the policy settings in Group Policy Object Editor is affected. Any active (either Enabled or Disabled) policy settings are not visible in Group Policy Object Editor, but remain active. Because the settings are not visible, it is not possible for the administrator to view or edit these policy settings. To work around this issue, administrators must become familiar with the .adm files that are included with each operating system or service pack release before using the Group Policy Object Editor on that operating system, keeping in mind that the act of viewing a GPO is enough to update the .adm files in the GPT, when the timestamp comparison determines an update is appropriate.
To plan for this in your environment, it is recommended that you either:
Define a standard operating system/service pack from which all viewing and editing of GPOs occurs, making sure that the .adm files being used include the policy settings for all platforms.
Use the Turn off automatic updates of adm files policy setting for all Group Policy administrators to make sure that .adm files are not overwritten in the Sysvol by any Group Policy Object Editor session, and make sure that you are using the latest .adm files that are available from Microsoft.
|The Always use local adm files for Group Policy Object Editor policy is typically used with the Turn off automatic updates of adm files policy setting, (that is, when it is supported by the operating system from which you are running Group Policy Object Editor).|
Keyboard Shortcuts for Administrative Templates Node
You can use the following keyboard shortcuts to navigate the Administrative Templates namespace:
SHIFT+asterisk (*) (on the keypad only) automatically expands the current node and all of its child nodes.
The plus sign (+) on the keypad expands one level.
Minus (-) on the keypad collapses one level.
Double-click a policy in the results pane to bring up the Properties page.
When the Properties page appears, move it out from in front of the Group Policy Object Editor window. Then, click back one of the Policies in the results pane. You can now use the cursor keys to navigate up and down the list. Notice that the information in the Properties page changes. This method also works for the text on the Explain tab. You can also use the Tab key to move back and forth between the tree pane and the results pane, while leaving the Properties page open.