MDT Debugger
edit: fixed error in command line example. Thanks to Aurélien Bonnin and FoW for pointing it out.
edit 2 : this version has been updated, please search the blog for the latest version.
When creating and configuring an LTI deployment solution there is one thing that always bugs me immensly: debugging custom scripts. Writing the scripts is easy, but debugging them is a whole different experience. The reason is simple, to debug a script you normally need to launch it from within the MDT environment (during the deployment). Consequently, it can be quite hard and very slow to iron out any errors that they (might) contain because of the need to run a full deployment of a computer, just to be able to do some testing.
This isn't the actual part that bugs me though. The annoying part is when the script fails and MDT ends, all because of a silly mistake made in the script; this for me is the frustrating part that could at times drive me insane. Because MDT has now terminated, pretty much the only sure way to re-test the script is to re-run the deployment; vastly slowing down the debugging time.
I should point out that this is no fault of MDT, it is all mine; after all, I was the one who put the error in the script! But, because of the way MDT works, the debugging of these custom scripts can be labourious task.... until now! [cue drum-roll] I would like to present version 0.1 of the "MDT Debugger"! This nifty little tool makes debugging most custom actions, script or not, simpler and prevents MDT from terminating with the red error screen if the custom action has failed.
The MDT Debugger sits in-between MDT and your custom script and intercepts the return code that is normally sent back to MDT from your custom action. It then displays the error code and allows you to either accept and return it to MDT, edit it before returning it to MDT, or to relaunch the custom action again. This later option gives you the opportunity to fix any errors in the script/action and then relaunch it - thus eliminating the need to relaunch the deployment process from the very beginning just to re-test the custom action.
As you can see in the above screenshot, my custom action (in this case, a VBS script) failed with a "File not found" error message. Because MDT by default expects an error code of either 0 or 3010, any process that returns a different error code will cause MDT to stop immediately with the error screen shown at the top of this post. However, you'll notice a new window in the top-left of the screenshot above.
But, with the MDT Debugger, the error code from my custom action is trapped and presented in the HTML window shown in the above screenshot. With this new window it is possible to manually edit the return code, overridding the one that was returned by the custom action, then return it to MDT (perhaps you don't want to do anything other than continue with the MDT task sequence without it failing). Or, the cause of the failure in the custom action can be fixed so that you can then immediately re-run it again. Each time you relaunch the action, you are returned to the MDT Debugger window afterwards where you can review the error code returned and decide the action you want to take. And, the best bit is that MDT will wait indefinetely until you decide on the error code that you want to return back to MDT.
To use the MDT Debugger, you need to follow the steps below:
- Download the ZIP file attached to this post, and extract the two files to the SCRIPTS folder on your deployment share.
- Open the MDT task sequence, and add the following text before the existing command line for any of your custom actions: "cscript.exe %SCRIPTROOT%\CUSTOM_MDTDebugger.wsf", as shown below (without the quotation marks). For example, your new command line might become "cscript.exe %SCRIPTROOT%\CUSTOM_MDTDebugger.wsf %SCRIPTROOT%\CUSTOM_MyCustomAction.vbs"
There is one thing that I also need to mention. This tool will only work for LTI deployments, because of the fact that it requires showing on the desktop a screen that the user will interact with - something that ZTI deployments are not too fond of. Finally, I have tested this as much as possible and have used it in several projects. Please let me know if you find any problems with it, or have any suggestions for changes!
This post was contributed by Daniel Oxley, a Consultant with Microsoft 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
Anonymous
January 01, 2003
I don't know about you but it frustrates me that, to test certain parts of a task sequence, I have toAnonymous
January 01, 2003
I don't know about you but it frustrates me that, to test certain parts of a task sequence, I have toAnonymous
January 01, 2003
I don't know about you but it frustrates me that, to test certain parts of a task sequence, I have toAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
@Aurelien, FoW & Joel Sorry for the typo, and thanks for commenting about it. This has been amended in the blog text. DanielAnonymous
January 01, 2003
@ J. Garrett, I don't think this is the problem as I have tried it myself with WSF scripts. At what point do you get that error? If you want to manually test it, you can simply open CMD into the network share where the deployment share is and run the script manually, this will have the same effect as running it from the MDT Task Sequence. @Brian No, this is not possible if you are using the Install Application action in the task sequence. An error code of 1 may not be a problem, if you find my post about Robocopy exit codes on this blog you'll see my explination about non-zero error codes and what they might actually mean. HTH, DanielAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Dan, Yes, I do see your HTA's opening screen come up, but that is immediately followed by the error screen. FoW, I didn't catch that little difference between the command invocations in the screen shot for the task sequence and where he actually spells it out. I'm in the process of trying letting the .WSF file run so it's invoking CSCRIPT.EXE file it's extension definition. (typing in a path to a file ending in .WSF should invoke the default script engine, which should be CSCRIPT unless otherwise changed.) I'll let you all know if there's any difference when it comes up. JoelAnonymous
January 01, 2003
Thanks for the clarification and correction. I found 5 really dumb errors in my code really fast. Now if I can only get past this one last hard problem with my custom script... At least the debugger's there to help me! Thanks again for the cool tool! Regards, JoelAnonymous
January 01, 2003
@Tou - The truth is that I never tested this script in XP, only in Vista and 7. I've only ever seen that error if you try to run it in WinPE because WinPE does not have Internet Explorer. Obviously not the cause for you in XP though.Anonymous
March 23, 2010
This looks great Daniel - thanks for your hard workAnonymous
March 25, 2010
The comment has been removedAnonymous
March 26, 2010
The comment has been removedAnonymous
March 31, 2010
@joel, this is a general error - you need to grep your BDD.log file and search a few lines above the error instance to find out whats caused it. I notice that Dan has put conflicting info in the post. In the screen shot you will see no 2nd cscript.exe call however in the post text he includes it. Have you tried without the second cscript.exe call? i.e. cscript.exe %scriptroot%CUSTOM_MDTDebugger.wsf %scriptroot%ZTIOEMLock.wsf FoWAnonymous
April 06, 2010
The comment has been removedAnonymous
May 02, 2010
The comment has been removedAnonymous
October 05, 2010
The comment has been removedAnonymous
January 16, 2011
Hi, can i use this script to debug PowerShell script in mdt 2010 update 1 ?Anonymous
January 18, 2011
The comment has been removed