Exchange 2010 Cross-Forest Migration Step by Step Guide Part I

Transcription

1 3 Exchange 2010 Cross-Forest Migration Step by Step Guide Part I Mohamed Marzouk [MSFT] 10 Jun :44 AM 13 This Guide will explain the detailed steps required to do cross forest migration from source forest running Exchange 2003 to target forest running Exchange Active Directory Migration Tool (ADMT) will be used to migrate user accounts as well as computer accounts. There are two scenarios when using ADMT to migrate user accounts with Exchange: 1. Run Prepare-MoveRequest.ps1 script first then ADMT: in this scenario the steps will be in the following order: a. Prepare-MoveREquest.ps1: The script will be used to create Mail Enabled Users (MEU) in the target forest; the MEUs will be disabled and will contain the following attributes: legacyexchangedn, mail, mailnickname, msexchmailboxguid, proxyaddresses, X500, targetaddress, useraccountcontrol, userprincipalname. b. ADMT to migrate user accounts: the main target is to get the old SID from the source domain (SID History), and to synchronize the password from the source domain to the new user account in the target domain, of course other AD attributes could be migrated like phone, address, title c. Move Mailbox: using new-move request from the source forest to the target forest. d. ADMT to migrate the computer account: this will mainly disjoin the client machine from the source domain and join the new domain, also will add (or replace) the SID of the new user in the target forest on the same profile used by the old user account, other options available like local group, profiles.. 2. Run ADMT first then Prepare-MoveRequest.ps1: in this scenario the steps will be in the following orders: a. ADMT to migrate the user accounts from the source forest to the target forest, users will be created or merged by ADMT not the script, SID history and password synchronization along with other AD attributes could be merged from the source forest to the target forest. By default ADMT is excluding all Exchange attributes. b. Convert the user accounts created or merged by ADMT to Mail Enabled User (MEU) accounts with proxy address as the source forest user account. c. Prepare-moverequest.ps1: the script will be used with localobject and overwritelocalobject switches, so the script will use the existing user accounted and will not create new account. d. New-MoveRequest: to move the mailbox from the source forest to the target forest. Choosing which scenario will be based on the customer environment, the selection of the scenario should consider: 1. First Scenario: This is the easy and straight forward scenario, should be used if the target forest (domain) is newly created, no users from the source domain exist in the target domain. 2. Second Scenario: As this is more complicated scenario, it should be used if ADMT must run first before prepare-moverequest, and this will be needed in case of there are already users from the source forest in the target forest. This series of articles will focus on the second scenario. Before going on the detailed steps, let s first explain the environment and the requirements. The current environment includes the following: 1. Source forest running Windows 2003, and Exchange 2003 (egypt.tailspin.com), address of all user 2. Target forest running Windows 2008 R2 and Exchange 2010 (tailspin.com), address for all 3. There are already user accounts for the source forest in the target forest, created manually and used by many applications, and they must be used.

2 The following diagram shows the details of the current environment: As the migration will take time, the co-existence period should be considered, so this guide will cover the following: 1. Addressing the migration challenges. 2. Configure Mail Flow between the two forests. 3. Migration of user and computer accounts using ADMT. 4. Exchange Mailbox migration using native tools. 5. Enable sharing Free/Busy information between the two forests, so when the user is migrated to the target forest, he will still be able to check the free/busy information of other users in the source forest and vice versa. The second part of this guide will address the migration challenges and setting up the mail flow between the two forests. Exchange 2010 Cross-Forest Migration Step by Step Guide Part I Exchange 2010 Cross-Forest Migration Step by Step Guide Part II Exchange 2010 Cross-Forest Migration Step by Step Guide Part III 3 Comments Vaseem 8 Jul :37 PM Nice - Short N Sweet. i think it would be better to mention about the SID history in a little bit detail as most of the cases we use it to ensure that migrated user is able to use the old domain applications and resources. Any way I like the Post. mvansickler 20 Jul :15 AM I believe in your first sentence you mean the target is Exchange Looks like a typo. ITnavMan 17 Aug :03 PM Nice introduction. I really like the scenario. Where's Part II? :)

