In my last post I wrote about scaling Transport servers to meet the growing needs of an organization.  In this post I will look at the same topic for Client Access servers.

Client Access Servers

The role of the Client Access server for Exchange Server 2007 is to accept all non-MAPI client connections and communicate on their behalf with the appropriate mailbox server.

An example of this would be Outlook Web Access, where a user connects with their web browser to a webmail interface on the Client Access server instead of directly to their mailbox using the full Outlook client.

The Availability Service is another example of Client Access server functionality.

Most of the traffic that Client Access servers process uses SSL encrypted connections.  Encrypted traffic requires more processing resources than non-encrypted traffic.  This means that the most important resource for a Client Access server will be the processors, however memory and disk performance also play a role and can cause bottlenecks if not appropriately sized.

Processor Scaling

A Client Access server is recommended to start with at least 4 processor cores, but very smaller environments can perform well with just 1 or 2 cores, even with multiple server roles consolidated onto a single server.

A single server can scale up to 6 processor cores if necessary to handle load.  It is not recommended to scale beyond 6 cores per server.  If processor bottlenecks are found with 6 cores it is time to scale out to more Client Access servers.

Memory Scaling

For Windows servers memory is important for caching of data for fast access by the processors.  Insufficient memory would lead to excessive page file usage on the server and higher disk I/O, slowing the server down.

The minimum recommended memory for a Client Access server is 2Gb, but as a general rule the server should contain 2Gb of memory per processor core.  So for example a 4 core server would require at least 8Gb of memory.

Client Access server memory can scale up to 16Gb (which is more than 2Gb per core for the maximum 6 cores) but beyond that you will encounter diminishing returns as you add more.

Disk Scaling

Client Access servers do not require a great deal of disk capacity in gigabytes, but will benefit from fast disks for read/write operations particularly for the Internet Information Service (IIS) that is core to the Client Access server’s role.

Because fast disk is quite common in servers these days most organizations will not hit disk bottlenecks on Client Access servers.

Scaling Impacts

The Client Access server does not contain any built-in clustering or load balancing intelligence.  Once an organization scales out to two or more Client Access servers it introduces extra considerations.

It will be desirable to load balance the incoming Client Access server connections for both performance and high availability purposes.  For those organizations without an existing load balancing infrastructure (such as hardware appliances or ISA Server firewalls) the Windows Network Load Balancing features can be used to form an NLB cluster of the Client Access servers.

In the next post in this series I will discuss scaling considerations for the Mailbox Server role.

Scaling Up vs Scaling Out Exchange Server 2007 Roles Part 2 – Client Access Servers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In Part 1 of this series I explored the backup requirements for each of the Exchange Server 2007 server roles.  In Part 2 I demonstrated Mailbox server database backup and recovery, and then in Part 3 I demonstrated the backup and recovery process for Hub Transport and Edge Transport servers.  In this part 4 of the series I will discuss the backup and restore process for Client Access servers.

The Client Access Server Role

Client Access servers perform a similar role to that of “front end” servers in previous versions of Exchange.  The Client Access server is responsible for all non-MAPI connectivity to Exchange server data.  In other words, anything that is not a Microsoft Office Outlook connection to a mailbox or public folder is handled by the Client Access server.  This includes Outlook Web Access, ActiveSync, and Exchange Web Services.

The nature of this role is such that it relies on Microsoft IIS to make these services available.  Because of this the Client Access server is one of the more complex when it comes to backup and recovery.

Backing up the Client Access Server

The data that needs protecting by backup for the Client Access server is located in several places:

• Exchange server configuration stored in Active Directory
• Configuration files stored in the file system (C:\Program Files\Microsoft\Exchange\ClientAccess)
• IIS customizations stored in the IIS metabase

Similar to the Hub Transport server the Exchange server configuration can be recovered from Active Directory using the setup /m:RecoverServer command.  Assuming the Active Directory is already backed up by your Domain Controller backup strategy the Client Access server backups only need to take into account the configuration files in the file system and the IIS metabase.

However there is a downside to this.  When setup /m:RecoverServer is used to restore a Client Access server, and then the IIS metabase is restored afterwards, the Client Access server will experience errors.  Because of this, Microsoft recommends keeping a manual change log of all customizations made to the Client Access server, such as changes to the default virtual directories, or any new virtual directories created.

A workaround for this is to perform a full backup of the file system and System State for Client Access servers.  This allows you to restore the entire server without causing problems after the IIS metabase is recovered.

Recovering the Client Access Server

Since there are two approaches to backing up the Client Access server role there are also two approaches to recovery.

The first is to use setup /m:RecoverServer to reinstall Exchange on the replacement server.  Then, restore the C:\Program Files\Microsoft\Exchange\ClientAccess files from the most recent backup.  Finally, manually apply all customizations that have been recorded in a change log.

The above method will work provided your change log is up to date and accurate.  Any discrepancies will potentially lead the recovery effort astray.  This method is also quite tedious and error prone in complex environments.

The second approach is to use a complete server backup for the restore.  In this scenario the new server is installed with the operating system only.  There is no need to join it to the domain or even to give it a static IP address provided a DHCP server is available.  Next, restore the last full server backup onto the server.  It is likely that the server will then require a restart.

This second approach is less effort and will tend to be more accurate but requires that more data be backed up each night than for the first method.

Recovering Individual Email Items

In Part 2 of this series I demonstrated the recovery of an entire mailbox database.  In some situations it may be necessary to recover just a single email item from a backed up mailbox.  In the next part of this series I will demonstrate how to restore single mailbox items.

Exchange Server 2007 Backup and Recovery Part 4 – Client Access Servers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators