Shop

InstallShield
Advanced Installer
AdminStudio
more / weitere

InstallShield und AdminStudio Schulungen

weitere Infos

An edited version of this article was published in the December 2006 issue of the Macrovision DevLetter.

More Windows Installer articles

Reasons why your setup may fail on Windows Vista

Windows Installer is not just a technology but also a set of rules and best practices. While these rules have been specified in the SDK for several years, many of them haven’t been enforced, and ignoring them didn’t break your setup. But on Windows Vista setups that don’t follow best practices may eventually fail on Vista.

This article doesn’t talk about the new features of MSI 4.0 on Windows Vista. It’s intention is to help you avoid those pitfalls, or to fix your setup to make it compatible with Vista.

Below is a list of problems that cause setups to fail on Windows Vista, while they seemingly worked properly on Windows XP. In many cases the problem becomes evident because of UAC (User Account Control): On Vista, even members of the Administrators group work with restricted permissions most of the time. UAC prompts users for their consent if elevated rights are required for a task. In the past such elevation often took place in corporate deployment scenarios, where an administrator advertised a setup, so that a restricted user could then install this „blessed“ setup. With UAC on Vista, this elevation becomes standard also for interactive installs.

Property values aren’t carried over from UI sequence to Execute sequence.

Symptoms: Property values that you set, or that a users enters, in the User Interface sequence get lost and reset to the default values when your setup switches to the Execute sequence. In the log file you see a message like:
Ignoring Disallowed Property PROPERTYNAME

Cause: This problem occurs if a privilege elevation takes place when the setup switches to the Execute sequence. Before Vista this mainly affected corporate deployment scenarios, but with Vista’s User Account Control (UAC), this is now the default for all MSI installs.

Solution: The properties that you want to pass from UI to Execute sequence must be listed as being secure. To do this, add a property called SecureCustomProperties and enter a list of your properties (delimited by semi-colons) as value. For more information see the documentation in the Platform SDK.

Custom Actions fail because of missing permissions

Symptom: Custom actions scheduled for immediate or deferred execution fail with error 1721.

Cause: On Vista, even administrators have only restricted permissions by default. Vista prompts for privilege elevation if needed. However only custom actions that are running in the Local System account get elevated right, while custom actions that impersonate as the current user don’t.

Solution: Schedule the custom action for „deferred execution in system context“ which is equivalent to setting the msidbCustomActionTypeNoImpersonate bit.

Custom Action still fails because of missing privileges

Symptom: Custom action fails although it is set to run „Deferred in System Context“ (NoImpersonate).

Cause: In Vista you can have NT services explicitly have only the privileges they need. On Vista Windows Installer, while running in the Local System account, has less peermissions than it had on previous versions of Windows. For instance, it doesn’t have the SeBackupPrivilege  which is required to call functions like RegLoadKey. Custom Actions inherit the privileges from Windows Installer and thus fail if they try to call this function.

Solution: There’s currently no solution. For more information please see Christopher Painter’s Blog and the Vista Compatibility Team Blog.

Setup works when using setup.exe but fails when directly launching the .msi file

Symptom: When you launch your setup by double clicking the .msi file or running msiexec it fails, but iof you start it using setup.exe your setup succeeds.

Cause: Windows Vista detects that setup.exe is a 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 fiel directly the UAC prompt will happen later, when your setup switches from UI sequence to 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 deferredin system context and placed in the Execute sequence between InstallInitialize and InstallFinalize. Modifying the system in the UI sequence always never was good practice. Often, this was used to run child installs without using the deprecated „nested install“ actions. The „InstallShield MSDE 2000 Object for NT Systems“ is a sample of this, and will fail on Vista.

Setup fails in silent mode

Symptom: Your setup fails if run in silent mode, e.g. using msiexec /q, but succeeds in Full, Reduced and Basic UI modes.

Cause: In silent mode Windows Installer doesn’t display the UAC elevation prompt, so all of your setup runs with restricted permissions.

Solution: If running in one of the other UI modes isn’t 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. 

Setup works when run by the built-in Administrator account but fails for other users of the Administrators group

Cause: The built-in account named „Administrator“ – which is disabled by default – is treated in a special way. UAC restrictions don’t 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’s one of the problems listed above, and fix it.

Setup packaged as single exe or web download fails

Symptom: While your setup exe unpacks or downloads, it fails with a message like:
Unable to save file C:\Windows\Downloaded Installations\...

Cause: Because of UAC even members of the administrators group don’t 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" (without quotes).

About the Author

Stefan Krueger is working as freelance setup consultant and is running the InstallSite.org web site, a place where setup developers share resources and information among peers. Stefan has been recognized by Microsoft as an MVP (Most Valuable Professional) for Windows Installer.

More Windows Installer articles

 

 

English News Discussions Windows Installer Related Tools More Help InstallScript About InstallSite Shop Site Search
deutsch Neuigkeiten Diskussionsgruppen Windows Installer MSI FAQ Artikel     Shop Suche

Copyright © by InstallSite Stefan Krueger. All rights reserved. Legal information.
Impressum/Imprint Datenschutzerklärung/Privacy Policy
By using this site you agree to the license agreement. Webmaster contact