Automation Decisions

This post is an updated reprint from an article published to my premium PowerShell newsletter Behind the PowerShell Pipeline available on Substack. Subscribers receive 6-8 articles like this a month delivered to their inbox or available on the Substack app. I hope you’ll consider subscribing. Trial subscriptions are available.

I’ve been scripting and automating things since the days of DOS 3.3, beginning with batch files. It always felt like magic. I could cast a charm simply by typing a few characters on a keyboard. Naturally, my magic skills went from batch files to VBScript to PowerShell. Throughout it all, I’ve also had an internal decision tree regarding automation. Over the years, I’ve seen IT pros new to scripting and automation needlessly struggle. Often it is due to a deficiency in their decision tree. Today, I thought I’d help you nurture yours.

Is it Worth the Investment?

This is the first question you should always ask when considering a new automation project. I’m sure you’ve all heard the phrase, “Just because you can do something doesn’t mean you should.” This is especially true when it comes to PowerShell.

PowerShell makes it easy to automate tasks. Ideally, you use PowerShell and automation to handle repetitive tasks, especially unglamorous tasks that must be done regularly. Any PowerShell solution that you develop will require an investment. At a minimum, you are investing time to write your code. This is time you are taking away from other work. Depending on the task, you may need to invest in additional educational material such as books or courseware.

As you consider a new PowerShell project, you need to be able to estimate how much time you will need. This becomes easier as you gain experience. And with experience, you’ll also find you can do more in less time. You need to weigh the time required against the time saved. For example, I probably wouldn’t take the time to build tooling around enabling the Active Directory Recycle Bin feature. Yes, you use PowerShell, but this is not an ongoing task. But I would create a PowerShell tool around resetting a user’s password.

Of course, there are exceptions. You may want to develop a PowerShell solution as a means of improving and expanding your scripting skills. I’ve been known to joke about spending a day writing a PowerShell function that saves me a few seconds. But, over the course of a year, those seconds add up. And when I’m finished, I’ve most likely learned something that I can use in future projects. In these situations, I’m using a different metric to justify my investment. It isn’t the time I’m saving but the learning process that warrants my time.

The bottom line is you need to look at the task at hand, consider how much of an investment it will require, and calculate the cost-benefit ratio. Your time is limited and valuable so use it wisely.

Can It Be Scripted?

You also need to consider if you can even automate the task at hand. I’ve seen many requests for automation help over the years that boggle my mind. This is a case where you must understand PowerShell and recognize what it is designed to do and, more importantly, what it can’t. Here is a shortlist.

• PowerShell is not designed to click through a website.
• It is not designed to run ON a website.
• It isn’t designed to manage a user’s Outlook inbox.
• PowerShell isn’t intended to manage desktop applications.

PowerShell was designed as a management engine, which initially meant Windows servers. It has since been developed to include cross-platform server management and cloud-based service management. I’ve never considered PowerShell a good tool for managing an end user's desktop or client experience.

I recognize that there you might be able to use PowerShell for some of these tasks. But most likely, it will require very sophisticated scripting, if not outright hacks, that border on .NET development.

Are There Better Alternatives?

Just because PowerShell is at your disposal doesn’t mean it is the right tool for your automation task. Instead of trying to cobble together PowerShell scripts to manage a client desktop, you should use Group Policy. That is a tool designed for that task. Do you really need to automate a GUI interaction? Consider a tool like AutoIt. There is almost more than one way to do something in Windows. Granted, you may need to do some research to discover alternatives.

I remember years ago getting a request for help with VBScript. The IT Pro was new to scripting but wanted to write a script using WMI to set file permissions. This is something that not even I would have wanted to do. A better choice would be using a tool designed for managing file permissions like cacls.exe or icacls.exe. Even today, using PowerShell to manage file permissions in Windows is not a trivial task. It may be just as easy to write an old-fashioned batch file using one of these legacy, but still useful utilities.

That said, using PowerShell may be justified even if there is an alternative. Assuming, of course, that the task at hand can be accomplished with PowerShell. If you need to integrate additional functionality like support for -Whatif, alternate credentials, or logging, writing a PowerShell solution may be worth your time. Assuming you’ve already done the cost-benefit analysis, I recommended earlier.

PowerShell Isn’t Always the Answer

By now, I hope you aren’t too surprised for me to tell you that PowerShell isn’t always the right tool for the job or the legacy alternative is just as valid. I am more likely to run route instead of Get-NetRoute. This is especially true when I only want to get a quick look at something.

It is just as easy to run:

icacls .\data.txt

as it is to run:

get-acl .\data.txt | select-object -ExpandProperty AccessToString

Let’s say you want to manage power settings on a local computer. The CLI tool powercfg.exe is going to be your best bet. Or you need to manage local security settings. PowerShell doesn’t offer any out-the-box solutions. You’ll most likely need to use secedit.exe. But remember, nothing is preventing you from wrapping these legacy tools in PowerShell. Secedit.exe doesn’t have a -WhatIf equivalent, but you could write a PowerShell function that does.

You Decide

I hope you don’t think I am advocating you only use PowerShell for special cases. That is not true at all. I would encourage you to always be thinking about how you could use PowerShell to make your job easier. However, you need to remain open to the possibility that PowerShell may not be the right tool for the job. Or even if it is, is it worth the investment? Before you dive into a new scripting project, take at least a moment to think and make a conscious decision. I hope this article will help you make the right choice. At the very least, I trust it will be an informed decision.