UAC: Five most common Install failure Scenarios and workarounds
User account control is one of the new security features in Windows Vista. It's the facilitator for running as Standard Users. UAC introduces the concept of split token - Standard User Token ( Limited Priviledges) & Admin Token ( Full Priviledges). With UAC on, installation programs happen to fail due to various reasons. The intension behind this post is to provide some of the very common install failure scenarios and their workaround.
A Quick Overview of Installation Programs and Windows Vista Installer Detection Mechanism :
Installation programs are applications designed to deploy software and most write to system directories and registry keys. Since these resources need admin rights, it means standard users don't have sufficient access to install programs. In Windows Vista, UAC detects installers and automatically prompts for elevation to admin status. Windows vista heuristically detects updater and un-installation programs too.
The detection applies to:
- 32 bit exes
- Apps without requestedExecutionlevel in the manifest
- Interactive processes running as standard users.
How the detection happen:
- Before a 32bit process is created, following attributes are checked:
- FileName includes: "install", "setup" "update" etc.
- Keywords in versioning resources fields: Vendor, Company Name, ProductName, FileDescrtiption, Original FileName, Internal Name and Export Name
- Keywords in side-by-side manifest embedded in
- Keywords in specific String Table entries linked in the exe
- MSIs are always detected as installation programs and hence will prompt for elevation (shield icon). [Unless the ALLUSERS property is either not set or set to nothing, and bit 3 in the word count summary in the summary information stream is flipped]
The detection happens only when "Detect application installation" group policy setting is on.
I have referred following link for this information:
https://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true.
Note :
The scenarios discussed in this post, represent the most common issues. This is for information purpose only. All of these scenarios should be treated as pointers. This information is subject to change at any time.
There can be multiple reasons an installer can fail in Vista. I am discussing some of the very common scenarios below:
Scenario I:
Installer fails without a UAC prompt / silently.
Reason: Installer fails because it is not detected as installer due to non-standard name and therefore it is not elevated.
Mitigation:
- Rename the exe to a standard name like setup.exe.
- Run Elevated
Scenario II:
Installer fails even though elevated with an UAC error
Reason: MSI contains a custom action that impersonates the user.
Example (ActionType = 1025 (0x401))
msidbCustomActionTypeInScript (0x400) delayed
msidbCustomActionTypeDll (0x1) = 0x401 – This is the Default
msidbCustomActionNoImpersonate (0x800) not set
Mitigation / Fixes:
Redesign to select not impersonating user.
Set bit msidbCustomActionNoImpersonate (0x800)
Example : ActionType 1025 (0x401) becomes 3073 (0xC01)Edit MSI with Orca.exe to change the right ActionType fields
Run from elevated command prompt
Scenario III:
Self Extracting EXE / custom wrapper runs elevated and executes a script, but script fails
Reason: UAC prompt occurs on self-extracting EXE or custom wrapper, but elevated privileges are not transferred to script
Mitigation / Fixes:
- Redesign to use MSI.
- Run from elevated command prompt
Note: Windows Installer 4.0 was designed to be fully UAC aware and compliant. So, if you can redesign the customer wrapper or self extracting EXE to be MSI, it can leverage the UAC model. You can repackage them using FLEXnet AdminStudio 7 SMS edition through SMS 2003. Flexnet AdminStudio 7 is a free download from SMS site. https://go.microsoft.com/fwlink/?LinkId=71355
Scenario IV:
Update fails when application with integrated updater tries to update itself. (Silent, error message, crash, etc.)
Reason: Application is not running elevated / Application is not designed to prompt for elevation
Mitigation / Fixes:
- Use alternate deployment technologies
- ClickOnce / MSI patching
- Redesign by separating the privileged functions
- Separate EXE
- Use Shield Icon when redesigning
- Run application elevated (not recommended)
Scenario V:
Update fails when application with separate updater tries to update itself. (Silent, error message, crash, etc.)
Reason: Separate updater not detected and therefore not elevated by PCA
Mitigation / Fixes:
- Use alternate deployment technologies
- ClickOnce
- MSI patching
- Mark updater to run elevated
I hope this post will help you resolve issues related with installation failures.
Comments
- Anonymous
June 12, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=5856