The Oversight Windows agent is a single small program that runs as a service on a Windows server, watches it continuously and decides for itself whether anything is wrong. It serves that verdict over HTTP: nothing wrong, or what is wrong and how badly. Oversight reads it with a Windows agent sensor.

It judges on the server because it knows the server far better than a threshold in a template can: how long a call to WMI or the service manager usually takes on this machine, which network ports have ever had a link, whether a service is quietly crashing and being restarted. It is read only by design, runs as its own virtual service account with no administrator rights, has no way to run commands, and nothing it serves is a secret, a process list or a user name.

It runs on Windows 10 and Server 2016 onwards, desktop or server, and finds for itself whether the machine is a domain controller or a Remote Desktop Session Host.

Installing it on the server

No script is run. In a Command Prompt opened with Run as administrator:

cd %TEMP%
curl.exe -fLo oversight-agent.exe https://oversight.im/windowssensor/oversight-agent-windows-amd64.exe
certutil -hashfile oversight-agent.exe SHA256
oversight-agent.exe --install --listen 10.1.1.100:29731 --token A-LONG-RANDOM-TOKEN --allow 10.1.1.25

The hash printed by certutil must match the one published at oversight.im/windowssensor; if it does not, do not run the file. curl.exe is part of Windows 10 1803 and Server 2019 onwards; on Server 2016, download the file in a browser instead. The same page lists every command below.

The install copies the program to C:\Program Files\Oversight\agent.exe, writes C:\ProgramData\Oversight\agent.json, creates the OversightAgent service running as NT SERVICE\OversightAgent, adds that account to the built-in Event Log Readers and Performance Monitor Users groups, opens the port in Windows Firewall to the allowed addresses only, and starts it. The config file can be read only by the service, SYSTEM and Administrators, because it holds the token.

Set --token, --allow or, better, both. Without either the agent listens on 127.0.0.1 only, and it refuses to listen beyond the server with neither.

Check it from the server before going near Oversight:

curl.exe -H "Authorization: Bearer A-LONG-RANDOM-TOKEN" http://10.1.1.100:29731/v1/status

Upgrading is the same download, check and --install: it stops the service, replaces the program and starts it again, keeping the config. Removing it is "C:\Program Files\Oversight\agent.exe" --uninstall, which leaves C:\ProgramData\Oversight to be deleted by hand.

Adding the sensor

On the device that is this server, add a sensor of type Windows agent. If the agent has a token, add a credential of type Windows agent on the Credentials panel of that device, or of a group above it to share one token across many servers, with the token in the Bearer token field. The sensor sends it for you.

A new Windows agent sensor is ready to use as soon as it is saved. It starts on the Status endpoint with these rows and rules already filled in. Changing the endpoint afterwards does not change the rows, because each endpoint carries different fields.

The rules: SV20 (HTTP status) not 200 is critical, SD01 red is critical, SD03 not empty is critical, and SD01 amber is a warning. SV20 is 401 for a wrong or missing token and 403 for a probe outside allow.

The agent also reports directory (domain controllers) and rdsh (Session Hosts), which have no slot of their own: there are ten text slots. Their problems are always in SD02, Status, and they can be extracted in place of an area that does not apply to the server.

Finding servers left behind

Because Build and Patch level are numbers, a rule or report can find every server at or below a given build, an upgrade that never happened, or below a patch level, one that has stopped taking updates. Read Build together with OS: servers and desktops share build numbers (Server 2019 is 17763, 2022 is 20348, Server 2025 and Windows 11 24H2 are both 26100).

What it checks

A problem must hold for the time shown before it raises, and clear for as long before it drops. For five minutes after a reboot nothing raises except the reboot and a crash, so services and links have time to arrive.

From the event log, each raising at once for the time shown:

The event checks take no limits: each can be turned off, and disk_errors, svc_crashing and svc_start_failed can be told to ignore one disk or service under ignore, by the name the alert gives it.

This list is a file, events.json, signed by GEN and fetched from oversight.im when the service starts and daily after, so a new Windows release needs a new list, not a new agent. A file that does not verify is refused and the agent keeps what it had, and where outbound access is blocked it simply uses the list it was installed with. events_version and events_source in the status say which it is using.

Anything that cannot be checked on a server, such as Kerberos on a machine in a workgroup, is listed under unavailable with the reason, so a check that cannot see is never mistaken for one that found nothing.

On a domain controller

A domain controller has no local groups, and the agent's own account cannot join the domain's, so the install says so and carries on without them. Everything still works except the Server service's work-item counters, which are listed under unavailable; the share-list timing, the main part of that check, is unaffected. The session count works everywhere, since it is taken from which sessions have a signed-in user's shell running, which needs no rights.

Protection: Defender

Defender is reported on its own endpoint, /v1/protection, and never in Status, because many servers are protected by another product. Where Defender is the protection, add a second Windows agent sensor on the Protection endpoint. It is amber at worst:

• antivirus or real-time protection switched off;
• signatures 7 days old or more;
• a threat found or acted on (Defender 1116, 1117), or real-time protection turned off (5001), for an hour after.

Where Defender is in passive or EDR block mode, another product is the protection and nothing raises; unavailable says so.

{"alarm":"amber","alarms":1,"status":"Defender real-time protection is off","defender":true,
 "defender_mode":"Normal","antivirus_enabled":true,"realtime_protection":false,
 "signature_age_days":0,"unavailable":[]}

with the rules SV20 not 200 critical and SD01 amber a warning. The signature age threshold is "defender": {"sig_days": 7} in the config.

Named events

For the few things only an event shows, list them in the sensor's Named events field, up to 20, comma separated, each as channel/ID or channel/provider/ID:

System/disk/7, Application/1000, Microsoft-Windows-Windows Defender/Operational/5001

Give the provider wherever the ID alone is ambiguous: 1001 is a blue screen in System and an application error report in Application. When one is seen, it appears in SD03 and in the status text for an hour or three polls, whichever is sooner, and the rule on SD03 makes the sensor critical. The first poll after the list changes reads the last hour back, so an event just before is not missed. Only IDs travel, never the text of an event.

The config file

To quieten an alarm on one server, find its check first: the alert's detail is the agent's own words, and the tables under What it checks give the check each message comes from, so commit reaches its limit in 2.1 h is commit_rising. Turn it off, or change its limits, under checks here. To exclude one volume, adapter or service rather than a whole check, name it under ignore. It can only be done on the server: nothing in Oversight changes the agent's settings.

C:\ProgramData\Oversight\agent.json, edited as Administrator. After editing by hand, net stop OversightAgent && net start OversightAgent.

{
  "listen": "10.1.1.100:29731",
  "tokens": ["a-long-random-token"],
  "allow": ["10.1.1.25"],
  "checks": {"vol_full": {"amber": 85, "red": 95}, "reboot_pending": false},
  "ignore": ["E:", "Ethernet 2", "SomeVendorUpdater"],
  "services": ["W3SVC", "MSSQLSERVER"]
}

When it is not answering

• SV20 401: the token in the credential does not match one in tokens.
• SV20 403: the probe's address is not in allow.
• No answer at all: the service is stopped, or the firewall rule does not cover the probe. Running --install or --allow again rewrites the rule from the config.
• The agent logs to the Application event log, source OversightAgent. "C:\Program Files\Oversight\agent.exe" --dump status samples for a minute and prints what it would report.