The moment is frustratingly familiar: you've just unboxed a brand-new Windows laptop, powered it on for the first time, and instead of the colorful welcome screen, you're staring at a generic "Something went wrong" message with a cryptic code—OOBEAADV10. Before you start drafting a return label, let me reassure you: your PC isn't broken. This error code has nothing to do with faulty hardware. It's almost always a fixable communication problem between your device and Microsoft's authentication servers.
In this guide, I'll walk you through exactly what triggers this error during the Windows Out-of-Box Experience (OOBE), why it's more common than you'd think on both Windows 10 and Windows 11, and—most importantly—six methods to resolve it, from the embarrassingly simple to the IT-admin-level deep dive. After fifteen years of troubleshooting Windows deployments, I've seen this one leave experienced technicians scratching their heads. It doesn't have to.
What Is the OOBEAADV10 Error?
OOBEAADV10 is a Windows setup error that appears during the Out-of-Box Experience phase when the Azure Active Directory sign-in page fails to load. It surfaces as a full-screen prompt that reads:
"Something went wrong. You can try again, or skip for now."
But the dialog gives you no clue about what actually broke. Let's decode it.
Breaking Down the OOBEAADV10 Error Code
The code isn't random—each segment maps to a specific technical milestone:
- OOBE: Stands for Out-of-Box Experience, the first-boot setup phase where Windows asks for your Microsoft account, Wi-Fi credentials, and privacy preferences.
- AAD: Refers to Azure Active Directory—now rebranded as Microsoft Entra ID—the identity service that authenticates work and school accounts during enrollment.
- V10: A version and failure marker, indicating the error occurred while the setup process was attempting to load the AAD sign-in screen itself.
In practical terms, Windows couldn't fetch the authentication interface from Microsoft's cloud servers. The setup's Cloud Experience Host component is essentially an embedded browser that renders remote pages—and when those remote requests fail, you get the generic error screen with this specific code in the second line.
The tricky part? Nothing is actually wrong with your PC. What failed was a network conversation between it and Microsoft.
4 Common Causes of OOBEAADV10 on Windows 11/10
Over the years, I've traced this error back to a handful of distinct causes. The most important distinction I can share from experience: in many cases, the flaw isn't in your local device. It's a service-side or infrastructure problem. That's counterintuitive for most users, because the error appears to be about your machine.
Root Cause Map: From Symptom to Source
| Cause | Typical Symptom | Who Is Affected | How to Confirm | Quick Fix |
|---|---|---|---|---|
| Network/Firewall/Proxy blocks Microsoft endpoint | Persistent OOBEAADV10, works on mobile hotspot | All users on restrictive network | WebErrorStatus 502 in Shell-Core log | Bypass proxy or use alternative network |
| System time out of sync | Error appears even after repeated tries | Individual devices | Check clock—may be hours/days ahead or behind | Sync time via w32tm /resync |
| Microsoft server overload/outage | Error occurs during known incident windows | Many devices simultaneously | Check Microsoft 365 Service Health dashboard | Wait and retry, or follow outage guidance |
| Misconfigured MDM User Scope | Error right after Autopilot login | Enterprise devices in Intune | Review Intune tenant settings | Set MDM user scope to "All" |
| Let me elaborate on the last row from that table, because it's one I've encountered repeatedly in enterprise environments. If your Intune MDM User Scope is set to "Some" but the Autopilot profile targets all users, the enrollment request gets rejected mid-flow. That triggers OOBEAADV10 even when your network, endpoints, and time settings are perfect. |
Why It Happens at the Windows OOBE Stage
During OOBE, the setup wizard isn't just checking boxes on your local disk. It's actively fetching JavaScript files, HTML5 pages, and authentication content from Microsoft endpoints. The two main servers involved are:
login.microsoftonline.com— delivers the main AAD sign-in pageacctcdn.msauth.net(previouslyaadcdn.msauth.net) — hosts the JavaScript that powers the login interface
When any of these requests return an HTTP 502 (Bad Gateway) error, the sign-in window can't render. The UI falls back to the generic "Something went wrong" screen, and OOBEAADV10 is born.
The scenario plays out in three common situations:
- Joining a device to Azure AD during initial setup
- Deploying via Windows Autopilot when the enrollment profile is improperly configured
- Signing in with a Microsoft account on a newly reset machine
A quick word about OS differences: the underlying error logic is nearly identical across Windows 10 and Windows 11, but Windows 11 24H2 introduced a few additional cloud-dependent steps in the setup sequence. In my experience, this makes the 24H2 rollout slightly more sensitive to network interruptions—but the fixes below work for both OS versions.
Fix OOBEAADV10: Step-by-Step Solutions
I've organized these fixes in the order you should try them—from least invasive to most technical. The good news is that about 80% of the time, you'll be done after Fix 1.
Fix 1: Retry Azure AD Sign-In
Yes, it sounds too simple. But hear me out.
In March 2022, when Microsoft's Intune service experienced a significant incident, devices across the globe were hitting this exact error. The root cause was server-side overload, not user error. If you're unlucky enough to be enrolling during a service incident, the first strategy is persistence.
Click Try Again five to eight times in a row. If Microsoft's authentication services are overwhelmed, each attempt is like a new car merging onto a congested freeway—eventually, one gets through. I've watched users click through ten times and succeed on the final try. It's not elegant engineering, but it's effective.
If the error persists through multiple attempts, proceed to Fix 2.
Fix 2: Check Local Network / Disable Proxy
This is the most common culprit I encounter when working with devices on corporate networks, and it's also the easiest to test.
Start by disconnecting your current Wi-Fi or Ethernet connection. Reboot the device and, at the network selection screen, connect to a completely different network—the simplest option is your phone's mobile hotspot. If the setup proceeds normally on the alternative connection, you've identified your original network as the blocker.
The usual offenders are:
- Corporate proxy servers that haven't been configured to allow Microsoft's authentication endpoints
- Router-level firewalls with overly aggressive web filtering enabled
- VPN software that intercepts traffic before it reaches the internet
To test whether the proxy is the problem: navigate to Settings > Network and Internet > Proxy on a fully installed Windows system and disable the proxy temporarily. On the OOBE screen itself, you can try Shift+F10 to open Command Prompt and then check connectivity with:
ping login.microsoftonline.com
No response or timeout messages indicate the endpoint is blocked or unreachable.
Fix 3: Sync System Date and Time
This one catches people off guard, and I'll admit it took me a few deployment cycles to fully appreciate how often it happens.
Your PC uses TLS certificates to establish encrypted connections with Microsoft's servers. Those certificates have an expiration window tied to the current date and time. If your system clock is off by even a few hours—which happens more frequently than you'd think on newly shipped hardware with drained CMOS batteries—the certificate validation fails, and the authentication page never loads.
From the OOBE screen:
- Press Shift+F10 to open Command Prompt
- Type
w32tm /resyncand press Enter - Restart the setup process
Alternatively, if you can reach the Windows clock settings via the taskbar, toggle Set time automatically off and on again. This forces an NTP resync and aligns your system time with Microsoft's servers.
Fix 4: Bypass OOBEAADV10 with Local Account
This is a workaround, not a true fix. Use it only if you need immediate access to the desktop and can defer the Azure AD join until later. I want to be transparent about the trade-offs: devices that require Entra ID join or Autopilot fully managed enrollment aren't supported in this configuration.
That said, here's how to recover a device from the error screen:
Option A: Domain Join Deception On the "Something went wrong" page, look for a back arrow or an alternative option. Some builds allow you to navigate to the previous screen and select "Domain join instead." Choosing this option bypasses the Azure AD sign-in flow and takes you to a screen where you can create a local account.
Option B: Audit Mode If the domain join option isn't available, press Ctrl+Shift+F3 to enter audit mode. Windows will reboot and log you in as a built-in administrator. From here, you can create a local user account:
- Right-click Start > Computer Management > Local Users and Groups
- Create a new user and add them to the Administrators group
- Reboot and sign in with that local account
Option C: Command Prompt User Creation From the OOBE screen, press Shift+F10 and type:
net user tempuser tempPassword123 /add
Sign in with that account. Once you're on the desktop, you can run shutdown /o /r to access the recovery options. Navigate to Troubleshoot > Reset this PC to initiate a fresh OOBE attempt—this time, hopefully, with the underlying network issue resolved.
Fix 5: Restart the OOBE Process from Command Prompt
There's a well-known command that temporarily lets you bypass the network requirement during setup:
oobe\bypassnro
Press Shift+F10 to open Command Prompt, type the command, and press Enter. Your device will reboot, and the OOBE will restart with a "I don't have internet" option visible on the network screen. This lets you complete setup with a local account and configure network connectivity afterward.
A word of caution for Windows 11 users: Microsoft has signaled that this command may be removed in the 24H2/25H2 feature updates. It still works in most released builds at the time of this writing, but it's not guaranteed forever. Use it as a last resort, not a primary strategy.
Fix 6: Run the Windows Diagnostics & Health Repair
If you're already on the desktop—perhaps via one of the local account workarounds above—or if you can boot an already-provisioned system, these tools can resolve underlying issues that contributed to the error.
Windows Troubleshooters
Navigate to Settings > System > Troubleshoot > Other troubleshooters and run two tools:
- Internet Connections — validates that your system can reach the internet properly
- Windows Update — repairs the update service, which shares infrastructure with authentication
System File Integrity
Open an elevated Command Prompt and run these commands in sequence:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
The first command repairs the Windows system image, and the second checks for corrupted system files. Both will take several minutes to complete, so run them when you have time to step away.
Connectivity Validation via PowerShell
To confirm your system can reach Microsoft's authentication endpoint:
Test-NetConnection login.microsoftonline.com -Port 443
If the test returns TcpTestSucceeded : True, your network path is clear—and the problem likely sits elsewhere (either at the server level or in your time configuration).
How to Fix OOBEAADV10 for IT Admins in Intune / Autopilot Environment
The fixes above work for individual users. But if you're an IT administrator seeing this error fleet-wide, you need a more systematic approach. Enterprise environments add layers of complexity: proxy configurations, firewall rules, MDM scopes, and conditional access policies can all trigger OOBEAADV10 in ways that aren't obvious from the user interface alone.
Enterprise Whitelist: Microsoft Endpoints That Must Be Reachable
Here's the list I share with every client migrating to Intune-based enrollment. Save this table and provide it to your network team before the first Autopilot pilot.
| Hostname | Port | Purpose |
|---|---|---|
login.microsoftonline.com | 443 | Main AAD sign-in page |
login.live.com | 443 | Microsoft account authentication |
acctcdn.msauth.net | 443 | Sign-in page JavaScript |
portal.manage.microsoft.com | 443 | Terms of Use page and device management |
The last entry deserves special attention. In several documented cases—including incidents covered on prominent Windows deployment blogs—the OOBEAADV10 error was triggered not by the authentication servers but by the Terms of Use page hosted at portal.manage.microsoft.com. When that page returned a 502 error, the error message pointed to the authentication flow, but the actual failure was the ToU content fetch. In an enterprise setup, ensure this endpoint is also accessible. |
For the most current and authoritative list, refer to Microsoft's official documentation on Microsoft 365 URLs and IP address ranges—it's updated monthly and accounts for regional variations.
Diagnostics: Reading Logs for OOBEAADV10
When you're troubleshooting fleet-wide, you need to capture forensic data before attempting fixes. These three methods will pinpoint the exact failure point.
Event Viewer
Navigate to Event Viewer > Applications and Services Logs > Microsoft > Windows > Shell-Core > Operational. Look for "Navigation Failed" entries. The relevant logs include the full URL that Windows was attempting to access. If a URL appears with WebErrorStatus 502, that's your smoking gun. The 502 status means a server acting as a gateway received an invalid response from an upstream server—essentially, the traffic reached Microsoft's infrastructure but the backend couldn't fulfill the request.
Fiddler or Browser Dev Tools
For a granular trace of the network requests, use Fiddler with HTTPS decryption enabled. Reproduce the error on the OOBE screen, then stop the trace and examine the requests sorted by result. You'll typically see a pattern of failed requests to acctcdn.msauth.net or login.microsoftonline.com returning HTTP 502.
PowerShell Test Connections
From any domain-joined machine, validate that your network permits access to the required endpoints:
Test-NetConnection login.microsoftonline.com -Port 443
Test-NetConnection acctcdn.msauth.net -Port 443
MDM User Scope Check
Finally, review your Intune tenant configuration: navigate to Intune > Tenant administration > MDM user scope. If it's set to "Some" rather than "All," and your Autopilot profile targets all users, you'll see OOBEAADV10 errors directly after the Autopilot login flow. Set the user scope to "All" to resolve it.
OOBEAADV10 vs Other Windows Setup Errors: 80192ee7, 502, and 0x8004005
If you're managing Windows deployments, you've likely noticed that setup errors rarely come alone. OOBEAADV10 often appears alongside companion codes. Understanding the relationship between them is the key to resolving multi-error scenarios quickly.
Related Error Codes Table
| Error Code | Platform | Likely Cause | First Step to Take |
|---|---|---|---|
| OOBEAADV10 | Windows 10/11 setup | AAD sign-in page failed to load | Retry or switch network |
| 80192ee7 | Windows 10/11 setup | Often paired with OOBEAADV10; endpoint unreachable | Verify endpoint whitelist |
| HTTP 502 | Backend service | Server overload or gateway issue | Wait and retry; check Service Health |
| 0x8004005 | Windows 10/11, Intune | MDM user scope misconfiguration | Review Intune tenant settings |
| In practice, when a 502 appears in the Shell-Core operational log, the UI typically displays OOBEAADV10 because the JavaScript content on the sign-in page failed to load. The visible error code and the underlying HTTP error aren't really separate problems—they're two different representations of the same root cause. |
The 0x8004005 code is the exception. When I've seen this paired with OOBEAADV10, the MDM User Scope setting was the culprit. Resolving the MDM scope issue clears both codes simultaneously, which reinforces the importance of diagnosing the root cause before applying fixes.
Frequently Asked Questions
What is the OOBEAADV10 error?
OOBEAADV10 is a Windows setup error that appears during the Out-of-Box Experience (OOBE) when the Azure Active Directory sign-in page fails to load. It usually shows the message "Something went wrong" and is caused by network issues, time sync problems, or Microsoft server overload.
How do I bypass OOBEAADV10 and finish Windows setup?
Two methods are most common: 1) restart the OOBE with the oobe\bypassnro command to temporarily skip network requirements, or 2) disconnect from the internet, create a local account, complete setup, and reconnect later. Be aware that bypassing changes the final enrollment state—the device won't be fully Entra ID-joined until you complete that step later.
Can I still fix OOBEAADV10 if I lost access to the setup screen?
Yes. Force shutdown three times to boot into Windows Recovery Environment. From there, navigate to Troubleshoot > Advanced options > Startup Settings, or use Command Prompt to create a local user account. Once on the desktop, you can re-initiate the Entra ID join from Settings > Accounts > Access work or school.
Is the OOBEAADV10 error caused by my network or by Microsoft?
It can be either. Here's a quick self-test: switch to a different network—a mobile hotspot works perfectly. If the error resolves, your original network's proxy, firewall, or DNS configuration is blocking Microsoft's authentication endpoints. If the error persists on the hotspot, open the Microsoft Service Health dashboard and check for active incidents related to Azure AD or Intune.
The Bottom Line
OOBEAADV10 is one of the most frustrating Windows setup errors—not because it's technically complex, but because the generic error message leaves users without direction. Now that you know it's an authentication loading failure tied to Cloud Experience Host, you can approach it methodically.
The fastest path to resolution is always: retry, switch networks, sync time, then escalate to the more advanced fixes. For IT administrators, the playbook is simpler: verify endpoint whitelists, inspect Shell-Core event logs, and review MDM user scopes before you even think about opening a support ticket.
If this guide helped you recover a device or unblock a fleet-wide enrollment, pass it along to your IT team. And if you're still staring at OOBEAADV10 after everything above, drop a comment describing your scenario—there's a good chance it's a new variant we can add to the collective troubleshooting handbook. Microsoft's authentication ecosystem keeps evolving, and every edge case documented makes the next deployment smoother for all of us.