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.
HKEY_CLASSES_ROOT\DesktopBackground
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.
- Take a backup of this key, you’ll thank me if you get it wrong!
- Browse down to desktopbackground\shell\display
- right click this key, choose permissions, click advanced then owner
- Select administrators from the list, then choose “Apply”.
- browse to the permissions tab and remove the “users” group.
- Click “apply”, then “ok”.
- The “screen resolution” menu should now disappear from any current and future sessions.
- Repeat step 2 to 8 on DesktopBackground\Shell\Personalize.
- 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
The first setacl.exe command you list here is giving me an error, suggesting -op needs a parameter? I am using the 64 bit 2.0.3.0 version. After some searching I think I found the parameter we need: -op “dacl:p_c;sacl:p_c”
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
Sorry about that Bruce, I’ll change the text type now.
Nice article also thx to Helge for setacl it’s really a time saver!
Setting the Security with a Group Policy works also
Great idea Tom, thanks for sharing.
Does using a GPO circumvent the trustedinstaller permission?
Yes – checked this in our Lab. Set the Registry Permission in the GPO (Remove USERS) – works !
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)
…