PowerShell has been around for many years now, but it’s still a source of confusion, anger, and frustration for a lot of IT professionals. To this day I still receive frequent comments and emails from people who are either:

  • Angry that a GUI management tool was replaced by PowerShell, or is less functional than PowerShell
  • Unsure which PowerShell commands to run for a task, and how to run them
  • Confused as to how a script or series of commands works, and unable to work out how to modify it for their situation

All of that is okay. We’re all beginners at something (lots of things, actually), and PowerShell is just another one of those things that has a learning process that you need to go through.

I will say though, if you’re in that first group of people who are angry about the dominance of PowerShell in the lives of Microsoft IT pros today, this article is not going to try hard to convince you to feel any better. Sure, if we happen to meet at a conference or event, I’m happy to have a beer with you and hear your story. But if you’re going to read any further, it should be because you’ve decided that no matter how you happen to feel about it, PowerShell is here to stay and it’s important for IT professionals to understand it.

A Little History

A long time ago, I was a desktop administrator. My job involved responding to tickets that were escalated from the help desk. Often this meant taking a long walk to the end user’s desk to fix a problem, because the help desk had been unable to use our remote control software to help them (it was constantly breaking).

I didn’t like taking those longs walks, particularly when it involved leaving the building to go across town in the middle of a hot Summer’s day. So I started looking for ways that I could remotely fix the most common problems with our desktop fleet (starting with that pesky remote control software). Using batch files and tools such as PSExec, I pretty quickly assembled a tool kit of useful scripts that saved me a lot trips. Maybe less walking wasn’t the best thing for my health at the time, but it certainly was good for my efficiency on the job.

Batch files can be surprisingly powerful, but I soon discovered VBScript and started writing more of my scripts in that language. I got reasonably proficient after a while, and our team tool kit once again expanded with useful scripts that improved our productivity. Many of the scripts were even provided to the help desk, which meant they needed to be pretty resilient to errors and simple to use.

In 2002 I heard about this thing called Monad. I found the Monad manifesto, written by Microsoft’s Jeffrey Snover. It seemed interesting, but we were working so hard at the time I didn’t give it more than a cursory examination before continuing on with my work in VBScript.

Fast forward a few more years, and after a string of roles in desktop and server support, my career had landed me in a role with a small consulting firm where I was tagged as “the Exchange guy”. This was shortly after the release of Exchange 2007, which threw a big new challenge at IT pros with its server roles architecture and use of PowerShell for management.

I got through my first few Exchange 2007 projects with a lot of “click, click, Next, Next” configuration, which was pretty slow going. But I noticed that Exchange 2007 would helpfully display the exact PowerShell syntax for the task you were about to perform, and let you copy it to your clipboard and save it for later. Projects started speeding up as I took more and more of the common deployment tasks, copied the PowerShell syntax, and started running the same steps as PowerShell scripts.

After a few more years of mostly working with Exchange, a new job opened up with a very large, multi-national organization. In my home town such opportunities don’t come along very often, so I took it. At first my role was simply moving mailboxes from various remote sites to new servers in a centralized datacenter. I pretty quickly scripted the migrations, to the point where I really spent most of my day analyzing data in Excel, working with the change control teams, and helping with the communications sent to each batch of users to be migrated that evening. At the end of the day I dropped a few CSV files in folders and went home, with the heavy lifting all handled by scripts and scheduled tasks overnight. In the morning I would check the results, send a report to the project manager, and start the whole process again.

That might sound a bit dull, but being there in that organization started opening up opportunities to help out with operational support as well. By the time the migration project finished, I had joined the team that managed the Exchange infrastructure for the Asia-Pacific region. Suddenly I was supporting far more users and servers than I ever had before, and I realised there was no way I could keep up without the help of scripting and automation. And that meant a whole lot of time writing PowerShell. Automation became critical to our team’s ability to perform our duties, as our head count shrank but our responsibilities grew. Doing “more with less” was the reality that we were dealing with.

In fact, it was in that job that the earliest versions of Get-MailboxReport.ps1 and Test-ExchangeServerHealth.ps1 were born, scripts that have been downloaded tens of thousands of times since. I literally used those scripts every day, and have continued to develop them and use them after I left that company.

Why Learn PowerShell?

