group policy – Virtual Engine Ltd

24th August 2012

Move Machine Based Context Menus to Per User (Part II)

In Part I of this two part blog post, I described how you go about denying access to the machine based content menus, this blog post will describe how you now can target these same context menus to specific users or groups i.e. moving them to per user based.

Before we go on another further, you’ll need to retrieve those .REG files we modified and saved in Part I – you know the ones where we replaced HKEY_CLASSES_ROOT with HKEY_CURRENT_USER\Software\Classes.

So as you might have guessed to target the context menus are specific users or groups we simply need to inject this .REG file or its values for those users or groups. This can be achieved by various means or methods such as:

Login Scripts (BAT, VBS, PowerShell);
Group Policy custom ADM or ADMX’s;
Group Policy Preferences;
User Environment Manager (RES Workspace Manager or AppSense Environment Manager to name a couple).

I’m not going to detail how you would go about doing this for options 1 – 3 as there are numerous articles on the internet to aid with that process. What I will say is that you get a lot more flexibility using option 4 with regards to who, what and when these context menus are applied for users or groups. In most of my environments we tend to use RES Workspace Manager, so I’m going to cover what needs to be done to target the context menus at users and groups.

As a simple overview this is how I configured RES Workspace Manager to achieve this:

Create a Location and Device (PowerZone), that determines if the application is installed that these context menus are associated with;
Create a Global User Registry setting that adds the required registry keys and values by importing modified .REG, and changing the ACL to target the specific users or groups and the PowerZone created in step 1;
Create a Global User Registry settings that removes the registry keys and values set in step 2, the ACL can be set to “All Users” but more importantly the order of execution for this setting must be HIGHER than that of step 2.

Step 1

To create this PowerZone use the “File or folder exists” rule for RES Workspace Manager 2012 or “File version” rule for RES Workspace Manager 2011 and below, that will check for the installation folder or file in the directory. My example here is using RES Workspace Manager 2012 to determine if WinRAR is installed.

Step 2

This registry setting will only get applied when both the user is part of the ACL and where the application is installed on the computer they are using; why apply these settings if the application isn’t installed!. These settings are applied at a Global level to ensure they are there, should the application be required to be started from the context menu and not just when the managed application is started.

Step 3

This step is import because should the user have access revoked to the application we need to make sure that context menu is removed from the users local cached profile. Make sure the order of execution for this setting is HIGHER than that of step 2, otherwise it will remove these settings after step 2 has applied, therefore removing the context menu for users or groups that have been granted access.

That’s all there is too it – any questions just post a comment.

Enjoy!

Nathan

16th January 2012

Locating Computer GPO Registry Values

I come across this scenario all the time that requires a HKLM registry setting to be configured. Typically this can be implemented via Group Policy but, for whatever reason, you which to set the resulting registry value directly. It might be because you don’t wish to cut a new GPO just for a couple of servers or workstations. A common requirement is to set the RDS licensing server as part of an automated deployment. Maybe you use RES Automation Manager like we do. However, this scenario is not limited to just RES Automation Manager. You could use the information in this post to configure a few specific settings as part of a WDS deployment for example.

Hopefully by now you are all familiar with the free Virtual Engine Toolkit (VET). No!? Shame on you! I suggest you take a look over here and see how it can help migrate from a unmanaged user environment to a managed one.

So you now know VET is especially good at converting user related GPOs into .REG files that can be imported in your UV/UEM tool of choice i.e. RES Workspace Manager or AppSense Environment Manager. One of VET’s hidden talents (and undocumented until now) is we can also convert computer related GPO’s into .REG files.

Using the settings above as an example I’ll run you through how we achieve this with RES Automation Manager and not in a GPO. If you’ve read our series on user GPO migration then you’re aware that GPO settings (not all!) are just registry settings. The problem we normally have, is where and what should these values be set to?

You could at this point download the Microsoft Group Policy Settings Reference guide and find the individual registry keys. You could use the Group Policy Search which Kees Baggerman spotted and pointed out in this blog post Winking smile . You can spend time Googling them at which point you would have to start manually adding them to the registry task in AM. But its much, much simpler to use VET!

