Managing Windows ADM Templates

You're likely to have a mix of client and server systems. It's likely you'll have Windows 2000 and Windows 2003 Domain Controllers, and Windows 2000 and Windows 2003 Servers and both Windows XP and Windows 2000 Professional clients . As I noted in Chapter 1, Windows XP and Windows 2003 have about 200 more policy settings available to them than their Windows 2000 pals do.

Note	You can see all the new Windows XP and Windows 2003 policy settings in "New Policy Settings for Windows 2003 and Windows XP" on this book's website, or on www.GPOanswers.com .

The good news (as I've previously stated) is that Windows 2000 clients ignore policies meant for Windows XP or Windows 2003. So there's really no reason not to use the latest version of the built-in template files to manage your entire universe: Windows 2000, Windows XP, and Windows 2003. The bad news is that if you're migrating to Windows XP clients but have already done a lot of work by creating GPOs with Windows 2000 Domain Controllers, some potential headaches are just around the corner.

Figure 5.8 shows a typical domain, w2kdomain.com, that has the following:

Windows 2000 Domain Controllers (various SP levels)
Windows 2003 Domain Controllers
Windows XP clients (various SP levels)
Windows 2000 clients (various SP levels)

Figure 5.8: A typical Windows 2000 network in transition

The goal is to leverage the latest ADM templates that will allow you to have maximum control over all your client systems.

How do You Currently Manage Your Group Policy Objects?

Before we proceed, you need to answer this question: How do you currently manage, create, and modify your GPOs? You have three main options:

Use a Domain Controller (or use Terminal Services to connect directly to a Domain Controller) to create or modify your GPOs.
Load the administrative tools ( specifically Active Directory Users And Computers or the GPMC) on any machine (workstation or server) you want, and then do your management.
Use a specific machine to manipulate all the GPOs over which you have control. That is, you have a management workstation you use when you need to manage your GPOs.

If you use either the first or second option, you're likely going to want to change your habits and start working with a strategy that gets you toward a management workstation. Here's why. Every time a new operating system is released, and again each time a new service pack is released, the base ADM templates change. Over time, Microsoft updates the ADM templates for bug fixes or clarity in the help files. Sometimes Microsoft changes the name of a policy setting for clarity (though its underlying actions are usually the same), and occasionally a new policy setting pops up that a target system might embrace. For instance, about five new policy settings were available in Windows 2000 + SP4, about two or three were available for Windows XP + SP1, and a whopping 600 or so were made available with XP + SP2. And a small handful of additional settings were made available with Windows 2003/SP1.

Microsoft makes updates; you have more power, right? Sure. And this sounds great, until you recognize the behavior of ADM template management.

ADM Template Behavior

Recall from Chapter 4 that when you use any ADM templates, including the defaults or any custom or additional ADM templates, these templates are added to the file-based Group Policy Template (found in SYSVOL) of the GPO. Unfortunately, there's no master update location where you can just drop the latest ADM files from Microsoft (or other vendors ) and universally update the ADM files of existing GPOs and any future GPO that will be created. Indeed, you'll need to understand where new GPOs get their ADM templates from when you create new GPOs or modify existing GPOs.

Creation Behavior with ADM Templates

If you want to create new GPOs and take advantage of the latest ADM templates, you really have to understand how the ADM update mechanism works. Here's the trick about creating GPOs with regard to ADM template files:

The ADM template files used to make a GPO are always copied from the place where you are running your editor. Not to put too fine a point on it, here's precisely what I mean:

If you create new GPOs while running Active Directory Users And Computers on a computer running Windows 2000 + SP4, the ADM files are from SP4. Consequence: You won't be able to see policy settings for Windows XP or Windows 2003.
If you create new GPOs while running Active Directory Users And Computers or the GPMC on a computer running Windows 2003, the ADM files are from Windows 2003. Consequence: You won't be able to see policy settings for Windows XP/SP2 or Windows 2003/SP1.
If you create new GPOs while running Active Directory Users And Computers or the GPMC on a computer running Windows XP, the ADM files are from Windows XP. Consequence: You won't be able to see policy settings for Windows XP/SP2 or Windows 2003/SP1.
If you create new GPOs while running Active Directory Users And Computers or the GPMC on a computer running Windows XP + SP2, the ADM files are from SP2. Consequence: You won't be able to see policy settings for Windows 2003/SP1.
If you create new GPOs while running Active Directory Users And Computers or the GPMC on a computer running Windows 2003/SP1, the ADM files are from Windows 2003/SP1. Consequence: Things are great! You can see policy settings for all current and previous ver sions of Windows as far back as Windows 2000 and as far forward as Windows 2003/SP1.

In all cases, the editor you use (either Active Directory Users And Computers or GPMC) really uses the GPEDIT function (really the GPEDIT.DLL) when actually poking around or creating new GPOs. GPEDIT pulls the ADM template files from the computer it is running on. And it pulls these ADM template files from \{systemroot}\infusually c:\windows\inf.

So, if you want the latest ADM templates to be used when creating new GPOs, you need to plop them into the \{systemroot}\inf folder that contains your Group Policy Object Editor. That way, the next time GPEDIT is used to create a new GPO, it pulls the latest ADM files you copied into the \{systemroot}\inf folder.

Tip	Read on to the "ADM Template Management Best Practice" section to learn my take on how to best update your GPOs.

Modification and Update Behavior with ADM Templates

Now, let's imagine that you created 200 GPOs in this way. That is, you created 200 GPOs by using the machine named W2kDC3 (which has some old-and-crusty Windows 2000 version of the ADM files). Now, you learn about a policy in Windows XP that requires the corresponding Windows XP templates.

You want to update your existing GPOs with the Windows XP versions. Here's the trick about modifying GPOs with regard to ADM template files: the ADM template files used to modify and update a GPO are always copied from the place where your editor is running.

ADM templates are automatically updated when you re-edit a GPO on a machine where the editor (Active Directory Users And Computer or GPMC) has newer ADM templates than are already in the GPT. Recall that the GPT is the Group Policy Templatethe files-based portion of Group Policy.

For instance, if you walk up to the machine named W2kDC4 (running SP4) and manipulate any Windows 2000-level GPO by editing it and merely look at the policy settings in the Administrative Templates section, the editor will say: "Ah-ha! I've got Windows XP templates available to me! This specific GPO's ADM templates are only Windows 2000! I'll update the underlying ADM templates automatically to Windows XPwithout even saying a word."

And it then proceeds. And it proceeds because the time/date stamp for Windows XP ADM templates your editor has access to is more recent than the time/date stamp for Windows 2000 ADM templates. It's doing you a favor behind your back. You must repeat for every old GPO you want to update. That is, you must open each old GPO and look at the policy settings in the Administrative Templates section. Then they'll be updated.

Again, there's no universal master update location where you can just "drop in" your latest ADM templates and be done. However, with a script, you could update all your GPOs at one time (which is what we'll discuss in the next section).

