Exchange 2010 Backup-Less Configuration

How would you like to never have to do another backup of your Exchange 2010 environment again? Well if you are using or intend on implementing DAG within your Exchange 2010 environment, then read on to revolutionize your backup strategy!!

When Exchange 2010 was in Beta I heard the rumours that if configured properly you could do away with traditional tape or disk based backups and use the High Availability functionality of DAG to achieve maximum up time. In fairness, since then I then thought nothing else of it and never looked into how exactly you could go about creating this type of solution - until now!

I received a request from a customer to investigate the possibility of implementing this within their existing DAG environement and I am very impressed with the information I found and the process involved in implementing it.

Here's a quick summary of whats involved in implementing the solution:

The requirements needed for a backup-less implementation of Exchange 2010 DAG are as follows:

• Windows Server 2008 Enterprise on all Exchange 2010 servers
• Exchange Server 2010 Standard or Enterprise Edition
• Circular Logging Enabled
• A minimum of 3 DAG copies of each active mailbox database within the DAG environment spread across different geographical locations for disaster recovery
• Lagged copies of each database preferably stored on a separate Exchange 2010 server within the DAG environment that has DAG Activation disabled
• Deleted Item Retention Policies to be reviewed
• Single Item Recovery Enabled on either each entire mailbox database or the top priority mailbox users within the organisation – i.e. Senior Management mailboxes
• Public Folder Replication Policies need to be in place if Public Folders are in use

The most comprehensive and intuitive source that I found on this topic comes from the guys over at msexchange.org. Exchange MCM and MVP Henrik Walther has created an excellent four part guide on this exact solution and you can view the entire postings from the links below:

http://www.msexchange.org/articles_tutorials/exchange-server-2010/high-availability-recovery/eliminating-traditional-backups-using-native-exchange-2010-functionality-part1.html

http://www.msexchange.org/articles_tutorials/exchange-server-2010/high-availability-recovery/eliminating-traditional-backups-using-native-exchange-2010-functionality-part2.html

http://www.msexchange.org/articles_tutorials/exchange-server-2010/high-availability-recovery/eliminating-traditional-backups-using-native-exchange-2010-functionality-part3.html

http://msexchange.org/articles_tutorials/exchange-server-2010/high-availability-recovery/eliminating-traditional-backups-using-native-exchange-2010-functionality-part4.html

Now, time to throw away those backup tapes...................................!!!

Increase Exchange 2010 DAG Failover Threshold

One of our clients has a 4 member node Exchange 2010 DAG spread across 4 different countries worldwide.

The client had reported to me that one of the sites that had a slight bandwidth issue was consistently failing it's Active Mailbox Store from the local site over to it's Dublin HQ site. When we manually moved the database back over to the original local site, it would randomly fail back over to the main Dublin HQ site presumably due to the intermittent latency on the Internet connection at that local site.

The customer requested that I find a way to increase the failover threshold or tolerance for the DAG so that it doesn't fail over as frequently without losing the functionality of High Availability.

After searching for quite a while on how to do this using Exchange Power Shell I found some information relating not to Exchange Server but to the Windows Server 2008 Cluster Service (which is essentially what the DAG uses when it is created for the first time) for it's clustering technology.

Using a standard Command Prompt (cmd), I started playing with the 'cluster' command and looking into what switches it used and what they could be applied to.

Here's what I came up with:

Type 'cluster /list' to display the name of the cluster that is present on the Server

When you run a 'cluster /prop' from the cmd line, it returns a number of values relating to the cluster, two of which are the following:

CrossSubnetDelay = 1000 (this is the default 1000 milliseconds which equals 1 second per heartbeat check)

CrossSubnetThreshold = 5 (this is the default number of heartbeats that can be missed before failover)

I changed the CrossSubnetDelay value to make the heartbeat check in every 2 seconds instead of the default 1 second by using the command below:

cluster /cluster:<ClusterName> /prop CrossSubnetDelay=2000

With this new setting along with the default value of 5 seconds for the CrossSubnetThreshold setting, this now allows the Cluster service to wait for 10 seconds before initiating a failover to a different DAG member.

This value can be increased to a maximum of 4000 milliseconds once the cluster is across subnets (it is a maximum of 2000 milliseconds if you are on the same subnet)

The CrossSubnetThreshold value can be modified with a value anywhere from 3 to 10.

This workaround / solution may need some tweaking with values until you reach the desired tolerance on your DAG.

It is also worth making sure you make a note of all changes that you make before and after the above commands and as always - make sure you have a full backup of your Exchange environment before you do anything like this!!!!