Something Went Wrong OOBEIDPS: Autopilot Network Block Fix

A Windows Autopilot device runs through the first out-of-box experience (OOBE) screens and stops with Something went wrong and the code OOBEIDPS. Profile, license and hardware hash all look right in Intune, and the device still won’t get past sign-in.

Microsoft lists this exact message in Troubleshooting Windows device enrollment problems in Intune. The cause it gives is: “This issue occurs if there’s a proxy, firewall, or other network device that’s blocking access to the Identity Provider (IdP).” The solution it gives is to make sure the required access to internet-based services for Autopilot isn’t blocked.

That’s the whole Microsoft entry. Here it becomes a set of checks you can run from the failed device and changes you can hand to the network team. I haven’t reproduced OOBEIDPS on a live tenant for this article. Everything below comes from the Microsoft Learn pages linked inline, and I haven’t run the commands on a failed device.

Key takeaways

• OOBEIDPS is a network error. Microsoft’s documented cause is a proxy, firewall or other network device blocking the identity provider.
• The tenant side (profile, license, hardware hash) is the wrong place to start. Prove the network path first.
• Test the Autopilot deployment service and Microsoft Entra sign-in hosts from the device with Test-NetConnection, then read the Autopilot event log and registry.
• Configure the proxy on the proxy server. Microsoft says proxy settings through Intune policy aren’t fully supported for Autopilot.
• Keep TLS inspection off Microsoft 365 identity and Intune endpoints. Microsoft says SSL inspection isn’t supported for *.manage.microsoft.com and *.dm.microsoft.com.

Free and read-only: the Kit 1 beta scripts include an on-device diagnostic that reads the ModernDeployment Autopilot events and Autopilot registry keys after a failure. It does no network tests, so run it alongside the checks below.

Quick Fix checklist

1. Confirm the code on screen is OOBEIDPS. If it’s 80180003 or 801c0003, you have an authorization problem instead; see error 80180003.
2. Press Shift+F10 to open a command prompt, start powershell, and test the hosts in the test script on port 443.
3. Collect logs before you reset anything: mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "c:\users\public\documents\MDMDiagReport.zip".
4. Check HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot for IsAutopilotDisabled = 1 and an empty CloudAssignedTenantDomain.
5. Ask the network team to allow the hosts in the endpoint table, with no proxy authentication and no TLS inspection on them.
6. Restart the device with shutdown.exe /r /t 0 and run OOBE again on the fixed network.

What OOBEIDPS means

OOBEIDPS is the code Windows shows when OOBE can’t reach the identity provider, the service that checks the user’s work or school credentials. For a cloud Autopilot deployment that’s Microsoft Entra ID. Microsoft’s Autopilot requirements say Microsoft Entra ID “validates user credentials” and that the device is joined or registered to Microsoft Entra ID during Windows Autopilot (Windows Autopilot requirements, Networking).

OOBEIDPS isn’t an Intune enrollment error. The same page says that “once authenticated, Microsoft Entra ID triggers enrollment of the device into the Intune mobile device management (MDM) service.” If authentication never reaches Entra ID, Intune enrollment hasn’t started, and the MDM enrollment events won’t explain the failure.

Why the obvious diagnosis is wrong

“Something went wrong” is the same headline Windows uses for enrollment failures caused by tenant settings or device state, such as 8018000a (device already enrolled) and 80180026 on Microsoft’s same troubleshooting page. So the reflex is to re-import the hardware hash, reassign the deployment profile or check the user’s license. None of that is in Microsoft’s documented cause for OOBEIDPS.

The network is easy to miss for two reasons. First, the device does have internet. Autopilot’s deployment service (ztd.dds.microsoft.com) and the Entra sign-in hosts (login.microsoftonline.com and others) are different names, so a filter can allow one and block the other. Microsoft’s Autopilot event 164, “AutopilotManager determined Internet is available to attempt policy download”, only tells you general internet worked.

