Exchange Server 2010 Administration Essentials : Using and Managing Exchange Server Services

Working with Exchange Services

To manage Exchange services, you use the Services node in the Computer Management console, which you start by completing the following steps:

1. Choose Start, point to All Programs, point to Administrative Tools, and then select Computer Management. Or, in the Administrative Tools folder, select Computer Management.

2. To connect to a remote Exchange server, right-click the Computer Management entry in the console tree, and then select Connect To Another Computer from the shortcut menu. You can now choose the Exchange server for which you want to manage services.

3. Expand the Services And Applications node, and then select Services.

Figure 1 shows the Services view in the Computer Management console. The key fields of this window are used as follows:

• Name The name of the service.

• Description A short description of the service and its purpose.

• Status The status of the service as started, paused, or stopped. (Stopped is indicated by a blank entry.)

• Startup Type The startup setting for the service.

  Note

  Automatic services are started when the computer is started. Manual services are started by users or other services. Disabled services are turned off and can't be started. To start a disabled service, you must first enable it and then start it.

• Log On As The account the service logs on as. The default, in most cases, is the local system account.

Figure 1. Use the Services node of the Computer Management console to manage Exchange Server services.

Note

On a new Exchange Server 2010 installation, some services are configured for a manual start for security reasons. Specifically, you'll find that the Microsoft Exchange Post Office Protocol version 3 (POP3), Microsoft Exchange Internet Messaging Access Protocol 4 (IMAP4), and Microsoft Search (Exchange) services are configured to start manually. If you use these services with Exchange, you need to configure them for automatic startup and then start them using the techniques discussed in this section.

test-servicehealth

Role: Mailbox Server Role
RequiredServicesRunning : True
ServicesRunning : IISAdmin, MSExchangeADTopology, MSExchangeIS,
MSExchangeMailboxAssistants, MSExchangeMailSubmission, MSExchangeRepl,
MSExchangeRPC, MSExchangeSA, MSExchangeSearch, MSExchangeServiceHost,
MSExchangeThrottling, MSExchangeTransportLogSearch, W3Svc, WinRM}
ServicesNotRunning: {}
Role : Client Access Server Role
RequiredServicesRunning : True
ServicesRunning : {IISAdmin, MSExchangeAB, MSExchangeADTopology,
MSExchangeFBA, MSExchangeFDS, MSExchangeMailboxReplication,
MSExchangeProtectedServiceHost, MSExchangeRPC, MSExchangeServiceHost,
W3Svc, WinRM}
ServicesNotRunning : {}
Role : Hub Transport Server Role
RequiredServicesRunning : True
ServicesRunning         : {IISAdmin, MSExchangeADTopology,
MSExchangeEdgeSync, MSExchangeServiceHost, MSExchangeTransport,
MSExchangeTransportLogSearch, W3Svc, WinRM}
ServicesNotRunning : {}

Configuring Service Startup

Essential Exchange services are configured to start automatically and normally shouldn't be configured with another startup option. That said, if you're troubleshooting a problem, you might want a service to start manually or you might want to temporarily disable a service.

You configure service startup by completing the following steps:

1. In the Computer Management console, connect to the Exchange server for which you want to manage services.

2. Expand the Services And Applications node, and then select Services.

3. Right-click the service you want to configure, and then select Properties.

4. On the General tab, use the Startup Type drop-down list to choose a startup option, as shown in Figure 2. Select Automatic to start a service when the computer starts. Select Manual to allow services to be started manually. Select Disabled to disable the service. Click OK.

Note

The Disabled option doesn't stop the service if it's currently running. It just prevents the service from starting the next time you start the server. To stop the service, you must click Stop.

Figure 2. For troubleshooting, you might want to change the service startup option in the Properties dialog box.

Configuring Service Recovery

You can configure Windows services to take specific actions when a service fails. For example, you can attempt to restart the service or reboot the server. To configure recovery options for a service, follow these steps:

1. In the Computer Management console, connect to the computer for which you want to manage services.

2. Expand the Services And Applications node, and then select Services.

3. Right-click the service you want to configure, and then select Properties.

4. On the Recovery tab, shown in Figure 3, you can configure recovery options for the first, second, and subsequent recovery attempts. The available options are as follows:

   • Take No Action

   • Restart The Service

   • Run A Program

   • Restart The Computer

5. Configure other options based on your previously selected recovery options. If you elected to restart the service, you need to specify the restart delay. After stopping the service, Windows Server waits for the specified delay period before trying to start the service. In most cases, a delay of one to two minutes should be sufficient. Click OK.

Figure 3. By using the Recovery tab in the Properties dialog box, you can configure services to automatically recover in case of failure.

When you configure recovery options for critical services, you might want to try to restart the service on the first and second attempts and then reboot the server on the third attempt. If you notice that a service keeps failing, you need to do some troubleshooting to diagnose and resolve the underlying issue causing the failure.

The Exchange management tools use the Microsoft .NET Framework version 3.5.1, Windows Remote Management (WinRM) 2.0, and Windows PowerShell version 2 for remote management. WinRM is implemented in the Windows Remote Management service, which is also referred to as the WS-Management Service or simply the Management Service. To remotely manage Exchange, your management computer must run this service and be configured to use the transports, ports, and authentication methods that your Exchange servers use. The Exchange server you want to connect to must also run this service. If this service isn't running on your management computer and on the server, remote connections will fail. For remote management, you normally connect to the PowerShell virtual directory configured in IIS on a Client Access server.

By default, the Management Service connects to and listens on TCP port 80 for HTTP connections and on TCP port 443 for Secure HTTP connections. Because firewalls and proxy servers might affect your ability to connect to remote locations over these ports, talk with your company's network or security administrator to determine what steps need to be taken to allow administration over these ports. Typically, the network/security administrator will have to open these TCP ports to allow remote communication between your computer or network and the remote server or network.

The Management Service is preconfigured to share ports with IIS when it runs on the same computer, but it does not depend on IIS. To support remote management, you need to install basic authentication and Windows authentication for IIS on your Exchange servers. These authentication techniques are used when you work remotely.

When you are working with an elevated, administrator command prompt, you can use the WinRM command-line utility to view and manage the remote management configuration. Type winrm get winrm/config to display detailed information about the remote management configuration. As Example 1 shows, this lists the configuration details for every aspect of WinRM.

Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 80
            HTTPS = 443
        TrustedHosts = CorpServer65
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX)
        MaxConcurrentOperations = 4294967295
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 80
            HTTPS = 443
        IPv4Filter = *
        IPv6Filter = *
        CertificateThumbprint
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5

If you examine the listing, you'll notice there is a hierarchy of information. The base of this hierarchy, the Config level, is referenced with the path winrm/config. Then there are sublevels for client, service, and WinRS, referenced as winrm/config/client, winrm/config/service, and winrm/config/winrs, respectively. You can change the value of most configuration parameters by using the following command:

winrm set ConfigPath @{ParameterName="Value"}

where ConfigPath is the configuration path, ParameterName is the name of the parameter you want to work with, and Value sets the value for the parameter, such as

winrm set winrm/config/winrs @{MaxShellsPerUser="4"}

Here, you set the MaxShellsPerUser parameter under WinRM/Config/WinRS. Keep in mind that some parameters are read-only and cannot be set in this way.

WinRM requires at least one listener to indicate the transports and IP addresses on which management requests can be accepted. The transport must be HTTP, HTTPS, or both. With HTTP, messages can be encrypted only using NTLM or Kerberos encryption. With HTTPS, Secure Sockets Layer (SSL) is used for encryption. You can examine the configured listeners by typing winrm enumerate winrm/config/listener. As Example 2 shows, this lists the configuration details for configured listeners.

Listener
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.1.225	

By default, your computer is likely to be configured to listen on any IP address. If so, you won't see any output. To limit WinRM to specific IP addresses, the computer's local loopback address (127.0.01) and assigned IPv4 and IPv6 addresses can be explicitly configured for listening. You can configure a computer to listen for requests on HTTP on all configured IP addresses by typing

winrm create winrm/config/listener?Address=*+Transport=HTTP

You can listen for requests on HTTPS on all IP addresses configured on the computer by typing

winrm create winrm/config/listener?Address=*+Transport=HTTPS

Here, the * indicates all configured IP addresses. Note that the Certificate-Thumbprint property must be empty for the SSL configuration to be shared with another service.

You can enable or disable a listener for a specific IP address by typing

winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP @
{Enabled="true"}

or

winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP @
{Enabled="false"}

You can enable or disable basic authentication on the client by typing

winrm set winrm/config/client/auth @{Basic="true"}

or

winrm set winrm/config/client/auth @{Basic="false"}

You can enable or disable Windows authentication using either NTLM or Kerberos (as appropriate) by typing

winrm set winrm/config/client @{TrustedHosts="<local>"}

or

winrm set winrm/config/client @{TrustedHosts=""}