Hi folks, Ned here again. Today I discuss an insidious issue you can see with USMT when you have previously migrated computers between forests with ADMT . This scenario is rare enough that I didn't bother with a KB article - not to mention it's easier to explain with pictures and "wit". If you get into it though, you will need the right answer, as there are some wrong answers floating around the Internet.
You will only have issues here during the loadstate operation, dropping data onto a fresh new computer. At first blush, the error will be generic and useless:
Error while performing migration
Failed.
Software malfunction or Unknown exception
See the log file for more information.
LoadState return code: 26
But if you look at the loadstate.log (having made sure to provide /v:5 on the command-line), you see:
Info [0x000000] Apply started at 4/18/ 2011 21:17:39
Error [0x000000] Invalid user mapping : BYAIR\testuser1 -> S-1-5-21-4187903345-2522736461-4139203548-1110
Info [0x080000] Received request to restart the explorer process from context: SYSTEM
Info [0x000000] Leaving MigApply method
Error [0x000000] Error while performing migration
Warning [0x000000] Internal error 2 was translated to a generic error
Info [0x000000] Failed.[gle=0x00000091]
Info [0x000000] Software malfunction or Unknown exception[gle=0x00000091]
An incomplete migration with ADMT causes this issue. Sometime in the past - perhaps distantly enough that it was before your time - this computer and user lived in another AD forest. In my examples below there was once an Adatum.com (ADATUM) domain and currently there's a blueyonderairlines.com (BYAIR) domain. I demonstrate this going from Windows XP to Windows 7, as most people are in that boat currently.
Let's go backwards through the sands of time and see where I went wrong…
1. I migrate users with ADMT, making sure to enable SIDHistory migration (this is on by default). See here how my TestUser1 account has its old ADATUM SID added to the sIDHistory attribute after migration between the forests:
2. I then migrate the users’ computers with ADMT and do not translate profiles during the migration (below should have been checked ON , but was not):
3. This means that the migrated users’ profilelist registry entries do not translate during migration. Note below how they are still the old domain SID:
4. Then the user logs on to his migrated computer with his migrated user and ends up with a new profile, as expected. Note how the old profile is still here and the user's new profile is too:
5. The user – probably confused at this point – calls the help desk. “Where are all my files?” The files are still in the old folder and because I performed sidHistory migration, the user still has full access to that folder and its contents. The user or help desk might copy files over into his new profile (probably just “My Documents to My Documents”). Or they might just leave the files there and the user knows to go access older files out of their old folder. It’s just a folder to them, they don’t understand profiles after all. It’s highly unlikely a user was still accessing this old location from here as it is obfuscated in Windows Explorer, but unlikely isn’t impossible - they could have been shown how by a misguided help desk staff who should have copied the files and alerted me to the real problem.
At this point, the “good” profile is “c:\documents and settings\testuser1.byair”. The “bad” one with data in it from the ADMT migration is the “c:\documents and settings\testuser1”. Again, someone may have reconciled these file contents by hand or they may not.
6. Years go by and I retire to Barbados. Along come you and your project to migrate old XP computers to the new Win7 machines. The ADMT migration is ancient history and that old domain probably doesn’t even exist anymore.
7. USMT scanstate.exe gathers the XP computer and gets all the profiles. If you watch this closely, you see that there are reconciliation problems:
8. You run USMT loadstate.exe on the Win7 computer that has none of these user profiles at all and because the user to SID mapping is invalid (there is no such thing as a user with that SID directly set anymore but there is a sidHistory that belongs to another profilelist SID entry for a “different” user), we finally error.
Uggh. Technically speaking, nothing is broken here: USMT is working by design and ADMT was following my (bad) instructions.
There are three realistic solutions to this, one overkill solution, and one that you should never use ever that I include only for completeness and to stop people from making a mistake through ignorance - five options. All SIDs provided below are samples, bien sûr.
scanstate c:\store /i:migdocs.xml /i:migapp.xml /o /c /v:5 /ue:* /ui:S-1-5-21-1120787987-3120651664-2685341087* /ui:%computername%\*
That quickly gathers only the current “good domain” user profiles and local user profiles, skipping the old “bad domain” profiles. If you have multiple “good” domains you might need to feed it multiple /ui of those you want to include.
scanstate c:\store /i:migdocs.xml /i:migapp.xml /o /c /v:5 /ue:S-1-5-21-4187903345-2522736461-4139203548*
Note: The issue remains with both option 1 and 2 that the old so-called "bad domain” profile might still contain data, as I outlined in the "What it Means" section. You must do some investigation to find out if these old profiles really are just garbage and can be freely abandoned, or if you need to also gather that data. On the plus side, you are not actually deleting data – you are only opting out of migrating it. The old data is still there and if you’re following the best practices, it’s contained in the backup taken before the migration. You let your users decide if the data is valuable by them asking for it back or not. The backup can be stored locally on that new computer for safekeeping indefinitely.
That being said, this option 4 is probably overkill, especially if you are getting backups before scanstate like we recommend. If you do the legwork to find out the status of all these old profiles, find out how people dealt with the new profiles after migration, and determine they truly aren’t being used, I’d not bother with this and stick with Options 1, 2, or 3 above.
Update: Octavian makes the excellent point that Favorites and Desktop are likely filled with valuable user goo. I updated the sample.
Sample XML named getdocsandset.xml :
<?xml version="1.0" encoding="UTF-8"?>
<migration urlid=" http://www.microsoft.com/migration/1.0/migxmlext/coallescemydocumentstoasafeplace ">
<component type="Documents" context="System">
<displayName>copy all the useful shell folders to a hidden folder on destination </displayName>
<role role="Data">
<rules>
<!—All copies shell folders saved so admins can decide what to do with the data later-->
<include>
<objectSet>
<pattern type="File">C:\documents and settings\*\my documents\* [*]</pattern>
</objectSet>
</include>
<!—Copies shell folders to a special folder for admin attention or destruction.-->
<locationModify script="MigXmlHelper.RelativeMove('C:\documents and settings','c:\extramydocsdata')">
<objectSet>
<pattern type="File">C:\documents and settings\*\my documents\* [*]</pattern>
<pattern type="File">C:\documents and settings\*\desktop\* [*]</pattern>
<pattern type="File">C:\documents and settings\*\favorites\* [*]</pattern>
</objectSet>
</locationModify>
</rules>
</role>
</component>
</migration>
scanstate c:\store /i:migdocs.xml /i:migapp.xml /o /c /v:5 /ue:* /ui:S-1-5-21-1120787987-3120651664-2685341087*/ui:%computername%\* /i:getdocsandset.xml
loadstate c:\store i:migdocs.xml /i:migapp.xml /c /v:5 /i:getdocsandset.xml
Just to be sure in this case, you now have all the profiles from the source computer saved to a central location after migration:
You set permissions to Administrators-only and Hidden, mainly to stop users from mistakenly using this folder as live data. You can do that through a batch file like this sample:
icacls.exe c:\extramydocsdata\ /grant administrators:(F) /inheritance:r
icacls.exe c:\extramydocsdata\* /grant administrators:(F) /inheritance:e /t
attrib.exe +H c:\extramydocsdata
Migrating users and computers without translating profiles is usually the wrong plan. See the ADMT Migration Guide in section " Translate Local User Profiles" . Even without USMT in the mix here, the users were unhappy campers after ADMT and Evil Twin Ned finished with them.
Until next time.
Ned "I like MT" Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.