At this point you might be wondering how my story applies to you. Perhaps you are thinking that since you don’t work on multiple customer projects, or don’t deal with hundreds or thousands of servers, that PowerShell has no real benefit to you. I don’t agree with that, because the same tasks that can be performed more efficiently in a 100 user environment can also be performed in a 10,000 user environment.

Tasks such as:

  • New user provisioning
  • Daily, or quick ad-hoc health checks
  • Monthly reports
  • Inventory collection
  • Copying files from one location to another
  • Archiving departed user data
  • Creating new virtual machines

If you’re going to do a task more than once, you should try to automate it with PowerShell.

Really? Even all those 10 second jobs that aren’t made any faster by scripting? Yes! For one thing, it’s good practice for writing PowerShell code. The more you write, the better you’ll get at it. And secondly, automation of tasks improves accuracy.

What’s more, the PowerShell you learn on one task will benefit you in completely different tasks later. Just because I learned my first PowerShell skills working with Exchange, didn’t mean I had to re-learn PowerShell again to work with Active Directory, DNS, Hyper-V, or anything else Microsoft releases that is PowerShell-driven (which is pretty much everything these days). PowerShell is PowerShell, and with knowledge of a few cmdlets like Get-Help and Get-Member, PowerShell becomes a self-teaching language.

And, importantly, the PowerShell skills you learn at your current job could help to land you the next (better?) job.

Are You Interested in Learning PowerShell?

You’ve read this far, so I assume that you’re interested in learning more. So where to from here? Well that’s up to you.

If you want to know more about PowerShell, leave a comment below to tell me the number one thing you wish you could do with PowerShell today.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.


  1. Josh

    My only widows computer right now is on my work computer, which is hosted on a server. I’ve tried a little with powershell in the past, but it seems like I am missing commands. Due to working in a call center, I can’t update anything.

    What I would like to be able to do is to 1) automate some of my notes. I type the same thing over and over, so I would like to be able to hit shift+f1 and have it type out stuff. This would be helpful.

    2) I would love to be able to have my system go from one window to another, click on certain links and then open up search windows so I find a serial number from a list.

    I have never used powershell before, so I don’t really know where to start.

  2. Ali Inam

    The main hesitation, in my opinion, is that I do not have a programming background. The word ‘scripting’ tells us that this is something to do with all the programming skills one could have. I know I might be wrong but there is a beginning to everything and I know we have to learn it sooner.

  3. Status

    Ramy – Filip, I am with you. A list of where to go and what to do would be amazing. If someone could supply a link to give further information I would be very grateful.

  4. filip

    I’m with Ramy. scripting logic and script workflows. Functions,For,Else,Loop and End.

  5. Ramy Asaad

    Hi Paul again

    If possible, it will be great to recommend a list of PowerShell books

    Thank you

  6. Ramy Asaad

    Hi Paul

    Really nice article, I have no that much experience in daily writting of scripts, so I want to learn scripting logic and script workflows in Powershell.

  7. Avram Woroch

    I can provide some feedback from a guy who falls into both camps. I love PowerShell… when I’m able to use it. Typically, I fall back to batch as most of the tricks I’ve learned over 20 years for parsing out data and combining it still work.

    PowerShell has brought me the following frustrations:
    * Find a way to do the task only to find out that’s a PS v3 or 2 thing and half the network has PS v1 – if it’s even available.
    * PS is the tool of choice and the language. But vX of whatever product doesn’t expost DHCP or XYZ role via powershell, so back to netsh or wmic I go.
    * Remote PS is disabled – never got installed, never got enabled, hyper-security sensitive administrators blocked or disabled it, etc.
    * WMIC is broken for some reason, and PS tool/module of choice relies on WMIC.

    Granted, many of these items point to a general health of the environment, consistency, planning, and staying current. But as a consultant, I’m often brought in for a specific project or task, and have very little impact over the environment other than to provide guiding commentary.

    So, quite often, I have to fall back to batch files that use FOR loops to kick out tokens to a file, and use find and such to parse them together into CSV’s I can import and then action with PSExec or something.

    I WISH PS was more consistent for me. I really really do. And in my lab, where it’s all 2012/2012R2 or better – I love it. But the customer environments don’t look like that in the real world 🙁 There’s an awful lot of very useful PS modules/functionality that only came in 2012 R2 (WSUS and DHCP and DHCP come to mind), and even if customers have SA, there’s not a ton of motivation to upgrade if they have a working fleet of 2012.

Leave a Reply