Software optimize

Start Exchange 2010 Migration with the CAS role

John Joyner shows you the steps to move Client Access Server connectivity in preparation for a large Exchange migration project.

When introducing Microsoft Exchange 2010 to an existing, large Exchange organization, the Exchange Client Access Server (CAS) components are the first pieces you install. Afterwards, you install the hub, edge, unified messaging, and mailbox server components, and then you are ready to move messaging services to the new Exchange 2010 infrastructure. Early in your migration journey, you will modify the connectivity path Exchange clients use to get to user mailboxes. To control and minimize user impact during the migration, consider moving the CAS connectivity well before starting a general mailbox move to the new platform.

Migration using the "Legacy Hostname" method

Exchange 2010 can't upgrade previous versions of Exchange "in place". To upgrade to Exchange 2010, you must always introduce Exchange 2010 into an existing Exchange organization, then migrate services from the old to the new side. Most large organizations running their business on previous versions of Exchange Server will want to migrate gradually and in controlled steps. Microsoft has published a method for migration called "Legacy Hostname" that offers a practically seamless experience for users.

You will basically publish your old Exchange infrastructure using a different hostname, the ‘legacy' name, perhaps for just a few weeks during the migration process.  For example, if your current Outlook Web Access base URL is https://mail.company.com, you could create a legacy hostname of https://owa.company.com. When the external connectivity change takes place, you will modify public DNS to point your production URL (mail.company.com) to the Exchange 2010 CAS. After configuring your Exchange organization correctly, users will access their Exchange 2007 mailboxes via the new CAS servers, without having to learn or use the legacy hostname (owa.company.com).

Exchange 2010 will help you with certificate management

You will most likely be deploying Exchange 2010 with certificates using the "Subject Alternate Name" (SAN) method, since "wildcard" certificates won't always work with all Active-Sync and Outlook Anywhere clients. Exchange 2010 has a great time-saving wizard that can prepare SAN certificate signing requests (CSRs) for submission to your public certificate provider (Figure A). The wizard also makes it easy to assign Exchange services such as Outlook Web App to the certificate after it has been issued.

Figure A - Exchange 2010 has time-saving wizards to request and assign certificates.

You will want to include the following names in your public-facing (Internet) SAN certificate. If you include all the names listed below, you can use the same certificate for old and new CAS servers as well as on load balancers for SSL offloading and/or firewalls with reverse proxy features.

  • Primary name: The fully qualified domain name (FQDN) users will type in their web browser for Outlook Web App, such as mail.company.com.
  • Legacy hostname alternate name: The legacy hostname for publishing existing Exchange, such as owa.company.com.
  • Autodiscover alternate name: The autodiscover host name, such as autodiscover.company.com.
  • Optional private DNS alternate names: The primary name and autodiscover hostnames with the Active Directory domain (private) suffix, such as mail.company.local and autodiscover.company.local. (A convenience to users and devices on the LAN.)
  • Optional private DNS CAS alternate names: The private domain FQDNs of both the current legacy Exchange CAS servers and the new Exchange 2010 CAS servers, such as ex07cas01.company.local and ex10cas01.company.local.

Adding the private domain names to the certificate does disclose the domain suffix and the hostname of the CAS servers to those on the Internet that might study the certificate. However this information is obtainable generally from the SMTP headers of every Internet email sent by the organization.

Accommodating the new CAS RPC Array feature

Optionally, create a CAS RPC array behind your hardware load balancer. CAS servers in Exchange 2010 have a huge new purpose compared to previous versions of Exchange. In Exchange 2010 architecture, Outlook clients make their MAPI (also known as RPC or Remote Procedure Call) connection to the CAS servers, which then connect by RPC to the mailbox servers and perform user mail operations for the user. This is a big change from the last fifteen years of Exchange MAPI clients connecting directly to mailbox servers. If you have a large environment, you must prepare your infrastructure for the potentially high volume of RPC traffic to your CAS servers.

To implement a CAS RPC array, load balance your array of CAS servers on TCP port 135 and ports 1024-63353 using your choice of hardware load balancer. F5, Cisco ACE, and Citrix NetScaler are common solutions. Establish an internal hostname like outlook.company.local for the load-balanced IP address. Then run the New-ClientAccessArray cmdlet and point Exchange to the CAS RPC array load-balanced internal hostname. Outlook clients will establish RPC connections to this array, and CAS nodes in the array will in turn connect to the respective mailbox servers.

Reconfigure legacy CAS servers and shift connectivity to Exchange 2010

You will publish your legacy Exchange environment via the legacy hostname, in parallel to the existing Exchange hostnames. You will enable DNS and firewall settings so that test users can type the legacy hostname URL in their browser address bar and get to their mailbox just like using the primary URL. Then you are ready to flip the switch and make the following changes rapidly during a maintenance window:

  1. Put your new SAN certificates in place on all CAS computers, SSL off-loaders, and reverse-proxy firewalls as appropriate for your environment.
  2. Change DNS to point your primary and autodiscover URLs to the new Exchange 2010 path.
  3. Reconfigure legacy Exchange CAS servers so that the External URLs for web access and offline address book are set to the legacy hostname.
  4. Set the ExternalURL for Active-Sync to NULL$ (blank) and disable Outlook Anywhere on the legacy Exchange CAS servers.

After making these changes, connectivity to your legacy Exchange servers is now handled by Exchange 2010. Exchange 2010 uses two different mechanisms to provide this backward compatible access:

  • Outlook Web Access (OWA, called Outlook Web App in Exchange 2010): Users authenticate to the new CAS servers, and then are redirected to the legacy hostname URL.
  • Active-Sync and Outlook Anywhere: Users authenticate and remain connected to the new CAS servers, which proxy the traffic internally to the legacy CAS servers.

With connectivity moved safely to the new Exchange 2010 side, a major milestone in a large Exchange 2010 migration project is complete. Remaining tasks are to move the hub services like SMTP to the new side, then move mailboxes, and finally stand down the legacy Exchange servers.

About

John Joyner, MCSE, CMSP, MVP Cloud and Datacenter Management, is senior architect at ClearPointe, a cloud provider of systems management services. He is co-author of the "System Center Operations Manager: Unleashed" book series from Sams Publishing, ...

0 comments