I encountered this problem while preparing a demo consisting in a migration from Windows XP to Windows 7. I was using USMT 4, MDT 2010 and SCCM 2007 SP2 RC. In my task sequence I used hard-links to capture user data from a Windows XP installation and then to restore data back after applying a Windows 7 Image previously created. The migration process completed successfully but no system component settings were migrated. I looked at the scanstate.log created in %systemroot%\system32\ccm\logs\SMSTSLog to see if something went wrong and I found the following line :
2009-10-17 17:19:44, Info [0x000000] Downlevel Manifests folder is not present. System component settings will not be gathered.
The error is related to a not present manifest folder, so I used FileMon lo verify in which location scanstate was looking :
Scanstate looked for that folder in %Systemroot%\system32, same location as the “Current Directory” of the process (as shown by Process Explorer).
By doing a simple search with Google I’ve found that I’m not alone and that other people experienced the same issue (http://systemcenterideas.com/2009/09/usmt-issues-with-mdt-2010). The fix proposed in that blog does not apply to me because I use a “Capture Task” and not a script to execute scanstate.
So while waiting to see if it will be fixed in RTM (I hope so) I needed a workaround.
I decided to create a wrapper that :
- executes a renamed scanstate.exe as a child process.
- passes the same parameters received from the command line to the child process
- passes the Application path as the Current Directory of the child process
- returns the child process exit code.
I used :
- GetCommandLine : to retrieve parameters passed to the wrapper
- GetModuleFileName : to get the application path (after eliminating the application file name)
- CreateProcess : to call the renamed scanstate and to pass the application folder as the Default Directory
- GetExitCodeProcess : to retrieve the child process exit code and to pass it to the task sequence.
I renamed scanstate.exe to _scanstate.exe and I putted my wrapper in the USMT x86 folder, naming it scanstate.exe.
As it can be seen in the previous picture, my wrapper calls the real scanstate application (named _scanstate.exe) as a child process and forces the “Current Directory” to be the same where the wrapper is located. With the correct “Default directory” _scanstate.exe is able to access the manifest folder.
This is a sort of hack, it is not supported an probably it is not the best solution to this problem, but in this case I’m running an RC version of SCCM 2007 SP2 and I’m only interested in have the demo working in the right way. I really hope that this will be fixed in the RTM version of SP2 or that if there is a supported alternative solution to this problem, that will be published soon (I know that I can copy manifest folder to the system32 before calling scanstate, but I don’t like to do that).
This posting is provided "AS IS" with no warranties, and confers no rights.