Troubleshooting Autopilot from inside OOBE: Shift+F10, the diagnostics page, and the policy that locks you out

A Windows Autopilot deployment that fails during the out-of-box experience (OOBE) produces the least diagnosable device in the estate. There is no desktop. There is no signed-in user. There is no Event Viewer to open, no Company Portal to check, and no local administrator account to elevate with. The device shows a grey error card and nothing else. Everything an administrator would normally reach for sits on the other side of a sign-in that is never going to happen. Getting information out of that box is a different problem from reading Autopilot logs on a working machine. It depends entirely on which doors your organisation left open before the device shipped.

The problem: a black box that cannot tell you why it failed

Most Autopilot troubleshooting guidance assumes you already have the logs. It tells you which file to open and which line to read. That guidance is useful, and this site already carries a full reference for Autopilot MDM log collection. This article is about the step before that one. It is about reaching a device that has never had a desktop.

The distinction matters because the tooling changes completely. On a provisioned device you sign in, open Event Viewer, browse to the Autopilot channel and read it. Inside OOBE you have none of that. You have a keyboard, a screen showing a Microsoft-authored error page, and whatever access routes were enabled before the device left the warehouse. If none were enabled, your only remaining option is to reset the device and hope the failure repeats. That destroys the evidence you needed.

Microsoft documents three interactive routes, plus one collection that runs without you. Each has a different gate. The gates live in three different places and are controlled by three different mechanisms. That is the real reason organisations lock themselves out. Nobody sets out to disable troubleshooting. They tighten one thing for security, leave another at its default, and discover the combination at three in the morning with a shipment of unusable laptops.

Why it happens: three routes in, three different gates

Route one: the Shift+F10 command prompt

This is the oldest route and still the most capable. Microsoft's ESP troubleshooting article states it plainly: if you are in OOBE on a non-S mode device, press Shift+F10. The Autopilot troubleshooting FAQ uses the same instruction when it explains how to reboot a device to re-download an Autopilot profile, then gives shutdown.exe /r /t 0 as the command to type.

What you get is a command prompt running in the OOBE session, before any user has signed in. That is enormously useful, and it is also the entire security problem. A prompt at that point in setup runs with system-level rights on a device that is not yet under management. Anyone with physical access to a machine sitting at OOBE can reach a privileged shell without presenting a single credential.

Organisations respond by removing the shortcut. The documented mechanism is not a Group Policy Object and not a configuration service provider (CSP). It is an empty file. Microsoft's archived Configuration Manager operating system deployment guidance states it in the reverse direction: delete C:\windows\Setup\scripts\DisableCMDRequest.TAG to enable Shift+F10 command line support in OOBE. When that file is present, the shortcut does nothing.

That folder is not arbitrary. Microsoft documents %WINDIR%\Setup\Scripts\ as the directory Windows Setup searches for SetupComplete.cmd and ErrorHandler.cmd. The tag file sits alongside them, which is why images produced by a Configuration Manager task sequence frequently already contain it. If your Autopilot image began life as task sequence output, assume the file is present until you have checked a device.

Routes two and three: one Intune setting controls both

The ESP Collect logs button and the Windows 11 Windows Autopilot diagnostics page look like two separate features. A single ESP profile setting governs both. Microsoft's wording for Turn on log collection and diagnostics page for end users makes the coupling explicit. Set to No, the collect logs button is not shown to users when an installation error occurs, and the Windows Autopilot diagnostics page is not shown on devices running Windows 11. Set to Yes, both appear.

That is the second half of the self-inflicted lockout. Plenty of organisations leave this setting at No because the words "for end users" read like a data-exposure risk. Combine that choice with the tag file and a failed device offers no prompt, no button and no diagnostics page.

The diagnostics page carries extra conditions worth knowing before you rely on it. Microsoft documents that it also requires Show app and profile configuration progress set to Yes. It is supported only on Windows 11, only in Windows Autopilot user-driven mode, and only when signing in with a work or school account. Personal Microsoft accounts are not supported. A self-deploying kiosk therefore cannot use it at all, which leaves the command prompt and the automatic upload as the only routes for that scenario.

Route four: the collection that happens without you

Intune's collect diagnostics device action has an Autopilot behaviour many teams have never used. Microsoft documents that it can be configured to automatically collect and upload Windows device logs upon a Windows Autopilot failure. When a failure occurs, logs are processed on the failed device and then automatically captured and uploaded to Intune. The documented limits are one set of logs per device per day, up to ten collections stored per device, and 28 days of retention before deletion.

This is the route that survives the Shift+F10 block, because it needs no keyboard and no user. Microsoft documents it as enabled by default. It also has a hard dependency that a tightly filtered OOBE network will break: the diagnostics upload endpoint must be reachable. The Autopilot FAQ names lgmsapeweu.blob.core.windows.net specifically, and the collect diagnostics article lists a longer set of regional blob storage endpoints by tenant geography. If your provisioning network allows only the Autopilot and enrolment endpoints, this route fails quietly. You find out when you go looking for a collection that never arrived.

How to verify: confirm your access before a device fails

Every check below can be run on a reference device today, on the bench, before you have a problem. That is the whole point. Verifying troubleshooting access after a failed deployment is too late by definition.

Check the tag file and the tool

Start with the file that decides route one. Then confirm that mdmdiagnosticstool.exe is present, because every documented in-OOBE collection command depends on it. Both checks are one line each.

The documented command lines differ by scenario. Microsoft's ESP troubleshooting article gives one for user-driven mode and a different one for self-deploying, pre-provisioning and any other scenario involving a physical device. The Collect MDM logs article gives a broader multi-area form that writes a zip file instead of a cabinet file.

Check the registry surfaces that survive a failure

Three registry locations tell you what the device knew and how far it got. All three are documented, and all three land in MDMDiagReport_RegistryDump.reg inside the collected archive. That means you can read them from a cabinet file on your own workstation, without touching the failed device again.

The absence of the user SID subkey under EnrollmentStatusTracking is a strong signal in its own right. Microsoft documents that this subkey is created in the account setup phase, and that it will not be created if the device setup phase fails. If it is missing, the failure happened before the user phase ever began.

Check the Autopilot event channel

Microsoft documents a dedicated Autopilot event channel. It is the fastest way to answer whether the device ever received a profile, which is the single most common OOBE failure class. You read it from the collected event log files on your own machine, and Microsoft advises that the machine viewing the logs should match the build the logs came from.

Check the two Intune-side gates

Now confirm what the service will offer a failing device. The ESP profile controls routes two and three.

1. Sign in to the Microsoft Intune admin center.
2. Select Devices, expand Device onboarding, then select Enrollment.
3. On the Windows tab, under Windows Autopilot, select Enrollment Status Page.
4. Open the profile that actually applies to your Autopilot devices. If several exist, remember that priority 1 is highest, and that a device-targeted profile is applied before a user-targeted one.
5. Select Properties, then select Edit next to Settings.
6. Read Show app and profile configuration progress and Turn on log collection and diagnostics page for end users. Both must be Yes for the Windows 11 diagnostics page to appear.

The tenant-wide diagnostics toggles control route four. There are two of them and they are separate.

1. Sign in to the Microsoft Intune admin center.
2. Select Tenant administration, then select Device diagnostics.
3. Confirm the control for device diagnostics on corporate-managed Windows devices is Enabled. That is the general collect diagnostics action.
4. Confirm the control for automatically capturing diagnostics on an Autopilot failure is Enabled. That is the one that rescues you when no keyboard route exists.

The fix: keep one documented route open on purpose

The fix is not "leave Shift+F10 enabled". For many organisations blocking it is a genuine and reasonable security decision. The fix is to make the decision explicit, and to guarantee that closing one route does not close all of them.

If you block the OOBE command prompt, do these three things first

1. Turn on ESP log collection. Set Turn on log collection and diagnostics page for end users to Yes on the ESP profile that actually applies. Microsoft's own guidance recommends turning this on because the user's logs and diagnostics could aid with troubleshooting. Pair it with Show app and profile configuration progress set to Yes so the Windows 11 diagnostics page works too.
2. Leave automatic Autopilot diagnostic capture enabled, and unblock its endpoint. The toggle being on is not enough on its own. Confirm the regional diagnostics blob storage endpoints for your tenant geography are reachable from the provisioning network, not only from the corporate LAN.
3. Write down how the tag file is reinstated after a reset. Community research from Rudy Ooms shows the file does not survive a Windows reset without extra work, so a reset device can end up with the prompt available again. Whichever way your organisation handles that, the behaviour should be documented rather than discovered.

The Intune and CSP route for the command prompt policy

If your intent is to stop signed-in users from opening a command prompt on the finished desktop, that is a different and fully supported control. It is a user-scoped ADMX-backed policy.

