The Deployment Guys : USMT

Keeping An Eye On USMT Progress v0.2

Daniel Oxley — Wed, 02 Sep 2009 18:41:00 GMT

Back in June I posted a script that I’d written that displays the progress of the USMT capture and recover phases in a neat HTML window off to one side of the screen; particularly useful if you are capturing/recovering large amounts of data because otherwise it looked like the USMT progress had hung due to the progress bar not moving along for quite some time.

While the script I wrote worked fine I was not 100% happy with it, mostly because it ate up too many CPU cycles, which could sometimes slow down the actual USMT progress; an effect that you would never want to happen! The problem was that there was no quick and easy way to parse the last few lines of a text file in VBScript without first reading in all the previous lines. This meant that as the log file grew, my script took longer and longer to run. So, I took it back to the drawing board, and reworked the innards of it to produce version 0.2!

This time, the script runs extremely quickly and it will barely register on the CPU, meaning that it shouldn’t slow anything else down. It still requires the same parameters to be passed to it when adding to the task sequence, which are detailed below. To add it to the task sequence, simply add the following Run Command Line action before the USMT capture or restore actions (or both):

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTCapture.prg”

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTRestore.prg”

It also has one other very important dependency. You must download tail.exe from the Windows Resource Kit and place it in the Tools folder of the MDT deployment share, along with this script. You can get the tool here, it doesn’t matter that it is the 2003 version, I have tested it on Windows 7 and it works fine. If you don’t put tail.exe in the tools folder, then the script will fail.

The next update might take a while to get round to doing, but I want to remove the requirements for the command-line parameter, and have the script find the progress file on it’s own. Also, it would be good to display more information rather than just the current position in the progress, perhaps an extra line that informs what the current task is that is being run. Also, a few cosmetic changes wouldn't go amiss, but I am a techie not a graphic designer!

Attached to this post is the script file.

This post was contributed by Daniel Oxley a consultant with Microsoft Consulting Services Spain

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Keeping An Eye On USMT Progress

Daniel Oxley — Fri, 26 Jun 2009 12:31:00 GMT

I recently did a project where all users had around 25Gb (don’t ask!) of data that had to be migrated with the USMT during the OS deployment. Because of the sheer volume of data, the USMT phases of the project took an extremely long time to complete, and because no on-screen feedback is given of the progress, the customer would often think that something had hung, so they often cancelled the deployment; only to find that it was indeed running correctly. In order to stop them doing this, I wrote a very simple VBS script that showed the current progress of the USMT. It works by simply parsing the progress file, looking for the percentage progress of the process.

I thought I would publish it here, because when I showed it to some colleagues they asked for a copy as they thought it would be useful to use during the lab phases of MDT projects.

It consists simply of a VBS file that requires the path of the USMT log file to be passed as a parameter. The script creates a small HTML window that then displays a single line showing the progress of the USMT as a percentage. You can either launch the script by hand or add it to the task sequence. To add this to the task sequence, simple add the following “Run Command Line" action before the USMT capture or restore actions (or both):

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTCapture.prg”

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTRestore.prg”

Why the two commands lines? Well, the first one is to show the progress of the capture phase of the USMT, and the second is to show the progress of the restore phase. Also, I should point out that the command is launched in this way because MDT needs to launch the command, and then move on. If you don't have the cmd.exe /c "start" part at the beginning then MDT will launch the script and wait for it to finish (which is never) and the USMT commands will never fire. You may also have noticed that I had to put the drive letter in the command path, this is because the variable %SCRIPTROOT% is not available with this usage.

The screenshot below shows what it looks like in action.

Be warned though, this script does consume quite a few CPU cycles because it is probably not the most efficient routine; it was really a proof-of-concept thing that I wrote in order to show that everything was running as expected. When I wrote it I was running it on dual core desktop computers and it didn’t seem to noticeable affect the deployment time.

Attached to this post is the script file.

This post was contributed by Daniel Oxley a consultant with Microsoft Consulting Services Spain

Excluding USB, FireWire and other drives from USMT Capture

DeploymentGuys — Wed, 29 Apr 2009 15:48:00 GMT

A common requirement during user state migration is to not capture data from certain drives. The most commonly requested for exclusion are removable drives such as USB and FireWire drives. There is no command line option to exclude these drives automatically with USMT v3. I had to turn to scripting to accomplish this.

I created a script, ZTI-ExcludeDrivesXmlGen.wsf (and its function library HelperFunctions.vbs), that will generate a USMT XML rules file to unconditionally exclude USB and FireWire drives (as well as additional specified drives) during the deployment. The script should be run during the State Capture phase before Scanstate.exe is run. The resulting XML file should be used on both the Scanstate.exe and Loadstate.exe command lines. The script is driven by either command line switches or MDT properties:

