December 2010 – Virtual Engine Ltd

6th December 2010

Migrating GPOs to RES Workspace Manager (Part 6)

Taking the Merging ADM files (Migrating GPOs to RES Workspace Manager – Part 5) blog post to the extreme, here is a demonstration of merging all the default Windows 7/2008 group policy ADMX files. By default there are 148 separate ADMX files that make up the “default” GPO settings available within the Group Policy Management Console (on Windows 7). If we needed to recreate these in RES Workspace Manager we would need 148 separate Registry Policy objects . Each Registry Policy object within the RES Workspace Management Console can only be based on a single ADMX file. Believe me, this is not pretty. Note: It’s not recommended that you do this and this example is for demonstration purposes only. Only merge the ADMX files that contain the options you need to set!

What follows is how we can create one (albeit very big) ADMX/L file that can be uploaded into RES Workspace Manager.

Open the Virtual Engine Toolkit.
Select the “Merge ADMXs” tab.
Drag’n’drop all the ADMX files in the default “C:\Windows\PolicyDefinitions\” folder (when run on a Windows Vista or later computer) into the top window.
Specify the output location directory.
Specify the output filename (the ADMX and ADML file extensions will automagically be added).
Click the green “Toolkit” button (and wait!).

On my laptop this took approximately 30 seconds and resulted in a combined 4.27MB “Win7_Defaults.ADMX/L” files. Load this into the RES Workspace Manager Management Console (it takes a little while!) and it looks like this:

Simple! And there’s more to follow…

6th December 2010

Migrating GPOs to RES Workspace Manager (Part 5)

Deploying new GPOs via RES Workspace Manager is incredibly simple. Unfortunately, as was highlighted in Migrating GPOs to RES PowerFuse (Part 1), it can be messy due to each RES Workspace Manager registry policy can only being based on a single ADM or ADMX/ADML file. A single Office GPO (if implemented via RES Workspace Manager registry policies) could look like this:

Opening the ACCESS14.ADM policy within the RES Workspace Manager Management Console only provides us with the ability to control the Access 2010 settings, e.g.

If we need to apply different settings for different users then we have to duplicate the required ADM/X policies and assign the access control as required. Over time this becomes increasingly hard to manage. With the updated Beta 2 release of the Virtual Engine Toolkit (VET) we can merge ADM files or ADMX/L files into a single file. This enables more effective use of RES Workspace Manager registry policies rather than having lots and lots individual policies. This in turn means a more simple model of administration and control. Note: it is still recommended that registry policies be applied at the application level rather than globally. The example used here is for demonstration only!

The Virtual Engine Toolkit will only extract and merge the “USER CLASS” and “[Strings]” entries within the ADM files. It does not merge the “CLASS MACHINE” entries in any way. Once you’ve downloaded the Virtual Engine Toolkit (registration is required), fire it up and navigate to the “Merge ADMs” tab.

Once you have the “Merge ADMs” tab open, perform the following:

Drag’n’drop all the required ADM files into the top box.
Select your file output location.
Specify the filename (no need to append .ADM as the Toolkit will do this for you).
Click the Toolkit button in the bottom right.

If all goes well then you should see something like this signifying that everything worked OK:

The “Merged_ADMs.adm” file can now be uploaded into RES Workspace Manager directly (it might have been better to call the merged ADM something like “Office2010.adm”!)

Now when we edit the the Merged_ADMs.adm registry policy it should look a little more intuitive! It’s a lot easier to manage settings for various groups of users when all settings are in one place. Remember that we can also do this with ADMX/L files too (in Part 6).

In the RES Workspace Manager Management Console all the settings are in one place and now look like this:

6th December 2010

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:

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

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

Launch the Virtual Engine Toolkit and select the “Convert POLs” tab.
Click the ‘…’ button to browse for the REGISTRY.POL file (next to the .POL File Location text box).
Open the ‘\\<DOMAIN FQDN>\SYSVOL\<DOMAIN FQDN>\Policies’ folder.
Select the folder that matches the GPO GUID found earlier.
Open the ‘User’ folder (this contains the User Configuration settings of the GPO).
Select the ‘REGISTRY.POL’ file.
Select an output location to save the .REG file in the ‘REG File Output Location’ text box.
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:

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:

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!

6th December 2010

Virtual Engine Toolkit BETA 2 Released

The Virtual Engine Toolkit BETA 2 (VET) has been released and can be downloaded from the web site here. This tool is free and will always be free although registration is required. At present there is currently no help available within the BETA 2 download so there will be a lot of blog posts to explain how all the features work to allow you to get you up to speed promptly.

So what does the Virtual Engine Toolkit do and what is its purpose?

The Virtual Engine Toolkit was originally developed (as the Building Block Spinner) to help automate the process of moving RES Workspace Manager Building Blocks between two domain environments. For example, you may have a development or test infrastructure that the RES Workspace Manager configurations are built/tested in and a live/production environment that is servicing your users. If our test and live databases are configured against the same Active Directory domain then they can typically be imported directly into the second environment. This scenario is covered in more detail in the Building Block Spinner (BETA 1) post.

This tool has since been extended to help with migrating and implementing Group Policy Objects within the RES Workspace Manager Management Console. The development won’t stop here so keep an eye out for future releases and future blog posts!

How can the Virtual Engine Toolkit help me?

The Virtual Engine Toolkit allows an administrator to specify different domain names for each of the two environments and select multiple Building Block files. When run it will create two sets of Building Blocks; one for the test environment and one for the live environment. Once the process is complete the Building Blocks can be loaded straight into the RES Workspace Manager Management Console. This saves you from having to perform a find and replace on each individual Building Block file which is both time consuming and error prone.

Existing Group Policy Objects (GPOs) can be converted in to .REG files for importation into RES Workspace Manager. This functionality mitigates the requirement of having to manually recreate existing GPOs within the RES Workspace Manager console.

Group Policy definition (both ADM and ADMX) files can be merged into a single file for more simple, logical management within RES Workspace Manager.

What next?

There are some additional use case scenarios for all you RES Workspace Manager consultants out there but we’ll save them for a future post. If you have any feedback, have found a bug or would like to see additional functionality put into the product then please Contact Us via the web site.