Exchange 2010 Client Access Arrays

By |2017-12-07T09:36:49+00:00October 21st, 2009|Exchange|0 Comments

Two of the many significant changes coming with Exchange 2010 are the change to DAG’s and to terminate MAPI connections at the Client Access Layer. 

Under Exchange 2007 an Outlook user has the server name configured to that of the mailbox (server / cluster) name, under Exchange 2010 with the concept of DAG’s you no longer connect to the exchange mailbox server directly, your server name is one of your Client Access Servers.  In its out of the box configuration its not very fault tolerant, if the client access server is unavailable the client wont be able to connect.  Client Access Arrays along with load balancing (can be NLB, Forefront TMG or another solution) are the way to tackle this issue.

In this example I have a Forefront TMG (beta 3 – I’ve not upgraded to the RC yet…) server exposed to the internet, behind this I have two Exchange 2010 servers both running Hub, Client Access and Mailbox roles.  There is also a supporting AD, DNS, Certificate infrastructure etc… however I’ve not shown it in the interests of keeping this simple, thanks to Visio it looks like this:


I am publishing the following external names: – Exchange autodiscover – OWA, OA, EWS, ECP, EAS

As we want to load balance / provide fault tolerance for our Exchange 2010 services we have a web farm created with & using HTTP / HTTPS GET requests to verify connectivity. 

Three publishing rules have been configured as follows:

Name Services
OA – Farm OA, OAB, EWS, Autodiscover
EAS – Farm EAS

All publish to the web farm containing the two Exchange servers.  Again in the interests of keeping this simple I’ve not gone into SSL offload & authentication delegation – best practice would have multiple listeners – FBA for OWA, NTLM for OA etc… but I’ve got one public IP so one listener it is!

To configure a client access array the following steps need completing (I’ve not documented the usual steps you would go through to configure your internal and external URL’s – you set these up as usual):

  • Create a client access array

Creating the client access array is simple, all that is needed is to specify an FQDN (an internal name which doesn’t resolve on the internet is fine – the name doesn’t get registered in DNS) and name, in this case I used (original eh!) and the AD site the array will serve:

New-ClientAccessArray -FQDN -Site Default-First-Name-Site

This will create your new array & place all Exchange servers with the client access role in the site specified into your array.

  • Configure mailbox databases to use the client access array – this information is then passed back to the client via autodiscover.
    When the mailbox database has the RPCClientAccessServer field completed this specifies either a client access server or client access server array to be returned to the client through autodiscover. 
    Simple enough to do, this is the command I used:

Set-MailboxDatabase testdb -RpcClientAccessServer

Once this has been set, allow a few minutes for replication & client connections will start to be directed to from autodiscover & existing clients will begin to update their configuration – the Exchange Server field in outlook will become

So should one of your client access servers go offline TMG will send the connection to another server in the farm and the client will continue to work as it has as CAS array name specified rather than an individual server.

There is documentation on technet about this, however it’s still quite vague – as you would expect at this stage, more will come in due course.

Exchange… awesome product!  🙂

Leave A Comment

like what you see? 

Sign-up to our newsletter and never miss out on the latest blogs, events and tech news from the world of risual
Give it a try, you can unsubscribe anytime.