Designing Software Installations for Windows Vista Using Windows Installer

Here's a handful of Vista-related gems that should make your life on the Windows Installer end of the new OS bearable -- dare we say enjoyable?

Restart Manager - Fewer Reboots

The Restart Manager (RM) is a new technology in Windows Vista that helps to address the cause of reboots. It's actually a set of Application Programming Interfaces (API) that allow a list of files to be sent off to RM. RM will then pass back a list of applications or services associated with those files. You can then request RM to shut down those processes that have the files open so that you can update the released files. Then the Operating System (OS) can restart those applications or services.

Windows Installer 4.0 (WI) is automatically integrated with the RM. Files in use can automatically be freed prior to an install. Applications can save their state so that work is not lost and applications can register to be restarted automatically after an installation is complete. This can be managed via the User Interface (UI) and dialog windows, presenting the end user with options.

To have your installation support RM you should ensure your application responds correctly to shut down messages and save state from RM. You can register your application for restart using the RegisterApplicationRestart() API call or author your WI package to use a new dialog named MsiRMFilesInUse. This dialog is in addition to the previous FilesinUse dialog.

MsiRMFilesInUse Dialog

This is an authored dialog that gives the option to shut down applications holding files open. There is a sample provided in the Software Development Kit (SDK). Notice the Radio buttons at he bottom of the MsiRMFilesInUse dialog, this allows the user to select "Automatically close applications and attempt to restart them after setup is complete" or "Do not close applications. (A reboot will be required.). Make sure the control event on the 'OK' button uses the new RmShutdownAndRestart event. This is what tells the WI that the users wish to shutdown the open files as part of the setup.

Click to view.

Installation Under User Account Control (UAC)

Background

Challenges include the fact that most users run with full administrator privileges all of the time. This places the computer / user / network at risk from malware, viruses, etc. and is typically expensive to support. Trying to enable a standard user to perform tasks, and for applications to run without administrative privileges is difficult. User Account Control (UAC) in Vista makes it easier to run as a standard user. Standard users can now change time zones, power settings, Virtual Private Networks (VPN) and more. They can install approved devices and there is a higher application compatibility focus.

UAC is a lot like a locked-down desktop, which stem administrators have been doing for some time now. WI was originally designed for this scenario, to be able to deploy applications to locked down environment to allow standard users to install them.

Credential Prompt-Free Patching

Since Windows Installer 3.1 credential prompt-free patching is supported when a signature file is added to the original MSI package. If the MSI was 'blessed' or allowed by the system administrator, the subsequent patch can be applied without user intervention. So with UAC nobody wanted to introduce any new prompts for patching existing installations.

Patches can be signed so that credentials are not required. Author MsiPatchCertificate table in WI package (original MSI) and sign the patch with the matching certificate. This is controllable via the DisableLUAPatching policy; you need to ensure this policy is set correctly. The registry key location is held under HKLM\Software\Policies\Microsoft\Windows\Installer and uses the property DisableLUAPatching.

If this per-machine system policy is set to '1', the installer prevents non-administrators from using UAC Patching for any application installed on the computer. Unsigned patches will still require credentials.

Click to view.

Installer Detection

As a 'setup.exe' is typically a big black box, it gets treated differently to a MSI package. Typically these need to run elevated and are, if allowed, elevated at the start of the installation. With WI the user will typically read the UI dialogs and have a better idea of whet the installation is, compared to the 'setup.exe' installation.

Sticky Elevation

There is a term 'sticky elevation' which refers to all the elevated activity which is not part of the initial installation or removal. Install on Demand (IoD), Repair and Patching are all typically activities which can run without standard user intervention in an elevated context.

Sign Your Package

Prior to Vista there were not too many reasons to sign your package. Now under UAC on Vista the credential prompts you see as the end user differs if you have signed your package. You should also sign any associated cabinet (CAB) files. Please refer to "Authoring a Fully Verified Signed Installation" in the Windows SDK for more detail.

Click to view.

Click to view.

AdminUser & MSIUSEREALADMINDETECTION

The 'AdminUser' property is treated differently under UAC, the property is always set to true to avoid issues. As the point with Vista and UAC is not to have any user logged in with Administrative privileges, it is simpler to set the value to always be true. If you need to really detect the credentials of the logged on user, use the MSIUSEREALADMINDETECTION property.

