Exchange 2013 Automatic Reseed

Microsoft has made great improvements in Exchange 2013, some of these around Database Availability Groups [DAGs]. For example, it is now possible to reseed a database from multiple sources, greatly reducing the overall time this operation usually takes. Another improvement, in this case a new feature, is called Automatic Reseed, or simply AutoReseed.

With Exchange 2010, if you lose the disk where your database is (either active or passive), Exchange will failover that database to another server (assuming it is part of a DAG with multiple copies). After that, an administrator will typically replace the faulted disk and reseed the database back to that server. This, of course, in scenarios where resilience through RAID or enterprise-level storage is not provided, which would cater for disk failures.

The purpose of AutoReseed is to overcome this situation and automatically restore database redundancy by using spare disks provisioned specifically for this. All it involves is pre-mapping volumes and databases using mount points that will be used for the databases and the reseed operation. In a simplistic way:

1. Mount all volumes (used for databases and as spares) under a single mount point, C:\ExchangeVolumes for example;
2. Mount the root directory of mailbox databases as another mount point under C:\ExchangeDatabases for example. Next, create two directories for each database: one for the database itself and another for the log files;
3. Finally create the database(s).

The diagram below should help understanding this design, but when we go through all the steps it will become clearer.

First, let’s look at the AutoReseed process flow:

1. The Exchange Replication service periodically scans for database copies that have a status of FailedAndSuspended;
2. If one is found, it does pre-requisite checks like checking if spare drives are available and ensuring nothing might prevent Exchange from automatic reseeding the database;
3. If all the checks pass, the Replication service allocates and remaps a spare drive;
4. Seeding is performed;
5. Once seeding is complete, the Replication service checks if the seeded copy is healthy.

All an administrator needs to do now is simply replace the faulty disk and reconfigure it as a spare for the DAG!

Now that we understand the overall principal of AutoReseed, let’s see how to configure it.

AutoReseed Scenario

For this article, let’s consider a simple scenario with a single database:

Figure 1: AutoReseed Diagram

In this scenario we have 2 volumes:

1. Volume1 is where database DB01 is hosted;
2. Volume2 is our blank spare drive.

Note:You can have as many volumes as you want and even multiple databases per volume.

To start with, I have already configured a DAG with two mailbox servers: EXMBX1 and EXMBX2 (with no databases yet):

Figure 2: Database Availability Group with 2 Nodes

Now, let’s add two new disks to the Exchange mailbox server EXMBX1 and name them Volume1 (E:) and Volume2 (F:):

Figure 3: Adding Disks

Configure DAG for AutoReseed

To configure AutoReseed we first need to configure three DAG properties introduced in Exchange 2013:

• AutoDagVolumesRootFolderPath is the mount point containing all the volumes available for databases and spares;
• AutoDagDatabasesRootFolderPath is the mount point containing the databases;
• AutoDagDatabaseCopiesPerVolume sets how many database copies per volume there going to be.

The default folders are C:\ExchangeDatabases and C:\ExchangeVolumes but you can use whatever you want, including place them on a different drive.

Note:Not all the databases you create in the DAG need to be placed in these folders! However, AutoReseed will only work with the ones that are properly configured in these folders.

To set all these properties, we use the Set-DatabaseAvailabilityGroup cmdlet:

Figure 4: Configuring DAG for AutoReseed

Configure Folders for Databases and Volumes

Next, we need to manually create the root directories that will hold the volumes and the databases:

Figure 5: Root Directories for Volumes and Databases

Mount Volume Folders

For each volume that will be used (both for databases and spares), we need to mount them in a mounted folder under C:\ExVols. In my case, because I am only using two volumes, I create the following two folders:

Figure 6: Directories for Volumes

Remember you can use whatever names you want. Just make sure you keep them consistent and easy to understand what they are!

Let’s now use Windows Disk Management (diskmgmt.msc) to mount our two volumes into these two folders. Starting with Volume1, right click on the volume and select Change Drive Letter and Paths...:

Figure 7: Configuring Mount Points – Volume1

Click Add...:

Figure 8: Configuring Mount Points – Change Drive Letter and Paths

Click Browse... and navigate to the location of where the Volume1 folder is. Click OK twice.

Figure 9: Configuring Mount Points – Add Drive Letter or Path

Now map the folder Volume2 to the volume Volume2 and you should see the folders with different icons, meaning they are now mounted folders:

Figure 10: Volumes Mount Points

Mount Database Folders

We now need to do something similar to our database folder. In our case we have a single database, so we will be mapping C:\ExDBs\DB01 to the volume Volume1 as well. So first we create the C:\ExDBs\DB01 folder:

