Software Deployment

I find this is a really generic error message when it comes to services.

In the past, I have received the same message when the actual problem was because the service depended on another service which hadn't been already installed.

Found out it was due to the user's machine not having the latest Windows Installer. You were right brenthunter2005. The error message doesn't reflect what's actually wrong. I know it's been two months, but thought I'd post this follow up for others' future reference.

Hmmmm, now that is a worry because the Services tables were built into the original Windows Installer engine and therefore should be supported wholely. Oh well, them's the breaks.

I'm getting the same error but my dependecies (RPC & WMI) seem to be inplace, and started and my InstallServices Table seems to be fine.

Does anyone have any idea why this wouldnt work, or an alternative method of installing services?

Thanks,

Can you post the details of your ServiceInstall table please?

ServiceInstall Table:


SERVICEINSTALL= MSExchangeMGMT

NAME= MSExchangeMGMT

DISPLAYNAME= Microsoft Exchange Management

SERVICETYPE= 272

STARTTYPE= 2

ERRORCONTROL = -1

DEPENDENCIES= WinMgmt[~]RPCSS[~][~]

COMPONENT=exmgmt.exe

Thanks BH.

I agree that your ServiceInstall table appears correct.

The way I troubleshoot these incidents is to install the service manually (at the point when the MSI fails) using a Resource Kit utility called INSTSRV.EXE.
Install the service manually and see if you can start it manually. This will tell you straight away if its a problem with the MSI (which I doubt) or a problem with the service (i.e.: missing registry keys, dependant files, etc etc)

Brent,

Great advice, and much appreciated.

I managed to install the service manually and start it manually. However the Dependency Tab remains blank. I suspect this may not matter too much as long as the dependencies are present and the service is running.

I could therefore include the manual installation of the service in a Custom Action that uses the INSTSRV command., No?

You can always test out the dependency by configuring the 'DependOnService' regkey in the appropriate HKLM services hive.

I always say that if Windows Installer can handle the command natively, then don't use a custom action.

To troubleshoot this further, remove the dependencies on the 'MSExchangeMGMT' service in your MSI and attempt to install it this way...

I agree with you in principle on your windows installer comment, however when you are being pushed for a solution....you know how it goes...

I tried the removal of dependency from the MSI previously but it didn't work.

Turns out the -1 value of the errorcontrol column shouldn't have the minus in there at all.

Works a charm now.

Appreciate the INSTSRV tip all the same.

Funny that, I came into work this morning and was going to post that! tou-che!

Error 1923

Check if you have the entry to the service in the HKLM\System\CurrentControlSet\Services as well as the Services table in your mis. If you do remove the entry from the registy table in the msi.

You should be able to run the msi with out the error.

I'm just trying to set an existing Service to Start and Automatically. Is this done via ServiceInstall or ServiceControl? Any other info is appreciated as I'm on a tight deadline.

You will need to use the ServiceControl table to control any installed service as the ServiceInstall table is used to install or remove services during install or uninstall.

Just ran into the same problem. Here are the steps to consider to avoid this situation:

If it is required to install a service under a specific limited account like the NetworkService account, the installer has to follow these steps
1) create a customaction for each OS that needs a different account name
2) create a property SERVICEACCOUNT and set it to the account name for the OS in a CostFinalize custom action
the names are: NT AUTHORITY\SYSTEM for Windows 2000, NT AUTHORITY\NETWORK SERVICE for Windows XP/2003
3) if the service needs the "allow interact with the desktop" flag, it MUST run under the LocalSystem account (thus the account name has to be left empty or set to NT AUTHORITY\SYSTEM)
4) add [SERVICEACCOUNT] to the account name field under Services
5) in any case, for the built-in service accounts like NetworkService, LocalService, LocalSystem, the password field is ignored and can be left empty

Any other setting leads to error 1923 (or in sequence to 1920) during installation without any other hint. An invalid account name is reported as an error during installation and gives the option to wait for the account to be created and retry.