Oliver Kieselbach
4bc2435ec5
Q1 (AppInstallTiming): a terminal->active transition (IME retry path, e.g. Error->Downloading or Skipped->Downloading) re-arms CompletedAtUtc so the final terminal payload covers first-start -> last-terminal instead of freezing at the first terminal state. Plus a negative-duration guard in AppInstallTiming.DurationSeconds (inverted endpoints -> null, field omitted) - observed in production as durationSeconds=-2342 on a Skipped-then-retried user-scope app (session 66f1c5e1). Q2 (esp_config_detected): the ESP blocking lists are read too early - device lists grow progressively, user-scope S-<SID> lists appear only after sign-in (88 of 89 prod sessions had an empty user list at last emission). DeviceInfoHost now re-collects the ESP configuration as phase-driven one-shots: apps sub-phase declaration (AppsDevice/AppsUser phase_transition = first app activity) and AccountSetup detection. The StartupEventGate keeps unchanged payloads silent (fingerprint covers list contents), so only grown lists actually re-emit. F1 EspBlocking resolution (latest list-bearing emission) benefits without backend change. Q5 (HardwareInfo): WMI values (serial, manufacturer, model) trimmed at the source via NormalizeWmiValue; whitespace-only collapses to the "Unknown" sentinel the retry logic already treats as unresolved. Attach-window investigation (11a3b67a): NO agent fix - hypothesis disproved against two real agent logs (diag bundles db5ce007/2.0.1337, 4a9e9273/2.0.1379). "completed without started" first apps were already installed (WinGet detection-only, zero install lines in AppWorkload.log); pre-attach replay provably works (pattern-match log). PR0's HasMeasuredDuration already handles the class server-side. Duplicate app_install_completed (66f1c5e1): mechanism narrowed to an in-process re-read of exactly one AppWorkload rotation window (<24h-old lines, historic suppression not applicable) - documented as follow-up, no fix without a bundle-bearing repro per lessons.md. Verified: solution build clean, Agent V2 Core 2058/2058 (14 new tests), DecisionCore 493/493. No ConfigVersion bump, no new event types, decision rail untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
AutopilotMonitor
Advanced monitoring and troubleshooting solution for Windows Autopilot deployments. Gain full visibility into every enrollment session with a detailed event timeline, fleet health dashboards, and session reporting. Define custom analysis rules to automatically detect issues and gather rules to collect targeted evidence. Retrieve diagnostics packages on demand, configure agent settings like auto-reboot behavior and automatic timezone adjustment — all managed centrally from the web dashboard.
Private Preview
Autopilot Monitor is currently running as a Private Preview. Visit autopilotmonitor.com to request access and learn more.
Overview
Autopilot Monitor provides real-time tracking, intelligent diagnostics, and automated troubleshooting for Windows Autopilot enrollment processes. It consists of:
- Bootstrap Script — PowerShell script deployed via Intune that starts monitoring early in the enrollment process
- Monitoring Agent — Lightweight .NET application that collects telemetry and evidence during enrollment
- Backend API — Azure Functions-based ingestion and processing pipeline
- Web Dashboard — Next.js application for real-time monitoring and fleet analytics
Architecture
For detailed information about the system architecture, components, and data flow, see Architecture Documentation.
Documentation
Full admin documentation is available at docs.autopilotmonitor.com
License
This project uses a split licensing model:
- MIT License — Agent (
src/Agent/) and Shared library (src/Shared/) — unrestricted use on end-user devices - AGPL-3.0 — Backend (
src/Backend/), Web Dashboard (src/Web/), and MCP Server (src/McpServer/) — server-side components remain open source
See LICENSE for full details.