Keeping An Eye On USMT Progress v0.2

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.


Comments (12)

  1. Anonymous says:

    @Mark – it should not be too hard to do.  You would just need to edit the path that the script uses to find the log file.  Change it to your own log file path and you should be good to go.


  2. Anonymous says:

    Hi Daniel.

    This sounds like a great idea. I don’t understand how the clien can map back to Z: and I am wondering what this line means:

    C:MININTSMSOSDOSDLOGSUSMTCapture.prg” is that something it creates or is that what it passes?

    Keep up the good work.


  3. Anonymous says:

    Hi Daniel, great tool ! , The USMT_Tracker.vbs works fine (USMT 4.0) but takes a huge amount of CPU as you state, however running CUSTOM_USMT_Tracker.vbs is not showing the progress %. Any idea ?

  4. Felipe Román says:


    Definitively, that’s a great tool.


  5. Leo Jacob says:

    Thanks Daniel!  Does this work with Windows 7?

  6. fred says:


    if i copy the tail.exe and the vbs to the Tools dir of the deployment share, its not copied to the MININT dir when i start the LiteTouch.vbs on the Client.

    And if i read the commandline, the vbs have toi be in the Scripts dir on the DeploymentShare

  7. brad says:

    This would be VERY handy to have, would this run on the stand alone non-mdt installation with USMT?

  8. Dave says:

    Hey Dan, Thanks for the great tool!

    I have a question on it, though. I have one user who’s getting these lines in the usmtcapture.log file.

    2010-04-19 11:56:33, Error                 [0x000000] Read error 32 for C:Documents and SettingsamedinaLocal SettingsApplication DataMicrosoftInternet ExplorerRecoveryActive [RecoveryStore.{9FAEA243-4BDE-11DF-9DFE-005056C00008}.dat]. Windows error 32 description: The process cannot access the file because it is being used by another process.[gle=0x00000020]

    2010-04-19 11:56:33, Error                 [0x000000] Read error 32 for C:Documents and SettingsamedinaLocal SettingsApplication DataMicrosoftInternet ExplorerRecoveryActive [RecoveryStore.{9FAEA243-4BDE-11DF-9DFE-005056C00008}.dat]. Windows error 32 description: The process cannot access the file because it is being used by another process.[gle=0x00000006]

    It would appear that USMT can’t get the type of handle it wants on those files. Considering the USMT progress dialog uses IE, could this be an issue?

    This was on IE8. I hadn’t run this on a machine using IE8 yet, so I thought I’d post it up!

    Thank you!

  9. Dave says:


    Yea, it will. Just launch it before starting MDT.

  10. Dave says:

    Hey Dan.

    Regarding my previous post, if the user closes the USMT tracker when it appears, the failure does not occur. Bummer!

  11. Mark P Nguyen says:

    What would be the command line for this tracker to work on USMT Standalone instead of MDT?

  12. Mauris says:

    Does this work with USMT 4.0 ?