Second, other devices work on the same network. A laptop that’s already signed in, or a phone, isn’t going through OOBE. It may have a proxy configuration or a trusted inspection certificate that a device fresh out of the box doesn’t have. That point is my reasoning, not a Microsoft statement, and it’s why I test from the failed device itself.

My recommendation: treat the first OOBEIDPS on a site as a network change request, and only look at Intune after the host tests in the next section pass.

What the device needs to reach

Microsoft’s Autopilot networking requirements say the simplest working setup is DNS resolution for internet names plus access to all hosts on port 80 (HTTP), 443 (HTTPS) and 123 (UDP/NTP). If your network is more restrictive, these are the services from that page and the pages it links that matter up to and just after sign-in:

The ID 56 and ID 59 rows list only some of the hosts in each Microsoft 365 entry. Take the full, current list from the Microsoft page or the Microsoft 365 IP Address and URL web service rather than copying this table into a firewall, because the endpoint lists change.

If your users sign in through a federated identity provider, I’d add that provider’s sign-in hostnames to the same allow list and the same test.

Test the hosts from the failed device

On the OOBEIDPS screen, press Shift+F10 to open a command prompt (the Autopilot troubleshooting FAQ uses the same shortcut to restart a device during OOBE). Type powershell and run:

# Read-only. Tests DNS and TCP 443 to the OOBE sign-in hosts.
$targets = 'ztd.dds.microsoft.com', 'login.live.com', 'login.microsoftonline.com',
           'device.login.microsoftonline.com', 'enterpriseregistration.windows.net'
foreach ($t in $targets) {
    $r = Test-NetConnection -ComputerName $t -Port 443 -WarningAction SilentlyContinue
    '{0,-36} RemoteAddress: {1,-16} TcpTestSucceeded: {2}' -f $t, $r.RemoteAddress, $r.TcpTestSucceeded
}

I haven’t run this on a device stuck at OOBEIDPS. It uses the -ComputerName and -Port parameters of Test-NetConnection plus the common -WarningAction parameter, and reads RemoteAddress and TcpTestSucceeded, two fields shown in Microsoft’s example output.

How to read it:

• No RemoteAddress: DNS can’t resolve the name. Microsoft’s requirements say the DNS server “must be able to resolve internet names.” Fix DNS first.
• RemoteAddress but TcpTestSucceeded: False: a firewall or proxy is dropping the connection on 443.
• Every test passes but OOBEIDPS comes back: a TCP test only proves the port opens. It can’t see a proxy that demands authentication or intercepts TLS after the connection is made. Go to Proxy and TLS inspection.

For a site-wide test of the Intune side, Microsoft publishes Test-IntuneAFDConnectivity.ps1 on the Intune network endpoints page. Microsoft says to run it from an Intune-managed device, so use an already-managed device on the same network segment rather than the device at OOBE.

Read the Autopilot evidence

Collect the logs before you restart or reset the device. From the same command prompt, Microsoft’s Collect MDM logs page gives this command:

mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "c:\users\public\documents\MDMDiagReport.zip"

The zip holds the Autopilot ETL traces, an MDM registry dump and the common .evtx event logs. Copy it to a USB drive and open it on your own machine.

Then check two places Microsoft documents in the Autopilot troubleshooting FAQ:

The Autopilot event log at Application and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot. Look for:

• Event 164, “AutopilotManager determined Internet is available to attempt policy download.” This tells you general internet worked when Autopilot started.
• Event 153 with ProfileState_Unknown to ProfileState_Available, which means a profile was downloaded.
• Event 807 (ZtdDeviceIsNotRegistered) or 815 (no profile assigned and no default profile). If you see these, you have a registration or assignment problem as well, and it needs its own fix.

The Autopilot registry key:

reg query HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

Microsoft says IsAutopilotDisabled = 1 means the device isn’t registered with Windows Autopilot, and that this state “could also indicate that the Windows Autopilot profile couldn’t be downloaded because of network connectivity or firewall issues, or network timeouts.” A blank CloudAssignedTenantDomain points the same way. If the profile downloaded and the tenant values are filled in, the block is narrower: Autopilot’s own service is reachable and the sign-in hosts aren’t, which matches OOBEIDPS.

