How to Troubleshoot Windows Autopilot Enrollment Status Page (ESP) Without Losing Your Mind

The Enrollment Status Page is basically the gatekeeper for the user’s first sign-in experience. After a device is registered for Windows Autopilot and the user signs in, ESP kicks in and does a few key things:

• Device preparation
• Enrolls the device into Intune
• Handles TPM attestation
• Makes sure the device is properly joined (usually Azure AD join)

• Device setup
• Security policies (like firewall policies)
• Certain certificates
• Windows Hello for Business configuration
• Network connections (Wi-Fi / Ethernet profiles)
• PowerShell scripts and remediation scripts assigned to the device
• Required apps that must install before the user can get to the desktop

• Account setup (often skipped)

The most visible part to the user is the app tracking section: “Installing app 1 of 4” and so on. But under the hood, ESP is doing much more than just pushing apps.

In Intune, under Devices → Windows → Windows enrollment → Enrollment Status Page, you configure how ESP behaves. This is where you decide things like:

• Should the device be held until certain apps are installed?
• Which apps are considered blocking / required for ESP?
• Can the user skip ESP if something fails?

A typical configuration for a group of Autopilot devices might look like:

• Hold the device in ESP until selected apps are complete
• Track and block on specific apps such as:
• Autopilot branding package
• Company Portal
• Microsoft Teams
• Notepad++
• Azure Monitor Agent

Here’s the catch: the more apps you add, the more likely you are to hit a failure. And not all apps are equal.

You really have to ask yourself, sometimes brutally:

• Is this app critical for the user’s first sign-in?
• Would it be fine if this came down later in the background?
• Can this be installed via Company Portal instead of being a blocking ESP app?

To be honest, a lot of environments get into trouble because they treat ESP like a dumping ground for “everything we think they might need.” Instead, ESP should be reserved for apps that are:

• Security-critical (e.g., AV, endpoint protection)
• Connectivity-critical (VPN client, certificates, network agents where needed)
• Absolutely required for the user to function on day one

Things like Notepad++? Nice to have, but very rarely a good reason to block the whole enrollment for 20 minutes or more.

During device setup, ESP is primarily tracking a subset of security-related items, not the entire Intune configuration universe. Specifically, ESP tracks things like:

• Certain security policies (firewall and similar settings)
• Certificates you’re pushing to the device
• Windows Hello for Business configuration
• Network connections (Wi-Fi/Ethernet profiles assigned via Intune)
• PowerShell scripts and remediation scripts assigned to the device

But it does not track every configuration profile under Devices → Configuration profiles in Intune. That’s where people often get confused.

So if you’re staring at ESP waiting for “Security policies” or “Device setup” to complete, don’t assume it’s hung on some random custom configuration profile. It’s likely security configuration, a script, or an app.

One subtle but very important point: PowerShell scripts and remediation scripts assigned to devices run during ESP.

That means:

• If you have a script that takes a long time, ESP will wait.
• If you have a script that fails in a nasty way (reboot, break networking, etc.), ESP can get stuck or behave unpredictably.

So when you’re troubleshooting:

• Check which scripts are assigned to the device group used for Autopilot.
• Be especially careful with scripts that:
• Change networking
• Modify security products
• Uninstall or reinstall system components

In my experience, keeping device-assigned scripts to a minimum during ESP makes your life much easier. Test them thoroughly before they ever touch a production Autopilot profile.

The community version of the tool, often referred to as Get-AutopilotDiagnostics Community, is a PowerShell-based helper that you can run during ESP to see exactly what’s happening.

At a high level, the process on a Windows 11 Autopilot device looks like this:

1. Open PowerShell (Shift+F10 if you’re still in OOBE, then run `powershell`).
2. Install the script from the PowerShell Gallery, for example:
```powershell
Install-Script Get-AutopilotDiagnosticsCommunity -Force
```
3. Run the tool:
```powershell
Get-AutopilotDiagnosticsCommunity
```

Once it runs, it surfaces a ton of useful information:

