Moving all data from one Exchange 2010 to another Exchange 2010 server

I am trying to move all data from a single Ex2010 multirole (CAS/HUB/MBX) server to another multirole server, serverB (CAS/HUB/MBX).

The old server (ServerA) is close to dying and I understand that I need to transfer all data to a new Exchange server.

So far so good. But the problem is pointing the Outlook 2010 clients to the new server.

This is what I have done so far:
1. Moved all mailboxes to a new mailbox database on the new server (ServerB).
2. Enabled and imported a public UCC certificate.
3. Moved OAB generation to ServerB
4. Created receive connectors on serverB, similar to ServerA.
5. Redirected mailflow by updating NAT rules on my firewall (both servers are public internet facing, so mail is flowing in and out correctly.
6. Updated both mailbox databases, so both points to ServerB. (Get-MailboxDatabase | fl rpc* shows ServerB).

But Outlook 2010 clients are still pointing to ServerA and is not starting at all if I shutdown ServerA. I can see in Outlook that it connects to ServerB for OAB, but still 3 connections to ServerA.

Any way I can solve this?
I was thinking that pointing the mailbox databases to the new RPCClientAccessServer would automatically redirect the clients.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Sadly, I'm afraid that's not quite going to work - matters are slightly more complicated!

Once a mailbox is established on an Exchange 2010 Server, and an Outlook client has a configured profile connecting to that mailbox, any changes to the RpcClientAccessServer do not trigger an update of the server property at the client. Every Client Access Server is a valid connection point for MAPI access to a mailbox, so Outlook's connection to ServerA is not invalid - despite the mailbox being located on ServerB. The servers are located in the same Active Directory site, so ServerA's CAS role can communicate with the mailbox role on ServerB to retrieve mailbox data and return it to the client. If you shut ServerA off, Outlook just assumes the machine is unavailable. At no point does Exchange tell Outlook it is using the wrong server.

The preferred way of avoiding this problem is to create a CAS array object, which uses some generic name like outlook.domain.local. CAS arrays are normally associated with highly available deployments with multiple CAS servers, but also serve a crucial purpose in single-server configurations: they allow you to abstract away the individual server names, so that RpcClientAccessServer - and the Outlook client - points to a generic name whose endpoint(s) you can change on demand using a combination of DNS and load balancers, with multiple servers.

Sadly, that technique still won't work for you with an Exchange 2010 environment already established without further work, for the same reason I outlined in my second paragraph. That said, while overcoming the problem, you can (and should) introduce a CAS array to avoid this problem again. See below.

To force Outlook to do an update, you generally need to manually repair the user's profile or, in theory, you should be able to delete all references to the old server (make the name unresolvable in DNS by removing the record). This should cause Outlook to discover the new server details via Autodiscover, but remember to properly decommission ServerA before eliminating it from DNS! This method is not always 100% successful, especially when there are misconfigurations with Autodiscover, and thus you should test this extensively before you depend on it as a solution to your problem. Outlook 2003 and older does not use Autodiscover - if you do have any of these clients (you indicate you're Outlook 2010, so I suspect not), you are going to need to create new Outlook profiles with the new details for each user. It would be cool if Autodiscover automatically detected a change to the RpcClientAccessServer attribute during normal operation and make the changes on-the-fly, but this is not currently an implemented feature.

When you do this update, you can introduce the CAS array so the problem does not occur again. The steps to do so are easy:
Create a record in your internal DNS named outlook.domain.local, which is either an A/CNAME record which maps to the IP of your Exchange Server/the internal name of the server (ServerB.domain.local). The latter is preferable. Information should not be duplicated, so a CNAME record avoids the duplication of serverB's IP address, which is already stored in DNS.
Create a Client Access Array object using Powershell: New-ClientAccessArray -Fqdn outlook.domain.local -Site <Your-AD-Site-Name>
Update the RpcClientAccessServer attribute on the mailbox databases to represent outlook.domain.local, rather than a particular server name.
Perform a profile repair or remove the old ServerA DNS record to force Outlook clients to repair themselves.

That will get you going again, but will also avoid any issues of a similar nature. Further, should you later add more Client Access Servers, it is trivial to add a load balancer in front of those servers, then modify the DNS record outlook.domain.local to refer to the load balancer's virtual IP address, rather than the IP of ServerB. Outlook clients will hum along, unaffected by the change.

One crucial point: do not allow your CAS array FQDN to be resolved externally. If you use as the FQDN, for example, this must be confined to internal DNS lookups. If this name is available externally, you will cause your Outlook Anywhere users hideous delays and timeouts when away from the office.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Please change Legacy Exchange DN attribute to point to new server new server using Adisedit

Open Adsiedit.msc->Config partition->services->Microsoft Exchange->Administrative Groups->Exchange Administrative group->Servers->Server Name->Properties
xcomiiiAuthor Commented:
Thanks for a long and thorough explanation.

I will try the solution, however I can not try it yet, since I cannot uninstall the old Exchange server (problems with Windows Installer). But I will let you know :)
xcomiiiAuthor Commented:
Tigermatt, thanks!
That really solved the problem for internal clients in our LAN.

But how can I make it work for users that are outside and user Exchange Anywhere?
I have updated DNS settings externally and directed autodiscover into the new server.

Will a profile repair be enough? Or maybe delete the OST file?

Some users are sitting on very unstable connections and I am a little worried that if those users starts to download the entire OST file with interruptions, it can take several days.
Sorry for the delay in getting back to you. I was away from my emails for a couple of days.

>> Will a profile repair be enough?

Yes, a profile repair, in theory, from a remote location should be enough.

Deleting the OST file wouldn't really do anything; Outlook could just re-connect to the same CAS as it was using before and re-sync the user's mailbox from there.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.