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...