Troubleshooting Security Translation 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 a known issue related to security translation using the Active Directory Migration Tool (ADMT).
Security translation does not affect the Outlook profile
When you select User Profiles on the Translate Objects page of the Security Translation Wizard, security is not translated on Microsoft Office Outlook® profiles. To fix Outlook profiles for migrated accounts, use the Microsoft Exchange Server Migration Wizard. The Exchange Server Migration Wizard ships with and is installed with Exchange Server beginning with Exchange Server 2003.
Security translation on native registry keys is not available when you are running 64-bit versions before Windows Vista
This is a known issue that occurs because of inconsistencies in how the Windows-on-Windows 64-bit (WoW64) subsystem handles registry redirection differently in Windows Vista and earlier versions of the Microsoft Windows operating system. This issue does not affect running security translation on native registry locations for 64-bit versions of Windows Server 2008 or Windows Vista or later.
After migration, new user accounts in the target domain cannot access resources where the source domain accounts have permissions.
Cause: The settings that are necessary to run ADMT have not been correctly established.
Most migration problems are caused by an incorrectly configured migration environment.
Solution: Open the migration log file, and find the account that you migrated with the security identifier (SID) history. If SID history was added to the account, you should see an entry similar to the following:
2005-10-06 18:28:50-SID for UserAccountName added to the SID history of UserAccountName
If you receive an error message, it is almost certain that you have not configured the environment correctly, and you should review the configuration topics before you try the migration again.
SID history migration is not working.
Cause: There are a number of conditions that must be satisfied for SID history migration to work.
Solution: Configure the migration environment correctly before you run ADMT, and review the configuration topics before you proceed with the migration.
Note
When you migrate a previously migrated security principal to a new domain, the criteria for migrating SID history should be in place for all three domains.
For example, say that you have the following three domains: DomainA, DomainB, and DomainC. User1 in DomainA (DomainA\User1) is migrated to DomainB as DomainB\User1 and SID history is translated. DomainB\User1 now has the primary SID for DomainB\User1 and the SID history value for DomainA\User1. If an administrator wants to migrate DomainB\User1 to DomainC\User1 and preserve all of DomainB\User1's SIDs, the proper configuration settings must be in place to allow migration from DomainA to DomainC and from DomainB to DomainC. If DomainA has been decommissioned, or if proper configuration cannot be satisfied between DomainA and DomainC, ADMT migrates the SID for DomainB\User1 to DomainC\User1 and logs the fact that it could not migrate the DomainA\User1 SID.
If DomainA does not exist, ADMT writes an error message to the log, but migration still succeeds. You can ignore this error message.
After migration, new user accounts in the target domain cannot access resources where the source domain accounts have permissions.
Cause: The settings that are necessary to run ADMT have not been correctly established.
Most migration problems are caused by an incorrectly configured migration environment.
Solution: Open the migration log file, and find the account that you migrated with SID history. If SID history was added to the account, you should see an entry similar to the following:
2005-10-06 18:28:50-SID for UserAccountName added to the SID history of UserAccountName
If you receive an error message, it is almost certain that you have not configured the environment correctly, and you should review the configuration topics before you try the migration again.
I am receiving the following error: "The Recycle Bin on C:\ is corrupt or invalid. Do you want to empty the Recycle Bin for this drive?"
Cause: This is by design. For security reasons, each user who logs on to a computer receives his or her own, user-specific Recycle Bin. The access control list (ACL) for each instance of the Recycle Bin can contain only one user-specific SID. When you migrate a user's profile using the Add option, the SID of the source domain user is added to the SID history of the Recycle Bin. This places two user-specific SIDs in the Recycle Bin's ACL. This problem does not occur if you migrate the profiles by using the Replace option.
Solution: On the error message, click Yes, and the Recycle Bin is emptied without a problem. If you click No, the error continues to appear until you empty the Recycle Bin.
Users in domains that are not trusted cannot access Distributed File System (DFS) shares in Active Directory domains.
Cause: This is by design.
Solution: If you plan to use DFS shares in your domain, migrate the computers that belong to users who access DFS shares first or migrate the computers and users in the same migration session.