If you listen to the evangelists, you'd probably think that in 2017, there is only one person who isn't using PowerShell: you. Everyone else not only gets it, but uses it to automate all of their work, including manipulating databases, monitoring systems, interviewing candidates, and filing IPOs. And the simple fact that you don't use it makes you a dinosaur. Frankly, it's amazing that you're even employed.
Luckily, you don't listen to evangelists. They spend too much time on Twitter and not enough time in the trenches.
So let's quit talking about PowerShell like it's the harbinger of change in the technology world. It's a scripting language1. Not the first, not the last, not the best, not the worst. It's not going to change your life. If you're unhappy with your job, learning PowerShell may be a temporary distraction from your unhappiness, but it's not going to change your sentiment with regard to your work.
I'm telling you this because you should have realistic expectations, in general, but specifically with new technology.
Once you've taken a moment to reconsider your opinion of PowerShell as panacea, continue reading.
Ready?
Now that you've gotten rid of the anxiety surrounding PowerShell, you are ready to see its strengths and weaknesses more clearly. For example, if you're looking to make a simple change to a number of servers, PowerShell is a great tool. If you're looking to deploy patches to a mission-critical database server, you're better off with another solution. PowerShell, like most automation solutions, is ideal for 1:many actions. The work is front-loaded; spend time developing a solution, then use automation to scale that solution out.
This is all to say that you should not consider PowerShell as a foreign language to learn only to remain relevant in IT. You should consider it as a technology that can change how you approach your work, especially when you're managing an infrastructure at scale.
Consider a timely example that we're dealing with in the Microsoft shops of the world: the mass disabling of SMBv1. In Server 2012 and newer, there's a PowerShell cmdlet that can be used to enable and disable SMB on a remote server. And even though you immediately think to yourself, "I can do this in a GPO," I submit to you that PowerShell is a much cleaner way to implement this type of minor change, if for no other reason than you're avoiding GPO hell, which is like .dll hell, but with a GUI.
With PowerShell, you can query AD for a list of computers, filter out the server running 2012 and newer, and invoke a remote cmdlet to disable SMBv1 on as many servers as you'd like, all in one fell swoop2. You don't need to worry about WMI filtering in GPOs, or wondering if your custom method of settings registry values will work on all versions of Windows Server. You just put a few lines of PowerShell together, and go.
The point of this post is not to show you the script itself (although I'll follow this post up with a post that includes the deets, because I oscillate wildly between essays and engineering). The point is that PowerShell really is an amazing chunk of code, and once you get your mind right about why you'd use it, learning PowerShell is fun.
1 - PowerShell MVPs and enthusiasts of all stripes just rolled their eyes so hard they can see their own brain stem.
2 - Your high school English teacher would really appreciate it if you'd read Macbeth, really read it, not just skim the first act and confuse it with Hamlet, which you should also read. Thanks.
