PowerShell pusher to log off from Microsoft: Write-Host "Bye bye, Jeffrey Snover" Jeffrey Snover's lengthy and occasionally controversial term at Microsoft is to come to an end this week, as the PowerShell inventor sets off for pastures new after more than two decades at the Windows giant. After 22+ awesome years at Microsoft (18+ of which were awesome in a good way 😂 ), it is time for me to try something …
Well users loved the move away from a command-line (D)OS so admins must have been the same, right? RIGHT?
No, MS, absolutely not!
You can always tell an admin apart from a user because we, the former, have a tendency to drop to shell (be that PS or CMD) to do things in Windows - whatever the version.
Yes, and there are things that require a few clicks in a GUI and an inordinate amount of typing in a CLI - when you can remember the commands and you don't have also to look them up somewhere, and higher risks of mistyping something and cause havoc.
Need to add a single AD user? Set directories or file permissions? Far faster to make it in a GUI - unless it's a web one.
While I fully understand the need to be able to script some tasks (but PS took really the wrong way relying on .NET and with a ugly syntax) - when you need to perform some "casual" administration a GUI is usually faster and tells you where settings are and how to modify them.
The fact Linux is stuck in 1970s technology and make some admins feel they are endowed with arcane powers is not a good excuse to make systems more difficult to manage.
Exchange is really a good example of a system that became a mess - as long as the script works it looks mostly OK, when they start to throw errors... No surprise people prefer to use its cloudy version
Both CLI and GUI are useful and can speed operations if properly used.
Most tasks involving shoving folders around are easier by drag-and-drop than typing out full folder paths. Especially since paths and filenames grew to biblical proportions.
But then as noted in the examples above, renaming a folder full of files in bulk is easier on CLI.
Windows loses out on usability over other platforms because of the over-complex morass that is the registry and active directory IMO. But those same tools with front-ends slapped over are popular in many applications and business; for better or worse.
The positively ancient CMD CLI needed an overhaul, and for better or worse powershell is that overhaul. Powershell cannot solve "registry" or other dumb design decisions. It can make them easier to live with.
I am totally all about the command line
I am constantly scripting in cmd , vbs (dont laugh it still works) and c#
I F*&^*g hate powershell though and use it only as a last resort and it only get subbed in to do the one thing from another script
those little egglet things or whatever ... uirggh
Personally I want both! Yeah I know, wanting my cake and eating it. :)
For something I'm unfamiliar with or don't touch very often the GUI is always king, having the ability click around the UI until I find what I'm looking for (because invariably I know what it is, I just can't remember what they call it)... and crucially a fully functioning GUI, not the half arsed Exchange GUI where you can only view a subset of the information.
But for regular tasks and automation command line and scripts win out every time, both in speed, and also when scripted in consistency since you can ensure the exact same options are selected every single time.
when a totally unrelated update from MS removed the MSCS component in Powershell and totally nuked the cluster we had just set up. It halted a deployment for almost two weeks while MS said there is nothing wrong for days but eventually a new release of the update was received. Summer in Chennai is not nice.
He maybe going/gone but he won't be forgotten... At least that was when I finally waved the white flag and decided to retire. F*** this for a game of soldiers.
It is how you use it. I prefer to write in Powershell 5.1 "without needing extra modules whenever possible". Not really a moving target since 5.1 is from 2016, and is available fro Server 2008 R2 up to Server 2022.
Without extra modules means, for example: I don't need that NTFS-Access thingy, get-acl set-acl and the methods bound to $acl are enough, and in many cases more efficient since you can get-acl, alter the $acl x times until it fits to your need, and then apply the final set-acl in one go. Pretty much like you do in explorer: Change around x times, and THEN you hit apply, instead of hitting apply after every step.
I wonder how much of the GUI/CLI split is down to how different people remember information?
Personally, if I've not used a command for a a few months, I've generally forgotten the syntax and have to look it up. Exact text just doesn't stick in my brain.
On the other hand, my spatial memory is good, so I can use a GUI I've not touched for years and still find the option I need. Even when the GUI has changed it doesn't slow me down much because I've got some memory of all the other GUIs I've come across and can make an educated guess of where best to look. Plus the first thing I do in any new software is find the settings and see what I can change.
Back in the 1980s we had SCL running programmatic automation on ICL VME systems.
The long gap between then and Powershell on Windows was far too long for my liking. So well done Mr Snover for standing up to the naysayers.
Programmatic Automation Rocks!
My son, one day you will grow up and realise that all are welcome in the Church of IT.
I used to be be like you, hated anything non-Unix, then as I got older and was forced to work so Solaris, HPUX, AIX, Linux (Suse and Redhat) and of course Windows, I grew to like the vast array of differences.
Sometime it al makes you want to tear you hair out when it won't play nice but solving problems is why I signed up to work in IT for the last 40 years, I realised I'm a better person for keeping an open mind and taking it all in no matter what it throws at me.
If it had a smidgeon of type safety, I'd be inclined to agree. But if I need object and methods and I'm on Linux, I'll use Python — I can't think of anything PS does better than Python except for (occasionally, but even then not often) doing Windows admin. And at least you can rely on Python to throw an exception and stop when it hits one, rather than barrel on regardless waving a sledgehammer around…
to make PS stop upon an error use -erroraction stop or $ErrorActionPreference="stop". If you script could to actual damage (i.e. delete something, or other dangerous stuff) do that. Also learn -WhatIf and $WhatIfPreference=$true, so you can test-run your stuff before it goes weird.
Yep, I use $ErrorActionPreference and Set-StrictMode religiously when I'm forced to use PS. It's not bulletproof but it makes it behave a bit more like an actual programming language. I'd really just rather we got an interpreted C# though (I know there are sort-of implementations of this concept, but a proper one would be ace).
It is documented! And $ErrorActionPreference is not the recommended way. Every powershell command has "-ErrorAction stop".
> Point is, I don't want to have to tell my shell that exceptions are bad.
Oh, you want to! You have a script which creates a directory. If that directory already exists, should it act as "I won't touch it" or should it act as "Don't care, go on" ? The latter is -ErrorAction Ignore, saves you an if/test-path in your code, the former is -ErrorAction stop.
And this is just the most simple example I can think of.
I remember well the Monad Manifesto coming out in 2002. It caused quite a stir on a little website called Slashdot, which had some mild popularity at the time...
And coincidentally in 2002 Microsoft was busy trying to migrate Hotmail - which it had bought a few years earlier - from its legacy platform of Solaris/FreeBSD to Windows 2000. It did not go well initially, partly because if you need to make a change to Apache on change 500 machines running Solaris/FreeBSD it can be easily scripted. Whereas to change the IIS configuration on 500 Windows machines you had to manually log on to 500 machines... Your only other option would be to write a script for WSH that connected and changed registry entries remotely. Which isn't very appealing.
The with the next release IIS suddenly gained the ability to use a config file, which was quite the coincidence...
So when Microsoft execs were saying "Admins don't want command line interfaces", I suspect that they simply weren't yet hearing what their own admins in the Hotmail division were saying whenever they tried to manage the test Windows environments.
PowerShell isn't without its flaws, but it is far better than what we had before. Thanks Jeffrey - if you're in London and want a pint (or a dram), I'll stand you one. Cheers!
> I'm taking the summer off and starting a new gig in Sept.
Perhaps you can persuade Apple to sort themselves out, what with AppleScript being left to languish; then Automator supposedly being a fresh new start, only to also be abandoned; then Shortcuts which is trailblazing only because it's been abandoned on both iOS and MacOS. <sigh>
They must be due a new one by now?
My apologies!
Enjoy your summer off, and I hope that your new gig is everything you want from it.
There do seem to be a lot of ignorant haters here, I hope you can ignore them. "A bad workman blames his tools" - and PowerShell is more a very large toolkit than a single tool, which unfortunately gives people a lot of room for manoeuvre.
Thanks for the clarifying reply - always good to see that the Reg forums are read by people at all levels!
Jeffrey Snover did some PowerShell videos with the GoateePFE on the predecessor to the current online learning thing they have.
Was just good to watch Jeffrey Snover using PowerShell and picked up loads just watching how he used the console.GoateePFE was very good too.
Is whoever came up with eseutil
Not perfect but has been my friend more often than I care to think.
Once upon a time NetWare was rubbished because everything was command line, whereas the new and shiny Windows was all GUI, despite the fact a lot of things were better done in a command prompt, something I remember bringing up in a few Windows admin courses at the time.
My experience has been with the Azure Service Bus cli, which i presume is very PowerShell-y. Oh and the ADFS stuff. I always get floored by the way the target is specified - -name to create, -target to ref. ASB then requires -queuename. Designed by committee, it seems.
That isn't PS causing the problem, it is down to whoever is writing the specific objects that you are attempting to use.
So, yes, overall the entire system that you interact with via PS *is* designed by committee. Quite possibly by people who don't even want to be exposing stuff to PS and really don't give a monkey's whether their stuff is self-consistent, let alone works beautifully with everything else.
So you miss something which a cmdlet does not expost directly? Speak to WMI / CIM directly if you want, offers a truckload of methods. Use inline c# or c to access .DLL functions directly. A more recent example of my stuff uses that to make A: A better shadowcopy schedule, and B: Supply the UI for it since Microsoft killed/crippled both in Windows 10/11.
There does seem to be a lot of hate for PowerShell here, which I find odd given the state of managing and automating Windows before it arrived.
So I figured I'd throw my tuppence out here.
PowerShell's biggest strength is that everything is an object.
PowerShell's biggest weakness is that everything is an object.
Some days everything being an object is great - to the point where you take it for granted. On UNIX based systems you might get back a stream of text from a command that you then have to strip text from with sed or split into fields and and recombine them with awk. That can be fragile if your regex isn't good or the data doesn't quite match your expectations. By contrast in PowerShell each item will be an object with properties - it's trivial to get back only the parts you want from an item, to the point where we take it for granted.
Some days everything being an object sucks because objects are more memory intensive and a bit slower than a text stream. Good old sort.exe can handle thousands of lines of text with minimal resources, but Sort-Object working on an array of a similar size can be slow. And I've also seen it almost kill machines due to memory usage. This sometimes means your script works just fine when you're writing it on your desktop with some test data but then fails on a server - because your workstation has four times the RAM that the server has. (Yeah, that can happen especially with smaller edge/management servers.) I've seen people get called out by the ops team because a critical RAM usage warning was issued, and the culprit was a PowerShell script with a Sort-Object a bit too early in the pipeline... Nobody is going to laud a technology that woke them at three in the morning for a callout!
All tools have their own strengths and weaknesses, and tools have a tendency to amplify the strengths and weaknesses of their wielder. Nothing's perfect, but I've enjoyed using PowerShell and I think of it as a valuable part of my toolkit, despite occasionally having fought and cursed it. In the end, I'd rather work with it than rail against it, because when it works it really works...
The RAM issue can even happen with a get-childitem -directory -recurse, taking > 8 GB just just because the directory to be scanned is simply that large.
Once you run across those cases you might be happy to remember how "iterative-recursive" works, and it requires minimal RAM. I had quite a few cases where I had to go that way, and I learned that way with a C16 (with 16 KB RAM) a little while ago. This is not powershell exclusive!
BTW: I loved the MUCH MORE powerful basic 3.5 of the C16 - C64 has only v 2.0 which is solala. And the ROM included Assembler/Disassembler.
Last case where I used the iterative way with powershell in a little fun thing which I could post online. (I cannot post scripts written for customers for obvious reasons)
Personally, I am a fan of both the GUI AND a CLI, be it esxcli, a unix/linux prompt, powershell, or even command.com (although powershell is better than command.com)
GUI for single/ simple changes? Yes please.
But if I'm doing something like building an 8 node ESX cluster, you damn well better believe I'm using as much CLI for configuring stuff- It's more consistent, and I can just copy-paste the CLI scripts into the window and let it do it's thing.
I hate powershell because of the deliberate gimping of functionality (like no access to the windows update client) deliberately intended to try force you to pay for things. Too bad for them I know how to do it with VBscript and RPC calls.
...but it was still a heck of a technical achievement and the reasons I hate it aren't Jeffrey's fault. Good luck and smooth sailing at your new gig, Jeffrey! IF you can convince Mark Russinovich to come with you, I'll buy stock now. ;)
You CAN access the Windows Update client. Works that way since Vista/Server 2008 with PS 3.0 (never tried on XP) up to Windows 11/Server 2022.
And there are countless examples on the net, and it does NOT require a extra module! Example for updating without driver updates:
#### Search updates
$Criteria = "IsInstalled=0 and Type!='Driver'"
$Searcher = New-Object -ComObject Microsoft.Update.Searcher
$SearchResult = $Searcher.Search($Criteria).Updates
etc etc etc... That method is out there, and has been there for quite a while. And if you couldn't find it you should tune your google-fu or duckduckgo-u or startpage-fu. There are really way too many complaining about PS here. Source for that information: For example this one from 2009 at microsoft, and this one from 2009 and so on.
Okay my fault for being not specific enough. You can access the LOCAL WU client. The intentional gimping was preventing REMOTE access to the Windows Update client. Upon re-reading my post, I guess I wasn't explicitly on that point. I thought the reference to RPC calls and 'pay for a feature' was plain enough it was gimped to force you to acquire licensing for system center.
Try using that code you posted, targeted to a remote machine, and you'll see what I mean (unless it's changed in the last two years or so and I missed it.) That's why I had to use vbscript + RPC, because the calls aren't blocked like they are if they come from powershell.
> preventing REMOTE access to the Windows Update client
Oh THAT is your gripe. That can be done as well. Either you do it manually with invoke commands, or you go the lazy way with the Install-Module PSWindowsUpdate - which does the same in the background, but saves you time developing.
Being a python person and having used bash etc, I wondered, why the f*ck would I want to use powershell. But then, after a while, although powershell is quite quirky, it's consistent. And it's a far better shell scripting language than any of the stuff I've seen on unix. Unix scripting is so much black magic and old lore, plus continually loading files and reading streams. Powershell does have the advantage of being very consistent. Even if the documentation can be crap at times and some of the features of powershell can take a while to get used to.
For scripting on a windows box, nothing beats powershell in my experience. Bringing OOP to the scripting language and allowing your scripting language to really extend the commands you have in your systems shell, it's really great. Powershell OOP fits well with Windows api-first approach. I love gnu/linux. But I miss the powershell shell/scripting experience.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
