nginx now checks every dashboard and API request with oauth2-proxy
(auth_request), which signs users in with Microsoft Entra ID. Who may
sign in is controlled in Entra: a single-tenant app registration with
"Assignment required", so only assigned users/groups get through.
- deploy/oauth2-proxy.cfg (entra-id provider, auth-only mode, secure
cookie, trusted proxy = localhost) and deploy/oauth2-proxy.service
- nginx: pages redirect to Microsoft sign-in and back to the same URL;
API calls get a plain 401 (the page already asks to reload);
/api/v1/ingest stays key-only for collectors; /oauth2/auth is
internal; the signed-in user is passed to the API in headers nginx
sets (so browsers can't spoof them); dashboard files are served with
Cache-Control: no-cache so updates show up at once
- GET /api/v1/me; the top bar shows the signed-in user and a Sign out
that also signs out of Microsoft (otherwise SSO signs straight back in)
- README: Entra and server setup steps
Tested locally with oauth2-proxy 7.15.5 and nginx 1.31 running the
deploy configs (TLS, self-signed): redirects to the tenant's sign-in
with the return URL kept, 401s, ingest bypass, sign-out allow-list,
cookie flags, security headers. The signed-in path was tested with a
stand-in for oauth2-proxy's auth answer; a real Entra sign-in wasn't.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The Veeam, MARS, WSB and VB365 collectors each carried identical copies
of logging, ISO time conversion, property lookup, posting to the API,
config loading, TLS setup, the sent-runs state file and the 401 check,
and their installers repeated the same key prompt, locked-down config,
file copy and scheduled-task registration. These now live in
collectors/common/BackupDashboard.Collector.psm1:
- Initialize-Collector / Test-RunSent / Send-JobReport /
Test-AuthRejected / Complete-Collector for collector runs
- Write-Log, Get-ErrorText, ConvertTo-IsoTime, Get-FirstValue
- Install-CollectorTask for the shared half of each installer
Collectors find the module next to themselves (installed) or in
..\common (repo); installers copy it into Program Files beside the
collector. The diagnostic scripts stay standalone single files.
No behavior change: a harness ran each collector against its mock
(12 scenarios: dry run, two real runs against a stub API, state file,
logs, exit codes, rejected key, en-GB, backfill) before and after, and
all 84 outputs are identical. Installers, run with stand-ins for the
Windows-only commands, write identical configs and tasks; the only
differences are the module being copied and the summary line naming
the shell's path.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PowerShell script for the VB365 server, run hourly as a SYSTEM scheduled
task (Windows PowerShell 5.1 by default, -PwshPath for PowerShell 7).
One dashboard job per VB365 backup job and backup copy job.
- Sessions from Get-VBOJobSession (and Get-VBOCopyJobSession where
available) within the lookback window; status from session Status,
message from the session log's warning/error lines, size from
Statistics.TransferredData ("1.5 GB" -> bytes)
- One VB365 server can protect several Microsoft 365 organizations, so
the dashboard company is chosen per job: OrganizationTenants mapping,
else Tenant, else the organization's name
- Next run from the job's NextRun; empty for disabled jobs
- Get-Vb365CollectorDiagnostics.ps1 dumps jobs and sessions, showing
each DateTime's Kind (local vs UTC); installer adapted from MARS
Not yet run against a real server.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PowerShell script for servers using Windows Server Backup, run hourly as
a SYSTEM scheduled task under Windows PowerShell 5.1. Each server is one
dashboard job.
- Backup jobs from Get-WBJob (in progress and -Previous) within the
lookback window; restores are ignored. WSB jobs have no ID, so runs
are keyed on start time, which also merges a Running report with the
finished one
- Error HRESULT -> failed; detailed error or a failed item -> warning;
messages include the error description, codes as 0x8XXXXXXX, failed
items and the failure log path
- Next run from Get-WBSummary's NextBackupTime
- Get-WsbCollectorDiagnostics.ps1 dumps the cmdlets' real objects and
recent Microsoft-Windows-Backup events (to check whether job times
are local or UTC); installer adapted from the MARS one
Not yet run against a real server.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PowerShell script for servers running the MARS agent, run as a SYSTEM
scheduled task (hourly) under Windows PowerShell 5.1, which the
agent's MSOnlineBackup module targets. Each server is one dashboard job.
- Backup jobs from Get-OBJob (in progress and -Previous) within the
lookback window; restores are ignored. Completed with failed bytes
or an error reports as warning
- Next run computed from the backup and System State policy schedules;
left empty for every-N-weeks schedules to avoid false Overdue alarms
- Property reads tolerate unknown names, since the agent's object
model isn't documented; Get-MarsCollectorDiagnostics.ps1 dumps the
real structure for checking
- Install-MarsCollector.ps1 mirrors the Veeam installer; tests/MockMars.ps1
provides stand-in cmdlets
Not yet run against a real MARS agent.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
kyleandClaude Opus 5.5