Configuring Database Availability Groups in Exchange Server 2013 Preview


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

The process of creating a Database Availability Group (DAG) in Exchange Server 2013 (Preview) is largely the same as in Exchange Server 2010. You can choose to create a DAG via either the Exchange Administrative Center (GUI) or through the Exchange Management Shell (PowerShell).

I prefer using the Exchange Management Shell over EAC as it provides you more information over the process.

Exchange Management Shell

To configure a Database Availability Group using the EMS, type in the following commands. Replace the example values with the ones that suit your environment:

New-DatabaseAvailabilityGroup –Name DAG01 –WitnessServer SRV01 –WitnessDirectory “C:\FSW” – DatabaseAvailabilityGroupIPAddresses

This command will create the DAG. As part of this process, a computer object, also known as the Cluster Name Object, will automatically be created:


Note   In order for this process to complete successfully, you need to have the appropriate permissions on the container in which the object is created. By default this will be the “Computers”-container. However, it is possible that your Active Directory has been reconfigured to use another container/OU as default location for new computer accounts. Have a look at for more information.

Another way to get around the possible issue of permissions, is to create the Cluster Name Object (CNO) upfront. This process is also called “pre-staging”. Doing so will allow you to create the object up-front with another account (that has the appropriate rights) so that you don’t run into any issues when configuring your DAG.

To pre-stage the CNO, complete the following tasks:

  1. Open Active Directory Users & Computers, navigate to the OU in which you want to create the object, right-click and select New > Computer:


  2. Enter a Computer Name and click OKto create the account:


  3. Right-click the new account and select Properties. Open the Security tab and add the following permissions:- Exchange Trusted Subsystem – Full Control
    – First DAG Node (Computer Account) – Full Control

image     image

More information on how to pre-stage the CNO can be found here:

Note   if your DAG has multiple nodes across different subnets, you will need to assign an IP address in each subnet to the DAG. To do so, you can separate the IP addresses using a comma:

New-DatabaseAvailabilityGroup –Name DAG01 –WitnessServer SRV01 –WitnessDirectory “C:\FSW” – DatabaseAvailabilityGroupIPAddresses,,

Once the command executed successfully, you can now add mailbox servers to the DAG. You will need to run this command for each server you want to add to the DAG:

Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer EX01
Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer EX02

Alternatively, you can also add all/multiple mailbox servers at once to the DAG:

Get-MailboxServer | %{Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer $_.Name}

Adding Database Copies

Now that your DAG has been created, you can add copies of mailbox databases to other mailbox servers. For example, to add a copy of DB1 to server EX02, you would run the following command:

Add-MailboxDatabaseCopy –Identity DB1 –MailboxServer EX02

Stay tuned! In an upcoming article, I will be talking about configuring high availability for the Client Access infrastructure in Exchange Server 2013 as well as a topic on high availability (more general).

Exchange 2013 How-To's

A closer look at the “new” Public Folders in Exchange Server 2013


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

In addition to some of the existing blogs and information out there, I wanted to take the time and explain the “new” Public Folders in Exchange Server 2013 a bit more in detail.


Ever since Exchange Server 2007 was released, Microsoft proclaimed Public Folders would eventually disappear. At that time, it was said Public Folders would stop to exist in “future versions” and consultants were given the advice to evangelize SharePoint as being thé replacement for Public Folders. It seemed, however, that these statements provoked quite some comments from the field: companies world-wide would still be using Public Folders and were not planning on giving that up so easily. Knowing what a migration to SharePoint could potentially cost, it’s quite understandable that some companies were rather reluctant to immediately jump on the SharePoint-train.

In fact, I cannot blame them. Even through today, there’s no real solution that offers the same functionality and ease of use as Public Folders.

Over time, Microsoft seems to have recognized that killing Public Folders might not be such a great idea after all and changed it’s attitude little at a time. Nevertheless, they’ve always deemphasized using Public Folders.

…At least until NOW.

To better understand at what the changes in Exchange Server 2013 are, let’s first have a look at how things were in Exchange Server 2010.

Public Folders in Exchange 2010 (and before)

In Exchange Server 2010 (and before), Public Folders were stored in their own database(s).

Basically speaking, Public Folders consists of two elements:

    • Hierarchy which contains the properties of the public folders and also  includes the tree-structure in which the Public Folders are organized. This tree structure contains Public- and System Public Folders.
    • Content which is the actual data (e.g. messages) in a Public Folder. Each Public Folder database contains a copy of the hierarchy, however not every database contained the same content:

image: a simplified graphical view of a public folder database

It was up to the administrator to define what content would be replicated across one (or more) servers. When a public folder was setup to have multiple copies, a process called “Public Folder replication” ensured that data was replicated across these “replicas” (= other public folder databases).

