Documentation Getting started Core concepts
GETTING STARTED

Core concepts

Overseer is built from a small set of ideas - deployments, targets, maintenance sessions, the agent, tenants, software and tasks. This page explains each one and how they depend on each other.

How the pieces fit together

Overseer does one thing: it makes computers match what you have declared.

You describe an item in the library, as software or as a task. A deployment says what state that item should be in, and a target says where. A maintenance session compares each computer with its deployments and closes the gap. The agent does the work on the computer. Tenants keep each client's computers and results apart.

Each idea below leans on the ones before it.

Deployments

A deployment is a standing declaration, not a one-off job. It answers three questions:

  • What. One item from the library: a piece of software or a task.
  • Where. The target: the computers or people the rule applies to.
  • When. The enforcement, which is one of three settings.
Enforcement When the deployment applies
Required At every maintenance session
Onboarding Once, when a computer is first set up
Ad hoc When a person runs it

A deployment for software also carries a desired state.

Desired state What it means
Installed Install the software if it is missing, and update it if it is old
Updated if Found Update the software where it already exists, and never install it fresh
Uninstalled Remove the software if it is present
Ignored Leave the software alone
Saving changes nothing yet. A deployment only declares. Nothing happens on any computer until a maintenance session runs.

Targets

A target decides which computers a deployment reaches. A target can be:

  • Every client. All the computers you manage.
  • One client. All the computers belonging to a single tenant.
  • A tag. Every computer, or every client, carrying a label you have applied.
  • A single computer. One named computer.
  • A person or a group of people. Overseer resolves the people to the computers they use.
  • Computers reported by an integration. For example, the computers of clients whose agreement in your PSA includes a particular product.
  • A filter script. A PowerShell script that decides, computer by computer, whether the deployment applies.

A deployment aimed at one client or one computer can override a broader one for the same item. That is how one computer gets its exception.

Maintenance sessions

A maintenance session is how deployments reach a computer. It is one ordered pass over one computer, in stages.

Detection is read-only. Overseer gathers every deployment that targets the computer, reads the computer's current state and lists the actions needed to close the gap. A maintenance action is one piece of work on one item.

Execution carries those actions out in order. After each action the computer is read again, and the item is marked Compliant only when that check passes. The finished session reads Passed, Partial passed or Failed.

A session starts in one of these ways:

  • By hand. A person presses Run maintenance.
  • On a schedule. A schedule starts sessions for the computers it targets.
  • From outside. An integration or the API asks for one.

The Overseer agent

The agent is a lightweight service on each managed computer. It keeps a connection to Overseer and:

  • carries out the commands a session sends
  • reports the computer's details and status
  • runs installers and applies configuration
  • runs PowerShell scripts, either as the system or as the person using the computer

The agent runs alongside whatever remote management tool you already have.

Tenants

A tenant is the record of one client in Overseer. Each tenant has its own computers and people, can have deployments that apply to it alone, and can carry its own settings, such as its time zone.

Tenants can be nested. A child tenant sits under a parent and inherits certain settings and deployments from it.

Software and tasks

Everything a deployment can name lives in the library, as one of two kinds of item.

Software

A software item is made of:

  • Versions. The releases of the software that can be deployed.
  • A detection method. A check that reports which version, if any, is on the computer.
  • Install scripts. The scripts that carry out the installation.
  • Configuration scripts. Scripts that set the software up once it is installed.

An item can also name prerequisites: something that must be installed, or removed, before it. Overseer follows those links and puts the actions in a working order.

Tasks

A task covers anything that is not software: a setting, a clean-up job, a piece of information to collect. A task has a check, which answers yes or no, and a correction. When a task deployment is Enforced, Overseer runs the check, runs the correction if the check fails, then runs the check again. A task can also be checked without being changed.

Where a script runs

Scripts are the building blocks of both software and tasks, and each one runs in a set place:

  • As the system. On the computer, with full system rights.
  • As the user. On the computer, as the person using it. That person must be logged on at the time.
  • On the Overseer server. Away from the computer, where a script can check another system or direct work on the computer.
  • Against a client. On the Overseer server, for work that concerns a whole tenant instead of one computer.

Next steps

Common workflowsThree jobs you do often, each written out from start to finish. DeploymentsStanding declarations of what should be true, and where. Maintenance sessionsWhat one complete run does, stage by stage.
Was this article helpful?
← Quick start guide Common workflows →

In development. Launch inquiries welcome.

This documentation describes Overseer as it is being built. If you would like to hear when it launches, get in touch.

Ask about launch