Note - Under UAC Administrate User is nearly always going to return false.

ALLUSERS

Avoid setting the ALLUSERS property as part of any UI. Set the property ALLUSERS=1 by default. UAC functionality will be enabled if ALLUSERS=1, otherwise the installation will be unmanaged and certain features will be turned off.

Elevation will not be 'sticky'; the user will need to answer credential prompts and UAC patching is not going to be enabled.

UAC & Bootstrappers

If you don't manifest your bootstrapper (setup.exe), then by default it's going to run elevated by virtue of 'installer detection' and not receive the benefits of elevation via WI.

UAC-Compliant Packages

When possible try to create a UAC-compliant package. This will install the package actually as the user, without requesting elevation. You need to mark the msidbSumInfoSourceTypeLUAPackage property in your package; this is a summary information stream. WI will not request elevation as part of the installation. It will not request elevated and will simply install with user credentials. If the installation tries to do something the user does not have permission to do, the installation will fail.

Custom Actions (CA) & UAC

The WI architecture has a client server model running as a service. The client runs as the invoker, which under UAC is standard user. The service has pieces that run as the invoker (non admin) and pieces that run elevated (admin).

On XP, for example, if you had an Administrator running an installation, the client invoker would be running with admin and the service would too.

The client side always runs as invoker and is run in the UI sequence (Installation Wizard and Immediate CA). Any immediate execute CA are going to run as the user, there is no way to elevate this. If you have a CA that requires Administrative permissions, in the UI sequence, you will have to redesign the package.

Deferred CA can either run elevated or not, there are two types of deferred CA. One is called an 'impersonate' and the other is called 'no impersonate'. The impersonate deferred CA actually runs as the user that executed the installation (i.e. it impersonates the invoker). The no impersonate CA is the one that actually runs elevated. You should author your CA, if it requires Administrative rights, to deferred no impersonate.

Common problems with CA failing under Vista include CA placed in the wrong sequence or mode, for the UAC.

Improved Manageability - Logging, Event log and WMI

Automatic per WI Logging

You can now enable logging on a per package basis. Just use the new property MsiLogging within the desired MSI package. There is also the DisableLoggingFromPackage policy to override this if Administrators wish. The MsiLogFileLocation property holds the log file location and name of the file for easier locating.

Windows Resource Protection (WRP)

WRP protects static files, and their associated registry keys, that ship in the OS. The majority of files installed by Windows are WRP-protected. The majority of registry keys are for system COM objects (26,000 keys out of 65,000 OS keys are WRP. WRP is based on Windows discretionary access control (DAC), only the operating Trusted Installer Service (TIS) can change WRP resources. Application installers attempting to change WRP resources will receive an "Error Denied" dialog.

If an authored MSI package tries to modify a WRP -protected resource, the installation will not fail. This behaviour is for application compatibility purposes, a warning will be written to the log file for information. If a component has a WRP-protected key path, the entire component will not be removed on an uninstallation of the MSI package. Only use approved redistribution packages / merge modules to install OS redistributables. Try not to just include files arbitrarily.

Improved Patch Creation Tools

Patchwiz v4.0

A complete re-write of previous versions, but is fully backward compatible. You can use the latest version to create patches (MSP) for any WI version. The patch creation process has been simplified and the performance has been drastically improved. This version really cuts the time down on creating patches. The logging functionality is enhanced, this should help debugging any problems and it also now has environment variable support.

Best Practises & Resources

Build backwards-compatible packages, there is no down-level redistributable for MSI 4. Follow Vista logo guidance (www.), even if you are not seeking logo. Test in a locked-down environment and with various UAC scenarios. If you are unable to perform full UAC testing on Vista, you can try advertising the package to a Windows XP machine (MSIExce /jm) and then install as a standard user. This will replicate the experience of UAC on Vista.

.NET

Be aware that .NET and WI has had some issues. You don't want to have any CA or custom code that's dependant on assemblies that you are installing as part of you installation. Those assemblies might not actually be available at install time.

Windows Installer SDK

http://msdn2.microsoft.com/en-us/library/aa372866....

Windows Installer Team Blog

http://blogs.msdn.com/windows_installer_team/

Credit to Tyler Robinson - Lead Program Manager