Use the KISS Principle for Your PowerShell Script

Summary: Microsoft Windows PowerShell MVP, Sean Kearney, teaches how to use the KISS principle for your Windows PowerShell script.

Weekend Scripter

Microsoft Scripting Guy, Ed Wilson, here. Sean Kearney graces us with his words of wisdom today as our guest blogger.

Photo of Sean Kearney

Sean Kearney is an infrastructure support analyst and Microsoft MVP in Window PowerShell. He is absolutely passionate about automation technologies—especially Windows PowerShell. If you say, “PowerShell,” he may just break into song. Sean considers himself “just a tech at heart,” but he can often be found dabbling with most Microsoft technologies at a moment’s notice. We have also been advised to keep him at arm’s length from any open Starbucks in Seattle.

Sean’s contact information:
Twitter: EnergizedTech
Blog: Energized About Technology
Website: PowerShell: Releasing the Power of Shell to You
MVP profile
LinkedIn profile

After looking at a lot of submissions in the 2011 Scripting Games, I had one thing I thought I’d throw out there: the KISS principle.

No, I do not mean that I am going to break out into parody of “I was made for lovin’ you, baby” by a certain rock group from the ‘70s. I mean simplicity.

I do not mean necessarily “simplicity of the script.” That can be interpreted in a myriad of ways. I mean simplicity of your thought process. Sometimes we need to think simply for the solution.

Yes, there are absolutely some better-practiced ways, more efficient ways to write the code—flows of binary that would make Bill Gates himself jump out of his chair and say, “Whoa! DUDE!”

But my background is as an IT professional. The amount of time that we may have to code a Windows PowerShell script (or any other solution for that matter) is INVERSELY proportionate to the amount of time our customers let us have free time to ourselves. We all know that sometimes that amount of time is about enough to sneeze, and maybe wipe your nose if you are lucky.

So when I write the script, it is a “NOW” solution.

For example, in the 2011 Scripting Games, I had to write a solution to quickly parse the Windows Update log for FATAL or ERROR. I received critique because, “It wasn’t necessarily the best solution.”

This is true. When presented with the task, I went about it with the thought process, “The boss has a computer, I’ve got 60 minutes to find the answer, I don’t have the Administrators Guide for Windows PowerShell handy, and (like the typical ITPro) I probably didn’t even have breakfast that morning.

My premise in script writing is “keep it simple.” I put my flow into the script so I can look at it immediately and understand “what I was thinking” when I go back to that script later.

When looking at the scripts during the games, I saw some absolute works of art that were applications unto themselves, but I kept thinking, “Simpler, simpler.”

I like a script that somebody can look at and immediately understand what I was thinking. I like “simpler” whenever possible.

Sometimes simple does involve breaking it into a function, but it depends on the purpose of the script. Whether it’s a one off solution or not, I tend to think out loud and type away. For example, in Beginner Event 6, the task was to get lines to match certain content, so my mindset was, “GET the CONTENT of the WindowsUpdate.log file first,” as shown here:

GET-CONTENT C:\Windows\WindowsUpdate.log

Then I was thinking to quickly examine the lines for a particular piece of content, as shown here:

GET-CONTENT C:\Windows\WindowsUpdate.log | WHERE-OBJECT { $_ –like ‘*fatal*’ }

Is this the FASTEST approach? Is this the BEST approach? Probably not. But it’s a simpler approach. The code just works. It CAN be improved without question, and it should be revised—but looking at its flow, it makes simple sense. More importantly, I am done with the task. I can now quickly focus on the more pressing issues, like unlocking some user account in the Accounting division for the 32nd time this hour.

Sometimes I have no clue about what the best approach is. I may just be typing things in Windows PowerShell, similar to the first time I had to query Active Directory to find who hadn’t logged in recently. I had the Quest.ActiveRoles cmdlets installed at the time. I pulled up a quick list of users like so:


And yes, B-O-Y, did it pull down a massive list—because I didn’t filter it. But piping it into Get-Member showed me that I could examine a property called CreationDate. I just wanted to see a list of users that had been created in the past 90 days. My thought process was as follows:

“GET me the list of USERS and store them away.”

“GET the date and store it away.”

“FOR Each user in the list, check the CreationDate against Today.”

“Show the Name on the Screen if they are LESS than 90 days old.”

This is what I wrote:




If (($TODAY – $PERSON.CreationDate) –lt 90) { WRITE-HOST $PERSON.Samaccount }


This is not necessarily the best approach, but it is the simplest approach (not in code, but in thought process). And that’s the point of Windows PowerShell. It is to try to come up with a simpler approach to getting things done. Whether you use a one-liner or even a simple foreach statement.  

Don’t forget. If it’s something you use on a regular basis, you can ALWAYS improve and revise it later. Your wheel may not be the BEST one your first time, but I am certain it (even if it is inefficient) will make YOU faster by making you more consistent.

…and this will make you look like a superhero.

Thank you, Sean, for this blog about practical scripting. You ARE a superhero—even if you do not wear tights and a cape.

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

Ed Wilson, Microsoft Scripting Guy