Monitoring Exchange Server 2010

Lesson 1: Monitoring Exchange Databases

Database monitoring involves regularly checking the health of your databases. Typically, your monitoring procedures are complemented by a notification system that sends alerts to administrators when problems occur. You can use the Exchange Management Console (EMC) and the Exchange Management Shell (EMS) to obtain database information and statistics. Additional tools, such as Microsoft Operations Manager, can also assist in monitoring your Exchange organization, but this chapter concentrates on the facilities provided directly by Microsoft Exchange Server 2010.

Microsoft recommends monitoring your databases on a daily basis. The main advantages to daily monitoring are as follows:

• You can quickly detect and address issues that may affect the messaging service or data availability.

• You can ensure the successful completion of specific administrative tasks, such as daily backup operations.

• It helps you meet the requirements of your Service Level Agreements.

In this lesson, you consider how you monitor public folder and mailbox database statistics to detect anomalies and indications of current and future problems and how you check the status of an Exchange Server 2010 database. You also consider how you monitor status information about mailbox database copies included in a database availability group (DAG).

Monitoring Exchange Database Information and Statistics

In order to check the health of your Exchange databases and of the replication process (if configured), you need to monitor your databases. You can obtain general information about both public folder and mailbox databases and statistics related to the public folders and mailboxes they contain. You can obtain more specific information about mailboxes and mailbox databases, such as usage information, information about queues, information about lagged mailbox database copies, and information about disconnected mailboxes.

Obtaining Information about Mailbox Databases

When you are monitoring a mailbox database you first need to obtain general information about the database, such as the server where it is located, its mailbox retention period, deleted item retention period, quota limits, associated public folder database, and so on. You can use the Get-MailboxDatabase cmdlet to obtain general information for mailbox databases. For example, the following command returns detailed information about all the mailbox databases in an Exchange 2010 organization:

Get-MailboxDatabase | FL

The previous command typically returns a lot of information that you would likely redirect into a text file for analysis. In a large organization that has a lot of databases, this command returns an excessive volume of information. You have the option of refining this information by specifying the Mailbox server, the mailbox database identity, or both. For example, the following command returns detailed information about the mailbox database named Mailbox Database 1363123687:

Get-MailboxDatabase -Identity "Mailbox Database 1363123687" | FL

Figure 9-1 shows some of the output from this command.

The transport dumpster is described in Chapter 8, “Configuring Transport Servers.” You can obtain statistics (if available) about the transport dumpster, such as dumpster deletes per second, dumpster inserts per second, and dumpster item count by including the DumpsterStatistics parameter, as demonstrated by the following command:

Get-MailboxDatabase -Identity "Mailbox Database 1363123687" -DumpsterStatistics | FL

You can also determine the status of the mailbox database, if this is available, by including the Status parameter. This tells you whether the status of the mailbox database is one of the following: BackupInProgress, Mounted, or OnlineMaintenanceInProgress. It also tells you the available free space in the database root. Checking the status of mailbox databases is an important step in monitoring replication health. The following command uses the Status parameter:

Get-MailboxDatabase -Identity "Mailbox Database 1363123687" -Status | FL

You can also use the EMC to determine the properties of a mailbox database. The procedure is as follows:

1. On your Mailbox server, open the EMC.

2. Click Mailbox under Organization Configuration in the Console tree.

3. In the Result pane, click the Database Management tab and then click the mailbox database whose status you want to determine.

4. Click Properties in the Actions pane.

The tabs on a mailbox database Properties dialog box are General, Maintenance, Limits, and Client Settings, as shown in Figure 9-2. The information available on these tabs was discussed in detail in Chapter 2, “Exchange Databases and Address Lists.”

Viewing Mailbox Statistics

You can use the Get-MailboxStatistics EMS cmdlet to view the statistics for all the mailboxes on a server, for all the mailboxes in a mailbox database, or for a single mailbox. Note that you cannot use the cmdlet without arguments to view the statistics for all mailboxes in an Exchange organization. The cmdlet requires the Server, the Database, or the Identity parameter.

For example, the following command lists the statistics for all the mailboxes on the VAN-EX1 Mailbox server:

Get-MailboxStatistics -Server VAN-EX1 | FL

The following command lists the statistics for all the mailboxes in the mailbox database Mailbox Database 1363123687:

