Alternative Client Access Cutover Approaches for Exchange 2010
When migrating from Exchange 2003 or 2007 to 2010, there is always a discussion about how coexistence works for external users. The Exchange Team Blog has an amazing post on how Microsoft would like you to do this. You can find it here. The Exchange Team’s approach is to force all users to connect to the new Exchange 2010 Client Access Server in one fell swoop. What the Exchange Team Blog article does not cover are the alternatives to doing a Big Bang cut-over of the Client Access Role.
There are a few risks that I see associated with the Big Bang cut-over approach.
1. There is only one -Exchange2003URL attribute that can be configured. If end-users are using webmail.domain.com externally, and webmail.domain.local internally, this creates a problem. If you have heavy internal OWA users, you may have to re-architect your internal DNS or routing traffic to get both internal OWA users and external OWA users to be able to resolve the lone Exchange 2003/legacy URL. For some companies, this creates a large hurdle for Exchange co-existence, and impacts the timeline for deployment.
2. All Active-Sync devices start using the Exchange 2010 CAS server at the cutover point. This creates an issue, because many active-sync devices behave differently or simply will not work on Exchange 2010. This may result in a flood of help desk calls and angry users at the time of the cut-over. Many times if the device does not work with Exchange 2010, the user will be forced to download a payed app.
So there is some risk associated with OWA and ActiveSync co-existence. In my experience, Outlook Anywhere doesn’t experience issues unless the public address for Outlook Anywhere is different than the certificate common name.
So what are the alternatives?
One alternative that an overwhelming number of companies go for, is to change the webmail address. If it was webmail.domain.com before, moving forward with Exchange 2010 the webmail address could be mail.domain.com. As user’s mailboxes are migrated over, they are instructed to start using the new address. The user will also have to change the Exchange Server Address on their phone. This may result in some frustration to users, but since you can migrate as many or as few users over as you’d like each night, the migration can essentially be throttled to match the user support load. It would look something like this.
Another, better alternative is to use your reverse Proxy, like Forefront Threat Management Gateway or ISA 2006 to direct user traffic based on an Active Directory Group Membership. This method has the best of both worlds because the users can continue to use the same webmail address, and all users do not have to be cutover at the same time. There is some overhead associated with this method for the Administrator. As user mailboxes are migrated, the user accounts will have to be put in an Active Directory Security Group that the reverse proxy will use to direct the user’s traffic to the new Exchange 2010 CAS Server. This method looks something like this.
This is my preferred method when a reverse proxy is in place. The webmail address does not have to be changed, and any active-sync devices issues that may occur will not affect the entire company at once. Microsoft might come back and say that any Active-sync devices that you are supporting, should be tested with the new server anyway. In my experience, this is rarely realistic.
In this post, I described some alternative methods to the “Big Bang” approach to cutting over the Client Access Role. As we can see, using Forefront Threat Management Gateway we can continue to keep the old webmail address, but not have to cut all users over at the same time.
Do any of you have experience with one or all of these methods? Which approach do you prefer?