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:
A thread on the MDTOSD mailing list hosted by http://www.myitforum.com website was talking about how some user state data, such as PST files that Outlook has opened, could be lost during the user state migration process. This reminded me of some new functionality coming in MDT 2012 Update 1 Beta 1. Yes, that hasn’t released yet, but it’s worth discussing now anyway because users of MDT 2010 and MDT 2012 can benefit from some of the same changes.
Fantastic post over on The Deployment Guys blog about using USMT in a Replace scenario.
While USMT 4.0 in a Refresh Scenario provides some great advance by using Hardlinking in a Replace Scenario customers still face multiple operational challenges and potential capital costs during large scale deployments because user data needs to make its way from the legacy computer to the new computer. Managing that data and its transfer can be an expensive task.
System Center Configuration Manager does provide some help in Replace Scenarios with their State Migration Point role, but with that approach comes several operational and hardware requirements. In the short term, when managing an enterprise wide migration of a desktop operating system, as many customers are facing with Windows 7, the state migration point can potentially become a bottleneck during the migration. There is a need for more storage capacity for USMT Data on the server. Without it only so many migrations can be run at any one time. There may be additional disk subsystem IO performance requirements as well which if not addressed could slow capture and restore of USMT data. The data also needs to be transferred twice over the network which costs additional time and could make the NIC of the SMP server a potential bottleneck. In remote offices transferring USMT data over WAN links would also potentially slow down network links impacting other business functions and increasing the time a given migrations may take. Managing and tracking all of these risks is one more thing IT admins have to take into account for a migration.
Some alternative approaches that enterprises use is a more manual method where a technician uses either Easy Transfer or USMT’s core tools, Scanstate.exe and Loadstate.exe, with a USB hard drive/stick to ports the user data from the legacy computer to the new one. Those approaches do work, though operationally they can be very labor intensive and thus does not scale well when an organization is facing hundreds if not thousands of systems to migrate.
There is a third approach to consider. Both Scanstate.exe and Loadstate.exe, the core utilities for USMT have input parameters for where to save and restore data. Using that functionality, data could be captured from the legacy OS and saved directly to the new computer over the network. The benefits to this are numerous. It would defuse the network and Disk IO load across many more computers and each of their NICS and hard drives thus avoiding potential bottlenecks of a centralized server. USMT data would only have to be moved once across the network. The process could still be zero touch without the need for any manual processes beyond delivering the new computer to the end user’s desk. There would be no need to purchase additional storage or manage it for state migration points. This isn’t to say there are no costs associated with the approach, but that the engineering and infrastructure required to make it happen should be weighed carefully against other options. For some organizations this approach does make sense and if so you’ll be interested in the processes I have outlined below to make this work.
Deployment Master Michael Niehaus has a few new posts from his adventures at TechEd New Zealand. He even used Angry Birds for an example, very cool!
Out of the box, USMT 4.0 migrates settings for Windows, Office, and various other applications (typically current versions as of 2009), mostly consumer-focused. (See http://technet.microsoft.com/en-us/library/dd560792(WS.10).aspx for the full list.) So what if you want to migrate settings from additional applications? Well, then you need to author your own migration XML file.
One of the questions that came up after my TechEd New Zealand session on USMT 4.0 was whether USMT migrated the contents of the client-side cache (CSC) used for offline files. Well, it sounds like it “sort of” does – but by default, it only moves the “dirty” files (those not yet sync’d to the network location). That’s a decent default I suppose, as the remaining files can be pulled back from the network after the state is restored, and the modified files won’t be overwritten. So there’s no data loss (always a good thing), but there will be extra network traffic to pull the content down to the cache again.
Andrew Barnes has created a really great post explaining USMT for MDT LTI.
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.
Michael Petersen has a really nice post on USMT 4, Hardlink and Bitlocker over on his blog.
I’m often asked if its possible to use the USMT 4.0 hardlinking (keep backup file on the OS Disk), in combination with bitlocker..
I guess the reason for the question is, that one might think!
- How can I do a backup of a machine, and keep the files on the encrypted drive, and then be able to reinstall that same drive with a new OS, ginning access to the backup that was on the encrypted drive?
- How do I stage WinPE on the Bitlocked disk, and then gain access to that same disk for the OS installation part when inside WinPE.Or at least something like that?
The thing is, that not only is it possible, it will also save you the time it takes to encrypt the drive again, because, even though a new OS is applied to the disk, the encryption is still in effect…
Fix: Unable to delete the OSDStateStorePath folder in an OSD Task Sequence using USMT 4.0 with Hard Links in ConfigMgr 2007
Read the original post here, contributed by:
Clifton Hughes | Senior System Center Support Engineer
When using Hard Links for User State Migration, attempting to remove the OSDStateStorePath folder after restoring the users data in a Task Sequence may fail or appear to hang.
Note: This is in reference to the steps listed in this article: http://technet.microsoft.com/en-us/library/ee344267.aspx
The command .\%PROCESSOR_ARCHITECTURE%\usmtutils.exe /rd %OSDStateStorePath% may appear to hang unless you configure a timeout value on the Run Command Line step, and/or it may fail with one of the following errors or warnings depending on how the Task Sequence Advertisement is configured:
SMSTS.log may show one of the following errors or warnings.
Warning: This command is going to delete the following list of path(s).
Please review before continuing…
Are you sure you want to proceed (Y/N)?
If you do not configure a timeout value, it will hang at this point, however, since you cannot see the prompt for user input you cannot continue.
Or, if you configure a timeout value on the Run Command Line step, you may see this error in the SMSTS.log
This operation returned because the timeout period expired. (Error: 800705B4; Source: Windows)
The amount of detail you see in the log will also depend on how you have configured the Advertisement for the Task Sequence. If the Advertisement is configured to Download content locally when needed by running the task sequence (commonly referred to as Download and run locally) then you will not see as much detail on the command line being run. However, if you select Access content directly from a distribution point when needed by the running task sequence (commonly referred to as Run from DP), then you will get more details on the command line being run, and it may show the prompt "Are you sure you want to proceed (Y/N)?" in the SMSTS.log. If you tried adding the cmd.exe /c echo Y | in front of the command and still try to use the Run from DP option, the command will fail with a Path not found error.
There are two things we are trying to overcome with this issue when running the USMTUTILS.EXE command from a ConfigMgr 2007 OS Deployment Task Sequence:
1. This command requires user input in order to delete the OSDStateStorePath folder and does not seem to support any command line switches to bypass this prompt.
2. Although we are able to use the echo command to pass the Y for yes to the command line step using cmd.exe /c echo Y | "command", this will only work if the Advertisement is configured to Download content locally when needed by running the task sequence (commonly referred to as Download and run locally). If you select Access content directly from a distribution point when needed by the running task sequence (commonly referred to as Run from DP) this step will fail. This is due to the echo command we are needed to pass, it is a built in command in the command interpreter, cmd.exe, so that is why we must specify the cmd.exe /c in the beginning of the command line, as this is not present in the package on the DP.
Note: This will only work if the Advertisement is configured to Download content locally when needed by the running task sequence (commonly referred to as Download and run locally). If you select Access content directly from a distribution point when needed by the running task sequence (commonly referred to as Run from DP) this step will fail. This is because the echo command we need to pass is a built in command in the command interpreter, cmd.exe, We must specify the cmd.exe /c in the beginning of the command line since this is not present in the package on the DP.
NOTE: Data Loss Warning, do not select Continue on error on the Restore User Files and Settings! It is also important to not select “Continue on error” on the Options tab, or “Continue if some files cannot be restored” on the “Properties” tab of the “Restore User Files and Settings” task sequence step, Selecting these options will allow the next task sequence step to delete the User Files and Settings even if they are not successfully restored.
This resolution assumes you have already successfully configured and tested an OS Deployment with ConfigMgr 2007 SP2 using Hard Links with USMT 4.0 . If not, follow the steps to configure the OSDStateStorePath, OSDMigrateAdditionalCaptureOptions, and OSDMigrateAdditionalRestoreOptions variables for using Hard Links with USMT 4.0 in ConfigMgr 2007 SP2:
To add a step that should successfully remove the User State folder after the User Files and Settings are restored, follow these steps:
1. In the Task Sequence Editor, after the Restore User State step, click Add, navigate to General, and then click Run Command Line action. Type the following in the Run Command Line action:
2. Type the following in the Command line field:
cmd.exe /c echo Y | ".\%PROCESSOR_ARCHITECTURE%\usmtutils.exe" /rd "%OSDStateStorePath%"
3. Select the Package check box.
4. In the Select a Package dialog box, browse to the USMT 4.0 package, and then click OK.
Although we are able to use the echo command to pass the Y for yes to the command line step using the command line step:
cmd.exe /c echo Y | ".\%PROCESSOR_ARCHITECTURE%\usmtutils.exe" /rd "%OSDStateStorePath%"
Ned has a great post I found this week over on the Directory Services Team Blog. Working with USMT XML files can be frustrating and you always wonder if your syntax is correct. Ned has a nice walkthrough on to use Visual Studio Express (free) to verify your syntax.
Here is a snippet:
Ned here again. XML is used to configure all aspects of USMT 4.0 migration and is especially important when customizing. Unfortunately most IT staffers are not familiar with XML – why should they be? It’s barely used within Windows and is mainly an applications-specific file store. Maybe you noticed that group policy ADMX files are XML – did you care, since you were using the GP editor to make changes?
Unfortunately, there’s no USMT XML editor. What’s more, XML follows programming conventions– tags must be closed; nesting must be complete; rules are case-sensitive. And any mistake in the XML will cause the migration to fail or skip crucial steps.
XML, like any programming file format, has rules. This means that there are tools that can examine that file and see if the rules are being broken – programmers are not super human. One such tool is Visual Studio 2008 Express. It has an excellent suite of XML authoring and validation options – and it’s free :).
Let’s come up with a scenario that requires custom XML, create our file, and then validate it.
Was recently working on a custom.xml for a client with USMT 4.0 and was struggling with getting my exclusions to work. My syntax appeared to be correct, however it wasn’t excluding the music file extensions I had created like it was supposed to. It was excluding them on the drive, but not on the desktop where I had placed some files to test.
After some searching, I came across this great blog post:
After reading through that post, I realized I had the incorrect syntax in my custom.xml. My context was set to context=”System” instead of context=”UserAndSystem”, doh! After making that change and testing, I finally got the behavior I was expecting. Mind the details!
So be sure to read the above link for the following issues.
Common cause 1: Your XML uses exclude and not unconditionalExclude
Common cause 2: You have set unconditionalExclude in the wrong context
Common cause 3: You have not correctly provided the case for unconditionalExclude
Microsoft has created an update for USMT 4.0 that adds support for Office 2010. USMT 4.0 migrations of Office 2010 are now supported .
You can get the update here: http://support.microsoft.com/kb/2023591
Here are some things you should be aware of:
- Certain settings and customizations in MS Word won’t migrate from any version to Word 2010, because of with the way Word is designed and how data is stored in “HKEY_CURRENT_USER\software\Microsoft\Office\<OfficeVersion>\Word\Data".
- Many Office settings (across all Office apps) won’t migrate when going from 32-bit Office to 64-bit Office. This is due to the way that the settings are stored in 64-bit Office installations.
- If you’ve launched Office on the destination PC as a user before doing the migration of that user’s profile, most of your settings won’t migrate. This happens because Office relies on some code that only runs the first time that an Office app is launched to migrate settings.
- This update isn’t a magic bullet. You may still need to do some customization to make USMT fit your particular configuration.
The update also fixes a couple of issues around hard-link migration performance when copying a folder with a huge number of files and an issue that affected certain time zones.
Also Michael Niehaus has a blog about the release of this KB that are of note.
A new hotfix for USMT 4.0 was released today to support migrating Office 2010 settings. (It includes other fixes too.) You may want to download this and integrate it into your deployment processes. The full instructions for doing this (including what needs to be done with MDT and ConfigMgr) are included in the KB:
There is one complication that you should be aware of if you are using ConfigMgr and moving from Windows XP or deploying Windows XP. USMT 4.0 uses a set of manifest files to determine what needs to be migrated from Windows XP. These manifest files are stored in the “DLManifests” folder, which is part of your USMT package in ConfigMgr. There is an issue though where Scanstate.exe can’t find this DLManifests folder when run from ConfigMgr. In MDT 2010 Update 1, we included a workaround for this, copying the folder where Scanstate can find it:
‘ Workaround for USMT bug in Windows 7 AIK
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" then
oUtility.RunWithHeartbeat "cmd.exe /c xcopy /iesryhd """ & sUSMTPath &"\DlManifests"" """ & oEnv("SystemRoot") & "\system32\DlManifests" &""" 1>> " & oLogging.LogPath &"\zticopyUSMT.txt 2>>&1 "
Notice that this checks specifically for build 6.1.7600.16385 of Scanstate.exe, the version released in the Windows 7 version of Windows AIK, as we expected this problem to be fixed in the next version of USMT. Well, it wasn’t. But once you install the KB 2023591 hotfix, the version changes to 6.1.7601.21645 and our fix stops working.
You can work around this by fixing the fix, to read like this:
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and (oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" or oFSO.GetFileVersion(sFoundScanState) = "6.1.7601.21645") then
If you aren’t using ConfigMgr or don’t have Windows XP around any more, you won’t need to worry about this.