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

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

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

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

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

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

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,

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

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

ADMT Series – 2. Preparing the ADMT Machine

You should install ADMT and SQL onto a member server in the target forest. Use the ADMT service account explained in the previous post to install SQL and ADMT. ADMT requires a preconfigured instance of SQL Server for its underlying data store, so we’ll go ahead and install SQL 2008 SP1 Express on Installing SQL Express 2008 SP1 SQL Express download here: 1. Choose New Stand-alone installation. 2. Select Database Engine Service. 3.