Active Directory Migration 2003 to 2008 R2

A few years ago in a past life I performed an Active Directory inter-forest migration from domain functional level 2003 to 2008R2 using ADMT 3.2 and PES 3.1 (x64/x86). An Exchange Server mailbox migration from 2007 to 2010 was performed simultaneously. The only problem I ran into was that the old X.500 addresses for the mailboxes aren’t migrated to the new mail system. The cached auto-complete email addresses in Outlook use the X.500 address for internal emails which caused internal to internal email to fail. Once the auto-complete addresses were wiped out everything was fine and Outlook began creating new auto-complete data with correct X.500 data. Good thing I saved this documentation, otherwise I wouldn’t be able to post this incredibly exciting information.

Where to get ADMT 3.2 and PES 3.1

The following tools are available from the Microsoft Download Center.

Active Directory Migration Tool version 3.2 (ADMT v3.2)

Provides an integrated toolset to facilitate migration and restructuring of tasks in an Active Directory Domain Services infrastructure.

Download Active Directory Migration Tool version 3.2

Password Export Server version 3.1 (PES v3.1)

Enables password migration during account migration in an Active Directory Domain Services infrastructure.

Download Password Export Server version 3.1 (PES v3.1), x64 package

Download Password Export Server version 3.1 (x86)

ADMT Guide

Provides guidance for migration of domains by using the Active Directory Migration Tool.

Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains

Notes

• ADMT has not been updated for Windows 8.1 and 10 workstation migration.
• Windows Server 2012, Windows Server 2012 R2 and later version of Windows Server have not been tested for modern applications and profile migrations. Your experience may vary, depending on many factors, including the Windows version that you are migrating. Use the tools suite at your own risk.
• An alternative to the ADMT tools suite is also available from Microsoft Services: Active Directory Migration Services (ADMS). This tool runs in the Azure cloud. For entry-level information, see the following articles:Taste of Premier: Directory Consolidation with Windows Azure Active Directory Migration Services

  Microsoft Azure Active Directory Migration Service

Known issues and limitations

Installing PES on Windows Server 2012 and later

Old ADMT guides don’t mention the need to run the pedmig.msi file at an elevated command prompt. The latest ADMT guide mentions this requirement. The latest guide is dated February 26, 2018, and is available from the Microsoft Download Center.

Computer running ADMT must not use Credential Guard

The workstation that is driving the migration is not doing the migration by itself. The object movement is executed on the target domain controller (DC). It is delegating the user running the migration task when migrating a user from the source domain.

By default, domain controllers are set up for unconstrained delegation which is not allowed by Credential Guard anymore.

If you have ADMT installed on a Windows Server 2016-based member server or a later version Windows Server-based member server, you must disable Credential Guard to run migrations. Or, you can move the ADMT installation to the target domain DC, where you don’t have to delegate. Also, Credential Guard is not supported on target DCs.

DC cannot use unconstrained delegation

Because of existing attack vectors, Microsoft is restricting and blocking the use of unconstrained delegation. This also affects DCs. ADMT logs the following error:

The change of behavior for Windows Server 2008 R2 is contained in March 12, 2019—KB4489885 (Security-only update).

Microsoft PFE discussed this problem in a blog in 2017. Another blog outlines the release plan.

You can configure the target domain DCs for constrained delegation and allow the target domain DCs to delegate to the source DCs (resource-based constrained delegation). This is only possible when your DCs are Windows Server 2012 or later version of Windows Server.

On Windows Server 2008 R2 or earlier version of Windows Server, you can only move the ADMT installation to a target domain DC. Then you don’t have the need to delegate.

The ADMT computer must have TLS 1.0 enabled in order to connect to SQL Server

If TLS 1.0 is disabled, you receive a message on the ADMT computer that resembles the following:

Unable to check for failed actions. : DBManager.ImanaDB.1 : [DBNETLIB][ConnectionOpen (SECCreateCredentials()).]SSL Security error.

Additionally, if TLS 1.0 is disabled, the Admin tool does not load the snap-in when it opens. You receive a message that resembles the following:

Users running ADMT must not be member of an authentication silo

The user account that is used to drive the migration of SidHistory must not be in an authentication silo. When migrating SidHistory across forest, the target DC creates a network session to the source DC and authenticates by using NTLM. For the Admin user accounts that are in an authentication silo, in some OS, NTLM is not allowed for these user accounts by default, or is disabled by users.

Domains in the authentication flow of ADMT tasks must not restrict NTLM

For the same reason as avoiding authentication silos, the domains that are used for ADMT SidHistory migrations must not restrict the use of NTLM by one of the policies.

SQL Server versions

There is no version check for SQL Server versions that have ADMT. The last tests were run in 2013. Therefore, computers that are running SQL Server 2014 and later versions were not tested. Please perform your own testing of ADMT in a test environment before you use the tool for production migration.