Get-MailboxStatistics -Database "Mailbox Database 1363123687" | FL

Figure 9-3 shows the output from this command.

If a user mailbox has been created but has never been accessed, that mailbox is not included when you list the statistics of mailboxes on a server or in a mailbox database. If you attempt to obtain statistics for a mailbox that has not been accessed, you will get no statistical information but will instead receive a warning message. Suppose, for example, that the Don Hall mailbox has never been accessed and you enter the following command:

Get-MailboxStatistics -Identity "Don Hall" | FL

This results in the message shown in Figure 9-4.

If a mailbox returns statistics, you can use the PowerShell format-list (FL) cmdlet to display the value of one or more specified statistics. This is more convenient than searching through the list of all the statistical values. For example, the following command displays the last logon time for the Kim Akers mailbox:

Get-MailboxStatistics -Identity "Kim Akers" | FL LastLogonTime

You can use the Sort-Object PowerShell cmdlet to sort the mailboxes in a mailbox database or on a Mailbox server by the value of one or more mailbox statistics. You can do this in either descending or ascending order and use the format-table (FT) PowerShell cmdlet to display the results as a table. For example, the following command lists the mailboxes in the Research mailbox database in descending order of item count:

Get-MailboxStatistics -Database Research | Sort-Object ItemCount -Descending | FT
DisplayName,ItemCount

The following command lists the mailboxes in the Research mailbox database in descending order of total item size:

Get-MailboxStatistics -Database Research | Sort-Object TotalItemSize -Descending | FT
DisplayName,TotalItemSize

If you do not want to list all the mailboxes in a mailbox database or on a Mailbox server but instead want to list, for example, the top five mailboxes in terms of total item size, you can pipe the results of your search into the Select-Object PowerShell cmdlet. For example, the following command lists the top five mailboxes in Mailbox Database 1363123687 in descending order of total item size:

Get-MailboxStatistics -Database "Mailbox Database 1363123687" | Sort-Object
TotalItemSize -Descending | Select-Object -First 5 | FT DisplayName,TotalItemSize

The following command lists the top 10 mailboxes on the Mailbox server VAN-EX1 in descending order of item count:

Get-MailboxStatistics -Server VAN-EX1 | Sort-Object ItemCount -Descending | Select-
Object -First 10 | FT DisplayName,ItemCount

Monitoring Resource Usage

Sometimes pressure on a mailbox database can be the result of certain users consuming a disproportionate amount of resources, such as by sending an excessive number of large attachments to a large number of recipients. To detect this situation, you can use the Get-StoreUsageStatistics EMS cmdlet to generate a report on the 25 accounts that are using the greatest amount of resources within a mailbox database. For example, the following command returns the 25 users with the largest mailboxes in Mailbox Database 1363123687:

Get-StoreUsageStatistics -Database "Mailbox Database 1363123687"

You can also use the Get-StoreUsageStatistics cmdlet to obtain statistics about a specific mailbox, but only if this mailbox account is one of the 25 top resource users. Under these circumstances, the following command would generate a report about the Kim Akers account:

Get-StoreUsageStatistics -Identity "Kim Akers"

Using Performance Monitor Counters

You can use the Exchange Server Performance Monitor tool to monitor counters that can indicate whether resources in your Exchange organization are coming under stress. This is the same tool as Performance Monitor (PerfMon) except that the Performance and Logs Alerts snap-in has been prepopulated with a large number of Exchange-related performance counters. You can access Exchange Server Performance Monitor from the EMC by clicking the Toolbox node, clicking Performance Monitor, and clicking Open Tool.

As an experienced administrator, you should have used PerfMon on both server and client operating systems to monitor current performance, create data records, and generate reports. The tool provided by Exchange Server 2010 works in the same way, but you have the option of monitoring performance counters specific to Exchange. More than 100 MSExchange countergroups exist, each one of which offers a significant number of counters.

You are not expected to be familiar with every counter that populates the Exchange Server PerfMon. It is probable that no single person could list and describe all of them. Nor can you be expected to know the acceptable values that every counter returns. Although some countervalues exist that definitely indicate a fault while other values indicate that a process is operating in a satisfactory manner, absolute good or bad values are not typical. If you want to use PerfMon counters to monitor performance, you would normally record baseline counter values when your Exchange organization is working in a satisfactory manner—possibly during a quiet period, under normal conditions, and during busy times. Recording values on a regular basis under the same conditions and comparing these to baseline values would indicate whether performance is deteriorating over time and help you track trends.

