Oliver Kieselbach
821c41e2ba
* feat: tenant Hello wait timeout up to 1 hour The "Hello Wait Timeout" setting (30..300 s in the UI) had no effect in the V2 agent: its only consumer, HelloTracker.StartHelloWaitTimer, has no production caller, while the decision engine armed a fixed 300 s hello_safety deadline after the ESP exit and the tracker ran a fixed 300 s completion timer after the wizard start. The setting is now the real Hello budget, clamped to 300..3600 s (HelloWaitTimeout in AutopilotMonitor.Shared). Every value that was valid before (<= 300, including the old 30 s default) keeps today's 5 minutes. - Engine: the agent stamps helloWaitTimeoutSeconds on EnrollmentFactsObserved (only when > 300), recorded set-once in EnrollmentScenarioObservations. All six hello_safety arm sites share one builder with the tenant window; a fact that arrives after hello_safety was armed moves it out. The WDP backstop is never shorter than the tenant window; the signal census surfaces hello_wait_extended. - Agent: the Hello tracker's wizard completion timer uses the same budget; the stall probe skips session_stalled while hello_safety is pending. - Backend: ValidateModel rejects values outside 300..3600; stored rows are read as their effective value, so legacy 30 s rows never block unrelated saves or backup reverts. Default 30 -> 300; shared manifest and wire types regenerated. - Web: input 300..3600, bounds pinned against the C# constants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S17pipjWqjZ8ULAu1JrFyG * fix: keep the Hello wait's 30 s minimum and default, raise only the maximum Product decision: the setting keeps its UI contract (30 s minimum and default, same description); only the maximum moves to 3600 s. Configured values up to 300 s keep the built-in 5-minute Hello window, larger values extend it. - HelloWaitTimeout: MinSeconds/DefaultSeconds 30; BuiltInSeconds 300 is the floor of EffectiveSeconds. - Backend validates only a changed value (30..3600), like the retention cap; the read-time normalization is gone again. - The agent stamps the tenant window only above BuiltInSeconds. - Web keeps the original text and default; only the maximum and its hint change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S17pipjWqjZ8ULAu1JrFyG * fix: Hello wait default 300 s, stale-fire guard, deferred stall report Product decision: default 300 s (what V2 has always waited), minimum 30 s still accepted, maximum 3600 s. Values up to 300 s keep the built-in 5-minute window, which the settings hint now says. Review follow-ups: - Engine: a hello_safety fire whose incarnation was replaced (armed due later than the fire's due time) is dead-ended, same guard as RealmJoin — a late tenant window could otherwise be undercut by the queued fire of the built-in deadline. The tenant fact is recorded only when it extends the built-in window. - Stall probe: session_stalled is held back while a tenant-extended Hello wait (hello_safety or the WDP backstop) is pending and emitted once it is over and the session is still idle; real activity drops it. Default tenants never hit the guard. - Comments: WDP backstop wording, 5-min reference, AgentConfiguration. - Web pins the default against the shared manifest; tracker constructor defaults use HelloWaitTimeout.DefaultSeconds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S17pipjWqjZ8ULAu1JrFyG --------- Co-authored-by: Claude <noreply@anthropic.com>
Autopilot Monitor
Autopilot Monitor is an open-source, real-time monitoring and troubleshooting platform for Windows Autopilot and Microsoft Intune enrollment. It records enrollment events, application installations, policies, device state, and diagnostics while provisioning is still running, instead of collecting logs by hand after a failure. Administrators get live enrollment tracking, Enrollment Status Page (ESP) visibility, detailed session timelines, automated issue detection, on-demand diagnostics, fleet health analytics, and AI-assisted troubleshooting through a hosted Model Context Protocol (MCP) server.
The platform supports classic Windows Autopilot and modern Intune provisioning scenarios, including Windows Autopilot Device Preparation.
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.
Key Features
- Real-time Windows Autopilot monitoring — follow device provisioning while enrollment is still running
- Detailed enrollment timelines — correlate Autopilot, ESP, Intune Management Extension, apps, policies, device state, and system events
- Enrollment Status Page visibility — see which phase, application, or policy is delaying provisioning
- Automated issue detection — define custom analysis rules that identify known failure patterns
- Targeted evidence collection — gather registry values, event log entries, files, log-parser matches, and allow-listed commands when specific conditions are detected
- On-demand diagnostics — request diagnostics packages from enrolled devices remotely
- Fleet health analytics — success rates, deployment duration, device models, applications, errors, and recurring issues
- Session reporting — inspect and share detailed enrollment information for individual devices
- Windows Autopilot Device Preparation support — monitor Device Preparation deployments alongside classic Autopilot scenarios
- Centralized agent configuration — control diagnostic behavior, automatic reboots, timezone adjustment, and other monitoring settings from the web dashboard
- AI-assisted troubleshooting — query enrollment data through the built-in Model Context Protocol server
How it works
Autopilot Monitor consists of several components working together throughout Windows enrollment:
- Bootstrap Script — PowerShell script deployed through Microsoft Intune that starts monitoring early in the provisioning 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, troubleshooting, and fleet analytics
- MCP Server — Model Context Protocol server that lets AI assistants query Autopilot Monitor data in natural language
Windows Autopilot and Intune Troubleshooting
Autopilot Monitor helps investigate common Windows provisioning and enrollment problems such as:
- Windows Autopilot deployments that fail or appear stuck
- Enrollment Status Page (ESP) delays and unusually long deployment phases
- Win32 application installation failures and slow application downloads
- Intune Management Extension problems
- Microsoft Entra join, Hybrid Join, and device registration issues
- policies that block or delay provisioning
- inconsistent behavior across hardware models and recurring failures affecting multiple devices
Because telemetry is collected during enrollment, many problems can be investigated without reproducing the issue or manually collecting logs from the affected device.
AI Integration (MCP)
Autopilot Monitor ships a hosted Model Context Protocol server. Connect Claude Desktop, VS Code, or any MCP client that speaks Streamable HTTP with OAuth, and ask questions like:
- "Show me all failed enrollments from the last 24 hours and group them by failure reason."
- "Why did session X fail, and which app install caused the delay?"
- "Which devices had unusually long ESP application phases this week?"
- "Which device models have the highest Autopilot failure rate?"
- "Which devices in my fleet are affected by CVE-2024-30078?"
Server URL: https://mcp.autopilotmonitor.com/mcp — sign-in runs through your existing work account, access is scoped to your tenant exactly like in the portal, and the MCP server stores no credentials. Setup guide: AI Integration (MCP).
Documentation
Full admin documentation is available at docs.autopilotmonitor.com — deployment, configuration, monitoring, diagnostics, troubleshooting, analysis and gather rules, integrations, and AI-assisted troubleshooting.
Open Source
Autopilot Monitor is developed openly on GitHub. The source is published so that customers and security reviewers can see what runs on their devices and with their data: the repository contains the device agent, shared library, backend, web dashboard, and MCP server.
Feedback
Bug reports and feature requests go through Issues, questions and ideas through Discussions. Security issues are reported privately, see SECURITY.md. For a problem in your own tenant, the Report Session button in the portal is the fastest path.
License
This project uses a split licensing model. The root LICENSE is AGPL-3.0, which covers the server-side components; the device-side components carry their own MIT license file:
- MIT License — Agent (
src/Agent/) and Shared library (src/Shared/) — unrestricted use on end-user devices, no copyleft obligations - AGPL-3.0 — Backend (
src/Backend/), Web Dashboard (src/Web/), and MCP Server (src/McpServer/) — modifications to server-side components remain open source, especially when deployed as a network service
The Shared library is MIT because it is a dependency of the MIT-licensed Agent. The license file inside each component directory is authoritative for that component.