Good morning, I am setting up Task Sequences that use USMT 4.0 to refresh workstations (XP to 7) and migrate user profiles using hardlinking. After the Task Sequence is done, it appears the user profiles are not migrated. Upon checking the scanstate logs, I get thousands of errors (a sample one is below): 2010-07-27 14:23:49, Status [0x000000] Processing File C:\Documents and Settings\jsmith\Application Data\Microsoft\Templates [CIO-ABC Memo.dot] 2010-07-27 14:23:49, Warning [0x080000] Mig::CTransportDataStore::Create: Failed to add intermediate folder for C:\Documents and Settings\jsmith\Application Data\Microsoft\Templates\CIO-ABC Memo.dot: Win32Exception: DoesObjectExist not allowed for a locked context.: The operation identifier is not valid. [0x000010DD] int __thiscall Mig::CMediaManager::DoesObjectExist(class Mig::CUserContext *,struct Mig::IMigLocation *,struct Mig::IMigLocation **,struct Mig::IMigLocation **) 2010-07-27 14:23:49, Error [0x000000] Read error 4317 for C:\Documents and Settings\jsmith\Application Data\Microsoft\Templates [CIO-ABC Memo.dot]. Windows error 4317 description: The operation identifier is not valid.[gle=0x00000012] 2010-07-27 14:23:49, Info [0x000000] Error ignored due to /c option 2010-07-27 14:23:49, Info [0x080000] Error 4317 while gathering object C:\Documents and Settings\jsmith\Application Data\Microsoft\Templates\CIO-ABC Memo.dot. Shell application requested ignore The command line that is run is: C:\_SMSTaskSequence\Packages\0A100238\x86\scanstate.exe C:\_SMSTaskSequence\UserState /o /localonly /c /efs:copyraw /v:5 /l:C:\WINDOWS\system32\CCM\Logs\SMSTSLog\scanstate.log /progress:C:\WINDOWS\system32\CCM\Logs\SMSTSLog\scanstateprogress.log /i:C:\_SMSTaskSequence\Packages\0A100238\x86\migapp.xml /i:C:\_SMSTaskSequence\Packages\0A100238\x86\migdocs.xml /i:C:\_SMSTaskSequence\Packages\0A100238\x86\miguser.xml /hardlink /nocompress /ue:ABCCN061105536\* Any ideas? Thanks, Terence Durning

Hi, It seems a known bug: 1. PC has two (or multiple) drives or partitions 2. User profiles and Windows are located on the first drive or partition (assume drive letter C:) 3. Second drive or partition has more available free disk space than the first (assume drive letter D:) 4. A ConfigMgr 2007 OSD Refresh Task Sequence that uses USMT 4 with hardlinking is run on the PC Then the Capture User Files and Settings"/"Capture User State" task will succeed, but the "Restore User State"/"Restore User Files and Settings" task will fail. Cause This problem occurs because the USMT 4 State Store is saved on a drive/partition other than the one where the Windows OS and user profiles were located on. When using the hardlinking feature of USMT 4, the State Store has to be on the same drive/partition as the Windows OS and user profiles. The State Store location is stored in the variable OSDStateStorePath. The default value of this variable is another variable, _SMSTSUserStatePath. _SMSTSUserStatePath usually resolves to a subdirectory called UserState within the Task Sequence cache folder. The Task Sequence cache folder is automatically created by the ConfigMgr 2007 Task Sequence and placed on the root level of the drive with the most available free space and given the name _SMSTaskSequence. Similarly, when using MDT 2010/MDT 2010 Update 1 integration, the State Store location is determined by the ztiuserstate.wsf script in the "Determine Local or Remote UserState" task. The ztiuserstate.wsf script also sets the value of OSDStateStorePath to a subdirectory within the Task Sequence cache folder, but to a subdirectory called StateStore. If a PC that only has one drive/partition, or has multiple drives/partitions but the first drive/partition has the most available free space, then the Task Sequence cache folder will be created at the path C:\_SMSTaskSequence. The State Store would then be saved within this folder in either the path C:\_SMSTaskSequence\UserState or C:\_SMSTaskSequence\StateStore. However, if a PC has multiple drives/partitions and the first drive/partition is not the one with the most available free space, then the Task Sequence cache folder will be created on the drive/partition with the most available free space. Assuming that the drive/partition with the most available free space has the drive letter of D:, then the path where the Task Sequence cache folder would be created is D:\_SMSTaskSequence. The State Store would then be saved into either the directory D:\_SMSTaskSequence\UserState or D:\_SMSTaskSequence\StateStore. Assuming that the drive/partition where the user profiles are located and Windows is installed onto is the first partition/drive with the drive letter of C:, then this is a problem when using USMT 4 hardlinking because the hardlink State Store is on a different drive/partition (D:) than Windows and the user profiles (C:). This scenario will not cause the capture performed by scanstate.exe to fail, however the State Store created will be invalid. When the restore of the invalid State Store is attempted by loadstate.exe, loadstate.exe will report that State Store is invalid and exit out with a failure. If the drive/partition where the user profiles were originally located has been formatted, wiped, or erased (usually via the "Format and Partition Disk" or "Apply Oeprating System Image" tasks), then there is no way to recover the original files and settings. Resolution To resolve the problem, the variable OSDStateStorePath has to be changed from its default value. When using MDT 2010/MDT 2010 Update 1 integration, the variable has to be redefined after it has been set by the ztiuserstate.wsf script in the "Determine Local or Remote UserState" task. To ensure that the State Store is saved to the same drive/partition where Windows is installed and the user profiles are located, the environment variable SystemDrive can be used as part of the path that defines the variable OSDStateStorePath. If MDT 2010/MDT 2010 Update 1 integration is not being used, the "Set Task Sequence Variable" task that sets the variable OSDStateStorePath needs to be modified: 1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node. 2. Right click on the affected Task Sequence and choose "Edit". 3. Click on the "Set Local State Location" task. Ensure that the task is a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath. Next to the "Value:" text field, change it from %_SMSTSUserStatePath% to %SystemDrive%\UserState 4. Click on the "OK" or "Apply" button to save the task sequence. If the "Set Local State Location" task does not exist, then look for a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath, and then make the changes above. If using MDT 2010/MDT 2010 Update 1 integration, then a new "Set Task Sequence Variable" task needs to be added after the "Determine Local or Remote UserState" task that redefines the variable OSDStateStorePath: 1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node. 2. Right click on the affected Task Sequence and choose "Edit". 3. Click on the "Determine Local or Remote UserState" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after "Determine Local or Remote UserState" task but before the "Request State Store" task. 4. In the newly created "Set Task Sequence Variable Task": o Next to the "Name:" text box, enter in: Set Local State Location o Next to the "Task Sequence Variable:" text box, enter in OSDStateStorePath o Next to the "Value:" text box, enter in: %SystemDrive%\StateStore 5. Click on the "OK" or "Apply" button to save the task sequence. If in Step 3 the task "Determine Local or Remote UserState" does not exist or has been renamed, look for the "Run Command Line" task that runs the script ztiuserstate.wsf, and then follow the above steps. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

This was related to the sIDHistory issue I posted about in the following: http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/18898692-c2d4-47ed-acf9-86fb042decae