Understanding Windows Services Architecture

Windows services, also called service applications, are applications that run on Windows computers regardless of whether a user is logged in. A Windows service includes an executable file, a directory for storing application components, and registry settings that define the service parameters. The Windows service implements a programmatic interface that SCM can use to control the service. A Windows service can be started automatically when the system is booted or manually with a service control program. A service control program is an application that uses SCM functions to control a service. Examples of service control programs are the Services tool and the command-line tools net.exe and SC.exe.

The following figure illustrates the Windows services architecture.

Relationships between service control program, service control manager, and Windows services

Responsibilities of Service Control Manager

SCM, also referred to as the service controller, is a generic Windows process that performs various service-related tasks. These tasks are detailed in the following sections.

Maintaining a database of installed services

SCM maintains a database of all installed services, including a list of all services and device drivers that must be loaded, in order for Windows to start successfully. As additional services, such as Exchange Server 2003 services, are installed on the server, entries are added to the services database. SCM maintains this database in the following registry location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

The services database contains a key for each installed service and driver. The name of the key corresponds to the name of the service, as specified when the service was installed by a service configuration program. For example, MSExchangeIS is the name of the Microsoft Exchange Information Store service and MSExchangeSA is the name of the Microsoft Exchange System Attendant service. The maximum service name length is 256 characters.

The following figure shows several Exchange-specific service entries in the registry.

Exchange-specific service entries in the registry

Locking and unlocking the services database

SCM must lock the services database during SCM initialization in order to serialize access to the configuration information. For example, SCM locks the services database before starting a service, so that the service configuration cannot be changed while the service starts. SCM releases the lock when the service start is complete. Service configuration programs must also communicate with SCM to request a lock before reconfiguring a service and to release the lock. You can use the SC.exe command-line tool with the command sc QueryLock to see if the services database is locked.

Enumerating installed services

The SCM process reads each registry key from the services database to create a service record for each service. A service record includes the service name, startup type, the service status (for example, the current state of the service and acceptable control codes), and a pointer to the dependency list. SCM uses these service records to determine which actions are valid for the services, according to their current status and dependencies. For example, you cannot stop System Attendant in the Services tool if another service is running that depends on System Attendant, such as the Microsoft Exchange Information Store service.

Starting, stopping, pausing, or resuming services

To perform general tasks, such as starting or stopping a service, SCM communicates with the services it controls. SCM can start Windows services automatically at system startup (auto-start service) or manually when requested by a service control program (demand-start service). However, if an auto-start service depends on a demand-start service, the demand-start service is also started automatically. The startup type can also determine that the service is disabled, in which case it cannot be started. You cannot start an auto-start or demand-start service if the service depends on a disabled service. This dependency is important to note, especially if you plan to disable services (for example, on a front-end server running Exchange Server). You must not disable essential services. Otherwise, the operating system may not start, because disabled services prevent the start of all other services that depend on them. If you notice startup problems after disabling a service, do not log on to Windows. Instead, you should reboot the system with the "last known good" configuration to discard the most recent changes to the service configuration. Windows stores the "last known good" configuration in the HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001 registry key and updates this key every time you log on successfully to the operating system. When you log on to Windows with an incorrect configuration, you apply the incorrect settings to the "last known good" configuration.

To quickly verify the dependencies and startup type of Exchange services, you can use the tool SC.exe with the command sc <service name> qc. For example, the following output represents the standard configuration of System Attendant (command line: sc qc MSExchangeSA):

SERVICE_NAME: MSExchangeSA

TYPE : 10 WIN32_OWN_PROCESS

ERROR_CONTROL : 1 NORMAL

BINARY_PATH_NAME : "C:\Program Files\Exchsrvr\bin\mad.exe"

LOAD_ORDER_GROUP :

TAG : 0

DISPLAY_NAME : Microsoft Exchange System Attendant

SERVICE_START_NAME : LocalSystem

To determine the startup type, from the Services tool, click the General tab, and then click Startup Type. You can also use the Services tool to start System Attendant or use SC.exe with the command line sc start MSExchangeSA. You can also start services with the net start command, such as net start MSExchangeSA. Most administrators prefer using the Services tool.

Whether you use the Services tool, SC.exe, the net start command, or any other service control program, SCM performs the following sequential steps to start a service:

1. Retrieves the account information stored in the services database

   The user name and password of the service account are specified at the time the service is installed. SCM stores the user name in a REG_SZ registry value named ObjectName within the Registry key of the individual service (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service name>). The password is in a secure portion of Local Security Authority (LSA). You can change the service account in the Services tool, using the Log On tab.

   Note

   Exchange Server 2003 services use the LocalSystem account by default. The LocalSystem account is a predefined local account that has extensive privileges on the local computer. This account is only available to system processes and does not have a password.

2. Logs on the service account

   All active processes must have an identity in Windows, and service applications are no exception. When starting a service, SCM uses the account information obtained from the services database and logs on to Windows. On the local computer, the account that SCM uses to log on must have the special user right Log on as a service.

   Note

   The LocalSystem account has the Log on as a service right implicitly, because this account has complete access to all local resources.

3. Creates the service in suspended state

   SCM starts new services in a suspended state, because the service is useful only after SCM adds the required security information to the new process.

4. Assigns the access token to the process

   Every process executed in Windows requires an access token, also referred to as a logon token. The access token is an object that describes the service's security context. The information in the token includes the identity and privileges of the service account that the service uses to interact with the operating system.

5. Allows the process to execute

   After it completes the logon procedure and assigns the access token, SCM can allow the service to run and perform its functions.

SCM performs the following sequential steps when stopping a service:

1. SCM receives a stop request for a service

   A service control program can stop a service using a service control function by sending a SERVICE_CONTROL_STOP request to the service through SCM.

2. SCM examines the service dependencies

   If SCM determines that other services are running that are dependent on the service specified in the stop request, SCM returns an error code to the service control program. Before it triggers the stop procedure, the service control program must enumerate and stop all services that depend on the specified service. For example, the Services tool displays a Stop Other Services dialog box, which asks if you want to stop all dependent services as well. SC.exe, however, simply reports the failure code and states that the service cannot be stopped, because other active services depend on it.

3. SCM forwards the stop request to the service

   If it detects no dependent active services, SCM instructs the specified service to stop by forwarding the stop code to the service. The service must now free its allocated resources and shut down.

Maintaining status information for services that are running

When a service is running, it sends status notifications to the SCM process. SCM maintains this status information in the service record for each service. SCM tracks this information so that it does not mistakenly send control requests that do not conform to the recipient service's current state.

The service status information includes:

• Service Type   A service can be a file system driver, device driver, or a Windows service, and can run its own process or share a process with other services. System Attendant is an example of a service that runs its own process. The SMTP service, however, is a service that shares a process with other services that are integrated with Internet Information Services (IIS).

• Current state   The service state can be starting, running, paused, stopping, or not running.

• Acceptable control codes   Theses are the control codes that the service is able to accept and process in its handler function, according to the current state.

• Windows exit code   The service uses this code to report an error that occurs when it is starting or stopping. To return an error code specific to the service, the service must set this value to ERROR_SERVICE_SPECIFIC_ERROR to indicate that additional information can be found in the service exit code. The service sets this value to NO_ERROR when it is running or stopping properly.

• Service exit code   The service uses this code to report an error when it is starting or stopping. The value is ignored unless the Windows exit code is set to ERROR_SERVICE_SPECIFIC_ERROR.

• Wait hint   The service uses this code to report the estimated time, in milliseconds, required for a pending start, stop, pause, or continue operation.

• Checkpoint   The service uses this value to periodically report its progress during a lengthy start, stop, pause, or continue operation. For example, the Services tool uses this value to track the progress of the service during start and stop operations.

Exchange Services and the LocalSystem Account

