Migrating Child Domains Within A Forrest

1. Migrating Child Domains Within A Forrest

2. Topics Why Migrate? Overview Preparation Migrating Group Policies Preparation Part 2 Migrating Groups Migrating Users Migrating Computers Migrating Servers Eliminating the Domain Potential Problems

3. Why Migrate? • Active Directory can “easily” handle over a million objects in a single domain • Child domains are not security boundaries • Just about everything you can do in a domain, you can do in an OU (CHFA only lost control of the password policy, which mostly matched the one used in AD-ITS) • Mac OS 10.5 (Leopard) disapproves of child domains • Eliminate excessive servers and their total cost • Remove AD roles from servers performing other roles • Really no reason not to

4. Overview That part of the presentation your supposed to have, but don’t really need.

5. Overview • Prepare • Notify users • Migrate Groups • Migrate Users • Migrate Computers • Migrate Servers • Fix Problems • Eliminate the Old Domain

6. Overview • The ADMT tool is quite easy to use, like the Add Printer Wizard without the drivers and with that whole can-screw-everything-up part. • Only way to undo an ADMT object migration when working within a single forest is to use the tool again, reversing the source and destination domains. • As long as groups are set to universal, half your users and computers could be in one domain and the other half in another with virtually no problems. • The ADMT tool has a comprehensive command-line interface in addition to its GUI interface. I will focus on the GUI interface.

7. Overview • CHFA completed the major migration tasks over winter break • Downtime to the typical CHFA user was about 2 hours for user migration, 2-4 hours for their computer migration (all GP software uninstalls and reinstalls), and 3 hours for server migration. • 2 machines (out of 312) failed severely enough to require reformatting, but both had experienced problems beforehand. • About 8 machines required manually binding to the AD-ITS domain. • A 3.2% failure rate on computers? • No users or groups failed to migrate successfully

8. Preparation AKA The most important part of the whole process.

9. Preparation • Create your new OU structure in the AD-ITS Domain (ask ITS-NS for initial setup) • Good opportunity to reorganize and clean up • Create new universal groups to represent the membership of various domain specific groups (like Domain Admins, or Domain Users). Add the users to these new groups before attempting any migration.

10. Preparation • Delete unneeded accounts from the old domain to save time. • Edit the “group scope” of all groups to be universal. This allows a user or group to be in either domain without difficulty.* *Technically the ADMT can do this for you, but why leave that to chance?

11. Preparation – ADMT • Install the Active Directory Migration Tool V3 on the server of your choice (probably a domain controller). • http://www.microsoft.com/downloads/details.aspx?FamilyID=6f86937b-533a-466d-a8e8-aff85ad3d212&displaylang=en • Download and read the ADMT V3 Migration Guide, especially pages after 224 • http://www.microsoft.com/downloads/details.aspx?familyid=D99EF770-3BBB-4B9E-A8BC-01E9F7EF7342&displaylang=en • Also available from: \\mercury.chfa.uni.edu\Public\Interdisciplinary\Domain Migration • The ADMT guide is very detailed and covers most of the issues I will discuss in greater detail.

12. Migrating Group Policies The part the ADMT guide doesn’t talk about.

13. Group Policy • Again, this is the time to make major changes if you feel the need. • Simple “backup” and “import” process. • Can configure a table to act as an automatic “find and replace” • Move policies out of the default domain policy

14. Group Policy – Step by Step • Have both the old domain and the AD-ITS domain open in two windows of Group Policy Management. • Create new policy in the AD-ITS domain (remember to name it beginning with your division name.) • Right-click old policy, choose “Backup.” Choose a location to backup to, and backup the policy. • Right-click new policy, choose “Import Settings.” • Choose the folder you backed up into, select the correct policy and work through the wizard.

15. Group Policy – Step by Step • If desired, policies can be altered by a migration table, which is a fancy find and replace list. • The table can be auto-populated from the GPO, allowing you to choose which items you want to change.

16. Group Policy – Screenshots

17. Group Policy – Screenshots

18. Group Policy – Screenshots

19. Group Policy – Screenshots

20. Group Policy – Screenshots

21. Group Policy – Screenshots

22. Group Policy – Screenshots

23. Preperation Part 2 Getting ready to create success.

24. Preparation – Service Account Migration Wizard • Launch the ADMT tool and run the “Service Account Migration Wizard” on your servers. • “The Service Account Migration Wizard checks every service on a computer to identify services that run in the context of a user account.” • “When the accounts that the Service Account Migration Wizard identifies in the ADMT database as running in the context of a user account are migrated to the target domain, ADMT grants each account the right to log on as a service.”

25. Preparation – Service Account Migration Wizard • “The wizard connects to the selected computers, and then sends an agent to check every service on the remote computers. The Service Account Information page lists the services that are running in the context of a user account and the name of that user account. ADMT notes in its database that these user accounts need to be migrated as service accounts.” • For instructions on running the Service Account Migration Wizard, see page 247 of the ADMT guide.

