Packaging issues that may be encountered when working with Vista

Products

• Symantec Products

Issue/Introduction

Installation packages work perfectly on earlier version of Windows, but fail when running them on Windows Vista*.

Cause

Windows Vista introduced a new security tool called UAC (User Account Control). As a consequence, even members of the Administrators group work with restricted permissions most of the time. If elevated rights are required for a task, the UAC prompts users for their permission to execute the task with elevated privileges.

Vista also introduced Windows Installer 4.0, and this service had some additional restrictions imposed, in the form of lesser privileges while running in the Local System context

Vista recognizes typical install program names such as "Setup.exe" and "Install.exe" and tries to ensure that no unauthorized code can be installed without user agreement. This is intended to reduce the impact of self installing virus code, but at the same time this mechanism can also interfere with normal installation operations encountered in software installers.

The Resolution section of this article lists some situations that are known to cause installation issues on Vista, and provides possible workarounds.

Resolution

1. Custom Action may fail if ALLUSERS is not Set: 

Deferred custom actions running in system context execute with the rights of the local SYSTEM accounts, as the Windows Installer service runs in the SYSTEM context. Actions not marked as "deferred in system context" run with user impersonation, and have the rights of the user account that launched the install.

When running a per-user installation (ALLUSERS not set, or set to 0), "deferred in system context" actions will run in the same context as normal deferred or immediate custom actions, which is with user impersonation. This can potentially cause a runtime issue with the custom action in the following circumstances:

1. The user that launched the MSI installation is not an administrator, or is running on Windows Vista, in which users are part of the administrators group, but do not have administrator privileges by default.
2. The custom action attempts to modify a resource in a per-machine location on the machine, such as a file in Program Files, or a registry key/value in HKEY_LOCAL_MACHINE in the registry.

While this may not be an issue with Windows XP or older versions of Windows, Windows Vista does not run users with full administrator privileges by default. Therefore, since a "deferred in system context" action runs with user impersonation when ALLUSERS is not set, the custom action could fail.

Solution: The recommendation to prevent this issue arising is to ensure that a per-machine installation is always performed by setting ALLUSERS to 1 in the Property Table or on the command line. Per-machine installations are generally easier to manage, and are the current best practice recommendation from Microsoft.

2. Launching a program at the end of an .exe setup may create a security issue:
Launching your application or displaying a readme file (using notepad for instance) at the end of your .exe installation may cause a security issue on Windows Vista. The problem arises if the installation runs with elevated privileges because the child process (your application or Notepad*) inherits these privileges. This means that now your application runs with full administrator rights, which defeats the purpose of UAC.

This is a problem for all setups that don't use Windows Installer technology, (for example, Wisescript) but MSI-based setups can also be affected.

If you launch an .msi file on Windows Vista, only custom actions that are scheduled for "deferred execution in system context" will run with elevated privileges. Usually you wouldn't launch your application with such an action, but instead use a DoAction event on the Finish button on the "setup complete" dialog. Using this method will avoid any security issues.

However, if you launch your MSI install using a setup.exe which is not explicitly manifested to indicate that it doesn't need elevated rights, the UAC prompt will be displayed right at the start, and your whole user interface sequence will run with elevated permissions. In this case the launched application will inherit these permissions.

Solution: In general it may be best not to launch the application at the end of the installation on Vista. This can be achieved by using a condition on any action based on the operating system major version. If a reboot is required to complete your installation, bear in mind that your application may not run properly when launched from the Finish dialog.
 
Note that similar security problems can also happen on Windows versions before Vista, for instance if the setup was launched using RunAs with administrator privileges.

3. Public Property values aren't carried over from the UI sequence to the Execute sequence:
Public Property values that you set, or that a users enters, in the User Interface sequence are lost or reset to their default values when your setup switches to the Execute sequence. In the log file you will see a message like:

Ignoring Disallowed Property PROPERTYNAME

