V1.1 Mike Brannigan Enterprise Strategy and Senior Consultant Domain Migration

Agenda Domain Migration Tips and Tricks Not covering design (Domain, Forest, OU, Site..)

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 – 3 rd 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 3 rd party tools

ClonePrincipal Free Scriptable Clones users and groups Can copy SIDHistory Can’t clone computer accounts (use Netdom) Can’t migrate password

Free Populates the AD from Exchange 5.5 directory Uses Connection Agreements to flow changes (uni- or bi- directional) – New user – Delete user – Change attribute Requires Exchange knowledge Needs schema extension Active Directory Connector (ADC)

3 rd 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 – 3 rd 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

Migrate Account Domains before Resource domains – Preparation – Build new infrastructure – Setup Trusts – Setup ADMT – Test – Migrate – Groups – Users – Service Accounts – Resources Domain Migration Roadmap using ADMT

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 Migration Preparation - Build New Infrastructure

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 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 $$$ 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 1 st ? – 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

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  Migration – Parallel Environments

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

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! Rollback Plan

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: /SO: /TD: /TO: /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 – ade/nt4/nt4townet.mspx Microsoft Solution for Management - Solution Accelerator for Windows Server 2003 Deployment – 7ff8-ae7d f8b-f8ce16d580dd&displaylang=en

©2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.