Exchange Server 2010 : Interoperability with Earlier Versions of Exchange

The interoperability and transition story for Exchange Server 2010 Client Access servers is a little different from the transition story from Exchange Server 2003 to Exchange Server 2007. In this section, we'll examine some of the details around transitioning the Client Access server role from Exchange 2003 and Exchange 2007 to Exchange 2010.

1. Exchange 2010 Coexistence Behavior

When thinking through your transition plan from your legacy Exchange infrastructure to Exchange 2010, it's important to understand how Exchange 2010 will behave when interacting with your older Exchange servers. For the Client Access server role, specifically, there are several things that you will need to know and keep in mind while you are planning.

The first thing that you should remember is that Exchange 2010 Client Access servers only talk to Exchange 2010 Mailbox servers. The Exchange 2010 CAS will never access an Exchange 2007 or Exchange 2003 Mailbox server directly. However, it will proxy connections to another Exchange 2007 CAS if the CAS doesn't have an external URL defined.

The second thing that you should remember is that your old Exchange 2003 front-end servers and your old Exchange 2007 Client Access servers need to use a different namespace for external access. What we mean by this is that you can't use mail.contoso.com for both your Exchange 2010 servers and your Exchange 2003/2007 servers. The reason is that if they use the same namespace, your Exchange 2010 Client Access server can't redirect the connection to the old Exchange server if it needs to. We'll look at this scenario more closely a little later.

The third thing that you should remember is that because your legacy servers require a new namespace, you will probably need to buy a new SAN certificate for them. If you are using wildcard certificates, this shouldn't be an issue.

And the last thing is that you should always transition your Client Access servers from the edge of your network inward. What do we mean by this? First, transition your Internet-facing sites, and then transition your non-Internet-facing sites. Exchange 2010 can handle coexistence scenarios with older versions of Exchange, so you want your users to hit the Exchange 2010 CAS first, and then let the Exchange 2010 CAS redirect or proxy the connection as appropriate.

With these principles in mind, let's take a closer look at the specifics for Exchange 2003 and Exchange 2007.

2. Coexistence with Exchange Server 2003

As we mentioned earlier, you will want to move your external namespace to your Exchange 2010 Client Access servers and ensure that your clients are touching those servers first when they access their mail from the Internet. Because of this, you will need to determine a new namespace for your old Exchange 2003 Outlook Web Access connections. For example, if your old namespace is mail.contoso.com, you will need to re-point this namespace to your Exchange 2010 servers and use a new namespace, such as e2k3mail.contoso.com, for your Exchange 2003 front-end servers. Don't forget to make the necessary DNS or proxy changes for e2k3mail.contoso.com.

After that, you must ensure that your Exchange 2010 Client Access servers know what URL to use for Exchange 2003 OWA. This is the URL that an Exchange 2010 CAS will use to redirect the Exchange 2003 users to a publicly accessible Exchange 2003 front-end server. It's interesting to note that this redirection is silent (the user won't know it's redirecting) if you have Forms-based authentication configured on your Exchange 2010 CAS and your Exchange 2003 front-end server. You configure this URL on your Exchange 2010 Client Access servers by running the Set-OwaVirtualDirectory cmdlet with the Exchange2003URL parameter, as shown here:

Set-OwaVirtualDirectory "CAS-1\owa (Default Web Site)" 

-Exchange2003URL https://e2k3mail.contoso.com/exchange

When you are ready to switch your infrastructure over and have your Exchange 2010 Client Access servers take over the entry point into your Internet-facing sites, you just need to make the DNS change to point mail.contoso.com to your Exchange 2010 CAS.

There are two other things that you will probably want to do as well. The first is that if you are using ActiveSync, you should ensure that your Exchange 2003 ActiveSync virtual directory is using Integrated Windows authentication. Second, if you are using RPC over HTTP, you can go ahead and move the connection point to the Exchange 2010 servers and turn off the RPC over HTTP on your Exchange 2003 servers.

3. Coexistence with Exchange Server 2007

When transitioning from Exchange 2007, you still want to stick to the principle of transitioning your Internet-facing sites first. However, with Exchange 2007, you want to transition the site hosting Autodiscover before the other Internet-facing sites. The proxying and redirection story is also different in Exchange 2007. If a user with an Exchange 2007 mailbox accesses a service on the Exchange 2010 CAS, one of the scenarios outlined in Table 1 will happen.

As in Exchange 2003, use a different namespace for your Internet-facing Exchange 2007 Client Access servers. You will move your public namespace (such as mail.contoso.com) to Exchange 2010. If the private keys are exportable on your Exchange 2007 SAN certificates, you can reuse them on your Exchange 2010 CAS, though the internal name will not be on the certificate. For external access scenarios, though, this shouldn't matter.

When you are ready for users to start using the Exchange 2010 CAS, update your DNS records for your existing namespace and point them to your Exchange 2010 CAS. Don't forget to update your Autodiscover record in addition to your public namespace. You will also have to reconfigure the external URLs on your Exchange 2007 Client Access servers to use the new namespace. You cannot share the namespace between Exchange 2010 and Exchange 2007. If you don't update your external URLs, Exchange 2010 will not properly handle the redirection for Exchange 2007 mailboxes.

Your transition scenario will be unique to your organization, because it's based on how you implemented the previous versions of Exchange. As always, before going public with Exchange 2010 Client Access servers, test, test, and test!