The Exchange Server 2010 Client Access Server role is responsible for client connectivity to mailboxes. All client connection methods are provided by the Client Access server, including:
- MAPI (eg connecting via Outlook on the LAN)
- HTTPS (eg Outlook Web App, ActiveSync, or Outlook Anywhere)
- IMAP
- POP3
The only client connections to Mailbox server resources that the Client Access server does not provide are Outlook clients connecting to Public Folder databases. Outlook connects directly to the Mailbox server for public folders.
What Needs to be Backed Up on Client Access Servers?
To plan for backup and recovery of the Client Access server you should start by knowing where the server stores its configuration and data.
Active Directory – the majority of the Client Access server configuration is stored in Active Directory. For example the internal and external URL settings of the OWA virtual directory are stored in Active Directory.
![Exchange 2010 Client Access server settings stored in Active Directory Exchange 2010 Client Access server settings stored in Active Directory](https://www.practical365.com/wp-content/uploads/2010/10/exchange-server-2010-client-access-owa-settings.png)
However not all of the settings for these Client Access server features are stored in Active Directory.
System State – the system state of the Client Access server stores important information such as the SSL certificates installed on the server, and service configuration information (eg dependencies and startup options). If the server is a member of an Exchange 2010 CAS array the NLB configuration is also stored in the system state. Finally if there are other applications installed on the server then those will likely have settings stored in the registry as well.
File System – because of the Client Access server’s integration with IIS there are multiple configuration files stored on the file system itself for components such as the OWA virtual directory. The IIS root config file (aka the IIS metabase) is also stored in the file system.
Planning the Client Access Server Backup
As you plan the Client Access server backup strategy there are different techniques that you can consider depending on your requirements.
Backing up Everything
A full system backup of the Exchange 2010 Client Access server, along with a working Active Directory, will have all of the required information to recover the Client Access server. Naturally this backup takes the longest to run, and will use up the most backup storage.
Backup up the Minimum
To reduce backup storage and keep the backup time frame shorter the minimum data on the Client Access server can be backed up. This involves backing up the system state of the server, and configuration files stored in the ClientAccess path of the Exchange Server 2010 installation folder (C:Program FilesMicrosoftExchange ServerV14 by default).
Backing up Nothing
It may be practical to not back up the Client Access server at all if:
- There are multiple, redundant Client Access servers deployed (ie Client Access Server Array)
- The SSL certificates are exported or retrievable from elsewhere
- Customizations to the Client Access server virtual directories can be quickly reapplied using an existing script
If all of those conditions are true then the Client Access server may not need to be backed up at all.
Backing Up and Restoring Client Access Servers
In this demonstration a Client Access server has been configured as a single-node NLB cluster and Exchange 2010 CAS array.
![Exchange 2010 Client Access server configured with NLB Exchange 2010 Client Access server configured with NLB](https://www.practical365.com/wp-content/uploads/2010/10/exchange-server-2010-client-access-nlb.png)
The external URL has also been configured.
[PS] C:\>Get-OwaVirtualDirectory | fl name, *URL* Name : owa (Default Web Site) Url : {} Exchange2003Url : FailbackUrl : InternalUrl : https://ex3.exchangeserverpro.local/owa ExternalUrl : https://mail.exchangeserverpro.local/owa
Recovering an Exchange 2010 Client Access Server
Because most of the Client Access server configurtion is stored in Active Directory when a Client Access server has failed you can recover the server using the following procedure.
- Install a new server to host the Client Access server role
- Configure the server to have the same name, IP address, and domain membership as the server that failed
- Install the Exchange Server 2010 pre-requisites
- Perform a recovery mode install of Exchange Server 2010
To run Exchange Server 2010 setup in Recovery Mode use the following command from an elevated command prompt.
setup /m:recoverserver
Setup performs a server recovery using the configuration information stored in Active Directory.
Welcome to Microsoft Exchange Server 2010 Unattended Setup By continuing the installation process, you agree to the license terms of Microsoft Exchange Server 2010. If you don't accept these license terms, please cancel the installation. To review these license terms, please go to http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/ ............... No key presses were detected. Setup will continue. Preparing Exchange Setup Copying Setup Files ......................... COMPLETED The following server roles will be recovered Client Access Role Management Tools Performing Microsoft Exchange Server Prerequisite Check Client Access Role Checks ......................... COMPLETED Configuring Microsoft Exchange Server Preparing Setup ......................... COMPLETED Stopping Services ......................... COMPLETED Copying Exchange Files ......................... COMPLETED Restoring Services ......................... COMPLETED Client Access Server Role ......................... COMPLETED Exchange Management Tools ......................... COMPLETED Finalizing Setup. ......................... COMPLETED The Microsoft Exchange Server setup operation completed successfully. Setup has made changes to operating system settings that require a reboot to tak e effect. Please reboot this server prior to placing it into production.
After the reboot you can verify that some configurations have been recovered, such as the OWA virtual directory URLs. However any other customized configurations that were stored in the system state or the file system are not recovered by this process. Those settings will need to be reapplied from the minimal backups, or reapplied manually or by using a script.
Full System Backup/Restore for Exchange 2010 Client Access Servers
For this demonstration I used Windows Server Backup to perform a full system backup of the Client Access server for use in a bare metal restore.
![Exchange 2010 Client Access server full system backup Exchange 2010 Client Access server full system backup](https://www.practical365.com/wp-content/uploads/2010/10/exchange-server-2010-full-backup.png)
Even though this Exchange Server backup can take the longest it is the simplest to restore from because it will restore the Client Access server as it was at the time of backup.
![Exchange Server 2010 Client Access server restore from backup Exchange Server 2010 Client Access server restore from backup](https://www.practical365.com/wp-content/uploads/2010/10/exchange-server-2010-client-access-restore.png)
Summary
You can see there are positives and negatives to the backup strategies for the Client Access server role in Exchange Server 2010. For most organizations the full backup/restore method will be the simplest to implement and maintain. Larger environments with multiple Exchange 2010 Client Access servers may prefer to backup the minimum instead, or even backup nothing at all, and rely on redundancy to keep services up while the Client Access server is recovered and reconfigured manually or via scripts.
Back to the full series on Exchange Server 2010 backup and recovery.
Pingback: get your lifelock coupon here
I have been working on disaster recovery scenearios in a virtual environment. I have been able to restore everything properly other than one niggling issue with the client access role.
I have built up the virtual machine with the same OS, hostname, and IP. The original AD computer account was reset to allow joining the machine to the domain.
I ran a /m:RecoverServer from the SP2 installer.
I restored the databases from backup.
At this point all mail functions work properly, and I am able to login to OWA, but there is one difference between live and this virtual test. When logging into OWA the live environment only requires the username of a user wanting to login. The test environment requires domainusername.
I know how to set this setting using Powershell and the GUI, but I am worried that there are other settings I do not know about that have not been properly restored.
I did try restoring: C:Program FilesMicrosoftExchange ServerV14ClientAccess with both overwriting and not overwriting. The issue is that after restoring the folder, OWA does not even load. The browser window comes up blank with no option to login.
Any thoughts?
The Real Person!
The Real Person!
I *suspect* what is happening with the OWA logon format is that particular setting is stored in IIS metabase/config not AD, therefore the /RecoverServer doesn’t restore that setting. I haven’t looked at this scenario in a while though so I’m not 100% sure.
A System State restore of the server would probably sort that out, but has other implications that I couldn’t fully cover off the top of my head.
So what I think would be the wisest course of action is to record/document all virtual directory configuration changes. Then you can use the document as part of your recovery procedure, or even create a script to automate those parts.
HI Paul,
I have been testing your method in the lab trying to recover a CASHUB server and it keeps failing, but it does reference “no more endpoints available from the endpoint mapper”.
and it also mentions bridgeheadrole in the logs.
Any clue how to get around this?
Hey Paul,
I figured it out, the firewall service was shut off and that is what caused that error. Once i enabled the firewall service the recovery completed successfully.
Great article thanks.
Good information..
But i have a scenario in which i have to deploy a seprate CAS for fault tolerance in remote location. If our primary cas down then it should be accessible by our remote CAS. Is the above task is sufficient for this scenerio or something else that i should have to do ..
Thanks
Zaheer
Hi Paul, thanks for your post. I can’t remember if I have received a free copy of Beginner’s Guide to Exchange Server 2010 ActiveSync. I would like to have it please.
Thanks
We have a CAS array setup but all of the hardware is in the same physical location. Does it make sense to backup system state/file system for all or one of the CAS servers using tape?
The Real Person!
The Real Person!
Depends, how quickly do you want to be able to restore all of your servers? If being able to restore just one of them from backup while you then manually rebuild the others is good enough, then just do that. Otherwise back up as many as you need to so that you meet your SLAs.
Thanks for the post. I was just challenged on if I need a CAS array with HLB for 1200 users.
If the restore for the CAS is this simple I may not need a CAS array.
If I virtualize the CAS and take veeam snaps each weekend could I just use the snap if I have a CAS failure?
The Real Person!
The Real Person!
Hi Jason, quite possibly. Best you test the process to make sure it meets your recovery SLAs.
Pingback: Recovering from a failed CAS or Hub Transport server « Chad Solarz's IT blog
Pingback: Backup e Recovery do CAS no Exchange 2010 « Elieser Lemos – IT for life
Pingback: Backup e Recovery do CAS no Exchange 2010 « Rodrigo Rodrigues .:. www.andersonpatricio.org