CORE FEATURES

Script editor

The Script Editor is where you read, write and test the PowerShell that software and tasks are built from. This page describes the parts of the editor and what each is for.

What the Script Editor is

Every action Overseer takes on a computer comes down to a PowerShell script. The Script Editor, found in the Library, is the one place where all of those scripts can be opened.

Any script opens here, whichever kind it is.

Global scripts are built in. You can open and read them, but you cannot change or delete them.
Local scripts are yours. You can create, edit and save them.

The editor exists so that nothing Overseer runs is hidden from you. Before a script reaches a computer you can read exactly what it does.

You rarely start here. When you build a software item or a task, Overseer creates and attaches its scripts as you go. Open the Script Editor when you want to read a script, change one of your own or test one.

The parts of the screen

The Script Editor with a script open, between the explorer and the script's details.

Explorer. The list of scripts. Local scripts come first, then Global ones, each grouped by category. The built-in categories are Diagnostics, Maintenance, Network, Patching and Preflight.
Open scripts. Each script you open gets its own tab, so you can keep several open and move between them. Close a tab when you have finished with it.
Editing area. The script itself.
Script details. The properties of the open script, including where on the computer it runs.
Script output. What the script returned when it ran, and any syntax errors found in it.
Functions. The helper functions a script can call. Type part of a name to find one.
Search. Finds scripts by the text inside them, or by name if you prefer.
Test run. Runs the open script against a computer you choose.

Where a script runs

A script's details say where it runs, and the choice changes what the script can do.

As the system. The script runs with full rights on the computer and cannot show anything on screen.
As the user. The script runs as the person logged on, with that person's rights, and needs that person to be logged on at the time.

A script that works at your own PowerShell prompt and fails in a session is often running in the wrong place. Check this setting first.

Writing and saving a script

You can start a new Local script from the explorer. Give it a name, set where it runs, write the PowerShell and save it. The script is then available to your software items and tasks.

To change a Global script's behaviour, make a Local script of your own and use that in its place. The built-in script stays as it was.

Testing a script

A test run lets you try a script against a real computer before any deployment depends on it. Choose a computer, run the script, and read the result under Script output.

A test run is a real run. It does on that computer whatever the script says, so use a computer kept for testing, or Windows Sandbox, until you trust the script. Like any other action, a test run is recorded in the audit log with who ran it and when.

Next steps

Scripting guideWhere scripts run, how they fit a deployment, and how to write them well. Creating and managing tasksWrite a PowerShell task that checks a setting and corrects it. Command referenceThe kinds of helper command Overseer gives your scripts.

Was this article helpful?

← Targets and targeting Installing the agent →