NOTE: the same process could be used for migrating multiple existing computer related GPOs into AM but please be aware that the computer will probably need a reboot before the targeted settings come into force.

First thing to we need to do is create a Dummy GPO where we can set the various policies we’d like included in AM. In my example I’ve called my GPO “Dummy GPO for VET” and configured the settings we’d like to apply as in our example above.
Next we need to launch VET and use the “Convert Group Policy Objects Wizard” to scan the SYSVOL folder for our newly created/existing GPO. Once VET displays the list of GPOs select the one that you wish to convert then click “Next”
.
Select “Use subfolders for User and Machine policies”. Deselect “Also create RES Workspace Manager Building Block Files” then click “Next”, “Next” and “Finish”.
Looking in the “Documents\Machine” folder you’ll find the newly created .REG File containing our settings.
Now launch the RES AM console and create a new module which contains the “Registry Settings (Apply)” task. Its then a case of importing the .REG File created previously; so you should end up with something looking like this.

It’s as simple as that! We’ve used a dummy GPO that is not applied to any computer objects, set our required settings and imported the exact resultant registry values into RES Automation Manager. You can probably think of other great use cases for this too.

You never know we might incorporate the ability for VET to generate RES Automation Manager building blocks in the future.. Hope this little gem helps someone in the future like it has me!

Nathan

27th July 2011

Using Software Restriction Policies to Block Scripts

When we are implementing RES Workspace Manager POC/Pilot’s on a customer’s site, one of the first things we try and do is create an new AD organisation unit (OU) where our test PC’s or XenApp/RDS servers will be placed. One of the reasons we do this is it allows us to block any existing AD group policies (GPOs) that might impact the POC e.g. startup/shutdown/logon/logoff scripts; especially as these might be the cause of slow logins that we are trying improve using Workspace Manager.

For computer related GPO’s we use “block inheritance” on the new OU. For user related GPO’s we employ the “GPO loopback > replace” technique.

These methods work very well but something I’ve come across on customers sites, they have set the login script in the AD properties for each user and not within any GPO that you are trying to block as you can see in the screen shot below. Generally this is the “old school” method of doing this but its still out there!

This causes us some headaches in our POC/Pilot especially when these users are asked to start testing the POC/Pilot and the first thing that happens is they start complaining that it takes an age to login. Why? Because the script is mapping 24 network drives and 15 printers at logon!!

Therefore, we need to stop this script from running on our POC/Pilot environment. We could do this by simply removing the line from their AD properties but what happens if they still want to use the existing environment that relies on this script to map drives and printers? We need to find another way of doing it…in steps “Microsoft Software Restriction Policies”.

Using Software Restriction Policies will allow us to block these logon scripts without affecting the users ability to use the existing environment and here is how.

Firstly we need to add the Software Restriction Policy to a GPO which will allow it to apply; the easiest way to achieve this would be to add it to the new GPO we have created in the first instance that applies the computer related settings.

Using the Group Policy Management Console (GPMC) edit the GPO and expand the “Computer Configuration/Windows Settings/Security Settings/Software Restriction Policies”

Right click on “Software Restriction Policies” and select “New Software Restriction Policies”.

At which point the you will see some additional settings available.

Right click on “Additional Rules” and select “New Path Rule”.

You now need to tell the policy what path to block scripts running from. Most lightly these scripts will located in the NETLOGON share on your domain controllers (DC); the problem now being which DC will the script run from should you have more than one DC in your environment. Easy we can use the %LOGONSERVER% environment variable that is used to store the logon DC used by the user who is logging on. The Security level should obviously be set to “Disallowed”.

That’s about it!! Now when you logon to the POC/Pilot environment you can be sure any unwanted logon/logoff scripts will be blocked from running.

Nathan

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!

8th October 2010

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:

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:

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…

17th September 2010

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…

13th September 2010

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…