The client is split across two folders by design: program files (code, locked down) and program data (config, logs, working files).

C:\Program Files\Outpost — program code

Locked to SYSTEM + Administrators. Contains the scripts the scheduled tasks run.

C:\ProgramData\Outpost — config, logs, working data

Also locked to SYSTEM + Administrators (only tray.json is user-readable, so the tray can read its config).

The client is driven by two scheduled tasks. Nothing runs as a Windows service.

Inspect them

Or with PowerShell:

"Restarting" the agent = running its task on demand. It normally runs itself every minute, so you rarely need this — but it forces an immediate check-in.

Force an immediate run (check-in now)

Stop a running agent (e.g. a stuck live-mode process)

Restart the tray for the current user

Kill a tray that's misbehaving (agent will relaunch it within a cycle)

Disabling stops the tasks from firing but leaves everything installed — useful for pausing a machine during maintenance.

Disable (pause) both tasks

Re-enable

A disabled agent stops checking in and will show Offline in the dashboard after 15 minutes.

Tail the agent log (most recent activity)

Watch the log live

What agent / tray version is installed?

Is the agent enrolled? (server URL + agent ID; no secrets shown)

In Live mode the agent holds a connection open to the server so commands run in ~1–2s. Toggle it per-machine on the machine's Console tab. Machines not in live mode use the 1-minute check-in.

Is this machine actually live right now?

Check the heartbeat is recent (updates every ~25s while live):

And look for this line in the log:

Commands are slow / not returning

Confirm the machine is on a recent agent (BOM fix + live mode need 1.12.0+), then force a check-in and re-test. If it's a Bitdefender machine, see the AV section below — task/command operations may be blocked by ATC.

The client is unsigned PowerShell running as SYSTEM, which behavioral engines (Bitdefender ATC especially) may flag. Symptoms: Access is denied on task operations in the log, quarantined files, or a missing tray.

In GravityZone, exclude the client folders (tick On-access + ATC/IDS):

Folder exclusions don't cover ATC's behavioral block on powershell.exe itself (it lives in System32). For that, add a Process exclusion for C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe (On-access + ATC/IDS) — or, tighter, use GravityZone's Add exclusion → To profiles from the Blocked Applications report. The permanent fix is code-signing the agent (one certificate-hash exclusion).

Note: the v1.0 folder is a legacy name — that is Windows PowerShell 5.1, the current engine, not "PowerShell v1."

Reinstall or repair (safe to re-run over an existing install)

Grab the machine's install one-liner from Fleet → Add device (it includes the enroll key). It re-creates the tasks and refreshes files.

Uninstall completely (removes tasks + both folders)

Replace YOUR-SERVER with your RMM URL. Run elevated. After uninstall the machine goes Offline and can be removed from the Fleet list.

Manual cleanup (if a task got orphaned)

Windows' execution policy blocks unsigned scripts. The install one-liner from the dashboard already prepends a process-scoped bypass, but if you're running a script by hand, set it for that window only (nothing permanent):

A server rollback does not automatically repair endpoints when the broken agent fails before check-in. Use the dedicated Recovery page for pinned tools and the full incident procedure.

Correct recovery order

1. Make the server serve the last known-good agent.
2. Run Stable Agent Recovery on each affected endpoint.
3. Repair the scheduled task only when it is missing or malformed.
4. Collect diagnostics from devices that remain offline.

Never delete C:\ProgramData\Outpost\config.json during a normal rollback. It contains the device identity and token. Deleting it turns recovery into re-enrollment and can create duplicate or mismatched records.

From agent 1.13.0, every device carries an isolated Windows Update worker. The main agent only checks in and runs jobs — it never talks to Windows Update itself. A separate worker process scans, hides denied updates, and installs approved ones on its own scheduled tasks with hard timeouts. A slow or stuck Windows Update can therefore never take a device offline: worst case the device shows a degraded update status while staying fully online and manageable.

The one switch that matters

Policy → Manage Windows Update with PrimeNetCore. OFF = observe mode: the device reports its update inventory and nothing else — users keep their normal Windows Update controls. ON = managed mode: user update controls are blocked, Windows is set to notify-only, denied updates are hidden from Windows itself, and installs happen only through PrimeNetCore (manual approval or policy). The global default applies to every customer that hasn't been given an override in the Per-customer tab. Devices converge within about 15 minutes of a policy change — no reinstall, fully reversible.

Update categories

Policy → Update categories controls what auto-approval may touch: Auto follows the severity + delay rules; Manual approval shows the update as pending until a technician approves it; Report only is informational — policy never installs it (a deliberate manual approval still works). Defaults: Drivers and Firmware report-only, Feature and Preview/Optional manual. Security and cumulative updates always follow the severity rules.

Daily workflow for technicians

Approve on a device page or in Patching queues the install; the isolated worker installs it and posts the result. Deny hides the update from Windows on that device (verified — the row shows the enforcement state). Un-deny restores it. Denied updates stay listed with a strike-through; they are never silently deleted. Each device page has Recent update activity inside the Windows Update card — the worker's run history (scans, hides, unhides, installs, errors).

What end users see

In managed mode: Windows Update settings are read-only for the user, "Check for updates" and Pause are blocked, and denied updates simply do not appear. Windows still shows its own seeker offers (e.g. the monthly preview banner) — those cannot be installed by standard users and are a known Windows-side display quirk, not a gap in enforcement.

Quick health checks on an endpoint

Expect agent 1.13.0+, the scan task present and Last Result 0 (75 just means a scan yielded to a running install — normal), and a recent worker report with worker_status: ok.

Good to know

New devices enrolled with the usual Fleet → Add device one-liner get all of this automatically — the agent provisions its own worker files and tasks on the first check-in. Devices that were offline during a server upgrade self-update whenever they next check in. If a device shows "awaiting capable agent" on the Policy page, it simply hasn't picked up agent 1.13.0 yet.

Look for a current run time, Last Result: 0, the expected stable agent version, and a recent successful check-in.