If you have ever done much work with group policies, then you have undoubtedly found out that managing group policies are an organization wide basis can be a complicated endeavor. That’s primarily due to the hierarchical nature of group policies. Group policy settings can be applied at the OU, site, domain, and local computer levels. All of these various group policy objects combine to form the effective policy.

As if combining settings for multiple group policy objects were not enough, contradictory settings can, and often do exist within the various group policy objects. Not only can two separate group policy objects contained directly contradictory settings, the group policy settings that apply to the computer can sometimes also contradict with group policy settings applied to a user.

Windows has all kinds of rules for automatically dealing with contradictory group policy settings. Even so, you as an administrator need to know the outcome of these conflict resolutions and what the effective policy look like once the various policy elements have been combined. In Windows Server 2003 this was known as the resultant set of policy. In Windows Server 2008, Microsoft has changed the name to group policy modeling.

Why Do Group Policy Modeling?

There are several different reasons why you might want to engage in group policy modeling. For starters, even if everything appears to be running smoothly is a good idea to periodically use group policy modeling just to make sure that group policies are being applied in the way that you think that they are. Group policy modeling is also extremely useful in situations in which you are reorganizing the Active Directory or creating new group policy objects.

Performing Group Policy Modeling

To perform group policy modeling begin by opening the Group Policy Management Console. When the console opens, right-click on the Group Policy Modeling container and choose the Group Policy Modeling Wizard command from the shortcut menu. When you do, Windows will launch the Group Policy Modeling Wizard.

Click Next to bypass the wizard’s welcome screen, and you will be taken to the Domain Controller Selection screen, shown in Figure A. As you can see in the figure, the screen asks you to choose the domain that you want to analyze, and then asks you to either choose a domain controller or specify that any domain controller can be used.

Figure A You must specify the domain that you want to analyze.

Click Next, and you will be taken to a screen that asks which user and/or computer you want to simulate the policy settings for. In both cases, you can either specify a particular container or an individual user and/or computer. That way, you can either evaluate a specific user and/or computer, or you can about your weight all of the users and/or computers within a particular container. You can see what this screen looks like in Figure B.

Figure B This is where you specify the Active Directory objects that you want to evaluate.

Click Next, and you will be taken to a page that gives you the chance to select a particular site. If you do not have any non-default sites defined, then you can just skip this page by clicking Next.

The next page that you will see allows you to enter alternate network location for a user and computer containers. The basic idea behind this screen is that it allows you to perform various what if scenarios. For example, you can see what would happen to the group policy settings if you were to move the computer in question to a different Active Directory container. Of course you do not have to specify an alternate location unless there is a particular location that you need to test.

When you click Next, you will see a screen listing all of the security groups that the currently selected user is a member of. You have the option of simulating changes to the users group membership if you want. When you’re done entering any desired changes, click Next. You will now be given the chance to entering WMI filters that you want to use. Add any desired filters, and click Next.

You should now see a summary screen listing the options that you have specified. Make sure that everything looks okay, and then click Next, followed by Finish. When you do, Windows will display a screen similar to the one that is shown in Figure C. This screen allows you to see the outcome of your proposed configuration.

Figure C Your proposed changes are displayed in the Group Policy Management Console.

Conclusion

In this article, I have explained that it is sometimes difficult to evaluate the outcome of changes to the group policy. I then went on to show you how to use group policy modeling as a way of testing your proposed changes before you actually implement them.

source:
http://www.petri.co.il/group-policy-object-modeling-windows-server-2008.htm

One of the issues that sometimes made managing group policies difficult in Windows XP and in Windows Server 2003 was the non centralized nature of the group policy template files. For example, Microsoft offers downloadable templates that allow you to manage Microsoft Office via group policy. Even so, these templates are not automatically available from every domain controller.

In Windows Vista and Windows Server 2008, Microsoft decided to make life easier for network administrators by introducing the concept of centralized group policy storage. This storage repository, known as a central store, can be created in domains containing Windows Server 2003 and / or Windows Server 2008 domain controllers. Even though Windows Server 2003 does not technically support centralized group policy storage, Windows Vista does, and this allows you to store the central store on Windows Server 2003 domain controllers if necessary, but manage the central store through Windows Vista.

How Does a Central Store Work?

As you may have gathered from the previous paragraph, there is really nothing special about the central store itself. It is nothing more than a folder on a server. The reason why a central store can work the way that it does is because of the way that the store is used by Windows Vista and Windows Server 2008.

When an administrator attempts to create or edit a group policy template, Windows checks the domain controller to which it is connected for the existence of a central store. If a central store exists, then Windows will use that central store by default. Otherwise, local copies of the template files are used.

Creating a Central Store

Creating a central store is actually a rather simple process. The first thing that you will have to do is to log onto a computer that is running either Windows Vista or Windows Server 2008. If you have one particular machine that has all of your group policy template files installed on it, then that machine is a good candidate.

The next thing that you must do is to open Windows Explorer, and then go into the C:\Windows folder. Locate the PolicyDefinitions folder, right click on it, and then choose the Copy command from the shortcut menu. This will copy the folder and its contents to the Windows clipboard.

The next step in the process is to map a network drive letter to the sysvol folder on a domain controller. The full path that you will need to access on the domain controller is c:\Windows\SYSVOL\domain\Policies. Finally, copy the PolicyDefinitions folder to the \Windows\SYSVOL\domain\Policies folder on the domain controller. You can see what this looks like in Figure A.

Figure A Copy the PolicyDefinitions folder to the domain controller’s \Windows\Sysvol\Domain\Policies folder.

Testing Your Central Store

In order to gain the maximum benefit from the central store that you have created, I recommend that you periodically run tests to make sure that the central store is actually being used. Fortunately, testing a your central store is even easier to do than creating the central store was. To do so, open the Group Policy Management console. Now, navigate through the console tree to Forest | Domains | your domain | Group Policy Objects | Default Domain Controller Policy. Upon selecting this policy container, the pane on the right side of the console should display a series of tabs. Go to the Settings tab, and look at the Administrative Templates section. It should confirm that the policy definitions (the ADMX files) have been retrieved from the central store.

One thing that you must keep in mind about this technique is that you may occasionally run into situations in which the Settings tab for a particular group policy template does not even contain an Administrative Templates section, let alone tell you that the template was retrieved from the central store. The reason why this occasionally happens is that the Administrative Templates section is only displayed if the group policy object contains at least one setting.

Conclusion

As you can imagine, keeping group policy templates in a central location can be a significant management issue for companies. However, Windows Server 2008’s (and Windows Vista’s) ability to create a central store greatly simplified the process of keeping track of the various group policy objects that are in use within your company.

source:
http://www.petri.co.il/creating-group-policy-central-store.htm

Introduction

Not too long ago I got a call from a friend who was having some problems related to group policy objects on his network. My friend made a habit of backing up his domain controllers on a regular basis. Even so, someone in the organization have made some changes to some group policy objects, and my friend needed to return them to their previous state. The catch was that he didn’t want to have to perform an authoritative restoration of the entire Active Directory just to recover a few group policy settings.

Fortunately, there is a way that you can backup your group policy settings separately from the rest of the Active Directory. Of course you have to do this before the need to restore your group policy settings arises.

Backing Up the Group Policy Objects

Begin the process by logging on to a Windows Server 2008 domain controller, and opening the Group Policy Management console. Now, navigate through the console tree to Group Policy Management | Forest: | Domains | | Group Policy Objects. When you do, the details pane should display all of the group policy objects that are associated with the domain. In Figure A there are only two group policy objects, but in a production environment you may have many more.

Figure A

The Group Policy Objects container stores all of the group policy objects for the domain.

Now, right-click on the Group Policy Objects container, and choose the Back Up All command from the shortcut menu. When you do, Windows will open the Back Up Group Policy Object dialog box. As you can see in Figure B, this dialog box requires you to provide the path to which you want to store the backup files. You can either store the backups in a dedicated folder on a local drive, or you can place them in a folder on a mapped network drive. The dialog box also contains a Description field that you can use to provide a description of the backup that you are creating.

Figure B

You must provide the path to which you want to store your backup of the group policy objects.

To initiate the backup process, just click the Back Up button. When the backup process completes, you should see a dialog box that tells you how many group policy objects were successfully backed up. Click OK to close the dialog box, and you’re all done.

Backing Up Individual Group Policy Objects

In case you’re wondering, Windows Server 2008 does allow you to backup individual group policy objects. The process for doing so is very similar to what I just showed you. The difference is that when you select the Group Policy Objects container, shown in Figure A, you would right-click on an individual Group Policy Object rather than on the Group Policy Objects container. From there, you would choose the Back Up command from the shortcut menu. The rest of the process is identical to what you have already seen.

The Anatomy Of The Back Up

When you create a backup, Windows creates individual folders within the target folder. Each of these individual folders bears the GUID of the Group Policy Object that contains. This is true whether you are backing up an individual Group Policy Object, or all of the Group Policy Objects in the entire domain. You can see what the backup folder looks like in Figure C.

Figure C

Windows creates a separate folder for each Group Policy Object.

The Restoration Process

When it comes to restoring a backup of any Group Policy Object, you have two options. The first option is to right-click on the Group Policy Object, and choose the Restore From Backup command from the shortcut menu. When you do this, Windows will remove all of the individual settings from the Group Policy Object, and then implement the settings found in the backup.

Your other option is to right-click on the Group Policy Object you want to restore, and choose the Import Settings option. This option works more like a merge than a restore. Any settings that presently reside within the Group Policy Object are retained unless there is a contradictory settings within the file that is being imported.

Conclusion

As you can see, it is pretty simple to backup your Group Policy Objects. Even so, a lot of administrators do not realize the importance of backing up group policy objects separate from backing up the Active Directory.

source:
http://www.petri.co.il/backing-up-group-policy-objects.htm

Group Policy is a powerful yet complex technology. It is used, to some extent, in almost every environment. And for many who rely on it heavily to secure and lock down their Windows environment, Group Policy is a key part of their infrastructure.

That said, I am always surprised to see how little automation is used for Group Policy management in many IT organizations. When the Group Policy Management Console (GPMC) shipped, Microsoft made a set of APIs and sample scripts available for automating tasks that were performed with that console. There is much that can be done using these APIs, as well as opportunities to automate other aspects of Group Policy management, such as troubleshooting and diagnostic tasks. And, with the advent of Windows PowerShell, some of these tasks have become easier.

Thorbjörn Sjövold discussed using Windows PowerShell for getting at some of the GPMC APIs in his article “Simplify Group Policy Administration with Windows PowerShell.” In this article, I want to build on that foundation with some additional automation techniques you can use to further automate management of your Group Policy environment.

What Does GPMC Offer?

The GPMC is focused on operating against the whole Group Policy Object (GPO), and its associated permissions, links, and so on. It does not provide automation or management of the actual settings within the GPO. However, it can be useful to perform automation against the whole GPO as a way of managing the change process within your Group Policy environment. For example, you can use the GPMC APIs to modify links to GPOs. If you have a new GPO that you want to deploy, you can script the creation of the GPO and then you can script the linking process after its settings have been populated. You can also script the changing of a GPO’s permissions, in case you want to modify which security groups are targeted by a GPO or who can edit that GPO.

And of course, you can always use the APIs to query information about GPOs, as opposed to just making changes. This includes generating HTML- and XML-based reports for GPO settings as well as Resultant Set of Policy (RSoP) reports against remote workstations and servers to determine if Group Policy was successfully applied.

It’s also worth mentioning that when Microsoft released the updated GPMC that shipped with Windows Vista SP1 and Windows Server 2008, there were some updates to the APIs in order to support some of the new features that GPMC and Group Policy in general support. These include the ability to create new GPOs from “Starter GPOs” and to add comments to a GPO. Starter GPOs are like templates—they let you create a set of Administrative Template policy settings that you can then apply to a new GPO, pre-populating some of its settings. I want to start by looking at how you can automate the process of creating, permissioning, and linking a GPO and then show how you can leverage some of these new GPMC features in this automation.

Automating the GPO Lifecycle

To demonstrate how you can automate creating and managing GPOs, I am going to use Windows PowerShell and the GPMC APIs. In my example, I am creating a GPO called “TechNet Marketing Policy.” When I create the GPO, I’m going to use a Starter GPO called “User Lockdown Template” as the starting point and add a comment indicating that I created the GPO. I could create the Starter GPO using GPMC APIs, but in this example, I’m going to assume it already exists.

The next step that I want to automate is the permissioning of the GPO. I’m going to permission the GPO so that only users within the “Marketing Users” group will process the policy, and I will add a group called the “GPO Admins” with the permissions to edit the GPO. Finally, I am going to link the GPO to the Marketing OU in my Active Directory domain.

The entire Windows PowerShell script, which I’ve called gpoCreate.ps1, is shown in Figure 1. I’ve added the line numbers simply for reference.

