Suppose you want to use the USMT 4 feature of hardlinking in a System Center Configuration Manager 2007 Task Sequence, but you notice that the "Capture User State"/"Capture User Files and Settings" and "Restore User State"/"Restore User Files and Settings" tasks do not have any options to perform a local capture with hardlinking. What's up with that?
Well what's going on is that USMT 4, which introduced hardlinking, shipped after ConfigMgr 2007 so the hardlinking option was not available in ConfigMgr 2007. However, USMT 4 support was added in ConfigMgr 2007 SP2, and via the OSDMigrateAdditionalCaptureOptions and OSDMigrateAdditionalRestoreOptions variables, a hardlink user migration can be accomplished in a ConfigMgr 2007 SP2 Task Sequence.
Out of the box, ConfigMgr 2007 SP2 only supports USMT 4 online captures, or captures that take place while in the full Windows OS. ConfigMgr 2007 SP2 does not support USMT 4 offline captures, or captures that take place while in WinPE. Offline captures are possible using the UDI feature of MDT 2010 Update 1 when it is integrated with ConfigMgr 2007 SP2.
With that said, there are several ways that a USMT 4 hardlink migration can be accomplished in a ConfigMgr 2007 Task Sequence, including:
Since USMT 4 support was not added until SP2 of ConfigMgr 2007, SP2 of ConfigMgr 2007 is required for hardlinking.
USMT 4 is supported in the following refresh scenarios:
USMT 4 is not supported for Windows XP --> Windows XP scenarios.
The first step is to ensure that the USMT 4 package is created:
Create the USMT 4 Package
When ConfigMgr 2007 SP2 is installed on the site server, the Windows Automated Installation Kit 2.0 (WAIK 2.0) is automatically installed. USMT 4 is part of WAIK 2.0 and its binaries can be found within the WAIK 2.0 installation folder.
Notes:
After creating the USMT 4 package, select the method below to enable USMT 4 hardlinking in a Task Sequence.
Method 1: Create a new ConfigMgr 2007 Task Sequence that supports USMT 4 hardlinking
Please make sure to look at the notes section at the end of this post for detailed explanations on some of the above actions.
Method 2: Modify an existing ConfigMgr 2007 Task Sequence that has the "Capture User State" and "Restore User State" tasks in it
If a ConfigMgr 2007 Task Sequence that was used with USMT 3 or USMT 4 exists and was setup for either network capture with a State Migration Point (SMP) or for local capture on the hard drive without hardlinking, it can be modified to support USMT 4 local capture with hard linking.
The below instructions assume that there is already a "Capture User State"/"Capture User Files and Settings" and "Restore User State"/"Restore User Files and Settings" tasks in the appropriate spots in the Task Sequence. If these tasks do no already exist in the Task Sequence, it is recommended to create a new Task Sequence using the method detailed above.
The below instructions are also not valid for a ConfigMgr 2007 Task Sequence that was created using the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard. Please see the section "More Information" for additional information regarding Task Sequences created using the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard:
Notes on the two above methods:
The protected folders that are not deleted include the Task Sequence cache folder and the State Store folder. The Task Sequence cache folder path is stored in the variables _SMSTSMDataPath , _SMSTSClientCache, and _SMSTSNewClientCachePathToCleanup and usually resolves to the path C:\_SMSTaskSequence. The State Store path is stored in the variable OSDStateStorePath. The protected folders that will not be wiped are stored in the variable _SMSTSProtectedPaths. In the SMSTS.log you will see the recursive delete and wipe process logged as something similar to the following: Wiping C:\ ApplyOperatingSystem Set "C:\_SMSTaskSequence" to not be wiped ApplyOperatingSystem Set "%OSDStateStorePath%" to not be wiped ApplyOperatingSystem Set "%_SMSTSClientCache%" to not be wiped ApplyOperatingSystem Set "%_SMSTSNewClientCachePathToCleanup%" to not be wiped ApplyOperatingSystem Skipping C:\_SMSTaskSequence for wipe ApplyOperatingSystem Calculating expected free space. ApplyOperatingSystem Reporting deletion progress. ApplyOperatingSystem Successfully wiped C:\ ApplyOperatingSystem
The protected folders that are not deleted include the Task Sequence cache folder and the State Store folder. The Task Sequence cache folder path is stored in the variables _SMSTSMDataPath , _SMSTSClientCache, and _SMSTSNewClientCachePathToCleanup and usually resolves to the path C:\_SMSTaskSequence. The State Store path is stored in the variable OSDStateStorePath. The protected folders that will not be wiped are stored in the variable _SMSTSProtectedPaths.
In the SMSTS.log you will see the recursive delete and wipe process logged as something similar to the following:
Wiping C:\ ApplyOperatingSystem Set "C:\_SMSTaskSequence" to not be wiped ApplyOperatingSystem Set "%OSDStateStorePath%" to not be wiped ApplyOperatingSystem Set "%_SMSTSClientCache%" to not be wiped ApplyOperatingSystem Set "%_SMSTSNewClientCachePathToCleanup%" to not be wiped ApplyOperatingSystem Skipping C:\_SMSTaskSequence for wipe ApplyOperatingSystem Calculating expected free space. ApplyOperatingSystem Reporting deletion progress. ApplyOperatingSystem Successfully wiped C:\ ApplyOperatingSystem
usmtutils.exe /rd <Path_to_State_Store> where <Path_to_State_Store> is the path as specified in the OSDStateStorePath variable via the "Set Local State Location" task (without the brackets <>). Not deleting the State Store can cause the following problems:
usmtutils.exe /rd <Path_to_State_Store> where <Path_to_State_Store> is the path as specified in the OSDStateStorePath variable via the "Set Local State Location" task (without the brackets <>).
Not deleting the State Store can cause the following problems:
Hardlinking is a feature of NTFS where multiple links can exist to one file on the hard drive. As long as one link exists, the file is not deleted. When a file has multiple links to it, the file will appear to exist in different locations in the file system, but the file only exists once on the hard drive. When the file is deleted from one location, as long as other links to the file still exist, the file is not actually deleted, and the file will still appear in the other locations that it has links to. The file is not deleted until it has been deleted from all of the locations that it has links to.
When USMT local capture is used without hardlinking, files are copied from their original location into the local State Store. For this reason, there has to be sufficient space on the hard drive to store all of the captured files. Even when compression is used, this can mean needing enough space on the hard drive somewhere in the area of almost double the amount of space taken up by the original files. If the original files take 30GB of space, then the hard drive will need about 30GB of free space on it.
When USMT 4 with hardlinking is used, instead of a file being copied to the local State Store, a second link to the file is created in the local State Store. The time taken to create the link to the file in the State Store is almost instantaneous, does not vary with the size of the file, and is much faster than trying to copy the file to the local State Store. The time it takes to capture 30GB of data will only take a bit longer than the time it takes to capture 1GB of data. When not using hardlinking, the amount of time taken to capture 30GB of data would be significantly longer than capturing 1GB of data.
Additionally hardlinking requires almost no additional hard drive space. The only additional hard drive space taken by USMT 4 with hardlinking are administrative files that keep track of where the files need to be restored to. This usually only takes a few MB of disk space vs. the potential GB of disk space taken when hardlinking is not used.
When USMT 4 with hardlinking is used in a ConfigMgr 2007 SP2 Task Sequence via the "Capture User State" task and the OSDStateStorePath and OSDMigrateAdditionalCaptureOptions variables, during the "Capture User State" task, new links are created for the captured files in the State Store location . All of the original links to the files are then deleted during the "Apply Operating System Image" task via recursive delete and wipe of the hard drive. However, because a second link exists in the State Store, and because the State Store is not deleted or wiped during the "Apply Operating System Image" task, the original files remains intact and are not deleted. Later in the Task Sequence via the "Restore User State" task and the OSDStateStorePath and OSDMigrateAdditionalRestoreOptions variables, the original links to the files are recreated back to their original location.
USMT 4 hardlinking also has the advantage over saving the State Store on a network location, such as a State Migration Point (SMP), in that it does not have to take the time to copy the files up to the network share, bandwidth is not used, and a server with plenty of disk space for saving the State Stores is not needed.
To summarize, USMT 4 with hardlinking has the following advantages:
The only disadvantage that hardlinking has is that it could potentially run into problems if there is file corruption on the hard drive, the hard drive has bad sectors, or the hard drive is having some other type of problems. However these problems would also be exposed when using local capture without hardlinking. In these scenarios, running a CHKDSK /R on the hard drive is advisable, and a full format of the drive may also be advisable. A network share (SMP) may be needed in these cases.
The above methods are not valid when using a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard because the Task Sequences created using the Wizard already have hardlinking enabled by default.
If a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard is inspected, it will be missing the "Set Task Sequence Variable" tasks that set the variables OSDStateStorePath, OSDMigrateAdditionalCaptureOptions, and OSDMigrateAdditionalRestoreOptions. So if the Task Sequence is missing the steps that sets these variables, and these variables are required to do hardlinking, how does the Task Sequence accomplish hardlinking?
It does this via the task "Determine Local or Remote UserState" task and the MDT script ztiuserstate.wsf. If the USMT 3 package is selected at the "Determine Local or Remote UserState" task, the ztiuserstate.wsf script determines if there is enough space on the hard drive to do a local capture (without hardlinking since it is USMT 3), and if not, it will perform a network capture via a State Migration Point (SMP). Based on which capture method determined by the ztiuserstate.wsf script is used, it defines the appropriate variables, OSDStateStorePath, OSDMigrateAdditionalCaptureOptions, and OSDMigrateAdditionalRestoreOptions, and along with conditions set on the relevant tasks, the Task Sequence will perform the appropriate capture.
However if the USMT 4 package is selected at the "Determine Local or Remote UserState" task, since disk space is not an issue, the ztiuserstate.wsf script will always default to local capture with hardlinking. It will then set the appropriate variables for the Task Sequence to perform a hardlink migration.
There is one problem though with using the ztiuserstate.wsf script. The ztiuserstate.wsf script defaults the State Store to the subdirectory StateStore within the Task Sequence cache folder. For the reasons stated in the notes above about saving the State Store within the Task Sequence cache folder, it is not always desirable to save the State Store within the Task Sequence cache folder. The Task Sequence created by the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard actually works around the first issue (State Store is deleted even if the data was not restored) by moving the State Store out of the Task Sequence cache folder via the ztimovestatestore.wsf script and the "Move State Store" task. The State Store is moved whether or not the Task Sequence succeeds or fails. However the other two problems can still happen.
To resolve the other two problems and save the State Store outside of the Task Sequence cache folder when using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard, follow the below steps:
The above steps resets the variable OSDStateStorePath to a path outside of the Task Sequence cache folder after the "Determine Local or Remote UserState" task and the ztiuserstate.wsf script sets it to the StateStore subdirectory within the Task Sequence cache folder.
Yes, but the order of the steps and where they are placed in the Task Sequence are critical. The five tasks that need to be added, and the order that they need to run in are as follows:
In addition, any "Format and Partition Disk" tasks need to be disabled.
The first three tasks, Set Local State Location, Set USMT Additional Capture Options, and Capture User State, have to run in the original full Windows OS before the Task Sequence boots into WinPE. This is usually before a "Restart Computer" task, such as the "Restart in Windows PE" task. The tasks also have to be placed into a group that has a condition where it only runs in the full Windows OS and not in WinPE. This can be accomplished by setting a condition on the group where the Task Sequence variable _SMSTSInWinPE equals false. The prevents the tasks from running in Bare Metal scenarios where the PCs are booted directly into WinPE and state capture is not needed.
The last two tasks, Set USMT Additional Restore Options and Restore User State, have to run in the newly deployed full Windows OS at some point after the "Setup Windows and ConfigMgr" task, preferably towards the end of the Task Sequence after all applications have been installed.
The Capture User State and Restore User State tasks are built in tasks of ConfigMgr 2007. They can be found under the "Add" --> "User State" menu in a Task Sequence.
The Set Local State Location, Set USMT Additional Capture Options, and Set USMT Additional Restore Options are all actually Set Task Sequence Variable tasks. For instructions on how to properly set up these tasks, see the two above methods.
As a general guide and template to modifying the existing Task Sequence, Method 1 above can be used to create a Task Sequence that serves as the template and guide to modifying the existing Task Sequence.
Frank Rojas | System Center Support Escalation Engineer
Nice article, but I miss Bitlocker in this story. What if you want to use Hardlink on a pc with Bitlocker enabled?
Then you need to add two steps:
The first step of the tasksequence must suspend/disable bitlocker. Add a commandline step with the command 'cscript manage-bde.wsf -protectors -disable c:' (if c: is the encrypted drive). Select as dir C:\Windows\System32.
The last step of the tasksequence enables Bitlocker again.
Add a commandline step with the command 'cscript manage-bde.wsf -protectors -enable c::' (if c: is the encrypted drive)
Daan
I adore your site, looks excellent and full of good info. Keep it up.
I tried the steps above exactly, and I still get an "Error 50: The request is not supported" during the Task Sequence.
I am not using SCCM to do this, just a Deployment Share....how can I modify the the ZTIUserState.wsf to default to %windir%\statestore?
Is there any "how to " guides on the ability to use the "Offline captures are possible using the UDI feature of MDT 2010 Update 1 when it is integrated with ConfigMgr 2007 SP2." you mention ?
I used your process under Method 1: Create a new ConfigMgr 2007 Task Sequence that supports USMT 4 hardlinking. Works wonderful! I'm just having an issue with Restoring the data. My SCCM task sequence just skips over the action "Restore User Files and Settings". I have my User state migration tool package selected. Also i have tried to use both "Restore all captured user profiles with standard options" and Customizing a xml from the USMT pacakge. In both cases my task sequence doest restore any data. When i look on my C root I find a directory called "User state". Any ideas as to what I should do to get this working?
Beautiful and well detailed article! Would be nice some screenshots..
Hi i have a problem actually i used Method 1 and all thing is great all data copied to USMT at C but i need to restore data to original place for example i need the user when logon on his machine see all data at desk top for example and so on can you advice me.
I followed this exactly. This is the best article I have found on USMT and SCCM/MDT2010. I am having a weird "bug" with the USMT not bringing over wallpaper, IE favorites/settings, and I think app settings also aren't coming over. I have only found one mention of this on google, but nobody has replied to the guy. Any thoughts?
Bit more info to my USMT not bringing over wallpaper and IE favorites, etc.... I have tried both "restore all captured user profiles with standard options" and the "Customize how user profies are restored" and enter in migapp.xml and miguser.xml
Machine is XP sp3, on a domain---> Win 7 on Domain. Win 7 image was prepared with MDT 2010, but I am not deploying it (atm) with a MDT task sequence....I used your Method 1 method.
I am going to test a manual run of USMT from command prompt and see if it works...if so then a batch file/command prompt TS will have to be run. I can't think of any other way around resolving this issue.
This is really a great information.Thanks
I have create a fresh task seqence as per above mentioned procedure , but when ever i deploy it it shows fail . any help ...
restore user profiles is failing. I can restore local accounts but not domain accounts.
Hi J.C
I suggest you to add reference to your own article support.microsoft.com/.../2018593 :-D
I am not able to copy Favorites properly to user's profiles when using Method 1 going from XP SP3 x86 or Windows 7 Ent x86 to Windows 7 Ent x86. I've applied the fix from support.microsoft.com/.../2018593. Favorites do seem to appear when migrating from x64 fine. I can still copy the Favorites from C:\UserState in x86, but I would rather not do that. Any ideas?