For example, to ensure that your mailbox databases continue to operate efficiently, you need to check that they are being defragmented online on an ongoing basis. Online defragmentation is a background task that operates continuously by default. Exchange Server 2010 provides the following performance counters for monitoring the behavior of online database defragmentation:

• MSExchange Database → Online Defrag Average Log Bytes Shows average size of the log records being generated by online defragmentation

• MSExchange Database → Online Defrag Data Moves/Sec Shows the number of times that data is moved from one page to another by the online defragmentation process

• MSExchange Database → Online Defrag Log Records/Sec Shows the number of times per second that data is moved from one page to another by the online defragmentation process

• MSExchange Database → Online Defrag Page Moves/Sec Shows the number of times that data is moved from one page to a new page by the online defragmentation process

• MSExchange Database → Online Defrag Pages Dirtied/Sec Shows the rate at which online defragmentation is modifying clean database pages

• MSExchange Database → Online Defrag Pages Freed/Sec Shows the number of pages per second that are freed from the database by the online defragmentation process

• MSExchange Database → Online Defrag Pages Preread/Sec Shows the rate at which database pages are read in anticipation of future use by online defragmentation

• MSExchange Database → Online Defrag Pages Read/Sec Shows the rate of database read operations being performed by online defragmentation

• MSExchange Database → Online Defrag Pages Re-Dirtied/Sec Shows the rate at which online defragmentation is modifying database pages that already contained modifications

• MSExchange Database → Online Defrag Pages Referenced/Sec Shows the rate at which online defragmentation is touching database pages

Obtaining Information about Public Folder Databases

When you are monitoring a public folder database, you first need to obtain general information about the database, such as the server where it is located, what public folders it contains, its maximum item size, quota limits, replication schedule, and so on. You can use EMS commands based on the Get-PublicFolderDatabase cmdlet for this purpose. For example, the following command gets detailed information about every public folder database in an organization:

Get-PublicFolderDatabase | FL

Figure 9-5 shows some of the output from this command.

If you want to obtain detailed information about a specific public folder database, you can specify the Exchange Server 2010 Mailbox server on which it is located. For example, the following command gets detailed information about the public folder database on the VAN-EX1 server.

Get-PublicFolderDatabase -Server VAN-EX1 | FL

It is typically easier to analyze and store this information if the output of the command is redirected to a text file. For example, the following command redirects detailed information about the public folder database on the VAN-EX1 server to the text file PublicFolderDetails .txt in the DatabaseInformation folder on the VAN-EX1 server:

Get-PublicFolderDatabase -Server VAN-EX1 | FL >
C:\DatabaseInformation\PublicFolderDetails.txt

You can use the Status parameter of the Get-PublicFolderDatabase cmdlet to obtain backup and mount status information (if available). Checking the status of public folder databases is an important step in monitoring replication health. The following command gets detailed information about the public folder database on the VAN-EX1 server, including status information:

Get-PublicFolderDatabase -Server VAN-EX1 -Status | FL

You can use the EMC to obtain information about a public folder database. This information, such as database path, status, maintenance schedule, replication interval, storage limits, public folder referral information, and so on, is the same as that returned by EMS commands based on the Get-PublicFolderDatabase cmdlet. It does not tell you about database usage or the size and number of the public folders within the database.

The procedure to view public folder database properties is very similar to that for viewing mailbox database properties described earlier in this lesson. The procedure is as follows:

1. On your Mailbox server, open the EMC.

2. Click Mailbox under Organization Configuration in the Console tree.

3. In the Result pane, click the Database Management tab and then click the public folder database whose status you want to determine.

4. Click Properties in the Actions pane.

5. The General, Replication, Limits, and Public Folder Referral tabs of the public folder database Properties dialog box, shown in Figure 9-6, show the properties of the public folder database.

Viewing Public Folder Statistics

No EMS cmdlet exists that returns the statistics for an entire public folder database. However, you can use the Get-PublicFolderStatistics EMS cmdlet to obtain statistics for each individual public folder within a public folder database. You would, for example, obtain public folder statistics if you had created a new public folder database on another Mailbox server and you wanted to replicate a public folder on your current server to the new public folder database.

