The Sysadmins

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.

Continue reading

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, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 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).
Continue reading

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.
Continue reading

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.

Continue reading

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).
Continue reading

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.
Continue reading

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.

Continue reading