Export (0) Print
Expand All

Understanding Windows Services Architecture

 

Topic Last Modified: 2005-05-23

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

ca48e350-ed32-4789-988f-9f28dc0567b6
noteNote:
The SCM process is a remote procedure call (RPC) server service. RPCs enable service control programs to communicate with SCM locally or over the network, in order to control services on remote computers.

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.

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

2c8c4abe-979d-4757-a34b-57339cfc5eca
noteNote:
The names that you can see when working with the Services tool are the display names of Windows services. For example, MSExchangeSA has a display name of Microsoft Exchange System Attendant. The display name is defined in a REG_SZ value named DisplayName that you can find under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service name>.

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.

noteNote:
When administering services that take a very long time to start, remember that you cannot reconfigure startup type or other configuration settings during the service start process, because SCM locks the service database. You can apply configuration changes only before or after you start a service.

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.

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.

    noteNote:
    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.

    noteNote:
    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.

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.

tipTip:
To display the current status for all Windows services, you can use the command sc query state= all type= service.

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.

    noteNote:
    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.

    noteNote:
    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.

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

Value Type Description
DependOnGroup

REG_MULTI_SZ

Lists load-ordering groups on which Windows services depend. Services that depend on a group can run if, after attempting to install all members of a group, at least one member of the group is running.

DependOnService

REG_MULTI_SZ

Lists the names of Windows services on which this service depends. SCM must start these services before it starts this service. This value can be an empty string if the service has no dependencies.

Description

REG_SZ

Describes the service. The description is simply a comment that explains the purpose of the service.

DiagnosticsMessageFile

REG_SZ

Contains the name of the resource DLL that contains the event description strings for those events that the service writes into the application event log. Resource DLLs are located in the \Program Files\Exchsrvr\Res directory.

DisplayName

REG_SZ

Contains the display name that is used to identify the service. This string has a maximum length of 256 characters. The name is case-preserved in SCM. Display name comparisons are always case-insensitive.

ErrorControl

REG_DWORD

Specifies error severity and the action taken if this service fails to start. This parameter determines one of the following:

  • The startup program logs the error but continues the startup operation.

  • The startup program logs the error and displays a message but continues the startup operation.

  • The startup program logs the error. If the "last known good" configuration is started, the startup operation continues. Otherwise, the system is restarted with the "last known good" configuration.

  • The startup program logs the error, if possible. If the "last known good" configuration is started, the system startup is cancelled. Otherwise, the system is restarted with the "last known good" configuration.

FailureActions

REG_BINARY

Cites the action SCM should take for each failure of a service. A service is considered failed when it stops without reporting a status to the service controller (for example, when a service fails).

Group

REG_SZ

Names the load-ordering group of which this service is a member. Note that setting this value can override the setting of the DependOnService value.

ImagePath

REG_EXPAND_SZ

Contains the fully qualified path to the service binary file. If the path contains a space, it must be quoted, so that it is correctly interpreted. For example, "d:\\Program Files\\Exchsvr\\Bin\\mad.exe".

The path can also include program arguments.

ObjectName

REG_SZ

Specifies the name of the account under which the service should run. If the service uses the LocalService account, this parameter is set to NT AUTHORITY\LocalService. It is also possible to specify an account name in the form DomainName\UserName.

Start

REG_DWORD

Specifies when to start the service. SCM can start a service automatically during system startup, or when a process requests the service start. This value can also specify that a service cannot be started and that attempts to start the service should result in the error code ERROR_SERVICE_DISABLED.

Tag

REG_DWORD

Determines the service startup order within a load-ordering group. Tags are only evaluated for driver services.

Type

REG_DWORD

Specifies the service type as file system driver, device driver, a service that runs its own process, or a service that shares a process with one or more other services. MSExchangeSA is an example of a service that runs its own process. EXIFS is an example of an Exchange-specific file system driver.

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.

CautionCaution:
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.
 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft