How to Improve Powershell

An Idea for PowerShell IDE and ecosystem

What is PowerShell?

 PowerShell is a powerful tool for managing Microsoft products and operating systems; one whose importance will only grow with time.  All components in Microsoft’s Windows Server 2012 have PowerShell APIs.  All new Server products (SystemCenter, Lync, SQL, Exchange) whose development started after 2007 are to be completely PowerShell based.

 The GUIs as exist within Server 2012 or any other products Microsoft produces (with the exception of endpoint operating systems) are merely GUI layers activating PowerShell scripts.  Office 365 and Azure are both addressable via PowerShell and even third party applications are by vendors deeply embedded within the Microsoft ecosystem are being coded to be PowerShell friendly.

 

What is the problem with PowerShell?

The PowerShell ecosystem is heavily fragmented.  Even Microsoft’s own resources are heavily distributed; there is no one place that an administrator can go to research all PowerShell commands.  Each application maintains its own documentation resources.  Community resources are scattered and rang from scripts to simplification of the often nearly incomprehensibly unhelpful Microsoft documentation to third-party PowerShell modules designed to simplify tedious tasks.  (MessageOps’s PoswerShell PST Migrator is an excellent example.)

 

What are the consequences of this issue?

This makes creating PowerShell scripts time consuming and research-prone.  It makes using PowerShell in a non-scripted fashion even worse.  It brings us back to an MS-DOS era of laminated “cheat sheets” and sacred text files filled with arcane strings of code that nobody can but “the guru” can decode, but which are nonetheless vital to the everyday workings of systems administrators.

This has dark security implications.  Modules that are loaded into PowerShell are often kept in ad-hoc repositories consisting of a simple directory on a file server.  They are rarely up-to-date as no automated update mechanism exists.  Scripts sourced from third parties suffer similar issues; security flaws or other bugs are left “lying around” in the form of these never-updated script files lying inside privileged administration space frequently accessed by harried, overworked sysadmins.

Worse; there are often no version controls in place!  While some companies use SVN or other versioning control systems for their PowerShell scripts many organisations – especially small businesses – simply have no such product in place.

While there are some few “best practice analysers” on the market to scan the PowerShell scripts you are developing; there are none that operate on a real-time basis helping administrators who are attempting to simply “solve the problem in from of them” rather than generate scripts.  Additionally, there are no password managers for PowerShell; PowerShell often requires an administrator connect to systems outside his own network (such as Office 365) in order to make changes.  This requires administrators to write down the passwords on a piece of paper, or keep them in a text file.  Both are a security risk.

Let's make Powershell better for all of us.

Let’s make Powershell better for all of us.

How to solve this problem?

What I propose as a solution is a combination of real-time console aide, script development IDE and “app-store” + attendant ecosystem.  The features and requirements would then be:

App Store + attendant ecosystem.

What the PowerShell community desperately needs is an App Store.  One centralised facility that third parties can submit PowerShell scripts and modules to.  Since PowerShell modules are the basis of many a company’s revenue stream, this App Store would have to have the ability to offer modules and scripts for sale.  (Likely at an Apple-standard 30% fee to the store maintainer.)

This App Store is the core of the business model under discussion.  Every script or module would be required to be submitted with accompanying documentation.  The documentation would cover syntax of accompanying commands which will play into both the real-time console and the script development IDE.

DRM would be a factor.  This would have to transparently handle licenceing of third-party modules in a Steam-like fashion.

Real-time console

The realtime console would consist of a modified PowerShell console with the following options:

  • Connectivity manager: this would retain connection strings to remote systems you have to manage.  Simply scroll through the list, select the server you want to connect to and *paf*, your PowerShell session is connected.  Alternately, enter credentials, IP/server name and server type (Office 365, Server 2012, etc) then hit connect.  Think Putty’s interface for managing SSH servers.
  • Password manager: if you are going to connect to other servers you need some way of saving passwords.  Preferably it would also have the option of changing passwords for your user to something impossibly hard and storing that.  (Could it jack in to third-party password managers like KeePass?)
  • Module selector: you have downloaded modules from the App Store – or sideloaded them from your own repositories – into the system.  Now you need the ability to graphically select which ones are made available to this console session with the simple click of a button.
  • Predictive command suggestions: as you type in a new command, a list of possible commands should show up in the right-hand pane.  If you start typing “new-” then a list of all commands known as part of the standard PowerShell featureset + any commands that are part of the modules you have imported which match should show.  Additional characters should narrow the list.  When you type the full command name (e.g. New-MailboxExportReqest) the help documentation for that command should be displayed in that pane.
  • Best Practices analyser:  If you make an egregious error, a warning should appear.  This will help train new coders.

 

