Extending Group Policy

Downloads
43203.zip

You're probably well aware of how you can use Group Policy to manage Windows XP Professional Edition and Windows 2000 Professional clients. What you might not know, though, is that you can create custom Administrative Templates to use with Group Policy to leverage Group Policy's broad management capabilities for items other than the standard OS-related Group Policy settings. Let's examine why you might want to create your own custom Administrative Templates and how the technology works and explore some caveats. Then, we'll dig into the nuts and bolts of bringing isolated applications under the management umbrella of Group Policy.

The Case for Custom Administrative Templates
Assisting users is certainly easier when they all share a consistent look and feel for a given application. In many cases, you can use custom Administrative Templates to nudge your users toward a more consistent environment, even if an application is manageable via Group Policy out of the box. Likewise, if a specific setting for an application generates confusion and support calls, you can use custom Administrative Templates to configure the setting to a desired value. These settings might include limiting access to or hiding advanced features within applications. You can also use custom Administrative Templates to populate registry-stored data for applications.

Registry-Based Group Policy
Group Policy uses Administrative Templates to implement registry-based policy, which means that any settings configured by a Group Policy Object (GPO) are stored in the registry. These registry-based settings, referred to as System Policy in Windows NT 4.0, comprise the majority of policies implemented through Group Policy.

When you use a vendor-supplied Administrative Template, it stores any changes it makes in one of four approved locations for registry-based policy settings: HKEY_LOCAL_MACHINE\SOFT-WARE\Policies, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current-Version\Policies, HKEY_CURRENT_USER\Software\Policies, or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies. These locations have special permissions to prevent users from tinkering with the subkeys and values therein. Another important distinction about these locations is that any subkeys created by a GPO are removed from the registry when that GPO is removed. Settings stored here are also nonpersistent, meaning that they're removed each time the GPO is reapplied.

This system of approved registry subkeys for important settings works well for the Windows OSs and for applications that are written to take advantage of Group Policy. However, some other applications have registry subkeys outside these approved locations that you'll want to alter. Microsoft supports altering registry subkeys in other locations, but you should consider a few caveats and rules of thumb when doing so.

As I mentioned, subkey changes that adhere to Microsoft's guidelines are nonpersistent. But subkey changes in other locations (such as the ones I show you how to make in this article) are persistent, which means that they remain in the registry even after you remove the GPO that implemented them. Thus, making such changes is known as tattooing the registry. Furthermore, although your GPO-implemented registry settings can be altered manually or by an application, the next GPO refresh will reset them to the GPO-implemented values. Technically, the settings you configure through custom Administrative Templates are preferences rather than GPOs.

Another thing to be aware of when implementing preferences is that the user interface of the application being managed might not be equipped to reflect in a user-friendly manner the changes you make. Applications designed to be managed with Group Policy will gray out or hide certain buttons or menu choices based on Group Policy settings. You should test the behavior of applications that you want to manage in this fashion on a case-by-case basis.

The first rule of thumb in working with custom Administrative Templates is that you should be fairly familiar with the registry and know the potential effects of malformed entries. Creating custom Administrative Templates isn't for novices. Second, don't just customize an existing Administrative Template provided with the OS or with a Group Policy­ready application. Instead, copy the existing template and use the copy as a boilerplate for a new, renamed template. (Existing Administrative Templates are overwritten by updates such as service packs.) Third, don't reinvent the wheel. Before you begin to create a template to manage a group of settings, make sure a template doesn't already exist that covers the same territory.

You can download Administrative Templates for managing Windows (including Windows Media Player—WMP) at http://www.microsoft.com/downloads/details.aspx?familyid=92759d4b-7112-4b6c-ad4a-bbf3802a5c9b&displaylang=en. Other Administrative Templates are available as downloadable resource kit tools. For example, the Microsoft Office 2000 Resource Kit includes System Policy templates for managing Office 2000 applications. You can read about them at http://www.microsoft.com/resources/documentation/office/2000/all/reskit/en-us/95ct_10.mspx. You can download the Microsoft Office 2000 Resource Kit core tool set (orktools.exe), which contains them, at http://www.microsoft.com/office/ork/2000/appndx/toolbox.htm#orktools.

