Here's What PowerShell is All About

I can across this today - ironically, in a post offering a PowerShell tip:

Wow. That's some anger. I'm wondering why the author decided to write about PowerShell! There was also this comment in an article I wrote:

That's a pretty articulate statement, but I think it's based on a misunderstanding. So let's try and clear up some facts about what PowerShell is and isn't.


PowerShell isn't a Scripting Language
I've said this before, but let's be clear about it: While PowerShell does contain a simplified scripting language (about 20 keywords, compared to the 200+ in VBScript, for example), you don't need to be a programmer to use the shell effectively.


PowerShell isn't a Command-Line Interface
This is kind of a secret, so don't let on that I told you. In reality, PowerShell is a set of .NET Framework classes - an "engine," if you will. The cmdlets you're used to seeing are also .NET Framework classes, written to a specific standard. PowerShell's engine instantiates those classes, and calls methods within them to make stuff happen. 

One way - just one, mind you - for you as a human being to interact with PowerShell is through a command-line interface. You type cmdlet names (e.g., instantiate classes), add parameters to them (setting properties of the class instances), and press Enter (thus calling the methods that make that class do stuff). 

I guess it's fair to call PowerShell a CLI, since that's it's most visible means of interaction. But the fact that it really isn't a CLI is kind of important to understanding why everyone is so excited about it.


GUIs are Nice for Specific Reasons
As the two comments above highlight, a GUI is great for making unfamiliar tasks more convenient and easy to learn. They do simplify your life. Where GUIs don't work so well is when you need to repeat some task across a hundred servers. Honestly, folks who only have to worry about a handful of servers might never touch PowerShell's CLI. That's fine. 


Servers Don't Need a GUI
I don't understand what all the fuss is about the GUI eventually going away from the Windows Server operating system. Look, are you currently administering your Exchange Server by logging onto the server console via an RDP session? I hope note. It's far easier to just install the GUI console on your workstation, right? In that scenario, the GUI lives on your computer, but most of the functionality is still happening on the server, right?

This is the same with something like Outlook Web App. The GUI lives on your client, courtesy of your Web browser; the functionality lives on the server. You wouldn't tell your users to RDP in to the server to access their mailboxes, would you?

The only legit reason to RDP into the server console is because you need to perform some task that can't be handled by the remote GUI on your client. That can happen a lot these days, but it's a scenario Microsoft is working very, very hard to solve. Their goal is to provide you with remote tools to manage your servers. If they do a good job, then you won't NEED a GUI **on the server** because your tools - including a GUI - can live on your client.


PowerShell isn't Making the GUI Go Away
As a .NET Framework developer who is writing a management GUI, I have two tasks: I have to make the GUI itself (tree views, buttons, toolbars, and whatnot), and I have to make the bits of the GUI work. That is, I have to write whatever code is needed to actually make the administrative stuff happen.

Almost inevitably, I (again speaking as a developer here) am going to have to write some command-line tools. While a GUI is great for getting things done, it's grossly inefficient at repeating them over and over. This has been the case since the first version of Windows Server shipped - look at how popular the Resource Kit utilities were, back in the day. So now, as a developer, I have to write that administrative functionality TWICE - once for the GUI, and once for the command-line stuff. That's time-consuming and annoying.

Now, as a smart IT person, you might just say "why not modularize your code, stupid developer?" And you'd be right in saying so. I should put my actual functionality into a DLL or something, which could then be called on by a command-line utility OR by my GUI console.

Folks, that's what a PowerShell cmdlet is. It's a class that lives inside of a DLL. It can be called upon from any .NET Framework code, including a GUI. Look at the Exchange Management Console in Exchange 2007 or 2010 - it's a GUI that calls PowerShell commands under the hood. It isn't "shelling out" to run batch files and stuff in the background; it's actually linking to a DLL that contains all of the Exchange commands, and running them internally. PowerShell.exe never actually gets executed by the EMC.


So one reason that "PowerShell fever" is sweeping the industry is that it's a more efficient way for developers to (a) give you the GUI you want while also (b) giving you command-line options that provide more direct automation. It isn't that companies are trying to "race" to see who can "add more PowerShell," it's that PowerShell is a more efficient way for them, as developers, to provide both interfaces (GUI and CLI) that their customers are asking for.


Windows Has to be a Lot of Things to a Lot of People
Why all this effort? Why couldn't Microsoft just leave the GUI in place?

Because Windows has to work in a ridiculous number of vastly different environments. It has to be accessible to the small business IT Pro, who may be the entire IT staff, and who doesn't have time to be a deep expert in anything. Instead, he or she needs to be a "jack of all trades," working in Exchange, SQL Server, Active Directory, SharePoint, VMware, and who knows what else. The GUI is a lifeline for this person, and Microsoft must - and will - continue to provide a GUI that works.

But Windows also has to work in huge enterprises, where administrators specialize. There's an Exchange admin, a SharePoint admin, a file server admin, an AD admin. These admins are responsible for dozens or hundreds of servers, and the GUI is too inefficient. They need automation, and that's easier to achieve from the command line. Microsoft has been taking a beating from these guys, because Microsoft's command-line efforts to date have been spotty. Thats' what happens when you're trying to build a GUI and command-line tools separately: You end up making compromises and tradeoffs about which functionality gets put into either form. With PowerShell, there's no tradeoff: Both the command-line and the GUI can be fully-functional, because they both rely on the same underlying set of DLLs to provide the functionality.

So when you're saying, "just leave the GUI in place!" you'er basically saying "screw all those admins who are killing themselves trying to make the GUI work in a huge environment!" On the other hand, saying "kill the GUI!" is saying "screw all those admins who have to wear fifty hats!" Microsoft doesn't want to screw anyone (at least not in this regard), and PowerShell is their way to make both audiences happy.


PowerShell, Then, Means Different Things to Different People
If you're in a large company and managing hundreds of servers, PowerShell is your command-line interface. It's your means of automation. You'll likely still use a GUI for infrequent stuff, though, because the GUI is easier than figuring out the command-line syntax. But the command-line will always be an option for you.

If you're in a smaller environment, where Windows' key value is the fact that it looks and works just like your desktop OS, then PowerShell might not be a visible part of your life - but it'll be underneath the GUI you're using. I have a colleague who's a Small Business Server (SBS) MVP, and she doesn't think she'll be spending a lot of time with PowerShell. After all, the whole value-prop for SBS revolves largely around its big, integrated GUI, and it's tailor-made for environments that, almost by definition, have very few servers to manage.


Will Management Believe the Hype?
I will offer you one bit of caution, though. Ask yourself if clicking buttons in a GUI is the sole value you bring to your organization, and if that value is sufficient enough to justify your continued employment. In some environments, a hearty "yes!" will be the answer, and that's fine. Just understand that not EVERY environment will fit that model. PowerShell, for the first time in Microsoft's history, gives YOU the CHOICE of how to administer Windows. Don't be bitter or alarms or angry about that. Be happy. Stick with your GUI if you like that - but know that, for the first time, you're not being forced to do so.

Of course, this brings up an inevitable question: If this PowerShell "hype" gets widespread enough, will management start looking at is as something they must have? Will you be FORCED to learn it?

Possibly. Management is all about efficiency, and although PowerShell has a decently-steep learning curve, once you pass that it's definitely more efficient than a GUI. You should have a discussion with your boss(es) about efficiency, and whether or not using PowerShell as a CLI makes sense in your environment. Sometimes, the answer will be "no," and you can go right on using the GUI. I can tell you this, though: You're limiting your career. If you ever decide to change jobs, and what's available are positions within larger environments that rely more on automation, a lack of PowerShell skills is going to prove fatal. If you're happy where you're at, though, and where you're at doesn't need CLI skills, then ignore the CLI. You'll probably be fine.

I'll mention one more thing, though: IT is an industry that's about change. If you got into the IT industry, you hopefully knew that at the time. Nothing is static. Windows has a powerful CLI now. Businesses are increasingly looking at "the Cloud" to solve specific problems. I've already known several folks who've gotten ground under the tank treads for choosing not to change, rather than embracing change and making a place for themselves in the changed world. Please don't let that be you. Maybe PowerShell truly won't matter to your career - fine. Just make sure you're making that decision based on the facts at hand, not from a dislike of having to learn something new.


Thanks, Microsoft.
In PowerShell, Microsoft has come up with a truly elegant solution to their biggest problem: Meeting the needs of a huge variety of administrators in very different environments.