USMT and Invalid User Mapping
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.
What you see
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]
What it means
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.
What you can do
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.
- Option 1: You tell scanstate to ignore the old domain by providing the SID of the new domain during the gather. From my example SIDs and domain names above, you know that the old dead domain SID was S-1-5-21-4187903345-2522736461-4139203548 and the new one is S-1-5-21-1120787987-3120651664-2685341087. You can also use PSGETSID to look up the domain SID. You could choose only to migrate the data from the current domain using this:
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.
- Option 2: Conversely, you skip the old domain (this is harder to predict – what if there were many ADMT migrations and I had collapsed various domains? You’d have to go find out all the “bad” SIDs, and this would probably be a trial and error process where you kept discovering old SIDs during your migration). Note this time the syntax does not include /ui.
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.
- Option 3: You can remove the invalid profilelist registry entries beforehand using a script. The net is that this has the same risk as above (it will prevent USMT from gathering the file data with that supposedly abandoned profile) and is probably more work (the customer or MCS has to write the script). Again, that profile may not actually be abandoned from a data perspective, only from a user logon perspective. However, if your investigations show that they truly are abandoned and they no longer contain useful data, this is an option.
- Option 4 (overkill): You can extend the above three options with a custom XML file you provide that gathers up all the important user shell folders (My Documents, Favorites, and Desktop are likely to have any meaningful user files in an XP profile) – effectively a catchall override that will not leave data behind. This drops the files into a central spot, maintaining relative folder paths so that you could go rescue data as needed. Once you think they’ve had enough time you can get rid of the folder to return disk space, or leave it there indefinitely. The main downsides to this technique is that it uses up extra disk space, it’s complicated, it makes the migration a lot slower, and it needs some ACLs to ensure you aren’t exposing user data to everyone on the computer (I’d recommend it being set to Administrators and Help Desk-only; if the user has “missing data” problems they call the helpdesk and you retrieve it. If no one complains for 3 months can probably just delete it). The main advantage to this is that it leans towards caution and prudence; always a good plan when it comes to a user's data.
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="https://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
- Option 5 (DO NOT USE): Remove the sidHistory entry for all these migrated users in AD. This is categorically the worst and most dangerous solution, as you probably have thousands of users accessing files, databases, email, etc. with their SID History alone. I mention this option only to be complete; it is highly discouraged, as you could cause a massive outage that would be very difficult to and time consuming to repair (probably an authoritative restore of all users in the forest; a nightmare scenario for most customers).
Final thoughts
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