Home > Batch Scripting, Remote Desktop Services (RDS), XenApp > Removing Screen Resolution and Personalize shell extensions from a users desktop session.

Removing Screen Resolution and Personalize shell extensions from a users desktop session.

While working in a XenApp 6 proof of concept I came accross this little feature and decided its time to share it!

When a user right clicks on the desktop, by default they get access to commands to manipulate the appearance of the desktop. As I restricted access to the control panel, the two options below were generating errors in the users sessions:

The error generated is your standard group policy restrictions error message as below:

While digging into this further I found the following registry key that corresponds to the two prompts we see above.


Under this key, you can see both entries that appear on the shell extension menu;

The problem with this key is, its owned by the TrustedInstaller account, and by default administrators cannot modify it. To modify this  key and hide this menu from users (but maintain it for administators) please follow the below steps.

Please note, any hotfixes from microsoft may remove your hard work, so be prepared to redo this work if Microsoft decide to work with this key in future.

  1. Take a backup of this key, you’ll thank me if you get it wrong!
  2. Browse down to desktopbackground\shell\display
  3. right click this key, choose permissions, click advanced then owner
  4. Select administrators from the list, then choose “Apply”.
  5. browse to the permissions tab and remove the “users” group.
  6. Click “apply”, then “ok”.
  7. The “screen resolution” menu should now disappear from any current and future sessions.
  8. Repeat step 2 to 8 on DesktopBackground\Shell\Personalize.
  9. Tada! go grab a coffee to celebrate your domination over the windows operating system.

And that’s it, you should now have a lean, clean and  error free shell extension menu when right clicking on the desktop.

Pedantic, begrudging scripters note:

Now if you’re a pedantic scripting so and so like me, you wont be satisfied to leave this job as a manual task. And despite spending more time than I’d like to admit, I couldn’t perform this work in powershell despite what I tried. Luckily the task was extremely easy to do with Helge Klein‘s setacl program.

Below is an example of a script to achieve this:

setacl.exe -on HKLM\software\classes\DesktopBackground -ot reg -actn setprot -op dacl:p_nc;sacl:p_nc -rec yes

SetACL.exe -on HKLM\software\classes\DesktopBackground -ot reg -actn ace -ace “n:system;p:read” -ace “n:administrators;p:read” -actn clear -clr “dacl,sacl” -actn rstchldrn -rst “dacl,sacl” -rec yes

  1. Bruce
    January 16, 2012 at 4:23 pm

    The first setacl.exe command you list here is giving me an error, suggesting -op needs a parameter? I am using the 64 bit version. After some searching I think I found the parameter we need: -op “dacl:p_c;sacl:p_c”

    • Bruce
      January 16, 2012 at 4:25 pm

      You know what .. you do have that there but I don’t see it on the page. I see it in the pages html code though. I cannot even copy and paste that line. Weird!

      -op dacl:p_nc;sacl:p_nc -rec yes

  2. January 16, 2012 at 4:31 pm

    Sorry about that Bruce, I’ll change the text type now.

  3. January 16, 2012 at 5:09 pm

    Nice article also thx to Helge for setacl it’s really a time saver!

  4. February 29, 2012 at 11:33 am

    Setting the Security with a Group Policy works also

    • February 29, 2012 at 11:54 am

      Great idea Tom, thanks for sharing.

      Does using a GPO circumvent the trustedinstaller permission?

      • February 29, 2012 at 12:03 pm

        Yes – checked this in our Lab. Set the Registry Permission in the GPO (Remove USERS) – works !

  5. Yahoo Serious
    May 23, 2012 at 3:13 pm

    A REALLY pedantic scripter would not use any 3rd party tool, but stick with the tools the OS provides:

    With WScript.CreateObject(“ADsSecurityUtility”)
    Set objSD = .GetSecurityDescriptor(“”, ADS_PATH_REGISTRY, ADS_SD_FORMAT_IID)

  1. January 16, 2012 at 3:56 pm
  2. January 20, 2012 at 9:04 am
  3. January 27, 2012 at 11:50 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: