We can use System Center 2012 Configuration Manager task sequences to capture and restore the user state data in operating system deployment scenarios where you want to retain the user state of the current operating system.
USMT can capture users’ Operating System settings, Application Settings and Personal Files before the OS deployment. After Windows installation finishes, USMT can load these settings and files during Task Sequence.
Computer Refresh: The computer might be an existing computer in your organization and you might want to reinstall windows on the same computer. This approach is named as Computer Refresh.
Computer Replace: The computer might be an existing computer in your organization and you might want to replace this old pc with a new computer. This approach is named as Computer Replace. You need to set up Computer Association on SCCM Console when implementing Computer Replace.
USMT uses migration xml files to capture and restore the user profiles, application settings and operating system components. The below links give detailed info about migration xml files and what usmt migrates.
https://docs.microsoft.com/tr-tr/windows/deployment/usmt/usmt-what-does-usmt-migrate
Methods for Storing User State:
1. State Migration Point:
We can store user state data on State Migration Point. The file we migrate and keep on SMP is encrypted to secure user’s data. You can see this in smsts.log on the client machine.
I’ve already written an article about how to configure state point migration role in the past.
2. Local Disk:
We can store user state data on local hard drive. This method does not use encryption and saves the migration file (USMT.MIG) under c:\_smstasksequence\UserState\USMT folder by default. If you are using this method, you should not partition and format the disk because local disk contains the user state.
3. Local Disk Hard Linking:
This method uses same path to store user state as Local Disk method which is c:\_smstasksequence\UserState\USMT folder but instead of creating a single USMT.MIG file, it creates catalog.mig and hard link information. Hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs.
You may be asking, what is the difference between Local Disk and HardLink Method. Local disk method copies everyfile to be migrated to the migration store however Hard Linking creates a hard link in migration store for everyfile to be migrated.
4. Offline: You can capture user state during the WinPE (even while windows is not running). By using this method, we can avoid conflicts where a file is in use by another application or service. I am going to explain how to create Task Sequences for each of these scenarios in the following posts.