Directions in Windows Scriptingby 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 ScriptingAnswers.com. 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.
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.
Pages: 1, 2