Script development IDE

The script development IDE should function more or less like any other IDE.  Full colour syntax highlighting, predictive command suggestions (as discussed in the real-time console) and the check scripts for syntax errors.

The IDE should also take full advantage of the App Store.  You should be able to import modules (or even third party scripts) simply by clicking on the item in your library.  (Adding a script should pop up the documentation for that script; adding a module merely adds possible commands, scripts both require an input and produce output that must be handelled.)

The IDE should incorporate version control as well as harness the connectivity manager and password manager features from the real-time console.  One-click incorporation of connectivity commands should be possible, while scripts should be “linkable” to stored credentials.

While embedding credentials into a script is a massive no-no, the IDE itself should serve as a script launching platform: if an authenticated uses is logged into the IDE, then launching a script that is “linked” to a given set of credentials should not prompt the user.  If the script is saved as a file and launched outside the IDE, it should prompt for credentials.

The script development IDE should also track changes to third-party scripts and modules, flagging the administrator if updated versions had been downloaded from the App Store, or if there are updates pending.  Any updates from the app store should both display change logs to the administrator and flag up any relevant scripts in the library which may be affected by these updates.

 

Business case:

On the whole, I believe the above described PowerShell application and App Store would give the developer of this toolchain a dominant position within the PowerShell ecosystem.  It would provide smaller vendors an outlet for monetisation of their intellectual property while at the same time providing them exposure they could not otherwise achieve.

It would provide the community a common documentation repository as well as a vehicle for community scripts to be located, vetted and improved upon.  (The details of which would be tied up in a ranking system and/or publicly exposing a CVS for open-source scripts that are part of the “store” ecosystem.)

With a proper community manager familiar with the details of content/technical marketing this application could easily blossom into a powerfully large and vibrant community of IT practitioners, though influences and decisions makers.  Given the monetisation opportunities surrounding such communities (E.G. Google or Spiceworks) this should be economic incentive enough to pursue development.

In addition to this, there is the economic incentive provided by the possibility of directly monetising the third-party PowerShell ecosystem via the “App Store.”  The end result being “Steam for PowerShell;” a monetisation platform for third parties surrounded by a cult-like community resistant to all external attempts to topple its market dominance, even when attacked by market leaders in the field.

Potential issues:

There is a significant amount of development required to achieve a workable beta required to start drawing in the community.  While the full “vision” of the above product does not need to be realised for initial go-to-market, a significant portion of the ecosphere will have to be in place before coming out of stealth mode.  That means start-up resources.

For this to succeed, there needs to be a trusted brand behind it.  Third party vendors, administrators and the development community are not going to line up behind any random joe with an idea and a beta.  This needs the support of a Force within the industry to get born; the bigger the extant community in place.  Ideally, Microsoft would pursue this on their own, but outside of Microsoft I see Spiceworks, Puppet, VMware and StackExchange all as having adequately sized communities to jumpstart this.

Of these, only Spiceworks and StackExchange could really make an argument for this project to be relevant to their community.  For StackExchange, this would be a natural fit.  For Spiceworks there is a bit of stretching to do, but they already have a script repository (to which this could be viewed as an evolution) and they could use the income diversification this would bring.

The other approach is the venture capitalist scene; back it with The Right Names as investors and developers and hope that you can make enough noise to get bought by someone who needs to absorb or create a vendor/user community in a hurry.

About Trevor Pott

Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley start-ups better understand systems administrators and how to sell to them.

Visit My Website
View All Posts