IT Connect

Information technology tools and resources at the UW

UW-IT Assisted Migration

If you haven’t already, please review the Domain Migration Blueprint document.

This document covers the do-it-mostly-yourself approach, where UW-IT partially assists you. In that approach, UW-IT maps your users and groups in our ADMT SQL database (ADMT is a free domain migration tool from MS), and then you can use your ADMT console (pointed at our DB) and it’s nifty migration agents to reACL and move computers at your convenience.

This approach comes with the option to set sidHistory on NETID users, and where needed, we can assist further for time based cost recovery. The benefit here is that ADMT reduces the amount of manual work, and if you choose to use sidHistory, resources that accidentally get missed by the reACL process still work.

UW-IT has used this approach with the Nebula domain migration (not into the NETID domain), a similar approach for Exchange mailbox migrations, the Libraries migrate into delegated OUs using this approach, and many others.

Getting Started

Contact UW-IT via help@uw.edu asking for Windows domain migration assistance. We’ll talk you through the big picture, and answer any questions you might have.

Outline of the migration process:

  1. Prepare for User and Group Mapping
  2. Install ADMT
  3. Prepare for Computer Migration
  4. Migrate Computers

Preparing for User and Group Mapping

  1. Use the Verify Domain Users are UW NetIDs tools to identify which domain users don’t line up with NETID users.
    1. Rename any domain users to line up with the NETID username (i.e. UW NetID).
    2. Get UW NetIDs for any domain users which don’t have a corresponding NETID user.
    3. Use

      verifyUsernamesAreUwnetids.exe validonly

      to create a simple vetted list of users to migrate to the NETID domain.

    4. Give your simple vetted list of users to UW-IT.
  2. Use PowerShell scripts import domain groups into the Groups Service (and therefore into the NETID domain).
    1. Review the Groups Service namespace, and identify where your groups will go. For background info, see
      • https://wiki.cac.washington.edu/display/groups/Groups+Service+Basics#GroupsServiceBasics-UWGroupIDs
      • https://wiki.cac.washington.edu/display/groups/UW+Group+Naming+Plan
      • https://wiki.cac.washington.edu/display/groups/Home+Groups
    2. Rename your existing domain groups so they match your desired Groups Service names.
    3. Use the PowerShell scripts to import your renamed domain groups. If you have nested groups, make sure you do the import in the right order, or run it a couple times to avoid gotchas tied to nested groups.
    4. Give UW-IT a list of your groups. This command will produce that list:

      net group /domain > groups.txt

  3. Add

    NETID\u_windowsinfrastructure_admtAccountMigrators

    to YOURDOMAIN\Administrators. The membership of NETID\u_windowsinfrastructure_admtAccountMigrators is NETID\Domain Administrators and a single application UW NetID used when automated user/group migrations are needed.

  4. Open firewalls on your DCs to all traffic from

    tatooine.cac.washington.edu.

  5. If your trust to the NETID domain has selective authentication enabled, then you must grant  NETID\u_windowsinfrastructure_admtAccountMigrators the ‘allowed to authenticate’ user right on all your domain controllers. Alternatively, you can also remove selective authentication on your trust to the NETID domain.
  6. Decide whether you want to use sidHistory or not. If you do, sidHistory will keep users from seeing any resources that are accidentally missed in the reACLing process. However, those NETID users will likely indefinitely have that sidHistory. Either way, let UW-IT know what you decide.

Installing ADMT

You’ll need to download ADMT and install it on one or more of your computers. Choose ADMT 3.2. Early versions of ADMT 3.2 could only be installed on Windows Server 2008 R2, but those restrictions have since been removed. See the links section below.

When you install ADMT, make sure to choose the remote SQL server option. Specify

ucssqlc6db1.cac.washington.edu\sql01

as the location for the database. The installer will figure out on its own that the database name is ADMT. If you have an existing ADMT installation, you can change the SQL database using this command:

admt config setdatabase /s:ucssqlc6db1.cac.washington.edu\sql01

.

Preparing to Migrate Computers

All members of NETID\u_windowsinfrastructure_yourOUNameHere_ouadmins have been granted access to access the ADMT database noted above. Please use the Admin UW NetID from the NETID domain to perform any computer migrations needed. This means you’ll need to make sure NETID\sadm_yourUwNetID has admin perms on any computers in your domain that you wish to migrate with ADMT. Only your Admin UW NetIDs needs to have admin permissions added–neither UW-IT nor any other account needs permissions added. If adding your NETID admin accounts on your computers presents a problem, ask UW-IT for help.

You can perform multiple batches of computer migrations at the same time via multiple consoles, using different user accounts, if needed. So the same account doesn’t necessarily need to have admin permissions on all your computers, and you can split up the work of migrating computers where needed.

Before you start migrating computers, you’ll want to create your OU structure in your delegated OU. And then you’ll want to recreate your Group Policy objects in the NETID domain. GPMC can be used to export and import group policy objects, so you can lift existing GPOs from your domain and reimport them in the NETID domain. However, any specific references to users or groups in your GPOs will need to be manually changed, so be careful. Microsoft has a whitepaper on Migrating GPOs Across Domains with GPMC.

