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:

SNAGHTML10a57999

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:

SNAGHTML10a90573

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.

image

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:

SNAGHTML55f270b

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.

Enjoy!

Nathan

2 Comments

  1. Ingmar Verheij Author August 21, 2012 (8:35 am)

    Hi Nathan,

    Good information about how to move the context menu from a per-machine to a per-user setup.
    I’ve just got one questions: Why wouldn’t you remove the Users group from the HKLM key instead of putting a Deny? This prevents an Access Denied and will block access for all user (including Administrators)

    An alternative could be to replace the Users group on the HKLM key with a AD group that gives access to the application. That way you filter the access to users who should have access to the application without roaming it with the profile.

    Regards,
    Ingmar

  2. Nathan Sperry Author August 21, 2012 (11:00 am)

    Hi Ingmar,

    Thanks for reading the blog and posting your comments. You’ve made some good points and I did consider just removing the ‘Users’ and adding in an AD group instead; as you’ve rightly pointed out. The reason I went down this route was because removing the “User” permission would have meant removing inherited permissions on parent registry keys. For some system admins this might have caused more confusion than just a ‘Deny’ and it can easily be reverted back.

    In Part II (which you’ve obviously not seen yet!) I describe how to target them at users which makes it more flexible. For example we can then target the users’ context as well as making it easier to audit and diagnose any potential issues. Of course if you’re not using a UEM solution then removing the “User” ACE and replacing it with an AD group would probably be the best way forward.

    Thanks again for your contribution!!

    Nathan

Leave a Reply

Archives

Categories