Scripting occupies the gray area between administration and programming. Used primarily by administrators, scripting lets them quickly and efficiently perform routine tasks in a way that's less prone to errors than using a GUI is.
Although it requires many of the same skills that programming does, a scripting project's scope is typically much smaller than that of a true programming endeavor. Scripting tasks are usually very focused actions (e.g., adding a user or printer), and scripting a solution doesn't require the level of complexity and power that a full-blown programming effort demands. And, because the script writer is often an administrator, error handling and UI concerns aren't the formidable considerations that they are in most end-user-oriented programming applications.
These differences mean that script writers need a different set of tools than programmers do. Microsoft provides a set of scripting tools, but those technologies are in need of a major update.
A Tale of Two Technologies
The two primary Microsoft scripting technologies for Windows administrators are command shell scripting and Windows Script Host (WSH)/VBScript. In spite of my familiarity with and fondness for command shell scripting, calling that technology a bit long in the tooth is more than an understatement. Although Microsoft pays lip service to the continued importance of command shell scripting, it's the stepchild in the family of Microsoft scripting technologies—Microsoft doesn't even mention command shell scripting in the 1200-plus-page Microsoft Windows 2000 Scripting Guide. But administrators like command shell scripting for its ease of use—it's simpler than most other scripting technologies and doesn't put big hurdles in the path of prospective script writers. However, the technology is outdated and isn't as powerful as it needs to be. Command shell scripting incorporates very little in the way of flow control and logic and offers no debugging tool to speak of other than using the Echo command.
Despite being Microsoft's favored scripting technology, WSH/VBScript never took the world by storm. Many administrators consider WSH/VBScript to be too much like Visual Basic (VB), complete with all the complexities of a programming language. Although WSH/VBScript is far more capable than command shell scripting, it lacks built-in functionality and too frequently relies on external COM objects. Sure, learning the VBScript syntax is relatively easy. But before you can solve your problem, you need to find the necessary COM objects and learn how to use them—and some of those objects, such as Microsoft Active Directory Service Interfaces (ADSI) and Windows Management Instrumentation (WMI), aren't all that simple. Furthermore, WSH's/VBScript's similarity to VB doesn't extend to having a good set of debugging tools.
Overdue for an Overhaul
Considering that Microsoft recently upgraded its development platforms by converting to the Windows .NET Framework and is planning a new release of Windows (code-named Longhorn), now is a great time for the company to introduce a new scripting technology. Ideally, the new environment would combine the ease of use and built-in functionality of command shell scripts with the power and flexibility of WSH/VBScript. Because Microsoft has shifted its development efforts to Microsoft .NET, it could base the new tool on the .NET Framework and incorporate some decent debugging capabilities.
Microsoft is rumored to be working on a .NET-based scripting environment code-named Monad. From what I've heard, however, Monad exceeds the scripting complexity of VBScript in the same way that Visual Basic .NET is more complex than VB. Above all, a new scripting tool should be simple enough that administrators can learn it as easily as they did command shell scripting. It shouldn't be a tool designed for programmers—Visual Studio .NET already fills that role nicely.
Scripting is a vital administrative activity. With a new version of Windows on the horizon, now is the time for Microsoft to overhaul Windows scripting.
