Saturday, September 4, 2010

Outlook profiles don't update when you move a mailbox (Exchange 2010)

So consider this....

You're performing a migration from a previous version of Exchange Server to the new 2010 platform. You move a mailbox, the person opens Outlook and poof......the profile gets updated. Now let's say the server you've just migrated the account to is an Exchange 2010 all-in-one (hub/mb/cas) server and you move the mailbox to another all-in-one server in a different site. No problem right? Well in the words of a well known Kazakhstan wiseman.......not so much!

Here's the problem. Your Outlook clients will NEVER update their profiles again as long as they can reach the Exchange 2010 CAS role they were moved to originally. This applies to all current Outlook clients including Outlook 2010!

So here's my story:
We were working on a client project where we completed a cross-forest migration from Exchange 2003 to 2010. We built a 3 server all-in-one Exchange 2010 in Canada which would eventually be the final location of the USA mailboxes. To make the move from the USA to Canada possible we set up a local Exchange 2010 server first. This allowed us to perform a cross-forest move locally first, then an online mailbox move over time. The online mailbox move feature in Exchange 2010 worked great. We used the "-SuspendWhenReadyToComplete" switch so we wouldn't interfere with end user connections and resumed the move request at night which flipped the mailbox over. Well we didn't get far before someone noticed Outlook wasn't pointed at the new environment in Canada.

Prior to the migration of any data, we set up our CAS Array in Canada and made sure the RpcClientAccessServer property of each database in the DAG pointed to the new FQDN we created. One would think the Outlook client would check this attribute on first connect to see which CAS server they should connect to but it does not.

Here are a couple ideas to resolve this issue which failed:

1. Running a script to update the Outlook profile using a ".prf" file. Unfortunately this causes the Outlook client running in cached mode to re-cache their mailbox. For an organization with slow WAN links and large mailboxes this can be disastrous. No dice.

2. Create a host entry on the servers in Canada pointing them to the IP of the USA server then updating the DNS record used by clients to have them point to the CAS array. This was less desirable due to the 'jiggery pokery' of meddling with DNS. It didn't work anyway...

3. Disable MAPI clients for a user using "Set-CasMailbox -identity -MAPIEnabled:$false". Have the user launch Outlook. Enable MAPI. Done! That worked.....but impossible to do for several hundred users individually.

I contacted a few Microsoft Exchange team individuals and quickly found out there was only one way to fix this. For Outlook 2003 clients you need to update the profile manually or run a PRF file to update it (causing a re-sync of the OST). For Outlook 2007/2010 clients, a "Repair" of the profile will cause it to wake up and talk to the right server.

So here we have it. Not the greatest solution. We currently have a high severity case open with Microsoft on the issue (as do others). I'll update my post as I know more.

Crap.

9 comments:

  1. Jason,

    Has anything changed with this issue?

    Sincerely,

    Wesley Jones
    http://bbcitdept.blogspot.com

    ReplyDelete
  2. As I understand it, this is still a 'feature'.

    ReplyDelete
  3. Good morning,

    You found a solution to this problem?
    I'm an Exchange 2010 migration to Exchange 2010 and migrated mailbox not updated the profile of Outlook. Thank you.

    vandatm@yahoo.com.br

    ReplyDelete
  4. Crap is right. I'm dealing with this EXACT issue right now. Moved mailboxes to release stress on a WAN link. All the clients are still pointing to the CAS on the far side of the WAN causing more traffic than before. Just worked with Microsoft for 2 days on this only to be told it's working as designed.

    ReplyDelete
  5. Uninstall the CAS role from the old server, but leave it up and running. When the clients try to connect, they'll be re-directed to a different CAS server and the profiles will update.

    ReplyDelete
  6. Hi Jason

    is there any news (hotfix or tricks) regarding this issue ?

    Hamid AICHE
    aicheh.wordpress.com

    ReplyDelete
  7. Maybe a late response. I was able to reset Outlooks RPC connection by deleting certain registry keys through GPO. This will work if all users are using the default "Outlook" profile. I gained a success rate of 8 out of 10 successful RPC resets. The only failure I encountered was that Outlook could not connect. A simple repair of the profile fixed that.

    The big + doing it this way is that Outlook is not downloading a new OST.

    You can look at these registry keys.
    [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\13dbb0c8aa05101a9bb000aa002fc45a]

    and delete the following REG_SZ value.
    001e6602
    001e6603
    001e6608
    001e6612

    As always. Test it first. Every environment is different.

    ReplyDelete
  8. I stopped the only the RPC-service on the old server. On the next outlook start the client will look for the new CAS server and will automatically change its config.

    Worked for me.

    ReplyDelete
    Replies
    1. Oh yeah - this worked for me too - thanks!

      Delete