Figure 1 The Windows PowerShell gpoCreate.ps1 scriptt

Line 1 is required to get started using the GPMC APIs. You will use this in any GPMC script you write. This line creates an instance of the base GPMC object and assigns it to the $gpmc variable. Line 2 is another commonly used command. The GPMC provides a set of handy constants that are used across the spectrum of tasks to indicate a particular state. You’ll see how I use it later in the script, but for now, I’ll just assign the constants to the $constants variable.

In Line 3, I need to get a reference to the Active Directory domain that I’ll be operating on. In my example, that is a domain called cpandl.com. To do that, I call the GetDomain method on the $gpmc variable. The two $null parameters are optional and allow you to specify a particular domain controller to connect to when you connect to the domain. By leaving these null, I’m essentially choosing the default, which is the PDC emulator DC.

In Line 4, I need to get a reference to my Starter GPO (User Lockdown Template). The GetStarterGPO method only supports calling the Starter GPO by its GUID, so I have to go into the GPMC console to look for that. (I could have scripted it also.) That’s the GUID I’m passing to the GetStarterGPO method.

In Line 5, once I have my Starter GPO reference, I use it to create the new GPO, using the CreateGPOfromStarterGPO method that is available on the $domain variable. I assign the newly created GPO to $gpo so I can continue to use it. Note that at this point, the GPO has no name (well, it has the default name of “New Group Policy Object”). So in Line 6, I modify the displayName property on $gpo to give it a new name. Line 7 is where I add a comment to the GPO, by setting the description property on $gpo.

Now that I’ve got my GPO created, the next set of tasks is to modify the permissions on the GPO. In Line 8, I start off by getting the current list of permissions on my newly created GPO, using the GetSecurityInfo method on the GPO. The approach for modifying permissions on a GPO is to get the list of current permissions on the GPO, add and delete entries from that list as needed, and then re-apply the list to the GPO. To that end, in Line 9, I remove the Authenticated Users default permission from the newly created GPO.

In Lines 10 and 11, I create the two new permissions that I want to add to the GPO. I create those using the $gpmc CreatePermission method, supplying the Trustee (user group) name and the permission that I want the group to have. Note that I’m using the $constants variable to define the permission. The $constants.permGPOApply property grants the “Read and Apply Group Policy” permissions that allow members of a group to process a GPO, while the permGPOEdit property grants the ability for that group to Edit a GPO. The $false parameter at the end of the CreatePermission method call simply says that the permission should not be inherited, which is the default for GPO permissions.

Once the two permissions are created, Lines 12 and 13 add them back to the $permissions list and Line 14 calls the SetSecurityInfo method on the GPO to apply the new list back to the GPO.

The final two lines link the GPO to the Marketing OU. In Line 15, I call the GetSOM method (SOM stands for “scope of management”) on the $domain variable to “connect” to the OU. In Line 16, I call CreateGPOLink on the $som object I just created and pass it two parameters. The first parameter indicates the order on the OU that I want the GPO to be linked (an OU can have multiple GPOs linked to it). The “1″ stated for the first parameter indicates that I want the GPO to be linked first in the list. The second parameter (in this case, the $gpo variable) is the reference to the GPO I want to link. And now I’ve successfully created, permissioned, and linked a GPO using automation. The result is shown in Figure 2.

Figure 2 Viewing the Newly Created GPO

Automating Group Policy Reporting

Another aspect of Group Policy management you can automate is the reporting. In this respect, there are at least two types of reports that GPMC delivers. The first is the ability to report on the settings within a GPO. This allows you to generate either an HTML- or XML-based report of the settings that are currently enabled in the GPO, as shown in Figure 3.

Figure 3 Reporting on GPO Settings

The second reporting capability lets you generate Resultant Set of Policy (RSoP) or Group Policy Results reports. There are two types of RSoP reports—logging and planning. A logging report is run against a remote desktop or server, indicating what policies were delivered to that remote system and whether they were successful. The RSoP planning report lets you perform what-if analysis against a particular OU, computer, or user to determine what policies will apply. In both cases—logging and planning—you can generate HTML or XML output using the GPMC APIs and Windows PowerShell.

Generating an HTML-Based Report

To generate a GPO settings report in Windows PowerShell, I start off with two familiar initialization commands, which I used in the previous script:

1. $gpmc = New-Object -ComObject GPMgmt.GPM
2. $constants = $gpmc.GetConstants()