You can check replication by ensuring that, for example, the number and size of items in the public folder replica are the same as in the original public folder. You could use the same procedure if you replicate an entire public folder database and want to check that replication is working correctly.

The following command obtains statistics for every public folder in an Exchange 2010 organization:

Get-PublicFolderStatistics | FL

The previous command can return an excessive volume of information, particularly if you have a large number of public folders. As with mailbox databases, you can refine the information. If, for example, you want to obtain statistics for every public folder in the public folder database on the Mailbox server VAN-EX1, you would enter the following command:

Get-PublicFolderStatistics -Server VAN-EX1 | FL

If you want to obtain statistics for the public folder MyPublicFolder on the Mailbox server VAN-EX1, you would enter the following command:

Get-PublicFolderStatistics -Identity \MyPublicFolder -Server VAN-EX1 | FL

Figure 9-7 shows the output from this command. Note that this command runs only if you have previously created a public folder named MyPublicFolder as a child of the public folder root.

Detecting Database Errors

Database corruption occurs, for example, when the Exchange Server Database (EDB) file is damaged during improper server shut down, through virus infection, or because of physical damage to the storage media. If an entire Exchange database becomes corrupt, the ESE writes error messages to Event Viewer, such as “Unable to read database header—database may have moved, or data was moved or was missing during recovery” or “Database page read failed verification because of a 1018 error (page checksum mismatch).” You can use tools such as Eseutil and Isinteg to repair a corrupt database or to fix database integrity problems. However, Microsoft recommends restoring a corrupt database from backup because the use of a tool such as Eseutil can lead to data loss. Chapter 14, “Exchange Disaster Recovery,” discusses repairing a corrupt database.

Sometimes a database is not itself corrupt but holds items such as email messages, which are. Corrupt email messages can cause problems with mail flow and lead to excessive queuing. If you move an Exchange database to another server or copy its contents to a new database, corrupt messages do not move or copy. You can then delete such messages, typically with a non-delivery report (NDR).

Monitoring DAGs

A DAG is a set of up to 16 Exchange Server 2010 Mailbox servers that provide automatic database-level recovery from the failure of a database, server, or network. DAGs use continuous replication and Windows failover clustering technologies to provide continuous mailbox availability. Mailbox servers in a DAG monitor each other for failures. When a Mailbox server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database failures. Chapter 13, “Exchange High-Availability Solutions,” discusses DAGs in detail. This lesson briefly discusses how you monitor the status information about mailbox database copies included in a DAG.

Exchange 2010 provides several built-in tools and features that are used for regular proactive monitoring when the Exchange organization is configured for high availability or site resilience through the creation of DAGs. The primary tools for monitoring mailbox database copies included in DAGs are the EMS cmdlets Get-MailboxDatabaseCopyStatus and Test-ReplicationHealth.

Exchange Server 2010 also introduces a new event log stream that uses the crimson channel capabilities in Windows Server 2008 and Windows Server 2008 R2 and built-in scripts that can collect data from these event channels.

Crimson Channel Event Logging

Applications and Services logs is a new category of event logs in Windows Server 2008 and Windows Server 2008 R2. Logs in this category store events from a single application or component rather than events that have systemwide impact. The Applications and Services logs category includes four subtypes: Admin, Operational, Analytic, and Debug logs.

Typically, you would use event log records in the Admin logs subtype to troubleshoot problems. These events typically provide guidance about what action you should take when the event is logged. Events in the Operational log require more interpretation. Analytic logs (hidden and disabled by default) store events that trace an issue and, if enabled, typically log a high volume of events. Developers use Debug logs when debugging applications.

An application’s crimson channel contains event logs in the Applications and Services category that are specific to that particular application. Exchange Server 2010 has two crimson channels: HighAvailability and MailboxDatabaseFailureItems. To view Exchange Server 2010 crimson channel event logs, carry out the following steps on the Exchange server:

1. Open Event Viewer in the Administrative Tools menu.

2. Expand Applications and Services Logs in the Console tree. Expand Microsoft. Expand Exchange.

3. You should see two crimson channels under Exchange: High Availability and MailboxDatabaseFailureItems. Expand High Availability. This gives you access to the Debug and Operational logs. Figure 9-8 shows the Operational log.