1. Create a custom profile for Windows 10 and later.
2. Add an OMA-URI setting of ./User/Vendor/MSFT/Policy/Config/ADMX_ShellCommandPromptRegEditTools/DisableCMD.
3. Set the data type to String. This is an ADMX-backed policy, so the payload must be the XML-encoded enable or disable fragment rather than a bare boolean value.
4. Assign the profile to a user group, because Microsoft documents this policy with no device scope.

The equivalent Group Policy path is User Configuration > Administrative Templates > System > Prevent access to the command prompt, from Shell-CommandPrompt-RegEditTools.admx. Microsoft documents the registry key name behind it as Software\Policies\Microsoft\Windows\System.

The image and unattend route for the OOBE prompt

There is no console path for this one, and that is the single most important thing to internalise. The OOBE command prompt is governed by whether a file exists in the image. You place it, or remove it, at image build or servicing time in %WINDIR%\Setup\Scripts\. The same folder holds SetupComplete.cmd, which Microsoft documents as running with local system permissions immediately after the user sees the desktop, and ErrorHandler.cmd, which runs automatically when Setup encounters a fatal error. Setup logs the SetupComplete.cmd action to C:\Windows\Panther\UnattendGC\Setupact.log.

That last path is worth remembering separately, because Intune's diagnostic collection gathers it. If you ever need to prove what ran at the end of Setup on a device you cannot log into, that file is inside the collected archive.

Getting logs off a device with no user session

This is the part people forget to plan. Collecting a cabinet file is only half the job on a device with no signed-in user, no mapped drive and no OneDrive.

The ESP Collect logs button covers the same need without a command prompt. Microsoft's ESP troubleshooting article states that when a time-out occurs in the ESP the user can select the option to Collect logs, and that log files can be copied to a USB drive. That is the documented off-device path for a non-technical user standing in front of a failed laptop, and it exists only if the ESP setting is Yes.

Proof it worked: what an accessible device looks like

The proof you want is boring. It is a device where every route reports open, checked before it mattered. The companion script produces exactly that summary in one read-only pass.

Read that output as three independent answers. Route one is open if the tag file is absent and the tool is present. The diagnostic surfaces block tells you the device will actually have something to report when it fails. The output locations block tells you where to look after a collection. The verdict line is the one to paste into a build sign-off checklist.

On the service side, the equivalent proof is a diagnostics collection that arrived without anyone touching the device. After an Autopilot failure on a device with automatic capture enabled, the collection appears against the device record and can be downloaded as a zip file.

If that row never appears after a genuine failure, you have found a network problem rather than an Autopilot problem. Check the diagnostics blob storage endpoints for your tenant geography before going any further.

References

Microsoft-official sources, each fetched and confirmed:

• Windows Autopilot troubleshooting FAQ covers the Shift-F10 reboot instruction, enabling and opening the Windows Autopilot diagnostics page with Ctrl+Shift+D, the Autopilot event channel and its event IDs, and the Autopilot profile registry values.
• Troubleshoot the Enrollment Status Page (ESP) covers the Shift+F10 instruction for non-S mode devices, the per-scenario mdmdiagnosticstool.exe command lines, the Collect logs behaviour and USB copy, and the FirstSync and EnrollmentStatusTracking registry keys.
• Collect MDM logs covers the multi-area -zip command, the C:\Users\Public\Documents\MDMDiagnostics output location, and the contents of the collected archive.
• Set up the Enrollment Status Page covers the exact wording and effect of Turn on log collection and diagnostics page for end users and Show app and profile configuration progress, plus ESP profile priority rules.
• Device action: Collect diagnostics covers automatic collection on Autopilot failure, the retention limits, the regional upload endpoints, and the full list of collected registry keys, commands, event channels and file paths.
• ADMX_ShellCommandPromptRegEditTools Policy CSP covers the DisableCMD OMA-URI, its User-only scope, and the Group Policy location and registry key name.
• Add a custom script to Windows Setup covers %WINDIR%\Setup\Scripts\ as the Setup scripts directory, and the C:\Windows\Panther\UnattendGC\Setupact.log logging path.
• OSD client side deep dive and troubleshooting, an archived Microsoft Learn blog, contains the explicit statement that deleting C:\windows\Setup\scripts\DisableCMDRequest.TAG enables Shift+F10 command line support in OOBE.

Community deep-dives, both fetched and confirmed on topic:

Companion script: Get-OobeTroubleshootingAccess.ps1. It is read-only, ASCII-only, runs on both Windows PowerShell 5.1 and PowerShell 7, prompts before installing any module, and aborts rather than reporting a clean result after a failed query.