Troubleshooting User Migration Issues

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

This topic describes known issues related to migrating users with the Active Directory Migration Tool.

Special characters are replaced when account names are migrated

ADMT replaces the following characters with an underscore character “_” in the pre–Windows 2000 name Security Accounts Manager (SAM) account name and user principal name (UPN):


The period character “.” is replaced with an underscore character “_” if it is the last character of a name.

Group membership of target accounts is updated after subsequent user migrations

When you migrate a user who has been previously migrated, the Migrate associated user groups option in the User Account Migration Wizard updates the group membership of the migrated account. During subsequent user migrations, any new groups that the source user account is a member of are appended to the group membership of the user in the target account.

Example: Bob is a user in the domain HB-ACCT-WC. He is a member of the group HB-ACCT-WC \Writers and he is migrated, along with the Writers group, to the target domain hay-buv.tld (NetBIOS name HAY-BUV). After the first migration, Bob is a member of HAY-BUV\Writers. Bob is also added to the following groups in the source domain after this first migration:

  1. HB-ACCT-WC\Bob is added to the group HB-ACCT-WC\Editors.

  2. HAY-BUV\Bob is added to HAY-BUV\TechEditors.

When HB-ACCT-WC\Bob is migrated again to fix his group accounts, HAY-BUV\Bob will be a member of HAY-BUV\Writers, HAY-BUV\Editors, and HAY-BUV\TechEditors.

To reset the account to only the groups of the source user, you must delete the target account and then repeat the migration of the source account.

It is also possible to remigrate groups with the Remove existing members option.

Permissions on a user that is migrated from an Active Directory domain are reset to default values during migration

When you migrate a user from one Active Directory domain to another, the User Account Migration Wizard creates a new security descriptor on migrated user objects by using settings from the target domain. The Security tab is only visible if you select View\Advanced Features.

This is by design, because the target domain, not the source domain, dictates security settings on the migrated user account.

Incorrect error message is displayed during user group fix-up if a user account is deleted

After a migration, if you delete a user account in the target domain and a group that contained the user account in the source domain (as a member of another group), is migrated between the same domains, ADMT logs the following wrong error message:

Cannot add <account> to <group>, because <account> has not been migrated to the target domain.

If you receive this error message, remigrate the user account to the target domain.

Exclusion of the useraccountcontrol property is ignored

The user property userAccountControl is always copied when you migrate from Windows NT 4.0 domains. Even if you choose to exclude this property on the Object Property Exclusion wizard page, the exclusion is ignored and the property is migrated.

However, when you migrate from Active Directory domains, the exclusion of this property is honored and it is not be copied during user migration.

The Remove existing user rights option did not work

Cause: If the Group Policy template that is associated with a user whose user rights are being removed contains the non-domain-qualified name of the user (for example, if it contains User1 instead of DomainA\User1), the remove operation fails.

Solution: Correct the user name entry in the Group Policy template.

You receive the following error when you try to migrate users with SID history

Unable to migrate users. The following configuration required for SID history has not been performed. Auditing has not been enabled in the target domain. Unspecified error (0x80004005)

This error can occur because some subcategories for the Directory Service Audit Policy are not enabled by default in Windows Server 2008 and later versions of Windows Server. All subcategories must be enabled to migrate users with their SID history. For more information about how to enable them, see Configuring the Source and Target Domains for SID History Migration.