UAC and Custom Actions in WiX-based Installation Packages

As part of trying to ship a stable version for our PowerShell provider for BizTalk, I set out to create a WiX-based Windows installation package and test it on different kind of environments and platforms.

Indeed, one of the goal of the provider, is to be able to access remote BizTalk instances from any given computer. Even from machines without Biztalk installed.

It turns out I had some problems successfully running the installation package on 64bit hosts.

One of the known limitations of our provider is that is relies internally on Microsoft.BizTalk.ExplorerOM which, incidentally, only runs as a 32bit-executable. That’s no big deal, since we can always run the x86 version of Powershell, and the BizTalk Server Administration Console itself has the same limitations.

However, there is no reason it should not install on a 64 bit host!

It turns out that, when running the msiexec.exe command-line directly in an elevated prompt, everything ran as expected. However, when double-clicking the .msi directly, I received the following error message:

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869.

After more research, it appeared that the problem does not lie with the host being 64 bit, but rather has more to do with the UAC feature of both Windows Vista and Windows 7.

In fact, the problem has to do with the Custom Action that runs as part of the installation process. This custom action registers the provider with PowerShell via the InstallUtil capability of the .Net framework. And this requires elevation to succeed.

After digging up loads of resources on the Internet, I finally stumbled upon a really excellent set of articles from Robert Flaming’s blog.

Once identified, thanks to the specific article that mentions the problem, the solution is, in fact, rather easy. Basically, as Robert puts it, with the permissions changes in the context of UAC, the server-side custom actions are executed as Standard User by default unless the NoImpersonate bit is flipped.

Here is the excerpt from the product.wxs file that need be changed:

<CustomAction Id="..."
 BinaryKey="InstallUtil" DllEntry="ManagedInstall" Execute="deferred" Impersonate="no" />

Installation can now be performed successfully, in Windows Vista or Windows 7.

This entry was posted in WiX. Bookmark the permalink.