Administrative Template Basics
Administrative templates are text files with an .adm extension stored in the %systemroot%\inf folder. You can load these templates into the Microsoft Management Console (MMC) Group Policy Editor snap-in to display the settings that you can configure and deploy. When you look at an existing .adm file for the first time, you might find it kind of confusing. After you learn the basic components and keywords and how they work together, though, you'll be able to interpret and create your own templates.

The .adm language has eight basic components, each of which can use a group of keywords that define the options that the Group Policy Editor snap-in will make available when you edit a GPO. The sample Administrative Template in Web Listing 1 shows how to use the components and commonly used keywords to manage preferences for WinZip Computing's WinZip. You can download the template and load it per the instructions in this article's "Test, Test, Test" section to see the results of a custom template. Having WinZip installed will let you better see the effects of the sample GPOs. If you don't have WinZip, you can download a 21-day evaluation version from http://www.winzip.com/downwzeval.htm. The eight components are Comments, Strings, CLASS, CATEGORY, POLICY, PART, ITEMLIST, and ACTIONLIST.

You use Comments to document the .adm file. A semicolon should precede each comment. Comments can be on a line by themselves or they can follow a component or keyword statement. Comment lines (in black text in the sample .adm file) describe the functionality of the various template sections.

Strings provide shorter, more manageable tags for pieces of text. You define Strings at the end of an .adm file in a \[strings\] section in the form

stringname="value"

Components and keywords in the main body of the template reference Strings by prefacing them with a pair of exclamation points (!!), as in

!!stringname

The \[strings\] section (in orange text in the sample .adm file) can get lengthy and difficult to read through, especially when you have strings for long policy explanations, so developing some method for organizing strings will help you when it comes time to edit or troubleshoot your template.

The CLASS component defines whether your GPO will show up under the User Configuration node or the Computer Configuration node in the Group Policy Editor snap-in. The only valid values for CLASS are COMPUTER and USER. In the sample .adm file, the only CLASS statement (in brown text) establishes that this template's settings will apply to the User Configuration node. The CLASS value and node also correlate to the registry subkey in which changes will take place. The USER class targets settings under the HKEY_CURRENT_USER subkey; the COMPUTER class affects settings under HKEY_LOCAL_MACHINE.

The CATEGORY component lets you provide a node name under which your GPO settings will be displayed in the Group Policy Editor snap-in. The CATEGORY node name appears under the Administrative Templates node of the User Configuration or Computer Configuration node. You can nest multiple CATEGORY statements to give more structure to your settings. The first two CATEGORY statements (in purple text in the sample .adm file) establish the uppermost nodes for the WinZip settings. Three subsequent categories (in red, green, and blue text) are found under the two initial nodes. Figure 1 shows how the CATEGORY structure of the sample WinZip template appears in the Group Policy Editor snap-in. You can use the KEYNAME keyword at the CATEGORY level to provide the path to the registry subkey that will be affected by all child categories, policies, and parts unless these items explicitly define a different KEYNAME. The sample template has a KEYNAME for each CATEGORY that applies to every policy within that category. The one exception is the last policy, which required a different KEYNAME than the one specified for the category.

In the POLICY component, you configure the actual changes that the GPO will make. You can use the PART, ITEMLIST, ACTIONLIST, and other keywords to tailor the interface to suit your policy settings.

You can use the PART component to specify objects that make up the user interface for editing the GPO in the Group Policy Editor snap-in, such as text boxes, check boxes, and drop-down list boxes. You use a part-type keyword—CHECKBOX, COMBOBOX, DROPDOWNLIST, LISTBOX, EDITTEXT, TEXT, or NUMERIC—to specify the type of object to be used. The sample .adm template uses several parts. Look in the template for the part-type keywords to see how they're used, and note the results in the Group Policy Editor snap-in. For more information about using these part types, see Appendix A of the developer-oriented white paper "Implementing Registry-Based Group Policy" at http://www.microsoft.com/windows2000/techinfo/howitworks/management/rbppaper.asp.

You use the ITEMLIST component with the DROPDOWNLIST part type to provide a list of valid selections for a given setting. This method enforces the integrity of data entered into the Group Policy Editor snap-in. You can see in the sample .adm template how I used ITEMLIST with DROPDOWNLIST for the OpenLocation policy in the Paths category.

