TechEd 2006: PowerShell, or, A Cure for All Your Right-Click Admin Nightmares

Thanks to the Microsoft AR folks, I had the chance to talk with Jeffrey Snover, architect for PowerShell née Monand. Once we got our dork credentials all settled out, we had a great hour and half or so talking about the architecture of PowerShell, some future ideas for PowerShell, Tom Bishop and Israel Gat stories, and other general systems management geekery.

In summary, PowerShell is perhaps the most exciting thing that I’ve seen coming out of Microsoft in the past few months. There’s only a little bit of exaggeration in that: while things like converting SharePoint to an MDM-stack are interesting, I have more faith in the PowerShell succeeding long-term based on its own merits instead of simply being what’s there than many of the other harvests in Microsoft’s upcoming bumper-crop. But that’s all for the next post on TechEd ;>

What is PowerShell?

If you haven’t seen a demo of PowerShell, or tried it out to yourself — it works on XP and Vista/Longhorn — here’s the shortest summary of it: Windows now has a real shell. To be frank, cmd.exe wasn’t ever really a contender against a *nix shell. It was only a few years ago that it had tab completion.

To be fair to cmd.exe, the power of the unix shell comes from three key things that cmd.exe doesn’t really have:

• 100’s of little tools that have had over a decade to mature, for example, as terrible as they may be to some, sed, awk, perl, etc.
• The pipe.
• A collective understanding among users and tools writers that each of these tools should play well with others.

In summary, The Art of Unix Programming.

Coming from a systems management, “let’s make the sys admin happy,” angle, the PowerShell team realized that Windows needed a command shell interface that would allow admins to do everything from the command line. No more Right-Click Admins, as it were.

The result is even more powerful than that: essentially, you because PowerShell plugs into the .Net runtime — the CLR, right? — you can sit at a PowerShell prompt and muck around with almost everything in Windows.

Even better, there’s a scripting language that you can use to manipulate the object instances you’re messing around with and you can pipe all of that around to other object/script combos.

For example, the demo we saw at MMS revolved around upping the amount of storage given to each email user. With a few commands, the demo’er queried for all the users, then passed in a closure (or “lambda,” as Jeffrey would say ;>) to that result set that upped the storage quota for each user. Compared to visiting each of the 100’s of users in the UI — right-clicking along the way, no doubt — this is unquantifiably faster.

Also, since most of the demos are done with a person interacting with a shell, it’s worth pointing out that you can programatically access PowerShell as well. That is, you can write code that uses PowerShell without having to screen scrape it.

Systems Management

I could talk about the cool stuff in PowerShell for several more pages, but there’s plenty of content available along those lines, including several videos from Jeffrey explaining PowerShell and then demo’ing it (both are tragically in WMV instead of MP3).

What I, and many of you, dear readers, are interested in is how you can use PowerShell to get a better foot-hold in Windows land. Of particular interest is using PowerShell in systems management as a substitute for the venerable Perfmon and annoying WMI interfaces/paths.

Perfmon is, of course, the friend of all systems management programmers who are adding in Windows to their platforms. It’s extremely straight forward, and you can write a JNI or other wrapper around it in the minim amount of code. More importantly, you can fire up perfmon.exe and use the resulting GUI to poke around at all the managed object and counters.

WMI, while it exposes more info is…well…weird. I shouldn’t bag on it too much since I was isolated from it for the most part thanks to others who had to use it, but it wasn’t quite as fun as perfmon. More importantly, WMI tended to have scaling issues when you were doing things remotely: if you wanted to pull over 100’s of records, well, it was have fun with that support call.

As the above, brief description should have alluded to, PowerShell can give you simpler access to all the things perfmon and WMI did. More importantly, the syntax and method for doing all this should be simpler — no WQL to hork around with.

The other advantage of PowerShell over previous management interfaces, Jeffrey told me, was that PowerShell has scaling built into it. So, if you’re operating over 1,000’s of objects, PowerShell will chunk out it’s interactions with those objects so that it doesn’t bring down the system.

Backing up a little bit, and to answer Chip‘s question from sometime ago, the next obvious question is: can I use this thing remotely? Not yet, but that’ll be a feature in 1.1. What gets crazy-cool with remote capabilities is the ability to execute commands over an aggregate of machines. That is, you could pool together several machines, and execute the same command over those machines. I assume that PowerShell will handle the load balancing and scaling problems, not to mention coordinating all this.

Now, what those two things mean is that — for the purposes of XP and Vista/Longhorn — you could replace all the Windows stuff you have with PowerShell calls…one would assume. Of course, you can’t chuck all that code: you’ve still got Windows 2000. The scaling and load-balancing that PowerShell has built in would, no doubt, be beneficial to all those times when WMI didn’t scale well. (You know what I’m talking about over there.)

Other Angles

As a replacement for using perfmon and WMI to do systems management, there are numerous other things that a real shell and programatic access to that shell makes possible:

