In order to automate the User State Capture and Restore task sequence steps in MDT 2010 you will need to configure your deployment share so it knows where to store the data. MDT 2010 installs the User State Migration Tool for usage prior to capture and restore tasks.
If you’re currently using Windows Easy transfer to migrate user settings and files during deployments then this post will help you to advance to the next level using the User State Migration Tool in MDT 2010.
This first example tells MDT to try to determine where to store the data. If there is enough space it will store it locally utilising the hardlinks feature:
This example shows a User State Migration using a network share:
UserDataLocation=NETWORK UDShare=\\SRV01\MigData$ UDDir=%OSDComputerName%
To skip the Lite-Touch wizard pages Specify whether to capture an image and Specify whether to restore user data enter this property in your customsettings.ini file:
After using the settings above, MDT is able to automate User State Migrations to the locations you have configured using the power of the ZTIUserState.wsf script.
Now, that takes care of the where but there’s still the matter of what. In the real world you will want control over the data that you migrate so read on for the advance bit.
Firstly the task sequence step Generate Application Migration File runs the script ZTIAppXmlGen.wsf with the /capture switch. It creates a file called ZTIAppXmlGen.xml which contains a list of all the extra file extensions on the machine. This will be used later by scanstate.exe to target new file types.
Next, the task sequence step Capture User State is run. It uses the ZTIUserState.wsf script with the /Capture switch to leverage the Scanstate.exe tool from the USMT to capture the user state data.
Finally, after the new OS is laid down, the task sequence step Restore User State is run. This step uses the ZTIUserState.wsf script with the /Restore switch to leverage Loadstate.exe to restore the captured user state data.
For those who need to know more about USMT, I suggest watching this webcast series, for all others continue reading.
There’s an extra switch in the ZTIUserState.wsf script. /Estimate generates a log file called USMTEstimate.log. This is used for capacity planning your migrations.
You may want to capture specific user profiles, in which case you can use the UDProfiles property in your customsettings.ini to list the user profiles. This is an example:
UDProfiles=Administrator, Scriptimus, User2, User3
If you’ve created customised XML files that surgically target your data you can use them in your migrations by using the USMTMigFiles property to call them in your customsettings.ini. They need to be sequentially numbered like in the example below:
USMTMigFiles001=MigApp.xml USMTMigFiles002=MigUser.xml USMTMigFiles003=MigSys.xml USMTMigFiles004=MigCustom.xml
If you’ve created a custom Config.xml using scanstate.exe to limit which files are migrated then you can use this custom XML file by using the USMTConfigFile property:
Finally, you can use ScanStateArgs and LoadStateArgs to customise the way that USMT is run during the migration process.
ScanStateArgs=/v:5 /o /c
The /v switch in the above example tells scanstate.exe to increase the level detail in your log files (0-15 are the options). The /o switch will overwrite any data in the target migration store as opposed to just returning an error and stopping. The /c Switch will continue on errors unless something really really bad happens.
This is an example of LoadStateArgs usage:
LoadStateArgs=/v:5 /c /lac
It’s the same as ScanStateArgs except for the /lac switch which tells Loadstate.exe that if it’s migrating a local account and it doesn’t exist on the target computer then it should disable it after creation.
Below is a list of resources for the User State Migration Tool.
My final words are only to say the User State Migration Tool is a powerful way of controlling your large scale enterprise migrations and more imporantly. . .it’s free!