Windows DevCenter    
 Published on Windows DevCenter (
 See this if you're having trouble printing code examples

Directions in Windows Scripting

by Mitch Tulloch

I've blogged several times recently on topics concerning Windows scripting technologies, so I thought it might be good to hear from an expert on the subject: Don Jones, a Microsoft MVP and the creator of Don is also the author of the Microsoft Windows Administrator's Automation Toolkit, one of the volumes of the Microsoft Windows Server 2003 Resource Kit, and of several other books on Windows scripting technologies. Below is the text of my interview in which Don speaks quite candidly concerning the strengths and weaknesses of administering Windows platforms using scripts.

Tulloch: I'm talking with Don Jones of Sapien Technologies, Inc., developers of PrimalScript and other great scripting and software development tools for IT professionals. Don, tell us a bit about what got you interested in Windows scripting technologies.

Jones: I think it'd have to be when I was working as a Windows administrator for a small company. We didn't have a lot of budget for tools, so in a lot of cases I had to come up with ways to do things on my own. Everyone on the IT staff worked hard; scripting was really just a way to give ourselves some breathing room, by automating stuff that was either repetitive or boring.

Tulloch: Windows platforms have traditionally lagged behind Unix/Linux as far as scripting capabilities have been concerned. What has Microsoft done in recent years to address this issue?

Jones: Until recently, Microsoft's efforts have been sketchy. Win2003 saw over 60 new command-line tools, but they weren't built in a consistent way. For example, sometimes you'd use /m to specify a machine name, but other tools would use -c. It made it tough to really use those because every tool had a learning curve. VBScript is more consistent, but one of its biggest assets--the ability to work with Windows Management Instrumentation (WMI)--is hampered by the fact that providing WMI support is up to each product group. So the DNS server in Windows has great WMI support; the DHCP server has zero. We're really at the mercy of product groups that, by and large, would prefer we just use the GUI tools they've written. Microsoft Shell (MSH, code-named "Monad") offers some promise. The administrative functionality in Exchange 12, for example, is being built entirely on MSH; the GUI just uses that underlying functionality. So for the first time the entire product will be totally scriptable. I hope other product groups go the same direction, because it'll put us firmly at the lead as far as OS scriptability goes.

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

Tulloch: How much are VBScript, WMI, and other scripting technologies used by Windows administrators in enterprises today? Is the trend growing for automating administrative tasks using scripts?

Jones: It's a growing trend, definitely. Some companies make much greater use of it than others, right now, because we're in a transition phase where scripting is just starting to be recognized as valuable. More and more administrators are starting to pay attention to scripting, and, more importantly, more and more managers are starting to pay attention. I think the days of a high-end Windows administrator who can't script are probably numbered at this point.

Tulloch: What sort of administrative tasks are still difficult (or even impossible) to script on Windows-based networks?

Jones: Group Policy just isn't as scriptable as it should be. Fairly big swaths of Windows--DHCP, as I said, is a notable one here--aren't readily accessible from a script. File permissions and AD permissions are scriptable, but it can be incredibly difficult to do. The tough part about scripting, actually, is that there are a lot of things you just can't do, but there's no rhyme or reason to it. Exchange Server 2003 can be scripted, but it's rarely worth the effort because it's so complicated. Virtual Server 2005 offers fantastic scripting capabilities. It's really all over the place. I think probably the biggest hole is the ability to remotely manage user settings and user-specific stuff--you can do it through technologies like Group Policy in some cases, but the security and profile model in Windows just makes this difficult, if not impossible, through any scripted means.

Tulloch: Is remotely managing Windows servers using WMI scripts a secure approach to system administration? What safeguards need to be implemented to prevent things like passwords being sent over the network in cleartext or unauthorized individuals trying to control servers using scripts?

Jones: It's pretty secure by default. By default, only local Administrators have permission to remotely access WMI, and I think that's a good way to leave things. I don't think you should be using alternate credentials inside scripts; if you need a script to run under credentials other than your own, execute the script using RunAs, so that it'll have the proper security permissions and will use Windows' own authentication mechanisms, which are pretty safe. The worst practice I see is the "I want to write a script that my users can run, which can do something they don't have permissions to do." That's just crazy. If you want your users to do something, give them permission to do it. Scripting isn't a way to bypass Windows' security, and doing things like hardcoding credentials into a script--so that a user can run the script without actually having permission to do what the script is doing--is nuts. It's like everything else in Windows: it's pretty secure, but you can certainly ruin that security if you make an effort.

Tulloch: What's the best way for a Windows administrator who is not a programmer to get started learning how to script?

Jones: Some training. This isn't stuff you can pick up on your own in most cases, without some kind of help--a book if you're a reader, a class if you're a listener, a video if you're somewhere in the middle. VBScript just has all these basic concepts and things you need to know before you can effectively do anything with it. While I'm a big fan of copying and pasting other folks' scripts that they've shared, you still need to know what you're looking at or you just wind up with these Frankenstein scripts that don't ever work properly. My first scripting book, Managing Windows with VBScript and WMI, is intended for someone who has no experience and doesn't want to become a programmer. Read it, walk through the exercises, try the scripts, and really spend time reading the scripts and figuring out what they do, and you'll be on your way.

Tulloch: Once one has mastered the basics of VBScript and WMI, how can one really get the most out of Windows scripting? What power tools and techniques are available?

Jones: I think just experimenting is probably the best way. Look at other people's scripts, visit websites like, read advanced materials--I have an Advanced VBScript for Windows Administrators book out now--do whatever you can to keep pushing the envelope on your scripts. Start really understanding how COM works and how VBScript can use it, start working with ActiveX Data Objects to interface your scripts to databases, that kind of thing.

Tulloch: Monad is being touted by some as the "next big thing" in Windows scripting. Is it really something radically new or is it just incremental in importance? What will you be able to do with Monad that you can't do today using WMI and VBScript?

Jones: It's a big deal. It's an all-new shell that logically replaced Cmd.exe; not to say that Cmd.exe won't be in Windows, but MSH is sort of "Cmd.exe for the 21st century." Rather than command-line tools like EXE files, MSH uses little cmdlets which are written in .NET. The cmdlets all follow a standard set of usage patterns, so learning how to use one helps you learn how to use others--they're consistent, in a way today's command-line tools aren't. Instead of BAT files for scripting, you write MSH scripts that string together cmdlets. Like BAT, there's a scripting language, although it's much more robust and flexible than the BAT scripting language. MSH's scripting language sits somewhere between C# and VBScript, so it's pretty easy to pick up if you're already scripting. I think its big advantage for administrators is that it leverages .NET, and Microsoft is putting everything in .NET. Like I said earlier, you'll be able to totally run Exchange 12 through MSH, and hopefully the eventual Windows-specific release of MSH will let you really manage Windows more consistently and more totally than you can today.

Tulloch: What else do enterprise administrators of Windows networks need to know about scripting?

Jones: Just that scripting is here to stay. VBScript has been around since the mid-1990s and administrators are just now picking up on it, but every administrator needs to get into scripting. It's not going to be long before managers start making this a top item when they're hiring and promoting--I've worked with companies who are literally saving hundreds of thousands of dollars a year because scripting is making their existing administrators more effective, and eliminating the need to staff up. One company doubled their user base without adding administrators because they invested in scripting training and they do a lot of automation now. That's an argument a CIO or CFO can't ignore, and that means Windows administrators shouldn't be ignoring it either.

Tulloch: Finally, tell us a bit more about yourself. You recently worked at Microsoft--what did you do there? Why the change to Sapien?

Jones: I actually was never a Microsoft employee--a "blue badge," they call it--although it sure did seem that way! I did a lot of consulting work for Microsoft Learning, but I still did a lot of freelance consulting and stuff, too. The move to Sapien was really a desire to do more with and scripting education. With a company behind me, we're putting some great new training products together, including new video-based, self-paced training. I'm able to make it to more conferences to meet people and teach them whatever I can, and I'm able to spend a lot more time on just answering questions, posting tutorials, adding scripts to our ScriptVault, and so forth.

Tulloch: Any more books in the pipeline? Your was excellent, though the plot was a bit dull and the characters all seemed the same. ;-)

Jones: Yeah, I get that a lot. Advanced VBScript for Windows Administrators is out, as I mentioned, and that was a humdinger. It's a pretty hardcore book and it was a lot of work to get it together, but the response from readers so far has been amazing, so it was worth the time. I'm actually starting work on a Monad book right now. It'll be very focused on the needs of a Windows administrator, so it won't get all bogged down in the .NET stuff, but rather just teach you how to use the thing effectively. That should be out this year, around the time Exchange 12 ships, if not a bit earlier. I do a lot of writing for RealtimePublishers, too, and I'm doing some new eBooks for them on Windows recovery and administration. They're great eBooks and totally free--and I've got a scripting eBook with them, too, which is also free.

Tulloch: Thanks for your time, Don, and for being willing to share your expertise with O'Reilly readers.

Jones: You betcha.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.

Return to the Windows DevCenter.

Copyright © 2009 O'Reilly Media, Inc.