why PowerShell sucks so badly

Here, I attempt to answer the rhetoric question, “Why does Microsoft PowerShell suck so badly?” Where to begin…? It has such promise, it’s clear that someone has spent much time coding everything. Ultimately, there appears to be power under that shell and it’s probably truthful to its name. But if you can’t use the tool in the real world, it should be renamed to Microsoft PowerlessShell.

“But if you can’t use the tool in the real world, it should be renamed to Microsoft PowerlessShell.”

It’s almost like a group of scientists in a desert setting somewhere—think “Manhattan Project”—created a collection of methods useful for annihilating the planet and then as almost an afterthought, enough preventive controls were placed upon its use that literally nobody could in fact blow anything up.

Today’s task is to automate the creation of a VPN button for Windows 10—based remote users here at the office. End-users then in theory can just double-click a PowerShell script that I’ve placed on a SharePoint server.  I would then individually share the link with them which would remotely install the new VPN profile. Sounds easy enough.  In fact, it sounds much easier than the two-page long tutorial in a Word document which attempts to educate them how to do all this manually.  Have you ever seen how long an L2TP shared key phase can be?  It’s pretty bad.  Just think of all the support calls I’m going to get if I can’t script this.

Is the PowerShell documentation easy to use? Hell no, it’s not. I’ve just spent a full hour trying to piece together the script required from this hobbled-together documentation on Add-VpnConnection. Does my script work under a test rig? I wish I knew, because at the moment I can’t actually run the script in any form or fashion because Microsoft doesn’t want me to.

“Does my script work under a test rig? I wish I knew, because at the moment I can’t actually run the script in any form or fashion because Microsoft doesn’t want me to.”

Now granted, I’m an Administrative user on my newly-upgraded Windows 10 laptop. The script fails with some terse error message which suggests that I need to run the PowerShell command as Administrator.  Well, that would foil things here in the real world because I’m trying to have the end-users run this script remotely so that I—the administrator—don’t have to be there in the first place.

So I doggedly trudge ahead and end my session and open up PowerShell by right-mouse clicking it and choosing Run As Administrator.  And yet, this still doesn’t work.  This time it fails with another terse error message which suggests that Set-ExecutionPolicy might help.  I then research this to find that “Unrestricted” is the probable attribute but when attempting to run this, I get another terse error message suggesting that I can’t change the policy.  Seriously?

I could now go back to my earlier research and re-learn how to digitally sign a script so that I can run it.  But the process to create and to troubleshoot a script usually requires multiple iterations before the script works perfectly.  And this is especially true since nobody yet on the Internet has provided a good example for creating a VPN tunnel to a SonicWall over L2TP/Ipsec with a pre-shared secret and authenticating to the firewall instead of the domain controller.  Designing a script like this takes trial and error.  Adding a signing phase between each script attempt effectively means:  I’m not going to do this.

“Adding a signing phase between each script attempt effectively means:  I’m not going to do this.”

In short, this is why Microsoft PowerShell sucks.  If you have to sign scripts just to run them while testing then it’s not worth the effort.  Why not include a button in the PowerShell IDE which allows me to “Sign & Execute” my script attempt?  And if I don’t have a digital certificate then open a dialog box to gather the information to magically make this happen.  Or even better, just allow me to create and run scripts without all the nonsense.  How about a big toggle that says “Unsafe Mode” versus “Safe Mode”?

