ADM Template Management Best Practice | Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

It's highly likely that you'll have to maintain various levels of service packs throughout the rest of your Group Policy career. To that end, here are several suggestions for the best practice of managing ADM template files.

Create a Windows XP Management Workstation

As I suggested in the previous section, I believe you'll want to create a management workstation to control precisely where the ADM files are coming from. First, create a Windows XP machine with the latest service pack. As of this writing, Windows 2003/SP1 is the latest released version of Windows with ADM templates. Whenever Microsoft releases a service pack for Windows XP or Windows 2003, immediately load it on your management workstation. If Microsoft releases another service pack for Windows 2003 or Windows XP, pluck out the ADM files from the service pack and plunk them into the Windows XP's \windows\inf folder. Yes, you read that righttake the ADM files from the latest-released operating system and plunk them onto your management station.

Additionally, if you use any ADM templates for Office or other applications, plunk those into the \windows\inf folder of your management workstation as well. This has a multilayered benefit:

Whenever you create new GPOs from this management workstation, the latest ADM files are used.
Whenever you modify old GPOs from this management workstation, the latest ADM files are used for updates.
Whenever you run reports using the GPMC, the GPMC will have the latest version of the ADM template files, and reports will show properly.
Whenever you want a nondefault template (such as Word9.adm from Office 2000 or the set_sounds.adm file you created), you'll always have it at your fingertips.

We've already looked at the first two bulleted items; now let's examine the last two.

Ensuring GPMC Reports Come Out Right

Figure 5.9 displays an ad hoc report from the Settings tab of a GPO where the management workstation does not have the latest copy of the ADM templates.

Figure 5.9: Without the latest ADM templates, your GPMC reports could come up short.

In Figure 5.9, you can see that the GPMC cannot determine the names of the actual policy settings; therefore, doing the best it can, it displays the Registry path that the policy setting is supposed to set. Clearly, this is not ideal. Again, the best thing to do is to drop the latest ADM templates into the \windows\inf folder on the management workstationand you'll be golden.

Note	You'll have to rerun some reports to see the updated settings, or you might have to close the GPMC and reopen it.

Using Add-In ADM Templates on Your Management Workstation

As you saw earlier, you can use Microsoft or third-party ADM templates to get a broader reach on your applications, such as Microsoft Office. The same advice applies here: place the latest ADM files for your applications on your management workstation. That way, whenever you create a new GPO or modify an existing GPO, you'll never have to worry about not having the ADM template you need. When you right-click Administrative Templates, you'll be able to select any template you placed on your management workstation's \{systemroot}\inf folder.

GPMC Reporting Options

The GPMC has some options for specifying where to look for ADM files when running reports. If you choose View ˜ Options ˜ Reporting, you open the Options dialog box at the Reporting tab (see Figure 5.11), in which you'll see the options for hunting down the ADM templates used in reports.

You can point the reporting mechanism toward a centralized path if you want to maintain a repository for the latest ADM templates; but this is only for reporting purposes.

Be careful regarding the Default option, as shown in the above figure. It implies that if the latest version is in the SYSVOL (and not on the local {system root}\inf folder), the report will function. This does not appear to be the case. The latest ADM templates must be loaded in the local {systemroot}\inf folder for reports to work. Otherwise, you get the message shown in Figure 5.10 earlier in this chapter.

Figure 5.10: Open the ADM template to locate the policy and the corresponding Registry hack.

Throttling an Automatic ADM Template Upgrade

You can specify two policy settings that affect how your Group Policy Object Editor deals with ADM templates:

Always use local ADM files for the Group Policy Object Editor (located in Computer Configuration ˜ Administrative Templates ˜ System ˜ Group Policy).
Turn off automatic update of ADM files (located in User Configuration ˜ Administrative Templates ˜ System ˜ Group Policy).

The first policy setting describes what should happen when you're using the Group Policy Object Editor. Enabling this policy setting uses the local {systemroot}\inf version of the ADM files while you view and edit the GPOsregardless of what version is really inside the SYSVOL part of the GPO. You might want to do this, as the policy setting suggests, if you have administrators modifying the same GPOs with different languages. You can see the policy settings in English, and the other administrator can see the policy settings in their language. That is, if you've set this policy to force their Group Policy Object Editor to look in their local {systemroot}\inf folder while editing.

Enabling the second policy setting prevents the local {systemroot}\inf versions of the ADM template from being copied into your GPO. In other words, whatever is on the server is used. If you disable the second policy setting, the default behavior is used; that is, the local {systemroot}\inf versions of the ADM template are always copied to the GPO. This might be useful if you're concerned about your SYSVOL getting too large and you want to micromanage which ADM templates are to be updated. Personally, I don't think you should use this setting.

Tip	You can learn more about the interaction between the two policy settings in the Microsoft Knowledge Base article 316977: "Group Policy Template Behavior in Windows Server 2003."

Another Use for the Always Use Local ADM files For The Group Policy Object Editor Policy Setting

There's another reason you might want to implement the Always Use Local ADM Files For The Group Policy Object Editor policy setting. The other reason for doing this comes down to traffic.

Remember how we said that whenever you create a new GPO, it "pushes up" the local ADM files (stored in \windows\inf) up into the SYSVOL part of the GPO. Indeed, each GPO you create takes about 4MB of disk space on each Domain Controllermost of this is a copy of the ADM files themselves .

And, after that one GPO is born, its 4MB of ADM template stuff is replicated to all domain controllers. So that replication takes up both disk space and replication time. Microsoft sometimes refers to this two-fold problem as "SYSVOL bloat."

So, here's the idea: If you don't keep the ADM files inside the SYSVOL, you're not hardly replicating 4MB of ADM stuff. You're just replicating the teeny-weeny part of the actual GPO itself that "does the work." To that end, you could enable this policy that basically says: "I'm not going to keep ADM files in the SYSVOL folder." After you do this, new GPOs won't push up their ADM template into the SYSVOL.

The downside, however, is that if you try to edit the GPO on a machine that doesn't have the same ADM templates as the GPO (or worse , the local machine is just plain missing an ADM template) you'll simply not be able to edit the GPO the way you want. You'll have to track down the original machine that had the full complement of ADM templates to properly manage the GPO.

Microsoft talks a bit more about this in MSKB 816662.