User State Without SMP

For refresh scenarios, leaving data in place is preferred because it avoids the overhead of transferring any content across the network. There are two ways to do this, based on the new OS deployed to the system and the version of USMT used:

• Hard-link: Hard-link migration can be used only if using USMT 4.0 and the new OS is Windows 7 (initial OS does not matter). Hard-link migration takes advantage of advanced features of the NTFS file system that allow files to physically remain in-place and intact even after the drive is wiped (not formatted). When restored, pointers to the files are restored, so the files never physically have to be copied or moved anywhere.
  To use hard-linking, select the Capture locally by using links instead of copying files option in the Capture User State task.
• File copy: If hard-linking is not selected, the traditional file copy method for storing user state is used. This method must be used if the OS you restore to is Windows XP or you use USMT 3.0. This file copy method literally copies all identified user state data to an alternative location on the hard-drive requiring extra disk space and extra time to complete the copy.

For either scenario, you must also set the OSDStateStorePath task sequence variable to a local path on the system. For hard linking, the recommended path is % SystemDrive %\ UserState. For file copy, the recommended path is the value of the built-in task sequence variable _SMSTSUserStatePath. Also, be sure you do not use a Format and Partition task during the task sequence because this wipes out the state store. If you build a task sequence using the Create New Task Sequence Wizard, all this is done for you. Because hard-linking is much quicker than having to physically bundle and copy all the captured user state to another location on the drive and does not require the extra necessary free space to do so, it is the preferred method for maintaining user state in refresh scenario deployments.

Although using an SMP is preferred for replace scenarios because of its self-cleanup and automatic encryption of state data, it may not always be ideal for one or more of the following reasons (although other reasons to not use an SMP are also possible):

• Lack of a local site server or sufficient storage space on a local site server.
• Using a local NAS or USB drive is preferred.
• Transferring user state data twice (once from the source to the SMP and once from the SMP to the destination) is undesirable because of the extra time involved.
• The destination system in a replace scenario is not available or known at the time the computer association is created.

For all these scenarios, you can use a simple SMB file share instead of an SMP-of course, you will have to manually clean up the share, organize it, and maintain encryption keys. To do so, set the OSDStateStorePath task sequence variable to your custom location and only use the Capture User State and Restore User State tasks. For best results, set OSDStateStorePath to a path determined at run time. For example, you could use a Set Task Sequence task to set OSDStateStorePath to \\< servername > \< share >\% OSDComputerName %. This would cause USMT to create a subfolder in the share specified named for the current system when capturing data and store the captured user data there. You would then have to store this path somewhere (in an external file or database) or prompt the interactive user to choose a source computer to restore from when it is time to restore the data.

Another advanced approach is to prompt the interactive user for a destination computer and populate OSDStateStorePath with a path on the destination system, bypassing the use of an intermediary file share altogether.