3 FlofromTO 18 Oct :30 AM Where is part II? Mohamed Marzouk [MSFT] 18 Oct :34 PM Thanks all for your comments, Part II and III coming early next week, so stay tuned :). alain33 19 Oct :29 AM Great post. Waiting for the next one... :) bluej 23 Oct :27 PM I am looking for the part II. Has it posted? If so, URL? Tried googled but no luck. Hemant 6 Nov :12 PM Nice Article Syed Aleem Uddin 19 Feb :48 AM when the part IV of the article will be released? waiting impatiently!!! Sathesh 18 Apr :09 AM Nice one!! Satheshwaran Manoharan 18 Apr :09 AM Good One! Ashwini Kumar 4 Jul :24 PM Its really nice one! Allen 15 Oct :02 AM My situation is a little different from yours. Our customer wants to upgrade from 2007 to 2010 and also change the forest name. Do you recommend upgrading Exchange in source forest or installing ex 2010 in the new forest then migrate?

4 0 Exchange 2010 Cross-Forest Migration Step by Step Guide Part II Mohamed Marzouk [MSFT] 25 Oct :26 AM 0 In Part I of this guide I ve explained the process of cross-forest migration and the differences between using ADMT first or using Prepare-MoveReuqest.Ps1 script first, I ve also explained the migration scenario and the current environment. Starting from this part we will talk about migration challenges and the best way to address these challenges. A quick reminder of the current environment: First Challenge: ADMT First Then Prepare-MoveRequest.Ps1: As explained in Part I, we need to migrate user accounts and mailboxes from the source forest to the target forest. However in the target forest (tailspin.com) we already have user accounts created manually for users in the source forest (egypt.tailspin.com), so each user in egypt.tailspin.com has two user accounts: Primary Account: AD User in the Egypt forest used for Windows logon, and everything. Secondary Account: AD user account created in Tailspin.com forest used for other applications hosted in tailspin, this user used to grant permissions and create profiles on Terminal Service servers. So the main target is we need to use the existing users in the target forest (tailspin.com), the consequences of this decision as follow: 1. We can t use the script first; the script in this scenario will create a new disabled Mail Enabled User (MEU), and will ignore the existing user account. 2. We will have to run ADMT first to synchronize the password, migrate SID history, and other AD attributes from the source forest to the target forest. 3. We need to provide prepare-moverequest.ps1 with attribute that links the user in the target forest with the user in the source forest, so when the script runs it will merge all the properties from the source account to the target account and will not create a new user.

5 Before going to the detailed steps, let s see the history and the relation between ADMT and Prepare- MoveRequest.Ps1: ADMT and Exchange Attributes: By default ADMT doesn t migrate Exchange attributes including mail, proxyaddresses, anything started by msexch. The reason behind that because when ADMT transfers Exchange attributes (e.g. homemdb, homemta, showinaddressbook, msexch*) that will make the target user looks like a legacy mailbox in the target domain. This leaves the target account in an invalid state (e.g. homemdb still points to the old forest) which is unexpected for the PrepareMoveRequest.ps1 script. To prevent this, Exchange attributes are excluded from ADMT. In Exchange RTM, running ADMT first and then running the PrepareMoveRequest script: When a user is created via ADMT, the PrepareMoveRequest script doesn't work since there are no proxyaddresses for the script to match the source forest user with the target forest user (the script is looking for some attributes in the target account and try to match it with the source account). The recommended approach was to copy at least 1 proxy address using ADMT. Even after doing that and using the -UseLocalObject parameter, the script will only copy the 3 mandatory parameters (msexchmailboxguid, msexcharchiveguid, msexcharchivename). This is not very useful as the other mandatory attributes are not copied. In SP1, a new switch has been added OverwriteLocalObject which mainly designed when running ADMT first scenario. ADMT can copy the SIDhistory, password, and proxyaddresses, and the PrepareMoveRequest script can attach the source account with the target account and sync the other attributes. In this case, it will copy attributes from source to target, so it's the opposite of UseLocalObject. PrepareMoverRequest.ps1: The PrepareMoveRequest.ps1 script can identify and match existing accounts in the target forest based on their SMTP address (proxyaddresses attribute). The script will only use the existing target accounts if all the following are true: The target account has a value in proxyaddresses which matches one of the proxyaddresses of the source account. The target account is a mail enabled user (healthy MEU that can be retrieves with Get-MailUser command, which means it must have mail attributes like 'mail', 'External Address', etc). You need to specify the -UseLocalObject parameter in the script. (and OverwriteLocalObject) If all these are true, the script will copy further attributes needed (especially msexchmailboxguid) to the target account so that the move request can process the accounts. If one of the above items is missing, the script will duplicate by creating a new disabled Mail Enabled User (MEU), and no error will be returned, using the script in verbose mode will let you see the details. Based on that the steps to solve this challenge should be: 1. Select the user or patch of users to be migrated. 2. Delete any Mail Contact for the users in the target forest. 3. Use ADMT to migrate the user account (merge) from source forest to target forest, this is required to get SID History and sync the password. Once ADMT migration is completed we should have normal user accounts with SIDHistory as the following snapshot:

6 4. Make the user (or patch of users) Mail Enabled User (MEU) (by running Enabl User), setting External Address matches the same address of the user in the source forest (this will be the anchor to associate the user in the target forest with the user in the source forest). The following snapshot shows how to do it for bulk users using (Import-CSV) We have a very simple csv file that contains two fields as the following snapshot:

7 Now we should have a healthy MEU ready for Prepare-MoveRequest, the following snapshot shows the LDAP properties of this user account: Check the proxyaddresses, mail, and mailnickname. 5. Use Prepare-MoveRequest.Ps1 with uselocalobject and overwritelocalobject, so the script will use the existing user account and overwrite the attributes in the target account by the attributes in the source account and most importantly migrate all the required attributes, so the MEU is ready to move the mailbox. Again we can do it for bulk users by using (Import-CSV), the following snapshot shows the command in verbose mode:

8 Check the first two lines, local account has been found and the anchor (proxyaddresses) has been used to identify it, then Merge will be done, last line indicates that the process is successfully completed. Now we have MEU ready to move the mailbox. In this part we solved the first challenge, in the next part we will continue with the second challenge before moving to the technical steps of the migration. Exchange 2010 Cross-Forest Migration Step by Step Guide Part I Exchange 2010 Cross-Forest Migration Step by Step Guide Part II Exchange 2010 Cross-Forest Migration Step by Step Guide Part III 0 Comments

9 0 Exchange 2010 Cross-Forest Migration Step by Step Guide Part III Mohamed Marzouk [MSFT] 25 Oct :44 AM 12 In this part of Cross-Forest Migration Guide we will solve the second challenge but before that let s take a look again on the current environment: Second Challenge: Move Mailbox Error: As explained in Part II, we will use ADMT first to migrate SID History, Password and other AD attributes then we will use Prepare-MoveRequest, the idea of these steps is to get healthy Mail Enabled User (MEU) that will be used later to move the mailbox from the source forest to the target forest, after finishing Part II now we have the healthy MEU and we can check the LDAP properties for the mandatory attributes required for the move to succeed. The following snapshot shows the LDAP attributes:

10 Now this is the time to run New-MoveRequest to migrate the mailbox from the source forest to the target forest. The following snapshot shows the result of running New-MoveRequest: The error is: Cannot find a recipient that has mailbox GUID The error is clearly saying that there is no MEU with the mandatory attribute msexchmailboxguid, however when we check the MEU LDAP property: The mailbox GUID is there (of course it s there because Prepare-MoveRequest migrated this attribute, check Part II), so what s the problem?! We have MEU with the required msexchmailboxguid and each time we try to migrate the mailbox we will

11 get the same error: Cannot find a recipient that has the mailbox GUID. The problem here that when the remote forest implies a child name relationship, Exchange 2010 will think that this is a child domain and then the strange error will be returned. In our case the source forest name is egypt.tailspin.com and the target forest name is tailspin.com so Exchange will think that the target is child domain from the source forest and it will fail. So what s the solution? We have two painful options: 1. Export all mailboxes as PST files from the source forest and then import it in the target forest: this option is based on big bang approach where there is no co-existence. This option might be considered in small companies where we can disconnect the source forest, export the PSTs and import it to the target forest in reasonable downtime. 2. Co-Existence: when co-existence is required in enterprise companies with thousands of users the only option will be creating Intermediate Forest. Intermediate Forest: As you might guess this will be our option as co-existence is required, in this option we will do the migration on two steps. First we will need to create a new Active Directory Forest with a different name in our scenario we will use nwtraders.com. This forest will contain Exchange 2010 server we can use single server with HUB/CAS/MBX installed on the same server, as this forest will be intermediate and will not serve any users you may decide that high availability is not required. Now the migration will be done on two steps as following: 1. Move the mailbox of the user (batch of users) from the source forest egypt.tailspin.com to the intermediate forest nwtraders.com. 2. Move the mailbox of the user (batch of users) from the intermediate forest nwtraders.com to the target forest tailspin.com. After implementing the intermediate forest it s very important to complete the following tasks before starting the migration: 1. Apply SSL certificate on the intermediate forest that can is trusted and can be validated from the target forest. If Exchange 2010 server in the target forest can t validate the certificate moving mailbox will fail. 2. Enable the MRS Proxy service: this service responsible of moving the mailboxes from/to Exchange 2010, as the intermediate Exchange server will be 2010 then moving mailboxes will not work without enabling the MRS Proxy service. The following section contains the detailed steps required to prepare the intermediate forest: 1. Install SSL Certificate This certificate must be trusted and validated from the CAS servers in the target forest. The certificate could be generated from internal Certification Authority trusted by the CAS servers in Corp forest. The steps to request to install the certificate as follow (on Intermediate Forest Exchange Server): a. Request certificate:

12 I. Open Exchange Management Shell: II. $data = New-ExchangeCertificate -GenerateRequest domainname mail.nwtraders.com,autodiscover.nwtraders.com,servername.nwtraders.com -FriendlyName Int-CAS II. Set-Content -path "C:\CertRequest.req" -Value $Data b. Import the Certificate: I. Import-ExchangeCertificate -PrivateKeyExportable:$true -FileData ([Byte[]]$(Get-Content - Path C:\cert.cer -Encoding Byte -ReadCount 0)) Enable-ExchangeCertificate -Services IIS 2. Enable MRSProxy Service This step should be completed before moving the mailboxes from the Intermediate forest to the target forest. a. On the Client Access server in the Intermediate Forest (nwtraders.com), open the following file with a text editor such as Notepad: C:\program files\microsoft\exchange\v14\clientaccess\exchweb\ews\web.config b. Locate the following section in the Web.config file: <!-- Mailbox Replication Proxy Service configuration --> <MRSProxyConfiguration IsEnabled="false" MaxMRSConnections="100" DataImportTimeout="00:01:00" /> c. Change the value of IsEnabled to "true". d. Save and close the Web.config file. In this part we addressed the second challenge and now we are ready to start the migration, in the next part we will start by configuring co-existence between the three forests. Exchange 2010 Cross-Forest Migration Step by Step Guide Part I Exchange 2010 Cross-Forest Migration Step by Step Guide Part II Exchange 2010 Cross-Forest Migration Step by Step Guide Part III 0 Comments Patrick 6 Nov :47 AM Wow! Very useful. Waiting for the next one. When? Patrick 16 Jan :57 AM Hi, Great post, as the next one been posted yet?

13 Taranjeet Singh 17 Apr :46 AM Nice n crisp article series, waiting curiously for part IV... Adam Paul Shattuck 15 May :02 PM dude where's part 4? I really really need the co-existence aspect of the migration!!! :-) Shared namespace, free/busy between the forests, etc... Great work so far, but it seems like with part 3 you focused on a potential "gotcha" that most companies who are migrating (due to an acquisition or merger) won't encounter! I'm sure it helped some folks out there and they really appreciated the help, though! I appreciate your effort on this! AUSSUPPORT 17 May :44 AM next one pls Paul Carroll 10 Sep :58 PM Same as others really need co-existence information and how to do so migrated mailbox users can still communicate with each other Mr half migrated 8 Oct :11 PM Well I just found this page a year after it was made but still no sign of any other parts. Can someone else pick it up as it was getting good! Banio 22 Oct :14 PM Very useful..can't wait for part IV Raviprem C J 29 Nov :22 AM It is really Good Article, thanks for sharing Best Regards, Raviprem J Brubaker 16 Apr :59 AM A year and a half later and nothing additional. Will this ever be completed? This would be a very useful source of information. Thomas Heaney 24 Apr :09 PM Great write up. I would love to see scenario 1 Thomas Heaney 24 Apr :17 PM Great write up. I would love to see scenario 1 or even a part 4 here.

14