Replace Scenario alternative for USMT Migration

Fantastic post over on The Deployment Guys blog about using USMT in a Replace scenario. 

Read the full post here.

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.


Leave a Reply