In this demonstration,
I'll show you how to use the Active Directory Migration Tool,
or ADMT for short.
We're looking at, as you can see in the upper right,
I've got some BGInfo output here.
I'm on a domain controller in another forest.
In fact, let me bring up my Admin Console here; it's srv1.company.com.
And let's pretend that this is our acquisition, all right.
And we're going to export users, groups,
computers,
out of this forest and domain into the one that we've been
using for this entire learning track, the timw.info forest and domain.
So what I want to draw your attention to here is in
Active Directory Users and Computers.
I've got one organizational unit called Office Staff that has a
couple global groups and some user accounts.
I also have another OU,
and I have one domain‑joined Windows 10 workstation called CLIENT1.
So it's just a simple lab environment.
In order to facilitate things, let me bring up my
network properties here, ncpa.cpl.
I've made sure that I can do DNS resolution,
so if I look at the Advanced properties of this
machine's network interface card, this machine is at 241,
but I've also included the timw.info DNS server.
I know that I could do forwarding and DNS,
but I'm actually distributing the IP address of the
destination domain's DNS server.
All right, also, again,
to facilitate this movement in the Active Directory Domains and Trusts console,
if I look at the Properties here and go to Trusts,
I've set up bidirectional transitive forest trusts
between company.com and timw.info.
All of this is to facilitate that transfer.
Lastly, I installed the ADMT, the latest version, which I believe is 3.2.
In order to install this,
you have to have an old version of SQL Server installed.
If you look down in my Start menu, I installed the SQL Server 2008 R2,
the Express, or free edition.
It's running as a named instance called SQL Express.
I had no problem installing the tools as long as I
had that old SQL Server running.
All right, anything else?
Yeah, one more thing actually.
Let me go to the Downloads folder.
If you're looking at password export,
you'll want to install the Password Export Server,
and that's what this little msi is.
If you just do a search on Google for ADMT Password Export, you'll get this.
And what you do is you'll run an ADMT command‑line command to
generate a key that the ADMT tools will use to encrypt the user
passwords as they go over that trust channel.
So that's what I got going on. Now, as far as actually performing the migration,
let's take a look.
It's not very intuitive at all because as you can see,
it's pretty much an empty MMC console that has just an empty
Reports node with some descriptive text,
but it's nonintuitive as far as how to use the tool.
You actually right‑click,
and you can invoke any of these wizards from the top part.
So let's start by grabbing some user accounts here.
So let's do User Account Migration Wizard.
All of these are using the traditional Win32 wizard interface.
Our first step here is to use either typing or these
drop‑down controls to specify the source and destination
domains and domain controllers.
So I'm going from company.com to timw.info.
And you can either choose a specific DC or you can choose any domain controller.
I'm being very intentional here in my work.
Let's click Next.
How are the users to be selected?
I'm not going to do an include file.
I'm going to do a direct selection.
So let's click Add here.
And now we can enumerate.
I forgot what their names are, so let me just bring up my office staff again.
I've got, let's say, Camila and Felipe will be our first ones.
So I'll bring in Felipe, and now I'll bring in Camila.
Click Next.
What is the distinguished name of the target OU?
If we click Browse,
this fortunately has a graphical overlay to where you don't
have to type out distinguished name syntax.
I'm going to put these new users in the Staff OU in the
timw.info destination forest and domain.
Click OK and Next.
What type of passwords do you want to use, you see?
So if we're not using the Password Export Server,
we have to really just either do not update or generate complex passwords.
And if we generate passwords, those will be captured in a separate file.
Well, I have the Password Export Server installed,
so I'm just going to specify that my Password migration
source is in fact srv1.company.com.
We'll click Next.
Now you'll want to make sure,
as I'm showing you here in the service control manager,
that you have the Password Export Server service running.
Mine was set to Manual Startup stopped, so I made sure to start the service here.
And so now we can, again, click Next to continue.
How do we want to handle migrating accounts?
By default,
it's just going to assume that if the account is
not disabled on the source side, it will be not disabled on the destination side.
So I'm just going to leave all that at the default.
Now look here.
Migrate user SIDs to the target domain.
This would override SID filtering.
I'm going to select that just because we can investigate it later.
I'm going to click Next.
It says here that Auditing is currently not enabled on the source.
Would you like to enable it?
If not, SID migration will be disabled.
Yeah, come to think of it, let me go back and make sure.
No, I'm not going to mess with that.
I'll leave SID quarantining on,
which will give these users a brand‑new SID in the target forest.
That's fine.
But we'll go Next.
What else do we want to do?
Do we want to update user rights?
Do we want to migrate associated user groups?
And if it's been previously migrated, the group update it?
Do I want to translate roaming profiles?
That could be a heavy lift.
I'm going to just select Migrate associated user groups.
If you have an extended schema in the source,
you can exclude properties from migration.
I'm not going to do that.
I'll leave everything stock and default here.
What if there's a conflict?
The default is to not migrate.
And that's really it. Click Finish.