Exchange Server 2013 Preview – Part 4: Configure DAG, CAS Array and Public Folders

Andersson · August 1, 2012

In this series of posts, you can read about the fresh release of Exchange 2013 beta/Preview.

The posts are done as “how-to” posts with configuration examples from both Exchange Administration Console (EAC) and Exchange Management Shell (EMS).

Earlier parts can be found below:

Part 1: Installation guide

Part 2: Basic configuration

Part 3: Continue of configuration, URL’s etc.

At the end of the post, I will link to some interesting TechNet articles around High Availability, Disaster Recovery, Site resilience and Public Folder migration.

Note: My posts around Exchange 2013 Preview/beta are based on Beta information and it could be changed before it will be released (RTM).

Database Availability Group (DAG)

If this expression is new to you, here are some background information.

The DAG is the new cluster technology from Exchange 2010 and also included in 2013. It give us the opportunity to have a mailbox database replicated between two or more servers, the DAG can have utilize up to 16 copies of each database (16 different servers). The advantage of this is that if one server fails, it’s easy and very fast for doing switchover/failover to another server.

Some interesting changes around databases are that each database runs under it’s own process in Windows. Store (ESE) is totally rewritten, again.. which means you can’t use databases from older versions of Exchange directly on Exchange 2013. I have also read that IOPS requirements for databases have been reduced with another 50% from Exchange 2010, but I haven’t read it officially so maybe it’s just a rumor. We’ll see what happens when it’s being release and probably Microsoft will release an update mailbox calculator.

DAG is available for both Standard and Enterprise version of Exchange, and supported to run on both Windows 2008 R2 and Windows Server 8. Though all DAG members needs to run the same OS version.

Let’s get ready to create the DAG and add the Databases as copies on each DAG member/node.

Using EAC: It’s time to like the new EAC “console”.

Running “ipconfig” on both mailbox servers, for checking the IP addresses. Both for the MAPI network and the Replication network.

Go into Control Panel and check the network interfaces,

Login to the EAC, go to Servers and select Database Availability Group. Press Add button (+).

Type in DAG name, Witness Server, Witness directory and DAG IP. Press Save.

When the DAG is created, select it and Press Edit. Check the option “Configure database availability group network manually”. Press Save.

It’s now time for adding the mailbox servers into the DAG, this by pressing “Manage membership” button.

Press the Add button (+) and add the mailbox servers.

Add the mailbox servers that should reside in the DAG. Press OK.

Press Save.

The configuration now gets saved, failover clustering was installed on mailbox servers. Press Close.

Next thing to do it the DAG Networks, as you can see in the right bottom corner, a network called “MapiDagNetwork” has been created. I want to have the control over these networks so I will create my own.

Start by pressing “New DAG Network”. I’m about to create two new networks.

I will give the first network a name like MAPI Network, and assign the Subnet to it where the clients are supposed to connect. Press Save.

My second network will be called Replication Network, since that it’s purpose and also assign it to the correct Subnet. Press Save.

Since we now have created those two network, let’s remove the automatic created one by pressing “Remove” button.

Press OK.

The MAPI Network is not supposed to be used as replication network, so let’s disable that function by pressing “Disable Replication” on the MAPI network. Press OK.

The DAG should now show two networks called MAPI and Replication. The MAPI Network should not be enabled for replication.

Final DAG configuration

The last step (just a recommendation) is to enable the DAC mode, this for preventing split brain syndrome. Which means that you end up with having same database mounted on two (or more) different servers. More info about DAC mode can be found on the link in the end of the post.

This can’t be done through EAC (maybe that will change to RTM). So let’s start up Exchange Management Shell (EMC).

Set-DatabaseAvailabilityGroup –Identity DAG01 –DatacenterActivationMode DagOnly

Database copies

On each mailbox database we now need to add a copy to another server for having the redundancy.

In the menu, go to Databases and select one database, then press the Add database copy button.

Specify mailbox server that at the moments doesn’t hold a copy of the database and add it by pressing the browse button. Press Save.

Note: In this menu you also have the option to configure lag time (if using lagging node).

The database now get’s copied (Seeding).

Then do the same procedure on all of your databases.

Press Close, when the operation is done.

Do the same procedure on all of your databases.

The seeding operation is running.

Press Close.

It might take a while (some minutes..) until it get’s Healthy and everything has been checked and verified.

In my test environment it took around 15min to be fine. It should look like the picture below when everything is completed.

Using PowerShell: The Web interface is nice to work with. But I prefer the PowerShell, because I have the full control over what’s going on.

Let’s start with creating the DAG by using the command below:

New-DatabaseAvailabilityGroup –Name DAG01 –WitnessServer TLCAS01 –WitnessDirectory C:\FSW_DAG01 –DatabaseAvailabilityGroupIpAddresses 172.16.1.15

Configure the DAG so that the networks can be manually configured:

Set-DatabaseAvailabilityGroup –Identity DAG01 –ManualDagNetworkConfiguration $True

Add the mailbox servers into the DAG:

Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer TLMB01

Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer TLMB02

Enable DAC mode for the DAG:

Set-DatabaseAvailabilityGroup –Identity DAG01 –DatacenterActivationMode DagOnly

List the DAG Networks:

Get-DatabaseAvailabilityGroupNetwork

