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:

  1. Login Scripts (BAT, VBS, PowerShell);
  2. Group Policy custom ADM or ADMX’s;
  3. Group Policy Preferences;
  4. 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:

  1. Create a Location and Device (PowerZone), that determines if the application is installed that these context menus are associated with;
  2. 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;
  3. 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.



Application Upgrades in RES Workspace Manager

Upgrading applications that store user personalisation settings in different places for different versions of the application can be problematic and we at Virtual Engine run into this time and time again. The most obvious example is Microsoft Office migrations but this isn’t the only example. Due to the latest upgrade cycles, the typical problem we come across is migrating from Office 2003/2007 running on Windows XP to Office 2010 running on top of Windows 7. Why is this so problematic?

Best practise within RES Workspace Manager mandates that application settings should be captured at the application level to improve logon performance etc. For example, we normally configure Microsoft Word to capture user personalisation settings behind the application like so:


In addition we probably have our applications to to be hidden (I’ll come back to this later) when they’re not detected on a machine, i.e. we won’t show the Word 2003 icon if Word 2010 is installed (and vice versa). The different application versions are installed into different paths and we don’t want both application icons appearing and confusing our users. Therefore, all the various Office applications are configured with the ‘Hide application if executable was not found‘ option.

This is fine for the individual application settings, but what about Office-wide settings, i.e. the stuff stored in ‘HKCU\Software\Microsoft\Office\Common‘ or ‘HKCU\Software\Microsoft\Office\11.0\Common‘? Normally we capture these all encompassing settings as a global User Setting, a la:


It’s all fairly straight forward thus far and so why the blog post? Well, this is where the fun starts. We have all our Office 2003 applications configured and we introduce the Office 2010 applications into Workspace Manager and configure the user personalisation capture settings as defined above, probably like this:




Are you with me so far? Good!

The first time that an Office 2010 application is run it will attempt to migrate/upgrade the existing user settings (if they exist) and write them into the Office 2010 specific locations, i.e. ‘HKCU\Software\Microsoft\Office\14.0‘. Now, think about this for a second as we have a BIG problem… We have moved the user from a v1 profile (on Windows XP) to a v2 profile (on Windows 7) which means a clean slate and no existing user settings. “WAIT,” I hear you cry, “RES WM will layer the user settings back in!”

Unfortunately, you’re wrong! RES Workspace Manager will only layer the application settings back in for an individual application if it’s detected on the system. Remember, we’ve elected to ‘Hide the application if executable was not found’ and therefore, they’re not loaded. When we start an Office 2010 application there is seemingly nothing to migrate. DOH! We’re safe with the global Office-wide settings though, as they are configured at the global level (loaded at logon) and not dependent on any application detection.

So how do we at Virtual Engine get around this little conundrum? Simple; linked user settings!

I don’t know why but this solution seems to confuse a lot of people. It’s actually an elegant solution and should be (in my humble opinion) adopted as a standard/best practice :=). Essentially we configure dummy applications that have the various user personalisation settings configured for each version of the application that we’re interested in. For example, we create a ‘Microsoft Word’ application that is hidden but will capture the user settings for all the individual Office Word versions, e.g. in our example Microsoft Word 2003 and Microsoft Word 2010 like so:





Each of the individual applications are configured as before, but their user personalisation settings are linked to our dummy Word application. Fortunately, this means that both the Word 2003 and Word 2010 settings will be layered onto the Windows 7 machine if either Microsoft Word 2003 or Microsoft Word 2010 is detected. When a user launches Word 2010, the previous settings will be available, upgraded and then captured in the same way. Here is how we now configure Microsoft Word 2003 as an example:


There is a small down-side to this approach. We’ll be collecting two sets of roughly the same settings for a short period. However, it’s a small price to pay compared to losing everyone’s settings and once the migration is complete, the user settings definition previous Word version, 2003 in our instance, can be removed from the dummy application. If you ever need to upgrade to the next version of Office you’ll also be covered with this solution. Hopefully, it’s fairly obviously that this approach can be used for application other than the Microsoft Office suite too.

We would like to hear how other people tackle this problem as well as update this post if someone has a more elegant solution/idea. Please leave your comments below and thanks for persevering.

Thanks, Iain

Internet Explorer Personalisation with RES Workspace Manager

