How to Achieve Optimal Availability for Microsoft Exchange

Assigning availability levels to Exchange environments

A meaningful exercise to undertake is to apply various levels of protection to your Exchange infrastructure based on your SLA commitments. First, look at the users and their requirements for Exchange access. Do you have a single SLA in place for all users or do you have multiple user groups with different SLAs? If you have a single SLA in place company-wide, you can deploy those users in workloads based on e-mail usage and assign them a single level of protection. However, if you have different SLAs for different business groups, you can divide those into multiple workgroups on the mailbox server based on their SLA requirements.

For example, if you have an executive group that needs a 24/7 uptime, then you should consolidate those executives in a dedicated Exchange workload and assign a level of protection that will provide continuous availability. Salespeople can often fall into this category as well, requiring non-stop access to e-mail and Exchange collaboration features. Other employees may have less stringent SLAs in place and would require a lower level of protection.

It is also important to keep the components of Exchange—including the Dynamic Host Configuration Protocol (DHCP) server, DNS server and Active Directory server—up and running. If one or more of these components goes down, it would require the IT administrator to manually intervene. This could cause excessive downtime for Exchange and exceed your SLAs. Automatic recovery from failures enables you to keep the Exchange environment operating to meet your SLA commitments.

Assigning a level of protection to the supporting systems (including the DNS, DHCP and Active Directory servers) that's equivalent to those necessary to meet your Exchange SLAs is as important as protecting the actual Exchange servers. Any single point of failure could bring down a well-protected Exchange server.

For remote employees and road warriors, your company may also have a BlackBerry Enterprise Server (BES) and/or Client Access Server (CAS) implementation to serve as a secondary or backup method for remote e-mail access. The BES and CAS implementations should be protected to the level you require based on your remote e-mail access strategy and user SLAs.

Establishing RTO and RPO for SLA commitments, determining the right level of availability protection to meet these commitments, and protecting all components necessary to support an Exchange environment will help create a robust and reliable messaging system.

Tom Reed is Senior Solutions Architect at Marathon Technologies Corporation, where he is responsible for the deployment of mission-critical platforms to support enterprise-computing environments. He can be reached at treed@marathontechnologies.com.