TMCnews Featured Article

The improved high availability story for messaging environments in MS Exchange 2010, in addition to the simple, out-of-the-box method for setting up multiple copies of Mailbox server databases with replication and automatic failover, works great and is a time saver for Exchange admins. However, setting up database availability groups (DAGs) in Exchange 2010 is not a smooth process. Some common problems and mistakes still exist.

Exchange Server MVP, Jim McBee, discusses some of these problems that he has encountered while configuring DAGs in Exchange 2010. The first of these is the lack of understanding of quorum. According to McBee, it is important to understand quorum and the voting procedure to avoid surprises when failures occur. It is also good to keep in mind that Exchange DAGs are based on the Windows Failover Clustering and its quorum model which always has to be up and running if the cluster service is to permit the databases to continue to operate.

Loading balancing is an important aspect of Exchange 2010 for effective Client Access server connectivity maintenance. Inefficient load balancing during deployments could render DAGs moot. Overlapping with this point is treating a DAG like an active/passive cluster to distribute active clusters across servers. McBee recommends learning about activation preferences to “maximize the use of your hardware and ensure if either node fails, only half of the users have to fail over to the alternate server.”

McBee also recommends documenting the processes for managing these systems and what needs to be done when moving databases or performing maintenance. While Exchange admins and IT pros are very hands-on type of people, McBee says that they “need to know exactly what would be necessary in order to take one server offline or to bring it back online” by writing down an instruction manual.

Failing to complete the upgrade process is another concern that needs to be addressed. Just because you’ve got all users on Exchange 2010 mailboxes is not enough. You need to address legacy issues such as addresses lists, public folder replication, Exchange email address policies and the like. Testing all functions of Exchange 2010 during a pilot test is also recommended, including moving databases between servers and “ensuring that backup and recovery procedures are working properly before putting production users on the system.”

McBee discusses other problems and offers good advice in the Exchange environment in a webinar which can be viewed on demand.

Want to learn more about cloud communications? Then be sure to attend Cloud Communications Expo, collocated with ITEXPO West 2012 taking place Oct 2-5, in Austin, TX.  Stay in touch with everything happening at Cloud Communications Expo. Follow us on Twitter.