A Windows NT service is a special executable program run by the system for performing background tasks. Windows 9x/Me does not support services. On Windows NT-based systems (Windows NT, Windows 2000, and Windows XP), Windows Installer itself has a service executable that is used to execute the installation script generated from your database.
Services run in a different security context than the interactive user,
and by default they run as the Local System account. While
the local system account is considered part of the "trusted computing
base" and has god-like powers over the system, it also has a very restricted
operating environment. For instance, the local system account does not
have permission to access file shares on the network. For
more about services, see the book "Professional NT Services"
by Kevin
Miller. For more about the Windows NT security model, see the book
"Programming Windows Security" by Keith Brown.
Windows Installer manipulates services through the information contained in the ServiceControl and ServiceInstall database tables. This information is used by the standard actions StopServices DeleteServices InstallServices and StartServices.
Packages with services generally need to control services, install new services, and possibly set security context information on newly installed services.
To install a service, you need to populate a row of the
ServiceInstall table for each service to be installed.
The information in this table corresponds to the arguments passed to
the ::CreateService Win32 API function. If your service
was created by the ATL AppWizard in Visual Studio, then you can extract
the information for this database table directly from the generated
code.
Many services are related and depend on each other for proper
functioning. This information is recorded in the Dependencies
column of the ServiceInstall table. COM EXE servers always
depend on the service RPCSS (Remote Procedure Call System
Service). izfree can automatically extract rows of the
ServiceInstall table for COM services that create a
service as part of their self-registration process.
If your service is a COM server, make sure that an entry for your COM server has been entered into the AppId table. Your COM server may fail to start if this information is not present.
You can manipulate any service through the ServiceControl table. For instance, your package might require that a service be restarted in order to find new information added by your package.
If your service requires a specific security context, you will need custom actions to provide that security context. For instance, you may want the service to run as a specific account which is created with the installation of the package. This reduces the chance that the system could be used to compromise the security of the target machine, since the service will be running in a restricted security context. The local system account is considered part of the "trusted computing base" and you should not run your services as the local system account unless absolutely necessary.
Windows Installer does not include any tables for manipulating the security context of the target machine (local user accounts, local groups, access rights, permissions, etc.) The MSI SDK contains an example of a custom action that creates user accounts. You will need to create any special user accounts before any service using such an account is installed.
Any security information associated with a COM server, such as that
configured by DCOMNCFG will also need a custom action for
adding and removing this information. The AppId table
does not provide a way to set security permissions on a COM server.