Although a Database Availability Group can provide high availability for the databases hosted on the Mailbox servers, the Client Access server needs to be considered separately for HA.
In Exchange 2010 high availability for the Client Access server was achieved through the configuration of a CAS Array and some form of load balancing (hardware/virtual, or Windows NLB). Although the CAS Array no longer exists in Exchange 2013, and other architectural changes mean that load balancing can be approached in different ways, the basic concept of a single namespace for Outlook connectivity remains.
Here is a general demonstration of configuring high availability for Exchange 2013 Client Access servers.
To begin with, two Client Access servers have been deployed in a site. The servers are multi-role servers and are also members of the DAG that has been deployed. A third server is installed with only the Mailbox server role and is a member of the DAG as well.
A mailbox user connecting via Outlook 2013 is connected to server E15MB2, as shown here in the Outlook connection status dialog. There was no manual configuration required for this, it is just how Outlook autodiscovered the endpoint to connect to.
The mailbox databases are currently active on E15MB2.
[PS] C:\>Get-MailboxDatabase -status | select name,mounted,mountedonserver Name : Mailbox Database 1 Mounted : True MountedOnServer : E15MB2.exchange2013demo.com Name : Mailbox Database 2 Mounted : True MountedOnServer : E15MB2.exchange2013demo.com
The trouble begins when E15MB2 goes offline. The databases are able to failover to other DAG members and remain available.
[PS] C:\>Get-MailboxDatabase -status | select name,mounted,mountedonserver Name : Mailbox Database 1 Mounted : True MountedOnServer : E15MB1.exchange2013demo.com Name : Mailbox Database 2 Mounted : True MountedOnServer : E15MB3.exchange2013demo.com
However the mailbox user is no longer able to connect to E15MB2 and access their mailbox.
Eventually Outlook may autodiscover other available Client Access servers in the site and connect to one of them, but it is not an ideal user experience.
To improve this situation we need to look at the Outlook Anywhere configuration for the Client Access servers. If you’re not already familiar with Outlook Anywhere from previous versions of Exchange it is the service that provides RPC/MAPI connectivity for Outlook clients over HTTP or HTTPS. While this was typically only used for remote/external access in the past, architectural changes in Exchange 2013 mean that all Outlook connectivity is via HTTP/HTTPS even for internal clients.
At the moment each of the servers is configured with their own name as the internal host name for Outlook Anywhere, which is the default.
[PS] C:\>Get-ClientAccessServer | Get-OutlookAnywhere | select identity,*hostname Identity : E15MB1Rpc (Default Web Site) ExternalHostname : InternalHostname : e15mb1.exchange2013demo.com Identity : E15MB2Rpc (Default Web Site) ExternalHostname : InternalHostname : e15mb2.exchange2013demo.com
We can configure a single namespace for these instead of the unique server FQDN for each. Note that when configuring the InternalHostName you also need to set the InternalClientsRequireSSL option as well. To keep this example simple I am not requiring SSL for internal clients.
[PS] C:\>Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname mail.exchange2013demo.com -InternalClientsRequireSsl $false
We also need to make sure that the DNS records exist for that namespace and resolve to the Client Access servers. With no load balancer available to me at this stage I am using DNS round robin, which is not as good as proper load balancing but will do the job for now.
PS C:\> Resolve-DnsName mail.exchange2013demo.com Name Type TTL Section IPAddress ---- ---- --- ------- --------- mail.exchange2013demo.com A 3600 Answer 192.168.0.187 mail.exchange2013demo.com A 3600 Answer 192.168.0.188
The change made with Set-OutlookAnywhere is not instantaneous. It takes about 15 minutes for the Client Access server to update with the new configuration. You’ll be able to tell it has taken effect when an Outlook autoconfiguration test returns the new value for Exchange HTTP.
After waiting a while and then restarting Outlook the client is connecting to the newly configured namespace. I left this for about 30 minutes before restarting Outlook only because I wanted to test the result quickly. In the real world you could just let users restart Outlook in their own time (eg the next business day).
Netstat shows me that the client has resolved mail.exchange2013demo.com to 192.168.0.188 and Outlook is connecting to E15MB2 at the moment.
C:\>netstat -ano | findstr ":80" TCP 192.168.0.181:50967 192.168.0.188:80 ESTABLISHED 2272 TCP 192.168.0.181:50968 192.168.0.188:80 ESTABLISHED 2272 TCP 192.168.0.181:50979 192.168.0.188:80 ESTABLISHED 2272 TCP 192.168.0.181:50980 192.168.0.188:80 ESTABLISHED 2272
So to test high availability I shut down E15MB2 while observing the Outlook connection status dialog.
Without the aid of a load balancer the Outlook clients takes about 20 seconds to time out and then re-establish connectivity to the other IP address that mail.exchange2013demo.com resolves to. A much better user experience than before the Outlook Anywhere namespace was configured on the Client Access servers.
C:\>netstat -ano | findstr ":80" TCP 192.168.0.181:51010 192.168.0.187:80 ESTABLISHED 2272 TCP 192.168.0.181:51011 192.168.0.187:80 ESTABLISHED 2272 TCP 192.168.0.181:51012 192.168.0.187:80 ESTABLISHED 2272 TCP 192.168.0.181:51013 192.168.0.187:80 ESTABLISHED 2272
So there you have it, a basic demonstration of Exchange 2013 Client Access server high availability. In upcoming articles we’ll look further at load balancing options for Exchange 2013 CAS, as well as how to configure the external hostname and the SSL options for Outlook Anywhere.