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.



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

WARNING! This post requires you to edit the registry. Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Virtual Engine cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you begin. If this hasn’t scared you off keep reading….

imageIn my time installing and configuring applications for multi user environments like XenApp or RDS, I come across many applications that will create context menus within Windows explorer that can help a user quickly perform a function. The screen shot below shows how WINRAR has added context menus in Windows explorer that allows the user to easily create a .RAR file having selected file(s) or folder(s).

Generally these context menus are machine based, i.e. any user that logs in to a XenApp server will be able to see and use these context menus. On the face of things you might ask yourself why would this be a problem? Well suppose this application is strictly licensed for particular/named users. Therefore, you wouldn’t want anyone having the option to use them otherwise you would need to license the application for all users! In this case what you’d really like is to only have them available to users whom are licensed or whom you deem need them. A typical example of this might be Adobe Acrobat Professional that adds in a context menu to combine documents to single PDF.

The good news is there is a way of moving them from being machine based to per user with some fancy manipulation of various registry keys. So lets begin using our example of WINRAR and see how this can be done.

Firstly, we need to understand where context menus are located within the registry. From my experience when you right click on file(s) within windows explorer the context menus will be found in:


Here’s an example with WinRAR:


When you right click on folder(s) within windows explorer the context menus will be found in one or both of the following registry locations:


Below is a screen shot showing these registry keys for WinRAR:


So now we know where they are located we should open up the registry editor (REGEDIT.EXE) and export the context menu registry keys that we would like to make per user to .REG files (saving them to a location for safe keepings should you need to revert it back!).

What we need to do next is take a copy of those same registry (.REG) files so we can edit them. Using those copies open them in say notepad and replace HKEY_CLASSES_ROOT with HKEY_CURRENT_USER\Software\Classes (this is where the equivalent registry keys are kept for a user). It should now look something like this; using WinRAR as the example. Once completed save and close the .REG file.


Now we get dangerous (well not really if you’re in the registry all time adding, deleting and generally tinkering – sound familiar?!?). The next step requires us to alter the permissions of those context menu registry keys located in:


Again using WINRAR as the example I would open up REGEDIT.EXE and browse to the following locations:


Modify the ‘Users’ permissions from ‘Read’ to ‘Deny’ on each registry key (as listed above) like so:


Having changed those permissions you have successfully removed the context menus from a per machine basis or more precisely denied access to users and administrators. I’m no fan of doing things manually so I try and automate where possible. My choice of tool to change the registry key permissions in that automated fashion would be to use RES Automation Manager which has a built-in task to manage registry key functions, e.g. registry permissions. Unfortunately there appears to be a bug – which has been logged with RES Support – in RES Automation Manager for this task when the registry key contains “*” i.e.


So I turned to the ever reliable SetACL from Helge Klein (follow Helge on Twitter here) to set the required registry permissions and added the command line into my RES Automation Manager job. For any existing users of RES Automation Manager I’ve attached a handy building block (just click on the big red brick) that can be used and manipulated for your needs to change those permissions as described above.

In Part II of this blog post I’ll describe how you go about targeting these same context menus at specific users Smile.