There are some very common application installer issues developers run into due to UAC. Most of the issues are easy to fix. I’ll cover the most common issues in this post.
Per Machine Installers Need Admin Privileges
Unless you have a ClickOnce installer, your installer probably installs to a per machine location. The recommended location is Program Files which requires administrative privileges. Therefore, your installer will need to run elevated. MSI based installers handle this automatically. Exe based installers require an application manifest with a run level=requireAdministrator. If your exe installer is elevating without a manifest, this is due to the Installer Detection mitigation. It is recommended you explicitly manifest the installer rather than relying on the mitigation.
My “Updater” Fails
Applications may “self update” or have a separate application that checks for update and applies the changes. The updater periodically checks for an update. If an update is available, it downloads and applies the update. If the updater is running as a standard user under UAC, it will fail when trying to write to Program Files.
Possible solutions with consent dialog:
- Manifest the updater with a run level=requireAdministrator. This will cause the updater elevate when it executes.
- Launch the updater by elevating using ShellExecute.
Possible solutions without consent:
- Use User Account Control Patching (not supported on Server)
- Have an updater Windows service. Run the service with an account with administrator privileges.
- Use a scheduled task to perform the update check and installation. Configure the task to have administrator privileges.
My Installer Fails and Does a Rollback
I was talking with a developer who had been testing his app on Windows 7 and had very few issues. I asked him if he had any UAC issues. He said, “No, it works just fine under UAC. But we need to tell the user to disable UAC, install the app, then turn UAC back on.” It turns out, he was having the following issue.
MSI Installers Have a user context and an admin context. Custom actions can run in either context and default to the user context. If your custom action is doing something that requires administrative privilege (e.g. register a COM component), it will fail and cause the installer to rollback.
Possible Solution:
You need to make the custom action run in the admin context. This is done by setting the noImpersonate bit for the custom action. Chris has a great post on this topic.
A quick test to verify if this is likely the issue is to right click the installer and select “Run as Administrator”. If it succeeds, it’s probably this issue.
My Settings are Missing or in the Wrong Profile
I like running my machines as a Standard User (not a member of Administrators group). If I need to install a program, I get prompted for an administrator account and the installer runs with the administrator account I choose. This works great for my home machines that my kids use. 🙂
Frequently, this scenario is not tested for installers (see our testing document for a good list of tests). An issue can occur if settings are configured at the end of the install. Since you are running the install as a different user, the settings are configured for the administrator account rather than the standard user account.
Possible Solution:
Per user configuration should happen during first run of the application by the user. This avoids this issue and does a better job supporting multiple users.