This problem occurs if a privilege elevation takes place when the setup switches to the Execute sequence. Before Windows Vista this mainly affected corporate deployment scenarios, but with UAC this is now the default for all MSI installations.

Solution: The public properties that you want to pass from the UI sequence to the Execute sequence must be listed as being secure. To do this, add a property called SecureCustomProperties to the Property Table and enter a list of your properties (delimited by semicolons) as its value (for example, "USERPROP1;USERDATA1").

For more information, see the documentation in the Platform SDK help file MSI.CHM.

4. Custom Actions fail because of missing permissions:
Custom actions scheduled for immediate or deferred execution fail with error 1721.

On Windows Vista, even administrators have restricted permissions by default. Windows Vista prompts for privilege elevation if needed. However, only custom actions that are running in the Local System account context get elevated correctly, while custom actions running in the Current User context do not.

Solution: Schedule the custom action for "deferred execution in system context," which is equivalent to setting the msidbCustomActionTypeNoImpersonate bit in the CustomAction table.

5. Custom Action still fails because of missing privileges:
Custom action fails even though it is set to run "Deferred in System Context" (msidbCustomActionTypeNoImpersonate).

The Windows Installer engine, running in the Local System account on Windows Vista, has lesser permissions than it had on previous Windows versions. For instance, the Windows Installer service does not have the permission SeBackupPrivilege, which is required to call functions such as RegLoadKey. Custom actions inherit the privileges from Windows Installer and thus fail if they try to call this function.

Solution: There is currently no solution.

You can find more information on the restrictions added to Windows Installer 4.0 by searching on google - eg: http://blog.deploymentengineering.com/2006/10/vista-deferred-ca-consideration.html 

6. Setup works when using Setup.exe but fails when directly launching the .msi file:
Windows Vista detects that setup.exe is an install program that will probably require elevated rights, and therefore displays the UAC prompt. As a result, the UI sequence will run with elevated privileges. However, if you launch the .msi file directly the UAC prompt will happen later, when your setup switches from the UI sequence to the Execute sequence. In this case the UI sequence runs with restricted permissions.

Solution: Custom actions that modify the target system (and therefore need elevated rights) should be scheduled as deferred in the system context and placed in the Execute sequence between InstallInitialize and InstallFinalize. Modifying the system in the UI sequence has never been good practice. Often, this was used to run child installs, such as software dependencies (MDAC, .NET2.0, etc)  without using the deprecated "nested install" actions.
Many current Autodesk product installs do this, and may thus require additional work to extract these child installs for deployment as separate MSIs.

7. Setup fails in silent mode, but succeeds in Full, Reduced, and Basic UI modes:
In silent mode Windows Installer does not display the UAC elevation prompt, so the entire setup runs with restricted permissions.

Solution: If running in one of the other UI modes is not feasible, use the Elevated Command Prompt to launch your setup, or use a management tool such as SMS, Tivoli, Altiris, etc., to deploy your setup.

To launch an elevated command prompt, simply press the Win key; type cmd; press Ctrl + Shift + Enter; and then press Alt+C to confirm the elevation prompt. Once you've got an elevated command prompt, consider executing color 4f as your first input so that this console window is visually differentiated from other non-elevated windows.

8. Setup works when run by the built-in Administrator account but fails for other users of the Administrators group:
The built-in account named "Administrator"—which is disabled by default—is treated in a special way on Vista.  UAC restrictions do not apply to this special account, but they do apply for all other members of the Administrators group.

Solution: Find out why your setup fails if UAC restrictions apply; maybe it is one of the problems listed above, and fix it.

9. Setup packaged as single EXE or web download fails:
While your setup executable unpacks or downloads, it fails with a message similar to:

Unable to save file C:\Windows\Downloaded Installations\...

Because of UAC, even members of the Administrators group do not have write access to locations such as the Windows folder and the Program Files folder.

Solution: Change the location of the folder for the extracted or downloaded setup files from [WindowsFolder]Downloaded Installations to [LocalAppDataFolder]Downloaded Installations

Applies To
Microsoft Windows Vista