Tuesday, March 23, 2010

Cross-Forest Migration with Exchange 2010 is a piece of cake!

By:Rik Hoffelder
Overview
It has been a while since I've posted anything new on The Generation V as I have been neck deep in projects. One of them involved a cross-forest Exchange migration as part of a larger AD migration. In this project the customer was migrating Exchange 2003 in Forest A to Exchange 2010 in Forest B and they needed to do it on a budget. In other words, no third party tools if at all possible. As the title suggests, with free tools from Microsoft and built-in features of Exchange 2010, it was remarkably easy.
Over the years Microsoft has added many tools, most free, to assist in numerous management and migration tasks. For this project I used the Active Directory Migration Tool 3.1, Exchange Sync from the Exchange 2003 toolkit, CVSDE, VBScripts, and PowerShell to perform all of the tasks. This saved the customer the many thousands of dollars third party software would have cost and not necessarily made the process any easier.
I will not go into the specifics of the AD migration part of the project, just know that all user and group accounts were migrated using ADMT 3.1. I also did not use ILM 2007 FP1 SP1 to provide GAL sync as this wasn't necessary due to the relatively small size of the project (about 600 mailboxes) and the rarity of account/mailbox additions/changes/deletions in this environment during the co-existence period. Even in that case, creating new accounts or modifying DLs followed a document process I created that eliminated the need for GAL sync. I would suggest ILM for larger organizations and those that make many changes during co-existence.

Prepare Routing

Prior to the Exchange migration, I had to establish a routing method to be used during the co-existence period between Exchange forests. This is necessary because both Exchange forests must be authorative for the primary SMTP namespace of customer.com. To do this I established a proxy address of ex2003.local for Exchange 2003 and ex2010.local for Exchange 2010.

I then added ex2010.local to the Accepted Domain Hub Transport organization configuration and added %m@ex2010.local as a proxy address to each affected E-mail Address Policy. Next I added the %m@ex2003.local proxy address to each Exchange 2003 Recipient Policy and selected the "This organization is responsible for delivery …" checkbox. All recipients were updated with the new policies.

Next I created SMTP connectors in each Exchange forest to forward to the other's proxy address space. For example the Exchange 2003 SMTP connector routes @ex2010.local to the Exchange 2010 forest and vice versa.

Prepare User Accounts

The Active Directory Migration Tool was used to migrate the Forest A user and group accounts into Forest B. (ADMT is also a free tool available from Microsoft's public download site http://microsoft.com/downloads). After the accounts were migrated I exported the displayName, samAccountName, mailNickname, and mail values for all mailbox-enabled users in Forest A using CSVDE as follows:

csvde -l displayName, samAccountName, mailNickname, mail -r "objectclass=user" -f c:\2003_Mailboxes.csv

This was done to use these values to mail-enable each user account in Forest B. By mail-enabling (not mailbox-enable) the Exchange 2003 users now appear in the Exchange 2010 address book allowing migrated users to communicate with unmigrated users seamlessly, thus eliminating part of the need for ILM in this project.

Before mail-enabling the Forest B users I changed the domain portion of each e-mail address to ex2003.local to use as an input value for the bulk mail-enable process. I also renamed the field in the CSV file to match the input values I used in the Exchange Management Shell cmdlet. DisplayName was changed to Name, samAccountName was changed to Identity, mailNickname was changed to Alias, and mail was changed to EmailAddress. I then ran the following cmdlet to complete the update:

Import-CSV C:\2003_Mailboxes.csv ForEach-Object –process {Enable-MailUser –Identity $_.Identity –Alias $_.Alias -EmailAddress $_.EmailAddress}

This would of course need to be manually updated for any new user accounts migrated over from Forest A.

The final step to prepare the users is run the Prepare-MoveRequest.PS1 script against the mail-enabled users. Prepare-MoveRequest.PS1 is a script created by Microsoft that updates the Forest B mail-enabled user with the MsExchMailboxGUID attribute from Forest A. This value will be used by the New-MoveRequest cmdlet to match the source Exchange 2003 mailbox to a target 2010 user. This little free script along with the –RemoteLegacy switch in the New-MoveRequest cmdlet are the new features in Exchange 2010 that help eliminate the need for third party tools in all but the most complex of cross-forest migrations.

I ran the following cmdlets in 2010 EMS, reusing the 2003.Mailboxes.CSV from the previous step:

$UserCredentials = Get-Credential

Import-CSV C:\2003_Mailboxes.csv ForEach-Object –process {Prepare-MoveRequest.ps1 -Identity $_.Identity -RemoteForestDomainController ex03.ex2003.local -RemoteForestCredential $UserCredentials –UseLocalObject}

For those new to PowerShell in general, EMS in particular, the $UserCredentials = Get-Credential cmdlet will open a dialog box requesting to enter the credentials of an account in Forest A with rights to migrate the data from Exchange 2003. Enter the credentials accordingly or the migration will fail with an error message containing 0x80004005, which means access denied in the entire Microsoft world.

Prepare Distribution Groups

Next I had to mail-enable the distribution groups migrated from Forest A. The ADMT will migrate the groups and group members as a group type of Distribution but it will not bring over Exchange attributes. This required two steps, first each migrated group had to be changed to a Universal group, as they were domain local or global groups in Forest A. Distribution Groups in Exchange 2007/2010 are Universal in scope as a result domain local or global groups cannot be mail-enabled. To do this I ran the following cmdlet in Exchange 2010 Management Shell:

Import-CSV C:\groups.csv ForEach-Object –process {Set-Group –Identity &_.Name –Universal}

I then ran the following script to mail-enable the Universal groups.

Import-CSV C:\groups.csv ForEach-Object –process {Enable-DistributionGroup =Identity &_.Name}

Now keep in mind that any new users created in Forest A and added to the Forest A version of this group, will become a member of the Forest B version of the group after the user account is migrated with the "Fix Group Memberships" option selected, thus negating the need for ILM.

Prepare Public Folders & Free/Busy

This migration occurred over a period of several weeks. Users were fully migrated to Forest B, meaning they were accessing Exchange 2003 from Forest B user credentials on workstations operating in the Forest B domain. After all users, groups, and workstations were migrated, I began the mailbox migration process.

This company relies on Public Folder data in several areas to collaborate and share information. As a result I had to maintain both public folder and free/busy synchronization between Exchange forests for a period of time. To do this I used the good old Exchange Inter-Organization Replication Tool. At preset this tool is not designed for use with Exchange 2010, but version 6.5.7408 is supported with Exchange 2007. I thought what the heck there isn't that much difference in public folder functionality between 2007 and 2010 so I gave it a try … in my lab first of course. What do you know, the darn thing worked and it worked very well.

To get it up and running I followed the steps outlined in this article: http://technet.microsoft.com/en-us/library/ee307369(EXCHG.80).aspx. It took a couple hours to get it fully functional in the customer environment, but it did the job very well and cost nothing but billable time! Hey I gotta eat too, right?


Migrating the Mailboxes

This is another area where Exchange 2010 really shines. The New-MoveRequest cmdlet offers a command-line only switch –RemoteLegacy. This switch tells Move Request to migrate a mailbox from a different Exchange 2003 or 2007 forest. It uses the MsExchMailboxGUID to match the source 2003/2007 mailbox in the remote forest with the target mail-enabled user in the Exchange 2010 forest, which was established earlier using Prepare-MoveRequest.PS1.


$UserCredentials = Get-Credential

New-MoveRequest –Identity migtest1 -RemoteLegacy -TargetDatabase "Mailbox Database 1" -RemoteGlobalCatalog 'ex03.ex2003.local' -TargetDeliveryDomain 'ex2010.local' -RemoteCredential $UserCredentials

When the move request completes it converts the target mail-enabled user to a mailbox-enabled user. It then deletes the source mailbox and converts the user to mail-enabled. As part of that process it adds a proxy address of @ex2010.local as the primary SMTP allowing users on the legacy forest to see the migrated mailbox in the global address list.

Finally using a group policy object I created a VB Script based user logon that creates a new Outlook profile by using a PRF file. The script checks for the presence of a specific profile name, if it doesn't find it Outlook is launched with the PRF as follows:


Path\Outlook.EXE Path\Update.PRF


It's quick it's easy and the code I used was readily available through a simple Bing search.

Final Words

I don't exactly recommend this process for large scale migrations, but for those of you operating on a budget and can't afford 10+ USD per mailbox for a one time use tool; this is will get you by. It isn't perfect, but it worked well for this project.





More information on Exchange


35 comments:

  1. rik can you explain more this part of the coexistence setup please
    I then added ex2010.local to the Accepted Domain Hub Transport organization configuration and added mailto:%25m@ex2010.local as a proxy address to each affected E-mail Address Policy. Next I added the mailto:%25m@ex2003.local proxy address to each Exchange 2003 Recipient Policy and selected the "This organization is responsible for delivery …" checkbox. All recipients were updated with the new policies.

    Cheers Brian

    BR@BRAMPLING.CO.UK

    ReplyDelete
  2. hi rik.
    you wrote that you was able to sync Public Folders. How did you get this running? Could you post a detailed description please? I´m having problems with that. I´m not able to authenticate in excfg.exe. At the subscriber side, under "folder list", logon fails with "Unable to logon to Exchange server using mailbox information".
    Cheers Felix

    ReplyDelete
  3. Hi Felix,

    Be glad to help. Actually there is another great article with a step-by-step on how to set this up between 2003 and 2007 that is identical to what I did. Not sure who the author is to give him credit, but it has a good step-by-step with screenshots. It follows the MS article I reference, but I think it provides a much better visual. My guess (since I had the same problem initially) is with the configuration of the ExchsyncSecurityFolder. If that isn't present or set with only the Folder Visible permission you will get errors. I sure did! : )

    Let me know if this helps. I can post some screenshot of my configurations too.
    http://exchangeserverinfo.com/2008/02/28/interorg-replication-from-exchange-2003-forest-to-exchange-2007-sp1-forest.aspx

    ReplyDelete
  4. Hi Rik,
    i tried it with only folder visible permissions and with owner permissions, too. it wont work. it would be helpful if you post some screenshots of your configuration.
    Thanks a lot...
    Cheers Felix

    ReplyDelete
  5. Hi Felix, I posted a new article on how I setup public folder replication here: http://www.thegenerationv.com/2010/05/replicate-public-folders-between.html. Hope it helps get you going!

    ReplyDelete
  6. Hi there - Great article!

    I am a bit confused by the "Prepare Routing" section. I must be missing something but I cant work out why you have done this part or more specifically, i cant see what this bit has achieved. I have to do a similar migration soon so am real keen to understand everything you have posted here.

    Can you give a bit more detail of what this step achieves and why it is necessary.

    Thanks a lot

    Andy

    ReplyDelete
  7. Hi Andy,

    This step was necessary to allow each Exchange organization to be authoritative for the same public namespace but still be able to route mail between organizations during the co-existence period. Without this users in one organization will not be able to route mail to users in another organization, they will receive “not such user” type errors.

    For example, user1@company.com is moved from old Exchange 2003 organization to a new Exchange 2010 organization in a different AD Forest. He now tries to e-mail user2 who still resides in the old Exchange 2003 organization. He uses user2@company.com to address the message. Because the new organization is authorative for company.com, it assumes the mailbox is within the organization and will not route to the old Exchange 2003 organization. As a result the message will NDR with the “no such user …” error because the mailbox does not exist in the 2010 org.

    To prevent this, I create an authorative address, used internally only, as the External Address on the Mailbox User (Mail-enabled User in 2003) object in the directory. As a result when User 1 uses the user2@company.com address, the External address of user2@ex2003.local is actually used to route the message to the Exchange 2003 organization.

    Hope this helps!
    Rik.

    ReplyDelete
  8. Hello Rik,

    Many thanks for taking the time to reply!

    I figured this is what you were trying to achieve but what happens when user2 (the EX2003 user) sends an email externally? surely his primary email address will appear to be user2@ex2003.local??

    I get it that if both exchange organisations are authorative for the domain they will send an NDR for a user that they are not aware of but I cant understand how your steps counter this :-{

    I know I am missiong something and understand that you have explaioned it twice... I guess I will have to lab it to see how this works in practice.

    If you ever have the time to maybe expand on this in the same way that you did for the ExchangeSync article I am sure there will be many grateful readers.

    Regards

    Andy

    ReplyDelete
  9. You are correct, the internal routing address is exposed to external recipients. In my case the co-existence period was brief, long enough to ensure Exchange 2010 was ready and verify the migration process. The organization was small enough that I migrated the bulk of production data over a weekend, this minimizing exposure to this problem. Note the problem only occurred when user1 mailed user2 and someone outside the organizations. In that case the user2 address was user2@ex2003.local and bounced. Now if User1 mailed someone outside without including User2, there were no issues.

    If you are in a lengthy co-existence period you could register additional public names such as legacy.company.com and new.company.com to account for that. We considered that for this project, but decided it was easier to get it over with quickly. Partly why I don't recommend this for larger migrations, in that case it's better to spend the money on something like Quest tools.

    ReplyDelete
  10. Hi Rik,

    Thanks for clearing this up!

    I will migrate over a weekend 600 users so i guess I wont have to worry too much about this.

    Great article though - keep up the good work!

    ReplyDelete
  11. Great article on how to achieve co-existence and perform migration between 2 orgs.

    Just had a question regarding mail flow during coexistence.

    Using ex2003.local as the target address in the contact object whose mailbox resides in the target forest; If you send an email to an external user as well as the contact, when the external user replies the user@ex2003.local address will bounce back since it is incorrect. This poses a problem as far as coexistence is concerned, is there a way around this?

    Thanks!

    ReplyDelete
  12. i am new to Exchange,

    What is the meaning of %m (%m@ex2010.local)?

    ReplyDelete
  13. I would look at using a 3rd party tool like http://www.priasoft.com/products-exchange-migration-mailbox.aspx that supports migration from 5.5, 2000, 2003, and 2007 direct to 2000, 2003, 2007 and 2010 and deals with all these issues.

    ReplyDelete
  14. yeah - thats what we went wioth in the end.

    Its quite costly but does make things sooo much simpler.

    At the end of the day, its not my money - the customer weidhed risk vs cost and bought the 3rd party tools.

    Unless its your own money I suggest you do the same :-)

    ReplyDelete
  15. Is there any way that only External Mails should be Redirected from a single mailbox...and Local Domain mails should be present in that particular Mailbox in Exchange2003

    ReplyDelete
  16. Great post! We're about to go through this same sort of procedure. One quick question though...how did you generate "groups.csv"? Using csvde?

    ReplyDelete
  17. I struggled with these scripts for a while so I though I'd post what worked for me. These scripts are probably really rudimentary, but this was my first stab at powershell and as I say, they worked for me:

    To migrate your distribution lists from one forest to another first run the ADMT and pull your groups over. This results in the group being set up with NO exchange properties.

    Then:

    **export your distribution groups from the source forest by running:
    Get-DistributionGroup | export-csv c:\groups.csv

    copy groups.csv to your new 2010 CAS server. in this example I copied it to c:\groups.csv

    **then use your CSV to apply all your the attributes from your old distribution lists to the new ones by running this:
    Import-Csv C:\test.csv | ForEach-Object -process {Set-Group –Identity $_.Name –Universal;Enable-DistributionGroup -Identity $_.Name;set-distributiongroup -identity $_.samaccountname -emailaddresspolicyenabled $false;Set-DistributionGroup -Identity $_.SamAccountName -PrimarySmtpAddress $_.primarysmtpaddress}

    Note that this script will result in your groups NOT using the email address policies you set up.

    ReplyDelete
  18. Hi, Rik ,

    Can you share the decommissioning process after this migration?

    ReplyDelete
  19. Hi Rik,

    Great Post. I am in the same situation, migrating E2K7 cross forest to a E2K10 environment using the same tools.

    My question is how did you get the free/busy information to replicate using the interorg replication tool as free / busy information is not supported E2K10 SP1 direct unless an E2K7 Server is introduced first in the target forest?

    Did you deploy an E2K7 server in the destination environment first, then deployed the E2K10 servers in the same org later? or did you have the E2K10 servers installed natively in the destination forest and somehow got the interorg replication tool working with free/busy on the E2K10 Target forest direct?

    Would you be able to share your process on how you went?

    thanks and regards,
    Kevin

    ReplyDelete
  20. This is exactly what I've been looking for. Thanks for taking the time to blog it and share it with the rest of the world.
    Lifesaver!

    ReplyDelete
  21. I would really like to know how you got the free busy components working across forest, I have a 2003 environment in the 1st forest and 2010 in the 2nd forest, I have implemented Interorg and its fine for Public Folders but not for Free/Busy as they are system folders, please clarify.

    ReplyDelete
  22. any notes on going from Exch2003 to Exch2007?

    ReplyDelete
  23. Hi AG,

    If you are talking about 2003 to 2007 cross forest, how I would do it depends on the size. In smaller scale (100 or less) I tend to use EXMERGE. For anything of any real size or the need for co-existence I go with Quest's QMM.

    Back on the smaller scale, you can precreate the mailboxes, contacts, DLs, etc. in 2007. I create the address policy, etc. to get it ready. I use EXMERGE on 2003 to get the data then import to 2007 to bulk load the mailboxes. For PFs you can either export to PST and import though Inter-Org Replication Tool is much cleaner, get the permissions, etc. Finally I do a cutover of the firewall, run a script via GPO to update the outlook profiles, and one more grab of data using EXMERGE. The GPO script essentially uses an Outlook PRF to create a new profile. This method does nothing for delegates or mailbox rules, the user will need to recreate all of that. Part of the reason I recommend this only for very small migrations. Quest QMM takes care of all of holes a manually process has.

    Hope this helps!
    Rik.

    ReplyDelete
  24. Rik,

    Thanks for sharing this article! It has helped my migration immensely.

    Chris

    ReplyDelete
  25. cross-forest Exchange migration as part of a larger AD migration

    HI Rick,

    Cam you send me the AD migration part?

    Cosy

    mcosy@hotmail.com

    ReplyDelete
  26. Hi Rick,

    May i also have the AD migration part via mail?

    chris@christian-kuever.de

    Thanks.

    ReplyDelete
  27. Hello Rick,

    Please send m the AD migration part by mail

    Evyn.valayten@eis.mu

    Thanks

    ReplyDelete
  28. Hi,

    could you please send me the AD migration part?

    ckuever@fum.de

    Thanks

    ReplyDelete
  29. Hi Rik,

    Great post!. Could you also send me the AD migration part?

    foskinjim@gmail.com

    Thanks.

    ReplyDelete
  30. Hey Rik
    Most users are able to be moved to new exchnage in new forest, some though have following error.
    Is there a way I can edit their account details so I can migrate.
    They currently have AD account in new domain and there mailbox account is linked.

    The operation couldn't be performed because object 'user@domain.local' couldn't be found on 'DomainController New Domain'.
    + CategoryInfo : NotSpecified: (0:Int32) [New-MoveRequest], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : E63FCBC9,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

    Cheers G

    ReplyDelete
  31. Hi Rick Can you explain the prepare Distribution list part?

    What command you used for exporting the groups to CSV?

    Do we have to edit anything in the CSV before importing it?

    Thanks in Advance
    Radan

    ReplyDelete
  32. the CSVDE command isn't working in server 2003.
    Syntax error

    ReplyDelete
  33. Does anybody know about Exchange 2013 ? Would this procedure work with 2010 and 2013 ? Are the scripts still available in exchange 2013 ?
    We have used this several times and it works very good.

    Many Thanks for an answer
    André

    ReplyDelete
  34. Very informative post, it provides the guide to cross forest exchange server migration. It provides the complete information about cross forest migration with exchange server. I found the good solution from http://www.lepide.com/exchangemigrator/ that helps to migrate exchange server to any exchange server and allow migration to public folder and cross forest exchange server. This tool migrate the Public Folders including the contents and folder list from one Exchange Server to another regardless of their versions.

    ReplyDelete

Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.