Migrating GPOs to RES Workspace Manager (Part 4)

Here is the story thus far. In Part 1 we discussed the issues with the RES Workspace Manager implementation of ADM/X templates and whether this is a good or a bad thing. The answer is, “it depends!” Part 2 detailed the locations of the existing Group Policy Objects (GPOs) and the REGISTRY.POL files. The last post (Part 3) we explored the REGISTRY.POL file format and the available options for extracting the resulting registry settings stored within.

Hail the release of the updated/new Virtual Engine Toolkit BETA 2 (registration required)! This update now incorporates the ability to create a .REG file from the GPO REGISTRY.POL file that we can import directly into RES Workspace Manager. We lose the ability to browse the ADM/ADMX structure hierarchy and view the explanations, but we do now have the ability to import existing GPOs without having to manually transition the settings!

Note: This is still a Beta product so please be careful and test, test and test again! If you have any issues please use the contact form on the website.

To migrate a GPO you will need to know where it is located and which REGISTRY.POL file to use and to add to the confusion all GPOs have a REGISTRY.POL file. To locate the correct REGISTRY.POL to import we  first need to find the GUID of the existing GPO:

  1. Open the Group Policy Management Console.
  2. Locate and edit the GPO we wish to migrate.
  3. Right click the <GPO NAME> in the left hand pane and select Properties from the resulting context menu.
  4. The GPO’s GUID will be displayed next the Unique Name entry (highlighted below).

image

Now we have the GPO’s GUID we can locate the correct REGISTRY.POL by performing the following:

  1. Launch the Virtual Engine Toolkit and select the “Convert POLs” tab.
  2. Click the ‘…’ button to browse for the REGISTRY.POL file (next to the .POL File Location text box).
  3. Open the ‘\\<DOMAIN FQDN>\SYSVOL\<DOMAIN FQDN>\Policies’ folder.
  4. Select the folder that matches the GPO GUID found earlier.
  5. Open the ‘User’ folder (this contains the User Configuration settings of the GPO).
  6. Select the ‘REGISTRY.POL’ file.
  7. Select an output location to save the .REG file in the ‘REG File Output Location’ text box.
  8. Give the file a name in the ‘REG Output Filename’ text box (the .REG extension will be added automagically).

It might look a little like this:

image

Note: It is possible to import the Machine (Computer Configuration container) REGISTRY.POL file and there are no checks enforced to stop you doing this. Within the REGISTRY.POL file is nothing to define whether the registry settings are User or Machine based, i.e. no HKLM or HKCU differentiators. The Virtual Engine Toolkit assumes that they’re User based and adds the HKCU text to the resulting .REG file manually.

Click the green “Toolkit” icon to create the .REG file. If all is well you should see something like this:

image

Now we can create a new Registry configuration object and import our .REG file into the RES Workspace Manager Management Console. If you browse the registry settings you should see that the resulting GPO settings have been migrated, in place exactly as they where configured in the GPO!

image

Migrating GPOs to RES PowerFuse (Part 3)

So far in our ambition to migrate existing Group Policy Objects into RES PowerFuse we have detailed the shortcomings of doing so (Part 1) and discovered that all the registry settings for the User Container settings (“Administrative Templates” only) in a GPO are stored in the SYSVOL share as a REGISTRY.POL file (Part 2). Now we need to transpose the settings contained within the .POL file into a .REG file that is useable by RES PowerFuse.

Unfortunately, the .POL file format is a binary format that is not the same as the text-based .REG file format. There appears to be no easy way to view the contents of these files. The binary format is documented on the MSDN web site if you feel inclined to have a look. When we open a .POL file with notepad this is what we get:

Registry.pol

Therefore, before we can import this into RES PowerFuse we need to convert it to a text-based .REG file. After many hours scouring the internet, only a handful of solutions seem to be available.

There do appear to be some commercial registry utilities, i.e. Registry Workshop, that permit the loading/viewing of .POL files. The evaluation version of Registry Workshop does not allow exporting so it is unclear as to whether a .POL file can be exported as a .REG file that we can use with RES PowerFuse. In addition, we’re after a solution that doesn’t cost any money.

An alternative is the REGVIEW.EXE utility in the Windows 2003 Server Resource Kit. This does allow us to view the contents of the REGISTRY.POL file. Running the utility displays the contents of a .POL in text format like this:

regview_registry.pol

Unfortunately, this utility does not allow us to convert the REGISTRY.POL to a useful format, e.g. CSV. To utilise this tool we will have to redirect the output to a .TXT file, e.g. REGVIEW REGISTRY.POL > OUTPUT.TXT. Once in a plain text format we would then have to run another tool or script to convert the output to .REG. This is going to require some development time to implement.

To be continued…

Migrating GPOs to RES PowerFuse (Part 2)

In Part 1 we covered the basics of Group Policy Objects (GPOs), how they are implemented and the shortcomings of implementing Policy objects as User Registry Policies within RES PowerFuse. In our quest to work out how to migrate existing GPOs in to RES PowerFuse we’ll take a deeper dive in to how GPOs are stored and how we can get the existing settings out and allow us to import them into RES PowerFuse.

