During my daily scroll, I came across a post on Reddit asking the community “Why are admins afraid of PowerShell?”

As always, many people chimed in and gave their perspectives on why their admin is the absolute worst and how ignorant admins are paralyzed by fear of the unknown.

However, probably the most illuminating comment was that “PowerShell is f***ing scary and no one is holding your hand.” That got me thinking, admins aren’t afraid of PowerShell, they’re afraid of what an untrained/unrestricted user can do.

Risks Using PowerShell

Another comment in a similar thread summarized it perfectly: “When you’re facing a command prompt, you could type literally anything. There are no hints, no rails, nothing to help you know what to do next. For a lot of people, that can be very intimidating.” Even with testing, things can go south quick and that’s scary for a lot of people. 

Of course, blogs, education, and Comment-Based Help reduces risk and helps beginners. There’s a long list of tutorial commands like “Get-Command,” tab completion, and “Get-Member.”

Comment-Based Help is a collection of descriptions and keywords enclosed in a block comment. Unlike normal comments, PowerShell can read COMMENT-BASED HELP and display it upon request using the “Get-Help” command. CBH can be as simple as adding in a single sentence before the .SYNOPSIS or .DESCRIPTION of a script that describes what it does.

Comment-Based Help Example:

function OpenClosePorts {
<#
.SYNOPSIS 
Create, modify, or toggle a firewall rule
.DESCRIPTION
Create, modify, or toggle a firewall rule
Set the parameters for the new rule.
If a rule with the specified name exists > Update the rule to match the new parameters 
If a rule with the specified name does not exist > create a new firewall rule with the specified parameters
.PARAMETER DisplayName
Specifies the name of the firewall rule to be modified
.PARAMETER LocalPort
(Optional) Specify the port affected by the firewall rule
.PARAMETER Direction
(Optional)Specify if the connection is Inbound or Outbound. (Default = Inbound)
.PARAMETER Action
(Optional) Select if you want to Allow or Block a connection. (Default = Allow)
.PARAMETER Exists
(Optional) Enable or Dissable the rule. True/False (Default = True)
#>
param (
        [string]$DisplayName = "Test",$LocalPort = 8626, [string]$Direction = "Inbound",[string]$Action = "Allow",$Exists = $true
    )
    $CheckRule = Get-NetFirewallRule -DisplayName $DisplayName 2> $null
    
    if ($CheckRule){
        Set-NetFirewallRule -DisplayName $DisplayName `
        -LocalPort $LocalPort `
        -Direction $Direction `
        -Protocol TCP `
        -Action $Action `
        -Enabled $Exists.ToString()
        }
    else {
        New-NetFirewallRule -DisplayName $DisplayName `
        -LocalPort $LocalPort `
        -Direction $Direction `
        -Protocol TCP `
        -Action $Action `
    }
}

However, admins aren’t scared of PowerShell – they’re scared of what you can do in PowerShell if you don’t know what to do. What’s more, a team member using “Get-Command” probably isn’t the most confident with PowerShell and therefore should simply be using a manual solution.

Admins properly understand the capabilities of PowerShell and often have to make the decision to encourage safe, manual procedures over efficient, risky PowerShell commands. It’s incredibly easy to make mistakes in PowerShell that ripple into disasters.

So Everything Should be Manual?

Not at all, I’m just saying that I understand how the admins feel. It’s easy to get comfortable with a technology or tool and forget what it’s like for people who aren’t proficient with it. Picking up the PowerShell command line and using it for the first time is terrifying – it should be terrifying.

But it doesn’t necessarily have to be.

Using a free tool like Otter, allows team members (regardless of PowerShell skill) to be proficient and safely execute scripts to remote servers.

Otter does this in two ways: GUIs and server targeting.

GUI

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, and empowers your team to do the work they need to without oversight through job templates. The next time anyone needs to run a job, even if they don’t have permission to run scripts, they can use the template, which will restrict inputs AND 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 until they were free.)

Server Targeting

When you run a script through Otter against a server, you have three options for how to target your servers:

Direct: Simply specify servers by name, and the script is then run against each server.

Indirect: Specify a combination of roles and/or environments that will be used to specify the servers the script is run against. This requires some planning ahead.

Custom: Perform complex orchestration that can run different commands or scripts on different servers. These servers can be targeted sequentially, in parallel, and with branching and iterating (looping) logic. This is the most complex but most flexible option.

Using Otter, when you use direct or indirect targeting, you can use variable names. Otter helps ensure that the scripts are running against the servers you want decreasing the chance of accidental catastrophic failures happening.

Admins Aren’t Afraid of PowerShell

Admins are afraid of people. I’ve never met an admin who doesn’t fully understand and respect the power of PowerShell. However, pairing your PowerShell scripts with a tool like Otter means you don’t have to live in fear any longer.

Try Otter’s free forever version and level up your team’s PowerShell with generated GUIs and server targeting.

Are you ready to “Level Up” your PowerShell usage? For many more ways to give your PowerShell scripts and modules a boost, take a look at our free eBook, “Ultimate Powershell Levelup Guide”. Sign up for your copy today!