Domain Migration Mike Brannigan Enterprise Strategy and Senior

Domain Migration Mike Brannigan Enterprise Strategy and Senior Consultant V 1. 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 – ADMT v 2 – Clone. Principal – ADC – 3 rd Party

ADMT v 2 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

Clone. Principal 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

3 rd Party Quest Migration Suite for Active Directory Bind. View bv-Admin for Windows Migration Net. IQ Domain Migration Administrator Pointdev IDEAL Migration Sys-Manage Copy. Right

Domain Migration Tools What tool to use? – Start with ADMT v 2 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 v 2 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 v 2 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 v 2 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

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 Win 2 K 3 CD using Migration account I 386ADMTadmigration. 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 Net. BIOS name> <path to save key> <password> Password Export Server (PES) – Requires 128 -bit encryption (NT 4. 0 SP 6 a) – Install i 386ADMTPWDMIGpwdmig. 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 HKLMSystemCurrent. Control. SetControlLSA Allow. Password. Export : DWORD : 0 x 1 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 HKLMSystemCurrent. Control. SetControlLSA Tcpip. Cient. Support : DWORD : 0 x 1 – ADMT will configure these automatically on 1 st 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 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 Default. Domain on NT/Win 2 K/XP HKLMSoftwareMicrosoftWindows NT Current. VersionWinlogon

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

Resources Whitepaper: Why Upgrade From Windows NT 4. 0 to Windows Server 2003 – http: //www. microsoft. com/windowsserver 2003/evaluation/whyupgr ade/nt 4 townet. mspx Microsoft Solution for Management - Solution Accelerator for Windows Server 2003 Deployment – http: //www. microsoft. com/downloads/details. aspx? Family. ID=f 4 d 0 7 ff 8 -ae 7 d-4717 -9 f 8 b-f 8 ce 16 d 580 dd&displaylang=en

mikebran@microsoft. com