Using USMT for User State Migration in ConfigMgr OSD (2026 Guide)

— it still works on the same ScanState/LoadState pair, driven by the same MigApp.xml/MigUser.xml/MigDocs.xml rule files — but it now ships as part of the current Windows ADK rather than a separate download, and the ConfigMgr task sequence steps that wrap it are largely unchanged in current ConfigMgr (formerly SCCM/MECM) releases.

Getting the current USMT

USMT is included in the Windows ADK, not distributed separately anymore. Install the ADK matching your ConfigMgr version (check the ADK’s release notes against your current ConfigMgr build for the supported pairing) with the User State Migration Tool (USMT) feature selected during ADK setup. ConfigMgr’s task sequence editor picks up the USMT package location automatically once it’s referenced in a User State Migration Tool for Windows package pointing at the ADK’s USMT folder.

The task sequence structure

A standard refresh (in-place reimage of the same machine, keeping user data) task sequence uses two steps:

1. Capture User State — placed before the OS image apply steps, this runs ScanState and stores the captured state either to a state migration point (a ConfigMgr site role) or a local hard-link path.
2. Restore User State — placed after the OS is installed and the client is reinstalled, this runs LoadState to bring the captured data back.

Both steps reference the same USMT package and, typically, the same rules — customise which files/settings get migrated by editing MigUser.xml (documents and user folders) and MigApp.xml (per-application settings) referenced by the step, or supply a custom .xml for anything not covered by the defaults.

Hard-link migration (same-machine refresh, no network needed)

For a same-machine refresh — the far more common scenario now than a wipe-and-load to different hardware — hard-link migration avoids copying the user’s data across the network entirely. Enable it in the Capture User State step by selecting Capture and restore locally by using links (or setting /hardlink /nocompress if you’re calling the tool directly rather than through the task sequence UI). This makes the capture near-instant and skips needing a state migration point.

Common failures

• ScanState error 27 (insufficient disk space): hard-link migration still needs headroom to build the link table — if the disk is genuinely nearly full, hard-link mode can’t help; free up space or fall back to a network state store.
• LoadState fails to find the captured store: usually a mismatched or expired Capture User State step configuration — hard-link stores are tied to the specific disk/volume, so if the task sequence reformats or replaces the disk (rather than a true in-place refresh) between capture and restore, the hard-link store is gone. Use a state migration point instead for scenarios involving a disk wipe.
• Missing application settings after restore: MigApp.xml only migrates settings for apps it has rules for — a newer application version than USMT’s built-in rules expect can silently skip settings it doesn’t recognize. Check the current ADK’s release notes for which app versions its MigApp.xml explicitly supports, and write a custom migration .xml for anything critical that’s missing.

Verifying a migration

Both ScanState and LoadState write detailed logs (scanstate.log, loadstate.log) to the location specified in the task sequence step, or to %WINDIR%\CCM\Logs\SMSTSLog\ alongside the rest of the task sequence logs if you didn’t set a custom path — check the summary lines at the end of each for a count of migrated files/settings and any skipped items before considering the migration verified.