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:

autodiscover.contoso.com – Exchange autodiscover

mail.contoso.com – 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 Exch2010.contoso.com & Exch2010-2.contoso.com using HTTP / HTTPS GET requests to verify connectivity. 

Three publishing rules have been configured as follows:

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 cas.contoso.com (original eh!) and the AD site the array will serve:

New-ClientAccessArray cas.contoso.com -FQDN cas.contoso.com -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 cas.contoso.com

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

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! 

Just found this gem of information on Anderson Patricio’s blog, something which stumped me when setting up some 2010 HA demo’s. 

Exchange 2010 allows you to create a highly available implementation with just two servers (excluding edge), you can combine mailbox, hub and client access on one box, do this twice & use a DAG to replicate the databases & you have highly available Exchange (you can use Forefront TMG to load balance). 

The Exchange 2010 DAG functionality replaces the CCR / SCR technology in Exchange 2007, like CCR DAG requires a file share witness to prevent split brain syndrome.  Typically in Exchange 2007 you would place this on a Hub transport server (having manually created the share & permissions), Exchange 2010 has a wizard to create the FSW on a remote server for you which is handy, however as I found out when I tried to use it against a non Exchange server it didn’t work, I manually created the FSW – putting it down to a Beta / RC bug, however it would appear that you need to add the Exchange Trusted Subsystem group to the local administrators group on the target server to allow the FSW wizard to work.

Rob

Recently I was tasked with performing a mass update on a large HMC / multi tenant style Exchange 2007 implementation.  The update itself was a reasonably simple one – prevent Outlook clients who were not running in cached mode from connecting to their mailboxes (as an aside the reasoning for this was the need to prevent clients with desktop search applications from having a negative performance impact on mailbox servers), the PowerShell cmdlet to do this is ‘Set-CasMailbox’.

In our test environment I executed the following in an Exchange PowerShell session:

Get-CasMailbox -OrganizationalUnit ‘PlatformUsers’ -resultsize unlimited | Set-CasMailbox -MAPIBlockOutlookNonCachedMode:$true

This had the desired effect however took quite some time to run, so looking for a way of speeding this up I stumbled upon the UseRusServer option.  Including this the above command now looks like this:

Get-CasMailbox -OrganizationalUnit ‘PlatformUsers’ -resultsize unlimited | Set-CasMailbox -MAPIBlockOutlookNonCachedMode:$true -UseRusServer <servername>

By using this command Exchange doesn’t have to look for a server running the Recipient Update Service, this makes the process a lot faster (by some rough timings in this environment somewhere between 7-10 times faster) it also meant I had control over which server was used to perform the update against, I chose a server responsible for OAB generation, Exchange could have chosen a mailbox server holding user mailboxes, there likely wouldn’t have been a performance impact but why take the risk.

In the live environment this change affected around 400,000 accounts, so the performance improvement was worth having!

Rob