Figure 11: Directory for the Database

Instead of using Windows Disk Management to map this folder to the volume Volume1, let me show you how to use the MountVol.exe tool. By simply running mountvol we can see all the volumes that are available for us to mount:

Figure 12: Available Volumes

In our case we know the one we want is \\?\Volume{03cf7f78-ed05-4bb7-a4f0-0914f9575bdd}\ because we can see the folder Volume1 is mounted to it. To also mount C:\ExDBs\DB01 to this volume, we use the following command:

Figure 13: Mounting DB01 to Volume1

The icon for the C:\ExDBs\DB01 folder should have changed to reflect it is now a mounted folder:

Figure 14: Database Mount Point

If we list all the mounted volume named for this particular folder, we will see it is mounted to volume Volume1:

Figure 15: Listing Mounted Volumes

If we run mountvol again we should also see volume Volume1 mounted on this folder:

Figure 16: Listing All Volumes

Create Database Directory Structure

Next, create the directories that will be used to store the database files: one for the database itself and one for the log files. If you are configuring multiple databases per volumes, you would create them all here, two folders per database.

Because we have two mounted folders pointing to the same volume, you can create these folders by going to C:\ExDBs\DB01 or directly to Volume1 (E:\ in my case):

Figure 17: Creating Database Folders

If we now go to E:\ we will see these same folders:

Figure 18: Checking Database Folders

Create Mailbox Database

Finally we need to create the mailbox database in the appropriate folders:

Figure 19: Creating Mailbox Database

After we mount the database we add a copy to mailbox server EXMBX2 and ensure it is healthy:

Figure 20: Mounting and Adding Mailbox Database Copy

Checking Database Creation

If we check the C:\ExDBs folder in server EXMBX1, it shouldn’t be taking up any space as all the data is actually kept in volume Volume1:

Figure 21: C:\ExDBs Folder Properties on EXMBX1

However, if we do the same check on EXMBX2, this will not be the case. This is because on EXMBX2 I did not configure any volumes and mount points for AutoReseed to use, so Exchange/Windows is keeping the files in the actual C:\ExDBs folder, which is perfectly fine. This means, however, that if the drive on EXMBX2 fails, AutoReseed will not be able to do anything about it...

Figure 22: C:\ExDBs Folder Properties on EXMBX2

Testing AutoReseed

Now we get to the fun part, let’s test everything! To do this, let’s bring volume Volume1 offline which should make Exchange automatically failover database DB01 to server EXMBX2 and then AutoReseed should start reseeding DB01 into the spare volume in EXMBX1.

To bring the disk offline, I use Windows Disk Management: right click on Disk 1 and select Offline:

Figure 23: Bringing Volume1 Offline

If we check the database copy status, we will see that Exchange immediately failed it over to server EXMBX2 and that the copy on server EXMBX1 is on a failed state:

Figure 24: Exchange Failover

Now, let’s keep an eye on the Seeding event log, where all the information regarding AutoReseed is kept:

Figure 25: Seeding Event Log

In all my tests, the longer it took for AutoReseed to detect a failed and suspended copy was 20 minutes (this one took only 3 minutes), so my guess is that Exchange checks every 20 or 30 minutes probably.

After it picks up on the failed disk, you will see the following events below, regarding the start and completion of the reseed operation:

Figure 26: Reseeding Has Begun

Figure 27: Reseeding Has Completed

And then checking to make sure everything is working fine:

Figure 28: Reseeding Repair Workflow Is Starting

Figure 29: Reseeding Repair Workflow Has Completed

Now this is the great part for me! If you go back to the beginning of the article, you will see in the AutoReseed process flow (step 3) that Exchange “allocates and remaps a spare drive”. If we check where C:\ExDBs\DB01 is mapped to, we will see that it is no longer volume Volume1 but Volume2!

Figure 30: AutoReseed Remap

Because AutoReseed re-maps the drive, from an Exchange and Windows perspective, DB01 is still in the same place as before (nothing changed – remember we are using mount points)! For this reason, after a few seconds, it will start reseeding the database to its “original” location and the database copy will get Healthy again!

Figure 31: AutoReseed Healthy Database Copy

Figure 32: AutoReseed Database Files on EXMBX1

During this entire process, users won’t even experience any downtime! For example, I had a user logged on to OWA which never got logged off.

At this stage, this is how everything is looking:

Figure 33: AutoReseed Complete

All an administrator now needs to do, is replace the faulty drive and configure it as a spare for this DAG!

Conclusion

In this article we explored Automatic Reseed, a new feature introduced in Exchange 2013 to further improve Database Availability Groups, that can automatically restore database redundancy by using spare disks.