Automatic diagnostics upload on Autopilot failure needs lgmsapeweu.blob.core.windows.net to be reachable (Autopilot requirements). On a network that’s already blocking things, don’t assume the upload happened. Keep the local zip.

Proxy authentication and TLS inspection

These are the two changes I’d ask the network team about first, because a port test won’t catch either.

Proxy settings belong on the proxy server

Microsoft is direct about this in the Autopilot requirements: “Deploying proxy settings for Windows Autopilot should be configured on the proxy server itself. Implementing proxy settings via Intune policy isn’t fully supported as it might cause issues and unexpected behavior with privileged access deployments.”

The same page says extra configuration “might be required” on networks that “require authentication before internet access can be obtained.” At OOBE no user has signed in yet. My recommendation is to let the Autopilot and Microsoft Entra hosts in the table through the proxy without authentication, or to provision on a network that doesn’t need it.

Keep TLS inspection off identity and Intune traffic

The Intune network endpoints page says: “SSL traffic inspection isn’t supported for ‘*.manage.microsoft.com’, ‘*.dm.microsoft.com’, or the Device Health Attestation (DHA) endpoints listed in the compliance section.”

For the Microsoft 365 side, which includes the Entra sign-in hosts, Microsoft 365 network connectivity principles tells you to “Bypass Microsoft 365 domains from TLS decryption, traffic interception, deep packet inspection, and network packet and content filtering.”

Microsoft’s OOBEIDPS entry doesn’t name TLS inspection by itself. It does name “a proxy, firewall, or other network device”, and an inspection proxy is exactly that, so I’d exempt the hosts before chasing anything else.

Fix and retry

1. Get the network change made: allow the hosts in the endpoint table, remove proxy authentication for them, and exempt them from TLS inspection.
2. Run the test script again from the same device. Every host should resolve and show TcpTestSucceeded: True.
3. Restart with shutdown.exe /r /t 0. Microsoft’s FAQ lists this command for restarting during OOBE, and notes that a restart is how a device gets a new Autopilot profile if a blank one was cached.
4. Run OOBE again and sign in. If the device now gets past sign-in and stops at the Enrollment Status Page (ESP), that’s a separate stage. Start with the ESP timeout guide, or get the free ESP Triage Checklist: two pages of read-only checks for which ESP phase failed and which logs and registry keys to read.

Using a different network to prove the cause

Moving the device to a network with open internet access is a quick way to prove the cause. For a Microsoft Entra join profile it can also be how you finish the build. For a Microsoft Entra hybrid join profile it won’t work: Microsoft’s Autopilot requirements say “the computer should be on the internal network for Microsoft Entra hybrid join to work.” Fix the corporate network for hybrid devices.

What not to waste time on

• Re-importing the hardware hash or reassigning the profile. Microsoft’s documented cause is the network. Change tenant config only if the event log shows 807 or 815.
• Pushing proxy settings with an Intune policy. Microsoft says that isn’t fully supported for Autopilot, and the device isn’t enrolled at this point anyway.
• Resetting the device again and again on the same network. Each attempt hits the same block. Collect the logs once, fix the network, then retry.
• Testing from your own laptop. A signed-in, managed machine doesn’t take the same path as a device in OOBE.

Prevention checklist

• Keep a provisioning network or VLAN with the Autopilot, Microsoft Entra and Intune endpoints allowed, no proxy authentication and no TLS inspection on those hosts.
• Track the Microsoft 365 IP Address and URL web service through its RSS feed, or have your firewall or proxy pull its endpoint list. Microsoft says new endpoints are published there 30 days before they’re provisioned for use.
• Allow time.windows.com on UDP 123 and make sure DHCP hands out a DNS server that resolves internet names. Microsoft’s Autopilot known issues page links TPM attestation errors and ESP timeouts to a real-time clock that’s off by several minutes or more; see the real-time clock article.
• For self-deploying and pre-provisioning, add *.microsoftaik.azure.net and the firmware TPM vendor URLs from the requirements page. Otherwise the next stop is a TPM attestation error like 0x81039001.
• Run the test script on one device per new site or network change before a deployment wave.

