In his blog at http://4sysops.com/archives/free-windows-powershell-book-or-why-powerscript-would-have-been-a-better-name/, Michael has a lot to say about his first thoughts about Windows PowerShell. Unfortunately, I think he may have missed a few salient points, and may just not “get it” yet. That’s easy to do with PowerShell – it’s a new way of thinking about things, and it requires you to acknowledge some realities about Windows that many administrators just aren’t comfortable owning up to.
Actually, you could also say, it is an introduction into Windows Powershell from Microsoft. When I skimmed over the document, I came once again to the conclusion that Powershell is not really a shell, but just another scripting language.
It’s actually both, just like the shells used by most Unix admins (Bash and so forth). You can do incredibly powerful things with PowerShell without writing a line of script “code.” In fact, Cmd.exe is the same thing, no? It’s a shell, but it does have a (primitive) scripting language embedded in it, as well. I’m not sure a “skim” is the best way to learn about PowerShell <grin>!
This is at least true if you take the original meaning of the term “shell” which is just a user interface. Of course, you can also use Powershell on the command prompt. However, I doubt that many Windows sysops will really do this.
Wow, I couldn’t agree more. Why do most Unix admins choose to work from a command shell? Easier, more consistent, more efficient. Why have Unix admins always given Windows a hard time in manageability brownie points? The lack of a cohesive, complete command-line shell. I’ve been flying all over the country in the past few weeks – and will fly more in the weeks to come – teaching eager Windows sysops how to use PowerShell, and they’re loving it. Funny you should use the word “sysop,” in fact, Michael – I didn’t think anyone did anymore! But just this week I was teaching a bunch of sysops who work for Google (yup, they use Windows, and lots of it) how to use PowerShell – and believe me, they “get it.”
Consider this example from the book which lists processes by its name and CPU time:
get-process | ForEach-Object { write-host $_.ProcessName $_.CPU}
Who really wants to type such longwinded commands? Yeah, you could also just use “get-process” to get a (different kind of) list of processes. But why not just use task manager for this? The point is, you usually need such a formatted list of processes only if you want to use it as input for another command. And that’s what I call scripting and not working on the command shell. Therefore, a better name for Powershell would have been “Powerscript” in my view.
It’s easy to think thaty when you’re getting started. But consider this: You know what that’s doing, because those long-winded cmdlet names are very clear about what they’re up to. And if you want pithy:
ps | select ProcessName,CPU
Short-winded enough? As with any product, you do have to take the time to learn how to use it properly and efficiently. That was the case when you started learning Windows’ graphical user interface, as well, and the same applies for PowerShell.
I think that Windows doesn’t really need a powerful command shell because it has very powerful GUI tools. This is the main difference to Linux. However, there are some tasks you can’t even do with a powerful GUI. But then they are usually so complicated that a longwinded command won’t be of help either. That’s were scripts come in.
Well, I just couldn’t disagree more! Let’s take a simple example: Changing the logon name a service uses. Can’t do it through the GUI, and with PowerShell you don’t need to write a script. You can do it in one nice command line – if you know how to use the shell. Yes, learning is involved – it’s the IT industry; learning will always be happening. Windows’ GUI, as I’ve said, makes Windows easy to use for one-off tasks; when you need to do something in batch, or consistently, or when the GUI presentation happens to be complex, Windows falls down. Yep, it’s a major difference from Unix or Linux – and it’s why those guys kill us in enterprise manageability. Hence, PowerShell.
On my blog someone asked why Sever Core doesn’t support Powershell. The official answer to this question is that Powershell needs .Net which is not supported by Server Core. Another reason is that Server Core wouldn’t probably benefit much from Powershell because it is a scripting language and not a command shell.
Michael, with all the respect in the world, you’re just dead wrong. It is a command shell – I suspect you just don’t have enough experience with it yet to realize that. You’re right in that Server Core won’t run PowerShell because of the .NET requirement; hopefully that’s something Microsoft will work on. However, I’ll suggest this: Windows admins need to get the heck out of this habit of managing servers from the servers’ console. Server Core is intended to be “headless;” you don’t log on to its console. You manage it remotely – something you could really do with any Windows server; Server Core just pushes the point harder. If you’re actually walking into your data center, you’re working too hard.
Now, leaving Michael alone for a minute, I want to make an observation: For folks whose chosen profession is an always-evolving one (e.g., IT), Windows admins seem remakrably reluctant to change their ways. Managing servers by logging onto the console has been a ridiculous, time-consuming, error-ridden process for years, and since at least 2000-2003, it hasn’t been necessary. Managing entirely from a GUI is also inefficient and inconsistent, although to date it’s still necessary – although PowerShell is the start of that changing. It’s frustrating for me to see people still doing things like walking into the data center to reboot a machine, or change a service, or create a user – but they still do it. Folks, if you decide you want to be stuck in time and use products like Windows in the most inefficient way they allow – well, more power to you! But products like Windows PowerShell are intended to fix what the rest of the industry has long perceived as grave shortcomings; if you don’t think a GUI is inefficient or inconsistent, then you don’t have to change – but recognize that tens of thousands of people disagree with you, so there’s the slightest chance you might be mistaken.
I hope every Windows administrator takes some time to really learn what PowerShell is about (not just a quick skim, although that’s certainly a great start). Be a professional in the IT industry. Accept that the way we’ve always managed Windows isn’t because that way is better – it’s because that way is all we had. Turn to operating systems like Unix – which have a 20-year head start on us in manageability – and learn a few lessons. Take the best of what they offer, and keep the best of what Windows offers – which is why I truly believe PowerShell is doing.
Don – I can still remember when you were nearly as skeptical.
You are right – it does take users/admins a while to "get it". Once they see what is truly innovative then they are hooked.
I was lucky to have been in on the beta along with some very smart and creative people. Their posts in the beta forum very quickly convinced me that Monad (PowerShell) was different.
It’s a "shell" and not a "shell game".
It’s a script engine too.
Two. Two. Two mints in one!
Wow that’s really a comprehensive reply to my post. I didn’t know that my little comment would provoke such reactions. First of all, I don’t have a problem with working on the command line. I also work with Linux boxes, and usually we don’t even install a GUI on them. The reason for this is that Linux is just made for the command line. But Windows is different and Windows sysops are different, too. They simply don’t like typing. That’s why they prefer Windows and are not Linux geeks. PowerShell won’t change much about this. And that’s why PowerScript would have been a better name because most Windows sysops will use it only for scripting. I am sure you’ll find a GUI tool for almost any task you can perform on the command line. All the tasks in your examples can be done with Windows GUI tools. No admin would ever go to the server room to reboot a server, for instance. As to the term “sysosp”, I know that it is an old-fashioned expression, but I never liked “Administrator”. We don’t really administrate machines like civil servants administrate people. We operate machines. This is the reason why my blog’s name is 4sysops.
"Changing the logon name a service uses. Can’t do it through the GUI"
I must not be understanding what you’re saying, because it’s pretty easy to change the logon name a service uses through the GUI. Mind you, I love Powershell, so this is just an observation.
Changing the logon name on multiple remote machines, I should have said.
to Michael: Your basic assumptions about Windows admins seem to be wrong. That assumption may hold true for the guy who manages 2-10 servers and does all the other IT support as well but it isn’t true for those who manage more.
There isn’t time to pull a report on a specific set of users by hand though the GUI tools on 20-2000 users. You use a tool, but if you are a small company you can’t afford to buy one, so you turn to scripting or other cmdline utilities (joeware, pstools, MS resource kit, vbscript). These tools allow you to automate tasks, reports, monitoring in a way that reduces your workload but dramatically increases your productivity.
vbscripts a pain, but look at the wealth of scripts developed for it. http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true
Have the admins where I work know or use vbscripts, most of the rest have a variety of cmdline tools and techniques they use daily.
PowerShell looks to solve those short comings in vbscript. I even recently found a nice article on managing Exchange 2003 through WMI that will vastly simplify our vbscripts we use to pull reports now. I can’t wait to figure out how it all works together.
http://thelazyadmin.com/blogs/thelazyadmin/archive/2006/03/23/Using-MSH-With-Exchange-2003.aspx
The GUI interface is fine for one of configurations, occasional tasks but for managing anything larger, it’s just not sufficient. "Just don’t like typing", that’s just to funny. 🙂
"But Windows is different and Windows sysops are different, too. They simply don’t like typing."
That’s definitely true for some – but definitely not true for all. In fact, in my experience, the ones who don’t "like" typing are also less likely to have a really good grasp on what’s going on under the hood – which impacts their effectiveness in a lot of ways. Not all – just many, in my experience.
"That’s why they prefer Windows and are not Linux geeks."
Oh, I don’t think typing is the whole reason.
"PowerShell won’t change much about this."
Actually, I bet it will. You’ll still have GUI admins, but they’ll on the whole be less experienced and less effective – and less desirable for employers. I think THAT – the desireability for employers – will keep more Windows admins interested!
"And that’s why PowerScript would have been a better name because most Windows sysops will use it only for scripting."
Wow, that’s a broad statement. I have about a hundred customers I’ve mine I could point you to who would disagree most emphatically. They’re mainly using PowerShell as a command-line shell, and doing very little scripting, and are liking it a lot.
"I am sure you’ll find a GUI tool for almost any task you can perform on the command line. All the tasks in your examples can be done with Windows GUI tools."
Yes, if you want to LOOK. But why should I have to have all these little "point solution" tools when I can have one shell that does it all? I don’t want a Start menu full of little utilities – I want one place that does everything. Which WILL (not yet) be PowerShell.
"No admin would ever go to the server room to reboot a server, for instance."
Hah! Yes, they do. Some do. I’m glad you don’t.
"As to the term “sysosp”, I know that it is an old-fashioned expression, but I never liked “Administrator”. We don’t really administrate machines like civil servants administrate people. We operate machines. This is the reason why my blog’s name is 4sysops."
Hey, I *like* "sysop." I started out as an AS/400 sysop and always wondered why the term went away!