The Bronx Bull

I've got another question for the USMT experts (anyone here?). I've got this offline TS working 100%, except my "Favorites" are not copying properly. This is in an XP with IE8 environment to Win7 with IE9. The scanstate is definitely capturing the favorites folder as it's supposed to, since I can see them in the C$ folder of the Hardlinks' USMTOffline folder. Then, then loadstate is definitely 'processing' them, as seen in the attached screenshot. For whatever reason though, my favorites are not restored to C:\Users\User1\favorites as they're supposed to be, I simply have the default "Favorites bar" and "Websites for the United States" folders in there. Anyone experience this before, or know what is interfering with the Favorites transfer? FYI I am using a slightly modified MigUser.xml and MigApp.xml (but I've also tested with the barebones config files), in addition to the Printers.xml and Wallpaper.xml files that were provided in this thread.

I wrote a very quick batch file to help Desktop Support in writing the MIG file to a NAS server. No changes were made to the network share, and it's not running IIS. echo off set server=LionKing set share=statepoint set drive=t: set domain=private.domain set user=sccmnetworkaccount set password=*password* net use %drive% \\%server%\%share% %password% /user:%domain%\%user% /persistent:no if "%errorlevel%"=="0" echo You should now be connected to the State Migration Point. if "%errorlevel%"=="2" echo You are already connected to the State Migration Point. Please continue. :Menu echo. echo ....................................................................................................... echo Please name the folder for your Profile Capture and press enter. echo ....................................................................................................... echo. set /P folder= if "%folder%"=="exit" goto exit if "%folder%"=="cmd" cmd Rem The following line ignores all profile SSIDs that are absent an ntuser.dat file (but still in the registry) SET MIG_IGNORE_PROFILE_MISSING=1 scanstate t:\%folder% /i:miguser.xml /i:migapp.xml /uel:60 if "%errorlevel%"=="0" goto complete if "%errorlevel%" NEQ "0" echo Error: %errorlevel% if "%errorlevel%"=="1" echo Double check that the profile capture completed please.. if "%errorlevel%"=="2" echo Double check that the profile capture completed please.. if "%errorlevel%"=="27" goto dupe :dupe echo A folder with the same name already exists. Please choose another. goto Menu :complete echo Profile Migration should be complete. Location: \\%server%\%share%\%folder% pause :exit exit Then you would do something similar to pull the data back, but with the loadstate.exe and applicable switches. Hard Linking is much better though.

Does anyone here use USB Task Sequence media? Assuming you have a 'reboot' step within your task sequence, and aside from modifying the boot sequence, how do you prevent the PC from rebooting and booting from the USB stick straight back into the WinPE Task Sequence wizard, as opposed to continuing to the next step of the task sequence? It seems as though you would have to remove the USB media each time, whereas on a CD, it only boots to the media after you "press any key to boot to CD." Anyone have a workaround for this? What is everyone else doing?

You would do a loadstate command using the proper syntax, i.e.: loadstate C:\USMTBits /i:miguser.xml /i:migapp.xml /uel:60 The syntax is here: http://technet.micro...28WS.10%29.aspx I believe if you're running in the WinPE environment, you will need the "/offline:windir:<windows directory path>" switch, and of course the /hardlink and /nocompress switches for the hardlinked data.

Got it... after I unchecked the "Allow this package to be transferred via multicast (WinPE only)" and "Encrypt multicast packages" from within the boot image properties, the TS was able to download and stage the boot image package properly.... I'm not sure yet which one of those settings was the instigator... can anyone enlighten me as to why these options were interfering?