Next, I need to get a reference to the GPO that I want to report on, like so:

3. $domain = $gpmc.GetDomain(“cpandl.com”,$null,$null)
4. $gpo = domain.GetGPO(“{31B2F340-016D-11D2-945F-00C04FB984F9}”)

In Line 3 here, I am again connecting to the domain and then in Line 4, I use the GetGPO method on the domain to get a reference to the GPO I want to report on. In this case, I have to pass the GUID of the GPO, which happens to be the “Default Domain Policy.”
Next, I need to generate the settings report:

5. $gpo.GenerateReportToFile($constants.ReportHTML,”c:\GPReports\DDPSettings.html”)

Here, I am calling the GenerateReportToFile method on the GPO to create the settings report. The first parameter uses the $constants variable to specify an HTML report type. The second parameter points to the path where I want to save the report.

Generating an XML-Based Report

Another way to access the settings data using Windows PowerShell is to take advantage of the built-in XML parsing capabilities in Windows PowerShell and its ability to generate a settings report in XML. So, instead of Line 5 above, I change that to the following:

[xml]$report = ($gpo.GenerateReport($constants.ReportXML)).Result

In this example, I’m using a different method on the GPO, called GenerateReport. This method takes a single parameter, which is the report type. But in this case, I am assigning the output of the method call to a variable called $report and I am preceding that variable name with the Windows PowerShell type accelerator [xml], which tells PowerShell to take the output of the command that I am storing in $report and convert it to an XML document instead of just a bunch of text. However, in order to get the actual XML from GenerateReport, I have to use the Result property on that output, which is what you see at the end of that statement. So the Result property holds the actual XML that I am using to generate my XML document.

Once I have the XML in the $report variable, I can do lots of interesting things with it. For example, consider the following command:

$report.GPO

This returns the “GPO” element within the document that provides overview information about the GPO I am reporting on. Or this command:

$report.GPO.LinksTo

This returns a list of all of the places that this GPO has been linked.

But more interestingly, I can use the structured nature of XML to investigate the actual settings within the GPO from the command-line. For example, since this is the Default Domain Policy GPO, I know it probably contains some security settings related to password policy. By navigating the GPO namespace as represented in the XML file, I can quickly get to those settings, as follows:

$report.GPO.Computer

This returns information about the Computer side of the GPO. If I view the properties on this Computer property, I notice a collection of policy areas under the ExtensionData property, as shown in Figure 4.

Figure 4 Viewing GPO Settings Through XML

In this example, there are two extension areas within the computer side of this GPO: registry and security. So I issue the following command:

$report.GPO.Computer.ExtensionData[0].Extension

This gives me a list of policy areas implemented under the Security policy section. I see two properties called Account and Security Options. Now I enter the following command:

$report.GPO.Computer.ExtensionData[0].Extension.Account

This gives me a list of each of the Account Policy settings for this GPO, as shown in Figure 5.

Figure 5 Viewing Account Policy Settings Within the GPO

Notice that some of the settings do not actually show the value in Figure 5. Each setting is returned as a member of a collection under the Account property. So in order to see, for example, the Minimum Password Length setting, I need to index into the collection, like so:

$report.GPO.Computer.ExtensionData[0].Extension.Account[4]

Once you get the hang of navigating the XML namespace for GPO settings, you can easily get to particular settings and use this capability in conjunction with Windows PowerShell to locate the values of settings within a GPO quite quickly.

Reporting on RSoP logging

Just as with GPO settings, you can generate an XML- or HTML-based report in Windows PowerShell that shows the Group Policy settings that have been applied to a given machine. The approach is a little different, though. Starting again with the two initialization commands, I take the script in a slightly different direction:

1. $gpmc = New-Object -ComObject GPMgmt.GPM
2. $constants = $gpmc.GetConstants()
3. $rsop = $gpmc.GetRSOP($constants.RSOPModeLogging,$null,0)
4. $rsop.LoggingComputer = “xp2″
5. $rsop.LoggingUser = “cpandl\dpmtest”
6. $rsop.CreateQueryResults()
7. $rsop.GenerateReportToFile($constants.ReportHTML,”c:\gpreports\XP2Rsop.html”)

After Lines 1 and 2 set up the process, Line 3 creates the $rsop variable by calling the GetRSOP method on $gpmc. In that method call, I indicate that I want to create an RSOP logging and not a planning report. Lines 4 and 5 set properties on that $rsop object to tell it what computer and user I want to collect RSOP data against. Then, the sole purpose of Line 6 is to connect to the computer specified in line 5 and generate the RSoP namespace for this query. Finally, in Line 7, I output the results of the query to an HTML file.
Note that the RSoP object also has a GenerateReport method similar to the GPO settings example. And you can output the RSOP report to an XML document and navigate through it in Windows PowerShell to find out what’s happening from a Group Policy perspective on that remote client. For example, say I want to quickly find out if Group Policy processing succeeded for the Computer side of GPO processing. I can use the previous script, but replace Line 7 with this:

[xml]$rsopReport =
($rsop.GenerateReport($constants.ReportXML)).Result

This puts my RSoP report into an XML document.
Next, I can navigate into the XML name-space to find out the Client-Side Extension (CSE) status for the computer as follows:

$rsopReport.Rsop.ComputerResults.ExtensionStatus

When I do that, I get a listing that shows me the status on each CSE that was processed by the computer!

An Easier Way

As I’ve shown so far, there is a lot of powerin leveraging the GPMC APIs to automate Group Policy lifecycle, reporting, and diagnostic tasks. But it does take quite a few steps to get to the desired result. However, there is somerelief and even more coming in the future.

I’ve created a set of 25 free GPMC Windows PowerShell cmdlets that wrap most of the common GPMC functions into easy-to-use cmdlets. You can download these GPMC cmdlets at www.sdmsoftware.com/freeware. To give you an example of the simplified process, from our first example of creating and then permissioning and linking a GPO, the following script using my GPMC cmdlets would accomplish the same tasks as the script I presented earlier, but with fewer commands:

$gpo = New-SDMgpo “Technet Marketing Policy”
-FromStarterGPO “User Lockdown Template” –native
$gpo.Description =
“Darren’s Technet Demo GPO” Remove-SDMgpoSecurity
$gpo.DisplayName -Trustee “Authenticated Users” –PermApply
Add-SDMgpoSecurity $gpo.DisplayName
-Trustee “Marketing Users” –PermApply
Add-SDMgpoSecurity $gpo.DisplayName
-Trustee “GPO Admins” –PermEdit
Add-SDMgplink “Technet Marketing Policy”
-Scope “OU=Marketing,DC=cpandl,DC=com” -Location 1

Even better, Windows 7 and Windows Server 2008 R2 will provide built-in Windows PowerShell cmdlets for GPMC. For example, to create my example GPO from a Starter GPO with a comment, I can issue one Windows PowerShell command, as follows:

new-gpo “Darren’s Technet Policy” -starterGPOName
“User Lockdown Template” -Comment “Darren’s Demo”

Microsoft is also adding support for reading and writing a subset of Group Policy settings. Specifically, there will be support for reading and writing registry settings into either native Administrative Template policy or the newer Group Policy Preferences registry extension. For example, to write a new registry value into Group Policy Preferences, I would issue the following command :

Set-GPPrefRegistryValue “Darren’s Technet Policy”
-key ‘HKEY_LOCAL_MACHINE\Software\SDM Software’
-ValueName “Path” -Value “2″ -Type String
-Context Computer -Action Update

Here, the set-GPPrefRegistryValue cmdlet takes a number of parameters to create a registry policy setting within my “Darren’s Technet Policy” GPO for the registry value HKEY_LOCAL_MACHINE\Software\SDM Software\Path= REG_SZ 2. The Context parameter tells the policy whether it should be put under the Computer or User side of the GPO, and the Action parameter specifies how to apply the registry value and corresponds to the options within the GPP UI (other options include Replace, Create and Delete).
As of the time of writing this article, Windows 7 and Windows Server 2008 R2 are planned to ship with 25 cmdlets for managing Group Policy. Once these are available, managing Group Policy through Windows PowerShell will be much easier.

source:
http://technet.microsoft.com/en-us/magazine/2009.06.gpmanagement.aspx

What are Administrative Template in Group Policy Objects?

In Windows 2000 and Windows Server 2003 Group Policy Objects (also known as GPO) you may find hundreds of useful settings and configuration options, all nicely divided in to specific sections. With GPO, you can create policies to centralize the management of user and computer settings. Amongst the various settings that can be accomplished via GPO, you can find the following options:

