A new, high-priority compliance requirement just came in! It seems simple enough: close up these 3 ports. And then you look closer: on all 1000 servers. 

Most of us would go straight to PowerShell Remoting. Windows PS Remoting (PowerShell remoting) lets you run any Windows PowerShell command remotely on other machines. Using PS Remoting, you can establish persistent connections, start interactive sessions, and run scripts on remote computers.

All of this sounds great in theory. But in practice – things get a little….messy. We all know that PowerShell is incredibly powerful. PS Remoting takes that power and risk of critical failure and then amplifies it. However, PS Remoting isn’t the only option. There is a much better way to run your PowerShell scripts on your 1000 servers. 

What is PowerShell Remoting & Why Would You Remote?

PS Remoting allows you to run commands on one or hundreds of computers with a single PowerShell command.

To run your script on a remote machine, start an interactive session, run a remote command, run the intended PowerShell script, and establish a persistent connection. The PowerShell scripts entered in the local system are sent to the remote computer and executed there.

PS Remoting enables team members to work on machines much more easily and faster. Regardless of team size, walking up and down rows of servers or driving to where your servers are located and accessing them is a logistical impossibility for most IT organizations/teams.

Problems with PS Remoting

The first major problem with PS Remoting is just how difficult it is to set up and execute. Networks and servers need to be configured in complicated ways to make them work. These configurations often require approval/authority/access from other members of your team. This turns a simple script execution into a team exercise since the person who configures your networks and servers most likely isn’t the team member responsible for configuring credentials.

Even after networks and servers are set up perfectly, PS Remoting is not as straightforward or “easy” as running a PowerShell script on your local machine. This basically restricts anyone but a senior team member or your local PowerShell expert from running scripts via PS Remoting. Running scripts via PS Remoting forces you to double down on how reliant your team is on your PowerShell experts. This creates a bottleneck and forces your PowerShell experts to be on hand to complete the simplest/straightforward remote scripting work. On top of this, because of how powerful it is, PS Remoting amplifies any errors that may occur. Errors can occur on the local machine, network, or remote machine.

So what you have is a lose-lose situation when PS Remoting:

•  You require your PowerShell experts to run all PS Remote work, creating a bottleneck.
•  OR you risk it and allow junior members to PS Remote eventually creating a bottleneck for your PowerShell experts when things go sideways.

Remote with Otter & Why It’s Better than PS Remote

The alternative (and in my opinion the better) option is to use a tool like Otter to run your PowerShell scripts remotely. Otter is better at running PowerShell remotely than PS Remoting for 2 big reasons:

1. Server Targeting

Server targeting allows you to create a Job Template restricting what actions users can take and reduces the risk of critical failure.

When creating a job template, you need to specify:

• Script to run
• Server targeting
• Template variables
• User permissions

You can specify server targeting to ensure the correct server is targeted. Scripts are run against a server, and there are three ways a job can target servers:

• Direct (simplest for just one or two): specify servers by name, and the script is then run against each server.
• Indirect (requires some planning ahead): specify a combination of roles and/or environments that will be used to specify the servers the script is run against.
• Custom (most complex but most flexible): 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.
• Note that, when using direct or indirect targeting, you can use variable names. See variables to learn more.

In Otter, server targeting is restricted by default. This means that the user creating a job from a template cannot change the server targeting defined in the template.

You can make the server targeting editable at job creation time by configuring “Allow server targeting to be specified when creating a job.” Note that the user creating the job must have permission for the environments that the server is in; see the security and access controls to learn more

The good thing with Otter is that you can control Who Can Create Jobs.

You can configure access controls (Admin > Tasks) to decide who can run jobs from templates. If you select “Allow creating jobs from the user interface,” it will be accessible to users who have permissions and can run jobs from templates.

2. Orchestration

Otter uses Jobs/Templates, Servers, and OtterScript (Otter’s domain-specific language) to orchestrate multiple servers by sending commands and telling them to run scripts in a specific order, at a specific time, perform custom server targeting, etc. OtterScript is accessible and easy to learn for those with little to no programming experience but is still extensible and powerful for those with programming and domain expertise.

Using the Visual Mode in the plan editor, many users may not even realize they’re building orchestration plans using OtterScript.

Orchestrations are often very complex and thus risky and nerve-wracking. Unlike PS Remoting, Otter allows you to simulate an orchestration job for testing before running the real deal. The peace of mind that this gives you when running complex orchestrations is immeasurable.

Some examples of orchestrations in Otter are:

• Installing a new version of software on a lot of different servers
• Installing a number of Windows patches on certain servers that need them
• Gathering dozens of different files on different servers and uploading them to a backup location
• Run job execution logic without sending commands or running scripts on actual servers to ensure that scripts/commands execute on the right servers, in the right order, and at the right time.

In Otter, you can do simple remote execution and complex orchestrations.

Simple remote execution runs commands and scripts against servers without having to “connect” to them first in your orchestration scripts or use passwords. This saves time and enables team members to self-service since users don’t need passwords to do their work.

Complex Orchestration is great because it enables complex orchestration scenarios like targeting servers sequentially, in parallel, or with complex branching/iterating logic or executing against any number of servers by name, role, and/or environment. This reduces the risk and stress that usually comes with complex remote orchestrations. This also enables team members to self-service since complicated orchestrations don’t require experts to run once they’re created

Conclusion

Running PowerShell scripts remotely is an integral part of your team’s work but PS Remoting is not an ideal way to go about it. PowerShell Remoting is too powerful, difficult to set up, and frustrating to work with. Using a tool like Otter enables team members to execute PowerShell scripts remotely without needing a PowerShell expert sitting right beside them.

Thanks to the restrictions, plans, and templates that your PowerShell experts set, users of any PowerShell level can run complicated server orchestrations through Otter.

Download Otter’s free forever version and try out the orchestration.  

Using Otter is just one way 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!