ACT: Suppressing Elevation Prompts for Legacy Applications

ACT: Suppressing Elevation Prompts for Legacy Applications

  • Comments 4
  • Likes

Hello all, Sumesh here once again.

With Windows 7 and Windows Vista being widely used these days, we see a lot of requests from customers about legacy application interaction with User Account Control (UAC).

A common question is why a legacy application is asking for Administrator credentials when it shouldn’t actually require any. This is because UAC-aware applications include a manifest that specifies the required privileges for the application to run. Applications that are not written for Windows Vista or newer are what we call legacy applications.

Since these legacy apps don’t have a manifest, there is no way for UAC to actually know what privileges the app may require. UAC does have heuristics to try and detect if an application will require elevation, and requests Administrator credentials or approval to run. However, at times UAC may not be able to accurately detect if the application needs to be elevated or not and you may end up with an elevation or credential prompt that is unwanted.

Today we’ll go over how we can use the Application Compatibility Toolkit to suppress elevation prompts for legacy applications which actually doesn’t require Admin privileges to run.

To start with we first need to download and install the Application Compatibility Toolkit [ACT]. You can get the latest version here.

Once installed, launch the Compatibility Administrator. What we need to do is to create an Application Fix for our application in order to suppress the UAC prompt.

Right-click New Database under Custom Databases and choose Create New -> Application Fix:

image

You will be asked for the Name of the app and the path to the executable. In the subsequent page, you have the option to choose the most commonly used Compatibility modes. A compatibility mode is applied to a process and is also inherited (so child processes, grandchild processes, etc. will inherit this flag). A compatibility fix is applied to only that process, and is not inherited.

image

Choose the RunAsInvoker compatibility fix and click next all the way to Finish.

Now go ahead and save the Database; it will be saved as an .sdb file. The .sdb extension stands for Shim Database. Basically it is a package that includes registry and compatibility information for a binary. In the instance above, all we are doing is creating a small database file that says to add the RunAsInvoker fix to the binary in question. The binary itself is not modified, but any time the system needs to use the binary, it checks for the existence of a shim and then applies the modifications at runtime. An .sdb file can include a single compatibility mode, or many in any combination, assuming you don’t try to apply mutually exclusive shims.

What we need to do next is to install the shim that we just created. If it is for the same box, you could simply right-click and choose Install (see the first screenshot above).

If you need to install the patch on other boxes, you can copy over the .sdb file that we saved earlier and then use this command:

Sdbinst c:\<directory>\MyTestAppfix.sdb

This can be done via script or any other method you choose, as long as it is executed against the machine in question. Once installed successfully, you should see the fix listed in the Add Remove Programs list.

image

If at any time you want to remove the fix, this is where you go to uninstall it.

For an opposite scenario, where an app needs to always run as Administrator, you can use ACT to force an application to request Admin credentials by using the RunAsAdmin shim.

Below are some useful links for ACT/UAC and previous posts from Askperf.

http://msdn.microsoft.com/en-us/library/bb756929.aspx

http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

http://blogs.technet.com/b/askperf/archive/2007/10/19/introduction-to-the-application-compatibility-toolkit-v5.aspx

http://blogs.technet.com/b/askperf/archive/2007/10/26/application-compatibility-toolkit-v5-setup-and-configuration.aspx

Sumesh P.

Share this post :


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I generally prefer to use the SpecificNonInstaller flag when specifically targeting erroneous setup detection, and the RunAsInvoker flag (you're applying as a layer in the above illustrations) when overriding a developer mis-mainfesting the application. The overall outcome is the same (no elevation) but you leave behind breadcrumbs that indicate why you chose to do it. If you ever turned off installer detection, for example, you could remove all of the SpecificNonInstaller flags from your shim database, but would want to leave the RunAsAdmin flags.

  • oh my god.. really... thanks.. was waiting for this for a long time

  • I have a question, when i follow the steps above and i isntall the script i try and luanch the application in question and it still prompts for admin rights?.

  • i tried this but it only works during Test Run. When actually applying the .sdb, it fails.