* Manage desktop environments and lock them down to reduce support calls and TCO (Total Cost of Ownership)
* Install, update, repair, and remove software
* Manage security settings including account policies, auditing, EFS, and user rights
* Control running state of services
* Redirect My Documents folders
* Configure Internet Explorer options and security settings
* Automate administrative tasks using log-on, log-off, startup and shutdown scripts

and many many more.

These sections can be clearly seen in the following screenshot:

Note that the GPO settings is divided between the Computer settings and the User settings. In both parts of the GPO you can clearly see a large section called Administrative Templates.

Administrative Templates are a large repository of registry-based changes (in fact, over 1300 individual settings) that can be found in any GPO on Windows 2000, Windows XP, and Windows Server 2003.

By using the Administrative Template sections of the GPO you can deploy modifications to machine (called HKEY_LOCAL_MACHINE in the registry) and user (called HKEY_CURRENT_USER in the registry) portions of the Registry of computers that are influenced by the GPO.

The Administrative Templates are Unicode-formatted text files with the extension .ADM and are used to create the Administrative Templates portion of the user interface for the GPO Editor.

Windows 2000/XP/2003 has some built-in default Administrative Templates:

These .ADM files are located in the %SystemRoot%\inf folder, and are copied to the SYSVOL folder whenever you create a new GPO (unless to manually configure it not to do so. See Links section on an explanation on how to do this).

On top of these templates, Windows 2000/XP/2003 also has other .ADM files that can be used in several scenarios:

However there may be times when an administrator will need to add more options to a new or existing GPO. Some examples of such additions are:

* Settings to disable mobile storage devices (USB, MP3 players, cameras and so on)
* Settings to control the functionality of specific Windows features
* Settings to control behavior of specific Windows services or drivers
* Settings that add or change registry keys
* Changes to the Windows security model

One method for an administrator to control such settings is by use of logon scripts and remote registry tweaks. This process requires knowledge of scripting languages, but is highly customizable and flexible, and is not restricted to GPO limitations (i.e. not working on pre-W2K computers). However we will not cover this method in this article.

Another method for an administrator to add such extensions to the GPO is by adding new settings to the Administrative Templates sections. This can be done by adding .ADM files to the existing Administrative Templates section in GPO.

In order to add additional .ADM files to the existing Administrative Templates section in GPO please follow the steps outlined in the Adding New Administrative Templates to a GPO article.

A great example of new .ADM files that can and should be used on a network is the set of Administrative Templates extension files that is a part of the Office 2000/XP/2003 Resource Kit. When installing the Resource Kit for the respective Office version, new .ADM files are copied to the %SystemRoot%\inf folder of the machine on which the Resource Kit was installed. The moment you edit an Active Directory-based GPO on that machine (the machine can be either a Windows 2000/XP Pro machine, or a server-based machine) the used .ADM file(s) will be copied to the SYSVOL folder on the target DC (typically the PDC Emulator), and from there replicated throughout the domain.

The following screenshot shows the new .ADM files while importing one of them to a GPO:

source:
http://www.petri.co.il/understanding_administrative_templates_in_gpo.htm

Introduction

There are numerous companies out there that have developed custom ADM templates to handle their hard to reach Registry settings. These custom ADM templates were necessary because Microsoft did not, and could not, include all Registry settings in the default Group Policy Object (GPO) settings. These ADM templates have been around for a long time and now that Windows Server 2008, Vista, and 7 do not use ADM templates, I often get questions asking me what will happen with the custom ADM templates. In this article I will briefly describe what an ADM template does, then describe how you will move forward with these custom templates in your new Windows Server 2008/Vista/7 environment.

What Does a Custom ADM Template do?

An ADM template is a file that is designed to be used within Group Policy to define a Registry setting and its’ value. There are 5 default ADM templates that come with Windows Server 2003 and XP, but these files can only handle so many Registry settings. If you want to have more Registry settings available in your GPO, then you have an option of creating a custom ADM template.

A custom ADM template (or a standard one for that matter) is responsible for doing two things. First, it is responsible for defining what will be changed in the Registry. We are all familiar with the Registry by now, I hope! The Registry is broken down into two parts for what ADM templates are concerned: HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER (HKCU).

The ADM template will define the path in the Registry, the value within that path, and the data (or set value) that the value can and will be set to.