• The Autopilot profile details (tenant ID, Autopilot ID, out-of-box experience settings)
• ESP configuration (e.g., whether the device is held until apps complete)
• The list of apps that ESP is tracking
• The current status of each tracked app (downloading, installing, failed, etc.)
• A timeline of key events:
• Profile downloaded
• Service connection point discovered
• MDM enrollment completed

This lets you stop guessing and start seeing:

• Which apps are done
• Which are in progress
• Which are failing

It feels surprisingly empowering compared to staring at a generic progress bar.

Out of the box, the diagnostics tool (and the underlying registry) identifies apps by their GUIDs (those long alphanumeric IDs), not by friendly names like “Microsoft Teams” or “Azure Monitor Agent.”

You have two ways to turn those GUIDs into something human-readable:

1. Manual URL swap method (works even without extra permissions):
- In Intune, go to Apps → All apps.
- Click any app to open its properties; look at the URL in your browser.
- Replace the GUID at the end of the URL with the GUID you got from the diagnostics output.
- Press Enter — you’ll be taken to the matching app in Intune.

This is a bit clunky, but it works when you’re on the fly.

2. Use the `-Online` (or sign-in) capability of the tool:
The community script supports authenticating to your tenant. When you run it online and sign in with Intune admin permissions, it can automatically:
- Query Intune
- Resolve GUIDs to friendly app names

So instead of:
- `{F7A187...}` failed

You’ll see something like:
- Azure Monitor Agent – Failed
- Microsoft Teams – Failed
- Autopilot Branding – Installed
- Company Portal – Installed (but maybe not tracked properly)

To be honest, the online mode is far nicer for day-to-day work. The manual GUID swap is handy when you’re limited or just want to double-check something.

The core telemetry for ESP’s app tracking lives under this registry path:

```text
HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\ESPTrackingInfo\Diagnostics\Sidecar
```

In that location, you’ll see multiple entries representing snapshots of ESP’s progress at different time intervals. There’s also a LastLoggedInState entry that reflects the final result after ESP finishes.

Inside those entries you’ll find:

• A list of GUIDs representing tracked apps
• A numeric value representing the status of each app

Each app’s state is tracked with a simple code (stored as an integer):

• `1` = Not installed (expected but not started yet)
• `2` = In progress (installing)
• `3` = Installed successfully (completed)
• `4` = Error (failed)

So, for example, at the start of ESP you’ll see something like:

• All tracked app GUIDs = `1` → “These need to install but haven’t started yet.”

As ESP proceeds:

• Some flip to `2` → “Currently installing.”
• Then to `3` when they’re done.
• If something goes wrong, one might end up as `4`.

The diagnostics tool is essentially just reading and parsing this information for you in a nicer way. But for deep troubleshooting, it’s good to know where it comes from.

Let’s walk through a real-world style scenario.

Imagine ESP is configured to block on these apps:

• Autopilot branding package
• Company Portal
• Microsoft Teams
• Azure Monitor Agent

You run Get-AutopilotDiagnosticsCommunity and see:

• Autopilot branding – Completed (status `3`)
• Company Portal – Completed quickly (status `3`)
• Microsoft Teams – Completed after a bit (status `3`)
• Azure Monitor Agent – Error (status `4`)

In the registry snapshot, you would see:

• All apps start at `1`
• Company Portal jumps straight to `3` because it installs fast
• Branding and Teams move from `2` to `3` over time
• Azure Monitor Agent stays stuck at `2` and then flips to `4`

In the LastLoggedInState, you’d likely see:

• “3 of 4 apps completed”
• Azure Monitor Agent = `4` (error)

Now, back in Intune, if you open the Azure Monitor Agent app and check its Device install status, you might see a pattern of failures across many devices. That’s your signal that:

• This app is unreliable in your environment, or
• There’s a configuration/packaging issue, or
• It shouldn’t be a blocking ESP app in the first place.

At that point, you have options:

• Fix the app package and redeploy
• Remove the app from the ESP tracking list (so it’s still assigned, but doesn’t block enrollment)
• Or in some cases, unassign it entirely until you know what’s going on

A key nuance: removing an app from ESP tracking doesn’t mean you’re uninstalling or unassigning it. It just means:

> “If this app is assigned, don’t hold the device at ESP waiting for it. Let it install later in the background.”