Looking at user settings, below are some recommendations for managing Internet Explorer with RES Workspace Manager. These are not RES “best practices” but tips and tricks picked up in the field after a number of deployments.

  1. Configure IE User Settings at a global level (or as an ‘auto launched’ application) so that they get applied to the user’s session at log on. There are lots of applications that rely on these settings and if they’re loaded in the background, they may not be available when needed and cause confusion.
  2. Do not use “Zero Profile” mode User Tracking for Internet Explorer. I’ve seen lots of deployments with this enabled and it generates very large User Settings (UPR2 and UPF2) files as IE touches lots of files and registry keys when running. This will certainly result in slower log on/off times and is not required – use the built-in User Settings template.
  3. Keep user Favo(u)rites, Cookies and History User Settings separate from the IE application User Settings, i.e. define two User Settings. This is contrary to the default User Settings template supplied by RES, however, but this allows users to reset the general settings for IE without affecting the their personal Cookies, Favo(u)rites and History. image
  4. We have found that when using the default User Settings template supplied by RES it doesn’t capture any typed URL history in Internet Explorer. To resolve this issue just add the registry key : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\TypedURLs to the IE application User Settings.
  5. If you have multiple managed instances of Internet Explorer, i.e. shortcuts to URLs that point to IEXPLORE.EXE make sure you link the settings back to the “master” IE application. Creating “snapshots” of the same keys and files/folders can cause major inconsistencies to the user’s environment as RES Workspace Manager loads different settings depending on which shortcut is used.

Enjoy ! Additional comments and recommendations are more then welcome!



The case of the missing Office 2007 Quick Access Toolbars

Recently I’ve been involved with one of our customers who is migrating from RES PowerFuse 2008 and roaming profiles on XenApp to RES Workspace Manager 2011 (WM) utilising Zero Profile Technology (ZPT) and a mandatory profile.

One of the issues they had on the new environment was the Office 2007 Quick Access Toolbars (QAT) weren’t being captured by WM using the built-in templates provided which capture the locations set out below:

Windows XP and Windows Server 2003 (v1 profiles):
%USERPROFILE%\Local Settings\Application Data\Microsoft\Office

Vista, Windows 7 and Windows Server 2008 (v2 profiles):

So everything appeared to be configured correctly; but still the QAT files weren’t being captured or worse still weren’t being saved in those locations.

Upon further investigation the QAT files where actually being saved in ‘%APPDATA%\Microsoft\Office’ which seemed very odd to me as I was sure one of the problems that people found when using roaming profiles with Office 2007 was the QAT didn’t roam!. This led me into thinking that maybe Microsoft had at some point released a hotfix that did in fact allow the QAT files to roam. So lets turn to the interweb and see what that brings up, and low and behold, Microsoft did just that and released a hotfix (included in Office 2007 SP2). Setting the registry key as described in the Microsoft article forces the QAT files to be saved in the users profile which would then allow them to roam.

Once I had this vital information I quickly found that this particular customer had uncovered this fix and had implemented it using RES PowerFuse 2008 (clever boys/gals!!). Because we had copied and upgraded the RES PowerFuse 2008 datastore to WM 2011, this user registry setting was being applied to the new environment. To resolve the problem we simply removed that registry setting and let the power of the templates supplied with RES WM 2011 do their thing and capture the QAT files in the default location.

NOTE: One thing I will add about the supplied templates is they don’t capture the QAT files for Outlook 2007 i.e. Olkaddritem.qat, Olkapptitem.qat, Olkdistitem.qat, Olklogitem.qat, Olkmailitem.qat, Olkpostitem.qat and Olktaskitem.qat.

To resolve this issue you can add file filter ‘%LOCALAPPDATA%\Microsoft\Office\Olk*.qat’ to the capture settings for Outlook 2007. Hopefully this will get rolled into the default Office 2007 application templates by RES in a future release.

Hope this helps.


RES Workspace Manager and 32/64 File Paths

With deployments of x64 Windows Operating Systems (Windows 2008 R2 RDS and Windows 7) on the significant increase, you will discover over time that you need to support the same applications in the RES Workspace Manager management console but with two differing file paths. For example, Adobe Reader 9 on a 32-bit OS will typically be located in the ‘C:\Program Files\Adobe\Reader 9.0’ directory (or ‘%ProgramFiles%\Adobe\Reader 9.0’). The same application installed on a 64-bit OS will generally reside in the ‘C:\Program Files (x86)\Adobe\Reader 9.0’ directory (or ‘%ProgamFiles(x86)\Adobe\Reader 9.0’). On x64 system the ‘C:\Program Files\’ (or %ProgramFiles%) is used for native 64-bit applications. Now, if only Mickeysoft had chosen an alternative path the native 64-bit apps life would have been a whole lot easier…

Historically when deploying RES Workspace Manager on x64 Operating Systems you would have to update all your applications within the management console to reference the ‘%ProgramFiles(x86)%’ location as the installation paths are different. RES Workspace Manager attempts to fix problem this with on-the-fly redirection. That’s to say that it’ll automatically detect it’s running on a x64 OS and attempt to launch the executable in the %ProgramFiles(x86)% location instead of the defined %ProgramFiles% path. In turn this creates a problem for the 32-bit OSes as the ‘%ProgramFiles(x86)%’ system environment variable does not exist – DOH!