How I put this together

• Sources: Microsoft Learn only, all retrieved 2026-10-30. Each claim links the page it came from.
• Commands: taken from Microsoft Learn syntax (mdmdiagnosticstool.exe, reg query, shutdown.exe, Test-NetConnection). I haven’t run them on a device at OOBEIDPS.
• Opinions: where I recommend an order of work or a network design, the text says so. Nothing here is a measured result from a real tenant.

For more Autopilot test-flow checks, see Autopilot part 3: testing and troubleshooting.

Get the Deployment Doctor

Kit 1 founding presale is open: $39 (regular $49). The Autopilot + Device Prep Deployment Doctor checks your tenant, read-only, for the config that breaks ESP and Device Preparation. You pay now and get the files by Tuesday, December 1, 2026, sooner if they’re ready. Full refund any time before delivery, then 14 days after delivery. The founding price runs until Friday, December 4, 11:59 PM MT.

Want to look first? The free, read-only beta scripts are on GitHub: autopilot-deployment-doctor-beta. Its README says they haven’t been run against a live tenant.

FAQ

What does OOBEIDPS mean in Windows Autopilot?

It’s the code on the “Something went wrong” screen when OOBE can’t reach the identity provider. Microsoft documents the cause as a proxy, firewall or other network device blocking access to the IdP, and the fix as unblocking the internet-based services Autopilot needs.

Is OOBEIDPS a licensing or Autopilot profile problem?

Not according to Microsoft’s troubleshooting entry, which names only the network. Check the Autopilot event log anyway: events 807 or 815 mean a registration or profile assignment problem exists as well.

Can TLS or SSL inspection cause OOBEIDPS?

Microsoft’s OOBEIDPS entry doesn’t name TLS inspection specifically, but an inspection proxy is a network device in the traffic path. Microsoft says SSL inspection isn’t supported for *.manage.microsoft.com and *.dm.microsoft.com, and recommends bypassing TLS decryption for Microsoft 365 domains.

Can I set the Autopilot proxy with an Intune policy?

Microsoft says proxy settings for Windows Autopilot should be configured on the proxy server itself, and that setting them through Intune policy isn’t fully supported. The device isn’t enrolled yet when OOBEIDPS appears, so an Intune policy can’t reach it at that point.

Will a phone hotspot fix OOBEIDPS?

It can prove the corporate network is the cause. For a Microsoft Entra hybrid join profile it won’t finish the job, because Microsoft says the computer should be on the internal network for hybrid join to work.

Sources

All retrieved 2026-10-30.

• Troubleshooting Windows device enrollment problems in Intune, Microsoft Learn: the OOBEIDPS cause and solution; the 8018000a and 80180026 entries.
• Windows Autopilot requirements, Networking, Microsoft Learn: services, hosts and ports; proxy guidance; hybrid join on the internal network; diagnostics upload URL.
• Windows Autopilot troubleshooting FAQ, Microsoft Learn: Shift+F10 and shutdown.exe; the Autopilot event log path and event IDs; the HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot values.
• Office 365 URLs and IP address ranges, Microsoft Learn: endpoint IDs 56 and 59.
• Microsoft 365 IP Address and URL web service, Microsoft Learn: the current endpoint list.
• Network endpoints for Microsoft Intune, Microsoft Learn: SSL inspection support; Test-IntuneAFDConnectivity.ps1.
• Microsoft 365 network connectivity principles, Microsoft Learn: bypass TLS decryption for Microsoft 365 domains.
• Collect MDM logs, Microsoft Learn: the mdmdiagnosticstool.exe command and zip contents.
• Test-NetConnection, Microsoft Learn: parameters and output fields.
• Windows Autopilot known issues, Microsoft Learn: real-time clock off by several minutes or more.
• reg query, Microsoft Learn: syntax.