GSX Blog

Exchange 2010 Monitoring: Database Availability Groups

Posted by Carl Drechsel on Thu, Jan 12, 2012

Database Availability Groups are the key component for Microsoft Exchange 2010 High Availability. As such it is critical to ensure their overall health and availability. High availability can give a false sense of security, in order to ensure an IT service is highly available the overall solution must include monitoring.

When monitoring the high availability function of Database Availability Groups it is important to consider three separate components:

  • Replication Health
  • Database Copy Health
  • Access

Replication Health

In Exchange 2010 any given Mailbox server in the Database Availability Group can host all, some or none of the active mailbox copies at any given time.  Proper replication between mailbox servers is vital to ensure high availability function.

In order to monitor replication health manually we can use the Management Shell cmdlet, Test-ReplicationHealth. In the example below, we specify the Database Availability Group

11 22 2011 12 17 40 PM

 

 

 

 

 

 

Database Copy Health

After multiple copies of a database are created, the health of each becomes critical to your overall high availability solution.  Again we can use the Exchange Management Shell to monitor the health and status of each copy and to perform other management tasks associated with database copies. Some of the management tasks you may need to perform include suspending or resuming a database copy, seeding a database copy, monitoring database copies, configuring database copy settings, and removing a database copy.

For Database copy health we can use the Get-MailboxDatabaseCopyStatus cmdlet to view status information about the mailbox database copies. This cmdlet enables you to view information about all copies of a particular database, information about a specific copy of a database on a specific server, or information about all database copies on a server. Running this cmdlet will present the status of a database copy as seen below.

  • Failed
  • Seeding
  • SeedingSource
  • Suspended
  • Healthy
  • ServiceDown
  • Initializing
  • SinglePageRestore
  • Resynchronizing
  • Mounted
  • Dismounted
  • Mounting
  • Dismounting
  • DisconnectedAndHealthy
  • DisconnectedAndResynchronizing
  • FailedAndSuspended
Access

Once we can ensure that replication is working as expected and we have healthy database copies we need to know that the information stores are accessible. 

We can use the Test-MapiConnectivity cmdlet to verify server functionality and database availability. This cmdlet will log on to the mailbox specified and retrieve a list of items in the Inbox. This test will also check two critical protocols used when a client connects to a Mailbox server: MAPI and LDAP. During authentication, the  cmdlet indirectly verifies that the MAPI server, Exchange store, and Directory Service Access (DSAccess) are working. 

11 22 2011 12 48 28 PM

Only by monitoring and measuring performance across these three components can you be sure that your Database Availability Groups are actually delivering high availability.

GSX Solutions is the leading provider of monitoring and reporting solutions for Unified Communications applications, whether on-premises or in the cloud. Find out more now >>

If you haven't tried GSX' solutions yet, why not sign up for a free 14-day trial or request a personal demo.

 

Tags: Exchange 2010, DAG, Exchange 2010 monitoring, database availability group, mailbox server