When I originally set out about writing this post, my understanding was slightly different from what I’ve ended up with. However, the findings are still valid so please continue to read. From the testing performed in preparation for this post with RES Workspace Manager 2011 SR2, it all appears to work correctly (shock/horror!). What I mean is, that not only does Workspace Manager appear to automatically redirect on 64-bit OSes, but also appears to attempt it on 32-bit OSes too.

The purpose of the “Disable folder redirection on 64-bit platforms” option (on a per application basis) stops RES Workspace Manager from redirecting entries defined with %ProgramFiles% to ‘C:\Program Files (x86)\’. Using Wordpad as an example, if you have the application entry defined as ‘%ProgramFiles%\Windows NT\Accessories\wordpad.exe’ Workspace Manager will automatically attempt to launch “C:\Program Files (x86)\Windows NT\Accessories\wordpad.exe” by default (the 32-bit version) on a 64-bit OS.

Checking the ‘Disable folder redirection..’ check box forces Workspace Manager to launch the actual process defined in the executable path, i.e. the 64-bit version. Obviously, this example only works if both 32-bit and 64-bit versions of the application are available. If you use Microsoft PowerPoint 2007 as an example, checking the ‘Disable folder redirection..’ option will break the 32-bit application on 64-bit OSes.

Caveat #1

The on-the-fly folder redirection only works when using system environment variables, i.e. %ProgramFiles% and/or %ProgramFiles(x86)%. If you have hard coded paths such as ‘C:\Program Files\’ or ‘C:\Program Files (x86)\’ it doesn’t work. So get updating all your applications to use these variables!

As previously mentioned, RES Workspace Manager appears to redirect on 32-bit OSes too. For example, Workspace Manager will launch an application defined with the executable path as ‘%ProgramFiles(x86)%’ successfully on a 32-bit OS even though the environment variable does not exist. I was not aware of this and can only assume that it’s a recent addition. Unfortunately this is different from what we’ve seen happening in the field and hence why we earmarked the subject for a blog post! What we have seen are applications failing to appear and/or launch correctly when updated to point to ‘%ProgramFiles(x86)%’ on 32-bit Operating Systems.

Caveat #2

Once you’ve updated all your applications with environment variables it should just work. To circumnavigate this issue we put the following simple workaround in place. Note: from the above diagnosis you should no longer have to do this.


  1. Define the %ProgramFiles(x86)% environment variable only on 32-bit machines via a Location/Device zone. Configure this environment variable to point to %ProgramFiles%. On 32-bit systems both variables will point to same location but your applications are guaranteed to work on 32-bit OSes.
  2. Ensure that you replace all file paths for managed applications with their associated environment string (I have mentioned this already haven’t I?!). If you don’t do this then you’ll need to ensure you manage the availability another way, e.g. via Workspaces or Zones.
  3. Add/configure applications in the RES Workspace Manager console on 64-bit OSes wherever possible. This will ensure that 32-bit applications always use the %ProgramFiles(x86)% variable (and not cross-platform %ProgramFiles%). If not, you need to hope that RES Workspace Manager performs it’s on-the-fly redirection magic!

Thanks, Iain

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.


RES Workspace Manager Zones and USB Devices

Have you ever had a requirement to base a Device Zone within RES Workspace Manager on a particular hardware device? If so, you may have already discovered that if is a storage based device then you’re good to go. However, if it’s not of a “removable storage” type then we’re seemingly out of luck. Not quite..

Whilst on a customer site, a requirement arose that necessitated that we detect whether a particular USB device was connected or not so that we could configure an application for the hardware device. After a lot of digging and searching, I discovered that device information is located in the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\ENUM] registry subkey(s). The problem with these registry entries is that if the device has ever been connected then it will exist and it doesn’t indicate that the device is currently connected so it’s back to the drawing board..

On further investigation, the [HKEY_LOCAL_MACHINE\System\CurrentContolSet\Services] key lists all the currently connected devices (all internal devices are listed in here so don’t be too surprised how many there are!). The difficult bit comes in determining how your USB device is enumerated. As a general rule all USB devices attached will probably be listed under keys beginning with USB. For example, the USB microphone I’m using is listed under the ..\Services\USBAudio subkey and a USB printer under the ..\Services\USBPrint subkey (more detail on hunting this information down might be a future blog post). In this instance I’m going to pick on the Samson C03U microphone and show you how can create a Device Zone in RES Workspace Manager that will allow you to set configurations options only when it’s connected. Looking in the registry in the [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Serices\USBAudio\Enum] key exposes the following settings:

I know that my microphone is identified as USB\VID_17A0&PID_0100&MI_00\6&1895ccd4&0&0000. We can see that the Samson microphone is listed in here. When the device is unplugged the instance disappears like so:

So to create our Device Zone in RES Workspace Manager for detecting the presence of a Samson microphone all we need to is create a zone based on the presence of this particular registry setting? Nearly! By creating a zone on the information from the first screenshot, it will only be true for the microphone on my desk, not any Samson C03U mike that might be on someone else’s desk. Experience has shown that everything listed after the ‘&MI_00\6&’ is device specific, i.e. a serial number or unique identifer and can safely be ignored (unless you want to tie the zone to a unique device). Therefore, if we create a Zone based on the presence of the ‘USB\VID_17A0&PID_0100&MI_00&6*’ (note the wildcard) value it should work for all Samson C03U microphones.

Done? Almost (and you knew I was going to say that!). The value of ‘0’ (zero) in the first screenshot depicts the order in which a device is attached. Therefore, if I just so happened to have another USB audio device, the Samson mike might be listed as the second device under ‘1’ or the third device under ‘2’ etc. In order to ensure that we account for this we need to add multiple entries in like so:

If I had 4 USB audio devices, then depending on the order they were attached my Zone may fail to detect that the Samson microphone was attached. I could have added 10 or so entries but hopefully you get the idea! If you have varying models of devices, then it’s likely that the PID_ (product ID) portion of the values will change. In this case, you’ll need to make sure the rules also incorporate any variations.

It would be nice to have pattern matching on the registry keys\values like we have within RES Automation Manager. Perhaps it’s an enhancement request, but in all honesty, why can’t we natively select any hardware devices attached rather than being restricted to USB storage devices already? Perhaps I’ll take this up with product management.

Good luck! Iain

RES Workspace Manager Registry Import Bug

[UPDATE 01/08/2011 – RES have released a fixpack for RES Workspace Manager 2011 SR1 that resolves the issues highlighted in this post. I don’t have any word on whether this fix will be rolled into the next Service Release of RES PowerFuse 2010 (SR5?). I hope so as we can then remove this post. In the meantime, please contact RES Software support to obtain this fix (assuming you’re running WM 2011 SR1!)]

An issue has been discovered in RES Workspace Manager 2011 and earlier versions (e.g. PowerFuse) when importing .REG files. Ironically, this was discovered when converting existing Group Policy Objects via the Virtual Engine Toolkit (VET). RES Workspace Manager does not implement the removal/deletion of registry keys or values correctly. It has been reported to RES Software and they have acknowledged there is an issue. It is not an issue with the Virtual Engine Toolkit but a problem with any .REG file, i.e. one’s migrated from log on scripts etc. [UPDATE – for clarification purposes, a support ticket had been raised prior to this post and RES are working on a fix.]

The following snippet from a REG file (some entries removed for clarity) should toggle the removal of NoInternetIcon and NoNetHood values and also toggle the removal of the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key.

Windows Registry Editor Version 5.00;
Created by the Virtual Engine Toolkit v0.9.7.0;
Creation date: 05-30-2011 17:04:08



What actually happens is RES Workspace Manager sets the two DWORD vales to 1 and doesn’t even import the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key as shown below. This results in complete unexpected behaviour and might impact any Proof of Concept or pilot deployments.

Hopefully this issue will get resolved promptly but in the meantime, please be vigil!


Finding the RES Workspace Manager Run Once GUIDS

Following on from the initial post on the Run Once Per Computer and Run Once Per Computer, Per User  GUID locations for the .ONCE files, it’s probably wise to let you know how to correlate the GUIDs used with their corresponding configuration items. There is no exposure to the GUIDs directly within the RES Workspace Manager GUI so to find these GUIDs we have to dig into the client database cache (there is a RES KB article but I can’t find it in the portal due to the search engine!).

All RES Workspace Manager agents download and cache a complete copy of the configuration database tables in the %RESPFDIR%\Data\DBCache\Objects folder as .XML files. In here are lots of files correlating to the configuration database tables within the database. The key to this process is to know what files you’re looking for! Here is a list of which files correspond to which object in the database that we’re interested in:

.XML File Object
apps.xml Applications (Notifications)
inst_mail.xml Email Templates
pl_reg.xml Registry Settings/Policies
pl_task.xml External Tasks

Armed with this information we can crack open the relevant file (pl_tasks.xml in this instance) with your favourite text/XML editor and perform a search for the “<runoncefile>” string to locate the relevant GUID.


To delete the .ONCE file for the “Per User Computer” external task, we need to delete the 132DBDF_34930_105A_TASK.ONE file from the %RESPFDIR%\Data (as it’s a related to the computer and not the user!) directory.

Note: @RESGuru has also pointed out that you can locate the relevant .ONCE files by exporting the item in question to a Building Block and then inspect the resulting .XML file. Thanks, Iain