Summary: Ed Wilson, Microsoft Scripting Guy, talks about when to write a Windows PowerShell script. Microsoft Scripting Guy, Ed Wilson, is here. I am enjoying a beautiful sunny morning in central Florida. The sun is shining, there is hardly a cloud in the sky, and a gentle ocean breeze tickles my skin. I am sitting outside under a beautiful, several-hundred year-old oak tree with Spanish moss that hangs to the ground from its bent branches. I mean, dude, if ZZ Top had a tree, it would look like this one. Anyway, I am sitting out here with an oversized cup of Darjeeling tea, a plate of freshly sliced locally grown mango, and my Microsoft Surface Pro 3. It is a great, lazy day to sit and think, and to reflect.

Number one problem for noobs …

The number one problem that noobies seem to have when learning about Windows PowerShell is that they get overwhelmed with the power of Windows PowerShell, and they seem to go crazy. This gives me a reason to kick off To Script or Not to Script Week. I mean, I can be at Ignite in Chicago, and a person comes up to me and asks a question like this: “So, I have this server at work, and it has all of these logs. I want to write a script that will parse each of the logs, and look for problems. If there is a problem, I want it to send me a text message to my phone, send an email to my corporate account, turn off a couple dozen services, reboot our firewall and our router, send an alert to all of the users connected to the server to let them know that the router and firewall will be rebooting. I also want it to add an entry to an Excel spreadsheet to automatically calculate service up time, generate a Word document for our monthly report, and make a PowerPoint slide deck for our quarterly meetings about service availability. In addition, if it could track disk space usage and automatically submit purchase orders for additional disk drives when utilization is predicted to reach 85%, that would be nice.” I can’t help but reply, “Uh, you’re a Windows PowerShell noobie, aren’t you?”

What is wrong with the do-all-at-once script?

So what is wrong with the “do everything at once” approach to scripting? I mean, isn’t that what automation is all about? Well, yes and no. To be fair, the noobie scenario I described could, in fact, be scripted. I could probably write such a script in less than two hours. But to be honest, I don’t think I would ever write such a script—except maybe for a demonstration about how cool Windows PowerShell really is and for how it could be useful in automating day-to-day tasks. Why? Well, I will tell you…. Because in reality, such a thing would be of limited usefulness. It also would be a nightmare to troubleshoot and maintain. Why a nightmare? Because there are too many moving parts. When a script has too many moving parts, the chance for it breaking is greatly enhanced. I think for every one new capability I add to a script, there is a fifty percent greater risk that the script will fail at some point in the future. That is, unless you add a lot of error handling and abstraction of parameters. For every additional level of error handling you add to a script, you increase the development time by fifty percent. This means, that I can write a simple script with no error handling in thirty minutes. But it will take at least forty-five minutes by the time I add error handling for one potential set of problems. If I add error handling for another set of potential problems, it will take an hour… and so on. This is why, most often, when I write a simple script for myself, I do not add much in the way of error handling. I will add comments that tell me how to run the script. For me, that is generally enough unless it is something that I expect to be more robust. This week I am going to talk about the thought process that goes into writing Windows PowerShell scripts, and provide some guidelines that will help you decide what to script, when to script, and when to simply run a few basic Windows PowerShell commands from the Windows PowerShell shell. Hope you have a great week, and I will see you back tomorrow. 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