Before there were GUIs, administrator interaction with computers was handled solely through text-based command-line interfaces. For years, Microsoft was pummeled by UNIX administrators who insisted that without a "real" scripting language, Windows was just a toy. Microsoft responded over the years by beefing up the built-in Windows command interpreter and building the Windows Scripting Host (WSH), a core system component that lets you write scripts in VBScript, Perl, Python, or other languages. When you couple WSH with the Windows Management Instrumentation (WMI) interfaces, you can do a lot of useful work from scripts.
However, WSH is missing a key feature of UNIX-style shell and scripting languages: composition, or the ability to create a complex command out of several smaller commands. This simple example
find . -print | xargs grep "onad" | wc -l
tells the UNIX command shell to find all the files in the current directory and its children, search them for the string "onad", and return a count of the number of files found. The find, grep, and wc commands each do one thing, but combining them with the pipe character (|) operator makes it easy to pass the output of one command to another. UNIX tools are generally designed to be small and limited in scope, so by stringing them together you can accomplish complex tasks fairly easily. WSH and the Windows command-line tools Microsoft gives us now don't really provide this same capability. As a result, it's hard to do things from the command line without writing an entire interactive script.
I've written before about Microsoft's new scripting environment, code-named Monad, but after using it for a while I'm happy to report that it solves this problem very well. Monad uses regular syntax (commands have a verb followed by an object--e.g., get-mailbox or get-WMIobject). In addition, it passes structured data objects, including attributes, between commands instead of just passing text. That means that you can use a rich set of Monad features to parse, display, and filter the results of commands. If you've used Joe Richard's (joeware--http://www.joeware.net ) AdFind and ExchMbx commands, you'll understand what it's like to be able to use command-line tools in this manner.
How can you get started? Microsoft hasn't yet shipped a public beta of the Exchange extensions for Monad. However, you can download the beta version of the Windows Monad shell from Microsoft's Web site and get started playing around with it. The Monad team blog (http://blogs.msdn.com/monad ) has some good introductory material, although you have to dig for it a bit.
For more depth, I recommend Andy Oakley's book from O'Reilly Media, titled (what else?) "Monad." It's not a long book, but it's a good one, with plenty of examples.
After you have experience using the Monad shell, there's a lot of neat stuff you can do. For example, Exchange MVP Glen Scales shows how to use the Windows Monad shell to interrogate Exchange objects with WMI at http://gsexdev.blogspot.com/2005/11/using-monad-and-wmi-with-exchange-2003.html . You can also use Monad scripts to create and modify any object that's accessible through the Microsoft .NET Framework, including windows, menus, and tons of other stuff. Monad offers enough customization and tinkering potential to keep you busy until Microsoft releases the first beta of the Exchange version, at which point you'll be ready to take full advantage of it.
In closing, I want to say "au revoir" to my friend and editor, Lisa Pere. She's leaving Windows IT Pro to take a new job with a literary agency, and I'll miss her. Best of luck, Lisa!