Group Managed Service Accounts

As of February 27, 2018, the ADMT Guide describes how to handle Managed Service Accounts as implemented in Windows Server 2008 R2. There was no testing done for Group Managed Service Accounts (GMSA). Given the special handling of these accounts in several places, you should follow these guideliens:

• Do not try to migrate GMSA across forest boundaries.
• Use caution when you try to move GMSA within a forest.

Client operating systems

Although the latest toolset was released after Windows 8.0 entered the market, there was no testing for Windows 8.x and 10.x computer account migration and, in particular, no testing for full migration of user profiles.

We found several migrations problems that are related to the correct transition of user profiles. This is particularly true for modern application registrations and profile permissions.

Repeat migrations for password updates

Some customers are running repeat migrations of accounts to transfer a new password from a source account to a new account in another forest. ADMT is not designed for this approach. It tracks each migration job in its database. Over time, the ADMT database size increases. Eventually, it might experience the following:

• The database exceeds the licensed size of the database (for SQL Express Deployments).
• The database exceeds the available disk space on the computers that are running SQL Server.
• Migration jobs slow down. This is because the tool scans the migration history when you run a new job.

Note If you intend to use ADMT in this manner for several weeks or months and you have a frequent synchronization schedule, we recommend a solution based on a synchronization solution, such as Microsoft Identity Manager.

Best Practices for Performing Computer Migrations

Applies to: Active Directory Migration Tool 3.1 (ADMT 3.1) and ADMT 3.2

•             Perform regular backups of domain controllers in both the source and target domains throughout the course of the migrations. If you are migrating computers that contain file shares to perform security translation, we recommend that you also back up those computers throughout the migration.

•             Verify that workstations and member servers have restarted immediately after you join them to the target domain. The Active Directory Migration Tool (ADMT) automates the restart of workstations and member servers, but you use the Minutes before computers restart after wizard completion option in the Computer Migration Wizard to select the amount of time that passes before the computer is restarted. Computers that do not restart after migration are in an indeterminate state.

•             Communicate to end users that their computers must be connected to the network at the time that their computer is scheduled to be migrated.

Best Practices for Rolling Back a Migration

Applies to: Active Directory Migration Tool 3.1 (ADMT 3.1) and ADMT 3.2

•             Roll back user and group accounts that have been migrated between forests by enabling the accounts in the source domain (if they were disabled during the migration), verifying that the accounts have access to resources in the source domain, and then verifying that logon scripts and user profiles work as configured in the source domain.

•             Roll back resources that have been migrated between forests by changing the domain membership of servers and workstations and then restarting them. Log on to the resources in the source domain to ensure that the resources are accessible.

•             Roll back accounts and resources that have been migrated within a forest by migrating the objects back from the target domain to the source domain. Accounts and resources that are migrated within a forest are moved and not copied. Therefore, they do not continue to exist in the source domain.

Decrypt files that have been encrypted by means of Encrypting File System (EFS). Failure to decrypt encrypted files will result in loss of access to encrypted files after migration. Be sure to communicate to end users that they must decrypt any encrypted files or they will lose access to those files.

Exchange 2010 Installation Prerequisites:

Run Powershell elevated as administrator and run:

Import-Module ServerManager
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Desktop-Experience -Restart

LDIFDE (ServerManagerCmd –i RSAT-ADDS)

Start mode for NetTcpPortSharing service needs to be automatic

sc config NetTcpPortSharing start= auto

2007 Office System Converter: Microsoft Filter Pack

.NET Framework 3.5 (add feature through server manager)

IIS prerequisites

Internet Information Service (IIS).
– World Wide Web service (W3SVC)
– Additional sub roles of W3SVC:
IIS 7 Basic Authentication
IIS 7 Windows Authentication
IIS 7 Digest Authentication
IIS 7 .NET Extensibility
IIS 7 Dynamic Content Compression
IIS 7 Static Content Compression
IIS 7 .NET Extensibility
IIS 6 Metabase Compatibility
IIS 6 Management Console
Web Server (IIS) Tools
– HTTP Activation
– Windows Process Activation Service Process Model

Use a text editor to enable the MRSProxy service

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the “Text editor” entry in the Client Access Permissions topic.

On the remote Client Access server without SP2, open the following file with a text editor such as Notepad:

<Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config

Locate the following section in the Web.config file:

<!-- Mailbox Replication Proxy Service configuration -->
<MRSProxyConfiguration
 IsEnabled="false"
 MaxMRSConnections="100"
 DataImportTimeout="00:01:00" />

Change the value of IsEnabled to “true“.

Save and close the Web.config file.

If the server does have SP2, use the new cmdlet:

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSProxyMaxConnections 50

1.) in the IIS management console verify that there are entries for *.svc in the “Handler Mappings” property of the Default Site

if not you need to register WCF in IIS (%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -i)  and iisreset

Step 1 – Preparing Source and Target Domains

1. Create a two-way external forest trust between SourceDomain.int and TargetDomain.int
2. To migrate computers running Windows Server 2008, Windows Server 2003, Windows Vista (without Service Pack 1), Windows XP, and Microsoft Windows 2000 (using ADMT 3.1) to a target domain with domain controllers running Windows Server 2008 R2 or Windows Server 2008, first set the following registry key on the target domain controllers:

Registry path: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

Registry value: AllowNT4Crypto

Type: REG_DWORD

Data: 1

3. Enable auditing for success and failures for account management in your default domain controllers policy in the source and target domain (Computer configuration|Windows settings|Security settings|Local policies|Audit policy|Audit account management)
4. Create a GPO in the source domain (SourceDomain.int) in advance to enable the File and Printer Sharing exception on all computer objects (clients and servers)
5. With the same GPO we can add the TargetDomain.int domain admins to the local administrators on every client and server to help facilitate migrating the computer accounts
   1. Computer Configuration|Windows Settings|Security Settings|Restricted Groups
   2. Right click, Add Group, enter “TargetDomain\Domain Admins”
   3. On the next screen under ‘This group is a member of:’ click Add and type Administrators
   4. Make sure Security Filtering on this GPO is set for Authenticated Users
6. Create new GPO in target domain (TargetDomain.int) to set the default logon domain (when user and computer accounts are migrated they still point to old domain at logon)
   1. Server 08/Vista/Win7: Set the group policy in ‘Computer Configuration|Policies|Administrative Templates|System|Logon’ called “Assign a default domain for logon” to “TargetDomain.int”
   2. Server 2000/2003/WinXP: Create the following VBscript and assign it to the computer startup script group policy:

Dim sDomName
 Set oWshShell = CreateObject("WScript.Shell")
 sDomName = "TARGETDOMAIN"
 oWshShell.RegWrite "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName", sDomName

7. Install SQL Server 2005 Express SP3 x64 on target domain controller or member server on which you plan to install ADMT
8. Install ADMT 3.2 on target domain controller or member server (add source domain admin account into target local administrators group using:

 net localgroup administrators /add <source\admin> then login as source domain admin on target ADMT box to migrate computer accounts/translate security for local objects)

9. Create encryption key on server with ADMT installed for PES:

admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*}

1. Install PES 3.1 (Password Export Service) on source domain controller for password migration and provide encryption key generated from ADMT machine
2. If we ever need to grant users in the TargetDomain.int domain access to resources left in the SourceDomain.int domain, disable SID filtering manually for both sides of the trust:

netdom trust source.net /domain:target.net /quarantine:no /usero:admin /passwordo:xxx
netdom trust target.net /domain:source.net /quarantine:no /usero:admin /passwordo:xxx

2. Recreate the OU structure on the target domain to your liking

Step 2 – More preparation using Prepare-MoveRequest.ps1

Prepare-MoveRequest prepares the AD target object and synchronizes the required attributes for cross-forest moves to work. In order to run New-MoveRequest cmdlet to move a mailbox from an Exchange 2003/2007/2010 source forest to an Exchange 2010 target forest, the target forest must contain a valid MEU account with the set of AD attributes that this script creates (legacyExchangeDN, mail, mailnickname, msExchmailboxGuid, proxyAddresses, X500, targetAddress, userAccountControl, userprincipalName).

ADMT transfers Exchange attributes (e.g. homeMDB, homeMTA, showInAddressBook, msExch*) which make the target user look 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, exclude Exchange attributes from ADMT except proxyAddresses.

Export a list of all user email addresses in the California and Pittsburgh OU (or break it into region) using dsquery which we can pipe to Prepare-MoveRequest.

dsquery * "ou=Pittsburgh,ou=CompanyName,dc=SourceDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user)(mail=*))" -attr mail displayname -limit 0 > email_addresses.csv && dsquery * "ou=California,ou=CompanyName,dc=SourceDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user)(mail=*))" -attr mail displayname -limit 0 >> email_addresses.csv

Open the file in Excel and use the Text to Columns function. Remove everything except the email addresses. Change row 1 from “mail” to “Indentity” so it looks like this:

Identity

TestUser@SourceDomain.int

TestUser2@SourceDomain.int

TestUser3@SourceDomain.int

Copy that file to the target Exchange server and run the Prepare-MoveRequest script in EMS.

$RemoteCredentials = Get-Credential
 $LocalCredentials = Get-Credential
Import-Csv email_addresses.csv | .\Prepare-MoveRequest.ps1 -RemoteForestDomainController SourceDC.SourceDomain.int -RemoteForestCredential $RemoteCredentials -LocalForestDomainController TargetDC.TargetDomain.int -LocalForestCredential $LocalCredentials -TargetMailUserOU "OU=MEU,OU=TargetDomain,DC=TargetDomain,DC=int" -Verbose -UseLocalObject -OverWriteLocalObject