15 thoughts on “why PowerShell sucks so badly”

  1. a) You don’t have to sign your scripts to run them. “Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass” can be used while you test
    b) UAC requires you to run elevated processes if you want to change/read certain system properties (that should be obvious – it’s been like that since Vista)

    In general PS’ execution policy is a means to decide whether you can only run signed scripts [Signed), run your own local scripts but not scripts from the internet [RemoteSigned] or all scripts [Unrestricted] (or just ignore all of that [Bypass])

    That’s 10 minutes of google research.

    Like

    1. You might have managed to find something that worked within ten minutes. Great. Personally, I’d suggest that Microsoft could default their currently terse error response system to make that suggestion.

      I believe I did eventually that day find this solution and eventually then managed to finish a script process that’s about as kludgey as they come: 1) a batch file copies a registry file locally, 2) runs the registry file locally, 3) runs the script with similar arguments, 4) put everything back to normal and clean up. And yet, this feels like something a hacker would have to do to get around security, not something an administrator should have to do to test something.

      Liked by 1 person

  2. I dabbled with Powershell when it first came out years ago, then decided to leave it alone on the basis that it was insufficiently compatible with the existing cmd.exe shell to be useful. (I don’t want to have to rewrite my existing environment from scratch).

    I’m currently trying to get a decent git prompt in a Windows shell. There is posh-git for Powershell, but I already know I don’t want to touch Powershell with a barge pole. So I’ve spent the entire day trying other things. Nothing is working nicely.

    Finally I succumb and fire up Powershell with a view to checking out posh-git. First thing I try to do is invoke my simple one-liner batch file to cd to my dev area. Powershell just emits a blank line, no error at all.

    Perhaps Powershell isn’t recognising the path. So I type ‘path’ to see what path Powershell is using. Result loads of red text, “the term ‘path’ is not recognised as the name of a cmdlet…”

    This is the defining characteristic of Powershell. The most basic tasks that have worked in well-known traditional ways for decades are incompatible, replaced by arcane new invocations that someone at Microsoft thinks I want to spend the time to relearn in order to do stuff I can already do elsewhere.

    If they can’t even be bothered to provide helpful messages showing you the Powershell equivalent to the most basic shell commands then Powershell can go and die in the cold.

    Liked by 1 person

    1. If you have Windows 10, I’ve got another post on here about the Ubuntu subsystem which is now native within Windows itself. It doesn’t have any GUI (no X-windows) but it is a reasonably full-fledged bash platform, if you will.

      With it, you could potentially execute Windows programs as if you were within a DOS batch file. I’m now working at a code academy and all three of the Windows-based students use this with git all day long and it seems to work out. It is Ubuntu under the covers, after all.

      https://outsourcedguru.wordpress.com/2017/03/22/ubuntu-bash-now-in-windows-10/

      Like

  3. From the perspective of someone who has been developing programs in one for or another for -eegadz!- 35 years or so, first with BASIC on various 8-bit computers, then assembly, Pascal, C, QuickBasic, VB6, Perl, JavaScript, VBScript / VBA / ASP, VB.NET, C#, a little Java, Scheme, Python, etc., on various systems from TRS-80 to classic Macintosh to Windows and Web, more and more I appreciate *SIMPLE* tools and approaches. For regular scripting of Windows functions, I find VBScript is capable and easy to use. It would be nice if MS would update it to include the option for stronger typing and a rudimentary IDE with Intellisense and debugging, like VBA has, but it works. It is certainly easier to use and do stuff in than PowerHELL, which is so freaking security-minded and locked down that you have to be a hardcore system admin to understand what’s going on. Just getting it to do the most basic tasks, I found that you have to jump through a million hoops. And then you have to deal with this clunky awful syntax. Why do we need some new syntax when BASIC / VB, or C / JavaScript work fine? I think PowerShell designed for a totally different mindset and skill set than your general use scripting languages like VB or Python, and gawd help us if MS ever pulls the plug on VBScript/VBA and leaves us with this mess instead!
    My suggestion? Include a full-featured IDE free with every copy of Windows that lets you develop in whatever language you want (or at least the main ones like JavaScript, .NET, classic VB/VBA/VBScript, Python), and can translate any code written in one syntax into one of the other languages on the fly. Computers and AI are (or shortly will be) powerful enough to where that should not be an issue. We should be able to program our computers in plain English goshdarnit! If no one is willing to enable the common person to program their machines easily, that must be taken as a political power play move, and screw the technical elite if they want to do that.

    Liked by 2 people

  4. PS breaks the principle of least astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishment
    It is basically a .NET language with dynamic types, but the syntax is like…on acid. It would have been so much easier if the syntax had been like e.g C#.
    It is great for “glueing” pieces together, like com objects, .net types and wmi objects, it may be used to do web requests and update databases. But as a user you easily get lost in the access hell to the point that you won’t bother. Some of the cmdlets are illogical, there is a Create-Service, Start-Service but if you want to find out if the service exists you need to write $service = Get-WmiObject -Class Win32_Service -Filter “Name=’servicename'”

    Liked by 1 person

    1. It feels to me like .NET was an “oh, s#@!” response by Microsoft when they realized that Java was a clever concept. So they slapped together an intermediate level compiler in a hurry and then later, wanted it to behave like POSIX or something at the IT automation level. Who knows?

      Like

  5. This still has not been fixed to this day.
    I’ve tried all of the following fixes… and PowerShell still compains that the system is not setup to run scripts.

    Notes:

    Get gpedit-enabler.bat from Drive>Company_Procedures>Security_Procedures>EnableVPN
    Copy file to local PC
    Right Click File & Select Run As Administrator

    After the gpedit-enabler.bat completes in the command terminal
    Type “run” in windows search bar (bottom left side of taskbar)
    Run “gpedit.msc”
    In the Local Group Policy Editor
    Select Computer Configurations
    Select Administrative Templates
    Select Windows Components
    Select Windows Power Shell
    Turn On Script Execution
    Enable and Set Execution Policy to “Allow All Scripts”

    Open Windows PowerShell — right click run as Administrator
    Enter the following command to check the execution policy:
    Get-ExecutionPolicy -List
    Example Output:
    Scope ExecutionPolicy
    MachinePolicy Undefined
    UserPolicy Undefined
    Process Undefined
    CurrentUser Undefined
    LocalMachine Unrestricted
    Enter the following commands to change the execution policy:
    Set-ExecutionPolicy unrestricted -Scope LocalMachine -Force
    Set-ExecutionPolicy unrestricted -Scope CurrentUser -Force
    Set-ExecutionPolicy unrestricted -Scope Process -Force
    Enter the following command in powershell to run the VPN configuration script
    powershell -ExecutionPolicy -Bypass -File C:\path\to\file\windows_USER.ps1
    Enter the pkcs12DecryptionPassword: ******** for the VPN Server
    Reset the execution policy for the computer by entering the following commands
    Set-ExecutionPolicy restricted -Scope LocalMachine -Force
    Set-ExecutionPolicy restricted -Scope CurrentUser -Force
    Set-ExecutionPolicy restricted -Scope Process -Force

    Liked by 2 people

  6. In the over three decades I’ve been in this industry this has to sit in the top ten of the most absurd, knee-jerk reaction posts I’ve ever come across – and by someone that codes and is IN this sector….are you joking me?!?

    So, because you had clearly NEVER EVER ONCE used Powershell, and clearly didn’t read so much as the f’ing README….and through nothing but 100% PURE USER ERROR did not understand STEP ONE as simple as setting your execution mode (one command, BTW I’m sure you’ve learned in the years since this post).

    You know, there ARE actually times that justify that “edit” button or in this case….that DELETE button on your wordpress – exactly FIVE MINUTES after you posted and (hopefully) figured out how idiotic it was that you couldn’t figure out how to run a script.

    Just wow. Hey it’s only 2+ yrs late but god forbid anyone more junior reads this post and very wrongfully believes for a second that this is true and Powershell isn’t the extremely powerfully (built on dotnet – aren’t you a dotnet DEV for god sake) interpreted scripting language.

    I respected the hell out of your blog, right up until I read this ignorant post.

    Like

    1. If you back up a bit and look at this, you might be able to see this from a bigger perspective. This isn’t a stupid-user problem. I really spent way too much time trying to work around what was a systemic problem in PowerShell’s design. You may not agree, you may even like to code in PowerShell.

      If I had been in the design effort for PowerShell, I think I would have introduced the concept that if you’re the Administrator on your own computer, then you should be able to run scripts. Period. Prompt the administrator one more time for their password to make sure, if you’d like, but don’t then just deny access with a terse error message. I seem to recall writing a remote Windows configuration patching tool back in the ’90s which simply worked without all this. It was modular and allowed me to write INI-like scripts to make updates across-the-network as the administrator.

      Although I welcome your feedback, my personal experience (with almost four decades in the industry) is that PowerShell was an ugly and frustrating experience.

      Liked by 3 people

  7. To anyone advising to use Set-ExecutionPolicy: are you working alone in a lab on your own private computer? Because if you work in a company that uses an AD and has set a GPO forcing RemoteSigned as a policy, you’re fuc***. I can’t even download a simple library I found and github and use it right of the bat, I have to fight with this signature nonsense. Everytime I try to do something in powershell, I wanna bash my head through the wall, I spend more time circumventing Microsoft decisions than actually coding. This is stupid design.

    Liked by 4 people

  8. Powershell is an on going dumpster fire of hatred. I’m a dev with a background in c,c++, c#, assembly, python yada yada.
    I pretty much can pickup any language and find the downfalls and the upsides real quick; powershell was foisted onto me due to my current employers extreme fear of uncontrolled module usage etc. plus the need to get things done without waiting for approvals that might never happen. So whats annoying about PS ? – scope is mad, syntax follows absolutely no other language, return values are insane, type definitions seem a mis mash of perl and some half bastard version of c#…
    God what a mess

    Liked by 3 people

  9. I have to agree–Powershell is the most upside down, inside out, convoluted and confused crap I have ever dealt with. There is no roadmap. Just read all the readmes and piece it together. Who has that kind of time? I make systems go for a living, not learn obscurities. I need to load a SQL management object. That’s all I need. Just the object to make a connection. I have been at it for a couple days. Repositories (that are private and cannot be used by others), package providers (that I must decided are trustworthy–oh, I guess I like font on their logo!. Must be a nice place.), and on. I have coded in C, C++, Basic, Perl, SQL,various shells, and other languages that you don’t hear about anymore. And I’ve been doing this since 1985. Hell, I could live with the idiocy if I could just find a recipe with all the steps. Apparently I have not been sufficiently marinated in the Powershell sauce and cooked crispy in the Powershell oven. What a joy. Oh, and FellowCoder, you miss the point. Not even close. You’re so hopelessly far from it that writing more is pointless. At one time I did find a site where someone was willing, I think, to explain the madness. Guess I’ll try to find that site again.

    Liked by 2 people

Leave a comment