While the Edge Transport Server role, the Hub Transport Server role, the Mailbox server role, and even the UC server role are all critical, it’s the Client Access Server role that your users interact with most. The CAS handles all the interactions between clients and the Exchange 2010 infrastructure – whether the clients are using Outlook, ActiveSync, OWA, IMAP, POP3, or EWS. It also handles all AD queries for clients. It’s critical to ensure that your CAS servers are configured correctly, and built with the redundancy and capacity your clients need.
In this post we will take a look at some of the recommend, or preferred, practices for setting up and maintaining your CAS servers to provide the best possible user experience with the least administrative overhead.
Size your CAS server to handle both the current, and the foreseeable growth of your user base. CAS servers consume RAM and CPU, and can use a lot of network bandwidth based on client needs, but won’t use disk for much other than the operating system and logging.
See this TechNet article for specific sizing recommendations, and use the enterprise version of the operating system so you can implement an array later even if you don’t want to start with one.
While smaller shops will try to reduce their server numbers as much as possible, larger organizations, and those who want to implement arrays, will want to keep the CAS servers roll specific. If your org is small enough to forgo the redundancy, the CAS role can be combined with the Hub Transport role easily.
Implement CAS server arrays to provide both maximum performance and redundancy. You will use the Network Load Balancing capabilities of Server 2008 to create a virtual ip.addr that listens for client connection requests, and balances the load across all array members. If one CAS server in an array must be taken offline, the other members of the array can handle client needs. Depending on your needs, you can implement up to 16 servers in an array.
Publishing to the Internet
All clients, no matter what type, will need to connect to the CAS server when using email. While most of your “fat” clients could first fire up their VPN before launching Outlook, web mail and smart phone users will want to get to email without a VPN. Microsoft Forefront TMG is a great solution for securely publishing all of the Exchange CAS server capabilities to the Internet in a secure and high performance way.
If you centralize your email system with all mailbox servers in one or more hubs, you might be tempted to place your CAS servers the same way. While this will work fine for smaller organizations, those with larger user counts across several offices might want to place CAS servers near their users. Remember, CAS servers not only proxy connectivity to the mailbox servers, they handle all directory lookups. Placing them closer to the users will improve response time and reduce WAN traffic. Of course you will want to place the CAS servers handling OWA and ActiveSync traffic close to your perimeter.
While the CAS server is very important to clients, it is also very fast to build. Since patching Exchange 2010 systems should start at the edge and work in towards the Mailbox and UC roles, you will patch your CAS servers before anything other than the Edge transport role. There are PowerShell scripts included to make it easy to take a CAS server out of an array, patch it, and then add it back to an array.
As a general rule, there is little on a CAS that cannot be easily recreated other than log files. Consider how important the log data is for your data retention policy, and implement the backup solution that supports that. My CAS servers are all virtual, so I just snapshot the VMs once a week.
Understanding these preferred practices for your Exchange 2010 CAS servers, and implementing the recommended configurations will help you to provide the best user experience, exceed your SLAs, and live the life of an Exchange rockstar. Okay, maybe the last one is a stretch, but trust me on the other two.