Exchange 2013 – Database Availability Groups – Part 3

In this post, I am going to take a look at various different methods that we can add a mailbox database copy for an existing “DB01” database copy in Exchange 2013. Currently my setup consists of two mailbox servers running on Hyper-V 2012 (on Windows 8). The mailbox servers are running standard edition trial licenses of both Windows and Exchange and they are a member of a two node dag leveraging an Exchange 2013 Client Access server as the file share witness. For more information on the setup please refer back to the first article, here.

Due to my lack of available disk, “DB01” is running in the default mailbox database location. For the sake of requirements, I don’t need to ensure that the same drive path is used because, they will be located in the default directories. To create a mailbox database copy of “DB01” on “EX13-MB2” in the EAC, navigate to “servers” in the features pane, and select “databases” in the tabs section. With the database in scope (DB01 in my case) selected, click the “more options icon represented by the ““, then finally select “Add database copy” from the available options list. The below screenshot shows all steps in a single view.


The “Add Mailbox Database Copy” will be displayed allowing for the selection of a mailbox server that is currently a member of a dag to host the passive of copy of the database in scope (DB01) in my case.


After clicking “Save” and if defaults were selected in the “More options” section in the previous step, Exchange will save the configuration and start a seed operation of “DB01 immediately. It will show the progress and remaining amount of data to be seeded during the operation.




To complete the “Add mailbox database copy” process via the shell, the following command will add a mailbox database copy for the database “DB01” on server “EX13-MB2“.


Once completed, the EAC will now show the additional passive copy of “DB01“, it’s current status and allow for administrative tasks to be executed as shown below.


Interestingly enough, by the time I saved the screenshot above, the resynchronization that was taking place had completed and a system initiated *over event occurred, resulting in the database copy on EX13-MB2 becoming the “active mounted copy and the original copy on EX13-MB1 becoming the “passive healthy” copy. See below. We’ll come back to this in the next post while attempting to invoke and learn more about the new “managed availability features; the probe engine, monitors and the responder engine.


I’m going to test out an administrator initiated database switchover and see if the Exchange 2013′s “managed availability” determines that for some reason the active database should not reside on “EX13-MB1“. To initiate the switchover, I’ll simply select “Activate” from the details pane as shown below.


After selecting “Activate“, a warning dialog box as shown below is presented, we’ll click “yes” to proceed.


During the activation process, a dialog box is presented stating that a remote procedure call has been issued to move the active copy of database “DB01“ to “EX13-MB1“. Although Exchange 2013 has eliminated the RPC protocol for client connectivity it is still present in various different mailbox server related functions. It appears that it is used in this scenario (database switchover events) and also when routing messages to and from the “Exchange Transport” service and “Exchange Mailbox Transport service.


After completion of the failover request, the database is now active and mounted on “EX13-MB1“.


To perform a database switchover via the shell, the below command can be executed.


Not shortly after editing some of this, I went back to check if the Exchange 2013 “managed availability” service has imitated a database failover for DB01 due to a threshold being reached only to find that the “EX13-MB1” virtual server was “Turned Off“. The server did not bug check and restart but it shut down, which leads me to believe if was a system initiated shutdown event. Could this be managed availability in the works, determining that the server is in fact unhealthy and is not able provide services to the enterprise? Below are two screen shots displaying the system in a “Turned Off” state and the status of the database copy in the EAC.



In the next post, we’ll see how easy it is for an administrator to leverage managed availability in Exchange 2013 to determine what in fact is causing the shutdown and failover events to occur in the two node Exchange 2013 database availability group. My hunch is that it’s disk related……..

Any thoughts?