Cross forest migration: Active Directory 2003> 2008 r2, Exchange 2003> 2010, users and computers. Address book synchronization
I can not write the introductory word, because immediately to the point.
Brief description of the migration technique:
Migration occurs side-by-side, they need deployment of a parallel AD DS \ Exchange infrastructure and related services. Stages:
1. Deploy target infrastructure.
2. Bilateral trust between domains and installing ADMT.
3. Synchronization of global address books and setting up the coexistence of postal organizations.
4. Actually migration, which consists of the migration of mail, users and computers.
More under the cut.
')
For the migration of users and computers - ADMT 3.2, for the migration of mailboxes - powershell, for synchronization of the global address book - FIM, for synchronization of the 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 is scaled without any problems.
The success of migration by 50% (minimum) depends on the planning stage, at this stage you need to think through everything in advance.
Most attention should be paid to the coexistence of postal 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 think about the strategy of mail forwarding between postal organizations during the coexistence of postal organizations. One option is to route all mail through Exchange 2010 and relay (forwarding) mail for the “old” mail organization. To do this, you need to add the mail domain of the “old” postal organization to the “accepted domains” of the “new” postal organization and configure this domain as an “internal relay”, and then configure the new Exchange Server to forward mail to the old Exchange (in fact, specify where to forward, tk new Exchange knows nothing about old). In this case, the Exchange 2010 mail server, when receiving a letter for a user from this domain, will search for a user with this address - in the absence of this user, the letter will be redirected to the mail server of the “old” postal organization.
2. Publication of a new postal organization in the old domain (SCP record) and prohibition of access to it for non-migrated users.
In the Exchange command line of the new mail organization, you must run the "Export-AutoDiscoverConfig -TargetForestDomainController domain_controller_domain_domain (those old) -MultipleExchangeDeployments $ true -TargetForestCredential $ targetcredentials" command. This command creates a new postal organization entry in the old SCP domain. Outlook clients will find it earlier than the SCP record of the old mail organization, it is closer to the root of the domain, so that non-migrated users of the old domain cannot read the information from this SCP entry, you must create a security group, add migrated users there (and add as you migrate ) and allow them read access to this SCP and remove permission to read this SCP from the Authenticated Users group.
Troubleshooting :: Right-click with ctrl pressed on the Outlook icon in the taskbar and select the item “Test E-Mail Autoconfiguration”. You can also enable additional logging in Outlook.
3. Synchronization GAL'ov and free \ busy information.
To synchronize GAL'ov will be used FIM 2010 R2. 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 thing with FIM filters, but this is, first, more difficult, and second, worse).
To synchronize the free \ busy information will be used Inter-Organization Replication Tool (more here ).
4. Mail migration strategy.
Returning 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), for example, 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 on the text.
5. User migration strategy.
Migration of users is carried out after the migration of mail (in fact, this is not quite so, the user may be a member of the new domain \ forest, and use mail from the old domain \ forest. Just this option seems to me the most logical). The process is very simple and intuitive. All operations are performed using ADMT. The only advice that can be given here is to come up with a plan / lists of migrants by day and coordinate with the business.
6. Computer migration strategy.
Migration of computers is carried out last, since in this case all user profiles that have ever worked on a computer are migrated. I will explain that if you migrate a computer on which 2 users work and only one of them is migrated to the new domain \ forest, then after migration of the computer 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) illuminate every 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 a number of users other than 100, the migration process will take more than one weekend and you need to ensure that users from the new domain have access to resources and services from the old domain. This moment is described in some detail on the Internet and 99% of the topics on forums and blog posts link to this article . But SID quarantine prevents administrators from a trusted domain from managing a trusted domain, rather than opening access to resources from the old domain. To do this, you need to enable SID History for 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). Read more here .
For convenience: SID History - Netdom trust TrustingDomainName / domain: TrustedDomainName / enablesidhistory: Yes / userd: domainadministratorAcct / passwordd: domainadminpwd and Quarantine SID'ov - Netdom trust TrustingDomainName / domain: TrustedDomainName / quarantine: No / userd.
Installing ADMT (on the domain controller in the new domain) is done by pushing the button further a certain number of times (it did not come up on SQL Express 2008, it was easy on 2005). If you need to export passwords, you need to set the Password Export Service on the PDC Emulator of the old domain (after installation, you need to start the service or rearrange it to start automatically, by default it is in manual mode and turned off).
In addition, you must correct the registry key on a domain controller with the role of PDC in the new domain. HKLM \ System \ CurrentControlSet \ Services \ Netlogon \ Parameters \ AllowNT4Crypto to support the migration of workstations running Windows XP, Vista (up to SP1) and 2000. We google on request AllowNT4Crypto.
3.Sync global address books
To do this, we need a SQL server, 1 piece, FIM Synchronization Service, 1 piece, the Exchange 2010 console on the FIM server, 1 piece (required for the version). The installation process is reduced to pressing the button further and specifying quite obvious parameters (the address of the SQL server, etc.). The only thing - I advise you to make a separate service account for FIM Synchronization Service.
FIM is configured via a graphical interface.
Provisioning must be enabled first. Bookmark Tools> 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 an empty “legacyExchangeDN” parameter or with empty parameters (at the same time) “msExchangeHomeServerName” and “targetAddress” or when the “proxyAddresses” parameter is not filled, besides, if it is “Mailbox Plan”, “Arbitration Mailbox” or “Discovery Mailbox”.
Let's start creating management agents for address book synchronization.
It is necessary to create 2 management agents (they are created identically), on the first screen you need to select “Active Directory global address list (GAL)” and give a name to the agent.
On the next screen, you must 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 take the data and the container where it will stack the crossforest contacts (the “Containers” button).
The next screen is the most interesting;). You must specify smtp suffixes and most importantly, tell FIM where to put the contacts and where to get the contacts from. To specify the organizational unit where contacts will be created, you must click the "Target" button. The "Source" button will allow you to configure the organizational units containing the users that you want to synchronize. “Support cross-forest delegation (Exchange 2007 or 2010 only)” will create the parameters necessary for delegation of authority for Mail-enabled user objects (for example, reading calendars).
Next, you need to click on the button many times;) On the last screen, you need to specify the version of the server ekschendzh (for the new domain) and the address where the Exchange 2010 is located (http: // exchangeFQDN / powershell).
When setting up an agent for the old domain, you will encounter problems;) The fact is that in Active Directory there are simply some parameters that FIM is looking for there by default, 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 “msExchRecipientTypeDetails” parameter. ". To correct this sad fact, you need to select the user entity in the “Configure Connection Filter” step and delete all references to “msExchRecipientTypeDetails”. But this is only the beginning, in 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 configuration is identical (except for specifying the address, I have to, this is not necessary). Well, or run in the old domain Exchange Server 2010 installer with the / PrepareAD key;)
Next, you need to run the agents every time you need to synchronize the global address books or set up a schedule. The sequence of launching agents is not critical, first you need to run a full import of agents, then full synchronization, then export. After that, it is necessary to make a confirming import, it is necessary for FIM to make sure that all changes are successfully made to the target systems.
For troubleshooting, 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 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 will cover the mail migration process 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 with 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 “proxyAddresses” parameter of the contact matches at least one of the “proxyAddresses” parameter values ​​of the original contact.
- The contact is “Mail Enabled User” and it has all the fields in Active Directory that have to be filled in with “Mail Enabled User”.
- The script must be run with the parameters "-UseLocalObject" and "-OverwriteLocalObject".
If these conditions are met the script will use the already created contacts. In general, for contacts created by FIM, this is always true (I have not encountered any problems).
Accordingly, if you start ADMT first, and then the script, your actions should be approximately as follows:
- Delete email contacts created by FIM (those users of which you are going to migrate).
- Migrate users using ADMT.
- Make migrated users "Mail Enabled Users" and set them the "-ExternalEmailAddress" parameter so that it matches one of the addresses of the original users.
Now you somehow have users who can take a mailbox of the old domain. Next, I will give you all the scripts that can be used to migrate mail using a CSV file.
Start the exend and ... cd "C: \ Program Files \ Microsoft \ Exchange Server \ V14 \ Scripts"
$ c = (Get-Credential Your Old Old Domain \ Mail Administrator)
Import-Csv c: \ _. Csv | ForEach {. \ Prepare-MoveRequest.ps1 -Verbose -Identity $ _. Identity -UseLocalObject -OverWriteLocalObject -RemoteForestDomainController old_domain_controller_domain -RemoteForestCredential $ c}
Import-Csv c: \ _. Csv | ForEach {New-MoveRequest -Identity $ _. Identity -Verbose -TargetDeliveryDomain vashnovyydomen.com -TargetDatabase database_name -RemoteLegacy -RemoteCredential $ c}, so I recommend settings "-BadItemLimit" and "-AcceptLargeDataLoss". I would also like to draw your attention to the switch "-RemoteLegacy", the fact is that besides it there is a switch "-Remote" and if you accidentally insert it, but not the correct switch, the exchanger will ask you for the MRSProxy server, those are actually the server with the role CAS Exchange 2010.
I used CSV files that consisted only of the list of names, in my case it was enough, yours may not be enough.
Remember that a mailbox that migrates to the mail database must meet the requirements of the database (for example, the size of the mailbox, for example).
At the moment I can not remember the other pitfalls, if there are interesting questions and answers, I will supplement the article. Questions are welcome.
ps useful links:
- Very good article about FIM and the coexistence of postal organizations
- Detailed article about mail migration
- Useful article about autodiscover, scp and co-existence of postal organizations.
- An article which is useful for understanding the work of “Move Requests” and one more .
This post is a pseudo-random data set.
4c74356b41
Brief description of the migration technique:
Migration occurs side-by-side, they need deployment of a parallel AD DS \ Exchange infrastructure and related services. Stages:
1. Deploy target infrastructure.
2. Bilateral trust between domains and installing ADMT.
3. Synchronization of global address books and setting up the coexistence of postal organizations.
4. Actually migration, which consists of the migration of mail, users and computers.
More under the cut.
')
For the migration of users and computers - ADMT 3.2, for the migration of mailboxes - powershell, for synchronization of the global address book - FIM, for synchronization of the 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 is scaled without any problems.
The success of migration by 50% (minimum) depends on the planning stage, at this stage you need to think through everything in advance.
Most attention should be paid to the coexistence of postal 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 think about the strategy of mail forwarding between postal organizations during the coexistence of postal organizations. One option is to route all mail through Exchange 2010 and relay (forwarding) mail for the “old” mail organization. To do this, you need to add the mail domain of the “old” postal organization to the “accepted domains” of the “new” postal organization and configure this domain as an “internal relay”, and then configure the new Exchange Server to forward mail to the old Exchange (in fact, specify where to forward, tk new Exchange knows nothing about old). In this case, the Exchange 2010 mail server, when receiving a letter for a user from this domain, will search for a user with this address - in the absence of this user, the letter will be redirected to the mail server of the “old” postal organization.
2. Publication of a new postal organization in the old domain (SCP record) and prohibition of access to it for non-migrated users.
In the Exchange command line of the new mail organization, you must run the "Export-AutoDiscoverConfig -TargetForestDomainController domain_controller_domain_domain (those old) -MultipleExchangeDeployments $ true -TargetForestCredential $ targetcredentials" command. This command creates a new postal organization entry in the old SCP domain. Outlook clients will find it earlier than the SCP record of the old mail organization, it is closer to the root of the domain, so that non-migrated users of the old domain cannot read the information from this SCP entry, you must create a security group, add migrated users there (and add as you migrate ) and allow them read access to this SCP and remove permission to read this SCP from the Authenticated Users group.
Troubleshooting :: Right-click with ctrl pressed on the Outlook icon in the taskbar and select the item “Test E-Mail Autoconfiguration”. You can also enable additional logging in Outlook.
3. Synchronization GAL'ov and free \ busy information.
To synchronize GAL'ov will be used FIM 2010 R2. 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 thing with FIM filters, but this is, first, more difficult, and second, worse).
To synchronize the free \ busy information will be used Inter-Organization Replication Tool (more here ).
4. Mail migration strategy.
Returning 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), for example, 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 on the text.
5. User migration strategy.
Migration of users is carried out after the migration of mail (in fact, this is not quite so, the user may be a member of the new domain \ forest, and use mail from the old domain \ forest. Just this option seems to me the most logical). The process is very simple and intuitive. All operations are performed using ADMT. The only advice that can be given here is to come up with a plan / lists of migrants by day and coordinate with the business.
6. Computer migration strategy.
Migration of computers is carried out last, since in this case all user profiles that have ever worked on a computer are migrated. I will explain that if you migrate a computer on which 2 users work and only one of them is migrated to the new domain \ forest, then after migration of the computer 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) illuminate every 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 a number of users other than 100, the migration process will take more than one weekend and you need to ensure that users from the new domain have access to resources and services from the old domain. This moment is described in some detail on the Internet and 99% of the topics on forums and blog posts link to this article . But SID quarantine prevents administrators from a trusted domain from managing a trusted domain, rather than opening access to resources from the old domain. To do this, you need to enable SID History for 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). Read more here .
For convenience: SID History - Netdom trust TrustingDomainName / domain: TrustedDomainName / enablesidhistory: Yes / userd: domainadministratorAcct / passwordd: domainadminpwd and Quarantine SID'ov - Netdom trust TrustingDomainName / domain: TrustedDomainName / quarantine: No / userd.
Installing ADMT (on the domain controller in the new domain) is done by pushing the button further a certain number of times (it did not come up on SQL Express 2008, it was easy on 2005). If you need to export passwords, you need to set the Password Export Service on the PDC Emulator of the old domain (after installation, you need to start the service or rearrange it to start automatically, by default it is in manual mode and turned off).
In addition, you must correct the registry key on a domain controller with the role of PDC in the new domain. HKLM \ System \ CurrentControlSet \ Services \ Netlogon \ Parameters \ AllowNT4Crypto to support the migration of workstations running Windows XP, Vista (up to SP1) and 2000. We google on request AllowNT4Crypto.
3.Sync global address books
To do this, we need a SQL server, 1 piece, FIM Synchronization Service, 1 piece, the Exchange 2010 console on the FIM server, 1 piece (required for the version). The installation process is reduced to pressing the button further and specifying quite obvious parameters (the address of the SQL server, etc.). The only thing - I advise you to make a separate service account for FIM Synchronization Service.
FIM is configured via a graphical interface.
Provisioning must be enabled first. Bookmark Tools> 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 an empty “legacyExchangeDN” parameter or with empty parameters (at the same time) “msExchangeHomeServerName” and “targetAddress” or when the “proxyAddresses” parameter is not filled, besides, if it is “Mailbox Plan”, “Arbitration Mailbox” or “Discovery Mailbox”.
Let's start creating management agents for address book synchronization.
It is necessary to create 2 management agents (they are created identically), on the first screen you need to select “Active Directory global address list (GAL)” and give a name to the agent.
On the next screen, you must 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 take the data and the container where it will stack the crossforest contacts (the “Containers” button).
The next screen is the most interesting;). You must specify smtp suffixes and most importantly, tell FIM where to put the contacts and where to get the contacts from. To specify the organizational unit where contacts will be created, you must click the "Target" button. The "Source" button will allow you to configure the organizational units containing the users that you want to synchronize. “Support cross-forest delegation (Exchange 2007 or 2010 only)” will create the parameters necessary for delegation of authority for Mail-enabled user objects (for example, reading calendars).
Next, you need to click on the button many times;) On the last screen, you need to specify the version of the server ekschendzh (for the new domain) and the address where the Exchange 2010 is located (http: // exchangeFQDN / powershell).
When setting up an agent for the old domain, you will encounter problems;) The fact is that in Active Directory there are simply some parameters that FIM is looking for there by default, 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 “msExchRecipientTypeDetails” parameter. ". To correct this sad fact, you need to select the user entity in the “Configure Connection Filter” step and delete all references to “msExchRecipientTypeDetails”. But this is only the beginning, in 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 configuration is identical (except for specifying the address, I have to, this is not necessary). Well, or run in the old domain Exchange Server 2010 installer with the / PrepareAD key;)
Next, you need to run the agents every time you need to synchronize the global address books or set up a schedule. The sequence of launching agents is not critical, first you need to run a full import of agents, then full synchronization, then export. After that, it is necessary to make a confirming import, it is necessary for FIM to make sure that all changes are successfully made to the target systems.
For troubleshooting, 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 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 will cover the mail migration process 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 with 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 “proxyAddresses” parameter of the contact matches at least one of the “proxyAddresses” parameter values ​​of the original contact.
- The contact is “Mail Enabled User” and it has all the fields in Active Directory that have to be filled in with “Mail Enabled User”.
- The script must be run with the parameters "-UseLocalObject" and "-OverwriteLocalObject".
If these conditions are met the script will use the already created contacts. In general, for contacts created by FIM, this is always true (I have not encountered any problems).
Accordingly, if you start ADMT first, and then the script, your actions should be approximately as follows:
- Delete email contacts created by FIM (those users of which you are going to migrate).
- Migrate users using ADMT.
- Make migrated users "Mail Enabled Users" and set them the "-ExternalEmailAddress" parameter so that it matches one of the addresses of the original users.
Now you somehow have users who can take a mailbox of the old domain. Next, I will give you all the scripts that can be used to migrate mail using a CSV file.
Start the exend and ... cd "C: \ Program Files \ Microsoft \ Exchange Server \ V14 \ Scripts"
$ c = (Get-Credential Your Old Old Domain \ Mail Administrator)
Import-Csv c: \ _. Csv | ForEach {. \ Prepare-MoveRequest.ps1 -Verbose -Identity $ _. Identity -UseLocalObject -OverWriteLocalObject -RemoteForestDomainController old_domain_controller_domain -RemoteForestCredential $ c}
Import-Csv c: \ _. Csv | ForEach {New-MoveRequest -Identity $ _. Identity -Verbose -TargetDeliveryDomain vashnovyydomen.com -TargetDatabase database_name -RemoteLegacy -RemoteCredential $ c}, so I recommend settings "-BadItemLimit" and "-AcceptLargeDataLoss". I would also like to draw your attention to the switch "-RemoteLegacy", the fact is that besides it there is a switch "-Remote" and if you accidentally insert it, but not the correct switch, the exchanger will ask you for the MRSProxy server, those are actually the server with the role CAS Exchange 2010.
I used CSV files that consisted only of the list of names, in my case it was enough, yours may not be enough.
Remember that a mailbox that migrates to the mail database must meet the requirements of the database (for example, the size of the mailbox, for example).
At the moment I can not remember the other pitfalls, if there are interesting questions and answers, I will supplement the article. Questions are welcome.
ps useful links:
- Very good article about FIM and the coexistence of postal organizations
- Detailed article about mail migration
- Useful article about autodiscover, scp and co-existence of postal organizations.
- An article which is useful for understanding the work of “Move Requests” and one more .
This post is a pseudo-random data set.
4c74356b41
Source: https://habr.com/ru/post/188204/
All Articles