Weekend Scripter: Why Should I Learn PowerShell?

Summary: Microsoft Scripting Guy, Ed Wilson, talks about why you should learn Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. The other day, I ran into an IT pro at the mall. He recognized me and started talking to me. It was like, dude, I was trapped. It turned out that he was cool, and yapping with him was much more fun than walking around a boring mall. Although, this particular mall happens to have a Microsoft Store in it (which incidentally is why the Scripting Wife and I made the trek downtown). Hmm, come to think of it, that might also be why there happened to be an IT pro hanging around. Anyway, he asked me a question that I have taken for granted for a number of years. In fact, I was actually a bit shocked that an IT pro would even ask this question today. But it turned out to be a good experience.

Basically, he said that at work he is swamped. Really swamped. Over the past several years, their staff has literally been cut in half, but the number of servers per staff member has nearly tripled. It is working him to death. Basically, he said that he does not have time to learn Windows PowerShell. Their training budgets disappeared years ago, and there is no time off to attend free events at the Microsoft Office. There is no lab at work, so if he was to learn anything new, it has to be on his own time, at home, using whatever equipment he happens to have on hand.

When I asked him how they managed their environment at work, he told me it was basically a hodge-podge of things cobbled together over the years. Many of their solutions were created by people who are no longer with the company, or by people who no longer have time to manage the solution that was created. This is because they now have new positions or so many additional responsibilities, that they have no time to fix or modify whatever was created so many years ago. Therefore, when something breaks, there is basically no one to fix it. They spend most of their time in break/fix mode, and they move from crisis to crisis.

When I asked him why he remained at the company, he told me that he felt he was lucky to have a job. As a matter of a fact, he had been looking for a new position, but his skills were pretty much out of date (they still have some NT 4.0 servers in production).

So, I told him he needed to learn Windows PowerShell. Surprisingly, he asked, “Why?”

And then I told him. Here are some of the main points I made.

Top five reasons for learning Windows PowerShell

1. It will save time.

Big time. Here is a prediction: For every hour, you spend learning Windows PowerShell, in the course of a single year, you will realize a two-fold return on the investment in your time. This value increases exponentially with the size of your network and the number of servers for which you are responsible. Note: I made this up, and there is no implied guarantee associated with this. But the numbers are also based on hundreds of conversations I have had with IT pros over the years.

Consider the following real world scenario:
You have no automation in place, and you need to create 50 new users in Active Directory. By using the graphical tools, it takes a minimum of 30 seconds per user. That is 25 hours of boring, error-prone work. But even a novice can create and run a script to create all 50 users in less than two hours. For the sake of argument, let’s say it takes five hours to research, create, and test the script. That one script still saves 20 hours of work—a tenfold payback with the very first use. And the next time another 50 users need to be created, it will take much less time to simply modify the script and run it anew.

2. It is less error prone.

As I alluded to in point number 1, it is less error prone. I don’t know about you, but I still remember a time when I was using Active Directory Users and Computers at a customer site (14 years ago). It was about 2:00 A.M. and I had been working for over 18 hours straight. I dozed off with the mouse in my hand. That was when I first learned that Microsoft had put drag-and-drop in Active Directory Users and Computers. Dude, I was panic stricken as I tried for the next several hours to find and to confirm everything that I had inadvertently moved.

If I had of written a Windows PowerShell script, a mistake like that would not have occurred. How many user names have you ever seen in Active Directory that were all lower-case, some that were first initial only, and every other possible combination of entry? How many streets are abbreviated, and how many are spelled out? Is it One Times Square, one times sq, or 1 x sq? Or is it all of these?

3. It is self-documenting.

Even if I mess up in a script, I at least know exactly what happened because my script becomes my change control. The script itself is what was done. Even when working interactively from the Windows PowerShell console, I can turn on logging. Therefore, I have a record of what was typed and what the outcome of the command was.

4. It is the Microsoft standard for automation.

Everything has Windows PowerShell in it. It is the standard for Microsoft automation. This means that I can use Windows PowerShell for Exchange Server, for SQL Server, for SharePoint, for Windows Server, for Hyper-V, for Office 365, for Azure, and so on. If I want to automate processes, configuration, maintenance, and other daily activities, Windows PowerShell is the way to go.

