Blast from the Past: Monad (Premium)

With the release this week of PowerShell 7, I’m thinking back to this automation environment’s early days as a Longhorn Server project called Monad. And as it turns out, I learned about Monad—and met its creator, Jeffrey Snover, in late 2002, well before it was announced and several years before it was released.

I have a lot of Monad pre-release information in my archives, but I thought I’d share the following two editorials because they together tell the most important parts of this story. The first is an August 2010 retrospective that details Microsoft’s first disclosure to me and a co-worker, and I believe this represents one of the first, if not the first, times that Monad was discussed with company outsiders. The second is from February 2007 and discusses the then-coming initial release of Windows PowerShell.

But I also have my notes from that first meeting, numerous pre-release presentations, including one given to MVPs at the April 2004 MVP Global Summit that tracks very closely to what Microsoft discussed to us about a year and a half earlier. Snover and Microsoft had clearly been honing the message on Monad/PowerShell for some time.

Anywhere. Let’s jump in. I’ll add a few annotations in bold where it makes sense.

Bridging the Developer/Admin Gap

August 10, 2010

Way back in late 2002, I toured the country with Mark Minasi as part of a Microsoft-sponsored security roadshow. It was a blast for a number of reasons, but one of the more interesting things we did, but couldn’t discuss at the time, involved a side-trip to the Microsoft campus. There, we got a very early preview of Monad, which went on to become Windows PowerShell. We were told that Monad was a way for Microsoft to bridge the gap between the command prompt/Windows Scripting Host environments then offered in Windows with the BASH-type shells common in Linux/UNIX. “UNIX has been kicking our butts within the scripting world,” we were told.

We were told that by Darrell Ray, a lead program manager for Monad, according to my notes. Here’s the exact quote as recorded in those notes:

“Jeff and I conceived Monad as a way to deliver a rich command line scripting environment in Windows, like BASH not WSH [Windows Scripting Host]. Within the scripting world, UNIX has been kicking our butts. But with Monad, we won’t just meet UNIX, but leapfrog it. This was received [internally] with healthy skepticism.”

OK, I thought, but so what? The reason Windows had become so popular in the server realm as well as on the desktop was the GUI: In fact, early versions of Windows NT Server were specifically designed to let Windows end-users become Windows IT pros and admins, thanks to the familiar GUI. Where UNIX and Linux were inherently command line systems with a GUI on top, Windows was designed the other way around. So while there were (and still are) some things you can do from the command line in UNIX that aren’t possible with a GUI, the reverse has historically been true for Windows.

Monad–excuse me, PowerShell–seeks to change that. And in the years since its first release, many newer Microsoft technologies have been developed like UNIX tools, where the underlying capabilities are in fact PowerShell-based, and the GUI is simply a front-end to PowerShell. This type of design makes the most sense in products where automation is not just desirable but necessary, a key example being Exchange Server.

But the problem with PowerShell is that it’s so powerful as to be indecipherable to admins. In fact, it’s arguably a full-blown development environment. It consists of a command-line shell, a .NET-based, object-oriented scripting language, and a runtime engine that can optionally be embedded in other applications. For the typical overworked admin or IT pro, PowerShell might be a godsend if they could actually use it. But I was of the mind in 2002—as I am today—that most admins and IT pros have a completely different set of skills and are overworked as it is. To really take advantage of PowerShell, you need to be a developer or learn those skills too. And finding people who have credible administrative and developer skills is quite a trick. If you are such a person, maybe it’s time to ask for a raise.

Technically, of course, PowerShell is excellent, but that’s like saying a Porsche 911 GT3 is a great commuter car. It could be … assuming you knew what you were doing.

Microsoft can’t stop making solutions like this because, at its heart, Microsoft is a developer-run company. And this isn’t just because it got its start making and selling developer tools. Microsoft has always seen the world through developer-colored glasses, and it is always willing to tackle even the simplest of problems with complete, extensible, and finely documented platforms. It’s just in their DNA.

And now they’re at it again. Last week, at the annual VSLive show, Microsoft announced a new version of its Visual Studio development tools aimed at–you guessed it–admins and IT pros. Dubbed Visual Studio LightSwitch, this product aims to provide the simplest way yet to build business applications for both the cloud (using an Azure backend) and the Windows desktop.

