Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 12)

If you would like to read the other parts in this article series please go to:


In part 11 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we configured the relevant Exchange 2013 namespaces, installed the necessary trusted certificate and created the required internal as well as external DNS records.

In this part 12, we will continue where we left off in part 11. More specifically our focus will be on the Mailbox role side of things. We will talk about how to create a database availability group (DAG) on a virtual machine in Windows Azure followed by creating a DAG and adding the two Exchange 2013 multi-role servers to the DAG. Lastly, we will create a public folder mailbox and the primary hierarchy.

Let’s get going…

Database Availability Groups in Windows Azure

At the time of this writing, virtual machines in Windows Azure are restricted to a single network interface and IP address. This is not really an issue when it comes to configuring a database availability group (DAG) though, since it is not required to have a unique network interface configured for MAPI (client connections) and replication (log file replication).

A single network interface works fine for this purpose. Using a single network interface is also supported for production environments.

What about the cluster name object (CNO) and static or DCHP assigned IP address required by the fail-over clustering component in Windows Server. Will it work with Windows Azure based virtual machines? I hear some of you grumble. The answer is no at the moment, that will not work. Fear not though. You see, Windows Server 2012 R2 introduces a great new improvement in regards to fail-over clustering named “Active Directory-detached cluster”. An Active Directory-detached cluster allows us to deploy a fail-over cluster without dependencies in Active Directory Domain Services (AD DS) for network names.

Similarly, Exchange 2013 Service Pack 1 introduces a new DAG specific functionality referred to as “DAG without a cluster administrative access point” which utilizes the new Active Directory-detached cluster functionality in Windows Server 2012 R2.

This means we can now configure at DAG without the need for the cluster name object (CNO), IP address and DNS registration, which was previously required. Said in another way, we can now create a DAG without using any form of IP address association.

In this specific lab environment, we will use a single network interface for both MAPI and replication purposes and utilize the new “DAGs without a cluster administrative access point” functionality now possible with Exchange 2013 SP1 running on top of Windows Server 2012 R2.

A “DAGs without a cluster administrative access point” can be created using the Exchange Management Shell (EMS) as well as the Exchange Admin Center (EAC). In this article, we will use the EAC, so let us open the EAC and then navigate to “Servers” and then click on the “Database Availability Groups” tab.

On the “Database Availability Groups” page, click on the plus icon shown in Figure 1.

Figure 1: Database availability group tab under servers in the EAC

Specify a name for the new DAG and then enter the name of the witness server. In this specific lab environment, I have deployed a domain member server named AzurelabDM1. Since this server is a non-Exchange server, I have made sure to add the “Exchange Trusted Subsystem” group to the “Local administrators” group. You can also specify the witness directory name on the server, but this is optional. If you do not specify the witness directory name, a default one will be used.

Figure 2:
Exchange Trusted Subsystem group to the Local administrators group

Lastly, we need to enter the IP address(s) to be used. This field is mandatory, however since we do not want to use an IP address, we will simply enter “” as shown in Figure 3.

Figure 3:
Creating a new database availability group

Click “save” and after a few seconds, the DAG will have been created.

If you receive an error and are told, you should create the witness folder manually, it may be because the Windows Firewall is blocking the communication. To fix this, turn off the firewall for “Domain” and “Private” and try again.

Figure 4:
The database availability group has been created with success

With the DAG created, let us add the two Exchange 2013 multi-role servers as DAG members. To do so, click on the server icon with the little gear on it as highlighted in Figure 5.

Figure 5:
Click the server icon with the little gear to add members to the DAG

Add the two servers in the list and click “save”.

Figure 6: Adding the servers on the list to the DAG

Let us switch over to the “databases” tab. As you can see, the databases that exist are the default ones created on each server.

Figure 7:
Default database names

We want to rename the databases to MDB1 and MDB2 respectively. To do that open the property page for each and specify the new database name.

Figure 8:
Renaming the default databases

Now it is time to add database copy to each database. To do this, let us switch to the “databases” tab. Here we need to select the database and click on the dots “” and then “Add database copy”.

Figure 9:
Selecting “add database copy” under “databases

Specify the Mailbox server on which a database copy should be created and click “save”.

Figure 10: Specifying the Mailbox server on which the database copy should be created

Repeat the above steps for both databases.

Creating a Public Folder Hierarchy

We also want to create a public folder hierarchy in our lab environment. As some of you probably know the Exchange team put a lot of resources into changing the high availability story for public folders. More specifically, instead of having a less ideal SMTP based high availability (not real HA but that is another story), public folders are now protected by a DAG just like mailboxes. The way this works is by storing the public folder hierarchy and data in special mailbox stored in the same databases as user mailboxes.

To create a public folder hierarchy, in the EAC click “public folders” in the left pane.

Figure 11:
Public folders cannot be created before at least one public folder mailbox exists in the organization

By default, no public folder mailboxes exists, so we must create one in order to be able to create public folders. To do so, switch to the “public folder mailboxes” tab and click on the plus icon “+”.

Figure 12:
Creating a public folder mailbox

Specify a name for the public folder mailbox, an OU for the associated AD account and in which databases the mailbox should be stored. Then click “save”.

Figure 13:
Adding a public folder mailbox

The public folder mailbox and the primary hierarchy has now been created and we can now create public folders.

This concludes part 12 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top