GPOs are stored within the SYSVOL share on Domain Controllers within the Active Directory infrastructure. The following information is from Group Policy Storage page from Microsoft.com.

Group Policy objects also store Group Policy information in a folder structure called the Group Policy template that is located in the System Volume folder of domain controllers (Sysvol) in the \Policies sub-folder. The Group Policy template is the container where Security Settings, Administrative Template-based policy settings, applications available for Software Installation, and script files are stored.

When you modify a GPO, the directory name given to the Group Policy template is the GUID of the GPO that you modified. For example, assume that you modified a GPO associated with a domain called Seattle. The resulting Group Policy template folder would be named as follows (the GUID is an example):

%systemroot%\sysvol\<SYSVOL>\Seattle.yourcompanyname.com\Policies\{47636445-af79-11d0-91fe-080036644603}

Registry.pol Files

All settings defined within the “Administrative Templates” section of a GPO are saved into the SYSVOL location indicated above as a REGISTRY.POL file either under the \User or \Machine subfolder depending on whether they are User-based or Machine-based policies. Here is the quote from the MS page:

The Administrative Templates snap-in extension of Group Policy saves information in the Group Policy template in Unicode files referred to as Registry.pol files; they are stored in the Group Policy template. These files contain the customized registry settings that you specify (by using the Group Policy Object Editor) to be applied to the Computer (HKEY_LOCAL_MACHINE) or User (HKEY_CURRENT_USER) portion of the registry.

Two Registry.pol files are created and stored in the Group Policy template, one for Computer Configuration, which is stored in the \Machine subdirectory, and one for User Configuration, which is stored in the \User subdirectory.

When you use the Administrative Templates extension of the Group Policy Object Editor to define customized registry settings, two Registry.pol files are created and stored in the Group Policy template. One Registry.pol file is for Computer Configuration-related registry settings and is stored in the \Machine sub-directory, and the other is for User Configuration settings and is stored in the \User sub-directory.

This means that all the User-based “Administrative Temples” settings within a GPO are stored within a single REGISTRY.POL file under the \User folder in the SYSVOL share. Therefore, if we can import the REGISTRY.POL file into RES PowerFuse we have a simple way of migrating an existing GPO, in its entirety. The custom extension information won’t be imported, e.g. software installation policies etc, but you’re probably using RES Wisdom for this anyway! There will be no need to manually import the ADM/ADMX templates and manually recreate all the individual settings for everything defined under the “Administrative Templates” section. Simples!

To be continued…

Migrating GPOs to RES PowerFuse (Part 1)

When delivering RES PowerFuse Pilots, the process that typically takes the most amount of time is the manual creation of existing user Group Policy Objects (GPOs). With a Pilot (and Proof of Concept) deployment a clean OU within AD is a mandatory requirement. This ensures that we have a safe haven to place the Pilot user accounts to ensure that they are not impacted by any existing GPOs and logon scripts. Adding RES PowerFuse on top GPOs and logon scripts is going to slow the logon process down and is contrary to what is trying to be achieved!

In an ideal situation, the Pilot customer will know which GPOs and which settings need to be applied to which user groups/OUs that are partaking in the Pilot. After the required ADM/ADMX files have been located, the required settings can slowly and painfully be transcribed into RES PowerFuse as User Registry Policies.

As a GPO is made up of one or more ADM or ADMX files, the Group Policy Management Console (GPMC) does a fantastic job of consolidating these in to a single view and a single resulting GPO. Unfortunately, RES PowerFuse doesn’t do a  great job of this. We can upload individual .ADM and .ADMX files but the result is numerous User Registry Policies for what was a single GPO. Let’s take Microsoft Office 2007 as an example. There is a separate ADM template for each Office 2007 application. In the GPMC we see these in a single view and can manipulate the settings under one Group Policy Object. With RES PowerFuse we need to upload each ADM template and create a User Registry Policy per ADM template. Now we have five User Registry Policies – one each for Word, Excel, Outlook, PowerPoint and Access rather than one. If we need to provide different settings to five groups of users we’ll need 25 User Registry Policies rather than 5 GPOs!

As an option, we can export the User Registry Policies from the RES PowerFuse management console to individual .REG files. The original User Registry Policies can be disabled and a new User Registry created. All the .REG files can be merged to create a single User Registry settings equivalent to our single GPO. However, by doing this we do lose the ability to “browse” the ADM file to turn settings on an off like within the GPMC.

The original ADM files shipped with Windows Server 2000 and Windows Server 2003 were quite large but there weren’t too many of them. With the release of Windows Server 2008 the file format changed to XML and Microsoft took the opportunity to split the large large ADM files in to many smaller ADMX files. On my test machine, I have 147 ADMX files on a basic install of Windows 2008. Now that equates to lots of User Registry Policies in the RES PowerFuse management console!

If getting the Pilot (or PoC) up and running as quickly as possible is a must, this manual process is going to add a vast quantities of time configuring the User Registry Policies. Manually transcribing the GPOs does allow for a review and consultation to be performed which is no bad thing considering there may be years of GPO bloat. What if there was a quicker method to actually getting the existing GPOs into RES PowerFuse? Would replicating existing GPOs “as is” without the review and consolidation be a good starting point? Would it be of benefit?

To be continued…