Microsoft Exchange 2013 AutoReseed -Part 1-


Exchange 2013 has been out there for a few month and I have been playing around with its High Availability features in a LAB.

One of my favorite new features in Exchange 2013 is its “Automatic Reseed capability”; at first sight AutoReseed might not look like a big deal for the RAID advocates but, in my opinion, it can really be a life savior.

Let start by understanding what does AutoReseed do. Well simply Exchange will periodically scan for databases in failed state and, if any is found and the DAG and server were provisioned for AutoReseed, Exchange will run a set of pre-requisites check and then automatically use one of the spare drives available and reseed the database without any intervention.

So why do I find this feature so important?

Well you probably already know that, in Exchange 2013, the CAS role doesn’t do much as it did back in Exchange 2010; its role is simply to proxy the requests to the mailbox server which handles all the data rendering. There are many advantages to this change, which are not in the scope of this article, but has one major drawback: The mailbox server that is going to handle the request is the same mailbox server on which the requesting user’s database is mounted.

Let’s take an example of a 2 nodes DAG running all roles and assume that the database gets corrupted on Node 1 and fails over to Node 2, and then IIS fails at Node 2. Applying this scenario to Exchange 2010 the load balancer will point you to CAS on Node 1 that could access the mailbox on Node 2 and we have no service disruption, this scenario on Exchange 2013 however is catastrophic! There is no healthy servers in the DAG that can host the database and render the requests and users will be disconnected.

In that case AutoReseed could save the day by bringing back a healthy copy of the database to Node 1 on which IIS is still operational.

Before we start

At the time I am writing this article there are already a few articles out there describing how to configure Exchange 2013 Automatic Reseed but there are a few points that, in my opinion, are worth stressing on and were neglected or left out in other articles and that is the reason why I decided to write my own article about it.

Let me start with a couple of points that should not be forgotten

  • Directory names are not optional: The edb and the log path of your mailbox database has to be AutoDagDatabasesRootFolderPath\DatabaseName\DatabaseName.db and AutoDagDatabasesRootFolderPath\DatabaseName\DatabaseName.log else the autoreseed prerequisites check will fail. Assuming your Database name is DB1 the edb should be in the AutoDagDatabasesRootFolderPath\DB1\DB1.db directory and the logs should be in AutoDagDatabasesRootFolderPath\DB1\DB1.log directory
  • Number of copies per volume should be equal: One of Exchange 2013 new features is the possibility to have multiple databases per volume. However for AutoReseed to work the same number of databases should be in each volume, you cannot, for example, have 2 databases on Volume 1 and one database of Volume 2

It should also be noted that, although the Set-DatabaseAvailabilityGroup has many parameters with the “AutoDag” term only 3 are needed in Exchange 2013 RTM for AutoReseed to work:

  • AutoDagVolumesRootFolderPath: Is set by default to C:\ExchangeVolumes and specifies the folder containing the mount points for all disks, including spare disks, used for Exchange databases.
  • AutoDagDatabasesRootFolderPath: Is set by default to default to C:\ExchangeDatabases and specifies the directory containing the databases mount points.
  • AutoDagDatabaseCopiesPerVolume: Specifies the number of database copies on each volume

In short

There is no real way of disabling or enabling AutoReseed, this feature will work automatically when all the below required steps are done

  • Mount all volumes to be used by Exchange for databases or spare under the same directory. This directory is by default C:\ExchangeVolumes and can be changed
  • Mount all databases under another root directory, by default C:\ExchangeDatabases, in a way that every database can be reached through C:\ExchangeDatabases\DBName\DBName.db and C:\ExchangeDatabases\DBName\DBName.log. Although C:\ExchangeDatabases\ can be changed the rest has to follow this naming convention.
    N.B.: If you are hosting more than one database on a single volume, this volume will have 2 mount points C:\ExchangeDatabases\DB1 and C:\ExchangeDatabases\DB2
  • Move your existing databases, or create new databases, in their corresponding location.

This was an overview of the Exchange 2013 Automatic Reseed feature, in part 2 of this tutorial we will apply these steps and see how it works.

I have been working in IT consultancy and solution integration since 1998 and I consider myself lucky to be, one in a few, making a living out of my passion. I am also member of the famous Experts Exchange (profile here) online community where I try my best to share what I have learned along the road.

Posted in Messaging & Collaboration Tagged with: , , ,
2 comments on “Microsoft Exchange 2013 AutoReseed -Part 1-
  1. David says:

    Hi Antoine, great article, but I don’t understand when you said “However for AutoReseed to work the same number of databases should be in each volume, you cannot, for example, have 2 databases on Volume 1 and one database of Volume 2”. Which is the reason?

Leave a Reply

Your email address will not be published. Required fields are marked *