PowerShell has been around for a long time now, consistently proving its value in terms of automation. PowerShell (aka Shell) was first introduced to me personally when it was still code (named Monad) in the early 2000s. Even then, it was clear that Microsoft had a long-term plan when they began sharing bits of code within the Exchange platform. Every time you did something in the GUI they would share with you the code to complete the task in Shell. They were making sure the learning process was already beginning.


PowerShell has come a long way since the early days of Monad, and just about any product, Microsoft or not, has PowerShell commands to help you complete your job.


Modern Day

Today, PowerShell is seemingly everywhere. Its ability to automate tasks that the traditional toolset cannot is impactful and necessary. Today, all administrators need to be able to do some level of PowerShell from simple to complex.


So, why has this become a staple in our workday?


Organizations today are streamlining IT always striving to simplify their workday.  Some may argue that organizations are trying to do more with fewer employees. This almost implies they are trying to overwork their teams, but I prefer to take a more positive spin. To me, automation is about allowing a process to flow, and happen in a way that simplifies my work day. This doesn’t mean that I am kicked back with nothing to do when automation is complete. It means that I get more time to work on other things, learn more, and grow professionally.


Today, automation presents endless possibilities. For context, let's take a look at some things that we automate today that, in the past, we handled manually.


  • Operating System deployment – In the early days of IT, we were feeding floppy disks or bootable CDs into computers to manually deploy an operating system to a computer. Once that was complete, we still had to install all of the necessary applications. Repeat this for every single person that needed a PC, and you had potentially thousands of PCs repeating this very manual process. When the application “Ghost” was released, we were ecstatic. Now we finally had a way to copy an image and deploy it to another PC, which significantly reduced our deployment time. Today, really the only accepted approach is to automate workstations via third-party tools and/or PowerShell. Enterprise IT staff cannot imagine spending a whole day setting up a laptop or PC for a user anymore. Now you are done in less than and hour!
  • Reporting – Anyone who knows me knows that I have done a lot of work with Citrix, and over the years I have found that there are just some things traditional reporting tools don't offer. While third-party offerings in this space are much improved today, this doesn’t mean that I might now need a custom report. PowerShell to the rescue! Custom reporting gives me the insights into my environment that I need to help ensure that it’s healthy and running successfully for the enterprise.
  • Microsoft Exchange – As previously mentioned, Microsoft Exchange was one of the first applications from Microsoft to use PowerShell. When working with Exchange, you open Exchange Management Shell to get all of the Exchange-related PowerShell commands pre-loaded. From daily tasks to automating mailbox moves and more, Shell has proven its value over and over if you are working with Exchange.


This list really only scratches the surface of PowerShell's automation possibilities. If you are doing work on Windows, as with most applications today, PowerShell skills are necessary for your technical success.


Taking it to the Next Level


The automation movement has already started. The power of automation has the potential to really change the landscape of the work we do. I anticipate that the need for automation will continue, and over the next few years the more we can automate, the better. That being said, there is a risk to automating everything with custom code without proper documentation and team sharing.  As employees leave organizations, so does the knowledge that went into the code. Not everyone that writes code does it well. Even if the script works, this doesn’t mean that it is a quality script.  Application upgrades typically involve rewriting the automation scripts that go with it.


As you can see, the time savings can go right out the window with that next big upgrade. Or does it?


If you plan the upgrade timeframe to include the rewrite of your automation scripts, then you are still likely better off than you were without it due to all of the time savings you realized in between.

My final thoughts on this, despite all of the pros and cons to automation, would be to automate what you can as often as possible!