•Why Migrate?

•Overview
•Preparation
•Migrating Group Policies
•Preparation Part 2
•Migrating Groups
•Migrating Users
•Migrating Computers
•Migrating Servers
•Eliminating the Domain
•Potential Problems
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
That part of the presentation your supposed to have, but don’t
really need.
Overview
1. Prepare
2. Notify users
3. Migrate Groups
4. Migrate Users
5. Migrate Computers
6. Migrate Servers
7. Fix Problems
8. Eliminate the Old Domain
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.
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
AKA The most important part of the whole process.
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.
 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?
 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.
The part the ADMT guide doesn’t talk about.
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
 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.
 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.
Group Policy – Screenshots
Group Policy – Screenshots
Group Policy – Screenshots
Group Policy – Screenshots
Group Policy – Screenshots
Group Policy – Screenshots
Group Policy – Screenshots
Getting ready to create success.
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.”
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.
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 migration so duplicate user or
computer names can be resolved
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.
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
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)
For Pete’s sake, don’t choose the “copy group members” option!
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
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.
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
Forced relocation just doesn’t have the same ring to it.
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)
Migrating Users
•When an account is migrated using ADMT, it receives
a new SID and its SIDHistory attribute 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
 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?
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.
 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
This is the part that might break things.
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
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
Migrating Computers
•You will have failures
•Machines need to be on
•Some will fail their post-check but will be fine
•Some will need to be bound manually
•There’ll probably be some that will need to be started
over from scratch
•Give the ADMT agent plenty of time to run.
•Probably best to move no more than 20 or so
computers at a time
Its not like they do anything important.
Migrating Servers
•Just like migrating computers, except you’ve got a few
extra things to watch for:
•Service accounts (mentioned earlier)
•Run the service account wizard if needed
•Maybe generic user accounts used that have already
migrated?
•Anything that ties to AD needs to be updated
CHFA Server Migrations
•CHFA Migrated via the ADMT:
•One major file server
•A VMware server
•Several VMware guests, which are licensing servers
•A file/RIS/print server
•An SQL server
•The ADMT agent did take a long time to run on a large
number of files (about a million files on our main file
server)
The fun part.
Eliminating the Domain
•Run DCpromo on each domain controller and follow
the on-screen prompts to remove AD from that server
•Once you only have one DC left, check the wonderful
box for it being the last DC in the domain
•At this point, you’ll need an enterprise admin to come
and enter their credentials to complete the process
•After it completes, anything left in the domain is gone
If you aren’t scared yet…
Potential Problems
•Conflicts, computer name or user name exists in both
domains. Resolve by renaming computers and
determining why duplicate user accounts exist.
•Saved passwords are usually lost.
•Some programs don’t see the account as being the
same (Dreamweaver for example) after its migrated, so
“protected” settings are lost, see above.
•Use of built-in groups for security permissions will
still point to the old domain
•Firewalls need to allow the ADMT agent into the
system
Potential Problems
•Machines left off
•Laptops that are somewhere
•Users will always try to login during the migration
process—even at 7 AM on Christmas Day
•Software packages deployed via GP must
uninstall/install successfully