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.
Attached to this blog post are the Task Sequence templates for my previous post on ConfigMgr and USMT, using a UNC path. These templates can be used with USMT4 as well, just make sure to chose a USMT 4 package for the Capture User State/Restore User State task sequence steps.
In addition, I’ve attached 2 other templates I’ve created.
One is for doing a USMT capture to the State Migration Point (SMP). (Based upon the MDT replace template)
The last one is for doing a USMT capture to the SMP, backing up the computer to a .wim and then optionally wiping the disk. (Based upon the MDT replace template)
If you want to wipe the disk, just enable the disabled TS step “Set WipeDisk to TRUE”