Deployments
A deployment is a standing declaration that something should be true on a set of computers. This page explains what a deployment contains, the choices you make in one, and when it takes effect.
What a deployment is
A deployment is a rule, not a job. A job runs once and is finished. A deployment stays in force and is checked again each time it applies, so a computer that drifts away from it is brought back.
Every deployment answers three questions.
- What. One software item or one task from the Library.
- Where. The target: the set of computers the rule applies to.
- When. The enforcement: how often the rule is applied.
This is why deployments exist. You write the rule once, and Overseer applies it to every computer the target covers, including computers that did not exist when you wrote it.
Software deployments
A software deployment names an application and a desired state. There are four.
| Desired state | What it means |
|---|---|
| Installed | Install the application if it is missing, and update it if it is old. |
| Updated if Found | Update the application where it already exists. Never install it fresh. |
| Uninstalled | Remove the application if it is present. |
| Ignored | Leave the application alone on these computers. |
A software deployment also chooses a version: either a specific version to hold computers at, or the latest. Where the application takes configuration, you fill in its parameters on the deployment, so one library item can be set up differently for different clients.
Task deployments
A task deployment names a task. Tasks cover everything that is not software, such as a Windows setting, a local account or a security policy.
A task deployment is Enforced: Overseer runs the task's check and, if the check fails, the task corrects the computer and the check runs again. A task can also be checked without being changed, which tells you where computers stand before you decide to act.
Enforcement
Enforcement decides when a deployment applies.
| Enforcement | When it applies | Suits |
|---|---|---|
| Required | In every maintenance session | Anything that must always be true, such as security software or a standard application |
| Onboarding | Once, when a computer is first set up | First-time setup, such as creating the first local account |
| Ad hoc | Only when a person runs it | Occasional work, such as a clean-up or a diagnostic script |
Targets, overlaps and exceptions
A target can be every client, one client, a tag or a single computer, among others. More than one deployment for the same item often reaches the same computer. When that happens the most specific one wins: a deployment aimed at one computer beats one aimed at a tag, which beats one aimed at its client, which beats one aimed at every client.
That rule is also how you make an exception. Suppose a browser is Installed for every client, but one computer runs a display in a reception area and must not be touched. Add a second deployment for the same browser, aimed at that one computer, with the desired state Ignored. The standard holds everywhere else.
When a deployment takes effect
Saving a deployment changes nothing on any computer. A deployment is applied inside a maintenance session, which is one complete ordered pass over one computer. A session starts on a schedule, when a computer is onboarded, or when a person presses Run maintenance.
A deployment can be switched off without being deleted, which keeps the rule for later. It can also be copied, which is the quickest way to start an exception from an existing rule.
The Deployments screen
The Deployments screen lists every deployment you are allowed to see, grouped by scope: those aimed at every client first, then each client's own.
Each row shows the item, whether it is software or a task, its target, the number of computers it reaches, its enforcement and its desired state. Counters above the list total the deployments by kind. You can filter the list to one client, search it by name, press New deployment to add a rule, or press Edit on a row to change one.
Habits that help
- Start narrow. Aim a new deployment at one computer or a small tag, then widen the target once it behaves.
- Test somewhere disposable. Windows Sandbox is a good place to prove an installation before it reaches a real computer.
- Read the session afterwards. The session shows what was asked, what the computer answered and how each item ended.
- Keep exceptions few. Each exception is a rule someone has to remember. Use a tag where several computers share the same need.