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
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.