That should create all users contained in the list as MEU accounts in the TargetDomain.int domain under the MEU OU.

Step 3 – Active Directory Migration Tool

On the machine running ADMT in the target domain, migrate objects in this sequence:

1. Service Accounts (does not actually migrate, identifies the account)

2. Security Groups (Exclude Exch attributes)

3. Distribution Groups (Include Exch attributes)

4. Users (Exclude Exch attributes, except proxyAddresses)

5. Computer Accounts

After running ADMT it forces the user to change their passwords in the target domain. If we decide this is unnecessary we can dsmod the accounts in a single OU in one batch.

dsquery * "ou=MEU,ou=TargetDomain,dc=TargetDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user)(mail=*))" | dsmod user -mustchpwd no

Step 4 – Mailbox Migration

1)

dsquery * "ou=Pittsburgh,ou=CompanyName,dc=SourceDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user)(mail=*))" -attr mail displayname -limit 0 > PGH_email_addresses.csv

2)

$RemoteCredentials = Get-Credential
 $LocalCredentials = Get-Credential
Import-Csv PGH_email_addresses.csv | .\Prepare-MoveRequest.ps1 -RemoteForestDomainController SourceDC.SourceDomain.int -RemoteForestCredential $RemoteCredentials -LocalForestDomainController TargetDC.TargetDomain.int -LocalForestCredential $LocalCredentials -TargetMailUserOU "OU=Users,OU=Pittsburgh,OU=TargetDomain,DC=TargetDomain,DC=int" -Verbose -UseLocalObject -OverWriteLocalObject

3)

dsquery * "ou=MEU,ou=Users,ou=Pittsburgh,ou=TargetDomain,dc=TargetDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user))" | dsmod user -mustchpwd no

4)

dsquery * "ou=California,ou=CompanyName,dc=SourceDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user)(mail=*))" -attr mail displayname -limit 0 > CA_email_addresses.csv

5)

$RemoteCredentials = Get-Credential
$LocalCredentials = Get-Credential

Import-Csv CA_email_addresses.csv | .\Prepare-MoveRequest.ps1 -RemoteForestDomainController SourceDC.SourceDomain.int -RemoteForestCredential $RemoteCredentials -LocalForestDomainController TargetDC.TargetDomain.int -LocalForestCredential $LocalCredentials -TargetMailUserOU "OU=MEU,OU=Users,OU=California,OU=TargetDomain,DC=TargetDomain,DC=int" -Verbose

6)

dsquery * "ou=MEU,ou=Users,ou=California,ou=TargetDomain,dc=TargetDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user))" | dsmod user -mustchpwd no
dsquery * "ou=Users,ou=Clients,ou=TargetDomain,dc=TargetDomain,dc=int" -filter "(&(objectCategory=person)(objectClass=user))" -limit 0 | dsmod user -mustchpwd no -canchpwd no -pwdneverexpires yes

 

$RemoteCredentials = Get-Credential
New-MoveRequest -Identity 'test@TargetDomain.net' -TargetDatabase "Mailbox Database 1 (A-M)"  -RemoteHostName 'OldMailServer.SourceDomain.int' -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'TargetDomain.net'

 

$RemoteCredentials = Get-Credential
Import-Csv A-M.csv | New-MoveRequest -Identity 'test@TargetDomain.net' -TargetDatabase "Mailbox Database 1 (A-M)"  -RemoteHostName 'OldMailServer.SourceDomain.int' -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'TargetDomain.net'

 

$RemoteCredentials = Get-Credential
New-MoveRequest -Identity 'cleister@TargetDomain.net' -Remote -TargetDatabase "Mailbox Database 2 (N-Z)"  -RemoteHostName 'OldMailServer.SourceDomain.int' -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'TargetDomain.net'

 

Import-Csv N-Z.csv | New-MoveRequest -Remote -TargetDatabase "Mailbox Database 2 (N-Z)"  -RemoteHostName 'OldMailServer.SourceDomain.int' -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'TargetDomain.net'

 

Import-Csv A-M.csv | New-MoveRequest -Remote -TargetDatabase "Mailbox Database 1 (A-M)"  -RemoteHostName 'OldMailServer.SourceDomain.int' -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'TargetDomain.net'

 

Import-Csv N-Z-2.csv | New-MoveRequest -Remote -TargetDatabase "Mailbox Database 2 (N-Z)"  -RemoteHostName 'OldMailServer.SourceDomain.int' -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'TargetDomain.net'

 

New-MoveRequest -Identity JAccount@TargetDomain.net -Remote -TargetDatabase "System Mailbox Database"  -RemoteHostName 'OldMailServer.SourceDomain.int' -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'TargetDomain.net'