Beta Man

New Command-Line Option

MSH offers a powerful new approach to Windows command-line scripting.

• By Don Jones
• 01/01/2005

Microsoft has always taken it on the chin when it comes to command-line power. After all, Windows' strength is supposed to be its graphical user interface, not a bunch of cryptic command-line tools. But when Microsoft starts talking to enterprise customers whose administrators are used to Unix—where, despite the availability of graphical operating environments, command line is still king—Windows' lack of robust command-line administrative tools is perceived as a weak point.

Microsoft hasn't been sitting still on the command-line issue. Windows Server 2003 introduced more than 60 new command-line tools, and Windows Resource Kits have always been a source of additional utilities. The Windows Script Host (WSH), combined with VBScript, provides additional power to automate Windows administration through scripting. The popularity of VBScript as an automation tool has been on the rise, in fact, as evidenced by increased attendance at Microsoft TechNet Webcasts on the subject and the emergence of third-party Web sites (including my own, ScriptingAnswers.com) offering scripting resources to Windows administrators.

Supported, Built-In Scripting
For years, Windows has offered two basic types of scripting. The officially supported, built-in scripting is available through the same command-line shell, CMD, present in Windows since NT 3.1 was released. It's where we write batch files, launch command-line utilities and so forth. WSH is the other option, relying on languages like VBScript and Perl variants. Windows Longhorn will introduce a third new scripting environment, the Microsoft Shell, or MSH, code-named "Monad."

MSH is based on version 2.0 of the Microsoft .NET Framework, which is also currently in beta. MSH provides a radical new approach to command-line scripting, one that is powerful, extensible and much more consistent. It's also intended to be easier to learn for administrators, and easier for software developers to create new tools for. Ideally, application vendors will expose their products' functionality through MSH, ensuring a consistent, scriptable command-line interface that works across all products running on Windows.

The beta of MSH, by the way, can run on Windows XP provided you install the beta .NET Framework v2.0. I'm not aware of any plans to release MSH in advance of Longhorn, although it seems Microsoft could do so if it wanted to. The initial beta for MSH was fairly open, meaning a lot of people got to play with it, and a number of Microsoft employees posted extensive blog entries on the new shell. But what, ultimately, does it mean to Windows administrators?

Microsoft Shell (MSH) Code-name: Monad Version reviewed: Beta 2 Current status: Still in Beta Expected release: With Windows Longhorn; 2006 to 2007

A New Model
MSH is built around the idea of cmdlets, pronounced "commandlets," a concept borrowed from the Unix world. Cmdlet names are always in a verb-noun syntax, such as get-process. Cmdlets can also pipe to one another, which is an important concept. You can see piping work in the regular CMD command-line shell. Run something like dir | sort from a command line. The output of the dir command is passed, or piped, to the sort command, resulting in a sorted directory listing. MSH does the same thing, except that instead of piping raw text output from one command to another, it passes .NET objects between cmdlets. So the get-process cmdlet can pass a programming object representing an entire running process to another cmdlet, which might then do something with it.

Here's an example: get-process | where "handlecount –gr 400" | sort handlecount | format. The get-process cmdlet retrieves the currently running processes on your system. Those objects are passed to the where utility, which filters them so that only the ones with a handlecount greater than 400 remain. Those are passed to the sort utility, which sorts them on their handlecount. The results are piped to format, which formats the result and displays a list of all processes using more than 400 window handles, sorted by the number of handles they're using.

WMI and Providers
A lot of MSH's power comes from the fact that it relies on the .NET Framework, which in turn completely exposes Windows Management Instrumentation (WMI). Microsoft has been building WMI capabilities into everything these days: Exchange Server 2003, IIS 6.0, Windows Server 2003, Windows XP, Active Directory, DNS, you name it. Abundant documentation helps third-party developers expose their applications through WMI, making it possible for MSH, then, to obtain information about those applications and even reconfigure them, if they support it.

MSH's flexibility comes from its implementation of providers, such as the built-in providers for the file system, registry and even AD. These providers allow different databases to be accessed in a consistent fashion, meaning working with AD or the registry becomes no more complex than working with the file system. You can, for example, map a "drive letter" to the registry.

Scripting and Automation
MSH is fully scriptable. Here's a sample script from Microsoft's Channel9 Web site:

$phrase = $args[0];
$wd = new-object -activex "word.application";
$p = pwd;
if ($args.length > 1) {
$docs = $args[1];
} else {
$docs = "*.doc";
}
foreach ($a in $(get-childitem $docs -name)) {
$doc = $wd.documents.open("$p\$a");
if ($doc.content.find.execute("$phrase")) { write-host $a }
$doc.close();
}

This script accepts two arguments: A phrase you want to look for, and a Microsoft Word file in which to look for it (or you can omit the second argument to search all Word docs in the current folder). It then creates a new ActiveX (Component Object Model, or COM) object named "word.application," which is actually Microsoft Word. The $wd variable represents Word. The script uses the get-childitem cmdlet to retrieve the document names you specify. (You could specify a wildcard, to match more than one file.) For each file, it asks Word to open the document, then executes a Find command to search for the phrase you specified. If the phrase is found, the document's filename is output to the console. The syntax for the script is remarkably C-like, which developers love; administrators who find languages like VBScript to be more approachable may have a tougher time learning how to write scripts in MSH.

Beta Man's Routine Disclaimer: The software described here is incomplete and still under development; expect it to change before its final release—and hope it changes for the better.

Business Analysis
MSH promises vastly improved and more powerful command-line capabilities, which should definitely please Windows' command-line critics, or at least give Microsoft ammunition to defend the enterprise readiness of Windows. However, I suspect it'll be many years before the current crop of Windows administrators—who are, by and large, used to their graphical user interfaces and command-line tools—start to feel comfortable working in MSH for an extended period of time. That's not to say Microsoft shouldn't proceed full speed ahead with MSH; getting this technology into the Windows product builds a foundation for future generations of administrators.

Is MSH more powerful than existing scripting solutions like CMD.exe or WSH? Undoubtedly. Is it simpler to learn? Almost definitely not. Remember that MSH was created in large part to provide parity between Windows command-line capabilities and the capabilities found in most Unix variants, and Unix isn't exactly known for ease of use.

The mission of MSH seems clear: Provide powerful, flexible capabilities. If those capabilities come with a somewhat higher level of complexity, so be it. Longhorn won't be ditching VBScript or CMD.exe, so it's important to realize that your existing investment in command-line and scripting technologies isn't going to waste. MSH simply represents the next step up, when you're ready to take it.

Wanted: Betas for Review Beta Man is always on the lookout for quality products to review. If you know of a software product that is currently or soon to be in beta, contact Beta Man at [email protected]. Vendors are welcome, but please act early–the meticulous Beta Man needs plenty of lead time.

Reality Check
Should you bother learning more about MSH? Well, Longhorn is quite a ways out, of course, and right now it doesn't appear as if we'll see a final MSH until Longhorn is finished. And MSH is definitely a radical new command-line concept. History suggests most administrators don't have the time or inclination to learn all-new administration technologies right away; witness how long it's taken VBScript, which has been around since 1994, to start gaining popularity as a scripting tool. Right now, I'd say MSH is something to keep an eye on, but nothing you need to worry about for at least a couple of years.