Five enhancements that PowerShell really needs

Five enhancements that PowerShell really needs

Summary: PowerShell is one of the best Windows tools available, but it could be even better. Here are my five suggestions for a better PowerShell experience.


PowerShell is Microsoft's scripting language, now in its third iteration. It's an extremely powerful tool to use for automation work, system administration, working remotely on systems, or working on multiple systems at a time. You can use it interactively or in a script. You can also touch multiple systems in a script by using its handy looping mechanism. So what more could one possibly want out of PowerShell that it doesn't already do? Plenty.

OK, first, PowerShell is a modular language, so that's one major point in its favor. Why? Because modularity allows it to be extended "voluntarily". By voluntarily, I mean that it can be extended by adding modules instead of having everything already packed in with no possibility of extension.

PowerShell 3.0 was a huge extension over PowerShell 2.0. PowerShell 3.0 comes equipped with thousands of cmdlets for almost every purpose — almost. And that's where this post begins — where PowerShell 3.0 leaves off.

Here is a list of what I think PowerShell 3.0 still needs: 

  1. *nix Connectivity Utilities — Boldly missing are tools for *nix style connectivity, such as SSH, SCP, SFTP, and others. There are some third-party modules for this, but they aren't very good, although I've had some success with SSHSession

  2. Backup/Restore Support — It would be nice to have some deep dive Backup and Restore tools in PowerShell, and enhanced versions of command line utilities such as AT and NTBACKUP

  3. Better Output Support — PowerShell has -OutFile and -ExportCSV output redirection, but you can't always get what you need from one of these because some output can't be redirected. For some output, you can do the following:
    PS> script.ps1 > file.txt and then use the text file. However, there are times when that sort of "out of script" redirection doesn't work for output either. You should see some of the crazy ways I've had to grab output from scripts. I'd really like to see better output redirection. In other words, anything that I can output to the screen (STDOUT), I'd really like to see supported in -OutFile or -ExportCSV, or some other redirection option

  4. Import on First Use — Rather than import Microsoft-branded modules, such as Active Directory modules, you should be able to download and install them on first use like you do with some of Microsoft's other features. This would be a very handy feature so that, for example, I could run a Get-ADUser on a system, and PowerShell would import the module and run the cmdlet without interaction from me

  5. Easier to Extract and Format Info — You can extract a lot of good information using PowerShell, but then to actually get the data you want into a desirable (readable) format, is very difficult. For example, PS> Get-Process provides you with a list of processes from your system in table format as shown in Figure 1.

processes_psFigure 1: Partial Process List — PowerShell. (Image: Screenshot by Ken Hess/ZDNet)

Now, try to just list the Process ID and ProcessName with PS> Get-Process | FT ID,ProcessName

See the result in Figure 2.

processes_2Figure 2: Processes Filtered by ID and ProcessName. (Image: Screenshot by Ken Hess/ZDNet)

Do you see the problem? Now you might think that this isn't a problem because you can either live with the odd original location format or you can direct it to a text file. Wrong. When you direct the output to a text file, you get a text file with the columns pushed out to the right, just like they are on screen.

Forget about Format-Wide; it doesn't work. Format-List is even uglier than Format-Table. And if you said, "Try Format-Custom"; it's worse than the others, although I think that you can create a custom view (an XML file) and use that for a better format. But seriously, that's a lot of trouble for a simple list of IDs and process names.

If this were a *nix environment, I'd do something like this to get the format I want:

$ ps -ef | gawk -F" " '{print $2,$8}'

To yield,

1 /sbin/init
2 [kthreadd]
3 [migration/0]
4 [ksoftirqd/0]
5 [watchdog/0]
6 [migration/1]
7 [ksoftirqd/1]

And in fact, what I would do on my Windows systems, since I have CygWin tools installed and in my path on my automation systems, is:

PS> Get-Process |gawk -F" " '{print $7,$8}'

To yield,

Id ProcessName
-- -----------
3780 AmIcoSinglun64
1788 AppleMobileDeviceService
4900 ApplePhotoStreams
5396 APSDaemon
1764 armsvc
3844 atieclxx
948 atiesrxx
1444 AvastSvc
5188 AvastUI

