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