2. Verify Exchange Server Health
A large part of being
proactive in managing your Exchange environment is knowing where your
servers stand in terms of health. This section discusses various things
that you need to keep an eye on to help ensure that your servers are
healthy.
2.1. Monitor the Event Logs
Event logs in Windows are used
by several components and applications as a place to record critical
alerts and notifications that may be of interest to system
administrators. Exchange Server 2010 also uses the Windows event logs to
record important events. Exchange records most of its events to the
Application log, but you may also see some events recorded elsewhere.
However, the majority of the events that you need to be concerned about
for Exchange will appear in the Application log.
As a part of your
responsibilities as an Exchange Server 2010 administrator, it's vital to
check the event logs on each Exchange server and make sure that you
don't see any undetected problems or other events that could become big
issues in the future. You will primarily want to keep an eye out for any
Warning or Error events, as they indicate problems that the server is
currently having or could have.
2.1.1. View Relevant Events
To view the Application event log, follow these steps:
Click Start => Administrative Tools => Event Viewer.
This launches the Event Viewer application that is built into Windows.
In the Event Viewer Console tree, browse to the Windows Logs => Application node.
The
event logs for Exchange (and other processes) are displayed in the
Results pane. You can search through the log line by line or you can
create a filter.
If
you want to filter out everything except for the Exchange logs, click
the Filter Current Log task in the Actions pane on the right.
In
the Filter Current Log dialog box, select the Critical, Error, and
Warning check boxes. These events will indicate that something is wrong
with Exchange or that something may soon break.
While
still in the Filter Current Log dialog box, click on the drop-down list
for the Event Sources field and select the relevant events that begin
with MSExchange from the list, as shown in Figure 10. Click OK when finished.
Back in the Event Viewer dialog box, you can now view only the events relevant to Exchange.
2.1.2. Specify the Level of Logging Detail
If you find that you need
more detail than what is provided in the Application logs, you can turn
the dial up on what Exchange logs in the Application log. To increase
logging, use the Set-EventLogLevel cmdlet in the EMS. You will need to
specify the category of logs that you want to increase and how much you
want to increase it.
In the following example, we will check and change the log level for the MSExchangeRPC log:
To determine what component to enable higher logging on and to determine the current logging level, run the following command:
Get-EventLogLevel
The
Get-EventLogLevel command displays information about each component.
Use the built-in PowerShell filtering capabilities to narrow down this
list to display only event log categories that have the characters rpc
in the identity:
Get-EventLogLevel *rpc*
To specify a logging level of High for the MSExchangeRPC log, use the following command:
Set-EventLogLevel "MSExchangeSA\RPC Calls" -Level High
2.2. Monitor Disk Space on Database and Log Drives
The amount of free disk
space is an important thing to monitor, particularly on your volumes
that contain the database files or the transaction log files. On Mailbox
servers, when the volume that contains the database gets full the
database will be dismounted, which prevents users from accessing their
mailboxes on that database. Dismounting the database is how Exchange
protects the integrity of the data, as it cannot write additional data
to the database if there is no space to do so. The database is
dismounted when there is 2 MB of disk space left on the volume.
When the database is
dismounted due to the disk being full, Exchange will log an event in the
Application log with event ID 1003, as shown in Figure 11.
Before the database can be mounted again, you must free up some space on the volume. There are multiple ways to reclaim space:
Back up the server and allow the transaction logs to truncate.
Back up the server and permanently delete any mailboxes that may be stored in deleted mailbox retention.
Perform an offline defragmentation of the database using the ESEUTIL /D command. This may take some time to complete.
If you're using a SAN-based volume, you can grow the size of the LUN that is presented to the Exchange server.
Back up any extraneous data or personal files and delete them or move them to a more appropriate server.
Move any transaction logs that have already been committed to another volume.
On Transport servers,
when the disk that contains the message queue database and logs nears
capacity, Exchange applies back pressure, which instructs Exchange to
stop accepting new connections and potentially stops all message flow.
By default, the Transport servers require at least 500 MB of disk space
free on the volumes that contain the queue database and logs, so you
should monitor the free disk space on those locations.
If you get into the situation
of being low on disk space on your Transport server and back pressure is
being applied, alleviate the problem using one of the following
methods:
Free up disk space on the Transport server by removing extraneous data.
Move the queue database and logs to a separate volume with more space available.
Modify the threshold numbers used to determine when to apply back pressure.
When back pressure is applied
or relinquished, the Transport servers will log events in the
Application log with event IDs of 15004 and 15005. You can monitor the
Application log for these events on your Transport servers to indicate
that back pressure is being applied.
2.3. Ensure That Services Are Running
The various components of
Exchange run as services in Windows. Not all of the services need to be
running in order for Exchange to be functional, however. Certain
services may only need to be started if Exchange is using a feature that
relies on services, such as POP or IMAP. In fact, one of the best
practices in hardening servers is to disable services that you are not
required to run.
There are core services
that need to be running in Exchange in order for an Exchange server in a
particular role to function correctly. You should monitor these
services to ensure that they are running. Many problems are attributable
to a service that has stopped running for one reason or another. If you
know when a critical service stops, you can respond rapidly to get the
problem resolved.
Table 3 lists the services that Exchange Server 2010 uses and identifies which services are critical for each role.
Table 3. Critical Services That Need to Remain Running for Each Role
| Service | Mailbox | Client Access | Hub Transport | Edge Transport |
|---|
| IIS Admin Service | Yes | Yes | Yes | No |
| Microsoft Exchange Active Directory Topology | Yes | Yes | Yes | No |
| Microsoft Exchange ADAM | No | No | No | Yes |
| Microsoft Exchange Credential Service | No | No | No | Yes |
| Microsoft Exchange EdgeSync | No | No | Yes | No |
| Microsoft Exchange Information Store | Yes | No | No | No |
| Microsoft Exchange Mailbox Assistants | Yes | No | No | No |
| Microsoft Exchange Address Book | No | Yes | No | No |
| Microsoft Exchange Forms-Based Authentication Service | No | Yes | No | No |
| Microsoft Exchange File Distribution | No | Yes | No | No |
| Microsoft Exchange Mail Submission | Yes | No | No | No |
| Microsoft Exchange Mailbox Replication | Yes | Yes | No | No |
| Microsoft Exchange Protected Service Host | No | Yes | No | No |
| Microsoft Exchange RPC Client Access | Yes | Yes | No | No |
| Microsoft Exchange System Attendant | Yes | No | No | No |
| Microsoft Exchange Search Indexer | Yes | No | No | No |
| Microsoft Exchange Service Host | Yes | Yes | Yes | Yes |
| Microsoft Exchange Throttling | Yes | No | No | No |
| Microsoft Exchange Transport | No | No | Yes | Yes |
| Microsoft Exchange Transport Log Search | Yes | No | Yes | No |
| World Wide Web Publishing Service | Yes | Yes | Yes | No |
| Windows Remote Management | Yes | Yes | Yes | No |
To determine if the required services for each role are running, you can execute the Test-ServiceHealth cmdlet in the EMS. You do not need to include any parameters.
The Test-ServiceHealth
cmdlet will return the list of roles that are running on the Exchange
server along with a list of the services for those roles. The cmdlet
identifies the services that are running as well as the services that
are not running but should be.
The following output
demonstrates what is returned by the command when the Mail Submission
service is stopped on a Mailbox server:
Role : Mailbox Server Role
RequiredServicesRunning : False
ServicesRunning : {IISAdmin, MSExchangeADTopology,
MSExchangeIS, MSExchangeMailbox
Assistants, MSExchangeRepl, MSEx
changeRPC, MSExchangeSA, MSExchange
Search, MSExchangeServiceHost, MS
ExchangeThrottling, MSExchange
TransportLogSearch, W3Svc, WinRM}
ServicesNotRunning : {MSExchangeMailSubmission}
2.4. Use the Test Cmdlets in the Exchange Management Shell
Exchange Server
2010 provides several cmdlets in the Exchange Management Shell that are
focused on testing the functionality and configuration of Exchange. The
list of test cmdlets has grown in comparison to those available with
Exchange Server 2007, and there are several useful ones that can make
your job as an Exchange administrator a lot easier. Table 4
describes the available test cmdlets. You may have seen some of these
cmdlets used throughout this book when working with certain aspects of
Exchange.
Table 4. The Test-* Cmdlets in Exchange Server 2010
| Cmdlet | Description |
|---|
| Test-ActiveSyncConnectivity | Tests
mobile device connectivity through ActiveSync. The cmdlet attempts to
synchronize the mobile device that you specify in the command. |
| Test-EcpConnectivity | Tests access to the Exchange Control Panel on a Client Access server that you specify. |
| Test-EdgeSynchronization | Tests the synchronization of Edge Transport servers. |
| Test-FederationTrust | Tests the configuration of the federation trust with the Microsoft Federation Gateway. |
| Test-FederationTrustCertificate | Tests the certificate used for your federation trust. |
| Test-ImapConnectivity | Tests the connectivity of one or more IMAP clients. |
| Test-IPAllowListProvider | Tests that the configured IP allow list provider is available and checks an IP address against it. |
| Test-IPBlockListProvider | Tests that the configured IP block list provider is available and checks an IP address against it. |
| Test-IRMConfiguration | Tests the configuration of Rights Management in Exchange. |
| Test-Mailflow | Tests whether mail can be sent to and from mailbox servers in the Exchange organization. |
| Test-MapiConnectivity | Tests
that a mailbox can be logged into. If run against a database, it tests
that the system mailbox for the database can be logged into. |
| Test-Message | Submits
a test message to the specified recipients. This can be used to test
transport rules and have a report generated about the tests. |
| Test-MRSHealth | Tests to ensure that the Mailbox Replication Service is running properly. |
| Test-OutlookConnectivity | Thoroughly tests the connectivity of Outlook by testing profile creation, AutoDiscover, and mailbox access. |
| Test-OutlookWebServices | Tests
that AutoDiscover is returning the correct configuration information
for a user and tests each of the service endpoints returned by
AutoDiscover. |
| Test-OwaConnectivity | Tests that Outlook Web App can be contacted and successfully logged into. |
| Test-PopConnectivity | Tests the connectivity of one or more POP clients. |
| Test-PowerShellConnectivity | Tests that PowerShell can be used remotely and can successfully issue commands. |
| Test-ReplicationHealth | Tests multiple aspects of replication for a server in a DAG. |
| Test-SenderId | Tests sender ID checking against an IP address and domain that you specify. |
| Test-ServiceHealth | Tests that the services for each Exchange role installed are running. |
| Test-SystemHealth | Tests the overall health of the Exchange server through multiple tests. |
| Test-WebServicesConnectivity | Tests the functionality of Exchange Web Services through the use of Outlook Anywhere. |
|
The test cmdlets don't need
to always be run on demand. You can choose a few of them that you want
to run on a regular basis and create scheduled tasks out of them.
|
|
When running some of these
test cmdlets, you may be required to have a specific test account
created beforehand. To create this account, use the following steps:
Open the EMS and browse to the Scripts folder in the location where Exchange is installed. By default, this location is C:\Program Files\Microsoft\Exchange Server\v14\Scripts.
Run the PS1 script called New-TestCasConnectivityUser.ps1.
When
prompted for a password, type a temporary password and press Enter.
This password is just used for the creation of the test account and you
will therefore not need to remember this password.
When prompted to continue creating the test user, press Enter.
The
test user is automatically created. When the test account is finished,
the script will end and you will be returned to the EMS command prompt.
3. Use the Exchange Best Practices Analyzer
The Exchange Best
Practices Analyzer (ExBPA) is a powerful tool in the Exchange
administrator's toolbox that should be run on a regular basis. The ExBPA
can perform a variety of tests that help ensure the health of your
Exchange organization. In this section, I will show you how to run a
health check.
The ExBPA health
check component performs a variety of tests against your Exchange
servers and presents the results in an easy-to-read report. When
reviewing the report, you will be presented with the critical issues
encountered and given the opportunity to read more about why the issue
was detected and how to correct it.
To perform a health check with the ExBPA, use the following steps:
Open
the Exchange Best Practices Analyzer. You can do this by opening the
EMC and browsing to the Toolbox node in the Console tree. Under the
Configuration Management Tools portion of the Toolbox, double-click on
Best Practices Analyzer.
If
this is the first time you are running the BPA, you will be presented
with a welcome screen. Decide whether you want to join the Microsoft
Customer Experience Improvement Program and then click Go To The Welcome
Screen.
At the Welcome screen, select the option Select Options For A New Scan.
On
the Connect To Active Directory screen, type the name of the domain
controller you want to connect to and click Connect To The Active
Directory Server.
If
you want to use different credentials than what you are currently
logged in as for communication with Active Directory, click Show
Advanced Login Options and enter the credentials that you want to use.
Your connectivity and access permissions are verified before continuing.
On
the Start A New Best Practices Scan screen, enter a name for the scan
and select Health Check from the list of scans to perform.
If you only want to scan specific Exchange servers, you can select those servers from the Specify The Scope For This Scan list.
After you configured your options, click Start Scanning, as shown in Figure 12.
On the Scanning In
Progress screen, the scan is performed. The amount of time that the scan
takes to complete will vary depending on how many servers you are
scanning and the speed of your network.
After
the scan completes, you will be taken to the Scanning Complete screen.
Select the option View A Report Of This Best Practices Scan.
View
the results of the scan and take any necessary action on reported
issues by selecting the option Tell Me More About This Setting.
