Cross-Forest Mailbox Move Changes in Exchange 2010

There’s quite a few changes coming to a cross forest mailbox moves in Exchange 2010. Well for one, in Exchange 2007, you would use Move-Mailbox. In Exchange 2010, you would use New-MoveRequest. The way these two cmdlets work in regards to cross forest mailbox moves is significant. Why? Read on…

In Exchange 2007, when you did a Move-Mailbox to another forest, that cmdlet would be doing some checks against your target environment to see if this user exists. What’s the algorithm you ask? IT’S A SECRET! No really, it is. It’s not really documented anywhere. But thanks to Dmitri Gavrilov from Microsoft, the algorithm is:

Match on objectSID – First try masterAccountSID then try objectSID and sidHistory

Match on source LegacyExchangeDN – look for an x500:LegacyExchangeDN in target directory

Match proxyaddresses – look for any smtp addresses in the proxyaddresses attribute that exist in the source proxyaddresses attribute

As you can see, there’s a lot of methods in which you can use. Some may consider this bad and some may consider it good. For Exchange 2010, Microsoft wanted to simplify the lookup process. So instead of searching the target forest for any of the above attributes, New-MoveRequest will look for only one attribute only; msExchMailboxGuid. Unlike Exchange 2007, the entire process for Exchange 2010 and exactly how you do this with Exchange 2010 will be fully documented. I consider this to be excellent news!

Some organizations will want to utilize ILM to bring over mail disabled users into the target forest so that New-MoveRequest will find the mail disabled user and use mail disabled user to associate a linked mailbox. In this case, you will also want to bring over the msExchMasterAccountSid attribute which is required for linked mailboxes.

Thanks to Ian Lui from Microsoft, he provided the recommended attributes for bringing over a mail user:

altRecipient

deliverAndRedirect

mail

mailNickname

msExchMailboxGUID

proxyAddresses (in addition to sync source mailbox proxyAddresses, synchronized legacyExchangeDN of the source mailbox as X500 address in the ProxyAddresses attribute of the target mail user. The logic is the same when the target object is a contact.)

publicDelegates

msExchHideFromAddressLists

msExchMasterAccountSid (needed for linked mailbox)

msExchRecipientDisplayType (Assume the source mailbox is a user mailbox; for linked mailbox, value is equivalent to *unsigned* 0xC0000006; for regular mailbox, value is equivalent to *unsigned* 0x80000006)

msExchRecipientTypeDetails (MailUser = 0x80, // 128)
TargetAddress (synchronize the PrimarySMTPAddress of the source mailbox as the TargetAddress of the target mail user. The logic is the same when the target object is a contact.)

You can also bring over any other attributes such as givenName, SN, etc at your discretion.

Now keep in mind, that if you are going to be migrating with a tool such as ADMT, QMM, etc. you will want to make sure the tool brings over the above attributes so when you do a New-MoveRequest, it will successfully find the target user and associate the mailbox with that migrated user. But if you are in a resource forest scenario, that’s where you’d want to bring the user over as a mail disabled account with the msExchMasterAccountSid attribute as noted above.

Now what about companies that don’t have ILM and aren’t going to be using ADMT either? Well, Move-Mailbox would create the mail disabled user if it found no user in the target forest with the appropriate attributes. New-MoveRequest will NOT do this. One reason is Microsoft wanted to reduce the complexity with Move-Mailbox. They wanted to simplify the attribute that is used, the algorithm, and wanted to separate the AD provisioning task to another process. Because of this, Microsoft is working on another separate tool/script that will provide the provisioning process for this exact task which reduces replication delay with the Move-Mailbox among other things.

At first, I was skeptical about all this. Why remove functionality that was built-into the Move-Mailbox cmdlet already? After taking an objective look at the reasoning of how complex Move-Mailbox was across forests before, and why simplifying the attribute used as well as separating AD provisioning to Exchange provisioning helps simplify the cross-forest mailbox moves and possible failures due to replication delay if you’re using the cmdlet to create mail disabled user accounts, you will understand the reasoning behind this.

Microsoft has yet to release the actual documentation on this or the script, but I wanted to give people a heads up on what’s to come. I will update this post as those things get released. A big thanks goes out to Dmitri Gavrilov and Ian Lui for providing a lot of the information that you see above.

Update (12/25/2009) – The Microsoft documentation has been updated on what mandatory and optional attributes are required for running New-MoveRequest for Cross-Forest migrations. You can view that here. This article also has documentation on ILM syncing as well as using a script. As of 12/25/2009, this information is in the document but there is no link as the script/ILM information is still unavailable. Keep checking back at the linked to article as the script and ILM information will eventually be published.

Update (02/04/2010) – As Geoff has stated in the comments, the script I have mentioned in the 12/25/2009 update has been published.

Update (02/18/2010) – A fellow MVP, Johan Veldhuis, has let me know that he had some issues running the above script that is mentioned. A fellow coworker of his has created his own VBscript that will do the same thing that Microsoft’s script would. If you run into an issue with the script, try this script. For information on the migration scenario and the script, please go here for Part 1 and here for Part 2.

Currently we are running an exchage 2003 in one forest. Now we need to migrate the exchange server to 2010 to a new forest. Since the budget is very low, we are looking for a free tools while migration, if not, we have to go with licensed one.

Now I have some questions reagrding the exchange 2010 migration on a cross-forest scenario. Could you please clarify the same?

1. How do I migrate the free/busy services and calender to the new Forest?Could you please suggest a good tool or solution?

2. How do I migrate the distribution list, contacts and resource mail boxes including deligation to the new forest?

3. How do I migrate the public folder to new forest? Can i use the inter-organization replication tool for this? if yes, what will happened to the existing permissions?whether it will map with the new forest accounts?

My previous plan was, just export the mailox to PST and import it in the new forest mailbox.Now the users are worried about their predefined calender, room booking while moving to the new forest.

New-MoveRequest cmdlet s*ucks so much that I just can't explain it. Sorry guys, but if you think it will pick up attributes if you copied them via ILM (BTW, Hello?? Is this really the way to go synching accounts? ILM? Version 2007? cmon..this is nonsense and most companies don't even have it) or if you migrated with ADMT, you are wrong. It won't pick it up. It will issue all sorts of strange errors most of them about US as admins providing him wrong switches. One time he complains about RemoteTargetDatabase, the next time you fix something it and it goes on complaining about something else. Not to mention you have to be especially careful with Prepare-MoveRequest script coz it can bring so much headaches.

And has anyone thought about passwords? Migrating mailboxes and their associated accounts with passwords included? No, not supported by Prepare-MoveRequest&New-MoveRequest combination.

But there is a solution, which I found out after weeks of work: Run Prepare-MoveRequest, move the mailbox with New-MoveRequest and you will be left with a mailbox migrated and account disabled. Then go in ADMT (which BTW you have to install on W2K8 box coz it won't go on W2K8R2, LOL LOL) and in ADMT perform account migration. Configure PES at source and do password migration but exclude all other account attributes at Exclusion page. You are then left with the previously migrated mailbox account now ENABLED and password synchronized. The only problem left is that it has "User must change password on next logon" ENABLED and you have to DISABLE it to enable user to log on to OWA or POP3 or with Outlook.