4. Expand MailboxDatabaseFailureItems. This gives you access to the Operational log, shown in Figure 9-9.

The MailboxDatabaseFailureItems channel logs events (including failure events) that affect a replicated mailbox database.

The High Availability channel contains events related to startup and shutdown of the Microsoft Exchange Replication service and the components that run within that service, such as Active Manager, the Third Party Synchronous Replication Application Program Interface (API), the Tasks Remote Procedure Call (RPC) Server, Tcp Listener, and Volume Shadow Copy Service writer. Active Manager uses this channel to log events related to Active Manager role monitoring and database action events, such as a database mount operation and log truncation, and to record events related to the DAG’s underlying cluster.

Obtaining the Status of Mailbox Database Copies

When you are investigating the condition of your mailbox database copies, you typically need to determine whether the status of a particular database copy is, for example, failed or healthy. You can use the Get-MailboxDatabaseCopyStatus EMS cmdlet to view status information about mailbox database copies. This lets you obtain information about all copies of a database, information about a specific copy of a database on a specific server, or information about all database copies on a specific server.

For example, the following command returns status information for all copies of a mailbox database copy named MyMailboxDatabase in an Exchange Server 2010 organization:

Get-MailboxDatabaseCopyStatus -Identity MyMailboxDatabase | FL

Note that commands based on the Get-MailboxDatabaseCopyStatus cmdlet also return information about mailbox databases on a server if mailbox database copies are not implemented. However, the status information for a mailbox database returns fewer possible values than that for a mailbox database copy. For example, a mailbox database that is not a copy cannot have the status “seeding.”

The following command returns the status for all mailbox database copies (and mailbox databases) on a Mailbox server named VAN-EX1:

Get-MailboxDatabaseCopyStatus -Server VAN-EX1 | FL

Figure 9-10 shows some of the output of this command.

The following command returns the status for all mailbox database copies on the Mailbox server on which the command is entered:

Get-MailboxDatabaseCopyStatus -Local | FL

The following command returns the status and log shipping and seeding network information for a mailbox database copy named MyMailboxDatabase on a Mailbox server named VAN-EX1 (log shipping and seeding information for a mailbox database copy are discussed in detail in Chapter 13):

Get-MailboxDatabaseCopyStatus -Identity MyMailboxDatabase\VAN-EX1 -ConnectionStatus | FL

Table 9-1 lists and describes possible values for the copy status of a mailbox database copy.

Table 9-1 Mailbox database copy status

COPY STATUS	DESCRIPTION
ActivationSuspended	An administrator has manually blocked the mailbox database copy from activation.
DisconnectedAndHealthy	The mailbox database copy is no longer connected to the active database copy and was in the Healthy state when the loss of connection occurred. This status represents the database copy’s view of connectivity to its source database copy. It may be reported during DAG network failures between the source copy and the target database copy.
DisconnectedAndResynchronizing	The mailbox database copy is no longer connected to the active database copy and was in the Resynchronizing state when the loss of connection occurred. This status represents the database copy’s view of connectivity to its source database copy. It may be reported during DAG network failures between the source copy and the target database copy.
Dismounted	Only the active copy of a mailbox database copy can have a copy status of Dismounted. In this state, the active copy is offline and not accepting client connections.
Dismounting	Only the active copy of a mailbox database copy can have a copy status of Dismounting. In this state, the active copy is going offline and terminating client connections.
Failed	The mailbox database copy is in a Failed state and cannot copy or replay log files. While the database copy is in a failed state and not suspended, the system will periodically check to see if the problem that caused the failed copy status has been resolved. If the system detects that the problem has been resolved and no other issues are causing the database copy to fail, the copy status automatically changes to Healthy.
FailedAndSuspended	The Failed and Suspended states have been set simultaneously by the system because a failure was detected, the resolution of which explicitly requires administrator intervention, such as if the system detects unrecoverable divergence between the active mailbox database and a database copy. Unlike when the mailbox database copy status is Failed, the system does not periodically check to see if the problem has been resolved. Instead, an administrator must intervene to resolve the underlying cause of the failure before the mailbox database copy can be transitioned to a Healthy state.
Healthy	The mailbox database copy is successfully copying and replaying log files, or it has successfully copied and replayed all available log files.
Initializing	The mailbox database copy status is set as Initializing when a new database copy has been created, when the Microsoft Exchange Replication service is starting up or has just been started, and during transitions from Suspended, ServiceDown, Failed, Seeding, SinglePageRestore, LostWrite, or Disconnected to another status. While a mailbox database copy is set to the Initializing status, the system is verifying that the database and log stream are in a consistent state. In most cases, the Initializing mailbox database copy status will last for about 15 seconds, but in all cases, this status should not last for more than 30 seconds.
Mounted	Only the active copy of a mailbox database copy can have a copy status of Mounted. In this state, the active copy is online and accepting client connections.
Mounting	Only the active copy of a mailbox database copy can have a copy status of Mounting. In this state, the active copy is coming online and not yet accepting client connections.
Resynchronizing	The mailbox database copy and its log files are being compared with the active copy of the database to check for any divergence between the two copies. The mailbox database copy status will remain as Resynchronizing until any divergence is detected and resolved.
Seeding	The mailbox database copy is being seeded, the content index for the mailbox database copy is being seeded, or both. After seeding has successfully completed, the copy status changes to Initializing.
SeedingSource	In Exchange Server 2010, any healthy database or database copy can be used as the seeding source for an additional copy of that database. When a database is being used as a seeding source, its copy status is SeedingSource.
ServiceDown	The Microsoft Exchange Replication service is not running on the server that hosts the mailbox database copy.
SinglePageRestore	A single page restore operation is occurring on the mailbox database copy.
Suspended	The mailbox database copy is in a Suspended state. You can manually suspend a database copy by entering a command based on the SuspendMailboxDatabaseCopy EMS cmdlet.