Automatically Updating All Your GPOs at Once with the Latest ADM Templates

In Chapter 7, you'll get a grip on all the myriad of things you can do with scripting and Group Policy. However, one thing that we won't tackle there (but we do want to tackle here) is how to automatically update all your existing GPOs with the latest ADM templates. As of this writing, the latest ADM templates are Windows 2003/SP1, but you could use this same tip to update all your GPOs with the ADM templates from, say, Windows XP/SP2 or earlier (not that you would really want to.)

To update all your GPOs (or just some of them), Microsoft has a downloadable script that will do this for you. You can find it at http://www.microsoft.com/technet/scriptcenter/solutions/admupdate.mspx (or shortened to http://tinyurl.com/7v4s2 ). It runs as a command line (as opposed to a GUI-based script.) I had some trouble getting this script to work 100 percent of the time. I alerted Microsoft to this problem, and they sprung into action and rightly fixed the script. However, as with everything, be sure to try in a test lab first before trying this in production.

When ready to give the script a try, be sure to set the script to run at the command line by initially typing the following command:

 cscript //h:cscript

Once performed, you'll be ready to run it. Here's what you need to tell the script:

You need to tell it which GPOs to update. You can update using the /GUID switch, the /GPOfriendlyname switch, or the very powerful /ALL switch.
You need to tell it where the latest ADM files reside. You do this with the /ADMSRC switch.
You need to tell it what domain to update. You do this with the /DNSDOM:< domain > switch.

There are other switches available, but these are the ones I'll need for this example. In the following example, I'm specifying to update all GPOs with the latest ADM files living in c:\windows\inf and update the GPOs in the corp.com domain.

If you tell it just this much information, it performs a simulation of what it will do.

You can see the output of this command run here:

 C:\script>cscript //h:cscript Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. The default script host is now set to "cscript.exe". C:\script>updateadm /ALL /ADMSRC:c:\windows\inf /DNSDOM:corp.com Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. updateadm.vbs - Updates Group Policy ADM files Updating Deploy the GPMC Adm Files... File Copy Mode:Disabled Copying File C:\WINDOWS\inf\conf.adm to \corp.com\sysvol\corp.com\Policies\{05BD2375-C45A-4FOO-898D- OA8833B75114}\Adm\conf.adm Copying File C:\WINDOWS\inf\inetres.adm to \corp.com\sysvol\corp.com\Po1icies\{05BD2375-C45A-4F00-898D- OA8833B75114}\Adm\inetres.adm Copying File C:\WINDOWS\inf\system.adm to \corp.com\sysvol\corp.com\Policies\{05BD2375-C45A-4F00-898D- OA8833B75114}\Adm\system.adm Copying File C:\WINDOWS\inf\wmplayer.adm to \corp.com\sysvol\corp.com\Policies\{05BD2375-C45A-4F00-898D- OA8833B75114}\Adm\wmplayer.adm Copying File C:\WINDOWS\inf\wuau.adm to \corp.com\sysvol\corp.com\Policies\{05BD2375-C45A-4F00-898D- OA8833B75114}\Adm\wuau.adm Updating Remove Search Adm Files... File Copy Mode:Disabled Copying File C:\WINDOWS\inf\conf.adm to \corp.com\sysvol\corp.com\Policies\{1515134B-778C-45EB-8946- 08A2792DC96C}\Adm\conf.adm Copying File C:\WINDOWS\inf\inetres.adm to \corp.com\sysvol\corp.com\Policies\{1515134B-778C-45EB-8946- 08A2792DC96C}\Adm\inetres.adm Copying File C:\WINDOWS\inf\system.adm to \corp.com\sysvol\corp.com\Policies\{1515134B-778C-45EB-8946- O8A2792DC96C}\Adm\system.adm Copying File C:\WINDOWS\inf\wmplayer.adm to \corp.com\sysvol\corp.com\Policies\{1515134B-778C-45EB-8946- 08A2792DC96C}\Adm\wmplayer.adm Copying File C:\WINDOWS\inf\wuau.adm to \corp.com\sysvol\corp.com\Policies\{1515134B-778C-45EB-8946- 08A2792DC96C}\Adm\wuau.adm

When you're actually ready for the script to do the deed and perform the upgrade, you need to add the /FILECOPY:ON switch (not shown in the preceding example). This actually performs the work. Note that this could take a long time and cause a lot of replication traffic. So, be sure to do it in the off-hours if possible.

Again, running this script isn't expressly necessary. This is because, as we've discussed, anytime you specifically touch an old GPO with an updated management station, the GPO will be automatically updated. Use this script to simply guarantee that the latest ADM files are pushed to every GPO. However, if you choose to update all GPOs with the latest ADM files and then intend to modify those GPOs using older systems (such as Windows 2000, Windows 2003 [pre-SP1], or Windows XP [pre-SP2]), be sure to read and apply the knowledge contained within the next section, "ADM Files Beyond XP/SP2: The Retroactive Bug That Ate New York."

