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.

Enjoy!

Nathan