-
Title
Things to know before starting an Intraforest Migration with SidHistory -
Description
Quest Migration Manager provides convenience and coexistence during the migration transitional period by allowing the migration of SidHistory in an Intra-forest migration. It allows gradually updating user's resources like windows profile and file system on the local workstation, and keeping uninterrupted access to all resources based on SIDHistory. One of the other big advantages is the possibility of rolling back to the source account that is still there and not deleted.
Other non QMM methods involve the migrating of accounts to the target domain, however the immediate deletion of the source object.
With the advantages of Intra-forest SidHistory migration come several issues that you should be aware of before attempting such a migration.
After performing user or group migrations with sidHistory from domain1 to domain2, which are part of the same forest, any permissions for migrated resources in domain1 are no longer resolved to user names. Once deleting migrated objects from domain1 or undoing migration session SIDs are resolving successfully. -
Cause
This is a known Microsoft GUI issue where the SIDs are displayed unresolved in the intraforest migration scenarios involving SIDHistory.
-
Resolution
Microsoft's method of IntraForest migration with sidhistory is to delete the source account after migrating. This limits the migration, as users must begin using their target accounts immediately after being migrated.
QMM 8.0 and previous versions allow both accounts to stay "active" within the forest. This is a great advantage during a migration, however also adds certain problems arising from having duplicate SIDS within the forest. By duplicate SIDs we are referring to the original SID of the object being migrated, and the SidHIstory value applied to the new target account.
In some situations when using the windows interface to assign permissions to objects, files, etc. The interface will not display the source and target object correctly. This is because the native API that Microsoft is using does not expect to see a populated SIDhistory value, equal to the SID of another object (user,group,etc.) in the same forest, and thus does not resolve them correctly.
** To resolve this issue, the target object must either have the SidHistory attribute deleted, or the source object must be deleted from the source environment. **
The processing of some NETAPP filers will not function correctly due to the way in which the NETAPP APIs cached credentials.
** for further information on this please see the following article: http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=158609 **
In certain situations after migrating users and performing Resource Updating, users are able to login to their target profile on the workstation, they receive the following error "Windows cannot find the local profile and is logging you on with a temporary profile. Changes to this profile will be lost when you log off."
** please see the following Microsoft article http://support.microsoft.com/kb/941339/en-us ** -
Additional Information
Other unknown issues maybe arise as a result of this migration scenario. This migration method is not designed to be used long term, and should only be used during brief periods due to the potential for problems.
It is strongly suggested that before attempting such a migration Quest Professional Services be involved for planning and to asses potential problems.