Windows Installer always fails with error 1601 or 1603 when run from a service

Question

We have an application that gets installed at a customer's location. This application consists of a self-hosted WCF server running as a Windows service, as well as a client application that isn't related to this problem.

We publish updates to our customers by having the service download our WiX-generated .msi file in the background, then it is installed when the customer chooses to install it. The installation procedure is as follows:

The server copies a bootstrapper application to a temporary path and runs it, passing it the path to the MSI file to install
The bootstrapper uses the upgrade code in the MSI file to uninstall the previous version, then install the new version. It invokes the installer using various P/Invoke calls related to MSI's, like MsiInstallProduct.
The bootstrapper restarts the service

The issue is that at almost call customer sites, this automated process fails, though as with everything, it works in both testing and production at our location. Sometimes it fails during uninstallation, but normally it's during installation. Error codes 1601 (InstallServiceFailure) and 1603 (InstallFailure) are as common as they are entirely unhelpful in determining what went wrong.

We have a backup procedure whereby the user can manually invoke the installer by running the bootstrapper from within Windows (Run As Administrator is required, of course). This process works without fail, and it uses exactly the same installation logic as the automated process that fails.

All services are running as accounts with, at minimum, administrative privileges on the server box.

Where can I start in either trying to find more information about what is causing the error(s) or, even better, prevent them in the first place?

EDIT Here's one example of a failed install's verbose log file:

=== Verbose logging started: 3/29/2013  8:23:30  Build type: SHIP UNICODE 5.00.7600.00  Calling process: <<PATH TO MSI>> ===
MSI (c) (00:7C) [08:23:30:194]: Resetting cached policy values
MSI (c) (00:7C) [08:23:30:262]: Machine policy value 'Debug' is 0
MSI (c) (00:7C) [08:23:30:418]: ******* RunEngine:
           ******* Product: <<PATH TO MSI>>
           ******* Action: 
           ******* CommandLine: **********
MSI (c) (00:7C) [08:23:30:491]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (00:7C) [08:23:30:520]: Grabbed execution mutex.
MSI (c) (00:7C) [08:23:30:562]: Failed to connect to server. Error: 0x800703FA

MSI (c) (00:7C) [08:23:30:605]: Failed to connect to server.
MSI (c) (00:7C) [08:23:30:637]: MainEngineThread is returning 1601
=== Verbose logging stopped: 3/29/2013  8:23:30 ===

Check a verbose log file. There are lots of reports out there about the Windows Installer not running happily under a service but the specifics vary. — Rob Mensching
@RobMensching: Thanks. Just to be clear, the service launches a second executable that runs the installer process. So while it's running within the session of a service, it's not running within the same process. — Adam Robinson
Most installs I saw fail as SYSTEM was due to InstallShield's DCOM failures prior to IS12. There are also subtle differences such as environment variables such as USERDNSDOMAIN not being part of SYSTEM's profile. You really need to log the installer to have any hope of knowing what failed. — Christopher Painter
@Adam Robinson, I understand but you'll get a different user profile and all kinds of stuff. The log file should have a little more specific information. — Rob Mensching
@ChristopherPainter: This service always runs as either a domain or a local account, never as SYSTEM. At Rob's and your good suggestion, I'm going to try to enable verbose logging. — Adam Robinson

Christopher Painter Christopher Painter · Accepted Answer · 2013-03-08T18:59:39

This is too broad of a question to answer but here's what I've designed for other customers:

1) The elevated service downloads the MSI to a local directory and "advertises" (blesses) the MSI using the command msiexec /jm foo.msi

2) The non-elevated client side component then installs the MSI using the command msiexec /I foo.msi

The MSI must be properly designed and UAC compliant. The transition from Install UI to Install Execute will happen without a UAC prompt. Only properly scheduled ( deferred without impersonation ) custom actions will run elevated.

Once all the kinds were ironed out, the customer was very happy with their autoupdate pattern.

Windows Installer always fails with error 1601 or 1603 when run from a service

2 Answers