Create two new DAG Networks, one for Mapi and one for Replication:

New-DatabaseAvailabilityGroupNetwork –DatabaseAvailabilityGroup DAG01 –Name Mapi –Description “Mapi Network” –ReplicationEnabled $False –Subnets “172.16.1.0/24”

New-DatabaseAvailabilityGroupNetwork –DatabaseAvailabilityGroup DAG01 –Name Replication –Description “Replication Network” –ReplicationEnabled $True –Subnets “10.0.0.0/8”

Remove the automated created network, it will not be used:

Remove-DatabaseAvailabilityGroupNetwork –Identity DAG01\MapiDagNetwork

Database copies

On each mailbox database we now need to add a copy to another server for having the redundancy.

Specify a mailbox server that at the moments doesn’t hold a copy of the database and add it by running the following commands.

Add-MailboxDatabaseCopy –Identity DB01 –MailboxServer TLMB02

Add-MailboxDatabaseCopy –Identity DB02 –MailboxServer TLMB02

Add-MailboxDatabaseCopy –Identity DB03 –MailboxServer TLMB02

Verify the replication status on each mailbox server:

Get-MailboxDatabaseCopyStatus –Server TLMB01

Get-MailboxDatabaseCopyStatus –Server TLMB02

Public Folders

The Public Folder databases are now gone, and transferred to “normal” mailboxes instead. The advantage of this is that the mailbox itself can now be replicated using DAG technology. This doesn’t mean that the public folder contents is replicated, it’s still required that you configure the public folder replication for the contents.

With “normal” mailbox I mean that they reside in the mailbox databases, just like user mailboxes does. However they can in someway be compared to shared and room, those are also special mailboxes.

If you decide to use the Public Folders in Exchange 2013, the first step will be to create a mailbox that holds the public folder hierarchy. This will be the writeable copy, you can have copies of the hierarchy. But you can only have one that is allowed to make changes/writeable.

How can the hierarchy mailbox be created?

Using EAC: Go to Public Folders section, this is the first warning/error message you will receive.

It means that you don’t have any public folder hierarchy (mailbox) created yet.

Go to the second public folder selection called “Public Folders Mailboxes”. Add (+), create the first mailbox for the public folders, so it’s hierarchy can be saved.

Give the mailbox a friendly name, example: PF_Hierarchy, place it into an organizational unit and select a mailbox database where it should be saved into. Press Save.

Now when the hierarchy is created, let’s create some test folders too.

Go back to “Public Folders”, press the Add (+) button. Give the public folder a name. Press Save.

If you want to configure any storage quota on the public folder content, press Edit and configure it. Statistics can also be found under Edit selection, which sometimes is valuable.

Just for testing purposes I did mail-enable the folder. By pressing the Enable button.

Press Yes.

Let’s check the properties for the folder again, now we see that we have lots of new settings. Here’s a small example how the Mail Flow settings looks like.

Using PowerShell: Start up Exchange Management Shell, the following commands will be used for creating the public folder hierarchy and contents folder.

Create the hierarchy by running the following command

New-Mailbox –Name PF_Hierarchy –Alias PF_Hierarchy –Database DB01 –OrganizationalUnit Users

This mailbox, like shared/room mailboxes is also disabled by default. This for not having the possibility to logon as this user.

Let’s create the folder named Testlabs

New-PublicFolder –Name Testlabs

Finally, mail enable the public folder

Enable-MailPublicFolder –Identity \Testlabs

We have public folders located in Exchange 2007/2010, what about them?

In the end of this post, you can find a link to a TechNet article, it provides you with a great step-by-step guide. I haven’t tried to migrate public folder contents from earlier versions of Exchange since SP3 for Exchange 2010 is required for having coexistence between Exchange 2010 and Exchange 2013. SP3 is right now under development/testing and no official information can be found.

When I get my hands on SP3, this will be one of the first things to try out.

Client Access Server Array

In my previous blog post I did write about some news regarding MAPI and RPC, where I did mention what changes been made. It can be found here.

The “new” Client Access Server role can now been seen as more of a traditional Front-End server.

It utilize as a front-end connection point and redirects/proxies (depending on method) the clients to it’s correct mailbox server.

After the architectural change around the CAS role, it’s now “stateless” which means there’s no need for the load balancer to configure affinity/sticky session. For example, it means that the clients is not required to have the connection established to the same CAS server for having the OWA to work. This means that all CAS servers now will serve all clients with connections to it’s mailbox endpoint server.

How to create a client access array?

Right now, I don’t see any specific reason for creating the CAS Array, since the traffic will be proxied from the CAS servers to the correct active Mailbox servers.

In an upcoming blog post I will cover how to configure the load balancing for Exchange 2013.

Upcoming topics: load balancing Exchange 2013 using different load balancers, database fail-over, move mailbox reports, disaster recovery etc.

But first it’s time for 3 weeks of vacation, until then. Keep on reading the posts and you’re more than welcome to comment on them.

Thanks for reading, I hope it did gave you some valuable information.

More information:

High Availability

http://technet.micro...exchg.150).aspx

DAC mode

http://technet.micro...y/dd979790.aspx

Client Access Server

http://technet.micro...14(v=exchg.150)

Public Folder migration scenario