Exchange Server 2003 services run under the LocalSystem account. This has the following security implications:

• No extra services account or password changes required   The LocalSystem account (NT AUTHORITY\LocalSystem) always exists and has a random hexadecimal number as the password. This password changes automatically every seven days, so you do not need to create a services account in Active Directory before you install Exchange Server 2003 or change a services password at frequent intervals.

• Full control to all local resources   Because Exchange Server 2003 services have full control over all local resources, these services usually have unrestricted access to the registry database, IIS metabase, and the file system. This is not the case, however, if the special Windows account SYSTEM or the Everyone account is explicitly denied access, which is not recommended. Thus, if Exchange 2003 is installed on a domain controller, Exchange Server 2003 services have full access to Active Directory, because the domain controller hosts a directory replica, and LocalSystem has complete access to local resources.

  Note

  Most security-conscious organizations do not install Exchange Server 2003 on a domain controller, because this installation does not enable separate administration of Exchange Server 2003 and Active Directory.

• LocalSystem enables access to local resources only   When a service runs under the LocalSystem account, it can access only local resources, unless another account is used for network access. Therefore, services that run under LocalSystem use the NetworkService account for network access. The name of the account is NT AUTHORITY\NetworkService. This account does not have a password.

  The NetworkService account corresponds to the computer account of the local computer in the domain. An Exchange service that runs in the security context of the LocalSystem account uses the local computer account credentials when accessing domain resources, such as Active Directory, over the network. Thus, Exchange Server 2003 has substantially fewer privileges on a member server than on a domain controller, because computer accounts by default have very few privileges and do not belong to any groups. The default configuration for computer accounts permits only minimal access to Active Directory.

  To address this issue and grant the computer account the required permissions, Exchange Server 2003 creates the following two special security groups in Active Directory:

  • Exchange Domain Servers   Exchange Domain Servers is a global security group that contains the computer accounts of all servers running Exchange Server in a domain.

  • Exchange Enterprise Servers   Exchange Enterprise Servers is a local security group that contains all global Exchange Domain Servers groups in the forest. This security group grants access to the required resources in the local domain for all Exchange computer accounts.

  Note

  Do not rename or move the Exchange Domain Servers or Exchange Enterprise Servers security groups, and do not remove computer accounts of existing servers running Exchange from these groups.

Examining the Services Database

When you open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services in Registry Editor (Regedit.exe) and examine individual keys for Exchange services, you find that many services that start with MSExchange contain similar values under their service keys. The following table lists these values.

General registry values for Windows services

DependOnGroup

DependOnService

Description

DiagnosticsMessageFile

DisplayName

ErrorControl

FailureActions

Group

ImagePath

ObjectName

Start

Tag

Type

In addition, the following subkeys might exist for Exchange services:

• Diagnostics   This key contains REG_DWORD parameters for possible event log categories that the service provides. The name of the parameters underneath this key is made up of a resource identifier number followed by a string, such as 9 Clean Mailbox. The value associated with each parameter represents the diagnostics logging level for that category. You usually configure these values through the server properties in Exchange System Manager. The Diagnostics Logging tab lists the various categories and assigns the selected values to these parameters.

• Enum   This key contains parameters that SCM uses to enumerate the services in the services database. For example, the REG_SZ parameter 0 contains a value that refers to subkeys under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root registry key. This enables the Windows configuration manager to enumerate the services as logical devices during system boot.

• Parameters   This key contains registry parameters for service-specific configuration information. The Parameters key can contain further subkeys.

• Performance   This key provides counters for performance monitoring. The REG_SZ parameter Library specifies the DLL that contains the performance counters. Further keys exist for the performance counters. For example, the REG_SZ parameter PerfIniFile refers to the .ini file that defines the individual performance counters.

• Security   This key holds a REG_BINARY parameter called Security that contains a service security descriptor that specifies which accounts can control the service. For example, an administrator may have permissions to start and stop a service, while a regular user does not.