Not Everything Needs to be a PowerShell Script


Crista Perlton

Crista Perlton


Do I really need to leave .NET Framework for .NET 8? 13th September, 2023

Demystifying Microsoft .NET Long Term Support (LTS) in 2024 30th August, 2023


Not Everything Needs to be a PowerShell Script

Posted on .

This is going to upset some people but – Not everything you do to provision and maintain servers needs to be automated.

Yes, PowerShell scripts are powerful, versatile, and reusable. But honestly, sometimes doing things manually or creating a simple application for more junior members to use is the right choice.

Your time is valuable, you are skilled, and (more often than you probably like to admit) you are wasting your time on scripts when things can be done manually.

Here’s an overview and guide (call it a little cheat sheet) of manual vs applications vs scripts, their pros and cons, and how you should be utilizing each of them.

Let’s imagine we have to open one port and close another port on an unknown number of servers.


Is the simplest execution of a task. To open/close our two ports you simply have to navigate through the UI clicking start/control panel/system…find the ports and open/close them.


Doing things manually is intuitive, it’s easy to train junior members on, and the user interface presents a limited number of things you can do based on buttons available to click. What that means is that there’s a very low chance someone can make a critical mistake.


It’s time-consuming and you need to know what and where the buttons are. Manual processes require training and directions. In our example, manually opening two ports on five servers would be reasonable. Opening two ports on 50 servers would be unreasonable. However, the biggest con to manual execution is the opportunity for human error. For every extra server your poor junior member has to set up, the risk of error increases.

When to Use

When you have a process that doesn’t have to be repeated very often or when there are many variables you can’t automate or predict.


Applications can be as complicated or simple as you need them to be. They’re built by your team (or for your team) and can be customized how you like. To open/close our two ports in a fantasy application you would simply run the application, locate the ports, verify their current status, and press a button to open one port and close the other.


Your application’s user interface is controlled by your IT organization. Everything you need to do is displayed in the interface and guides the user. Applications can be as complex or as simple as you need them to be and can cover a vast number of functions. There’s a lot less room for error compared to doing something manually.


They take a long time to create and a long time to update. In our example, if the ports changed or if we wanted to add a third port, we would have to add those features, test, and deploy (you know the song and dance.) Applications are only worth it for predictably repetitive activities.

When to Use

Due to the work that needs to go into building and maintaining an application, you should look at using these with expect to routinely do with little variation. Applications work perfectly in situations where something that can be automated but you’d like to control the actions via user interaction.


What you already know and love. PowerShell scripts are powerful, versatile, and useful for automating tasks.


Scripts allow you to do anything and everything you want. They’re extremely versatile and adaptable to anything you want. If you have the skills and know-how, you can easily add an extra port (or a hundred) to open/close.


Scripts are extremely technical and therefore aren’t very accessible to junior members. The risk of failure or catastrophic failures is highest when using scripts (compared to manual and applications.)

When to Use

All other use cases.

Best of Both Worlds: GUIs

If you’re looking for a solution that gives you all the power and flexibility of scripts with all the control and guidance of an application, you need to be using GUIs.

Instead of trying to make an application out of a script, I prefer to use Otter to run scripts with auto-generated UIs.

GUI’s let users run PowerShell by themselves and provide a job-specific interface to enforce limited input. They allow you to limit who can do what with PowerShell in that given situation and give “immediate visual feedback” (aka lets you know when you’ve forgotten a required form, for example.)

Using a GUI is intuitive and allows anyone on your team, regardless of PowerShell experience, to be productive.

Creating a GUI with Otter

Otter can automatically generate a UI around your scripts. It does this in two ways:

  • Comment-based Help
  • Otter’s Job Template Feature

Otter lets you add comments and descriptions, which as I’ve stated before, is the key to near-perfect PowerShell scripts (definitely read this article if you need to learn how to do Comment-Based Help).

And by using job templates, you enable self-service. The next time anyone needs to run a job, even if they don’t have permission to run scripts, can then use the template, which will restrict inputs AND will remind you when you’ve forgotten to fill out required fields. (In an untemplated world, you’d have to bug your manager any time you needed to do this and wait around til they were free.)

Get Everything you Want and Need

“If the only tool you have is a hammer, you will start treating all your problems like a nail.”

Scripts are cool and impressive, but they aren’t always the solution; Doing things manually and building applications have their place too. Use GUI’s if you want the best of both worlds.

Download Otter to try more and get started with your own GUIs.

Crista Perlton

Crista Perlton