Debugging MDT Litetouch Wizard Pages

A friend e-mailed me this morning asking about a problem they were having with a custom MDT Litetouch Wizard page. MDT supports a framework for the development of custom Wizard Pages during deployment, but there are some gotchas.

In the case of the code today, they were kind enough to send me the code for the wizard page so I could reproduce the behavior in the comfort of my (home) office. The specification was clear enough, they had some custom code to determine the ComputerName based on the Site, IP Address, and other factors. This is quite common. But they wanted to disable the “Next” button on the page until the Technician had fully completed all fields of the form, and confirmed the inputs. For reasons that were not obvious to us, the “Next” button was being disabled, but randomly it was being enabled. We wanted to find out more.


First off, MSHTA is *very* finicky. A web page that runs with no errors in a full Windows 8 instance, may not display or function correctly in WinPE. Often I find that this is caused by errors in the HTA code, where the MSHTA.exe wrapper in the full OS is silently *ignoring* errors in the code, where the WinPE version is complaining.

Setting up a private Environment

Running a single MDT web page is fairly easy to do. Run the MSHTA.exe program, and use the wizard.hta wrapper as the web page, finally pass in your web page as a definition to the wizard.

C:\>mshta "c:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Scripts\Wizard.hta" /definition:CustomPane1.xml /TaskSequenceID=100

You must specify the full path to the wizard.hta file, the custom wizard page can be relative to the Wizard.hta file, or just type in the full path.

What is also cool, is that you pass in any additional parameters in the command line, and they will get picked up as MDT Key Value Pair properties.


I have Visual Studio installed on my local machine, and Visual Studio has a built in debugging engine for tracing through MSHTA code, However it’s a little tricky to get working.

You must enable script debugging in Internet Explorer: Start IE, Click on Internet Options, Advanced Tab, then uncheck the following options:

“Disable script debugging (Internet Explorer)”
“Disable script debugging (Other)”

Then add the statement “Stop” to your VbScript code at the place you wish to debug.

When you run your program using MSHTA in a full Windows environment, and it hits the “stop” statement, the Visual Studio Just in Time Debugging environment will start up allowing you full debugging.

Finding the problem

I was able to reproduce the problem observed by my friend in my office, but setting the debug “stop” in code at the point where the problem occurred didn’t reveal the root cause. In fact further debugging revealed that none of my friend’s code was causing the Next button to re-enable. What gives? <sigh>

I went back to the CustomPane1.xml definition with the HTML code in it and found the following

  <label>Computer Name</label>
  <label for=CombinedName>* Build on tab!</label>
  <input type="text" name="CombinedName" size="15" style="width: 200px" readOnly=True>

Ha, we have a culprit!

MDT has a feature where it will disable the next button if it finds that some required fields are empty. In this case it looks like the MDT wizard was treating the text box above as a required field, and was overriding the custom code of my friend.

My recommendation was to use the following modification:

  <label>Computer Name</label>
  <input type="text" name="CombinedName" size="15" style="width: 200px" readOnly=True>


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s