Way back in late 2002, I toured the country with Mark Minasi as part of a Microsoft-sponsored security road show. 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 (WSH) environments then offered in Windows with the Bourne Again Shell (BASH)-type shells common in Linux and UNIX. "UNIX has been kicking our butts within the scripting world," we were told.
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. 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.
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 PowerShell based and the GUI is simply a front end to PowerShell. This type of design makes the most sense in products where automation isn't just desirable but necessary, with a key example being Exchange Server.
But the problem with PowerShell is that it's so powerful its indecipherable to admins. PowerShell is 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 typically overworked admins and IT pros, 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're such a person, maybe it's time to ask for a raise.
Technically, 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 is always willing to tackle even the simplest of problems with complete, extensible, and finely documented platforms. It's just in its DNA.
And now Microsoft is 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 back end) and the Windows desktop.
LightSwitch isn't available yet—the first beta is expected late this month—so I can only go off what Microsoft has publicly demonstrated so far. What I've seen reminds me of the video game "construction set"-type products that were popular a while back. You basically piece together forms from templates and bind them to back-end data The question is going to be how powerful this is on its own and when code will actually be required. If it's too code-heavy, you're in PowerShell territory—useful, yes, but too much for the average admin.
I'll reserve judgment on LightSwitch until I've seen it in action, but the only surprising thing about it, really, is that we were surprised by it. This is exactly the type of tool Microsoft loves to makes, and while I give the company credit for trying to expand the capabilities available to admins, I'm not sold on whether such a tool can ever really work well in the real world.
Windows 7 Deployments Follow-Up
I'd like to take a moment to thank everyone who wrote in about their Windows 7 deployment experiences. The sheer amount of feedback I got was overwhelming and much appreciated. I'll try to work some of it into a future article about Windows 7 deployments, probably in early September. (I still need to talk to a number of Microsoft partners about their experiences. This will be difficult while I'm on the road, so I'll try to schedule that for the end of the month.)