I go on to described LightSwitch, but that’s sort of beside the point. That said, I did express skepticism about this product, noting that “I’m not sold on whether such a tool can ever really work well in the real world.” It didn’t work.

Real Admins Use the Command Line

February 6, 2007

When Microsoft was freely handing out certifications back in the mid-1990s to anyone with a pen and a heartbeat, there was a real concern that Microsoft’s certification program would become a joke of sorts, offering no real benefits to the certifiers or certified. And, of course, that’s exactly what happened. So Microsoft overhauled its certification program, made the tests and certifications more meaningful, and turned things around. But there’s still a strange stigma hanging over the heads of Windows-based admins. Unlike their UNIX counterparts, Windows admins are often perceived as being less technical, less knowledgeable, and, in some cases, even less employable.

This one is doubly interesting because Microsoft just killed its certification programs.

Well, those days are coming to a close. Through a strange series of coincidences, Microsoft appears to have warmed to the UNIX-style command-line interfaces that inspired the company to earlier go in a completely different direction with the GUI-based administration tools we’re familiar with in Windows. Part of this shift is common sense: Many repetitive admin tasks need to be scriptable, so that they can be completed more efficiently. Part of it was the rise of XML, a text-based descriptive markup language that is both standards-based and malleable from within text editors and scripts. And part of it, of course, is the maturity of Windows-based servers. Once Microsoft hit the high points, the company naturally began looking to fill in those areas in which its server products still lagged behind the UNIX and UNIX-like competition.

Let’s take a look at three examples of how Microsoft’s new command-line religion is dramatically changing its products, and for the better.

I’ve written a lot about Exchange Server 2007, Microsoft’s latest messaging server. There’s a lot to like about Exchange 2007, from its roles-based administration model and componentized design to its x64-based scalability to its comprehensive security features. But to me, the most impressive change in Exchange 2007 is that the server was completely designed around the Windows PowerShell (“Monad”) command line and scripting environment. Like a UNIX server, Exchange 2007’s GUI tools were built on top of this command-line interface (CLI), and not vice-versa as with all previous Microsoft solutions. This is a revolutionary change, and one that admins will immediately benefit from as they discover the rich capabilities of PowerShell.

The next version of Windows Server, codenamed Longhorn, includes a new Server Core install option that dispenses with the Windows GUI all together and provides a baseline of functionality that is perfect for infrastructure servers like DNS, DHCP, and so on. What’s truly interesting about Server Core, however, is that it represents the logical conclusion of Microsoft’s “secure by design, secure in deployment” mantra: Because Longhorn is componentized, Server Core, like all other Longhorn install types, includes only that code needed to generate the services it supplies. It is, quite literally, as secure as it can be. By stripping Windows to its most basic parts, Microsoft has limited what the server can do, but its’ also limited what can go wrong. Humorous bit: When Microsoft demonstrates this feature publicly, it routinely gets rowdy applause from admin crowds. You guys are such geeks.

Today, standalone, on-premises Windows Server installs are being deemphasized, and I was interested to discover last year that one of the two only supported new Windows Server versions comes only in a command-line, Server Core-style install. You can’t even add a GUI if you want to.

Finally, even Windows Vista gets into the CLI game, sort of. You may recall that previous Windows versions utilized a simple boot.ini file to determine the configuration of the system on boot-up. Though this behavior was determined by a text file, it was controlled via a GUI tool in the System Properties dialog box. In Vista (as in Longhorn Server), boot.ini has been replaced by a boot file named BCD (for Boot Configuration Data). It’s locked down, so you can’t edit it easily, and Microsoft–get this–only supplies a command-line tool, bcdedit.exe, for editing BCD features. BCD comes with a new set of terminology, naturally, and if you want to set options like the boot manager timeout or which OS options appear in the menu, you’re going to have to grok the command line. (I do expect, however, that enterprising admins will construct GUI front-ends to this.)

What this all means for Windows-based admins is that it’s time to bone up on your typing and scripting skills. There’s a brave new world out there, and if you want to take advantage of it, you’re going to need to leave the familiarity and comfort of the Windows GUI behind.