For problematic or slow apps, that’s often the more user-friendly choice.

Here’s a simple workflow you can use when an Autopilot device gets stuck on ESP:

1. Observe what the user sees
- Note where ESP is stuck: app counts, stage (device setup vs. security policies vs. apps).

2. Run Get-AutopilotDiagnosticsCommunity on the device
- Open PowerShell (Shift+F10 if still in OOBE).
- Install and run the script.
- If possible, run it in online mode and sign in so you get friendly app names.

3. Identify failing apps or components
- Look for apps marked as Failed.
- Note whether any apps are missing from the list but should be tracked.
- Confirm whether security policies, certificates, or network profiles show any issues.

4. Cross-check in Intune
- In the Intune portal, go to Devices → All devices → [that device] → Managed apps.
- Check install state for the failing app(s).
- Also look at Apps → All apps and review the deployment status across multiple devices.

5. Decide how to handle problem apps
Ask a few honest questions:

• Is this app mission-critical for first sign-in?
• Is it consistently failing across devices?
• Is there a newer or more stable way to deploy it (e.g., Win32 packaging, different detection rules)?

Based on that:

• Fix the app and test again, or
• Remove it from ESP tracking (so it doesn’t block enrollment), or
• Temporarily unassign it until you resolve the root cause.

6. Retest from a clean state
- Reset the Autopilot device and go through the process again.
- Confirm that ESP completes successfully with your revised configuration.

7. Use “Continue anyway” only for test scenarios
ESP gives you an option to continue anyway even when something fails. That can be handy during testing if you just want to get to the desktop and investigate.

But in production, it’s risky:

• The user could land on the desktop without AV, endpoint protection, or a critical line-of-business app.
• You lose your guaranteed baseline for compliance.

For testing, sure. For real users, it’s usually better to make ESP rock solid so they never even need that option.

One of the biggest mistakes with Windows Autopilot is skipping proper testing and going straight to large-scale deployment.

When you’re building or changing your Autopilot and Intune configuration:

• Always test with real hardware that matches what users will get.
• Run through the full Autopilot flow multiple times, making sure:
• ESP completes consistently
• Apps behave as expected
• Scripts and policies don’t cause delays or failures

If you change anything significant — app assignments, ESP settings, scripts, Windows Hello for Business configuration, etc. — run through the full ESP flow again on a test device.

Once you start drop-shipping Autopilot devices directly to users, your margin for error becomes tiny. When something breaks and the device is in another city (or country), troubleshooting becomes slow and painful.

Testing thoroughly while the device is sitting right in front of you, where you can:

• Run diagnostics
• Check registry entries
• Capture logs

…is infinitely easier than trying to walk an end user through it remotely.

In my experience, the organizations that invest a bit more time up front here save themselves tons of support tickets and frustrated users later.

A simple but powerful rule of thumb:

> If the user can reasonably work without it in the first 10–15 minutes, it probably doesn’t belong as a blocking ESP app.

Use ESP to guarantee:

• Device is securely enrolled in Intune
• Baseline security is in place (AV, firewall, endpoint protection)
• Necessary connectivity pieces (Wi-Fi, VPN if needed, certificates)
• Any truly core business apps that absolutely must be there before the first logon

Defer or push everything else via:

• Background installs after ESP finishes
• User-available installs through Company Portal

This keeps ESP:

• Faster
• More reliable
• Much easier to troubleshoot, because there are fewer moving parts

Honestly, that simplicity is half the battle.

It’s tempting to throw in:

• Advanced scripts
• Complex network agents
• Heavy monitoring tools (like Azure Monitor Agent)
• Aggressive configuration changes

Some of those are absolutely valid. But you should:

• Test them thoroughly in isolation
• Watch how they behave during ESP specifically
• Confirm they don’t significantly slow down or break the first sign-in

If a particular tool — say Azure Monitor Agent — keeps failing during ESP, you have to ask:

• Does it truly need to be installed before the user ever sees the desktop?
• Or can it come down five minutes later in the background with no real downside?

If it’s the latter, don’t let it hold ESP hostage. Move it out of the blocking app list and let users get to work sooner.