5. Everything you learn applies to everything else.

PowerShell is PowerShell is PowerShell. Everywhere, it the same. This means that if I use Windows PowerShell to administer Active Directory, I can also apply that knowledge to administering Exchange Server. When I learn Windows PowerShell conventions, I can sense how it will work on other products.

But that is not all because the Windows PowerShell team respects the effort you spend in learning Windows PowerShell. What I learned about Windows PowerShell 1.0 applies equally well to Windows PowerShell 4.0, and this knowledge will also provide me with a good stead when the next version comes out.

It is not like having to forget everything I learned last year to work with this year’s version of the product. There may be improvements, shortcuts, and new features, but the old ways continue to work. I have scripts that I wrote in the beta of Windows PowerShell 1.0 and they still work today.

There are many other reasons for learning Windows PowerShell, such as interaction with a great community of fellow scripters, and the fact that Windows PowerShell is just plain fun. If you become addicted to Windows PowerShell, you might even begin talking in Windows PowerShell code. I remember one time when someone asked someone else how they were doing that day, and they replied, “Dollar sign wonderful.” I am not naming names, mind you—but that actually happened, and there were witnesses!

I hope you have an awesome day.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (9)

  1. I say, its a must for every SharePoint administrator to learn to script in PowerShell, in order to effectively work on SharePoint.

  2. @Nick @wayne riddle

    Ed might have made a booboo on the math but speaking as somebody who had to manage an Active Directory infrastructure for a decent size user environment it still adds up.

    What you also get out of using PowerShell is Consistency in User Creation and ease of use in certain day to day Management tasks.

    Think on the Lunch hour when everybody seems to lose their brains and forget their passwords. Invariably you have 5 people (random uses too, that drove me nuts) coming up and having locked themselves out.

    Old process, find user in GUI, unlock account, maybe reset password.
    Do this again 5 times
    Oh right
    Somewhere in this process somebody locked themselves out again (Grrrr) reset their password again.

    I found at lunch time this was an ongoing 20 to 30 minute battle daily depending upon who/how many times they did it/how urgent it was to them and how far up the ladder they would go to bypass the Support Queue.

    With PowerShell it was one Cmdlet in Quest (Unlock-Qaduser) with a quick "up cursor, type new name enter"

    The other one you ran across were users that had to be disabled at a specific time. In Powershell with Quest I could immediately type in Disable-QADUser accountname and there access was off *or* schedule a task to run that Cmdlet at the days end.

    So maybe on creating users I did not save 25 hours a week but on regular tasks? User creation, Disabling, password resets, unlocks (especially when I created a script to fully automate the user creation process across multiple environments *AND* do that with
    a simple prompt of "First Name, Lastname, Division, Location")

    Yeah…. I also forgot to mention that we had this tied into a SOX compliant process. The time saved when the company would onboard 5 or 10 staff plus offboarding *AND* auditing A/D for changes….. EASILY 25 hours saved per week with Powershell.

    Windows PowerShell MVP

  3. Wayne Riddle says:

    "You have no automation in place, and you need to create 50 new users in Active Directory. By using the graphical tools, it takes a minimum of 30 seconds per user. That is 25 hours of boring, error-prone work."

    Was the math or posting done using PowerShell?

  4. nick says:

    For piont 1 to work you need 3000 users.

  5. KRountree says:

    uhhh… might want to take a look at your math in Point 1… 30 seconds x 50 users = 25 minutes not 25 hours 🙂 but your point is well taken… cheers!

  6. John Alacce says:

    The big savings appear when you realize the value in error prevention and remediation.Manual tasks result in more mistakes. Mistakes cost money and in some cases jobs. Putting the time into developing tools also gives your junior IT pros the opportunity
    to develop their skills instead of wasting it on manual tasks. Letting them see your scripts and give feedback also brings them along. It’s the flywheel effect.

  7. I really wonder.
    every time I try to run some example of powershell that is supposed to do something wonderful
    they never work.
    always with some arcane error that takes more time to try and figure out
    than to whip up a vbscript that is done in seconds.
    been doing that for 10 plus years.

  8. David Johnson says:

    "4. It is the Microsoft standard for automation"
    Not until I can write my Excel macros in it it isn’t! (Seriously, when’s that coming? It’d be awesome)

Skip to main content