New USMT 5.0 Features for Windows 8 Consumer Preview

This post has been republished via RSS; it originally appeared at: Ask the Directory Services Team articles.

First published on TechNet on Apr 13, 2012
Hi all, Ned here again. Frequent readers know that I’ve written many times about the User State Migration Tool; it’s surprising to some, but the Directory Services team owns supporting this tool within Microsoft in the United States (our European colleagues wisely made sure the Deployment team owns it there). With Windows 8 Consumer Preview, we released the new tongue twisting Windows Assessment and Deployment Kit for Windows 8 Consumer Preview (Windows ADK), which replaces the old WAIK and contains the updated User State Migration Tool 5.0 (binary version 6.2.8250). The new tool brings a long sought capability to the toolset: corrupt store detection and extraction. There are also various incremental supportability improvements and bug fixes.

Store verification and recovery

USMT 4.0 introduced usmtutils.exe, a simple command line tool that was mainly used to delete hardlink folders in use by some application and no longer removable through normal measures. The new usmtutils.exe now includes two new command-line arguments:
/verify [:reportType] <filePath> [/l:logFile] [/decrypt[:<AlgID>]] [/key:keyString] [/keyfile:fileName]

/extract <filePath> <destinationPath> [/i:<includePattern>] [/e:<excludePattern>] [/l:logFile] [/decrypt[:<AlgID>]] {/key:keyString] | [/keyfile:fileName] [/o]

You use the / verify option after gathering a scanstate compressed store. This checks the store file’s consistency and if it contains corrupted files or a corrupted catalog. It’s just a reporting tool, and it has options for the verbosity of the report as well as the optional encryption key info used to secure a compressed store. In Microsoft experience, hardware issues typically cause corrupt compressed stores, especially when errors are not reported back from USB devices.

You use the /extract option if you want to simply restore certain files, or cannot restore a compressed store with loadstate. For example, you’d use it if the store was later partially corrupted after validation, if loadstate cannot operate normally on a destination computer, or if a user deleted a file shortly after loadstate restoration but before their own backups were run. This new capability can restore files based on patterns (both include and exclude). It doesn’t restore setting or registry data, just files.

Changes in capabilities

USMT also now includes a number of other less sexy - but still important - changes. Here are the high points:

  • Warnings and logging – Scanstate and loadstate now warn you at the console with "…manifests is not present " if they cannot find the replacement and downlevel manifest folders:

USMT also warns about the risks of using the /C option (rather than /VSC combined with ensuring applications are not locking files), and how many units were not migrated:

Remember: you cannot use /vsc with /hardlink migrations. Either you continue to use /C or you figure out why files are in use and stop the underlying issue.

To that point, the log contains line items for each /C skipped file as well as a summary error report at the bottom:

----------------------------- USMT ERROR SUMMARY ------------------------------
* One or more errors were encountered in migration (ordered by first occurence)
| Error Code | Caused Abort | Recurrence | First Occurrence
| 33         | No           | 18         | Read error 33 for D:\foo [bar.pst]. Windows error 33 description: The process cannot access the file because another process has locked a portion of the file.[gle=0x00000012]
18 migration errors would have been fatal if not for /c. See the log for more information

  • Profile scalability – USMT 4.0 can fail to migrate if there are too many profiles and not enough memory. It takes a perfect storm but it’s possible and you would see error: “Close programs to prevent information loss. Your computer is low on memory” during loadstate. USMT 5.0 now honors an environmental variable of:


When set, loadstate trims its memory usage much more aggressively. The consequence of this is slower restoration, so don’t use this switch willy-nilly.

  • Built-in Variables - USMT now supports all of the KNOWNFOLDERID types now. Previously some (such as FOLDERID_Links) were not and required some hacking .

  • Command-line switches – the legacy /ALL switch was removed. The ALL argument was implicit and therefore pointless; it mainly caused issues when people tried to combine it with other arguments.

  • /SF Works - the undocumented /SF switch that used to break things no longer breaks things.

  • Scanstate Administrator requirements – Previously, loadstate required your membership in the Administrators group, but bizarrely, scanstate did not. This was pointless and confusing, as migration does not work correctly without administrative rights. Now they both require it.

  • "Bad" data handling - Certain unexpected file data formats used to lead to errors like "Windows error 4317 description: The operation identifier is not valid". Files with certain strings in alternate data streams would fail with "Windows error 31 description: A device attached to the system is not functioning". USMT handles these scenarios now.

  • NTUSER.DAT load handling - The NTUSER.DAT last modified date no longer changes after you run scanstate, meaning that /UEL now works correctly with repeated migrations .

  • Manifests and UNC paths - Previously, USMT failed to find its manifest folders if you ran scanstate or loadstate through a UNC path. Now it looks in the same folder as the running executable, regardless of that path's form.

  • Orphaned profiles - When USMT cannot load a user profile as described here , it tries 19 more times (waiting 6 seconds between tries) just like USMT 4.0. However, USMT skips any subsequent profiles that fail to load after one attempt. Therefore, no matter how many incorrectly removed profile entries exist, the most delay you can see is 2 minutes.

  • UEL and UE - In USMT 4.0, a /UEL exclusion rule would override the processing of a /UE exclusion rule, even though it was likely that if you were setting UE because you had specific need. USMT now returns to the USMT 3.01 behavior of UE overriding UEL.

USMT 5.0 still works with Windows XP through Windows 7, and adds Windows 8 x86 and AMD64 support as well. All of the old rules around CPU architecture and application migration are unchanged in the beta version (USMT 6.2.8250).

Feedback and Reminder about the Windows 8 Consumer Preview

The place to send issues is the IT Pro TechNet forums . That engages everyone from our side through our main conduits and makes your feedback noticeable. Not all developers are readers of this blog, naturally.

Furthermore, Windows 8 Consumer Preview is a pre-release product and is not officially supported by Microsoft. In general, it is not recommended pre-release products be used in production environments. For more information on the Windows 8 Consumer Preview, read this blog post from the Windows Experience Blog.

Until next time,

Ned “there are lots of new manifests too, but I just couldn’t be bothered” Pyle

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.