This replication is in no way comparable to how a DAG replicates data though: SMTP messages are sent between the different Mailbox Servers that hosted a Public Folder database:

image:a simplified overview of the PF replication model

Although from a data point-of-view having multiple writeable copies of Public Folders highly available: it is not. At least not when it comes to the end-user experience during a failover. Each Mailbox database is configured with a default (“preferred”) Public Folder database. Mailboxes within that mailbox database would automatically connect to their preconfigured “preferred” Public Folder database.

    • If – for some reason – the server hosting the Public Folder database would be unavailable entirely (e.g. offline), a timeout (+/- 60 seconds) would occur and clients would be redirected to another Public Folder database.
    • If, however, the server would still be online but the database would e.g. be dismounted, there would be no redirection and clients would end up with no Public Folders.

As you can imagine, not really a nice user experience, is it?

From a design point of view, Public Folders allowed you to easily spread data across multiple locations and have people make changes to the data in different locations. These changes are then replicated amongst the different replicas. In fact, Public Folders (in Exchange 2010 and before) are implemented in a sort of multi-master model:  all public folder replicas in a PF database are writeable.

Changes in Exchange Server 2013

Exchange Server 2013 entirely changes how Public Folders operate (from a technical point-of-view). From an end user’s perspective, everything remains as it used to be.

The main architectural changes that are introduced are:

    • Public folders are now stored in a mailbox database
    • Public folders now leverage a DAG for high-availability

Public Folder Mailboxes

Public folders are now also mailboxes, but their type is “Public Folder” (just like a Room Mailbox is a Mailbox with type “Room”). In a way, Public Folders still exist of two main elements mentioned above: the hierarchy and contents.

  • The hierarchy is represented by what is called the Master Hierarchy Public Folder Mailbox. This PF Mailbox contains a writeable copy of your public folder hierarchy. There is only a single Master Hierarchy PF mailbox in the organization.
  • Contents (in Public Folders) are now stored in one or more Public Folder mailboxes. These Public Folder mailboxes usually contain one or more Public Folders. Next to the contents, each PF Mailbox also contains a read-only copy of the hierarchy.


Note   because Public Folders are now stored in mailboxes, mailbox quota’s apply to them. For instance, this means that if a PF Mailbox would grow too large, you’d have to move Public Folders to another PF Mailbox (or increase the quota).

PF Mailboxes can grow quite large without really suffering from performance issues, just like regular mailboxes. Although real-world experience will have to tell us what the performance of Public Folders would be with a large amount of numbers, I’m confident that most companies won’t have a problem fitting a Public Folders in one (or more) PF Mailboxes. Nonetheless, you should carefully plan your Public Folder deployment, especially If you’re company heavily relies on them.

How do these “new” Public Folders work?

The process of connecting to and performing actions on a Public Folder could be summarized as follows:

    1. A user connects to a Public Folder (Mailbox).
    2. Any operation to the Public Folder is recorded in the PF mailbox
    3. If the data is located in another Public Folder Mailbox, the operation is redirected to the appropriate PF mailbox (which contains the Public Folder against which the action was performed)
    4. Hierarchy changes (e.g. adding or removing folders) are redirected to the Master Hierarchy PF Mailbox from where they are in turn replicated to all other PF Mailboxes (5).

Note   Hierarchy changes are never recorded through a regular PF Mailbox


High Availability.

Because Public Folders now reside in regular mailbox databases, they can benefit from the High Availability model that a Database Availability Group offers. Since you can store Public Folder mailboxes in any database, there’s no difference as to how they are treated in case of a failover.

The implications of changes

Because of these changes, the way we will implement Public Folders will also change. Foremost, placement for Public Folders will require a bit more planning from now on.There can only be a single active copy of a mailbox database at any given time, so we can no longer “benefit” from the multi-master model that existed previously.

This means that you should – preferably – place your Public Folder Mailboxes as close to your users as possible. If, however, to different groups need to work on the same set of folders but at opposite sites of the globe; you might be in for a challenge… Of course, one might start to wonder if Public Folders would be the right choice in such a scenario after all.

It’s not only good news

Unfortunately, every upside also has a downside: due to all the changes that were introduced, it seems that Microsoft isn’t able to get everything finished in time. At RTM we won’t have Public Folders in OWA. Perhaps this is something we’ll see added in SP1 (just like with Exchange 2010)…

Migration and coexistence

I will keep the migration and coexistence part for a future article. At the moment, Exchange Server 2013 Preview only support greenfield installs… On the other hand, if you’re interested in reading more on the migration stuff, you might want to take a look at a fellow-UC Architect Mahmoud Magdy’s blog about the new Public Folders.

Blog Exchange 2013