The custom ADM template also establishes the folder(s) and policy within the GPO. If the Registry value falls under HKLM, then the policy will be located under Computer Configuration\Policies\Administrative Templates and if the value falls under HKCU the policy will be located under User Configuration\Administrative Templates when you edit the GPO to find the setting. Figure 1 illustrates that a custom ADM template entry might look like.

Figure 1: Custom ADM template entry in the GPO editor

Note:
If you are looking at a GPO on Windows Server 2008/Vista/7, then you will also have a Policies folder before the Administrative Templates folder in the GPO editor.
How do you Include Custom ADM Templates in Windows Server 2003/XP and before?

When a custom ADM template was added to a GPO in the past, the ADM template was added through the GPO editor. Because ADM templates only control the Administrative Templates portion of the GPO, this is where you go to add in any custom ADM templates.

In order to add a custom ADM template, you right-click on the Administrative Templates node (you can select either the one under Computer Configuration or User Configuration, it does not matter for the importing of the ADM template), then select the Add/Remove Template option, as shown in Figure 2.

Figure 2: Adding Custom ADM templates to a GPO

If there are no errors in the custom ADM template syntax, the new setting will just appear in the editor. If there are errors, and there will typically be an error message that will not allow the file to be imported until the error is corrected.

Where are Custom ADM Templates Stored?

ADM templates are all stored with the GPO settings on the domain controllers. The location for these files is in the default path of c:\Windows\Sysvol\sysvol\\Policies\\ADMs. Here, you will find the default 5 ADM templates, as well as any custom ADM templates that you have imported into the GPO.

Note:
Custom ADM templates are associated with only the GPO that imported it. If you want an ADM template to be available for multiple GPOs, you must import it into each GPO individually, thus creating multiple copies of the ADM file in each GPOs storage folder in sysvol.
Windows Server 2008/Vista/7 and Administrative Templates

Microsoft made a radical change from ADM templates to ADMX/ADML files when they released Windows Vista and Windows Server 2008. There are no ADM templates on either of these operating systems. The role of the ADMX/ADML is identical to that of the ADM template, it is just that each responsibility of the ADM template is now broken such that the ADMX file is responsible for one task, where the ADML file is responsible for the other.

ADMX files are responsible for defining the Registry portion of the GPO setting. These files are not language specific, in that they come in English only.

ADML files are language files and are responsible for creating the folder and policy structure in the GPO editor. This allows for many languages to be supported, where ADM templates only supported English.

Be default, ADMX/ADML files are obtained from the local computer where the GPO is being administered. If you create a central store, http://www.windowsecurity.com/articles/Managing-Windows-Vista-Group-Policy-Part1.html , then you have all Windows Server 2008/Vista/7 computers using a single version of the ADMX/ADML files.

Note:
Be sure to update the central store with Windows 7 or Windows Server 2008 R2 ADMX/ADML files once you get one of these operating systems on your network. There are changes to the files that you will want all computers taking advantage of.
Having Custom ADM Templates with Windows Server 2008/Vista/7

Since Windows Server 2008/Vista/7 do not use ADM templates, what would happen when you try to mix custom ADM templates and ADMX/ADML files? The answer is very simple!

The ADMX/ADML files will generate the default GPO settings that fall under Administrative Templates. The custom ADM templates that reside in the ADMs folder under the GPOs sysvol location will show up under the Classic Administrative Templates (ADM) folder, which is located under the Administrative Templates nodes in the GPO editor. You can see an example of this in Figure 3.

Figure 3: You can clearly see custom ADM templates show up under Classic Administrative Templates (ADM) in the editor

Summary

There has been a change from ADM templates to ADMX/ADML files in Windows Server 2008/Vista/7. This change could have an impact on your custom ADM templates, if you are not aware of the overall big picture of the changes. Keep in mind that ADM templates are no longer used, but are instead replaced by ADMX/ADML files in the creation of the Administrative Templates nodes in the GPO editor, as well as the definition of the Registry entry that will be altered. Custom ADM templates are stored in the GUID folder of the GPO that they are associated with, regardless of the version of the OS that is performing the administration of the GPO. It is this structure and the ability of the newer OSs that provide the cohabitation of the newer files along with the custom ADM templates. Just keep in mind that the custom ADM template settings will show up under the Classic Administrative Templates (ADM) folder.

source:
http://www.windowsnetworking.com/articles_tutorials/Using-Custom-ADM-Templates-Windows-Server-2008-Vista-7.html