Viewing the Continuous Replication Status of Mailbox Database Copies

If you need to check all aspects of the replication and replay status of mailbox database copies and obtain a complete overview of replication on a specific Mailbox server in a DAG, you can use commands based on the Test-ReplicationHealth EMS cmdlet. This functionality implements proactive monitoring of continuous replication and the continuous replication pipeline. It indicates the availability of Active Manager and the health and status of the underlying cluster service, quorum, and network components. You can run the commands locally on or remotely against any Mailbox server in a DAG.

For example, the following tests replication health for the Mailbox server VAN-EX1:

Test-ReplicationHealth -Identity VAN-EX1 | FL

Figure 9-11 shows the output from this command.

The Test-ReplicationHealth cmdlet supports the OutputObjects parameter, which enables a command that uses this cmdlet to output an array of information regarding failures. The information returned can include the following:

• ServerName The server on which a failure occurs

• CheckID A unique identifier for every check performed

• CheckTitle The title of the check that was run

• InstanceIdentity A unique string identifying the instance that failed (for example, a database Global Unique Identifier [GUID])

• DbFailureEventID The Event identity (ID) of the failure event logged by the Microsoft Exchange Replication Service for a database copy that is in a Failed state

• CheckResult A check result (for example, pass, fail, or warning)

• ErrorMessage A failure message logged by the check for the specific failure instance

For example, the following command tests replication health on server VAN-EX1 and returns failure information:

Test-ReplicationHealth -Identity VAN-EX1 -OutputObjects | FL

Figure 9-12 shows the output from this command. Note that if no failure has occurred, then no failure information is recorded.

Table 9-2 lists and describes the tests you can perform by using the Test-ReplicationHealth cmdlet.

Table 9-2 Continuous replication status tests

