There are few things I love more than hearing, “This software requires Administrator rights.” Statements like this make me irritable and elated at the same time. An odd combination. On the one hand, I am irritable at that developer who can’t be bothered to follow best practices. On the other hand, I can’t wait to prove them wrong.

Though this guide won’t fix every single application that requires admin rights, it will solve the vast majority of these issues. We can break down administrative requirements into some pretty broad categories such as: file permissions, registry permissions, and User Account Control issues. Let’s talk about solutions for these three big problems.

 

Fixing File, Folder, and Registry Permissions with Group Policy

Standard users can write to just a few locations on a local machine by default. The primary location they control is their own user profile. Applications that write outside of these locations need additional permissions delegated to work properly with a standard user account. We have to overcome two problems to solve this issue:

• What permissions does this application require?
• How can I distribute these permissions automatically?

If the application is nice enough to say, “Hey – I can’t write to C:\StupidApplication\”, proceed to problem 2. If the developer doesn’t follow best practices with permissions, they probably don’t write helpful error messages either. Microsoft’s Process Monitor will show us what permissions are needed and it can be downloaded from here.

Ideally, install and run Process Monitor on a dedicated VM that has little else running on it (no AntiVirus, no indexing, etc). Process Monitor can be a little overwhelming at first. Like that annoying friend with no filter, it will literally tell you everything. Start your application as a standard user and reproduce any errors that you’ve received. Stop the capture in Process Monitor. Find your application in the capture, right click and filter only to it. You should now see exactly what your application is doing and the permissions needed to do it. Looking through the logs, you can further filtered to DENIED actions and see the exact permission that are needed.

Launch the Group Policy Management Console and create a new GPO named APP_Your Application Name (ex: APP_Adobe Reader). I prefer keeping all related settings, such as security settings or preferences, in a single GPO. Navigate to Computer Configuration/Policies/Windows Settings/Security Settings.

Right click on File System and Select Add File. From here, you can browse to the exact file or folder that needs additional permissions assigned. In the screenshot below, I’ve already added C:\Program Files\Meals Plus. Group Policy will automatically change any hard coded paths (like C:\Windows or C:\Program Files) to their correct variables. If a program can be installed in multiple locations (Program Files (X86) or Program Files), create a separate File permission setting for each.

The File System security settings in Group Policy allow you to easily deploy file and folder permissions to your clients. Though rarer, some applications might also need additional permissions to the registry. For example, an application may right a license key or registration information to HKEY Local Machine. Process Monitor is still used to find the requirements and Group Policy is still used to deploy the required settings.

Registry permissions are configured at Computer Configuration/Policies/Windows Settings/Security Settings/Registry. Right click on Registry – select Add Key. Navigate to the key that needs the extra permissions assigned. If the key does not exist on your computer, you can paste a key path directly into Selected Key location. As a note, you can also paste file and folder paths directly into the This Folder box under File System.

 

Fixing UAC Problems with Application Compatibility Toolkit

Occasionally, you will have an application that triggers a User Account Control (UAC) prompt when the application doesn’t require elevated rights. Don’t get mad at Microsoft for this one – the unnecessary UAC prompt is a result of shoddy coding. Preventing the UAC prompt can be accomplished in two ways:

• Stupid Way: Disabling UAC
• Easy Way: Creating an Application Shim

Because readers of this blog are never stupid, let’s take the easy way and create an application shim. Start by downloading and installing the Microsoft Application Compatibility Toolkit. Currently, it is part of ADK. Launch the Compatibility Administrator tool. Under Custom Databases, select New Database and press the Fix button in the toolbar. Name your application fix and browse to the executable that needs a bit more persuasion to work right.

Under Additional compatibility modes, scroll down and select RunasInvoker. You can press Test Run now to see if the application starts correctly. If it does, continue through the rest of the wizard. This tool can also be used to set other compatibility settings such as setting an application to run in particular mode for an older OS.

Save your database and it will generate an shim with the file format .sdb. You can deploy this fix by using a startup script (in Group Policy) or an application dependency(in SCCM). The script should simply run: sdbinst.exe .\applicationfix.sdb

We covered file/folder and registry permission changes with Group Policy and creating a shim for UAC. What other tricks do you use to fix applications that require administrator right