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:
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.
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.
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-compatibi...
http://blogs.technet.com/b/askperf/archive/2007/10/26/application-compatibility-toolkit-v5-setu...
Sumesh P.
| Share this post : |
|
|
|
|
|
|
|
|
<br/>