Seen when trying to install the ‘ADMT Password Export Server Service’, whilst doing a domain migration;
Invalid Password!
The supplied password does not match this encryption key’s password. ADMT’s Password Migration Filter DLL will not install without a valid encryption key.
Solution
At first I assumed I was suffering from ‘fat fingers‘ and just entering the wrong password, (or the Caps Lock was on.) However, it became apparent that this was not the case. I attempted to generate a new file by re-running the command on the ADMT server;
Same error? The only way I could get this to work was cancel the install, then launch an administrative command window, and finally running the install, ‘en-US_pwdmig.msi’ file from within that Administrative Window.
Related Articles, References, Credits, or External Links
On the homeward stretch now, back in Part Three, we migrated service accounts, groups, and users. Now we turn our attention to our machines.
Note ADMT 3.2 Only support the migration of Operating Systems up to Windows 7, (that doesn’t mean Windows 8 and Windows 10 wont work, it just means they are not supported). Migrating Windows 8 and 10 throws a lot of security translation errors, because of the way it treats ‘Apps’, so I’d recommend you do a LOT of testing before carrying out a live migration.
Solution
ADMT Computer Security Translation
Migrating computers is a two-step procedure, you do a security translation on a machine, then you migrate the machine. The security translation adds the security for the user(s) in newdomain.com to all the objects (files, folders, user profiles, and registry hives, etc) that their user account in olddomain.com did. like doing the service account migration (above) the plan is to get everything ready to ‘work’ before the machine is migrated.
Real World Note: This can take a while, (up to an hour for some machines,) and it’s best done without anyone being logged in (to prevent any profiles, or registry hives being locked). So take time to plan when this is done – rush it and you will have problems, and the very users who are too busy to be interrupted, are the very ones that shout the loudest if there’s a problem post migration. I would (if possible) have a stock of prebuilt machines on the new domain in case there’s any migration dramas, at least then you can get people working quickly.
This should be getting familiar by now, accept the defaults.
Select your computer(s) > Select all the options > SELECT ADD > Finish.
Agent Note: You are about to deploy the ADMT agent, make sure you have followed part one and part two.This process will be familiar if you carried out the service translation wizard earlier.
Run the pre check, and agent deploy.
What you will find after translation is all the profiles, and files etc will have the new domain users added alongside the old one with the same rights.
ADMT Computer Migration
Now finally to migrate the machines, ADMT > Computer Migration Wizard.
Select the computers.
Select the Target OU > Tick everything > Add > Select the amount of time to wait before rebooting the machine into the new domain.
Hang About Haven’t we done some of this? Yes, but because you have done the security translation already it can see the ACLs exist as it goes through and skips creating them.
As usual I’m not filtering any attributes > I’ll quit if theres a conflict > Migration should then complete.
Can I migrate Servers With ADMT?
Yes, but you need to have a good think about doing so first? For simple file and print servers that should be OK (Obviously back them up first etc). DONT try and do this with an Exchange server, or any other server that relies on Active directory for its very existence! And wherever possible if you can create clean new servers and migrate your data into them do so!
What about Microsoft Exchange and User Mailboxes?
I mentioned Exchange briefly on the user migration, Exchange migrations between domains, are possible, depending on your setup it may be easier to export all the mail form the old system and import it into the new one (use the search bar above. I’ve already written a load of stuff about doing this). In the not to distant future I’ll cover Exchange Inter Organisation Mail migrations.
Readers Note:
As with all the articles here, please provide feedback below, if one thing you have found can save another reader sweat and toil, then that’s the very reason for this site! If you have been with this since part one thanks for staying till the end (PL).
Related Articles, References, Credits, or External Links
Seems like ages since I wrote Part Two, now we are ready to actually start moving objects from one domain to another.
Solution
ADMT: Service Account Migration
Why would you want to do this first? Well this replaces any service accounts on the OLD domain machines with migrated service accounts form the NEW domain, so when the client machines, (or servers,) are migrated they’re already using the new service account, (neat eh!) Not only that, it will replace Local accounts with Domain accounts, for which you can specify a decent (secure) password.
Common Sense Check: If you are carrying this out on a server, then I’d suggest a good backup, or if it’s a VM, then at least a snapshot before you start!
Launch ADMT > Service Account Migration Wizard.
The wizard is pretty straight forward.
When prompted select the computer(s) you want to perform the service account migration upon.
Select Run pre-check > OK > It should say ‘Passed’.
Select Run pre-check and agent operation > Start > It should say ‘Successful’.
It will locate (if found) any service accounts, you can choose whether to ‘skip’ them or ‘include’ them > Next > Finish.
Now we have to do a ‘User migration’ for these users, (don’t panic we haven’t started migrating domain users yet.) But these service accounts need creating in newdomain.com
Launch a ‘User Account Migration Wizard’.
This time it will remember the domain settings, and should display your chosen service accounts.
Select the ‘Target OU” in newdomain.com > Next > Generation complex passwords > Make sure you tick ‘Migrate User SIDs to target domain’.
Because I was lazy, and didn’t manually enable auditing, ADMT will do it for me, (Note: This will create a security group in olddomain.com).
Update User Rights > I’m not excluding any attributes > Do not migrate if theres a conflict > Check and include the accounts as required > Select “Migrate all service accounts and update SCM for items marked include”.
Heed the local group warning > Finish > Hopefully it should complete without errors.
So now your computers, (still on the olddomain.com) have their services running under service accounts on newdomain.com.
ADMT Domain Group Migration
Wait, you are migrating groups before users? Yes, the ADMT database tracks who is in what groups, and they will all get put in the right groups as the users come across into the new domain.
There is a sequence for doing this though, you may or may not be aware there are three types of security groups and they HAVE TO be migrated in the correct order;
First: Universal Groups
Second: Global Groups
Third: Domain Local Groups
To locate what types of groups you have, and what they are called, run the following commands;
This is probably the easiest of all the migrations, just accept the defaults and locate your universal groups.
Select the target OU > Fix Membership of group > Migrate Group SIDs to target domain > Again I’m not excluding any attributes.
Dont migrate if theres a conflict > Finish > Hopefully they will all complete successfully.
Then repeat for the other two group types.
What about Distribution Groups? These are created by Microsoft Exchange, if you need to migrate Distribution groups then you can convert them to domain local security groups, then migrate them with ADMT. Note: You may need to fix their Email address manually, that depends on your new email deployment in newdomain.com
Common Sense Check: At this point it’s worth considering ‘user attributes’. For the uninitiated, a user attribute is a ‘setting’ that all users can have, e.g. a user-name, a telephone number, a department etc. All these are ‘user attributes‘ The attributes that users can have, are defined in the ‘Schema‘. So if you have any software that ‘extends the schema‘, this creates new attributes. The best example of this is Microsoft Exchange, which add lots of attributes. But there are third party bits of software that you may use, that do the same. For example I have client that has third party software that creates a ‘Photo’ attribute that holds the users ‘mugshot’, and another that adds employee payroll numbers. MAKE SURE that these bits of software have been installed into the target domain, if you want the attributes to migrate properly.
ADMT > User Account Migration Wizard.
Accept the defaults > Select the users you want to migrate.
Note: If you are wanting to change the username i.e. from p.long to pete.long then you can use a CSV and select ‘read objects from include file.’
Back in Part One we setup our migration admin account, and installed ADMT. Now, as I’m going to migrate the users passwords I need a ‘Password Export Server‘, but first I need to tackle the subject of user SIDs
Solution
Domain Migrations and SID Filtering
Every user has a SID (Security Identifier) it’s the thing AD uses to refer to and apply security to users, (and other objects). This is why you can rename a user and it’s security does not change, (because the SID always remains the same). Why is this important for domain migrations? Well if you’re a doing a migration that’s taking place over a period of time, users in the NEW domain may still need access to things IN the OLD domain, (like file shares, printers, applications etc).
This is a problem because when you setup a domain trust it Enables SID filtering, back in part one it told you this, here. So if a user in newdomain.com tries to access a folder, (they could access before the migration,) in olddomian.com they wont be able to do so, (because their SID has changed, to a new SID in the new domain. Even if you migrated their old SID if get’s filtered out as the user comes back over the trust).
How do we fix that? We need to do two things,
Migrate the users old SID to newdomain.com (This then become their, sIDHistory attribute)
Disable SID filtering in olddomain.com (To allow the sIDHistory attributes to come back over the trust)
This lets users in the new domain have their NEW SID, and their OLD SID.
Migrating the users SID is simple, (it’s just a box you tick when running a migration, you will see that later). Disabling SID filtering can be a little confusing. Where do you do it, and which way round do you execute the command? Above I’ve solved the first one for you you Disable SID Filtering on the OLD domain. The following diagram will explain why;
Usually users DON’T have a sIDHistory. attribute, (unless they’ve been migrated before!) They only have a SID (objectSID attribute.) To demonstrate let’s jump forward in time, and look at a migrated user (ABarksdale)
Click to enlarge the above image, and inspect the users SID (objectSID) and old SID (sIDhisttory) attributes.
As the name implies, this is a piece of software that runs on the source domain, (on a domain controller,) that ADMT uses to migrate user passwords. Before you can do this, you need to create a ‘key’ in the NEW domain, (where ADMT is running). Then, you use that key to setup the password export server in the OLD domain.
password: can be anything you want, but you will need it to setup the password export server, so don’t forget it.
If it runs OK, find your keyfile, then copy this to the domain controller in the old domain you are going to install the password export server service on.
Theres two versions of the password export server software, (a 32 bit and a 64 bit version.) Download and install the version applicable to your source domain controller.
Note: The install requires a reboot of the server, you might want to do this at the end of the day.
The install is pretty simple, Accept the EULA, browse to the keyfile, and enter the password you used above.
Specify a user account to run the service as, (I just use the ADMTAdmin account we’ve already created).
Finish the install, and let it reboot.
After a reboot, if you look in the services (Start > Run > services.msc). You will see the ‘Password Export Server Service’.
Note: You will also notice the startup type for the service is ‘Manual’. ONLY start this service, when you are actually migrating passwords.
ADMT: Granting Local Rights to ADMT user in the Source Domain.
To migrate machines, the ADMTAdmin user needs “Local” administrative access on all the source machines. The easiest way to do this is via group policy, using ‘Restricted Groups’. This allows you to take a group (or user) and put put them on the local groups (including administrators) of the targeted machines.
In the OLD domain, create a group and put the ADMTAdmin from the target domain in it. (I put the domain admin from the target domain in it as well, to be on the safe side, but that’s up to you).
Note: You may see this a few times while doing migrations, notice above the user icon there’s a small red curved arrow (below), that logo denotes ‘Foreign Security Principle’, it’s not really our user at all, it’s a special object that AD creates in a hidden OU, (turn on advanced mode in AD users and computers you can see them.)
Create a new GPO that will apply to the computers/servers you are going to migrate.
To test it has applied, on a client run ‘gpresult -R’ at an administrative command prompt.
You can of course, simply check the local administrators group to make sure the new group is in there.
ADMT: Additional GPO Note
To perform computer migrations, (and security translations), ADMT needs to deploy an ‘agent’ to the machines in the OLD domain. The local firewall (if enabled) can stop this, I simply disable the local firewall. (If someone wants to send me a list of ports to add, to make it work I’ll publish the). But even the Microsoft Documentation on Technet says disable the firewall.
Create a new GPO linked to where your source computers are, (here I’m just linking to the root of the domain).
In addition I have also seen the agent fail to deploy if the ‘Remote Registry Service’ is not running on the target machines, (it’s disabled by default). So I use this policy to turn that on as well.
In the same GPO navigate to;
[box]Computer Configuration > Polices > Windows Settings > Security Settings > System Services[/box]
Locate the ‘Remote Registry’ service, and set it’s startup to automatic.
I’ve not used ADMT for ages, I’ve got a domain migration to do soon, so I thought I’d get on the bench and have a reminder. Although ADMT 3.2 was ‘re-jigged’ to support Server 2012 R2, I’m still going to install it on Server 2008 R2. I’ve got a test domain built to migrate from, and a new domain setup ready to migrate into.
The old domain needs to be able to resolve names in the new domain, and the new domain needs to be able to resolve names in the old domain. To achieve this you need to setup ‘Conditional Forwarding’ in each domain for the other one.
Don’t worry if it looks like there’s a problem as long as the DNS servers can se each other, (and there’s no firewall in-between blocking TCP and UDP port 53). Just add in the DNS server give it a while then re-open the forwarders settings and it should have ‘gone-green’.
You can test it’s working by pinging BOTH the old and new domain names, in BOTH domains.
In addition, we want all machines (in both domains) to set their primary DNS Suffix, to their own domain, and their DNS suffix search list to look for their own domain first, then the other domain. The easiest way to do that is via group policy. On a domain controller > Administrative Tools > Group Policy Management Console.
It’s better practice to ‘link’ your policy to the actual OU that your computers are in, to keep things simple, (and because I’m lazy) I’m going to link my policy to the root of the domain.
Above: you can see both the policies have taken effect.
Repeat the procedure in the new domain, (but the domain names will be the opposite way round) like so;
ADMT – Creating Domain Trust
Both domains need to trust each other for the migration to take place. If you have two simple domains like I do a “two way domain trust” is fine. You would only need a ‘forest-trust‘ if you were migrating from/to root and sub domains for example.
As the name implies Trusts are setup from Administrative tools > Active Directory Domains and Trusts. You can setup the whole thing from one domain, below I’m creating it in the old domain.
Welcome Screen = Next > Provide the name to the ‘other’ domain > Next > External Trust > Next.
Two Way > Next > Both this domain and the specified domain > Next > Provide administrative credentials for the ‘other’ domain > Next.
Domain wide authentication > Next > Domain wide authentication > Next > Next.
Next > Yes. Confirm outgoing trust > Next > Yes. Confirm incoming trust > Next.
Finish > READ the warning about SID history, we will have to mess about with SID History filtering a bit further on > OK.
This step is not really necessary, (it’s just for peace of mind). I do this in BOTH domains and validate each trust, (so you will do this four times).
Select the trust > Properties > Validate > Type in credentials > OK > Type in Credentials > OK > OK.
ADMT – Users / Admins and Rights Assignment
Create the user that will do all the hard work in the NEW domain. Then add that user to the domain admins group (again in the NEW domain).
Username: ADMTAdmin (Can be anything you want, but I’ll refer to this username throughout).
Over in the OLD domain, you won’t be able to add your ADMT user into the domain admins group, you need to add the ADMTAdmin account from the NEW domain into the Builtin\Administrators group on the OLD domain.
Additionally: the ADMTAdmin user needs to have local administrative rights to all the machines in the OLD domain. The easiest way to do that is again with a group policy.
In the OLD domain create a group, (Type: Domain Local)
Group Name: GP-ADMT-Admins, (again you can call it something else if you want).
Add your ADMTAdmin account to this group, (Note: I like to add the domain admin account for the NEW domain as well, though that’s not necessary).
On a domain controller > Administrative Tools > Group Policy Management Console.
Once Again: It’s better practice to ‘link’ your policy to the actual OU that your computers are in, to keep things simple, (and because I’m lazy) I’m going to link my policy to the root of the domain.
Or the best test is, make sure that the GP-ADMT-Admins group is actually in the local admins group.
ADMT – Database Requirements
OK, a lot of posts say don’t install ADMT/SQL on a domain controller. That’s not strictly true, you can install ADMT and SQL on a domain controller, in fact that’s what Im going to do (there are a few commands and extra steps that I will point out below).
You can you use full blown SQL if you like, but it’s just as easy to use SQL Express 2008 SP1 > Download and run > Instalation > New SQL Server stand-alone installation or add features to an existing installation.
Accept the defaults > In feature Installation select ‘Database Engine Services’.
Accept the named instance ‘SQLExpress’.
Keep accepting defaults until you get to ‘Server configuration‘ page, add in the ADMTAdmin account.
Then add in your ADMTAdmin account again. (Once again theres nothing wrong with adding the domain admin account as well).
ADMT – Additional SQL Steps For Domain Controllers
NET LOCALGROUP SQLServerMSSQLUser$Target-DC$SQLEXPRESS /ADD
SC SHOWSID MSSQL$SQLEXPRESS
{Copy the SID to the clipboard you will need it in a minute}
MD %SystemRoot%\ADMT\Data
ICACLS %Systemroot%\ADMT\Data /grant *{Paste the SID from above}:F
i.e.
ICACLS %systemroot%\ADMT\Data /grant *S-1-5-80-3880006512-4290199581-1648723128-3569869737-3631323133:F
[/box]
ADMT – Downloading and Installing ADMT
Download the ADMT software, if that link ever dies use this one. Download ADMT 3.2. Launch the installer and accept all the defaults until you get to database selection, use .SQLEXPRESS
No we don’t want to import and data from an existing database > Next > Finish.
We can now open the ‘Active Directory Migration Tool’ management console.
In Part Two we will look at SID filtering, setup a password export server, and do some group policy work.
Related Articles, References, Credits, or External Links
