I’ve had several people contact me asking if I had new templates for ConfigMgr 2012 for my popular USMT to UNC posts I’ve done in the past. I’ve cleaned up the process quite a bit over the years and here is what I’ve been using with clients lately. In this blog post I will explain how I configure my Task Sequences to capture to a network location and I will provide links for the templates you can download.
There are many times where capturing/restoring USMT to a network share fits into the workflow better than using the built in State Migration Point (SMP). The SMP is encrypted, which is a good thing, but can cause issues for swapping data between devices. You are also required to create computer associations before you do a capture, which some times people forget to do. So an easy solution is to simply capture USMT to a network share instead. This process can be configured to dynamically move to different servers for different locations without much difficulty but I won’t be discussing that in this post.
The first thing I do in the Task Sequence is create a Set Variables group where we can set a few properties to be used in the Task Sequence.
The first variable we set is a ServerA property. This is the name if the server you want to capture the data up to. This step is conditioned to only run if the ServerA value is not already defined. If you are using MDT integration, you can define the ServerA value dynamically using the Database. This is commonly used to account for different geographical locations.
The second step we use to define the MigData variable. We take the ServerA value and create the path with the built-in OSDComputerName variable available to the Task Sequence.
The third step in the Set Variables section we use to set the OSDStateStorePath variable which is what USMT will actually use. We use this value so we can use the built-in USMT steps in the Task Sequence.
Capture User State
The USMT Capture section is made up of 3 steps.
The first step creates the directory in the targeted OSDStateStorePath location. This ensures the folder for the computer name exists. If the folder doesn’t exist, we can’t dump the user state data to it. This step is conditioned to continue on error, if the folder already exists, then the step will error out.
The second step is optional, but is an example of how you would pass additional parameters to the built-in Capture User State step. In the templates, I’m doing a /uel:90, which excludes all accounts older than 90 days. We do this using the variable OSDMigrateAdditionalCaptureOptions.
The third and final step in the USMT capture group is the default Capture User State step. You can customize which XML’s you want to use and the step will automatically process the values we have set previously.
Restore User State
One of the big advantages of using a process like this to capture user state is that we are dumping the data to a network share. If you are using the templates I’ve provided or created a similar process using the steps in this blog post, then User State will automatically be restored whenever a matching folder name is found. No association is required, if we can find data in the OSDStateStorePath then we will restore it.
The USMT Restore process also consists of 3 steps.
The first step simply sets our OSDStateStorePath variable again.
The second step configured additional restore options. In the templates/example, I’ve used a /ue:%computername%\* which excludes all local accounts from being restored.
The third and final step again simply uses the built in Restore User Step. This will use the OSDStateStorePath variable we’ve set and the OSDMigrateAdditionalRestoreOptions values together with however you have chosen to configure the Restore User State Step.
The first template I’ve created is for a stock ConfigMgr Task Sequence without MDT Integration. This has all the steps I’ve discussed configured for you, with explanations of what each step is doing.
These templates were created on a ConfigMgr 2012 SP1 lab environment, I don’t believe you can import these into a RTM site without issues.
If you are not going to use the templates I’ve provided, then you will need to configure your Task Sequence using the logic I discussed in this blog post and you will need to disable/remove all existing Request/Release/Move State Store steps in the Task Sequence. Those are used to work with the SMP and we won’t be needing those.
The second template is configured for a MDT integrated Task Sequence.
Download the Templates here: