> For the complete documentation index, see [llms.txt](https://docs.autopilotmonitor.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autopilotmonitor.com/troubleshooting-and-support/faq.md). # FAQ Frequently asked questions about setup, the agent, the portal, and data handling. ## General
What is Autopilot Monitor? Autopilot Monitor gives IT admins real-time visibility into Windows Autopilot enrollments. A lightweight, temporary agent runs on devices during enrollment and streams events to a web portal where you can watch progress live, diagnose failures with automated rule analysis, and review historical sessions. See [How Autopilot Monitor Works](/getting-started/how-it-works.md).
Which Autopilot scenarios are supported? **User-Driven** and **Pre-Provisioned** (White Glove) Windows Autopilot flows are fully supported — for **Entra joined** and **Hybrid joined** devices alike — as are self-deploying/kiosk profiles. **Autopilot Device Preparation** is supported — including [device association](/getting-started/autopilot-device-preparation.md#device-association) as a validation method — and uses its own agent delivery channel — see [Autopilot Device Preparation](/getting-started/autopilot-device-preparation.md). **Windows 365 Cloud PCs** are supported as an opt-in per tenant — see the next question. The full overview: [supported enrollment scenarios](/getting-started/how-it-works.md#supported-enrollment-scenarios).
Does Autopilot Monitor support Windows 365 Cloud PCs? Yes, as an opt-in per tenant. Cloud PCs are provisioned headless and are never Autopilot-registered, so they need their own validation method and a small deployment addition: enable **Windows 365 Cloud PC Validation** in Settings (requires the optional `CloudPC.Read.All` add-on permission) and assign the bootstrapper script to a group that includes your Cloud PCs. Monitoring then covers the first-connect enrollment (Account Setup) of the assigned user. The full setup is on [Windows 365 Cloud PCs](/getting-started/windows-365-cloud-pcs.md).
Is Autopilot Monitor free? Yes — the **Community plan is free and stays free**, and it is publicly available: sign in with your work account and your tenant is activated after a short activation step (see [Requirements & Access](/getting-started/requirements-and-access.md)). A commercial **Pro plan** is coming later for organizations that need more — see [Plans](/plans.md).
Where is my data stored? **In Germany.** All customer data and all compute that touches it run in Azure **Germany West Central**: Azure Functions, Table Storage, Blob Storage, queues, SignalR, the MCP container app, and Application Insights / Log Analytics. Your data is not replicated to another region. One component sits outside that region — the Static Web App in West Europe that serves the portal front-end. It delivers the HTML, JavaScript, and images that make up the portal and **stores no customer data**; every request for actual data goes from your browser to the API in Germany West Central. Data retention is [configurable per tenant](/reference/settings.md#data-management) (default 90 days), and a tenant can [offboard](/reference/settings.md#danger-zone) — irreversibly deleting all its data — at any time. Diagnostics packages can be kept entirely in **your own** Azure Blob Storage. For the full data-residency answer, see [Trust & Security](/trust-and-security/security-faq.md).
## Setup & Agent
Why are there two "Autopilot Monitor" applications in my Entra tenant? Autopilot Monitor is moving to a new multi-tenant app registration. The application with ID `886ab5e2-6144-442c-80cc-9b28e0667731` is the new one; `1a400946-62c1-4ab4-aa37-f730ac89704d` is the previous registration your tenant consented to at onboarding. Migrating is a one-time admin consent under **Settings → Autopilot Validation**, and after migrating the previous application can be deleted from your tenant. See [App Registration Migration](/troubleshooting-and-support/app-registration-migration.md).
How do I deploy the agent? Via an Intune platform script — the [Deploy the Agent](/getting-started/deploy-the-agent.md) guide covers it step by step, including the safety guards and a dry-run tester. For **Autopilot Device Preparation** enrollments the recommended channel is a small MSI line-of-business app. It installs before Microsoft 365 Apps, while the platform script only runs after them — see [Autopilot Device Preparation](/getting-started/autopilot-device-preparation.md).
Do I need to update the bootstrap script in Intune? Yes — check it from time to time. The agent itself always stays current (the script downloads the latest release fresh on every device), but the bootstrap script is a static copy frozen at the moment you uploaded it to Intune — and the script keeps evolving: new install guards, exemptions for new Windows capabilities, and endpoint changes ship regularly. An outdated copy still fails soft and never breaks an enrollment, but it can **silently skip devices that a current version would monitor**. Example: **Windows Backup for Organizations** restores a user profile during OOBE — older script versions read that profile as "device already in productive use" and skip the install, so the enrollment never shows up in the portal. To check: compare the current version badge on [Deploy the Agent](/getting-started/deploy-the-agent.md#1-download-the-bootstrapper-script) with your Intune copy (the version is in the script header, and every run logs `Bootstrap script version`). Updates worth acting on are flagged **action recommended** in the [Platform Changelog](/changelog/platform-changelog.md). Updating takes under a minute: upload the new `.ps1` over your existing platform script in Intune.
Does the agent run permanently on the device? No. The agent only exists during the enrollment window: it self-destructs after completion, stops after 6 hours of active time, and — as a backstop — removes itself at its next start once an enrollment phase is older than 48 hours. It never runs as a persistent background service. See [Agent Lifecycle & Security](/concepts/agent-lifecycle-and-security.md).
What data does the agent collect? Enrollment telemetry only: ESP phases, app and script installations, IME log entries, device information, performance snapshots, and security posture. It does **not** collect personal user data, user files, or browsing history. Optional collectors (geo location, software inventory, diagnostics package) are controlled by your tenant settings. See [the full list](/concepts/agent-lifecycle-and-security.md#what-data-is-collected).
How does the agent authenticate? With the device's **MDM client certificate** issued by Intune, over TLS. The backend additionally validates each device against your Intune tenant (Autopilot registration, device association, corporate identifiers, or Cloud PC inventory) before accepting any data — only devices under your management can send telemetry. See [Authentication](/concepts/agent-lifecycle-and-security.md#authentication).
## Portal & Features
What are Gather Rules and Analyze Rules? **Gather Rules** collect custom evidence from devices during enrollment (registry, WMI, files, allow-listed commands). **Analyze Rules** automatically evaluate every session and surface findings with explanations and remediation steps. They work best together — see [How Rules Work Together](/rules/overview.md).
Can an AI build custom rules for me? Yes — with [AI Integration (MCP)](/integrations/ai-integration-mcp.md) connected, your assistant has the complete rule schemas and allowlists, can validate a draft, and can **dry-run an analyze rule against a real session from your tenant** before anything goes live. See [AI-Assisted Rule Authoring](/rules/ai-assisted-rule-authoring.md).
Can I export or download diagnostics data? Yes — when the [Diagnostics Package](/troubleshooting-and-support/diagnostics-and-log-collection.md) feature is enabled, each session detail view offers a download of the collected log bundle. Session reports and timeline exports are available from the session's **Report** action.
Can I follow a Windows Autopilot enrollment live? Yes. Every enrolling device appears on the [dashboard](/portal-guide/dashboard-and-sessions.md) as it starts, and its [session](/portal-guide/session-details-and-diagnosis.md) shows ESP phases, app downloads and installs, reboots, errors, and performance snapshots as they happen — no refreshing, no touching the device.
Why did an enrollment fail, and how do I find out without the device? Open the session: [analyze rules](/rules/analyze-rules.md) have already flagged app install error codes, detection-rule failures that break the ESP, blocking-app timeouts, download and proxy failures, TPM attestation and MDM enrollment error codes, hybrid join problems, failed Windows updates, and low disk space or battery (full list: [built-in rules](/rules/analyze-rules/built-in-rules.md)). [Guided diagnosis](/portal-guide/session-details-and-diagnosis.md#guided-diagnosis) names the primary suspect with a copyable quick fix; [diagnostics collection](/troubleshooting-and-support/diagnostics-and-log-collection.md) brings the agent and IME logs to you.
Are failed enrollments analyzed automatically? Yes. Dozens of built-in, community-maintained rules evaluate every session automatically and report confidence-scored findings with remediation steps. You can adapt [template rules](/rules/analyze-rules/template-rules.md), [write your own](/rules/analyze-rules/cookbook.md), and add [IME log patterns](/rules/ime-log-patterns.md); [regression detection](/rules/analyze-rules.md#regression-detection) tells you when a rule starts firing more often than usual.
How do I get alerted when an enrollment fails? Configure [notifications](/integrations/notifications.md) for Microsoft Teams, Slack, Discord, or a generic JSON webhook and pick the triggers: start, success, or failure. The same channel carries SLA breach and resolution alerts, consecutive-failure alerts, and hardware rejection notices.
Is there reporting on success rate, enrollment duration, and failing apps? Yes. [Fleet Health](/portal-guide/fleet-health.md) shows the success rate, average enrollment time, a daily timeline, top failure reasons, the slowest and most-failing models and apps, and a first-time-right rate. [SLA Compliance](/portal-guide/sla-compliance.md) reports against your own targets; [Geographic Performance](/portal-guide/geographic-performance.md) compares sites.
Why does enrollment take so long, and which app is slowing it down? Every finished session gets a [time attribution](/portal-guide/session-details-and-diagnosis.md#time-attribution) bar that shows where the minutes went and which apps blocked the ESP. [Fleet Health](/portal-guide/fleet-health.md#time-attribution) aggregates the same data per enrollment class and ranks the apps that cost the most time.
Can end users or field technicians check a device's status without portal access? Yes. The [Progress Portal](/portal-guide/progress-portal.md) shows a device's enrollment status by serial number — status, progress bar, steps, and what is currently downloading or installing — live and strictly read-only. No portal role is needed; the serial number is the access key.
## Troubleshooting
The agent is deployed but I don't see any sessions. Work through the checklist in [Common Problems → No sessions appear](/troubleshooting-and-support/common-problems.md#no-sessions-appear-in-the-portal).
A session shows "In Progress" but the enrollment already finished. The completion signal was missed — for example the device rebooted before the agent could detect the final state. The session resolves automatically: after the configured session timeout (default 5 hours) the backend reclassifies it from its evidence to **Awaiting User** or **Incomplete** (a timeout is no longer treated as a failure), and reconciles it to **Succeeded** if a genuine completion later arrives. You can also mark it succeeded/failed manually via [Admin Mode](/concepts/roles-and-permissions.md#admin-mode). See [Sessions & Statuses → Timeouts](/concepts/sessions-and-statuses.md#timeouts-what-happens-to-stuck-sessions).
Where are the agent's own log files? `%ProgramData%\AutopilotMonitor\Logs` on the device — startup, event collection, and backend communication are all logged there. Log verbosity is a [tenant setting](/reference/settings.md#agent-parameters). Note the logs are removed by self-destruct unless **Keep Log File** is enabled.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.autopilotmonitor.com/troubleshooting-and-support/faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.