ADM File Fine Print for Windows 2000 SP4 and Windows XP SP1

Hopefully, you're utilizing the Windows XP/Service Pack 2 templates, as previously described. However, it could still be common that you're using Windows 2000 SP3 and Windows XP SP1 still (and not yet using any Windows XP SP2 templates). As I just stated, ADM templates are automatically updated if your editor has access to newer ADM files than those stored on the server. However, things aren't always as they seem. You might be thinking to yourself: "This is great! I'll run out and update all my current GPOs that have Windows 2000 ADM templates so now they have the Windows XP or Windows 2003 templates." That way, all GPOsold and newcan be used to manage Windows 2000, Windows XP, and Windows 2003.

The plan is good; just make sure you don't fall into the following trap. That is, the time/date stamp on Windows 2000 SP4 ADM files is more recent than even the time/date stamp on Windows XP + SP1 ADM files. Here's what that means:

You upgrade all your Windows 2000 domain controllers to SP4.
You create a Windows XP machine with SP1 and load the GPMC on it.
You attempt to modify an existing GPO that you created with Windows 2000 + SP4 to update it with the Windows XP ADM templates.

When you launch the GPMC on the Windows XP machine with SP1, you would expect that the ADM files from Windows XP's SP1 would overwrite the Windows 2000 ADM files. But the Windows 2000 + SP4's ADM files in the GPTwon't be updated. Windows XP + SP1 's ADM templates are dated 9/3/2002. Windows 2000 + SP4's ADM templates are dated 6/19/2003. Who's newer? Windows 2000 + SP4, actually, so the ADM templates won't automatically update.

The solution is simple: Change the date/time stamp on the Windows XP + SP1 ADM templates to today's date. It's easy: Just open each of them ( Conf.adm, Cntetres.adm , and System.adm ) in Notepad, and then resave them. The next time your Windows XP machine with the GPMC opens the GPOs created with Windows 2000 + SP4's ADM templates, the time stamp on the ADM templates will be newer and will, in fact, be updated.

ADM Files Beyond XP SP2: The Retroactive Bug that Ate New York

Recall that when you create GPOs in AD, you can do so from anywhere . Some examples have shown how you can create a new GPO by logging on locally to a domain controller (DC). You can then walk back to your desktop and modify that GPO through GPMC or the Microsoft Management Console (MMC) Active Directory Users And Computers snap-in. Hopping between machines like this usually isn't a problemunless you use Windows XP/SP2 or Windows 2003/SP 1 create the original GPO, and then use a non-Windows XP/SP2 (or Windows 2003 + SP1 machine to modify it).

For instance, imagine the following:

Bill creates a new GPO called "Our Windows XP Firewall Settings" from his Windows XP/SP2 machine. The GPO is hanging out in the swimming pool of the domain.
Fred then modifies this GPO from his Windows XP/SP1 machine.

When this happens, you'll get an error like that seen below. To clear this error, you need to press OK about 50 ( yes, 50 ) times.

The cause of this difficulty is known as the LISTBOX ADDITIVE problem. This is a "retroactive" bug that manifests only if you try to view templates from XP/SP2 (and newer) on Windows XP, Windows 2003, and Windows 2000 machines that aren't prepared to understand these new templates. Specifically, older versions of the GPEDIT can't process a. syntax that occurs only within XP + SP2 and Windows 2003 + SP1 ADM templates.

Microsoft describes this problem and has hot fixes available at http://support.microsoft.com/?kbid=842933 . There are patches for Windows Server 2003 (pre-SP1), Windows 2000, and Windows XP (with or without SP1).

To be especially clear, you need to load the patches only on machines where you modify Group Policynot every machine in the domain or all domain controllers (unless that's where you typically modify Group Policy from).

After your Windows XP machine has Windows XP/Service Pack 2 (or the patch), or your Windows 2003 machine has SP1 (or the patch), or your Windows 2000 machine has the patch, you won't see this error anymore.