I shouldn't have to resort to such measures to get what I need in terms of formatting. If you know of a better way, I would love to see it. So far, I haven't found one, though I've looked for a solution.

OK, that was a really, really long number five, but sometimes, it helps to fully illustrate a point to drive it home. 

[Update: one of my readers has supplied a fix for this problem with the -Autosize switch. If this works for all such formatting, then I guess we can mark number five off the list. Thanks.]

These are my five enhancements to PowerShell that I'd like to see. Do you have any improvements that you want included in a PowerShell update? Talk back and let me know.

Topics: Microsoft, Software, Software Development


Kenneth 'Ken' Hess is a full-time Windows and Linux system administrator with 20 years of experience with Mac, Linux, UNIX, and Windows systems in large multi-data center environments.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • fix for number 5


    get-process | ft -autosize id, processname
    • BAM!

      That was simple. Nice one.
  • forgot to include the link
  • Try and manipulate the objects in pipeline before exporting or displaying

    Try manipulating the objects in the pipeline before exporting or displaying. Usually this will enable you to get the output in any format required. For example for example 5 just select the id and processname and then export:
    get-process|select-object id, processname|Export-Csv test1.csv

    For backup, if you are using the latest system center then everything should be available in PowerShell including backup with DPM.
  • Thanks,

    -autosize did work. Thanks. Appreciate that.
  • PS is certainly NOT that bad!

    I would highly recommend reading the book "Learn powerShell in 30 lunches". You will be able to find the answers to #3, #4, and #5 right in the book. As far as #2, the VSS-hooks are already available for snapshots and such - what problems are you having kicking off snaps/backups? As far as #1, why don't you just alias your own Linux command equivalents with known scripts? Again, reading a good book on Powershell before making an article describing how poor Powershell is - would really help your case here. Not saying PS is all-powerful, but geesh, it's certainly not bad at all and I can easily manage pretty much everything from VM's to registries, to Exchange, to SQL, to VSS snapshots easily using PS with no real sweat and/or programming knowledge.
    • @lawryll

      Did you read the article? Where did I say it was bad?
    • How to run powershell script without importing module

      Hey lawryll@.. I am new to powershell.. and want some help on it...
      Supporse having exchange module imported I created PS script that does something with exchange on System A... Now I took same script to my client or friends machine which does not have exchange modules..
      So how can a PS script (which was developed with help of specific module) be executed on a machine not having modules.
  • "thousands of cmdlets for almost every purpose"

    And a sure fire method for none of them to be used.

    Anytime something requires more than about 300 "commandlets" to be useful is pretty will guaranteed not to be that useful.

    Everybody will be recreating them because they can't find the right one(s) to use, and likely can't be used in combination.
    • Yet it is extremely easy to not only find the right one

      You can combine cmdlets for different technologies in one script. So you could write a script that targets active Directory, Windows, SQL server and Exchange if you want to.
  • Decouple Command Interpreter From GUI

    PowerShell shares the same fundamental limitation as CMD.EXE, and that is that the same program is responsible for both the windowed GUI and the interpretation of the commands you enter into it. On a Linux system, Bash and other command interpreters have no responsibility for any GUI functions: these are left to a "terminal emulator" that can run any command you like. This allows you to mix and match your choice of GUI with your choice of command interpreter. And just as importantly, it allows you to run commands on remote systems via SSH just as easily as on your local system (no need for all that WMI rigmarole that PowerShell forces you to go through).

    Windows simply does not grasp the full power of the command line. No wonder Windows users, even seemingly knowledgeable ones, think it is something to be feared.
    • As someone

      who has used bash scripting and powershell scripting, I do not see any limitation on the powershell end, in fact I prefer it above bash as it is more advanced.

      Knowledgeable Windows users have no fear for the command line whatsoever, and there isn''t any need. Running commands on remote systems do not require wmi, you are mixing things up here. powershell is using winrm which is just as simple as enabling ssh on unix like systems.
      • Re: powershell is using winrm

        I'm not sure which is worse, WinRM or WMI. Certainly neither can match the simplicity of SSH on Linux: suppose you have a command sequence "cmd" that you want to execute remotely on "host": there is little more to it than just typing "ssh host cmd".

        Those who only know Windows just seem incapable of appreciating this.
        • What is wrong with winrm I wonder ?

          It seems you have no idea what it is. You certainly have little knowledge of Windows. Suppose I want to issue cmd remotely on a host. I could in fact use powershell by simply executing: invoke-command host {cmd}. Or I could get a full fledged prompt on the host just by simply entering enter-pssession host.

          I probably have more years under my belt on Unix and Linux that you, I certainly know Windows, something you obviously know next to nothing about..
          • Re: What is wrong with winrm I wonder ?

            So what are the WinRM equivalents to "ssh -t", "ssh -X" and "scp"?
    • Powershell remoting blows bash and ssh out of the water

      want to execute a command on a remote machine? No need to use WMI. Want to get the process list from a remote computer?
      Type: icm host1 {ps}

      Want to get the process list from multiple computers?
      Type: icm host1,host2,host3 {ps}

      You can pass any sequence of commands in the script block. You can execute script files even if they only reside on your local machine. You can connect to remote computer without that stupid and tedious mocking around with ssh keys and passwords.

      Want to enter a remote Shell?
      Type: etps host1
      and you are remote

      authenticated, encrypted and secure.

      Want to admin your servers from anywhere? Install powershell web access and you will have a CLI gateway from any browser anywhere. Yes. a CLI in the browser with tab completion and everything. Try THAT wiyh bash.
  • Decent syntax

    #1 that power shell needs is decent syntax. For occasional users string manipulation and input and output redirection is unnecessarily convoluted. I also do not understand why every variable has to begin with $ and instead of regular comparison operators we have to use stupid expressions like .eq, .le or .gt. Powershell would be a good tool if it could be picked by any programmer and used without much training.
    When I was writing my first powershell script I spent whole day looking for simplest things that I have done many times before using other tools. Yes I learned powershell but I felt like I learned just another useless variation of batch syntax.
  • 5 enhancements and not one of them valid

    This was such a badly written article, I signed up just to comment on it. It seems as if the author had done no homework at all before writing this.

    1. *nix Connectivity Utilities – Already present (WinRM & PowerShell remoting)

    2. Backup/Restore Support – Already present.
    Now please do not go asking for PowerShell to do more than the OS can actually do, NTBACKUP is not available in any Windows version after XP or 2003. From what I see most (if not all) backup features included in Windows 2008 (should be the same for Win 7) are covered. If you are talking about Windows 8, I have not checked but I suppose file history feature are implemented in PS.

    For the at command:
    help ScheduledJob

    3. Better Output Support – I don’t understand what the author exactly means, as I don’t know why he had to use the crazy ways to grab output. However I think once he gets a better understanding of what will be redirected and what will not, things will be much more easier .

    4. Import on First Use – I will have to agree on this, but just a bit. For my servers I would rather suggest depending on what roles / features are installed and being used, the modules should be automatically installed and imported on boot up; it may slow the boot time by a few seconds, but then again I’m not expecting my server to complete booting within 1 minute or so. For the client machines, I will agree with this point. However this is more a matter of individual choice.

    5. Easier to Extract and Format Info – Can be done using a simple switch as already pointed out.
    • Re: 5 enhancements and not one of them valid

      1. The problem is that none of the facilities offered by PowerShell are as convenient, powerful and flexible as on *nix.

      2. PowerShell and Windows lack anything to compare with the power of rsync on *nix.

      3. Probably he is talking about the fundamental Windows limitation that prevents treating all file handles as the same.
      • Re: 5 enhancements and not one of them valid

        1. The problem is that none of the facilities offered by PowerShell are as convenient, powerful and flexible as on *nix.
        stillsjaak327 has already addressed this above and I will not repeat it.

        2. PowerShell and Windows lack anything to compare with the power of rsync on *nix.
        Did the author mention anything about rsync?
        The way I see it rsync is an additional application that can be installed. But again there are other applications for Windows which can be installed and managed using PS, like DPM.

        3. Probably he is talking about the fundamental Windows limitation that prevents treating all file handles as the same.
        Maybe; or maybe he does not know PS well enough, to be able to suggest meaningful enhancements for it.