• Systems management interfaces could “cross launch” PowerShell sessions to Windows machines for admins to check things out. For example, in a web based platform, you could make click on a URL like msh://admin:[email protected] to open up PowerShell and login to the remote machine. Wouldn’t it be swanky if IE 7 had that protocol built in?
• You could write an explorer, using the PowerShell API, that let you navigate the object instances in Windows. This is more for trouble shooting, but it’d be the kind of thing that sysinternals.com-type people love. Along those lines, check out PowerShellIDE.
• As you need more narrow functionality in PowerShell, you can write commandlets to extend PowerShell’s functionality.
• Jeffrey shows me how you can store little bits of data — cookies, really — on each instance. That is, PowerShell provides a way of saving state on the object instances it interacts with. Now, I’m not fully clear on the breath of this functionality, but in the maximal version, it means that your management software could leave behind notes for itself on objects. More importantly, different software using PowerShell could use those little notes to coordinate with each other. I’m sure it’s not just a general blackboard — otherwise, it’d get crazy and insecure — but even a shade of a blackboard is handy when you’re doing remote systems and coordinating ad hoc with little a priori knowledge.
• The combination of the snap-shotting, formatting, and diff’ing functionality opens up all sorts of fun things to do. You could take a snap-shot of some part of your system at a “good” point in time. Then, when something goes wrong, but you don’t know what, you take another snap-shot. Then, you can compare those two snap-shots, and see what’s different. Chances are, whatever is different is what’s causing problems. The formatting — to CSV and XML — allows you to pull out all this stuff into other systems as needed. If this one doesn’t make you drool, you must be normal, cause systems management whack-jobs dream of that kind of stuff.
• Using the aggregating functionality in 1.1, you could do bulk-management operations like turning on the SNMP Agents for a large group of boxes instead of going to all those machines individually to start it up. In fact, you could probably write a script that handled various exceptions in turning on those agents. Now, parts of that that would certainly be possible using even net start or writing your own code, but scripting it isn’t really part of the game at the moment.

Put more abstractly, once 1.1 is out and enabled remote operations, it’ll be much easier to do both monitoring and management of Windows.

The Bad

For all that excitement, there are several troubling points. In outlining them, it’s good to remember that PowerShell is just barely 1.0. Pointing out flaws in 1.0 products is a bit unfair. But, looking at it from a higher level of concerns is still useful:

• I haven’t, nor, more than likely, will I in the near term, used PowerShell. That’s because I run a OS X. PowerShell, of course, runs only on a Windows. Again, we want to apply Metcalfe’s law, but we can’t. That said, I wouldn’t be suprised if the Mono crew or someone else whipped up something like MorePowerfulShell. At the very least, once remoting comes out in 1.1, it’d be good to see clients released for OSX and Linux. Sure, you’d just be connecting to a remote Windows box, but, hey, that’s better than terminal servicing into it. More importantly, we’d want programatic access via the client.
• Which gets to the language problem mentioned above. I don’t believe Microsoft has any intentions of providing Java or other wrappers.
• There isn’t a spec for other people to run with to write PowerShell for *nix or OS X. I know that may sound nutty, but I can see that people will start thinking, “man, I wish I had this for my Linux systems.” Now, as Jeffrey pointed out, PowerShell is itself very reflective and introspective. You can tell PowerShell to expose itself to you, letting you figure out how it works. The syntax and functionality is all out in the open for people to find.

Those are the kinds of things I tend to ask Microsoft people, and I should probably have learned my lesson by now: the answer is, 90% of the time, “no.”

Still, for being tragically trapped in the Windows silo, I’m still excited by PowerShell, something I’ll probably use only rarely when I’m unlucky enough to be out of my own ghetto.

What to Do If You Care

Non-Microsoft stack people will need to write wrapper libraries to access PowerShell. For example, we’ll need a Java wrapper. I don’t think Microsoft intends to provide these wrappers, which seems like a tactical error in that you’re cutting yourself off from a Metcalfe effect: the more ways you have to access and do things with Windows, the more value there is in Windows. But, hey, that line of thinking isn’t really Microsoft’s thing.

And, anyhow, it’s ripe for an OSS project. It’d be wise for one of The Big 4 to start that project up and lay down the initial version. It’d certainly bring some good will with the OSS crowd, in an interesting way. Other than that, the reason is simple: you want the functionality on PowerShell, but you don’t want to spend the effort to maintain that kind of wrapper on your own and, more importantly, you’ll never be able to catch all the errors and update it will require was fast enough as an OSS community would.

It’s not only the systems management people who’d benefit. In reality, I’m guessing PowerShell could be used as a tunnel into Windows-land in general, for example, all that out-of-the-box Active Directory integration we tell everyone they should have.

(Apologies if the above is a bit raw, I was in a hurray to both go get some groceries for tonight and post this: “Great pate, mom, but I gotta motor if I wanna be ready for that funeral.”)

Disclaimer: BMC, where Chip, Israel, and Tom work, is a client. As is Sun. Microsoft isn’t at the moment, though they did pay my T&E for TechEd and fed me well, both with good and content: Mr. Snover is quite awesome.

Tags: jeffreysnover, monad, msh, opensource, powershell, sysmgmt, teched, teched2006, windows