Here’s another quick suggestion, especially for VBScript, that will make script development and debugging a little easier and a lot less stressful. It may seem like common sense, but sometimes we all just need a reminder: Start Simple.
The first application of this dictum is that if you are writing your first or second script, don’t try to create the mother of all scripts to manage your entire Active Directory enterprise from a web based HTA using ADSI, WMI and ADO. (Ok, I’m stretching a bit, but I think you get the point). That’s a lot of scripting technology to digest all at once, especially when just starting out. Yet, you’d be surprised how often I see this sort of thing.
The second application applies to everybody. This application of the dictum concerns scripts with multiple scripting technologies. For example, you might want to develop an HTA with VBScript functions and WMI queries to build a reporting tool. Don’t try to do it all at once. Start Simple. First, build and test your WMI queries using WBEMTest. Once you have a known good query, then write a standalone VBScript that uses the query. Modularize the script into functions and/or subroutines and verify that the output is what you want. Once you have a working script, then wrap it up in the HTA format and add the necessary HTML and other script code to take the VBScript output and display it within the HTA.
This same dictum applies to PowerShell and batch files as well. Start with simple expressions or commands. Make sure each command runs as expected from the console, then start building your script file. If you are using Get-Wmiobject with a WMI query, test the query in WBEMTest. Start Simple.
By following this approach, you are working with known good building blocks of script functionality. When you run into a problem or are debugging, you should be able to concentrate on the “new” functionality because odds are that’s where the problem lies. Start Simple and you’ll enjoy scripting a whole lot more.
