Domain Migration
Mike Brannigan
Enterprise Strategy and Senior Consultant
V1.1
Agenda
Domain Migration
Tips and Tricks
Not covering design (Domain, Forest, OU, Site..)
Domain Migration
Domain Migration
Benefits
– Start with a pristine environment – no baggage or “history”
– Perceived as less risky (not big bang)
– Used to consolidate domains
Disadvantages
– Far more effort than upgrade
– Have to manage parallel infrastructures for duration
– Exchange is more complex
Domain Migration
Typically used
– After forest root is created through in place upgrade
– To consolidate resource and account domains
– For merger, acquisition or to divest businesses
SIDHistory is the enabler
SIDHistory
What is it?
How does it work?
What are the downsides?
Domain Migration Tools
Tools
– ADMT v2
– ClonePrincipal
– ADC
– 3rd Party
ADMT v2
Free
Migrates user, group, computer, & password
Drive via wizard, cmd line or script
Perform trial migrations
Translate SIDs on workstations and servers
Can translate Roaming Profiles
Lots of guidance
Primary tool used by MCS
Not as automated as some 3rd party tools
ClonePrincipal
Free
Scriptable
Clones users and groups
Can copy SIDHistory
Can’t clone computer accounts (use Netdom)
Can’t migrate password
Active Directory Connector (ADC)
Free
Populates the AD from Exchange 5.5 directory
Uses Connection Agreements to flow changes (uni- or bidirectional)
– New user
– Delete user
– Change attribute
Requires Exchange knowledge
Needs schema extension
3rd Party
Quest Migration Suite for Active Directory
BindView bv-Admin for Windows Migration
NetIQ Domain Migration Administrator
Pointdev IDEAL Migration
Sys-Manage CopyRight
Domain Migration Tools
What tool to use?
– Start with ADMT v2 and look for reasons why not to use it. E.g.
– Huge number of domains
– 3rd party tools may have better consolidation features
– Want to migrate >1 domain at a time
– As above
– Want to perform more manipulation of user objects during
migration
– E.g. rename / change naming convention
ADMT v2 Overview
Analyzes the migration impact both before and after the
actual migration process
Tests migration scenarios before you perform the migration
Supports migration within a forest and between forests
Provides wizards to support the most common migration
tasks
ADMT key components
ADMT “Server”
– Usually DC in target domain
– Stores everything in Protar.mdb
– Migrated users and computers
– SIDHistory
– Used for security translation
– Protar.mdb not editable
Password Export Server
– BDC in NT 4.0 domain
– Uses encrypted channel to send password hashes to ADMT
Server
ADMT key components
Agent
– Installed automatically on computers to be migrated by ADMT
– Performs security translation, profile translation and changes domain
membership
Can use a SID mapping file for more complex situations
ADMT v2 Migration Scenarios
Migrating user, group, and computer accounts between
domains
Performing security translation on local groups, user
profiles, and file and print resources
Populating the SIDHistory attribute with migrated security
principals
Translating security on computers
Resolving the related file, directory, and share security
issues
ADMT v2 Security
Delegated users can migrate computers
Launching agents requires local admin rights (e.g. Profile
translation)
Running ADMT requires local admin rights
SID History migration has special requirements
– Source domain:
– User must have administrator rights
– Target domain:
– Windows Server 2003: Domain administrator rights OR “Migrate
SID History” extended right on domain
ADMT Security Requirements
Migration
Object
Credentials Necessary
In Source Domain
Credentials Necessary in Target Domain
User/Group
with SID history
Local administrator or domain
administrator
Delegated permission on the user OU or the group
OU, extended permission to migrate SID history,
and local administrator on the computer on which
ADMT is installed.
Computer
Domain administrator or
administrator in the source
domain and on each
computer
Delegated permission on the computer OU and
local administrator on the computer on which
ADMT is installed.
Profile
Local administrator or domain
administrator
Delegated permission on the user OU and local
administrator on the computer on which ADMT is
installed.
Domain Migration Roadmap using ADMT
Migrate Account Domains before Resource domains
– Preparation
– Build new infrastructure
– Setup Trusts
– Setup ADMT
– Test
– Migrate
– Groups
– Users
– Service Accounts
– Resources
Migration Preparation - Build New Infrastructure
Create target infrastructure
– Forest & Domain structure
– OU structure
– GPOs, incl login scripts
– Domain must be in Windows 2000 Native mode for SIDHistory
– Ensure name resolution works between old and new
infrastructures
Preparation – Trusts
Minimum: source domain trusts target domain
If migrating some resources before users, you need 2-way
trust
Recommended: 2-way trust
– Simplifies troubleshooting
– Gives you more migration options
Preparation – Setup ADMT
Install ADMT from the Win2K3 CD using Migration account
I386\ADMT\admigration.msi
Recommendation: installed on a DC in target domain
– Runs faster (less network latency)
– Always targets the local DC
Ensure the Pre-Windows 2000 Compatible Access group
contains
– Everyone
– Anonymous Logon
– Note: if this is not the case, you need to restart the Server service
on all DCs in the target domain after replication
Preparation – Setup ADMT
Create an Encryption Key
– On target DC
ADMT KEY <source domain NetBIOS name> <path to save
key> <password>
Password Export Server (PES)
– Requires 128-bit encryption (NT 4.0 SP6a)
– Install i386\ADMT\PWDMIG\pwdmig.exe on the nominated BDC
in source domain
– Will ask for path to encryption key
– Don’t locate the key on a share
Preparation – ADMT Setup
Enable auditing of Account Management in the Target
domain
Enable User and Group Management in the source
domain
Create the following registry entry on the PES
HKLM\System\CurrentControlSet\Control\LSA
AllowPasswordExport : DWORD : 0x1
Restart the PES
Create a domain local group called <domain>$$$ in
source
– This is used by ADMT to cause auditing to occur (drops the
migrated account into this group, then removes it)
Create the following registry entry on the PDC
HKLM\System\CurrentControlSet\Control\LSA
TcpipCientSupport : DWORD : 0x1
– ADMT will configure these automatically on 1st run
Test
Create a test user in the source domain
– Make this user representative (homedir, group membership,
roaming profile etc)
Create a test workstation in the source domain for each
OS
– Make this representative (e.g. apps & local/roaming profiles)
Test
Refine your migration plan during tests
– Which group of users will be migrated 1st?
– Will you migrate user profiles?
– Will their workstation be migrated? If so, at the same time?
Migration – Global Groups
Migrate Global Groups before users
Group needs to be there before users can be made
members
Groups are what give the migrated user access to shared
data in old domain (via SIDHistory)
Group membership may (likely) change during the
migration project
– ADMT allows re-migration to fix this
Lesson: migration of GG consumes lots of network &
resources on DC executing ADMT
ADMT does not migrate Local Groups
– Move members to global groups
– Permission resources with computer local groups
Migration – Users
Think about creating Migration Groups to make batch
migrations easier
Change drive mappings to Dfs if possible
– You’re then free to migrate shares at your leisure
If not migrating workstations, update the DefaultDomain on
NT/Win2K/XP
HKLM\Software\Microsoft\Windows NT\
CurrentVersion\Winlogon
Migration – Users
Any changes made to users in target domain need to be
made manually in source domain to maintain rollback
ability
– Lesson 1: Avoid changes to both source and target, make them in
1 domain only
– Lesson 2: Set user expectations up front
– Lesson 3: Communicate with all users about their domain name
(not just migrated users)
– Lesson 4: Provide at least some minimal training
Get user representation in the planning
Run a pilot to get feedback and refine communications
plan
Migration – Users
If you don’t migrate profiles, you need to think about
– Printer access/mappings
– Persistent drive mappings
– Desktop items
– Application settings which aren’t part of Default User
– Start Menu
Migration – Computers
Wizard deploys an Agent on computers to be migrated
(hence need for Admin)
Agent changes Domain Membership and initiates a restart
Old SIDs remain in place, which is how SIDHistory works
– Lesson 1: Ideally migrate out of working hours or set the restart
time to a low number
Migration – Service Accounts
ADMT can identify all servers/workstations in the source
domain which run services not using Local System
Windows Server 2003 Deployment Kit states you should
migrate these first
– I migrate them
– Separately
– Often after users
– Not using ADMT because the service is generally deployed on new
hardware
Migration – User Profiles
Local and Roaming can be translated (“owning” user
changed)
– Windows NT 4.0, Win 2000 & Windows XP
Primary SID is used on migrated profile, not SIDHistory
– Logging on with the old account will not pick up the translated
profile
New SID can be added rather than replacing old SID
– Lets the old user access the profile (e.g. to copy favourites), but
won’t be used for the users active profile
Migration – User Profiles
ADMT does not move the Roaming Profile – it will remain
in the original share
Lessons
– If you translate profiles and then roll back, the target domain
roaming profile won’t be rolled back
– If local profiles: next time user logs on with old account, a new
profile is created
– If roaming profiles: next time user logs on, profile error will occur
(access is denied) and user will get new local profile
Migration – Parallel Environments
Perform administration in the source domain only during
migration
– E.g. group membership & new starters
– Schedule an ADMT re-migration nightly (for example) and use
“replace conflicting accounts”
– Maintain a list of migrated users in a CSV file, pointing ADMT at
this
– Freeze passwords for duration – “replace conflicting accounts”
also migrates password 
Rollback Plan
Windows NT 4.0 account objects
– Enable the user accounts in the source domain (if you disabled
the accounts during the migration process)
– Get the users to log off from the Active Directory target domain
and log on to the source domain
Rollback Plan
Windows NT 4.0 resource objects
– Change the domain membership for the resource object to the
source domain
– Restart the server or workstation
– Log on to the source domain and verify that you can access the
resource
– Don’t forget to change service accounts!
Post Migration
When everything is migrated
– Remove all bar PDC and 1 BDC from old domain
– Re-ACL migrated servers
– This is called Translating Security – ADMT
– Replaces SIDs from old domain with Group/User SIDs from new
domain
– Power them off for a period to ensure everything is OK, then
– Tear down trusts with existing domain
Post Migration
Disable the migration account in new Domain
Delete Migration Groups
Remove SIDHistory from each user / group?
– Ideally, as this will have a minor performance improvement, and
reduces chance of token-bloat
– Reality, never seen a customer do it, and have not knowledge of
problems
Tips and Tricks
Cleanup the source domain before migration
– Unused groups
– Group Membership (esp. Domain Admin)
– Retired users
– Old computer accounts
Migrate shares to Dfs if possible
– Use deep mappings if clients are XP
Different password policies between source and destination won’t stop
password migration
Tips and Tricks
Really long path/filenames
– >260 characters and ADMT will fail
Clone an OU?
– Not via the Wizard
– Command line or script, e.g.
ADMT USER /SD:<source_domain> /SO:<source_ou> /TD:<target_domain>
/TO:<target_ou> /D:RECURSE+MAINTAIN
Recurse = clone sub OUs too
Maintain = maintain OU structure in destination
Tips and Tricks
Update Previously Migrated setting
– Replaces destination account – any changes since original
migration are lost
Terminal Server profiles are not migrated
– Do it manually, or abandon
ADMT cannot migrate EFS files
– Decrypt
Don’t open / edit Protar.mdb, you’ll break it!
Make sure name resolution works – this is the root of lots
of potential issues
3rd party tools
Resources
Whitepaper: Why Upgrade From Windows NT 4.0 to
Windows Server 2003
– http://www.microsoft.com/windowsserver2003/evaluation/whyupgr
ade/nt4/nt4townet.mspx
Microsoft Solution for Management - Solution Accelerator
for Windows Server 2003 Deployment
– http://www.microsoft.com/downloads/details.aspx?FamilyID=f4d0
7ff8-ae7d-4717-9f8b-f8ce16d580dd&displaylang=en
mikebran@microsoft.com
©2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.