Domain Migration Blueprint

Last updated: January 30, 2023
Audience: IT Staff / Technical

This document covers a do-it-yourself approach to migrating your existing Windows domain into a delegated OU. This approach uses free tools, which might be summarized as: leverage dual ACLs, a bulk group upload, manual computer migrations on your time frame, and removal of the dual ACLs once all migrations are complete.

Each migration to a delegated OU will be different–your environment and existing Windows domain is different than everyone else’s. However, there are many things in common. This document tries to capture those commonalities and give you a blueprint to follow. Like any building project, you’ll need to adjust what you actually do to fit the materials and conditions you find instead of blindly following this blueprint.

With the do-it-yourself approach, you are in control of the entire process and costs are only your staff time.

The Steps – Do-It-Yourself Migration

  1. Rename local domain users to match UW NetID users
  2. Rename local domain groups to match Groups Service namespace
  3. Upload groups to UW Groups Service
  4. ReACL all local domain resources to add NETID equivalent users/groups (so both local domain and NETID domain are included)
  5. Change all local group policies to act on computer objects with loopback instead of on users
  6. Remove logon scripts, roaming profiles, Terminal service profiles, and other user attributes where possible using the NETID User Workaround options
  7. Document what user attributes are still needed on user objects and investigate whether you can set them in NETID domain
  8. Import NETID users and groups into SQL environments and apply same roles
  9. Replicate OU structure in your delegated OU. Ask UW-IT for any special directory permissions
  10. Export your GPO-based IPSec rules and either redeploy them as local IPSec rules or ask UW-IT to implement them as GPO-based for you
  11. Export/import your group policy objects to NETID domain and link as appropriate
  12. Reconfigure new computer deployment processes to target the NETID domain
  13. Ensure you’ve got the cross-forest GPO setting in place in your local domain
  14. Update all IIS default domain settings if using your local domain for authentication
  15. Change ownership of profiles from local domain user to NETID user
  16. Change default logon domain on all computers to NETID domain
  17. Disable local domain users
  18. Adjust ‘change domain suffix on domain join’ setting as needed (PS script available!)
  19. Migrate workstations on whatever time scale that works. Disable local domain computer account when moved to keep track
  20. Migrate servers on whatever time scale that works. Start with least complex servers
  21. Until all computers are migrated, leave a single domain controller behind with a logon script to automatically migrate missed computers like laptops
  22. Decommission your old domain and ask your manager for donuts

Changes to the Above Blueprint

You should feel free to add, remove, and re-order the above steps according to your needs.

For example, steps 15 and 16 can be omitted, if desired. The user will be forced to login with a NETID user account if their workstation is moved to the NETID domain, so step 18 accomplishes the work of 15. If you do omit step 15, then step 16 should probably happen after step 18 is complete.

If you are considering some changes, here are a couple key things to keep in mind:

  • What user account are my users logging in with at this point in the plan? Can they get access to all my resources with that user account?
  • How can I reduce interruptions to my users?

To make it easy to see where the user affecting steps are, they are highlighted in red.

Details

Step 1:

Several tools to identify which of your accounts need a UW NetID are available and discussed here.

A good place to find out about UW NetIDs is http://www.washington.edu/itconnect/accounts/.

UW NetIDs can be created several different ways:

Step 2:

This step is not required, but we recommend that you rename your groups prior to import (and migration) to reduce the number of moving parts. You can find out more about Groups Service namespace and how to choose the right names at:

Do note that AD only supports group names to 63 characters in length, so groups with longer names will not make it to UWWI.

Step 3:

The PowerShell scripts linked to the Groups Service pages can be used to automate this.

Step 4:

Subinacl.exe is your friend. Or try using something like SetACL. There’s a blog post about one problem we’ve seen with subinacl.

You’ll probably want to add ACEs and NOT replace, and you’ll want to test things out.

An example subinacl command line might be:

Subinacls.exe /subdirectories c:\temp\*.* /migratetodomain=ischool=netid

Steps 5 & 6:

The NETID User Workaround page is very relevant.

Step 7:

Details on which user attributes you can set and how are still outstanding.

Step 11:

Group policy can be migrated with the GPMC tool. There are backup, export and import functions that are documented in the help files. Additionally, you can export & import ipsec filters underlying group policy. You may need to create a mapping file to translate the specific users and groups referenced in group policy. The GPMC help and documentation is pretty explanatory.

See the Migrating GPOs Across Domains with GPMC whitepaper for more details.

Step 13:

Administrative Templates/System/Group Policy/Allow Cross-Forest User Policy and Roaming User Profiles=Enabled

Allows User based policy processing, Roaming User Profiles and User Object logon scripts for cross forest interactive logons.

This setting affects all user accounts interactively logging on to a computer in a different forest when a Cross Forest or 2-Way Forest trust exists.

When this setting is Not Configured:
– No user based policy settings are applied from the user’s forest
– User will not receive their roaming profiles, they will receive a local profile on the computer from the local forest. A warning message will be shown to the user, and an Event Log message (1529) will be posted.
– Loopback Group Policy processing will be applied, using the Group Policy Objects scoped to the machine.
– An Event Log message (1109) will be posted stating that Loopback was invoked in replace mode.

When this setting is Enabled, the behavior is exactly the same as with Windows 2000 Server Family, User policy is applied and a roaming user profile is allowed from the trusted forest.

When this setting is Disabled, the behavior is the same as Not Configured.

Step 15:

There are many ways to accomplish this. We recommend a web search using the phrase “migrate domain user profile” to find an approach that works for you.

Step 16:

You can include the following command in a script:

reg add “\\mycomputer\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v DefaultDomainName /d NETID /f

Step 18:

Ensure that the ‘Change primary DNS suffix when domain membership changes’ checkbox is set to the correct value (no reboot necessary as prompted). We’ve found we needed to manually change the default setting on all servers at the very least. The migrationHelperScripts includes doNotChangeDnsSuffixWhenDomainMembershipChanges.ps1, a PowerShell script that’ll do this for you.