Jason Helmick has a new post entitled “Helping Admins Getting Started with PowerShell” up now on PowerShell Magazine. Its a great article, its worth the read and a few moments pondering how you are utilizing PowerShell.
I’ve known Jason for a few months now. He works as an instructor for Interface Technical training here in Phoenix. He introduced me to the AZPOSH usergroup (he’s also it’s co-founder). He was also my instructor for a class on IIS back in October, that while about IIS 7.5, contained a significant introduction to PowerShell. Which was nice since all of my co-workers took the same class and I think all have a much greater understanding and appreciation of PowerShell now. Jason clearly has an affinity for PowerShell and knows what he is talking about. I like that he is championing the “new guy” to PowerShell. He is particularly conscious of the non-programmer admin types. He made this case well in his recent, PowerScripting Podcast appearance.
I think to this point the adoption of PowerShell has happened most significantly with those who were scripters or programmers in some other language, and who have transitioned to PowerShell. The exception being the traditional admins for things like Exchange and SharePoint. As these and other products introduce a scaled back GUI in favor of PowerShell this trend will continue and the basic admin will outnumber these “programmer” types. Many of these programmer types are of the “Dev Ops” variety who maybe used VBscript, Perl, Python, or even some C# to get a handle of their management tasks on Windows. Some of these types have tended to “ignore” some of the more basic elements of PowerShell and end up using it for more of a drop in replacement for those other languages. They lose sight of the pipeline and the shell aspects, and instead produce these monolithic .ps1 files much like they would produce, .vbs, .pl, or .py type scripts.
There is nothing wrong with that, it works and gets the job done. I have certainly been one of those types and those are some of the habits I am trying to break out of this year. PowerShell is much more an “environment”, a true management shell. The scripting elements are absolutely important to PowerShell and its success and future. However being grounded in the basics of PowerShell and its pipeline and the other management facilities the shell provides is where PowerShell’s value and strength lie.
My only subtle criticism of Jason’s article is the slight argument against the programmers, focusing less on the scripting and more on one liners. I think the “toolmakers” in PowerShell, who are the programmers effictively leveraging the shell and management aspects by producing great script cmdlets; with embeded help, that take and output objects are absolutly the best thing for PowerShell.
If you are an admin whose environment is made up of typical Microsoft enterprise software; Exchange, Active Directory, SharePoint, SQL, and the Systems Center suite, your set with PowerShell. Your primary and likely only toolmaker is Microsoft. Even if you utilize VMware products your still good because of the PowerCLI product, they are also your toolmakers. However many of us out there exist in enterprises that contain only a fraction or portion of those products. Many of our production applications and infrastructure is not, and probably will not be manageable by this wonderful Shell out of the box. We need to find toolmakers elsewhere. Some of us will need to evolve our skills into that arena or look to others who may have already tackled problems we need solved, from places like TechNet Script Center Repository, CodePlex, or even GitHub. For PowerShell (and Microsoft) to be truly successful PowerShell and the admins who use PowerShell need to manage the vast majority of their enterprises and not just the Microsoft portions.
I certainly agree with Jason about helping the beginners get a firm, none fearful understanding of PowerShell. PowerShell itself is unlike anything before it, Perl, Python, or any of the Unix shells really expect a certainly level of knowledge and skill to master and utilize effectively. If the basic admins have a good understanding of PowerShell fundamentals and the toolmakers have that same understanding, then the Object becomes the sole common unit of “commerce” within the shell. If the toolmakers are programming for the Object, and the admin (new, basic, or otherwise) knows how to utilize and consume that Object through the pipeline the “dark arts” of how that Object came to be are not important for these admins or the many other toolmakers out there.