Home > Exchange 2010 > Alternative Client Access Cutover Approaches for Exchange 2010

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?

Categories: Exchange 2010
  1. Scott
    October 17, 2011 at 9:05 am

    I would prefer to use the reverse proxy method. But I have a problem. Our external OWA users log into mailboxes explicitly. The user does not have their own mailbox. They go to a specific address like https://mail.contoso.com/exchange/mailbox@contoso.com. Using the reverse proxy method would have to point them to https://legacy.contoso.com/owa/mailbox@contoso.com. Do yo know how I can use TMG and a security group to acheive this?

    • October 17, 2011 at 3:45 pm

      Having a user go to https://mail.contoso.com/exchange/mailbox1@contso.com would take the user to the same place as if they were to go to https://mail.contoso.com/exchange, and then login as mailbox1@constoso.com.

      To make it easier on yourself, and for future migrations, once tmg is setup, instruct users to enter the root https://mail.constoso.com as the web address, and have them login with the mailbox1 account credentials.
      I’ve never seen a company have users login the way you do, and if I were designing and deploying the upgrade, I would be changing it moving forward. It’s easier on the users and the support staff to have all users enter the same web address for OWA.

      • Scott
        October 17, 2011 at 4:00 pm

        I understand that logging in to the mailbox that way is not ideal. The reason we do it that way is because we have high turnover. These mailboxes are all shared. A security group is created for each of these shared mailboxes with the proper permissions to send etc. When a new user starts they are not given a mailbox only a username. That user is put into the proper security group. I wish I could make it easier but with the high turnover the password for those mailboxes would need to be changed all the time. This way we just disable the user account. Nobody is ever given the password for the actual mailbox.

        I am typing this on my phone so hopefully this makes sense.

      • October 18, 2011 at 8:47 am

        The good news is, in Exchange 2010 users can still login with https://mail.contoso.com/exchange/mailbox1@contoso.com. After the user logs in with /exchange, it just opens up the /owa vdir.
        You will just have to continue to use Basic Auth instead of forms. If you go this route, the TMG user groups should work as expected, with your current login scenario.

        For example:
        User1 has access to SharedMailbox03, which is on Exchange 2003
        User2 has access to SharedMailbox10, which is on Exchange 2010.

        When User1 browses to https://mail.contoso.com/exchange/SharedMailbox03@contoso.com, TMG will prompt for authentication. As long as User1 is in the “2003 users” group in TMG, and the group is paired with the 2003 publishing rules, the user will be forwarded to the 2003 mailbox after login
        When User2 browses to https://mail.contoso.com/exchange/SharedMailbox10@contoso.com, TMG will prompt for authentication. As long as User2 is in the “2010 users” group in TMG, and the group is paired with the 2010 publishing rules, the user will be forwarded to the 2010 mailbox after login.

        I’ve never tested this, however I believe it should work. Once TMG is deployed it would be very easy to test by adding test accounts to the corresponding groups without affecting production users.

      • Scott
        October 18, 2011 at 8:52 am

        OK I am already using TMG and have a few users already on Exchange 2010. I will try out the security groups and see what happens. Thanks a lot for your help.

  2. rm
    October 26, 2013 at 8:42 am

    do you have references on how to configure the security groups in TMG?

    • October 26, 2013 at 9:33 am

      When you’re creating the rule, there is a section for “This rule applies to user set”, click add, create a user set, and edit the user set to it holds members of an internal AD group. Otherwise you can edit the user set by clicking on the rule itself and editing it. Sorry, I don’t have click by click instructions, but it definitely is not buried, there are a few places you will find the ability to add/edit the user set a rule applies to.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: