"Cross forest" migration: Active Directory 2003> 2008 r2, Exchange 2003> 2010, users and computers. Address Book Sync

I don’t know how to write an introductory word, so immediately to the point.

A brief description of the migration methodology:
Migration occurs side-by-side, they need to deploy a parallel AD DS \ Exchange infrastructure and related services. Stages:
1. Deployment of the target infrastructure.
2. Bilateral trust between domains and installation of ADMT.
3. Synchronization of global address books and setting up the coexistence of mail organizations.
4. Actually migration, which consists of the migration of mail, users and computers.

More details under the cut.

For migration of users and computers - ADMT 3.2, for migration of mailboxes - powershell, for synchronization of the global address book - FIM, for synchronization of free \ busy information - Inter-Organization Replication Tool. Thus, all tools used during migration are free. I migrated about 600 users using these tools and did not encounter any significant problems. The solution scales without any problems.

The success of migration by 50% (minimum) depends on the planning stage, at this stage you need to think over everything in advance.
Most attention should be paid to the coexistence of mail organizations, since this service is usually very critical for the organization and problems with this service “pop up” extremely quickly.

1. Namespace.
You need to consider a strategy for forwarding mail between mail organizations during the co-existence of mail organizations. One option is to route all mail through Exchange 2010 and relay (redirect) mail for the "old" mail organization. To do this, you need to add the mail domain of the "old" mail organization to the "accepted domains" of the "new" mail organization and configure this domain as "internal relay", and then configure the new Exchange Server to forward mail to the old Exchange (actually specify where to forward, maybe the new Exchange knows nothing about the old one).

2. Publication of a new postal organization in the old domain (SCP record) and prohibition of access to it for non-migrated users.
At the Exchange command line of the new mail organization, you must run the command "Export-AutoDiscoverConfig -TargetForestDomainController target_domain_controller_domain (those old) -MultipleExchangeDeployments $ true -TargetForestCredential $ targetcredentials". This command creates a record of the new mail organization in the old SCP domain. Outlook clients will find it earlier than the SCP record of the old mail organization, because it is closer to the root of the domain, so that non-migrated users of the old domain can not read information from this SCP record, you need to create a security group, add migrated users there (and add as you migrate ) and allow them read access to this SCP and remove the permission to read this SCP from the Authenticated Users group.
Troubleshooting :: Right-click and hold ctrl to the Outlook icon in the taskbar and select "Test E-Mail Autoconfiguration". You can also enable additional logging in Outlook.

3. Synchronization of GALs and free \ busy information.
FIM 2010 R2 will be used to synchronize GALs. To synchronize contacts, you need to remove contacts that do not need to be synchronized from all organizational units (you can, of course, do the same with FIM filters, but this is, firstly, more difficult, and secondly, worse).
To synchronize free \ busy information, the Inter-Organization Replication Tool will be used (more details here ).

4. Mail migration strategy.
Back to the namespace, if you are migrating from the xxx.company.com domain to the company.com domain, you will need to migrate through an intermediate domain (mail only) such as firm.com. This is necessary because the Exchange server “thinks” that it is a child domain and will return an error even though everything is done correctly.
In general, you have 2 options:
- First, Prepare-MoveRequest then ADMT (order: Prepare-MoveRequest, ADMT, New-MoveRequest)
- First ADMT then Prepare-MoveRequest (order: ADMT, Enable-MailUser, Prepare-MoveRequest, New -MoveRequest)
The first scenario is preferable if you are migrating to a new domain \ forest and there are no copies of these users in it. More details later in the text.

5. User migration strategy.
User migration is carried out after the mail migration (in fact, this is not entirely true, the user can be a member of the new domain \ forest, and mail can be used from the old domain \ forest. It just seems to me the most logical). The process is very simple and intuitive. All operations are done using ADMT. The only advice that can be given here is to come up with a plan \ lists of migrants by the day and coordinate with the business in advance.

