Writing custom scripts with MDT 2010 November 3, 2009

Ben Hunter wrote a great blog post a few years ago on how to create a custom VBscript to use with BDD 2007 (http://blogs.technet.com/benhunter/archive/2007/04/15/bdd-2007-ndash-tips-and-tricks-ndash-how-to-write-a-custom-script.aspx). Ben’s script template will still work with MDT 2010 however If you have spent any time looking at the scripts in MDT 2010 you will notice that the format of the built in scripts have changed. So you might be wondering how to create a custom script with MDT 2010. MDT 2010 introduced some script structure changes to better handle error reporting and to make the scripts a bit easier to read and test. The new template is listed below. So how do you use the template? Start by pasting the following code into a script file with a WSF extension (somefile.wsf). After creating the file edit the Class ScriptName with the name of your script. As an example if you named your custom script somescript.wsf then the Class would be Class SomeScript.

Now that you have your script and your class named correctly you can add your code under the Function Main. Once you are finished you just need to save the file and put it into the scripts folder in your deployment share.

So what does the new structure give you beyond what Ben’s post originally pointed out? First it gives you some nice debugging capabilities. Normally you would run your script by calling cscript.exe “%scriptroot%\somescript.wsf” in the task sequence. If you want to use the advanced debugging you can add /debugcapture. Adding the /debugcapture will turn on advanced debugging features by disabling the standard On Error Resume Next in the scripts and capturing any errors in the script that might occur and displaying them to the screen. For example if you forgot to declare a variable the /debugcapture will display the variable that could not be found and the line number that the error occurred on. You can also use your own test hook scripts to unit test the different functions in the script (more on that later). For right now, enjoy the template and we will definitely be posting more custom script samples over the next few months!

[…] creating and adding custom scripts isn’t to difficult (have a look on Tim Minters Post about writing custom scripts with mdt 2010 as a reference) handling custom settings can become difficult. But when do you need a custom […]

The toolkit reference document in the MDT documentation does a pretty decent job of going over all of the variables.

Once you have your script template in place you can access any variable using the oEnvironment.Item

For example to access the computer name you would do
oEnvironment.Item(“OSDComputerName”)

Testing your scripts can be difficult without going through an entire deployment process but it is possible. You could run ztigather.wsf to get all of the local variables set and stored in variables.dat and then run your custom script. Ztigather would run through all of the rules in the customsettings.ini and store all of the variables. This may not work for every script but is a good start.

Wow what a gold mine this site is… Been looking for just this kind of thing.
Question I have is: Is there a good way to test my scripts without going through an entire capture/deploy process?
And
How do I “see/access” what variables are out there for me to use? For example “IsDesktop = True/False” Where do I go to find these from the script? I notice some variables are stored in .xml files but, I’m not clear about how to read them properly.