Windows Vista
In general installs and applications designed for Windows XP are highly compatible with Windows Vista given its file, folder and registry virtualization features. Many of Windows XP's existing features have been enhanced and new features added. While there is a high compatibility, new features and the tightening of security require developers to be aware of certain changes that affect both application development and distribution.
By default, in Windows XP all user accounts were created as local administrators. This meant that many users ran as administrators with full access privileges leaving the security of the system open to attacks. A design goal of the UAC was to prevent installations from being executed without the user's knowledge. While user accounts and restricted tokens have been around in previous versions of Windows, Windows Vista contains security protection for the administrator account as well. When an administrator logs in, two different tokens are created. The first token grants all the permissions and privileges of the administrator, while the second token is a restricted token (filtered token), offering virtually the same privileges of a standard user. With UAC (User Account Control) enabled, members of the administrators group run with the same access token as standard users. Only when the user gives approval will the program be granted the full access token.
Note: Features of UAC can be enabled and disabled, so developers should not rely on its features for elevation.
While application manifests are not new to Windows Vista, a new section has been added for the UAC to mark applications with a requested execution level. This information notifies the operating system of the privileges that the application requires so it can perform any necessary elevation. All UAC compliant applications should have the requested execution level added to its application manifest. Applications that are not run elevated or are not detected by Windows Vista's installer detection, may be run with file and registry virtualization (see next section). In future releases of Windows, the only way to run an application elevated will to have a signed manifest identifying the required privilege level.
In an attempt to provide compatibility for applications that are not UAC compliant, Windows Vista contains a new virtualization technology for files, folders and the registry. When a non-UAC compliant application tries to write to a protected directory such as Program Files, or a global portion of the registry such as HKEY_LOCAL_MACHINE\Software, the application is provided with a virtualized copy that is stored under the user's profile. Developers are not to rely on this technology being present in the future.
Virtualization (file/registry) is turned OFF for any applications:
Containing an application manifest with an appropriate requested execution level.
Detected by Windows Vista as installation programs resulting in a prompt for elevation/approval.
That are run elevated.
64-bit processes (Setup Factory installs are always 32-bit).
As of Setup Factory 7.0.6.0 or later, several new features have been added to aid in the installation process on Windows Vista. Additional features will be added in future service releases.
Windows Vista system requirement checkbox found in Project > System Requirements.
Windows Vista single and multiple file install conditions found on the Conditions tab of the single or multiple file/folder reference properties dialog.
Setup application manifests containing configurable requested execution level settings. The Requested User Privilege Level (Vista) setting can be found in Project > Advanced Settings.
Support added to the System.GetOSName and System.GetOSVersionInfo actions.
New return code for the File.Run action pertaining to elevation being required.
The Requested User Privilege Level (Vista) setting specifies which requested execution level to include in the install/uninstall's application manifest for distribution on Windows Vista. When the installation is run, the operating system reads this information to identify what privileges the installation requires. The default setting in Setup Factory is "Require administrator" and should generally never be changed. If for some reason you do not want to require administrator privileges to run the setup given the content of your install, you should be aware of the following information and required changes:
Using the "As invoker" setting means that your setup does not require any system access other than the current user's profile areas. Many of these issues exist for previous versions of Windows when running the setup as a standard user.
The following changes from Setup Factory's defaults are required:
Log file creation (install/uninstall): By default, the install log file is created in the Windows folder. This folder generally cannot be accessed by a user (all users initially) assigned the standard user access token. Therefore this path must be changed to a per-user writable location such as the user's Documents folder, or Application Data.
Install or copy destination: Certain locations are only accessible to users with administrative privileges such as: C:\Windows, C:\Windows\System32, Program Files.
Uninstall: By default, the uninstall executable is written to the non-accessible Windows folder. This must be changed to a writable per-user location such as Application Data.
File.Run actions: If you are running an executable file that does not require the "WaitForReturn" option, you should change it to the Shell.Execute action. The shell execute uses the Windows shell which will properly handle any elevation required to run the file via a confirmation dialog.
The following features will fail if used:
File registration: Registration of files requires access to certain areas of the registry that cannot be accessed by a standard user access token. These will fail.
Registry writes: Generally standard users only contain write access to locations under HKEY_CURRENT_USER. Other locations will likely fail.
Uninstall Control Panel Entry: The uninstall control panel entry is written to a location under the HKEY_LOCAL_MACHINE registry key and will fail when attempted as a user with the standard user access token.
Install or copy destinations: Certain locations are only accessible to users with administrative privileges such as: C:\Windows, C:\Windows\System32, Program Files. These will fail to be written to.
File.Run actions: If the executable file being run requires any type of elevation, the action will fail. This includes setup files, patch files or any file that contains a manifest marked as "highestAvailable," or "requireAdministrator." You should use the Shell.Execute action instead so the file can be run using the given privileges.
Using the "Highest available" setting means that your setup is designed to be run by all users. The setup runs with the same access token as the parent process. This means that if the setup is run by a member of the administrators group, their privileges will be elevated to the administrator's full access token. However, this also means that if a standard user ran the install, they would only have their highest privileges, those being a standard user. Therefore all issues mentioned above for "As invoker" would also exist using this setting. Again, the "Require administrator" option is generally best for installations.
Setup Factory 7.0's Vista compatibility was implemented in the 7.0.6.0 service release. Setups are now properly manifested using the Requested User Privilege Level (Vista) setting. Installs created using a previous service release may encounter some compatibility problems. However, Windows Vista contains a new "Installer Detection" feature that automatically detects unmanifested Setup Factory setups as installations. This will automatically prompt the user for elevation.
Note: While the Windows Vista "Detect application installation and prompt for elevation" setting is enabled by default, it can be turned off. If this setting was disabled, the setup would be subject to file, folder and registry virtualization that may cause application failure. If you wish for your setups to be Windows Vista compliant, we strongly recommend publishing the setup again using Setup Factory 7.0.6.0 or later.
The goal of Authenticode signing is to ensure both the integrity and authenticity of the program. If you plan to distribute on Windows Vista, another point of consideration beyond user experience, is the fact that Windows Vista has the ability to prevent any unsigned application from launching with full privileges. This may impact both the install and application functionality. It is recommended that all application and setup files be signed when distributed on Windows Vista.
Note: For more information, see Authenticode Code Signing.