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