Use the /output switch or the USMTExcludeDrivesOutput property to specify the output XML file. If not specified, the default of oUtility.LogPath & "\MigExcludeDrives.xml" is used.
Use the /usb switch or the property USMTExcludeUsbDrives=True to exclude USB and FireWire drives from the migration.
Use the /scriptdrive switch or the property USMTExcludeScriptDrive=True to exclude the drive from which this script is running from the migration.
Use the /drives switch or the USMTExcludeDrives property to exclude specific drives from the migration. The switch should be specified like this example:
/drives:"D:,E:,F:"
The property should be specified like this example:
USMTExcludeDrives=D:,E:,F:
Use the /flagfile switch or the USMTExcludeDriveFlagFile property to exclude specific drives from the migration using a flag file. Using the /flagfile switch without a value or setting USMTExcludeDriveFlagFile=True will cause the script to exclude drives that have the default flag file, NO_USMT_ON_DRIVE.USMT, in the root folder of the drive. (You SMS experts out there will get the choice of the default flag file name. J ) Using the switch or property with a file name value will exclude drives that have the specified named flag file in the root folder of the drive.

Remember that the generated XML file must also be used with Loadstate.exe. Therefore, it must be saved to a location that from which it can be retrieved during the State Restore phase. I have included a script, ZTI-CopyFilesToStateFolder.wsf, to copy files to a subfolder of the state store location that can be used for this.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

USMT Error Codes

DeploymentGuys — Wed, 14 Jan 2009 10:38:10 GMT

I was recently configuring the User State Migration Tool for a customer’s MDT server when, during the testing phase, the USMT began failing with an error code (‘return code’ or ‘rc’ when you read the MDT log files). I searched the USMT documentation on TechNet looking for the explanation of what the error code meant, only to discover that I could not find any information at all.

So, after a bit of asking around internally at Microsoft, I have managed to obtain the below list of error codes. I should point out though that this list of error codes is only for version 3.01 of the USMT, I don’t know if there are differences for any past or future versions of the tool.

Error code	Error text
0	USMT_SUCCESS
1	USMT_DISPLAY_HELP
2	USMT_MEMORY_FAIL
3	USMT_INVALID_PARAMETERS (Bad command line)
4	USMT_INVALID_STORE_LOCATION
5	USMT_NO_MORE_TOKEN
6	USMT_UNABLE_SET_SCRIPTFILES
7	USMT_UNABLE_GET_SCRIPTFILES (Can’t find XML file(s) specified in the command-line)
8	USMT_UNABLE_SET_STOREPATH
9	USMT_UNABLE_SET_USERS
10	USMT_UNABLE_FINDMIGUNITS
11	USMT_UNABLE_DOMIGRATION (A file is in use)
12	USMT_FAILED_MIGSTARTUP (Error in XML file ‘Bad XML’)
13	USMT_FAILED_SETMIGRATIONTYPE
14	USMT_FAILED_LOCALONLY
15	USMT_UNABLE_GET_WORKINGDIR
16	USMT_UNABLE_SETKEY
17	USMT_UNABLE_READKEY
18	USMT_TOO_LONG_KEYSTRING
19	USMT_UNABLE_SETCOMPRESSION
20	USMT_ERROR_INSUFFICIENT_RIGHTS
21	USMT_UNABLE_DELETE_STORE
22	USMT_UNABLE_SET_BENONADMIN
23	USMT_ERROR_INSUFFICIENT_STRINGBUFFER
24	USMT_ERROR_UNSUPPORTED_PLATFORM
25	USMT_ERROR_UNABLE_TOVERIFY_PLATFORM
26	USMT_UNABLE_SET_EFSMODE
27	USMT_INIT_ERROR
28	USMT_UNABLE_SET_LAC_LAE
29	USMT_ERROR_CORRUPTED_ENCRYPTED_STORE (Store is encrypted and no or invalid key has been specified)
30	USMT_ERROR_NO_INVALID_KEY (Store is only compressed but a key has been specified)
31	USMT_ERROR_CORRUPTED_NOTENCRYPTED_STORE
32	USMT_ERROR_LOGFILES_INSIDESTORE
33	USMT_INVALID_PLATFORM_FOR_TARGETXP
34	USMT_STORE_VALID_ONLY_FOR_XP
35	USMT_UNABLE_TO_READ_CONFIG_FILE
36	USMT_INVALID_CONFIG_FILE_FORMAT
37	USMT_ERROR_UNABLE_CREATE_LOGS
38	USMT_ERROR_USE_LAC
39	USMT_FAILED_TO_EXCLUDE_FOLDERS
40	USMT_ERROR_UNABLE_CREATE_PROGRESS_LOG
41	USMT_STATUS_CANCELLED

Most of the codes are pretty self-explanatory, but I have included some extra information for some of the more cryptic error messages.

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain