- Use PowerShell splatting and PSBoundParameters to pass parameters - Wed, Nov 9 2022
- Using PowerShell with $PSStyle - Mon, Jan 24 2022
- Clean up user profiles with PowerShell - Mon, Jun 9 2014
Again like many of you, I was coming from a heavy VBScript experience so naturally I was drawn to PowerShell’s scripting capabilities. Over time I’ve come to appreciate the finer points of PowerShell and after the recent Microsoft MVP summit I am coming to understand even more about what PowerShell is to an IT Pro and where we are all going to end up.
PowerShell is ongoing product of the Monad Manifesto, written by Microsoft Distinguished Engineer and for all practical purposes, the father of PowerShell, Jeffrey Snover. Each PowerShell version, now at 4.0, has been building on this manifesto. There is a lot of confusion and misunderstanding about PowerShell so I’m going to attempt to lay it out for you.
First of all, I always explain to students and the like that PowerShell is a management engine that is intended to improve efficiency through automation. The goal is to use this engine everywhere an IT Pro might need to manage something. PowerShell is exposed to us through hosting applications, like the blue console many of you use, or the PowerShell ISE.
We learn the PowerShell language of cmdlets, pipelines, object and variables and without much effort can get the job done. From creating a folder, starting a service or creating a new user account in Active Directory. PowerShell lets us take this a step farther by supporting a batch-style scripting language. If you can type a few commands in a PowerShell console, you can create a PowerShell script. Certainly, PowerShell scripting can get as complicated as you wish to go. For many IT Pros, their PowerShell experience will fall somewhere in the middle, and in fact may never need to use PowerShell for anything else.
The other aspect of PowerShell is that if you can do something for 1 you should be able to do it for 10, 1000 or 100000 efficiently. PowerShell 2.0 introduced PowerShell remoting so now we could run a PowerShell command or script against 1000 servers in the enterprise just as easily as we could against a single server. PowerShell 3.0 brought us CIM sessions and the WS-MAN protocol for working with WMI data on remote machines.
Today, PowerShell is a very flexible management engine that you can work with interactively, or through scripted solutions. As other vendors and Microsoft product teams introduce PowerShell support for their products, your investment in learning the PowerShell language, syntax and paradigm begins to pay off rather quickly. Of course, not every solution, even from Microsoft is perfect as even vendors I think sometimes have trouble truly grasping the PowerShell paradigm. I’m sure you’ve come across PowerShell modules that use non-standard verbs or just behave in ways you don’t expect. All we can do as members of the PowerShell community is gently prod them in the right direction.
As for the future, well, we’re already living in it. PowerShell 3.0 introduced the concept of workflow to many IT Pros. I’ll admit to some confusion myself in trying to understand how this fit into the PowerShell vision. A workflow script looked like PowerShell but didn’t fit into the mind-model I had at the time. PowerShell 4.0 brings us Desired State Configuration (DSC) which can also be baffling unless you adjust your perception. This is the realization I had during the MVP Summit as I saw demonstrations of technologies under consideration that might be part of the PowerShell paradigm.
Features like PowerShell workflow and DSC are not like PowerShell experiences you are accustomed to. Rather, these features are leveraging the PowerShell engine and syntax. Often, the actual work is done out of sight of the IT Pro using parts of the PowerShell engine, or other engines (WMI jobs run in non-PowerShell process for instance) that are never fully exposed to us. What we are doing is taking our experience with PowerShell syntax, language and elements and applying them to these features. Think of something like DSC as an extension to PowerShell, or at least to the PowerShell that you think you know.
You have to think of PowerShell as the glue that holds everything together in what we do as IT professionals. This is why it is important to learn PowerShell if you are responsible for managing Windows-based servers and platforms. Certainly, depending on your position you may not ever use any of the extensions like workflow. In fact, your role might be to simply run a PowerShell script or tool that someone else has developed. There’s nothing wrong with that.
But the more of the PowerShell world and paradigm that you can master, the farther you will go in your career. As PowerShell MVP Richard Siddaway is fond of saying, “PowerShell doesn’t matter. It’s what you can do with it that matters.” Fortunately for us it can do a lot and will continue to do even more in the future.
Agreed completely! DSC is just the beginning of the PowerShell pyramid. I am seeing more technologies relying on these mechanisms everyday. Just today, I found out that UE-V relies on it!
I’m attempting to incorporate PowerShell into the things I work with daily, including Configuration Manager 2012 and Active Directory. That was a great window to look in on for PowerShell. Thanks!