6. Computer migration strategy.
Computer migration is the last thing to do, since in this case all user profiles that have ever worked on a computer are migrated. I will explain if you are migrating a computer on which 2 users are working and only one of them is migrated to the new domain \ forest, then after the computer migration the "old" profile will be available (those are copied to the "new" profile, in fact) only to this user. The second user will have an empty profile.

Briefly (relatively) I will cover each item except the first.
Trust between domains:
This stage is important not only because it is necessary for direct migration, but also because if you migrate the number of users other than 100, the migration process will take more than one weekend and you need users from the new domain to have access to resources and services from the old domain. This moment is described in some detail on the Internet and 99% of topics on forums and blog posts link to this article . But quarantine of SIDs prohibits administrators from a trusted domain to manage a trusted domain, and does not open access to resources from the old domain. To do this, you need to enable SID History for the trust (maybe I'm tight, but I spent a lot of time until I realized that SID quarantine does not do what is described everywhere). More details here .
For convenience: SID History - Netdom trust TrustingDomainName / domain: TrustedDomainName / enablesidhistory: Yes / userd: domainadministratorAcct / passwordd: domainadminpwd and quarantine SIDs - Netdom trust TrustingDomainName / domain: TrustedDomainName / quarantine: No / userdcdaddadministrator
Installing ADMT (on the domain controller in the new domain) occurs by clicking on the button a certain number of times (it did not work on SQL Express 2008, it’s easy for 2005). If you need to export passwords, you need to install the Password Export Service on the PDC Emulator of the old domain (after installation, you need to start the service or switch it to auto start, by default it is in manual mode and turned off).
In addition, you must fix the registry key on the domain controller with the PDC role in the new domain. HKLM \ System \ CurrentControlSet \ Services \ Netlogon \ Parameters \ AllowNT4Crypto to support migration of workstations running Windows XP, Vista (up to SP1) and 2000. Google on request AllowNT4Crypto.

3. Synchronization of global address books.
For this we need 1 SQL server, 1 FIM Synchronization Service, 1 Exchange 2010 console on the FIM server 1 (required for parallels). The installation process boils down to pressing a button next and specifying quite obvious parameters (SQL server address, etc.). The only thing - I advise you to create a separate service account for the FIM Synchronization Service.
FIM configuration is done through a graphical interface.
You must enable provisioning first. Tools tab> Options> "Enable Provioning Rules Extension".
Next, you need to create 2 management agents, one will synchronize contacts from the old domain to the new, and the second vice versa.
By default, the GALSync management agent does not synchronize the following users: users hidden from the global address book or with the empty legacyExchangeDN parameter or with the empty (simultaneously) msExchangeHomeServerName and targetAddress parameters or if the proxyAddresses parameter is not filled in addition, if it is “Mailbox Plan”, “Arbitration Mailbox” or “Discovery Mailbox”.
Let's start creating management agents to synchronize address books.
You need to create 2 agent management (they are created identically), on the first screen you need to select "Active Directory global address list (GAL)" and give the agent a name.
On the next screen, you need to specify the forest \ domain and credentials to connect to it.
On the next screen, you need to select the organizational units from which FIM will collect data and the container where it will put crossforest contacts (button "Containers").
The next screen is the most interesting;). You must specify smtp suffixes and most importantly, tell FIM where to put contacts and where to get contacts from. To specify the organizational unit where contacts will be created, you need to click the "Target" button, the "Source" button will allow you to configure organizational units containing users that need to be synchronized. “Support cross-forest delegation (Exchange 2007 or 2010 only)” will create the parameters necessary for delegation of authority to Mail-enabled user objects (for example, reading calendars).
Next, you need to click the next button many times;) On the last screen, you need to specify the version of the e-mail server (for the new domain) and the address where Exchange 2010 was located (http: // exchangeFQDN / powershell).
When setting up the agent for the old domain, you will encounter problems;) The fact is that in Active Directory there are simply not some parameters that FIM looks for by default there, and at some point you will not be able to continue setting up the agent due to an error related to the absence of the parameter "msExchRecipientTypeDetails ". To correct this sad fact, you need to select the user entity at the “Configure Connection Filter” step and delete all references to “msExchRecipientTypeDetails”. But this is only the beginning, at the “Configure Join and Projection Rules” step, you need to select the “Object Type: User” parameter and find and delete “msExchRecipientTypeDetails” in the properties of this entity, and delete “msExchRecipientDisplayType” for the “Object Type: contact” entity and "msExchRecipientTypeDetails". Further settings are identical (except for the address this does not need to be done). Well, or run the Exchange 2010 server installer in the old domain with the / PrepareAD switch;)
Next, you need to run agents every time you need to synchronize global address books or set up a schedule. The order of launching the agents is not critical, first you need to start the full import of agents, then full synchronization, then export. After which it is necessary to make a confirmation import, it is necessary for FIM to make sure that all changes are successfully made to the target systems.
For Trouble Shooting, you need to use the Event Log. But remember that if you have a problem with a specific user / contact, it is better to change the information in the target system than to try to solve the problem using FIM's tools.

