Just Be Yourself: Understanding Windows Installer (MSI) Custom Action Contexts

From the beginning, one of the advantages of the Windows Installer (MSI) service has been the ability to run with elevated privileges: Depending how the installation was launched, it might be able to do more than the logged-in user would normally be able to do. One hurdle when beginning to use Windows Installer, particularly with respect to custom actions, is understanding the significance of the account, or context, in which your custom actions run.

The basic principles are:

  • The installation’s user interface just asks questions—some to the target system and some to whoever is running the installer—but shouldn’t make any system changes.
  • Immediate-mode custom actions run with the current user’s credentials, and generally don’t make system changes.
  • Deferred-mode custom actions can run either with the current user’s privileges (in user context, or with impersonation) or with elevated privileges (system context).

When you’re getting started, it can be useful to examine whose account is running a particular custom action. For example, if you have a custom action that displays the account running the action*, an immediate-mode or deferred action runs in your context (in this picture, the administrator’s account):

Robertblog1 
* There’s a bunch of ways to do this: Windows API, WMI, C#, you name it. Probably the simplest is to launch an executable in a custom action and then look at the Task Manager while the executable runs.

A deferred action in system context runs in the system account, assuming the installer was launched with elevated privileges:

Robertblog2 

This—in system context—is the type of action that can do things the logged-in user couldn’t necessarily do, assuming the installation was pushed out by an administrator using SMS, Active Directory, or something of the sort. When setting up your action in InstallShield’s Custom Actions and Sequences view, you specify the action context using the In-Script Execution setting.

Robertblog3 
If your action fails in a locked-down environment because of insufficient privileges, often with an error in the 1720’s, fixing up the action context will often do the trick. (Of course, there are some things that no action can do: say, trying to create a registry key directly under HKLMSOFTWARE, which gets you error 1406.) There are some cases where a deferred action need not run in system context: for example, an action that doesn’t make any system changes, or one that involves the local network, where the Windows Installer service might not have permissions that the logged-in user does.

Running Windows Installer ICE validation and InstallShield’s ISICE and ISBP validation can flag many issues related to scheduling and options for custom actions.

Parting words, even more basic than before:

  • If your action shows a dialog box or other UI, place it in the UI sequence, which uses only immediate mode.
  • If your action sets a property value, use immediate mode.
  • If your action changes the system, make it deferred, probably in system context.

For more information about elevated privileges, see the Windows Installer Help Library topics “Guidelines for Authoring Secure Installations” and “Installing a Package with Elevated Privileges for a Non-admin

For more information about troubleshooting custom action errors, download my white paper MSI Run-Time Logging and Debugging.

Leave a Reply

Your email address will not be published. Required fields are marked *