TEST	DESCRIPTION
ActiveManager	Verifies that the instance of Active Manager running on the specified DAG member (or, if no DAG member is specified, on the local server) is in a valid role (Primary, Secondary, or Standalone).
ClusterNetwork	Verifies that all cluster-managed networks on the specified DAG member (or, if no DAG member is specified, on the local server) are available.
ClusterService	Verifies that the Cluster service is running and can be reached on the specified DAG member. If no DAG member is specified, this tests if the service is reachable on the local server.
DagMembersUp	Verifies that all DAG members are up and running and reachable.
DBCopyFailed	Checks whether any mailbox database copies are in a Failed state on the specified DAG member or, if no DAG member is specified, on the local server.
DBCopySuspended	Checks whether any mailbox database copies are in a Suspended state on the specified DAG member or, if no DAG member is specified, on the local server.
DBDisconnected	Checks whether any mailbox database copies are in a Disconnected state on the specified DAG member or, if no DAG member is specified, on the local server.
DBInitializing	Checks whether any mailbox database copies are in an Initializing state on the specified DAG member or, if no DAG member is specified, on the local server.
DBLogCopyKeepingUp	Verifies that log copying and inspection by the passive copies of databases on the specified DAG member (or, if no DAG member is specified, on the local server) is able to keep up with log generation activity on the active copy.
DBLogReplayKeepingUp	Verifies that replay activity for the passive copies of databases on the specified DAG member (or, if no DAG member is specified, on the local server) is able to keep up with log copying and inspection activity.
FileShareQuorum	Verifies that the witness server, witness directory, and share configured for the DAG are reachable.
QuorumGroup	Verifies that the default cluster group (quorum group) is in a healthy and online state.
ReplayService	Verifies that the Microsoft Exchange Replication service is running and can be reached on the specified DAG member, or if no DAG member is specified, this tests if the service is reachable on the local server.
TasksRpcListener	Verifies that the tasks RPC server is running and reachable on the specified DAG member or, if no DAG member is specified, on the local server.
TcpListener	Verifies that the TCP log copy listener is running and reachable on the specified DAG member or, if no DAG member is specified, on the local server.

Obtaining Switchover and Failover Statistics

If you are monitoring mailbox database copies, you sometimes need to monitor when switchovers or failovers occur and how frequently this is happening. Exchange Server 2010 provides the CollectOverMetrics.ps1 script. This collects information about switchover- and failover-related statistics that have already been recorded. It is a passive monitoring script and does not generate any new statistics. The script supports parameters that enable you to customize the script’s behavior and output. For a full list of these parameters, refer to the More Info link at the end of this section. Examples of the (arguably) more significant parameters are as follows:

• DatabaseAvailabilityGroup The DAG from which you want to collect metrics. If this parameter is omitted, the local server’s DAG is used.

• Database One or more databases for which the report is generated. This parameter supports wildcards.

• StartTime The time from which event data is collected. If this parameter is omitted, the start time is 12:00 AM on the preceding day.

• EndTime The time at which event data collection stops. If this parameter is omitted, events are collected up to 11:59 PM on the preceding day.

• IncludeAppLogs Specifies if events in the Application event log should also be collected, merged, and processed. The following providers are included by default: MSExchangeIS, MSExchangeIS Mailbox Store, and MSExchangeRepl.

• ShowHtmlReport Specifies that an HTML report should be displayed in a web browser after it is generated.

• GenerateHtmlReport Specifies that the report should be output in simple HTML table format.

For example, the following command collects metrics for all databases whose names start with MyData in the DAG named MyDAG and generates and displays an HTML report after the metrics are collected:

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup MyDAG -Database:"MyData*"
-GenerateHTMLReport -ShowHTMLReport

This command collects metrics for all databases in a DAG named SecondDAG and generates and displays an HTML report after the metrics are collected:

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup SecondDAG -GenerateHTMLReport
-ShowHTMLReport

Monitoring Replication Metrics

If you need to collect and monitor metrics actively in real time, you can use the Exchange Server 2010 CollectReplicationMetrics.ps1 script. The script supports parameters that enable you to customize its behavior and output. It does not have a StartTime or an EndTime parameter because it starts immediately. Instead, you can specify a duration parameter. The script does not support the ShowHTMLReport or GenerateHTMLReport parameters, but you can specify Verbose to display the script output on the screen.

For example, the following command collects metrics for all databases in the DAG named MyDAG and displays the collected data in an on-screen report:

CollectReplicationMetrics.ps1 -DagName MyDAG -Verbose

As with the CollectOverMetrics.ps1 script, the CollectReplicationMetrics.ps1 script will not run if the server is not part of a DAG.

Lagged Mailbox Database Copies

A lagged mailbox database copy is a passive mailbox database copy that has a log replay lag time greater than zero. You can create lagged mailbox database copies as insurance against corruption caused by, for example, damage to the EDB file during improper server shutdown. If you activate and recover a lagged mailbox database copy, the database replays all log files and makes the database copy current. The database copy thus created replaces the corrupted database. If you want to replay log files up to a specific point in time, you need to manually manipulate log files and run the Eseutil utility.