The way the ADMT computer migration process works is:

  1. You tell your ADMT console which computers to migrate.
  2. Your ADMT console contacts those computers and using the permissions of the user running the console, installs a Windows service on that computer.
  3. The installed Windows service reACLs the resources on that computer, using the user and group mappings in the ADMT database.
  4. A computer account is created in the NETID domain (in the OU you’ve specified).
  5. The Windows service joins the computer to that NETID computer account and reboots the computer after the warning period you’ve specified.
  6. On reboot, the computer detects & applies new group policy settings and then the Windows service removes itself.

Here are some known gotchas in this process:

  • Firewalls between your ADMT console and your computers
  • Firewalls between your computers and the NETID domain controllers
  • File and Printer Sharing for MS Networks is disabled
  • Server service is not started
  • Netbios over TCP/IP is disabled
  • The computer running the ADMT console can’t resolve the computer name to an IP address
    • If the dnsHostName value on the existing computer account is incorrect, then ADMT will always fail to find the computer, because it prefers that value over NetBios name resolution. You can either fix that value or delete that value and rely on NetBios name resolution. migrationHelperScripts has a vbs script to delete the dnsHostname value.
  • The account running the console doesn’t have admin permissions on the computer
  • The account running the console doesn’t have permissions to the DB or to create a computer account in NETID.
  • You’ve left the ‘Change primary DNS suffix when domain membership changes’ checkbox enabled. No computers can have a DNS suffix of netid.washington.edu. migrationHelperScripts has a PowerShell script to fix this setting.

A couple tips for managing computer migration:

  • If you are migrating a batch of computers at the same time, first ping that batch of computers. That’ll weed out any computers which aren’t available, which slows down the entire process within the ADMT console. migrationHelperScripts has a vbs script to do that.
  • After you’ve got a batch of computers that are online, remotely run the dnsSuffix powershell script in migrationHelperScripts against them. That’ll ensure their DNS suffix is still good post-migration, while also verifying that you have admin privs on those boxes before you make ADMT try your privileges.
  • Delete each computer object in the source domain when you’re done. Otherwise you may lose track of what’s left to move. migrationHelperScripts has a vbs script to do that.

Finally, there are a couple advanced topics which you may or may not need to prepare for.

  • If you’ve got servers with services (or scheduled tasks, etc.) that run with a domain user account, then we’ll need to deal with those specially. Talk to UW-IT about this.
  • If you are using cross-realm authentication with u.washington.edu currently, be aware that the NETID domain doesn’t support that. Talk to UW-IT about this.

Migrating Computers

To migrate computers using ADMT, you have two primary choices. You can either use the GUI-based Computer Migration Wizard or the command-line. The command-line gives you the same configuration options as the GUI, but less visibility on what’s going on. For the purposes of showing what a computer migration looks like, we’ll show a few key screenshots of the GUI here.

You’ll need to fill in the source and destination domains, e.g.:

domain selection

Then you’ll need to specify which computers to migrate at this time. You can pick them or point at a file with their names.

Then you’ll need to tell ADMT where to put the computer object within the NETID domain, i.e. which OU under your delegated OU, e.g.:

target ou

Then you need to enable/disable which resources the ADMT agent will reACL. In almost every case, you’ll leave everything enabled.

resources to translate

Then you configure whether the ADMT agent is going to *replace* existing ACEs with the corresponding NETID target or just *add* the NETID corresponding target. Most folks should choose replace. If you do choose add, then at some later point, you’ll want to remove the unneeded ACEs from your source domain or your ACLs will be very messy. Note that user rights translation is add mode only.

translation options

Then you configure how much warning end users get when the ADMT agent completes it’s business. In other words, if there are users interactively logged into a computer which ADMT is working on, then they’ll get a warning that the computer is going to reboot is X minutes. You get to choose how much time they get. The default is 5 minutes, and you probably don’t want to pick a big number or else you’ll end up with computers in an odd state.

restart time

Next you can accept no property exclusions, and leave the conflict management setting at ‘Do not migrate source object if a conflict is detected in the target domain.’

Finally, you’ll get a summary window which will display all the options you choose so you can review them before selecting Finish. When you click Finish, you’ll get a window which shows you the status of the ADMT agent on each of the computers you selected, like so:

agent deployment window

Under the Agent Actions section, you can ‘run pre-check’ to make sure you’ve got connectivity & perms to the computer, and then ‘run pre-check and agent operation’ to deploy the agent.

On the computer to be migrated, an active user won’t see anything until the agent is complete, when a pop-up window like this will appear:

agent reboot notice

If you have problems, a quick check for the first 6 gotchas noted above is to try connecting to \\computername\admin$. This checks name resolution, connectivity, and all the SMB-related issues.

If ADMT reports any errors or has an unknown status, check the agent logs. For complete errors, you can remotely drill down to the logs from within ADMT as long as the computer is up. Otherwise, check %systemroot%\temp\dctlog.txt on the computer you migrated.

Links