seyup.exe via COM service application

[jonathanqis]

Has anyone ever tried to run an installation setup.exe application from within a Windows service ?

I am currently trying to do so (using Installshield Spring 2012) and only succeeding when the service is registered as a COM server.

It fails with -3 when it is registered as a COM service.
N.B. I am passing it an .iss file on it's command line e.g.

setup.exe /s /f1"setup.iss"

The command line parameters have been checked thoughroughly.

It also works if I drop the silent installation (use of .iss file) even with my COM app registered as a service.

It appears it does not like using the silent install method when called by 'createprocess' from the service.

I noticed that the temporary files generated, are stored under my login accounts appData folder when NOT running as a service.
It uses a windows folder when my COM server is a service.

Has anyone come across problems, possibly file access or rights related when using the windows NT account (services run as by default) for running a Setup.exe install file.

Any help would be greatly appreciated thanks.

[phill_mn]

I used to write windows services (which was not a setup), and actually when we started developing our product as a windows service, the boss wanted me to take a GUI mode 'server' application and launch it 'as a service' thinking it would run as a service. I currently write setup packages which deploy lots of windows services. I learned quickly that there are a number of reasons why an application written to run in GUI mode may (likely will) have problems 'as a service' and most of the problems relate to the security context differences.
1) A Windows Service runs in a separate "Winstation/Desktop" combination than the interactive Winstation/Desktop.
2) Generally a Windows Service should never try to interact with the user (except through some very specific mechanisms, such as a named pipe to a GUI mode client).
3) When a windows service launches another process using CreateProcess the spawned process ends up in yet another Winstation/Desktop. Windows messages cannot transverse Winstation boundaries, so named pipes or MMF files should be used for the processes to communicate. If a service needs to interact with the spawned process it should first do a LogonAsUser, create a Duplicate of the Impersonation Token, and pass that token to CreateProcessAsUser along with a Startup structure which is loaded with the service's Winstation and Desktop information.
4) A user's profile is only loaded when a user logs into the Interactive Winstation and is only available to processes running in that context (which does not include services). So a service must be coded to load the user's profile to gain access to that users' registry hive and user specific folders.

This is just a few of the security context issues related to writing Windows Services. Clearly a tool like InstallShield (InstallScript) or even the client portion of MSI is not designed to be run in a Windows Service context. It is foolish to try and shoehorn it into that context, which will result in security problems in addition to the operational failures that you are observing. Maybe folks can get away with running a simple console type application has little interaction with the user or system resources, and launch it under a wrapper as a windows Service. But a setup.exe which was never designed to be a windows service and which provides such critical functionality I do not believe should be used in this way.

Regarding your specific observations they are pretty much the kind of issues I would expect from calling CreateProcess on any application in a Windows Service context. Yes the default Service accounts have very restricted permissions on the local file system on Vista or later, and no access off the box. By impersonating another user within the service these issues can be addressed, but a setup.exe is not designed to do this.

When doing /s on an InstallScript package, code 3 means that the script engine could not locate an entry for a dialog in the response file. So when your setup is run in one context you may see one set of dialogs and when it is run in another context you may see a different dialog sequence (an error message or some other dialog). This is probably what is happening to you when you are running in silent mode. Also remember that it not setup.exe that is doing this processing but the underlying engine process which setup.exe has spawned (and in an application not designed to be a service the winstation issue is probably a part of this failure). You can capture a response file doing one dialog sequence and then capture the response file doing another dialog sequence (maybe repair, or an error sequence) and then manually edit the INI format of the response file to add all of the dialog entries into a single response file which handles a wider variety of scenarios to avoid the error 3.

I'm sorry for the long answer which does not give you an easy fix, but I hope it helps. I have tried to provide info to others who have reported similar errors trying to launch their setup.exe using a RunAsService wrapper with similar problems. I'm not aware of anyone that has succeeded, particularly without rewriting both setup.exe and the underlying GUI mode engine.

Phill

[jonathanqis]

The point of running the setup with the /s option and providing it with an .iss file is to eliminate all user interaction. No dialogs or GUI components appear during the install. All data related to dialogs is read in from the InstallScript code around the dialogs (instead of).

I should stress this is the only time we run it from within the service. This enables any user on a machine to update our existing software and to allow the process to be automatic (i.e. not require a user decision at all).

We have now got it working. The problem seemed to be related to the fact that it would not copy the .msi file to the folder we chose to cache it in on the system.
However, it appears that the folder c:\windows\installer is acceptable to the system.