using Offline Mode in Windows PE using USMT 4 via a task sequence in SCCM 2007 SP2

[anyweb]

hi all,

 

Note: This post has been reproduced in a webcast, so if you'd like to see a video of Offline Mode in WinPE then click here

 

 

 

well this feature in USMT 4 is handy, as it allows you to do a scanstate while in Windows PE in other words, not in the OS so no problems with services running or applications running meaning that you get to backup everything you want without any locked files stopping from doing so.

 

Offline mode does however have some restrictions, read this page on Technet for details of that. To get around these restrictions and to migrate wallpaper see here, to migrate your network printers see here.

 

 

Great, but how do I do Offline Mode in Windows PE using SCCM ?

 

according to Microsoft, we can use the /offlinewindir switch in USMT 4 with scanstate.

 

/offlinewindir: "path to a windows directory"

 

 

This option specifies the offline Windows directory that the ScanState command gathers user state from. The offline directory can be Windows.old when you run the ScanState command in Windows or a Windows directory when you run the ScanState command in Windows PE. This option is incompatible with the /offline option.

 

However, implementing it isn't so straigtforward as you've probably already discovered and documentation about getting it to work within SCCM is as far as I can see pretty much non-existant,

so here courtesy of windows-noob.com is one way of doing it, feel free to show us other ways.

 

The theory behind this:-

 

As the Capture User State Step in a standard task sequence can only run in Windows, we cannot use that step to do our scanstate while in Windows PE, therefore we will use some tricks to run scanstate from WinPE.

 

To do this we create two special packages, the first package contains a batch file which calls the scanstate.exe file and the second package is the entire USMT X86 scanstate files and folders, (note: in this example we are using scanstate from the X86 folder).

 

This means that we create a separate package to the normal USMT4 package and this is only because this example is a workaround or proof of concept to prove that Offline Mode in Windows PE can be done via a Task Sequence in SCCM.

 

Update: If you would like sample code to check for and use the correct USMT architecture in offline mode then see Peters post here

 

 

Get your lab ready

 

We need a Windows XP client machine to test scanstate on and you should enable the F8 command prompt option in your boot.wim (you'll need it).

 

 

The Task Sequence

 

You can use this Task Sequence in SCCM by importing it. Please note this task sequence only has the 4 groups in it, if you want the 4 groups plus OSD then use the other Task Sequence further down.

 

Offline Mode in Windows PE using USMT 4.xml

 

The task sequence depends on three packages, the X86 bits from your USMT 4 (ie: copy everything in the X86 folder from C:\Program Files\Windows AIK\Tools\USMT folder. There are two versions, one for 32bit (X86) and one for 64bit (amd64), we are only using the X86 bits in this guide), the Batchfile

 

 

 

I break up my task sequence into four distinct groups, Set, Create, xcopy and Run

 

SET

 

 

In the Set group I set SystemDrive to c: (otherwise it will try and do this on the windows PE x: drive)

 

 

Next we set the OSDStateStorePath Task Sequence Variable to %systemdrive%\USMToffline which translates to c:\USMToffline, this directory will store our migration data during scanstate operations and when the new os is being applied.

 

 

Finally we set the hardlink load parameters

 

 

 

CREATE

 

In the Create group we just create two folders, c:\USMToffline,

 

 

and c:\USMTbits\X86

 

 

 

the c:\USMTbits\X86 will store all our scanstate native files.

 

 

XCOPY

 

In the xcopy group we do the clever stuff, we copy the X86 USMT stuff to the newly created folder, and then we copy our batch file for later user.

 

 

The batch file itself has the following contents

 

 

@set USMT_WORKING_DIR=%~2%\USMTbits\x86

"%~2\USMTbits\x86\scanstate.exe" "%~1" /c /o /hardlink /efs:hardlink /nocompress /offlinewindir:c:\windows /v:5 /l:%~2\windows\TEMP\SMSTSLog\scanstate.log /progress:%~2\windows\TEMP\SMSTSLog\scanstateprogress.log /i:%~2\USMTbits\x86\miguser.xml /i:%~2\USMTbits\x86\migapp.xml

 

 

You can download the batchfile below however you must rename it back to .bat

 

runscanstate-offlinewindir.bat.txt

 

 

RUN

 

The Run group does the actual running of the batch file and passes two variables to the file.

 

 

 

 

Testing Offline Mode.

 

Create an optional advertisement to a Migrate XP to W7 X86 collection for the Task Sequence and PXE boot your XP client (press F12 first....), select the Task Sequence when the wizard appears,

 

 

at this point press F8 to bring up the command prompt, you are doing this to verify that your data is getting migrated in OFFLINE mode. So here we can see the command prompt is open.

 

 

Ok switch back to the TS and start the task sequence. You will see it starts creating the folders, copying the USMT stuff and our batch file(s) and then actually running the scanstate command.

 

 

 

Once it is completed your migrated data will now be stored in C:\USMToffline\USMT

 

browse it and verify

 

 

If you want to see a working SMSTS.log file from the above test see below

 

smsts.log

 

 

Ok now what ?

[lipoufski]

Why would you want to save it on a servershare??

 

The idea of hardlinks is that you store the links to the file locally, then wipe the drive (which save the hard-links) and then reinstall.

 

First I must say that this thread was a godsend.

I applied all the steps and everything is now working perfectly.

I'm also interested in finding a way to store the data to a network share, I'll tell you why. In our environment we have some users that have huge profiles and limited local disk space for storing the data.

It would be great if there was a way to either map a drive then store the scanstate using some sort of script that would create a folder using there existing computer name and store the data there. Is that even possible with hard links? Is there a workaround for those machines with limited local storage aside from telling users to move or delete their data.

 

 

Thanks

[Peter van der Woude]

I'm also interested in finding a way to store the data to a network share, I'll tell you why. In our environment we have some users that have huge profiles and limited local disk space for storing the data.

It would be great if there was a way to either map a drive then store the scanstate using some sort of script that would create a folder using there existing computer name and store the data there. Is that even possible with hard links? Is there a workaround for those machines with limited local storage aside from telling users to move or delete their data.

 

The idea of using hardlinks is that you only store links to the files, so there is no file copying. AND the best part is that there is only arround 200Mb free disk space needed. If that is still to much then you shouldn't be looking at a hardlink migration, but just a a 'standard' migration with a State Migration Point.

[marine87]

Question...If we are going from 32bix XP to 64bit 7 do we still use the x86 version of usmt, and if not Should the Disable 64bit file system redirection be unchecked? I just get to the Do x86 scanstate and then it fails and the task sequence is exactly like you have it in the example...thanks in advance for your help.

 

I just tried it again and looked at the scanstate log and this is what I have...I did uncheck the boxes to disable 64bit file system redirection too:

 

2010-12-06 12:13:50, Info [0x000000] USMT Started at 2010/12/06:12:13:50.977

2010-12-06 12:13:50, Info [0x000000] Command line: \USMTbits\x86\scanstate.exe /c /o /hardlink /efs:hardlink /nocompress /offlinewindir:c:\windows /v:5 /l:\windows\TEMP\SMSTSLog\scanstate.log /progress:\windows\TEMP\SMSTSLog\scanstateprogress.log /i:\USMTbits\x86\miguser.xml /i:\USMTbits\x86\migapp.xml

2010-12-06 12:13:50, Status [0x000000] Activity: 'MIGACTIVITY_COMMAND_LINE_PROCESSING'

2010-12-06 12:13:50, Info [0x000000] Failed.[gle=0x00000091]

2010-12-06 12:13:50, Info [0x000000] An error occurred processing the command line.

\USMTbits\x86\scanstate.exe ##ERROR## --> /c /o /hardlink /efs:hardlink /nocompress /offlinewindir:c:\windows /v:5 /l:\windows\TEMP\SMSTSLog\scanstate.log /progress:\windows\TEMP\SMSTSLog\scanstateprogress.log /i:\USMTbits\x86\miguser.xml /i:\USMTbits\x86\migapp.xml

Settings store argument specified is invalid[gle=0x00000091]2010-12-06 12:13:50, Info [0x000000] USMT Completed at 2010/12/06:12:13:50.977[gle=0x00000091]

2010-12-06 12:13:50, Info [0x000000] Entering MigShutdown method

2010-12-06 12:13:50, Info [0x000000] Leaving MigShutdown method

[Peter van der Woude]

/c /o /hardlink /efs:hardlink /nocompress /offlinewindir:c:\windows /v:5 /l:\windows\TEMP\SMSTSLog\scanstate.log /progress:\windows\TEMP\SMSTSLog\scanstateprogress.log /i:\USMTbits\x86\miguser.xml /i:\USMTbits\x86\migapp.xml

Take a good look at this line and you will find the problem (hint: location of the logfiles).

[marine87]

Take a good look at this line and you will find the problem (hint: location of the logfiles).

 

 

Oh, so is it just supposed to be in the root of C? c:\SMSTSLog ? I do have one showing up there now and then the others in the windows/temp folder

 

Actually, this one isn't showing up in temp:

\windows\TEMP\SMSTSLog\scanstateprogress.log

 

Is that the problem? I just copied the batch file from the begining of this post

[Peter van der Woude]

I meant that the driveletter is missing...

[Matthijs]

Hey Niall,

 

Thanks for the very nice webcast & manual.

 

However........I'm facing a little problem.

The Run scanstate task fails with an error: 11135

Run command line

Working dir 'C:\USMTbits'

Executing command line: Run command line. The operating system reported error 27: The drive cannot find the sector requested.

 

The task is as you described:

cmd /c runscanstate-offlinewindir.bat %OSDStateStorePath% %systemdrive%

Start in: %systemdrive%\USMTbits\

Package: Microsoft RunScanState 1.0 English

 

Any thoughts?

 

Thanks a lot in advance!

 

 

 

Sollution: There was a missing "/" in my batchfile.......back to testing! ;-)

Noticed it when I viewed the local scanstate.log

Edited December 10, 2010 by Matthijs

[marine87]

I meant that the driveletter is missing...

 

 

Thanks, well I changed the batch to include the c:\ but it still fails...here is the edited batch, not sure if it needs a space

 

 

@set USMT_WORKING_DIR=%~2%\USMTbits\x86

 

"%~2\USMTbits\x86\scanstate.exe" "%~1" /c /o /hardlink /efs:hardlink /nocompress /offlinewindir:c:\windows /v:5 /lc:\windows\TEMP\SMSTSLog\scanstate.log /progressc:\windows\TEMP\SMSTSLog\scanstateprogress.log /i:%~2\USMTbits\x86\miguser.xml /i:%~2\USMTbits\x86\migapp.xml

 

I also tried it this way:

 

@set USMT_WORKING_DIR=%~2%\USMTbits\x86

 

"%~2\USMTbits\x86\scanstate.exe" "%~1" /c /o /hardlink /efs:hardlink /nocompress /offlinewindir: c:\windows /v:5 /l c:\windows\TEMP\SMSTSLog\scanstate.log /progress c:\windows\TEMP\SMSTSLog\scanstateprogress.log /i:%~2\USMTbits\x86\miguser.xml /i:%~2\USMTbits\x86\migapp.xml

 

 

 

Am I still missing something...I'm not sure what this, /i:%~2\, refers to..should that be C:\USMTbits... also?

 

Just checked on the computer I'm trying to migrate and the usmtbits and usmtoffline folders are there, but it didn't create the c:\windows\TEMP\SMSTSLog\scanstate.log

 

Can anyone paste the correct batch file using the c drive as the drive letter? I would greatly appreciate it

[anyweb]

in between your tests make sure to delete the usmtbits and usmtoffline folders, i didn't build in any error detection for seeing if they existed in the sample task sequences so it will generate an error the second (and subsequent) time you run the ts. easy to test, just manually delete the dirs before running the task sequence

[mvrabel]

Awesome doc - and am using at client with success -

 

ONE question though:

 

Seems the process is downloading every package into the x86 package - and this takes forever -

 

Is this an "advertisement" setting -