84 tests in collectors/tests, run with Invoke-CollectorTests.ps1 (~15 s,
PowerShell 7.2+ and Pester 5.5+):
- Module.Tests: the shared module (property lookup, time format,
config/lookback, sent-run state and pruning, dry runs, exit codes,
401 detection)
- Veeam/Mars/Wsb/Vb365.Tests: each collector run in its own process
against its mock and a stand-in ingest API, asserting the behaviours
confirmed on real servers: VBR 13 live schedule, copy jobs, MARS UTC
times and ErrorCode 0, WSB culture-formatted times and nested VMs,
VB365 organization mapping, log prefixes and retries, state and
resending, rejected keys
- Installers.Tests: config, files and scheduled task from each
installer, with stand-ins for icacls / Task Scheduler / the key prompt
Collectors run under the test runner's PowerShell, or another shell via
-CollectorShell (e.g. powershell.exe, to test under Windows PowerShell
5.1 like the MARS, WSB and VB365 servers). The mocks take their "now"
from MOCK_NOW so expectations can't drift with the clock; the WSB mock
gains -RunningJobFinished for the running-to-finished case.
Each of 12 past bugs, put back one at a time, fails the test for its
behaviour (and the runner exits 1).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
On VBR 13 a job's ScheduleOptions property is a stale snapshot: NextRun
is empty (and its LatestRunLocal years old), so every Veeam job showed
no next run and could never be flagged Overdue. GetScheduleOptions() /
Get-VBRJobScheduleOptions return the live schedule ("2026-10-09
12:15:00 AM"). Use GetScheduleOptions(), falling back to the property.
Immediate-mode backup copy jobs (IsContinuous) have a live NextRun too,
but it's a stale date months in the past, which would show as Overdue;
keep reporting no next run for them.
Parsing tries the current culture, then invariant; VBR 13's format
parsed correctly under en-CA, en-US, fr-CA and en-GB. Mock updated to
VBR 13's schedule shape.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
VBR 12+ backup copy jobs showed as Unknown. Get-VBRJob returns the copy
(policy) job, but Get-VBRBackupSession only returns sessions of its
hidden worker jobs, whose JobId matches no listed job, so they were
dropped. Confirmed on a VBR 13.0.2 server with the new diagnostics
script.
- File worker sessions under their policy job via
Session.GetJob().PolicyJobId (looked up once per worker job), and
record the source job in details.copied_from
- Add Get-VeeamCollectorDiagnostics.ps1, a read-only report of jobs,
unmatched sessions and their link properties
- Mock: backup copy policy/worker case and a session from a deleted job
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PowerShell script for the VBR server, run as a SYSTEM scheduled task.
Each run reports every Get-VBRJob job's next scheduled run and any
sessions from the lookback window (default 48h) not yet delivered in
their final state; running sessions are resent until they finish.
- Session result maps to success/warning/failed; non-Stopped states
report as running; message combines the session reason, objects that
didn't succeed, and warning/error lines from the session log
- Delivered sessions are tracked in a state file; failures are retried
next run, and a rejected API key stops the run immediately
- Install-VeeamCollector.ps1 writes an ACL-restricted config, copies
the script to Program Files and registers the task
- tests/MockVeeam.ps1 provides stand-in cmdlets for testing without VBR
Co-Authored-By: Claude Opus 5.5 <[email protected]>
kyleandClaude Opus 5.5