If you want to configure a lagged mailbox database copy of a mailbox database, you can use the Add-MailboxDatabaseCopy EMS cmdlet. If you specify the SeedingPostponed parameter, the new copy remains in a Suspended state because the database needs to be seeded.

The ReplayLagTime parameter specifies the amount of time that the Microsoft Exchange Replication service waits before replaying log files that have been copied to the passive database copy. If you set this parameter to a value greater than zero, this creates a lagged database copy. The TruncationLagTime parameter specifies the amount of time that the Exchange Replication service waits before truncating log files that have replayed into the passive copy of the database. This time period begins after the log has been successfully replayed into the copy of the database.

If you want to configure a lagged mailbox database copy of the database Mailbox Database 1363123687 that is hosted on Mailbox server VAN-EX1 and you want to configure a replay lag time of 10 minutes and truncation lag time of two days, you would enter the following command:

Add-MailboxDatabaseCopy -Identity "Mailbox Database 1363123687" -MailboxServer VAN-EX1
-ReplayLagTime 00:10:00 -TruncationLagTime 02:00:00

If you want to change the replay lag time for the lagged mailbox database copy Mailbox Database 1363123687 to a value of one hour, you would enter the following command:

Set-MailboxDatabaseCopy -Identity "Mailbox Database 1363123687" -ReplayLagTime 00:01:00

Lesson Summary

• You can use EMS commands based on the Get-PublicFolderDatabase and Get-PublicFolderStatistics cmdlets to monitor public folder databases.

• You can use EMS commands based on the Get-MailboxDatabase and Get-MailboxStatistics cmdlets to monitor mailbox databases.

• You can view the Crimson Channel logs in Event Viewer or use commands based on the Get-MailboxDatabaseCopyStatus EMS cmdlet to obtain the status of mailbox database copies.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 1, “Monitoring Exchange Databases.” The questions are also available on the companion CD if you prefer to review them in electronic form.

1. You want to view detailed information, including backup and mount status information, about the public folder database on the ContosoMail01 mailbox server. What EMS command do you enter?

   1. Get-PublicFolderDatabase –Identity ContosoMail01 | FL

   2. Get-PublicFolderDatabase –Server ContosoMail01 | FL

   3. Get-PublicFolderDatabase –Identity ContosoMail01 -Status | FL

   4. Get-PublicFolderDatabase –Server ContosoMail01 -Status | FL

2. You want to discover whether the status of the mailbox database MyMailboxDatabase is BackupInProgress, Mounted, or OnlineMaintenanceInProgress. You also want to find how much free space is available in the database root. What EMS command do you enter?

   1. Get-MailboxDatabase -Identity MyMailboxDatabase –Status | FL

   2. Get-MailboxDatabase -Server MyMailboxDatabase –Status | FL

   3. Get-MailboxDatabase -Identity MyMailboxDatabase – DumpsterStatistics | FL

   4. Get-MailboxDatabase -Server MyMailboxDatabase – DumpsterStatistics | FL

3. You want to obtain statistics for the Jeff Hay mailbox in the mailbox database MyMailboxDatabase on the Mailbox server Mal01. You enter the following command:

   Get-MailboxStatistics -Identity "Jeff Hay" | FL

   Mailbox statistics are not returned, but instead you get a warning message. What is the likely reason for this?

   1. You need to use the Server parameter and specify the value Mail01.

   2. You need to use the Database parameter and specify the value MyMailboxDatabase.

   3. Jeff Hay has never logged on to his mailbox, and the mailbox has not been accessed in any other way (for example, an email message has not been sent to it).

   4. You need to use the Get-StoreUsageStatistics cmdlet, not the Get-MailboxStatistics cmdlet.

4. Which mailbox database copy status indicates that the mailbox database copy is no longer connected to the active database copy and that it was in the Resynchronizing state when the loss of connection occurred?

   1. DisconnectedAndResynchronizing

   2. ActivationSuspended

   3. Seeding

   4. DisconnectedAndHealthy

5. Which EMS cmdlet can you use to generate a report on the 25 accounts that are using the greatest amount of resources within a mailbox database?

   1. Get-MailboxStatistics

   2. Get-StoreUsageStatistics

   3. Get-MailboxDatabase

   4. Get-MailboxDatabaseCopyStatus