Exchange Server 2010 : Keep Exchange Healthy (part 2) - Verify Exchange Server Health

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

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:

  1. Click Start => Administrative Tools => Event Viewer.

    This launches the Event Viewer application that is built into Windows.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

    Figure 10. Filtering out everything except for the Exchange logs in Event Viewer
  6. 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:

  1. To determine what component to enable higher logging on and to determine the current logging level, run the following command:


  2. 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*

  3. 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.

Figure 11. Event ID 1003 is logged when the database volume is out of free space.

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
ServiceMailboxClient AccessHub TransportEdge Transport
IIS Admin ServiceYesYesYesNo
Microsoft Exchange Active Directory TopologyYesYesYesNo
Microsoft Exchange ADAMNoNoNoYes
Microsoft Exchange Credential ServiceNoNoNoYes
Microsoft Exchange EdgeSyncNoNoYesNo
Microsoft Exchange Information StoreYesNoNoNo
Microsoft Exchange Mailbox AssistantsYesNoNoNo
Microsoft Exchange Address BookNoYesNoNo
Microsoft Exchange Forms-Based Authentication ServiceNoYesNoNo
Microsoft Exchange File DistributionNoYesNoNo
Microsoft Exchange Mail SubmissionYesNoNoNo
Microsoft Exchange Mailbox ReplicationYesYesNoNo
Microsoft Exchange Protected Service HostNoYesNoNo
Microsoft Exchange RPC Client AccessYesYesNoNo
Microsoft Exchange System AttendantYesNoNoNo
Microsoft Exchange Search IndexerYesNoNoNo
Microsoft Exchange Service HostYesYesYesYes
Microsoft Exchange ThrottlingYesNoNoNo
Microsoft Exchange TransportNoNoYesYes
Microsoft Exchange Transport Log SearchYesNoYesNo
World Wide Web Publishing ServiceYesYesYesNo
Windows Remote ManagementYesYesYesNo

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
Test-ActiveSyncConnectivityTests mobile device connectivity through ActiveSync. The cmdlet attempts to synchronize the mobile device that you specify in the command.
Test-EcpConnectivityTests access to the Exchange Control Panel on a Client Access server that you specify.
Test-EdgeSynchronizationTests the synchronization of Edge Transport servers.
Test-FederationTrustTests the configuration of the federation trust with the Microsoft Federation Gateway.
Test-FederationTrustCertificateTests the certificate used for your federation trust.
Test-ImapConnectivityTests the connectivity of one or more IMAP clients.
Test-IPAllowListProviderTests that the configured IP allow list provider is available and checks an IP address against it.
Test-IPBlockListProviderTests that the configured IP block list provider is available and checks an IP address against it.
Test-IRMConfigurationTests the configuration of Rights Management in Exchange.
Test-MailflowTests whether mail can be sent to and from mailbox servers in the Exchange organization.
Test-MapiConnectivityTests 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-MessageSubmits a test message to the specified recipients. This can be used to test transport rules and have a report generated about the tests.
Test-MRSHealthTests to ensure that the Mailbox Replication Service is running properly.
Test-OutlookConnectivityThoroughly tests the connectivity of Outlook by testing profile creation, AutoDiscover, and mailbox access.
Test-OutlookWebServicesTests that AutoDiscover is returning the correct configuration information for a user and tests each of the service endpoints returned by AutoDiscover.
Test-OwaConnectivityTests that Outlook Web App can be contacted and successfully logged into.
Test-PopConnectivityTests the connectivity of one or more POP clients.
Test-PowerShellConnectivityTests that PowerShell can be used remotely and can successfully issue commands.
Test-ReplicationHealthTests multiple aspects of replication for a server in a DAG.
Test-SenderIdTests sender ID checking against an IP address and domain that you specify.
Test-ServiceHealthTests that the services for each Exchange role installed are running.
Test-SystemHealthTests the overall health of the Exchange server through multiple tests.
Test-WebServicesConnectivityTests 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:

  1. 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.

  2. Run the PS1 script called New-TestCasConnectivityUser.ps1.

  3. 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.

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

  1. 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.

  2. 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.

  3. At the Welcome screen, select the option Select Options For A New Scan.

  4. 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.

  5. 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.

  6. 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.

  7. If you only want to scan specific Exchange servers, you can select those servers from the Specify The Scope For This Scan list.

  8. After you configured your options, click Start Scanning, as shown in Figure 12.

    Figure 12. Configuring the BPA to perform a health check

    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.

  9. After the scan completes, you will be taken to the Scanning Complete screen. Select the option View A Report Of This Best Practices Scan.

  10. View the results of the scan and take any necessary action on reported issues by selecting the option Tell Me More About This Setting.

  •  Programming WCF Services : Queued Services - Instance Management
  •  Programming WCF Services : Queued Services - Transactions
  •  Exchange Server 2010 : Implementing Client Access and Hub Transport Servers - Test Cmdlets for CAS and Hub Transport Servers
  •  Exchange Server 2010 : Implementing Client Access and Hub Transport Servers - Installing the Hub Transport Server
  •  Exchange Server 2010 : Implementing Client Access and Hub Transport Servers - Transport Pipeline
  •  Exchange Server 2010 : Implementing Client Access and Hub Transport Servers - Understanding the Hub Transport Server
  •  Implementing Client Access and Hub Transport Servers : Installing the Client Access Server
  •  Implementing Client Access and Hub Transport Servers : Understanding the Client Access Server (part 2)
  •  Implementing Client Access and Hub Transport Servers : Understanding the Client Access Server (part 1)
  •  SharePoint 2010 : Implementing and Managing In Place Records
    Top 10
    Free Mobile And Desktop Apps For Accessing Restricted Websites
    MASERATI QUATTROPORTE; DIESEL : Lure of Italian limos
    TOYOTA CAMRY 2; 2.5 : Camry now more comely
    KIA SORENTO 2.2CRDi : Fuel-sipping slugger
    How To Setup, Password Protect & Encrypt Wireless Internet Connection
    Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
    Backup & Restore Game Progress From Any Game With SaveGameProgress
    Generate A Facebook Timeline Cover Using A Free App
    New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
    SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
    - Messages forwarded by Outlook rule go nowhere
    - Create and Deploy Windows 7 Image
    - How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
    - Creating and using an unencrypted cookie in ASP.NET
    - Directories
    - Poor Performance on Sharepoint 2010 Server
    - SBS 2008 ~ The e-mail alias already exists...
    - Public to Private IP - DNS Changes
    - Send Email from Winform application
    - How to create a .mdb file from ms sql server database.......
    programming4us programming4us