Deploying and Patching UAC

  • Article

Deploying and Patching Applications for Standard Users

Generally, enterprises will have to consider how they will install applications on their users’ workstations in an automated manner, thereby reducing administrative costs. There are fundamentally two parts to this problem: first, how these applications should be packaged for deployment and, second, what technology should be used to deploy them. In the case of smaller enterprise environments, a robust, automated deployment mechanism may not be necessary.

Assuming that the enterprise has already taken an inventory of the software that is run in its environment, the next step is to repackage these applications for deployment. Microsoft recommends the Windows Installer format because it has the unique ability to separate managing per-user settings from per-machine settings. This type of management generally is not possible with other packaging formats, especially deployment executables that are simply run by an account with more privileges, such as SYSTEM. The MSDN library (https://go.microsoft.com/fwlink/?LinkId=71498) contains many articles on Windows Installer; one suggestion is the Roadmap to Windows Installer documentation (https://go.microsoft.com/fwlink/?LinkId=71499).

The Windows Installer format includes the ability to user control the installation of these applications through Group Policy (Microsoft® IntelliMirror) and also through SMS. To enable Install on Demand with file extension or shortcuts, the following tables in the Windows Installer–based package must be populated with advertising data: Shortcut, Extension, Icon, and Verb. It is recommended that you also populate class, MIME, ProgID, and TypeLib. More information about IntelliMirror and Install on Demand is available at MSDN (https://go.microsoft.com/fwlink/?LinkId=71492).

There are other installer technologies that allow applications to install per-user and support auto-update, such as ClickOnce. This means that the installer will not require administrator or higher privileges to install and that the user will always run the latest version as long as the computer is connected to the network. It also places some limits on an IT professional's ability to control the installation of these applications.

ClickOnce (https://go.microsoft.com/fwlink/?LinkId=71500) deployment is a Microsoft .NET installation technology that automatically installs and configures a client-side application when a user clicks an application manifest link, such as an application manifest in a Web site, on a CD, or on a universal naming convention (UNC) path. By default, the application will copy itself to the Temporary Internet Files folder and run within a restricted environment.

Note

Even if your application has been signed with the IT strong name that gives it Full Trust, you still cannot do anything that requires administrator permissions, such as access certain parts of the file system and registry. ClickOnce applications however, are targeted as per-user applications, so this should not be a problem.

Important   ClickOnce should not be used for deploying applications that perform administrative operations.

Deploying to a Single Computer

To deploy an application for a single computer, the administrator must "publish" the application on that computer.

Deploying to All Users in a Domain

To advertise for all users in a domain, the administrator must "publish" the application through Group Policy deployment. Currently, only the Group Policy–based software deployment component of the Windows Server® 2003 operating systems and Windows® 2000 Server operating system takes advantage of this functionality.

Patching Applications as a Standard User with Windows Installer 4.0

Standard user account patching enables Windows Installer package authors to identify signed patches that can be applied by a future standard user. The following conditions must be met to enable standard user patching with Windows Installer 4.0:

  • The application was installed on using Windows Installer 4.0.

  • The application was originally installed per-machine.

  • The MsiPatchCertificate table is present and populated in the original Window Installer package (.msi file).

  • The patches are digitally signed by a certificate listed in the MsiPatchCertificate table.

  • The patches can be validated against the digital signature.

  • Standard user account patching has not been disabled by setting the MSIDISABLELUAPATCHING property or the DisableLUAPatching policy.

Windows Installer 4.0 Standard User Uninstall Behavior

The expected behavior for a Windows Installer 4.0 patch applied by a standard user is that it can also be removed by the standard user.

Launching an Un-Elevated Application from an Elevated Process

A frequently asked question is how to launch an un-elevated application from an elevated process, or more fundamentally, how to I launch a process using my un-elevated token once I’m running elevated. Since there is no direct way to do this, the situation can usually be avoided by launching the original application as standard user and only elevating those portions of the application that require administrative rights. This way there is always a non-elevated process that can be used to launch additional applications as the currently logged on desktop user. Sometimes, however, an elevated process needs to get another application running un-elevated. This can be accomplished by using the task scheduler within Windows Vista®. The elevated process can register a task to run as the currently logged on desktop user.

A C ++ code sample illustrating how to use the Task Scheduler to perform this operation is available in the references section of this article.

See Also

Other Resources

User Account Control (UAC)