This is obviously great but I find it annoying the instructions ask your to Set-ExecutionPolicy Unrestricted in order to run the PowerShell script. That is just lazy.
Their choices are AllSigned (or RemoteSigned which is the same thing in this context) or Unrestricted.
If they chose the AllSigned route and then sign it with a CA certificate (e.g. Microsoft's Code Signing cert) that would work, but if the user ever made even a one character change to the script the thing will break and it might be unclear as to WHY. Plus you have to be careful not to lose your signature when sending files via certain technologies.
Alternatively they could teach the user how to set up a local CA, make a key pair set, and then install. But that too is going to break a lot as it needs to be re-signed each time the script is updated, and obviously inter-machine coding will be a PITA.
It is fairly standard practice on non-server developer machines to set it to Unrestricted. It isn't really any more dangerous than for example BAT or VBS scripts which have no such default restrictions.
You call it lazy, but the alternatives seem impractical and painful. There are scenarios where you want to enforce code signing, I just don't really feel like a developer machine is one of them.
This is like a Linux distribution shipped OpenSSH disabled by default, and if you enabled it, you'd have to sign every script you run or allow everyone to run (almost) as root.
I'm not a fan of PS (coming from Python, PS syntax is just nuts), but it's the most useful tool in the Windows world to automate tasks and deployments of all sorts... or rather it would be, if the security model weren't so inane that few people dare touching it.
In the past "bad guys" have used VBS to leverage a minor exploit into a full compromise. For example, they might have the ability to write arbitrary strings to the filesystem but not execute or run code. So they write out a *.VBS into the StartUp folder, and when the user reboots they have gone from a relatively minor entry into full remote control.
While VBS and BAT remain on Windows based PCs, having PS be locked down is a little irrational. However I suspect Microsoft might be looking to the future when one day they can remove both BAT and VBS (or force the user to enable/install them manually) so that it becomes harder to use such things to escalate your compromise.
Essentially they're trying to limit attack surface on 90%+ of consume grade machines, as your average consumer will never run a PS script or even care that they cannot. A lot of medium to large enterprises have an internal CA (with the CA cert already on the machines for authenticating with AD) so internally signing their network scripts is of lower cost (i.e. the infrastructure is all in place, just a single command to sign which you can automate with PS, unlike a solo developer who might not be aware of certificate issues anyway and certainly won't be running their own CA).
Your post assumes that PS hasn't been hugely successful, which is definitely not my experience. SysAdmins in the Windows worlds are all over PowerShell, they love it, and if you go read something like SpiceWorks or any other similar community 90% of the new automations are written in PS rather than VBS/BAT (it helps that all of the MS tools in Server 2012 natively support PS). I don't really think the default security restrictions are going to limit PS's popularity, they might limit it for certain niche deployments (e.g. MAKE scripts distributed over the internet) but not for internal use.
As far as you not liking PS, I understand, I really do. Most other scripting languages use strings as their fundamental unit of work (e.g. pass strings from process A to B, even over pipes it is all strings or file names which are also strings). In PS the System.Object is the base unit, and everything above that is also an object (it is classic OOP), so it really takes some getting used to. There's a lot of inheritance in there.
But once you understand the underlying concepts involve, it is quite de-mystified. However it really helps if you've come from a Java/.Net programming background since even things like overloading isn't really something you'd run across in a scripting language based largely on string transportation.
If you want to get started watch this workshop (you don't need to watch the full 4 hours(!)): https://www.youtube.com/watch?v=-Ya1dQ1Igkc
> A lot of medium to large enterprises have an internal CA (with the CA cert already on the machines for authenticating with AD)
That's not my experience, but I guess we're both going by anecdotes here. (to be precise, in the few cases where an internal CA is actually present, the process to have anything signed is usually a bureaucratic nightmare)
My particular point of view is a vendor who comes in to deploy stuff on customer servers and is told that Powershell should remain disabled (or be enabled for installation purposes and then disabled again, which removes the possibility of automated maintenance via PS). I guess it's a political choice as much as a technical one, but that's what I've experienced; and the larger the company, the most likely that this policy is not negotiable.
I don't disagree that PS has been successful; the Windows world was screaming for a half-decent shell and PS is exactly that. I just think that it could have been much more successful had MS chosen their defaults a bit more carefully (and/or implemented a better security model).
On the syntax, what I don't like is not being object-based -- I don't particularly like the "string everywhere" approach -- but rather the over-reliance on special characters (that tends to make a PS script fairly unreadable compared to Python). It also feels more of a bash-style world than a scripting-language world, which I think is a step back from VBS/JS.
PowerShell -ExecutionPolicy Bypass -File (...)