Just a heads up on a new ConfigMgr 2007 Knowledge Base article we published this morning. If you're using a ConfigMgr Task Sequence on a PC with multiple drives or partitions and it uses USMT 4 with hardlinking then you'll want to check this one out:
=====
Symptoms
Consider the following scenario:
- A computer has two or more drives or partitions.
- The User Profiles and the Windows directory are located on the first drive or partition (assume drive letter C:).
- Second drive or partition has more available free disk space than the first (assume drive letter D:).
- A Configuration Manager 2007 OSD Refresh Task Sequence that uses USMT 4 with hardlinking is run on the computer.
In this scenario 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.
Viewing the SMSTS.log reveals the following errors:
Executing command line: osdmigrateuserstate.exe /apply /continueOnError:%OSDMigrateContinueOnRestore% TSManager
==============================[ OSDMigrateUserState.exe ]============================== OSDUSMT
Initializing from environment successful OSDUSMT
Trying to resolve package path for packageID - <Pacakage_ID> OSDUSMT
Successfully connected to "<Package_Location>\<Pacakage_ID>" OSDUSMT
USMT package path = '<Package_Location>\<Pacakage_ID>\' OSDUSMT
Initiailization succeeded OSDUSMT
EncryptionKey ENV var not found. This may be because Local state Store is used. OSDUSMT
Building Default USMT params successful OSDUSMT
Adding config files to user params successful OSDUSMT
Additional user defined options = "/hardlink /nocompress" OSDUSMT
Building user defined params successful OSDUSMT
Building USMT command successful OSDUSMT
Executing command line: "<Package_Location>\<Pacakage_ID>\<Arch>\loadstate.exe" "D:\_SMSTaskSequence\UserState/c /all /v:5 /l:"C:\Windows\CCM\Logs\SMSTSLog\loadstate.log" /progress:
"C:\Windows\CCM\Logs\SMSTSLog\loadstateprogress.log" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\miguser.xml" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\migapp.xml" /hardlink /nocompress OSDUSMT
Process completed with exit code 38 OSDUSMT
USMT completed with exit code 38 OSDUSMT
USMT returned exit code (0x00000026). Look USMT log file loadstate.log for detail error message. OSDUSMT
Invoking ReleaseSource on USMTPackagePath <Package_Location>\<Pacakage_ID>\ OSDUSMT
OSDMigrateUserState finished: 0x80070026 OSDUSMT
Process completed with exit code 2147942438 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Restore User Files and Settings.
Reached the end of the file. (Error: 80070026; Source: Windows) TSManager
Alternatively, if you are using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard you will see the following:
Executing command line: osdmigrateuserstate.exe /apply /continueOnError:%OSDMigrateContinueOnRestore% TSManager
==============================[ OSDMigrateUserState.exe ]============================== OSDUSMT
Initializing from environment successful OSDUSMT
Trying to resolve package path for packageID - <Pacakage_ID> OSDUSMT
Successfully connected to "<Package_Location>\<Pacakage_ID>" OSDUSMT
USMT package path = '<Package_Location>\<Pacakage_ID>\' OSDUSMT
Initiailization succeeded OSDUSMT
EncryptionKey ENV var not found. This may be because Local state Store is used. OSDUSMT
Building Default USMT params successful OSDUSMT
Adding config files to user params successful OSDUSMT
Additional user defined options = "/hardlink /nocompress" OSDUSMT
Building user defined params successful OSDUSMT
Building USMT command successful OSDUSMT
Executing command line: "<Package_Location>\<Pacakage_ID>\<Arch>\loadstate.exe" "D:\_SMSTaskSequence\StateStore /c /all /v:5 /l:"C:\Windows\CCM\Logs\SMSTSLog\loadstate.log" /progress:
"C:\Windows\CCM\Logs\SMSTSLog\loadstateprogress.log" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\miguser.xml" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\migapp.xml" /hardlink /nocompress OSDUSMT
Process completed with exit code 38 OSDUSMT
USMT completed with exit code 38 OSDUSMT
USMT returned exit code (0x00000026). Look USMT log file loadstate.log for detail error message. OSDUSMT
Invoking ReleaseSource on USMTPackagePath <Package_Location>\<Pacakage_ID>\ OSDUSMT
OSDMigrateUserState finished: 0x80070026 OSDUSMT
Process completed with exit code 2147942438 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Restore User State.
Reached the end of the file. (Error: 80070026; Source: Windows) TSManager
The loadstate.log will also show the following errors:
<Date> <Time>, Status [0x000000] Activity: 'MIGACTIVITY_TRANSPORT_SELECTION'
<Date> <Time>, Info [0x000000] Processing the settings store[gle=0x00000006]
<Date> <Time>, Info [0x000000] Opening hardlink store D:\_SMSTaskSequence\UserState
<Date> <Time>, Info [0x000000] Entering MigOpenHardLinkStore method
<Date> <Time>, Info [0x0802e2] User selecting transport(UNC Transport (class CUNCTransport) ) with initialization data(UNC: Path(D:\_SMSTaskSequence\UserState\USMT))
<Date> <Time>, Error [0x080000] HARDLINK: cannot find distributed store for c - 0694a57d-1506-4755-af10-782d0a5b1723[gle=0x00000002]
<Date> <Time>, Error [0x0802e3] SelectTransport: OpenDevice failed with Exception: Win32Exception: HARDLINK: cannot find all distributed stores.:There are no more files. [0x00000012] void __cdecl Mig::CMediaManager::SelectTransportInternal(int,unsigned int,struct Mig::IDeviceInitializationData *,int,int,int,unsigned __int64,class Mig::CDeviceProgressAdapter *)
void __cdecl Mig::CHardLinkHelper::Open(class UnBCL::String *)[gle=0x00000002]
<Date> <Time>, Error [0x000000] Unable to open store at D:\_SMSTaskSequence\UserState\USMT[gle=0x00000002]
<Date> <Time>, Info [0x000000] Leaving MigOpenHardLinkStore method
<Date> <Time>, Error [0x000000] Failed to select store. Path: D:\_SMSTaskSequence\UserState[gle=0x00000002]
<Date> <Time>, Warning [0x000000] Internal error 23 was translated to a default error
<Date> <Time>, Info [0x000000] Failed.[gle=0x00000006]
<Date> <Time>, Info [0x000000] An error occurred during store access[gle=0x00000006]
<Date> <Time>, Info [0x000000] USMT Completed at 2010/06/30:15:46:50.995[gle=0x00000006]
Alternatively, if you are using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard you will see the following:
<Date> <Time>, Status [0x000000] Activity: 'MIGACTIVITY_TRANSPORT_SELECTION'
<Date> <Time>, Info [0x000000] Processing the settings store[gle=0x00000006]
<Date> <Time>, Info [0x000000] Opening hardlink store D:\_SMSTaskSequence\StateStore
<Date> <Time>, Info [0x000000] Entering MigOpenHardLinkStore method
<Date> <Time>, Info [0x0802e2] User selecting transport(UNC Transport (class CUNCTransport) ) with initialization data(UNC: Path(D:\_SMSTaskSequence\StateStore\USMT))
<Date> <Time>, Error [0x080000] HARDLINK: cannot find distributed store for c - 0694a57d-1506-4755-af10-782d0a5b1723[gle=0x00000002]
<Date> <Time>, Error [0x0802e3] SelectTransport: OpenDevice failed with Exception: Win32Exception: HARDLINK: cannot find all distributed stores.: There are no more files. [0x00000012] void __cdecl Mig::CMediaManager::SelectTransportInternal(int,unsigned int,struct Mig::IDeviceInitializationData *,int,int,int,unsigned __int64,class Mig::CDeviceProgressAdapter *)
void __cdecl Mig::CHardLinkHelper::Open(class UnBCL::String *)[gle=0x00000002]
<Date> <Time>, Error [0x000000] Unable to open store at D:\_SMSTaskSequence\StateStore\USMT[gle=0x00000002]
<Date> <Time>, Info [0x000000] Leaving MigOpenHardLinkStore method
<Date> <Time>, Error [0x000000] Failed to select store. Path: D:\_SMSTaskSequence\StateStore[gle=0x00000002]
<Date> <Time>, Warning [0x000000] Internal error 23 was translated to a default error
<Date> <Time>, Info [0x000000] Failed.[gle=0x00000006]
<Date> <Time>, Info [0x000000] An error occurred during store access[gle=0x00000006]
<Date> <Time>, Info [0x000000] USMT Completed at 2010/06/30:15:46:50.995[gle=0x00000006]
Cause
This problem occurs because the default path where the USMT 4 state store is to be saved as specified by ConfigMgr 2007 is on a drive or partition other than the one where the Windows directory and User Profiles are located. When using hardlinking, this could possibly cause the state store to either span multiple drives/partitions and/or actually reside on a drive/partition other than the drive specified in the path by ConfigMgr 2007. The reason for this is that when using hardlinking, the state store has to reside on the same drive/partition where the original data existed.
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 Configuration Manager 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 computer only has one drive or partition, or has multiple drives or partitions but the first drive/partition has the most available free space, 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 specified to be in 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 the state store will actually span multiple volumes and/or reside on a drive/partition other than the one specified in the state store path since some or all of the original data exists on C:.
This is a problem when using USMT 4 hardlinking with ConfigMgr 2007 because at least part of the hardlink state store is on a different drive/partition (D:) than Windows and the user profiles (C:). When a ConfigMgr 2007 OSD Task Sequence runs, at the "Apply Oeprating System Image" step, before the OS is applied to the hard drive, a recursive delete runs that wipes all contents of the drive minus a few protected folders. Normally the folder containing the state store and specified in the OSDStateStorePath variable is marked as one of the protected folders. However, if the state store spans multiple volumes, only the part of the state store that resides on the same drive/partition that is specified in the OSDStateStorePath variable is not wiped. The state store that resides on the OS volume is wiped, causing the problem.
This scenario will not cause the capture performed by scanstate.exe via the "Capture User State" task to fail because a hardlink state store that spans multiple drives/partitions is a supported scenario when using USMT 4 outside of ConfigMgr 2007. However, when the restore of the state store is attempted by loadstate.exe via the "Restore User State" task, loadstate.exe will report that state store is invalid since part of it has been deleted and it will exit 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 prople the state store has to be all saved to the same drive/partition where the Windows OS and User Profiles reside. This will cause the state store not to span multiple drives/partitions. To do this, 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 "Determine Local or Remote UserState" task via the ztiuserstate.wsf script .
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:
- In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
- Right click on the affected Task Sequence and choose "Edit".
- 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 Click on the "OK" or "Apply" button to save the task sequence.
If the "Set Local State Location" task does not exist, 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:
- In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
- Right click on the affected Task Sequence and choose "Edit".
- 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.
- In the newly created "Set Task Sequence Variable Task":
- Next to the "Name:" text box, enter in:
Set Local State Location - Next to the "Task Sequence Variable:" text box, enter in
OSDStateStorePath - Next to the "Value:" text box, enter in:
%SystemDrive%\StateStore
- Next to the "Name:" text box, enter in:
- 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.
Note:
In the above two methods, the state store subdirectories are called UserState and StateStore. However the name of the state store can be whatever the user desires as long as it is within Windows naming conventions. The key point is to use the environment variable SystemDrive as part of the path to ensure that the state store is saved in the same drive/partition as Windows and the user profiles.
Ensure that there are no "Format and Partition Disk"/"Partition Disk"/"Partition Disk 0" tasks in the Task Sequence that format and partition the drive/partition where the user profiles are originally located and where the state store is saved. If there are any such tasks, either disable them or make sure that they have conditions on them where they do not run if state store is saved locally on the hard drive.
If a "Format and Partition Disk" task runs on the drive/partition where the user profiles are originally located and where the state store is saved, then all of the data and settings captured in the state store will be lost. Instead the "Apply Operating System Image"/"Apply Operating System" task will run a recursive delete of all files and directories on the drive/partition minus a few protected folders.
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. As mentioned earlier, 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, the recursive delete and wipe process that occurs during the "Apply Operating System Image"/"Apply Operating System" task is 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
=====
For the latest version of the article see the link below:
J.C. Hornbeck | System Center Knowledge Engineer
The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
