Best practices
These are the working habits that keep Overseer predictable as you add clients and computers. They cover scheduled maintenance, how to scope deployments, naming across your tools and email delivery.
Why these practices matter
Overseer does what you declare. A setup built from a few broad rules is easy to reason about: you can say what happens to any computer, and when. A setup built from many narrow rules and overlapping schedules is not.
The practices on this page all push in the same direction. Declare broadly, schedule sparingly, test on a few computers before the rest, and keep names consistent. Some of them need a role that can change settings for every client.
Scheduled maintenance
A schedule starts recurring maintenance sessions for the computers it targets.
Run scheduled maintenance once a week at most
Run scheduled maintenance for a computer once a week at most. That keeps the load down, on Overseer and on your clients' computers.
If you manage a large number of computers, do not run them all on the same night. Split them into batches that run on different days.
This limit applies to scheduled sessions only. Sessions a person starts are separate, and keeping the schedule light leaves room to push out an urgent item when you need to.
Schedule full maintenance
A schedule can be limited to a single item, but avoid making that a habit. A schedule for each deployment soon becomes a timetable nobody can read.
Prefer a small number of schedules that each run full maintenance for every client they cover. Full maintenance applies everything that targets a computer in one ordered pass, which is the point of a maintenance session.
Use tags to spread the load
A schedule can target a tag. Every client carrying that tag is then covered by the schedule, with nothing else to set up.
To spread maintenance over several nights:
- 1Create one tag for each night you want to use, for example Tuesday and Thursday.
- 2Create one schedule for each tag, recurring weekly on that night and targeting every client that carries the tag.
- 3Give each client one of the tags, sharing the computers out evenly between them.
Moving a client to a different night is then a matter of changing its tag.
Deployments
Declare for every client, then narrow down
Make a deployment that targets every client your default. Narrow it with a tag, a filter or a condition where it should not apply everywhere.
Keep deployments aimed at one client or one computer for real exceptions. One rule that covers all clients is easier to check than the same rule copied to each of them, and a new client is covered from its first session.
Target by what the client pays for
If your PSA integration reports what each client's agreement includes, use that as the target. One deployment for every client can then install your security software, or any other product you resell, only where the agreement includes it.
Two points keep this accurate:
- Keep start dates correct in your PSA. Overseer does not act on an agreement line that is not yet active.
- Or hold the client back by hand. Give that client its own deployment setting the product to Ignored, and remove it the day before the product is due to go on.
Test on a pilot group first
Create a tag for a pilot group and put it on a few chosen computers at each client. Create a schedule that targets only that tag and runs ahead of the main schedules.
Changes reach the pilot computers first. Review their sessions before the same changes reach everyone else. This needs a routine on your side: decide who reads the pilot sessions and when.
Keep names the same across your tools
Give each client the same name in Overseer as it has in your PSA, your remote management tool and your other tools. Matching names keep the standard you are aiming for consistent from one tool to the next.
The easiest way to hold to this is to choose one tool as the source of truth and create clients from it.
Make sure email arrives
Overseer can email the people who use your computers about maintenance. For those messages to be delivered:
- Send through an authenticated SMTP relay.
- Send from a domain you control. Do not spoof a sending domain.
- Set up SPF and DMARC for that domain.