Monitoring & Managing Database Availability Groups

Monitoring & Managing Database Availability Groups

Contents 1.    Replication Health 2.    Database Copy health 3.    MAPI Connectivity check             4.    Service Health Check

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 like Replication Health, Database Copy Health & Access

1.  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. Cmdlet Test-ReplicationHealth is extremely useful in proactive monitoring as it checks all aspects of the replication status to provide a complete overview of a specific Mailbox server in a DAG.

Command:

Example – 1

This example tests the health of replication for a local Mailbox server on which the cmdlet  was run.

Test-ReplicationHealth

Example – 2

This example tests the health of replication for a Mailbox server ServerName.

Test-ReplicationHealth – Server ServerName

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

Before we start checking the status we need to understand all the possible values a mailbox database copy state can have. Below is the small note on each:

      Failed - because it isn't suspended and it isn't able to copy or replay log files;

      Seeding - the mailbox database copy is being seeded, the content index for the mailbox database copy is being seeded or both are being seeded. Upon successful completion of seeding, the copy status should change to Initializing;

      SeedingSource – it is being used as a source for a database copy seeding operation;

      Suspended - as a result of an administrator manually suspending the database copy by running the Suspend-MailboxDatabaseCopy cmdlet;

      Healthy - is successfully copying and replaying log files or it has already successfully copied and replayed all available log files;

      ServiceDown - the Microsoft Exchange Replication service isn't available or running on the server that hosts the mailbox database copy;

      Initializing - when a database copy has been created, when the Microsoft Exchange Replication service is starting or has just been started, and during transitions from Suspended, ServiceDown, Failed, Seeding, SinglePageRestore, LostWrite or Disconnected to another state. While in this state, the system is verifying that the database and log stream are in a consistent state;

      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;

      Mounting - the active copy is coming online and not yet accepting client connections;

      Mounted - the active copy is online and accepting client connections;

      Dismounting - the active copy is going offline and terminating client connections;

      Dismounted - the active copy is offline and not accepting client connections;

      DisconnectedAndHealthy - is no longer connected to the active database copy and it was in the Healthy state when the loss of connection occurred;

      DisconnectedAndResynchronizing - is no longer connected to the active database copy and it was in the Resynchronizing state when the loss of connection occurred;

      FailedAndSuspended - the Failed and Suspended states have been set simultaneously by the system because a failure was detected and because resolution of the failure explicitly requires administrator intervention;

      SinglePageRestore - this state indicates that a single page restore operation is occurring on the mailbox database copy.

Command:

Example – 1

This example returns status information for all copies on the local server

Get-MailboxDatabaseCopyStatus

Example – 2

This example returns status information of databases on the specified server (ServerName).

Get-MailboxDatabaseCopyStatus -Server ServerName | Format-List

Example – 3

This example returns the status for the active and passive copy of database MBX-0001

Get-MailboxDatabaseCopyStatus -Identity MBX-0001 | FT

Reseeding a database copy

There may be times when database replication issues arise in your environment. These issues could be caused by hardware failures, network issues, or, in extremely rare cases, log file corruption, and leave you with failed database copies that need to be reseeded. Process for reseeding database copies using the Exchange Management Shell

1. To reseed a database copy, suspend replication using the following command syntax:

Suspend-MailboxDatabaseCopy -Identity MBX-0001\ServerName -Confirm:$false

2. To reseed the database, use the Update-MailboxDatabaseCopy cmdlet, as shown:

Update-MailboxDatabaseCopy -Identity MBX-0001\ServerName –DeleteExistingFiles

When using the Update-MailboxDatabaseCopy cmdlet to reseed a database copy, you can use the -DeleteExistingFiles switch parameter to remove the passive database and log files. Depending on the size of the database, it may take a long time to perform the reseed. Once the reseed is complete, replication for the database will automatically be resumed.
If you don't want replication to resume automatically after a reseed, you can configure it for manual resume:

Update-MailboxDatabaseCopy -Identity MBX-0001\ServerName -DeleteExistingFiles -ManualResume

In this example, we've added the -ManualResume switch parameter. After the reseed, we can manually resume replication:

Resume-MailboxDatabaseCopy -Identity MBX-0001\ServerName

Corrupt Content Index State.
One of the things that you may run into is a database with a corrupt content index state. In this situation, it's not necessary to reseed the entire database, and you can reseed the content index catalog independently:

Update-MailboxDatabaseCopy -Identity MBX-0001\ServerName -CatalogOnly

Using the -CatalogOnly switch parameter as shown previously will allow you to reseed the content index catalog without reseeding the database. Alternatively, you also have the option of reseeding only the database:

Update-MailboxDatabaseCopy -Identity MBX-0001\ServerName -DatabaseOnly

In this example, the DB01 database on the MBX2 server is reseeded without having to seed a copy of the content index catalog.

Verifying the Database Activation preference

Get-MailboxDatabase | Sort Name | FL Name, ActivationPreference

3.   MAPI Connectivity check

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.

Command

Test-MAPIConnectivity

Only by monitoring and measuring performance across these three components can you be sure that your Database Availability Groups are actually delivering high availability. Below example checks the MAPI connectivity against a database MBX-0001

4.  Service Health Check

As the name suggests, Test-ServiceHealth checks the state of the services that should be running on the Exchange server. One of the best things about this cmdlet is that it checks the services depending on the Exchange server roles that are installed.

Command

Test-ServiceHealth -Server ServerName