Anyone who has worked with me for any length of time has heard me speak ad nauseam about how PowerShell is the greatest thing to come to the Windows ecosystem since Active Directory. Yet there are those troglodytes who insist on clicking away in the GUI, ignoring the speed, efficiency, and consistency that come with performing tasks at the command line. As recently as this past May, I met someone at Microsoft’s TechEd conference whose primary responsibility was to manage and maintain Microsoft SQL databases and the servers that they run on, and who was largely unaware of the ability to leverage PowerShell for SQL management. After a 30 minute conversation, and another 10 minutes of browsing for resources, this person was convinced that conservatively, he would be able cut two to three hours of repetitive weekly work down to about 15 minutes. Saving two hours per week adds up to an extra 13 days per year, and I know that in the seemingly endless struggle to trim budgets and do more work in less time, anyone reading this blog would love to get 13 days of time back (or if you’re a manager, get 13 days of extra productivity from your staff).
But who has time to learn this stuff? Well, the answer is anyone and everyone… but especially people new to managing anything in the Windows ecosystem. The way I learned PowerShell was by learning Exchange. When Exchange 2007 was released, I was in a position where most of the senior staff at my company had left, and I was put in charge of a number of projects, including deploying our new messaging platform. At some point I realized that the GUI was only giving me half the story, and I started running “Get” commands in the Exchange Management Shell. What I saw was an enormous amount of information that simply was not available in the GUI. From that point on, I have been loath to manage any part of Exchange from the GUI and even get frustrated when people asking me for help point to the GUI and don’t even have the shell open.
So while I may be a command line snob (I always was jealous of my Linux friends in that regard), and the GUI in most cases is an adequate management tool, there are several reasons that working and scripting in PowerShell is an essential skill that every admin needs and every organization can benefit from.
Automation
It is well worth investigating whether anything that you do on a regular basis is something that can be automated and/or scripted. PowerShell scripts are easily leveraged as scheduled tasks, making zero-touch management for certain tasks possible. For the bean counters, it’s an easy task to find out if a task is worth automating. Just figure out how long it takes you to perform a task, and multiply it by the number of times in a given period that you perform this task. If the number of hours that it will take to develop a script is less than that number, you are already in the black. What you do with that extra time is up to you, but I hope my SQL friend that I mentioned above spent some of those 13 days figuring out how to automate more of his tasks. But ROI is not the only reason you should consider scripting a solution.
Consistency
Human beings are unreliable. We make mistakes, we get sick, we cut corners, we change jobs, and sometimes we are too busy tending to emergencies to keep up with tedious tasks. So when an admin is inundated with a myriad of mundane operations that require multiple steps, things will get missed. We also have egos and sometimes fail to acknowledge or admit to these mistakes. So while I am not calling for the creation of Skynet, or advocating an AI takeover, there is something to be said for extricating the biological subsystem from certain tasks within your environment. A script operates the same way every time and doesn’t make mistakes. If the results of a script are not what you expected, then either you wrote the script wrong or the conditions in which the script is operating have changed.
Troubleshooting
Even without going into scripting, learning how to effectively leverage PowerShell in your environment can make your troubleshooting that much more efficient. For example, I have a list of commands that I run through whenever I am trying to troubleshoot issues. Instinctively, the first thing I do when logging into an Exchange server is open the Exchange Management Shell and run the following commands:
Get-MailboxServer | Get-MailboxDatabaseCopyStatus
Get-TransportServer | Get-Queue
Test-ServiceHealth
Test-ReplicationHealth
I know that the result of these commands will give me an indication of the general health of an Exchange environment and a good idea of what component or setting to look at next. All of this, and it likely takes under a minute in even the largest of Exchange environments. Trying to get all of this information from the GUI (some of which isn’t even available) would take 5 to 10 minutes in a small Exchange environment, with that time increasing proportionally with the size of the Exchange environment.
Expanding Ecosystem
The biggest reason to learn PowerShell may be something I like to call “PowerShell Sprawl.” With each release of Windows Server, Microsoft has exposed an increasing number of components and services to PowerShell. These services are not limited to on-premises deployments and extend far into the cloud, with PowerShell being an essential skill in managing your Office 365 and Microsoft Azure presence. It is also not limited to Microsoft Products, as many third-party vendors have written PowerShell modules to manage their own products, such as VMware with the “PowerCLI”, which with its most recent update, supports the newest versions of vCloud Director and vCloud Air.
From a Microsoft perspective, one of the latest and most interesting extensions is the PowerShell Desired State Configuration (DSC), which allows you to define a configuration template that a server will configure itself to, and provides a means to maintain that configuration going forward, preventing “configuration drift.” Shipped with PowerShell v4 on Windows Server 2012 R2, DSC is changing the way we consider deploying and maintaining Windows Server environments.
There are more benefits to be gained from investing in PowerShell skills than can possibly be explained in one article. Keep an eye on this blog for more on how to better automate and manage your environment with Windows PowerShell.