ADMT Series – Misc. Cannot open database ADMT – The login failed
If you install ADMT under a different user, you may receive this error when trying to access the ADMT MMC console:
Unable to check for failed actions. : DBManager.IManageDB.1 : Cannot open database "ADMT" requested by the login. The login failed.
To resolve this you will need to install the Microsoft SQL Server management Studio, download available here: http://www.microsoft.com/en-us/download/details.aspx?id=7593
Run the installer and select New SQL Server stand-alone installation or add feature to an existing installation.
Choose Add features to an existing instance of SQL Server 2008.
Select Management Tools - Basic (it's greyed out here as I've already got them installed).
Follow the rest of the installation through, when complete run the SQL Server Management Studio and connect to the SQLEXPRESS instance.
ADMT Series – 11. Computer Migration Wizard
This post will cover the process of migrating computers from the source domain to the target domain. After you migrate a batch of local user profiles, migrate the corresponding batch of user workstations.
ADMT Supported Operating Systems for Computer Migration
ADMT 3.2 - supports the migration of computers that run Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
ADMT 3.1 - supports the migration of computers that run Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, and Windows Server 2008
ADMT 3.0 - supports the migration of computers that run Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server, and Windows Server 2003.
Computer Migration
From the ADMT machine, run ADMT and select Computer Migration Wizard.
Select the source and target domain, you can also select which specific domain controller to use.
Select computers from the domain or use an include file. This may be quite useful if you're doing an OU at a time as you can export objects of an OU via ADUC (right click -> export list).
ADMT Series – 10. Security Translation Wizard – Local Profiles
This post will cover the Security Translation Wizard from the context of migrating local user account profiles into the target domain. This step is crucial if you want your users to maintain the same local profile. The Translation Wizard needs to be run before migrating the computers. If you decide to skip this step, the users will receive a new profile when they logon to the target domain for the first time:
Be aware this process can take some time, I've seen it take up to 40-45 minutes on some older laptops.
Translation Security Wizard - For Local Profiles
From the ADMT machine, run ADMT and select Security Translation Wizard.
Next.
If you have migrated the source domain user accounts, you can select Previously Migrated Objects- this will pull the list of the source and target SIDs from the ADMT database for mapping across the new permissions. This is probably the best method if you have migrated the users across, or if you don't need granular control over the process.
You can use a SID mapping file to link two accounts from the source and target domain. In the migration I recently went through, the accounts had already been created in the target domain, and there was no requirement for SID history. I decided that merging the user accounts wasn't necessary. As I hadn't migrated the users I was unable to use the previously migrated objects option, as ADMT has no history of the account SIDs in the ADMT database. A SID mapping file was used instead.
The SID Mapping file can be in the following formats:
OldSID,NewSID
or
OldSID,TARGET\USER
or
SOURCE\USER,TARGET\USER
For demonstration purposes I have migrated a bunch of users accounts so I can choose the previously migrated objects option.
ADMT Series – 9. Merging Users with a Different sAMAccountName
Is the last post we looked at a vanilla user account migration, assuming a clean target domain.
There may be a situation where the users have already been created in the target domain with a different sAMAccountName. For example, the user Branch Warren might have the sAMAccountName of bwarren in the source domain but branch.warren in the target.
Source
Target
To get around this you can use an include file to map these different sAMAccountNames together when migrating. The include file is in the following format, and if we use the example above would look like this:
Sourcename,TargetSAM,TargetUPN bwarren,branch.warren,branch.warren@target.local
Creating the Include File
To generate this list you can use CSVDE to pull out the required information from the two forests. The final include file will require a bit of manual preparation to get into the correct format.
From the source domain:
csvde -d "OU=source,DC=source,DC=local" -f sourceinclude.csv -l "sAMAccountName"
From the target domain:
csvde -d "OU=target,DC=target,DC=local" -f targetinclude.csv -l "sAMAccountName, userPrincipalName"
Create the include CSV file in the same format as the example above, I've created three users which I need to migrate and merge with an include file.
Sourcename,TargetSAM,TargetUPN jjackson,Johnnie.Jackson,Johnnie.Jackson@target.local jcutler,jay.cutler,jay.cutler@target.local bwarren,branch.warren,branch.warren@target.local
Once you have this in place, the migration process is very similar to the method outlined in the last blog post. When you are asked to select users, choose Read objects from an include file, specify the Include file you created above.
ADMT Series – 8. User Account Migration Wizard
In this post we'll run through the User Account Migration Wizard to migrate users from the source to target domain. This guide will cover migrating users that do not exist in the target domain, if they do, please wait for the next article which will cover merging user accounts with an include file and/or migrating only the siDHistory attribute (with no other attributes).
I have created 9 test users in the source domain, which are members of the global security group we migrated in the last series post.
Migrating Users
From the ADMT machine, run ADMT and select User Account Security Wizard.
Select the source and target domain, you can also select which specific domain controller to use.
Select users from the domain or use an include file (the include file will be explained in the next ADMT Series post).
ADMT Series – 7. Group Account Migration Wizard
Universal, global and domain local groups can be migrated with the ADMT tool. Each group type has different rules for membership, and each group type serves a different purpose. This affects the order that the groups are migrated from the source to the target domains.
Universal groups
Universal groups can contain members from any domain in the forest, and they can replicate group membership to the global catalog. Therefore, you can use them for administrative groups. When you restructure domains, migrate universal groups first
Global groups
Global groups can include only members from the domain to which they belong. Create global groups to organize users. Global groups should be migrated second.
Domain local groups
Domain local groups can contain users from any domain. They are used to assign permissions to resources. When you restructure domains, you must migrate domain local groups when you migrate the resources to which they provide access, or you must change the group type to universal group. This minimizes the disruption in user access to resources. Migrate Domain Local groups last.
In this example we will migrate a global security group and a domain local security group which is the member of the global group.
Migrating Global Groups
From the ADMT machine, run ADMT and select Group Account Security Wizard.
Select the source and target domain, you can also select which specific domain controller to use.
ADMT Series – 6. Service Account Migration Wizard
The Service Account Migration Wizard will identify, migrate and update services that run in the context of a domain user account. ADMT does not migrate services running under the Local System account as they are migrated automatically when the computer is migrated. The Local Service and Network Service accounts are not migrated, because they are well-known accounts that always exist in domains.
When you run the Migrate Service Account Wizard, you are asked to select the computers you wish to scan for service account flagging. You can either search for computers on the domain, or provide an include file (text file with new computer objects separated by a line break). The wizard will then deploy the ADMT agent to the selected computers and scan for services running in the context of a domain user account. After the scan is complete, you will be presented with a list of services and service accounts.
The Service Account Migration Wizard doesn't migrate any service accounts, nor does it make any changes to the services running under the computers you choose. It's simply to flag the service accounts in the ADMT database.
To migrate the service account and update the service with the migrated user (in the target domain), you need to run the User Migration Wizard and select the Service Accounts highlighted in the process above. This doesn't need to be done straight away and can be part of the User Migration Process. For this demo I will carry out the complete process so you can see what happens to the services.
This step isn't mandatory, and you would typically only run this against your servers (see the security concerns at the bottom of this post). You may find if you have a small number of servers you would want to do this manually with a re-jig of your service accounts. Or perhaps the target domain has a different policy for service accounts, be that a naming scheme or how they are used.
Identifying Service Accounts
On XP1.source.local I've changed two of the services to run under domain user accounts.
From the ADMT machine, run ADMT and select Service Account Migration Wizard.
Select the source and target domain, you can also select which specific domain controller to use.
ADMT Series – 5. Machine Preparation
This post will look at preparing your workstations and servers to work with ADMT and to make sure you give ADMT the correct permissions and connectivity.
Local Administrators Group
The ADMT Migration Account that you use to migrate workstations and member servers must have local administrator rights in the the source domain. If you don't the ADMT agent cannot be deployed which will result in errors such as:
ERR2:7006 Failed to install agent on \\xp1.source.local, rc=5 Access is denied.
ERR2:7674 Unable to determine the local path for ADMIN share on the machine 'xp1.source.local'. rc=-2147024891
We'll look at two ways to achieve this with group policy.
Method 1. Restricted Groups
Create a Domain Local Security Group in the Source Domain, add the ADMT Service Account (ADMTUser in my case) to the group. You may decide to simply add the domain admins group from the target domain, as this includes the ADMTUser account. Also the Domain Admins group will get automatically added when the computers are migrated. The end result is the same though.
Create a new GPO and link it to the OU with the computer objects in.
Give it a name.
ADMT Series – 4. Password Export Server
During the User account migration you will have the option to migrate passwords from the source domain user accounts to the target domain. If you choose to use this feature there are a few steps you need to carry out. This feature is very useful, and removes the requirement to communicate new passwords to end users.
Migrating Password Prerequisites
Before you can migrate passwords, you will need to install the password export server onto a domain controller in the source domain.
Download the tool here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10370
Before you go ahead and install PES onto a DC in the source domain you need to create an encryption key from the machine running ADMT in the target domain. In our case this is ADMT.target.local. From the command prompt run:
admt key /option:create /sourcedomain:source.local /keyfile:"c:\PES Key\PES.pes" /keypassword:*
Now head over to a DC in the source domain (AD01.source.local) and download and run the PES installer. When prompted choose the .key file you created on the ADMT machine.
Provide the password you used when creating the key.
ADMT Series – 3. SID History
In the first post we setup the trust and prepared Active directory for the migration. One of the last messages provided when creating the trust states:
To improve the security of this external trust, security identifier (SID) filtering is enabled. However, if users have been migrated to the trusted domain and their SID histories have been preserved, you may choose to turn off this feature.
What is SID History
SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you migrate users into the target domain you will have the option to migrate the users SID to the target domain. This becomes the sIDHistory attribute under the new user object.
Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.
SID history can be used for roaming user profile access, certification authority access, software installation access and resource access.
To visualise this I've created a user called Ronnie Coleman in the source domain and run dsquery to display the user's SID.
dsquery * -filter "&(objectcategory=user)(samaccountname=ronnie.coleman)" -attr objectsid
Here is Ronnie Coleman's SID in the Source Domain:
If we use ADMT to migrate Ronnie Coleman to the target domain and migrate his SID from the source domain you will see both the new SID, and the sIDHistory from the source domain.
The actual process of migrating the sIDHistory will be shown in the Migrating Users part of the series, this post is simply to explain what SID History is and why you would use it in your migration.