26. Preparation – Reporting Wizard • The ADMT tool comes with a reporting wizard to gather information • It can tell you about: • Already migrated user accounts • Already migrated computer accounts • Expired accounts • Account references • Account name conflicts • The account name conflict report should be run before attempting migrationso duplicate user or computer names can be resolved

27. Preparation – Develop Strategy • Determine if you’re going all at once or going to go department by department • If migrating one department at a time, create lists that can be imported into the ADMT tool • Come up with a plan to notify users, no matter how much you do, somebody will miss the message • Make sure computers remain on, temporarily disable computer-power saving features.

28. Preparation – Develop Strategy • Make sure your admin account in each domain has adequate rights to resources in the other domain • Be sure to move a few test users over well in advance to assure your procedure will work

29. Ideas to Mitigate Computer Failures • Make sure the local Admin account is enabled and you know the password • If the machine is not nearby, make sure the local Admin account has RD rights to the machine or have a VNC-type software package in place. (For the machines that need to be bound manually) • Have a plan to recover data from hard drives of machines that don’t survive, the user’s data will most-likely be fine (BartPE, USB->IDE/SATA adapter)

31. Migrating Groups For Pete’s sake, don’t choose the “copy group members” option!

32. Migrating Groups • See page 253 of the ADMT guide • Launch the ADMT tool • Start the Group Account Migration Wizard • Choose the source and destination domains • Add the groups you wish to migrate to the list or choose a pre-populated list of groups if you have created one • Choose the OU in the target domain where you want the groups to appear

33. Migrating Groups • The “Migrate Group SIDs to target domain” and “Fix Group Membership” should be the only options selected besides “Do not migrate source object if a conflict is detected in the target domain.” • DO NOT CHOOSE THE “COPY GROUP MEMBERS” OPTION! It pulls every user that’s in any group or nested group over along with the group. • View the log for problems.

34. Migrating Groups • Users in the old domain will be able to use the migrated groups just as they were in the old domain, as the group’s SID is still recognized. • If you were to migrate a global group (remember, you changed them all to universal already), it will convert it to a universal group until all group members are moved to the target domain (see page 257 of the ADMT guide). • Standard groups, like domain users, domain computers, are handled automatically when you migrate those objects

35. Migrating Users Forced relocation just doesn’t have the same ring to it.

36. Migrating Users • Probably best to move an OU at a time • Command-line ADMT can move entire OUs and sub-OUs, see page 267 of the ADMT guide. • The following will not migrate: • Web page credentials (for example, passwords) • File share credentials • Private keys associated with EFS, S/MIME, and other certificates • Program data that is protected by using the CryptProtectData() function • You could disable the accounts to prevent problems during the migration and enable them after they move (they remain disabled after migrating)

37. Migrating Users • When an account is migrated using ADMT, it receives a new SID and its SIDHistoryattribute is populated with the user's old SID. • Same basic procedure as migrating groups • Launch the ADMT tool • Start the User Account Migration Wizard • Choose the source and destination domains • Add the users you wish to migrate to the list or choose a pre-populated list of users if you have created one • Choose the OU in the target domain where you want the users to appear

38. Migrating Users • Select the “Translate roaming profiles” check box. • Select the “Update user rights” check box. • Clear the “Migrate associated user groups” check box.* • Do not migrate source object if a conflict is detected in the target domain. • View the log for problems. • Immediately follow-up with a run of the Security Translation Wizard on your servers • All users will be flagged to change their passwords *While equally evil to its sibling “Copy Group Members” option, your groups should already be migrated, right?

39. Security Translation Wizard • Very similar to the computer migration wizard (which I discuss next), except this one doesn’t migrate anything, but rather fixes security permissions for objects that have been migrated. • Longest part of the user migration, as the group and user moves are very quick, this scans the servers for references to the old accounts and updates them.

40. ADModify.net • Bulk AD object modification tool • Used to undo the forced password change • Users get a freebie on the password age and get a fresh start on their 3 months • ADModify.net tool keeps an undo file for everything it does • Might prove useful for other AD needs • http://www.codeplex.com/admodify • MSI package in • \\mercury.chfa.uni.edu\Public\Interdisciplinary\Domain Migration

41. Migrating Computers This is the part that might break things.

42. Migrating Computers • Again, similar process to migrating groups and users. • Migrated computers are disabled in source domain instead of being removed like users and groups • Launch the ADMT tool • Start the Computer Migration Wizard • Choose the source and destination domains • Add the computers you wish to migrate to the list or choose a pre-populated list of computers if you have created one • Choose the OU in the target domain where you want the users to appear

43. Migrating Computers • Choose all available translation options • Choose replace mode • Choose either 0 or 5 minutes for the computers to wait before restarting • Don’t exclude any properties • Do not migrate an object if there is a conflict • When prompted, run the pre-check and agent operation in the ADMT Agent dialog box • The ADMT Agent fixes references to the source domain on the computer • Check the logs for problems