4. Migration
I will not cover the migration of users and computers because it is done through a graphical interface and is intuitive. I’ll cover the process of mail migration in some detail.
To begin, I will consider the principle by which the Prepare-MoveRequest script finds contacts in the target domain. Since you have already created mail contacts by FIM, this process must be understood, otherwise if something goes wrong you will have 2 identical entities in the domain and you will not understand why this is so.
- The contact proxyAddresses parameter matches at least one of the values ​​of the proxyAddresses parameter of the source contact.
- The contact is a “Mail Enabled User” and it has filled all the fields in the Active Directory that must be filled in “Mail Enabled User”.
- The script must be run with the parameters "-UseLocalObject" and "-OverwriteLocalObject".
If these conditions are met, the script will use already created contacts. In general, for contacts created by FIM, this is always true (I have not encountered any problems).
Accordingly, if you will first start ADMT, and then the script, your actions should be approximately as follows:
- Delete the email contacts created by FIM (those users of which you are going to migrate).
- Migrate users using ADMT.
- Make the migrated users “Mail Enabled Users” and set them to the “-ExternalEmailAddress” parameter so that it matches one of the addresses of the original users.
Now, one way or another, you have users who can accept the mailbox of the old domain. Next, I will give you scripts that can be used to migrate mail using a CSV file.
Run the execced and ... cd "C: \ Program Files \ Microsoft \ Exchange Server \ V14 \ Scripts"
$ c = (Get-Credential YourOldDomain \ Administrator of the Postal Organization)
Import-Csv c: \ _. Csv | ForEach {. \ Prepare-MoveRequest.ps1 -Verbose -Identity $ _. Identity -UseLocalObject -OverWriteLocalObject -RemoteForestDomainController olddomain_controller_domain_name -RemoteForestCredential $ c}
Import-Csv c: \ _. Csv | ForEach {New-MoveRequest -Identity $ _. Identity -Verbose -TargetDeliveryDomain your new domain.com -TargetDatabase database_name -RemoteLegacy -RemoteCredential $ c}, I also recommend the parameters "-BadItemLimit" and "-AcceptLarge. I would also like to draw your attention to the "-RemoteLegacy" switch, the fact is that in addition to it there is a "-Remote" switch and if you accidentally insert it, and not the correct switch, the EXCHENGE will ask you for an MRSProxy server, those are actually the server with the role CAS Exchange 2010.
I used CSV files that consisted only of a list of full names, in my case this was enough, yours might not be enough.
Remember that a mailbox that migrates to a mail database must meet the requirements of the database (those mailbox sizes, for example).

At the moment, I can’t remember other pitfalls, if there are interesting questions and answers I will supplement the article. Questions are welcome.
ps. useful links:
- A very good article about FIM and the coexistence of postal organizations
- A detailed article about mail migration
- A useful article about autodiscover, scp and the coexistence of postal organizations.
- An article that will be useful for understanding the work of the “Movie Requests” and one more .

This post is a set of pseudo-random data.
4c74356b41

Also popular now: