Leveraging User Account Control in Applications

Programmers no doubt will wish to leverage UAC in applications, and even system administrators often do some programming in their daily jobs. This section is not meant as a complete introduction to how to use UAC in your applications but rather to give some ideas to system administrators to help them perform their tasks more easily. We also hope to give you a slightly better understanding of why UAC behaves the way it does in some situations.

Developers wishing more information on UAC are directed to books specifically targeted for developers on Windows Vista.

Application Manifests

The primary way to control UAC in applications is through the use of application manifests. An application manifest contains XML metadata about an application. These manifests are typically embedded within an application and are created when the application is built.

UAC is controlled by using a label called requestedExecutionLevel. There are two parameters in this attribute:

The level attribute defines how the application should behave. If the level is set to asInvoker the application runs without any elevation. In other words, for both standard users and admins in admin-approval mode, it would run with a standard user token.

If the level is set to highestAvailable, the application will run with the highest privileges the current user can have. This attribute is the reason why some applications, such as regedit.exe, require elevation when run from an admin in admin-approval mode, but not when run by a standard user. The standard user can never become more than a standard user. Therefore, the highest available run level is what the user has already-standard user. The admin in admin-approval mode can become a full admin, and therefore, the highest available run level requires an elevation.

highestAvailable can cause some very strange user experiences. While some users get a consent prompt, others get no prompt at all and the application just launches. The application, however, is restricted even though no user interface component informs the user of that. Some users get a credential prompt instead. Overall, the experience is confusing. Therefore, highestAvailable should be considered an application compatibility mitigation that should be used sparingly.

Finally, we have the attribute requireAdministrator. This is used for applications that require administrative permissions to run and will cause an elevation prompt (if this functionality is enabled) for all users.

The second parameter to requestedExecutionLevel is the uiAccess attribute. If this attribute is set to false then applications on this desktop with a filtered or standard user token may not send window messages to an application with an admin token. If the attribute is set to true then this application will send window messages to applications running at higher privilege levels.

Elevating Installers

Elevating installers properly tends to be a task that is not as straightforward as it seems it should be. Robert Flaming, Program Manager on Windows Installer, has written a series of 27 blog posts on how to integrate UAC and MSI at

http://www.blogs.msdn.com/rflaming/archive/2006/09/20/763945.aspx. This series is well worth reading for anyone that needs to build installers. Perhaps the most important takeaway is that all installers should be marked with requireAdministrator. The OS will attempt to guess whether an installer needs it, but it is just a guess, and it is not always accurate. Unfortunately, the OS will also not give the user an option to attempt to run installers as a nonadmin. As soon as it detects that the program is an installer it always prompts for elevation.

Elevating in Scripts

Many IT professionals spend much of their day writing scripts. A common question is how to cause something inside a script to be elevated. This can be done by using the runas invoke verb in your script. Here is a sample script that launches an elevated command shell:

Set myShell = CreateObject("Shell.Application")
Set myFolder = myShell.Namespace("c:\windows\system32")
Set myFolderItem = myFolder.ParseName("cmd.exe")
myFolderItem.InvokeVerb "runas"

The Elevate Tool

The runas verb can also be used in calls to the ShellExecuteEx API. Without going into complete details on how this works, the runas verb is used to specify that the application should be elevated.

Because we always thought the ability to invoke an elevation from the command line was a useful feature that Microsoft omitted in Windows Vista, we used the runas verb and the ShellExecuteEx API to write a small application that can be used to elevate any command from the command line. The elevate.exe application is available on the Web site associated with the book. Using it is quite simple, as Figure 1 shows.

Figure 1: You can use the elevate.exe application to elevate any application from a command line.

Elevated Command Prompt

One of the most useful tips if you need to perform many administrative tasks is to open an elevated command prompt and launch many of your applications in there. Any application launched from an elevated command prompt (except for ones that explicitly cannot be elevated, such as explorer.exe) are launched elevated.

Using the elevate.exe tool mentioned earlier, you can get an elevated command prompt by just right-clicking. Add this text to a registry script:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\ECmdHere]
@="Elevated Command Prompt Here"
[HKEY_CLASSES_ROOT\Directory\shell\ECmdHere\command]
@="elevate.exe cmd.exe /k cd \"%1\""

Import that script into the registry and put elevate.exe somewhere along the path. Now when you right-click on a folder, you get see an entry like the one in Figure 2.

Figure 2: With the elevate.exe tool, it is easy to get an elevated command prompt anywhere.