pss53, I'm pretty sure that the runstanstate.bat does NOT need a program from within the package... it was working for me without one just last week. Alas, I'm still stuck. However, in case anyone is interested, I was able to determine *why* the runscanstate.bat was taking so long.... this was because in the scanstate.log file, it was trying to copy profiles that were absent in reality and had no ntuser.dat file, but still existed as a SID # within the registry (but had no profile data to be found). Therefore, it was trying to copy each of these nonexistent profiles about twenty times each, failing each time since it could not find the data in C:\Documents and Settings, and waiting six seconds between each retry. I was able to circumnavigate this issue by using the following line in the runscanstate.bat: SET MIG_IGNORE_PROFILE_MISSING=1 Now my other issue is still the boot image. Is it normal for the boot image to be copied to C:\_SMSTaskSequence\Packages\DOT0001 (the last part being the package identifier of my x86 boot image)? I read earlier in this thread that you need to have the advertisement set to "download content when needed by task sequence" instead of the "access content directly," so I set it as such. I do have my boot image set to "Allow transfer over multicast (winPE only)" and "Encrypt multicast packages"; should this make a difference? Also, I've tried a substitute boot image, an alternate operating system image, and I've tried re-advertising the task sequence.. so that rules those out. Therefore, I'm almost certain that it's an issue within either the properties of the boot image, or the properties of the specific advertisement.. In my smsts log file, I see: Boot Image package not found. Unspecified error (Error: 80004005; Source: Windows) TSManager 9/12/2011 10:20:20 AM 1752 (0x06D8) Entering ReleaseSource() for C:\_SMSTaskSequence\Packages\DOT00001 TSManager 9/12/2011 10:20:20 AM 1752 (0x06D8) The user tries to release a source directory C:\_SMSTaskSequence\Packages\DOT00001 that is either already released or we have not connected to it TSManager 9/12/2011 10:20:20 AM 1752 (0x06D8) BootImage::ResolveImageSource( pszPackageId, sImagePackageSourcePath, sImageSourcePath), HRESULT=80004005 (e:\nts_sms_fre\sms\framework\tscore\bootimage.cpp,687) TSManager 9/12/2011 10:20:20 AM 1752 (0x06D8) TS::Boot::BootImage::StageBootImage(sBootImageID, StageBootImageProgressCallback, (LPVOID) m_sStageBootImageMessage.c_str()), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\executionengine\engine.cxx,816) TSManager 9/12/2011 10:20:20 AM 1752 (0x06D8) Failed to stage a boot image DOT00001. Unspecified error (Error: 80004005; Source: Windows) TSManager 9/12/2011 10:20:21 AM 1752 (0x06D8) I'm really not sure what any of this means, aside from the fact that it was unable to download the boot image locally (aka stage), and therefore it cannot launch. I wish this would start working

Yes the scanstate action completed with no errors, but if you look here, I get the "Starting the Migration Process" (the first step of the USMT) appears at 15:36, and then it doesn't start the first gathering of profile data until 16:10... if I run the USMT from a full OS standpoint, the gathering of the profile data starts almost immediately. It seems as though there's definitely a hold up here, and the ts is idle for about 30 minutes during the 'run scanstate x86' portion: <![LOG[Starting the migration process]LOG]!><time="15:36:17.171+240" date="09-09-2011" component="InstallSoftware" context="" type="1" thread="1812" file="runcommandline.cpp:34"> <![LOG[Offline engine startup from WinDir - c:\windows]LOG]!><time="16:10:33.614+240" date="09-09-2011" component="InstallSoftware" context="" type="1" thread="1812" file="runcommandline.cpp:34"> <![LOG[Processing the settings store]LOG]!><time="16:10:33.614+240" date="09-09-2011" component="InstallSoftware" context="" type="1" thread="1812" file="runcommandline.cpp:34"> <![LOG[]LOG]!><time="16:10:33.614+240" date="09-09-2011" component="InstallSoftware" context="" type="1" thread="1812" file="runcommandline.cpp:34"> <![LOG[Examining the system to discover the migration units]LOG]!><time="16:10:33.614+240" date="09-09-2011" component="InstallSoftware" context="" type="1" thread="1812" file="runcommandline.cpp:34"> <![LOG[]LOG]!><time="16:10:33.614+240" date="09-09-2011" component="InstallSoftware" context="" type="1" thread="1812" file="runcommandline.cpp:34"> <![LOG[ S-1-5-21-1210859283-1907650544-1231754661-71091 (SWDist) (1 of 4): 0% done ]LOG]!><time="16:10:33.879+240" date="09-09-2011" component="InstallSoftware" context="" type="1" thread="1812" file="runcommandline.cpp:34"> <![LOG[ S-1-5-21-1210859283-1907650544-1231754661-71091 (SWDist) (1 of 4): 42% done ]LOG]!><time="16:10:33.879+240" date="09-09-2011" component="InstallSoftware" As for the OS image, there shouldn't be any problems with it. There's nothing out of the ordinary on the WIM file, and I've used it countless times in my standalone Windows 7 Base Image task sequence. Correct me if I'm wrong, but the steps here would be: Scanstate Stage the boot image Apply the Operating System It seems as though the root of the problem is that the boot image is not being loaded successfully (although it works fine from another TS), and yes, I've updated the x86 boot image on both DPs. Why would it try to apply the operating system before the boot image is even loaded? As for the scanstate.log, that's the one thing I am going to check as soon as I get back to the office on Monday. I was about to examine it briefly on Friday evening before I left, but I checked both C:\USMTbits\x86 and X:\Windows\temp and I did not see it listed there from within the command shell. Thanks in advance for your help guys! I really want to tackle this.

Also, I would think you could just mount your boot WIM with ImageX using the DISM command, then throw the trace32.exe into the X:\Windows directory. Unmount, update the distribution point; then, after a failed TS or other error, you can simply F8 to pull up your command prompt, and type: cd X:\Windows\temp\SMSTSLOG\ trace32 smsts.log

Have you tried starting a new boot image from scratch? Pull the one from the PETools directory of Program Files\WAIK\PETools\x86 and start fresh - I ended up doing this and it worked out. It seems that if a boot image gets 'corrupted,' unless you have a backup of previous source versions, it's quite difficult to fix. That said, my broken boot image ended up being a driver issue, so I cleared all of NIC drivers from the boot image and it was then able to update successfully.

I'm hoping someone can help with this! As stated in my above post, the "do runscanstate x86" step takes forever... after examining my smsts.log... it's almost as if it's not even doing anything for an entire half hour - THEN it starts to migrate the profiles and shows the percentages. Also - since then, for whatever reason, it's telling me my boot image is inaccessible, and thus, my TS fails directly after the scanstate. I've attached my smsts.log ...PLEASE someone help! smsts.log

I'm having this same issue - I'll add a driver to the driver pool, update the driver package to the DP, then head over to the boot image to add said NIC driver. I have verified that the driver package successfully updated to the DP and the package status is "installed", but I'm still unable to update the WinPE boot image - a bunch of errors about the ConfigMgr binaries as well as the driver failing to inject. I have a lot of experience with standalone imageX and the way it mounts, unmounts, and services WIM files - and it's very picky during the unmount process (i.e. if an explorer window is open that references a path inside the boot image, the unmount will fail, and you'll have to use the /discard option). Could it be something ridiculous pertaining to the mounting/unmounting of the virtual boot WIM?

Are you executing the task sequence from the operating system or are you doing so in offline mode (Windows PE)?

Are the program folders existent in your custom Windows 7 image? USMT only copies what you tell it to, using the customizable XML files (MigUser, MigApps, MigDocs). USMT does NOT copy entire program installations over to the new OS, however.

I've got this working now - thanks anyweb for your excellent work! One question: when firing off the TS, everything seems to work properly.. no significant errors or anything, but the "do x86 scanstate" stage seems to take a long while - i.e. 25-40 minutes plus, even for a base image with nothing on it. I am familiar with the USMT outside of SCCM, and I do know that when running in the Windows XP OS, it's definitely quicker than that. Is there something that my "do x86 scanstate" portion of the TS is getting held up on? I tried checking the scanstate.log, but it was nowhere to be found in the C:\USMTbits\x86 folder - which could mean that the scanstate hasn't even started yet and is still "hung." Eventually, it does go through though.... anyone else experience this?

I'm at a loss here. I'm trying to develop a solution to use scanstate and loadstate within an SCCM '07 Task Sequence, which basically captures the user state, installs Win7 over XP, and hardlinks the user state back. But I can't even seem to get the scanstate to work properly... I've got them both (scanstate + loadstate) working within the XP OS just fine. Basically, I've browsed several of the tutorials on here about using hardlinks with an SCCM task sequence, and I'm trying to replicate doing so. Our environment dictates usage of SCCM boot media, and we boot into Windows PE. No PXE boot yet. First I tried setting the OSDStateStore variable, launching the USMT 4 package, and specifying the AdditionalCaptureOptions with the /hardlink and /nocompress switches, all from the TS. No cigar. I think the task sequence fails because Windows PE cannot provide a domain account to pull the USMT files from the SCCM server. Second, I tried copying the USMT x86 folder to the Boot Image WIM-file, and using a "Run command" task sequence variable to run "X:\Windows\USMTmain\USMT\scanstate.cmd" My scanstate.cmd batch file looks like this: echo off Rem The following line ignores all profile SSIDs that are absent an ntuser.dat file but still existent in the registry SET MIG_IGNORE_PROFILE_MISSING=1 scanstate C:\migdata /i:miguser.xml /i:migapp.xml /uel:60 /nocompress /hardlink This fails because it tells me I need to use the "/offline" command line switch when in PE; scanstate error 36 is specified in the log. Third, I specify the /offline command line switch in the batch file, and am left with: Scanstate return code 11, Undefined or incomplete command line option. It shows the error as being my /offline command switch. At this point, I've stopped using the task sequence to test, and have started to just manually execute items from the prompt, so I can get my error messages a bit quicker. On paper, it seems like everything I'm doing should work... it's just PE that is the problem. The scanstate.cmd batch file works perfectly from within the OS, and hardlinks the data to C:\migdata Lastly, I tried copying the USMT files directly to the C drive of the XP OS, and running them from the PE prompt. Same as above. My questions are: 1) Why can I not do a "cd c:\" within the Windows PE command prompt? Why does it open up defaulting to X:\Windows\System32 (probably because that's where the cmd.exe is launching from - but I've seen screenshots of people using the F8 command support from a TS and getting a prompt that defaults to C). 2) What more is there to know about the /offline switch? Do I need to add to it? 3) Each time a boot image is modified within SCCM, does new boot media need to be created to go with it? Thanks guys, in advance; I just found this forum and I have a feeling it's going to be very helpful, and I'd like to contribute.