High availability for microsoft exchange server

Every day, more businesses recognize that access to a reliable and available messaging system is fundamental to their success. For many organizations, the messaging system is part of the business continuity plans, and their messaging service deployment is designed with site resilience in mind.

Fundamentally, many site resilient solutions involve the deployment of hardware in a second datacenter. Ultimately, the overall design of a DAG, including the number of DAG members and the number of mailbox database copies, will depend on each organization's recovery service level agreements SLAs that cover various failure scenarios. During the planning stage, the solution's architects and administrators identify the requirements for the deployment, including in particular the requirements for site resilience.

They identify the locations to be used and the required recovery SLA targets. The SLA will identify two specific elements that should be the basis for the design of a solution that provides high availability and site resilience: the recovery time objective and the recovery point objective. Both of these values are measured in minutes. The recovery time objective is how long it takes to restore service.

The recovery point objective refers to how current the data is after the recovery operation has completed. An SLA may also be defined for restoring the primary datacenter to full service after its problems are corrected.

When service for the users of one datacenter fails, those users are activated in the other datacenter. By answering these questions, you begin to shape a site resilient design for your messaging solution. A core requirement of recovery from site failure is to create a solution that gets the necessary data to the backup datacenter that hosts the backup messaging service.

There are no unique or special design considerations for certificates when deploying a DAG in a single datacenter. However, when extending a DAG across multiple datacenters in a site resilient configuration, there are some specific considerations with respect to certificates.

Generally, your certificate design will depend on the clients in use, as well as the certificate requirements by other applications that use certificates. But there are some specific recommendations and best practices you should follow with respect to the type and number of certificates. As a best practice, you should minimize the number of certificates you use for your Exchange servers and reverse proxy servers. We recommend using a single certificate for all of these service endpoints in each datacenter.

This approach minimizes the number of certificates that are needed, which reduces both cost and complexity for the solution. For Outlook Anywhere clients, we recommend that you use a single subject alternative name SAN certificate for each datacenter, and include multiple host names in the certificate. To ensure Outlook Anywhere connectivity after a database, server, or datacenter switchover, you must use the same Certificate Principal Name on each certificate, and configure the Outlook Provider Configuration object in Active Directory with the same Principal Name in Microsoft-Standard Form msstd.

For example, if you use a Certificate Principal Name of mail. Some applications that integrate with Exchange have specific certificate requirements that may require using additional certificates. Because using an OCS server name for the Certificate Principal Name would prevent Outlook Anywhere from working properly, you would need to use an additional and separate certificate for the OCS environment.

In addition to the specific networking requirements that must be met for each DAG, as well as for each server that's a member of a DAG, there are some requirements and recommendations that are specific to site resilience configurations. As with all DAGs, whether the DAG members are deployed in a single site or in multiple sites, the round-trip return network latency between DAG members must be no greater than milliseconds. In addition, there are specific configuration settings that are recommended for DAGs that are extended across multiple sites:.

This configuration is necessary to prevent network heartbeat cross talk. Client-facing DNS records should have a Time to Live TTL value of 5 minutes : The amount of downtime that clients experience is dependent not just on how quickly a switchover can occur, but also on how quickly DNS replication occurs and the clients query for updated DNS information.

Use static routes to configure connectivity across Replication networks : To provide network connectivity between each of the Replication network adapters, use persistent static routes. This is a quick and one-time configuration that's performed on each DAG member when using static IP addresses. If you're using DHCP to obtain IP addresses for your Replication networks, you can also use it to assign static routes for the replication, thereby simplifying the configuration process.

Humans of IT. Green Tech. MVP Award Program. Video Hub Azure. Microsoft Business. Microsoft Enterprise. Browse All Community Hubs. Turn on suggestions. Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type. Showing results for. Show only Search instead for. Did you mean:. Sign In. High Availability in Exchange Server The Exchange Team.

Published Dec 15 PM For example, you might want to start with this four-part video blogcast on high availability in Exchange High Availability in Exchange Server - Part 1 High Availability in Exchange Server - Part 2 High Availability in Exchange Server - Part 3 High Availability in Exchange Server - Part 4 Next, visit the Exchange library in TechNet, where you can read topics that will help you understand high availability and site resilience in Exchange A transport server feature that provides redundancy for messages for the entire time they're in transit.

A configuration that extends the messaging infrastructure to multiple Active Directory sites to provide operational continuity for the messaging system in the event of a failure affecting one of the sites. A DAG is the base component of the high availability and site resilience framework built into Exchange Server.

A DAG is a group of up to 16 Exchange servers that hosts a set of databases and provides automatic, database-level recovery from failures that affect individual databases, networks, or servers.

When a server is added to a DAG, it works with the other servers in the DAG to provide automatic recovery from failures that affect mailbox databases, such as a disk failure or server failure. For more information about DAGs, see Database availability groups.

The high availability and site resilience features used first introduced in Exchange are used in Exchange Server to create and maintain database copies. Exchange Server also leverages the concept of database mobility, which is Exchange-managed database-level failovers. Database mobility disconnects databases from servers and adds support for up to 16 copies of a single database.

It also provides a native experience for creating copies of a database. Setting a database copy as the active mailbox database is known as a switchover. When a failure affecting a database or access to a database occurs and a new database becomes the active copy, this process is known as a failover. This process also refers to a server failure in which one or more servers bring online the databases previously online on the failed server.

When either a switchover or failover occurs, other Exchange servers become aware of the switchover almost immediately and redirect client and messaging traffic to the new active database. For example, if an active database in a DAG fails because of an underlying storage failure, Active Manager will automatically recover by failing over to a database copy on another server in the DAG.

In Exchange Server, managed availability provides behaviors to recover from loss of protocol access to a database, including recycling application worker pools, restarting services and servers, and initiating database failovers.

For more information about mailbox database copies, see Mailbox database copies. Exchange Server leverages Active Manager to manage the database and database copy health, status, continuous replication, and other aspects of high availability. For more information about Active Manager, see Active Manager. In Exchange , you could deploy a DAG across two datacenters and host the witness in a third datacenter and enable failover for the Mailbox server role for either datacenter.

But you didn't get failover for the solution itself because the namespace still needed to be manually changed for the non-Mailbox server roles. Exchange leverages fault tolerance built into the namespace through multiple IP addresses, load balancing and if need be, the ability to take servers in and out of service.

Modern HTTP clients work with this redundancy automatically. In a soft failure connection is lost after the session is established, perhaps due to an intermittent failure in the service where, for example, a device is dropping packets and needs to be taken out of service , the user might need to refresh their browser. This means the namespace is no longer a single point of failure as it was in Exchange In Exchange , perhaps the biggest single point of failure in the messaging system is the FQDN that you give to users because it tells the user where to go.

And you have name caches in browsers that are typically about 30 minutes or more that also have to be handled. In Exchange Server, clients have more than one place to go. What is meant here is that if you have applications that needs to relay off your server. In this case, you can create a connector and load balance to accept these connections. Office Office Exchange Server. Not an IT pro? SQL Server. Sign in. United States English. Home R2 Library Forums. Ask a question.