wifi_signal_info was missing on most Windows 11 24H2+ WiFi enrollments (build 22631 3/3, 26100 37/178, 26200 43/95 over n=276 sessions since 08-01). Not a parser or language problem: every event that exists carries a full SSID, so the failure is binary at the reader level. Since 24H2 Windows gates WlanQueryInterface with wlan_intf_opcode_current_connection — the only opcode we use — behind precise-location consent and returns ERROR_ACCESS_DENIED. The consent prompt only fires for a process in the user's context outside System32, so the agent (SYSTEM, session 0, before the OOBE privacy page) is denied silently, and it resolves consent from the HKLM ConsentStore because the S-1-5-18 hive has none — while the interactive user on the same machine reads the SSID fine via the per-user NonPackaged value. That is why it tracks the image's location setting, not hardware, driver or language. netsh wlan hangs off the same gate, so the 2026-07 netsh fallback and its multi-language labels never covered the case they were built for; more labels cannot fix it. - New WinRtWifiSsidReader: Microsoft's documented replacement WlanConnectionProfileDetails.GetConnectedSsid (ungated, SSID only), bound via the CLR WinRT projection — no winmd, no NuGet, no csproj change — the same mechanism OobeStateReader already uses from the SYSTEM context. - New WifiInfoProvider owns the tier order (native -> WinRT -> netsh) that both collectors had duplicated. - The step diagnostics added in 2026-07 were logged at Debug while the default level is Info, so they never reached a field log. The all-tiers-failed case is now a Warning that decodes rc=5 into the location-gate explanation. Signal, PHY and channel have no ungated source and stay null on tier 2; deriving a percentage from GetSignalBars would fabricate precision. Verified: build 0 warnings, agent suite 2542/2542, interop struct sizes measured live (532/604), and the full WinRT chain resolves and returns the SSID under net48. Co-Authored-By: Claude Opus 5 (1M context) <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.
Availability
Autopilot Monitor is publicly available — the Community plan is free. Sign in with your work account at autopilotmonitor.com; new organizations complete a short activation step after first sign-in.
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.