The ACTIONLIST component lets you define one or more registry subkey values according to the state of a control. For example, if you used a DROPDOWNLIST part type, you could follow up with ACTIONLIST statements to define a series of registry subkey values to alter according to which item from the drop-down list is selected.

The sample .adm template uses some additional keywords. For example, most components require an END keyword to function correctly. You'll see this keyword in statements such as END PART and END POLICY. EXPLAIN lets you provide text that describes your GPO and how to use it; the Explain tab displays the text when you edit a GPO. VALUENAME is the actual name of the registry subkey whose value you will alter via the specified GPO. You can use the DEFAULT keyword to provide default values to user-input areas of the GPO. By default, the CHECKBOX part writes a REG_DWORD value of 1 when a box is checked, but WinZip stores settings configured via check boxes as string values. The template uses the VALUEON and VALUEOFF keywords with the check box­based Wizard and ShowTips policies to interpret the check box state and write appropriately formatted registry values.

Test, Test, Test
After you've completed (or downloaded) a sample .adm file and copied it into the %systemroot%\inf folder, you can start the Group Policy Editor snap-in and load the new template to see how it works. You must be logged on to the computer with an account that has administrator privileges to use the Group Policy Editor snap-in. From the Start menu, select Run, type mmc, and click OK. From the File menu, choose Add/Remove Snap-in, then click Add. Select the Group Policy Editor snap-in and click Add. I recommend that you first try your creation as a local GPO before unleashing it on a production domain. So, for now, leave the default Local Computer selection and click Finish. Close the Add Standalone Snap-in dialog box and click OK in the Add/Remove Snap-in dialog box.

To add your new template, right-click the Administrative Templates node under either Computer Configuration or User Configuration and choose Add/Remove Templates. When you click Add, you should see a list of available .adm files. Select your new custom template and click Open. Close Add/Remove Templates and you should see new categories made available through your custom template in the Group Policy Editor snap-in. However, you might be frustrated to see that the individual settings aren't visible. Fear not, the folks at Microsoft are just trying to protect you from messing up your registry. You'll find the secret to viewing your newly created preference settings in the Group Policy Editor snap-in's Filtering dialog box. Select View, Filtering to open the dialog box, which Figure 2 shows, and uncheck the Only show policy settings that can be fully managed check box.

Of course, you should test the behavior of any Group Policy settings before you deploy them, but I encourage you to be even more stringent in your testing of settings made through custom Administrative Templates. Make sure that you understand which keys the settings alter and how they affect the application in different situations. For example, test what happens when an application user changes the settings a template has altered and what happens to the settings when a user logs off, when the system is rebooted, and when the GPO is altered or removed. The last thing you want to do is deploy a setting that cripples an application for your users and then be unable to undo that setting.

After you've verified that a GPO template lets you manage an application successfully with no side effects, you can use the template to modify a domain GPO. The process is similar to that described here except that instead of accepting the default Local Computer selection (as I advised in the first paragraph of this section), click Browse. You can then browse your domain to select the GPO that you want to edit.

When Confused, Break It Down
I've thrown a lot of components and keywords at you in a short amount of space, and you might feel a bit overwhelmed. The best advice I can give you is to start simply. Break down the application and its interface to determine the settings you want to change and add the changes one GPO at a time to your template. Don't start a new GPO until the prior one is behaving as expected. You can use a registry-monitoring tool such as Regmon (freeware from Sysinternals) to find the keys and values that you want to alter.

Group Policy is one of several ways that you can manage Windows and some Windows applications. If you're already using Group Policy to manage your client systems, you might find that leveraging custom Administrative Templates to manage formerly unmanaged applications is an effective use of this technology.

Resources

MICROSOFT "Implementing Registry-Based Group Policy" white paper http://www.microsoft.com/windows2000/techinfo/howitworks/management/rbppaper.asp Office 2000 System Policy template documentation http://www.microsoft.com/resources/documentation/office/2000/all/reskit/en-us/95ct_10.mspx Office 2000 System Policy templates http://www.microsoft.com/office/ork/2000/appndx/toolbox.htm#orktools Windows Administrative Templates http://www.microsoft.com/downloads/details.aspx?familyid=92759d4b-7112-4b6c-ad4a-bbf3802a5c9b&displaylang=en OTHER WinZip http://www.winzip.com/downwzeval.htm