Replace Scenario alternative for USMT Migration
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.
Please note the steps below are very SCCM centric as I mostly work with large enterprise customers, but they could be leveraged for Lite Touch deployments as well.
I’ll break out the tasks to get this working into 4 sections:
Section 1: Prepare for the build
Operationally this is the most challenging step after the engineering is complete.
Environmental/Infrastructure Preparations Requirements:
- A build workbench/build center with enough network ports to support the number of systems you want to deploy in a given time is a hard requirement.
- This process is dependent on having both the legacy and new computer on the network at the same time.
- As both computers would be on the network concurrently, validate your DHCP scopes have enough leases to support this.
- Power and Cooling for the workbench/build center must also be taken into consideration.
- In order for the XP system to connect to the new computer, the DNS infrastructure needs to be up to date otherwise the legacy computer will not connect properly to the new computer. In fact you’ll see in the steps below that I tend to take a “trust by verify” approach to confirming I’m connecting to the correct computer.
Associating the new and legacy computer:
Each time a computer is deployed in a Replace Scenario build the relationship to the new computer must be determined and defined. This work is required regardless of whether a State Migration Point is used (thus required Computer Association) or a manual approach is taken (take USB Storage Device from computer A to computer B). This work isn’t new but how it done is bit different than the other approaches.
The key to redirecting where USMT captures data and where it restores it from is based on the Variable OSDStateStorePath which both Capture and Restore steps in SCCM Task Sequences can leverage to determine where to save and restore USMT Data. The variable is also used by MDT’s ZTIUserState.wsf and ZTIBackup.wsf scripts so WIM backups and Lite touch deployments can leverage it as well.
Example for the additional steps describe below:
Let’s say you’ve determined a computer named “Desktop1XP” will be your legacy computer to be replaced by a new computer called “Laptop1-W7”. You will now need to setup computer variables. This could be done via an MDT Database (thus getting pulled in via a Gather step) or in SCCM by a computer variable put directly on the computer. Mass importation of variables/computer creation is possible via the SCCM SDK, but that is a topic probably better left for another blog posting.
For Laptop1-W7 a computer variable named LegacyComputer with a value of “Desktop1XP” should be created. This will be leveraged at multiple points for validation and preparation purposes.
For Desktop1XP a computer variable named NewComputer with a value of “Laptop1-W7” should be created. This will be used to send USMT data to the new computer.
Section 2: Update your build computer task sequence
In your Deploy Windows 7 task sequence at the end of the build process, or as close to the end as possible add a group step for the new steps to prepare the new computer to accept USMT data. This should be at the end of the build because if the build fails and you are planning to rebuild the system you don’t want the capture process to potentially see the computer on the network and start the capture to a system you are planning to rebuild anyway or multiple additional reboots for things like application install requirements will occur before the build is complete which could break your USMT capture.
Steps to add:
Step 1: Run Command Line Step
Command: cmd.exe /c md c:\USMT
Rational: Create the Directory to keep the USMT Data
Step 2: Run Command Line Step:
Command: net share USMT$=c:\USMT /grant:%DomainName%\%LegacyComputer%$,Change
Rational: Set Permissions so only the legacy computer account has rights to access the share. Note this assumes the computer is domain joined. If it isn’t then this will fail.
Step 3: Run Command Line Step:
Command: cmd /c copy %_SMSTSLogPath%\smsts.log c:\USMT\%OSDComputerName%-%LegacyComputer%.log
Rational: This is an inelegant solution to providing for validation checking and allows techs to easily see the computer relationship without SCCM access for troubleshooting.
Other considerations:
- If the new computers have multiple hard drives you may want to configure your build scripts to put the user data on a drive other than C. If that is the case Section 3 and 4 will need updates to support that as well.
- You may want to add additional permissions to the share so that administrator can access the share to testing/troubleshooting purposes.
Section 3: Update your Capture USMT task sequence
There are a few steps you would need to add to the task sequence you use to capture USMT data from the legacy computer. These steps are both for validation and redirecting USMT to save directly to the new computer.
Steps to add at the top of your task sequence:
Step 1: Set Variable Step
Command: OSDStateStorePath=\\%NewComputer%\USMT$
Rational: Set Variable for OSDStateStorePath to be used USMT Capture Process and validation step below.
Step 2: Run Command Line Step
Command: cmd /c copy %_SMSTSLogPath%\smsts.log %OSDStateStorePath%\2-USMT-Validation_successful_%_SMSTSMachineName%.log
Rational: Validate that new computer is on the network, name resolution is working correctly and permissions were setup correctly on the new system.
Steps to add after the USMT Capture steps:
Step 1: Run Command Line Step
Command: cmd /c copy %_SMSTSLogPath%\scanstate.log %OSDStateStorePath%\scanstate-%OSDComputerName%.log
Rational: Puts the scanstate log file onto the new computer for future review and as a marker that the USMT capture has completed successfully.
Other considerations:
Sometimes to ensure better results for USMT captures the following additional steps after the validation step and before USMT Capture are completed should be run:
- Run Command Line Step: FSUTIL dirty set c:
- Reboot to OS
The FSUtil step tells the OS to do a chkdsk on reboot. By doing this and rebooting the computer, issues which can cause Scanstate failures/skipping of files such as memory fragmentation, fix disk corruption issues and applications locking files are avoided.
Section 4: Updates for USMT Restore
The following steps can be added into the build under two different methods:
- Run as a separate task sequence that just does USMT Restore steps. I generally create this by taking a standard MDT build template task sequence and removing all the sections above State Restore and removing most steps within State Restore which are not related to USMT (minus things like Gather and Use Toolkit Package). This can be beneficial if as part of your deployment process you build a lot of computers ahead of time and want to put systems back on the network closer to the migration time to get USMT data.
- As part of the build task sequence if you can code a loop waiting for the existence of the scanstate-%OSDComputerName%.log file you could eliminate the need for another task sequence entirely. I haven’t provided code for this, but it is very possible. Note: for this approach to work the new computer would need to stay on from the time of build to the after the capture and the task sequence should be set to unknown/unlimited run time (so it will not time out).
Steps to add before the USMT Restore Task Sequence Steps:
Step 1: Run Command Line Step
Command: cmd.exe /c copy c:\usmt\scanstate-%LegacyComputer%.log c:\usmt\starting_loadstate.log
Rational: Validates that USMT Capture has completed successfully.
Step 2: Set Variable Step
Command: OSDStateStorePath=c:\USMT
Rational: Set Variable for OSDStateStorePath to be used USMT restore process
Steps to add after the USMT Restore Task Sequence Steps:
Step 1: Run Command Line Step
Command: net share usmt$ /Delete
Rational: remove share no longer needed.
With all of this in place USMT data in a Replace scenario can be done without a State Migration Point or manual processing.
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use
This post was contributed by Andres Springborn, a Senior Consultant with Microsoft Services - U.S. West Region .