This blog will be about a strange Autopilot failure we could reproduce again and again. Right after the Terms of Use was accepted, the device doesn’t join Entra ID but instead stops with an “unexpected page” error during OOBE.
You’ve Reached an Unexpected Page.
We were contacted by someone on Reddit with a strange Autopilot issue. During OOBE, the device failed immediately after the Terms of Use were accepted, showing an error screen I had never seen before. As shown below, it was mentioned that: Something Went Wrong and You’ve Reached an Unexpected Page.
The funny thing? There is no way of closing the app or browser…
Because this happened at the OOBE stage, we asked for logs, to be precise, the Shell-Core Operational log that records every page CloudExperienceHost shows. Those logs revealed exactly where the flow broke.
OOBE and CloudExperienceHost
One thing is for sure: the weird, unexpected page error shows up during OOBE (Out of Box Experience). The OOBE is more than just a couple of setup screens. Behind the scenes and under the hood, Windows loads the CloudExperienceHost WebApp component.
CloudExperienceHost is responsible for showing all of the interactive pages during OOBE: the account sign-in dialog, MFA setup or challenge if required, the Terms of Use page, and the Autopilot join steps. It also recently gained the ability to show the new Install Windows Updates page, where quality updates can be applied during Windows Autopilot Provisioning.
Every page transition and token exchange handled by CloudDomainJoin is logged by CloudExperienceHost into the Shell-Core Operational log. That is why the root cause will show up so clearly there. By following the sequence of CDJUI… events, you can connect what the user saw on screen, the JavaScript flow, and the point where it fails.
The Expected Flow
Before diving in, let’s examine what needs to happen when a device is getting enrolled with Autopilot and starts showing you the OOBE pages. When CloudDomainJoin drives Autopilot enrollment, the intended steps are:
- A[DRS Auth Code Request] –> B[DRS Redeem: IdToken + Drs Tokens]
- B –> C[MDM Auth Code Request]
- C –> D[MDM Redeem: Access Token]
- D –> E{Terms of Use Required?}
- E — No –> F[doAzureADJoin()]
- E — Yes –> G[TOU Prompt Shown]
- G –> H[User Accepts TOU]
- H –> I[Return with IsAccepted + OpaqueBlob]
- I –> J[Store Artifact]
Investigating the Unexpected Page Failure
Knowing the flow and that CloudExperienceHost drives the OOBE pages, the first step was to look at the Shell-Core Operational log. Every navigation during enrollment is logged there, so it was the perfect place to trace what happened after clicking Accept on the Terms of Use page.
The logs showed:
- CDJUINavigateToTermsOfUseBlackBox → the Terms of Use flow was triggered
- Navigation to portal.manage.microsoft.com/TermsOfUse.aspx → the page appeared as expected
- But after acceptance → NavigationSucceed {uri:”…/common/wrongplace”}
At this point, there should have been a CDJUIReturnControlAfterTermsOfUseBlackBox event confirming an OpaqueBlob was returned. That event never appeared. Without the artifact, the CloudDomainJoin script had no reason to continue with doAzureADJoin().
On screen, this matched exactly what the user saw: The generic “Something went wrong and You’ve Reached an Unexpected Page” error shown right after Terms of Use is accepted.
How to Reproduce the Unexpected Page.
Luckily, we could easily reproduce this behavior with Autopilot, Device Preparation, and Pre-provisioning by enabling Terms of Use in Intune. Yes… just by enabling or changing the existing Terms of Use in Intune.
- The moment a new version of the Terms of Use was applied, the next enrollment would break.
- After a wipe and retry, the device enrolled fine again, because the user only needs to accept the Terms of Use once per version. So if the ToU changed and the user needs to reenroll the device, that error would show up!
Root Cause
The failure is not caused by Conditional Access policy or tenant mismatches. The issue sits in the CloudDomainJoin package, which is a JavaScript that Windows Autopilot downloads during OOBE and stores under the defaultuser0 profile’s local app data.
This package is not baked into the OS. Microsoft can update it on the fly without shipping a Windows update. If the Terms of Use redirect handling is broken in the current package, every enrollment that encounters a new Terms of Use version will fail in the same way.
That also explains why we could reproduce this so easily. With Autopilot, Device Preparation, or Pre-provisioning (even Windows 10!!). All of them showed the Something went wrong: You’ve reached an unexpected page error.
Enabling a Terms of Use in Intune and forcing a new version made the next enrollment break. After wiping and retrying, the device worked again, because the user only needs to accept each Terms of Use version once.
Inside the CloudDomainJoin Code
As mentioned in the previous paragraph, the whole OOBE Entra Join flow is driven by CloudDomainJoin JavaScript loaded during OOBE:
- x(): After redeeming the MDM code, checks if mdm_terms_of_use_url is present. If so, launches TOU with g().
- g(): Builds the request to the TOU page, attaches a Bearer token, and navigates.
- h(): Handles the return. Expects IsAccepted=true and OpaqueBlob. If both are present, the artifact is stored and doAzureADJoin() is called.
In the failure case h() never receives the artifact and stops the flow.
Conclusion
Autopilot enrollment can fail right after Terms of Use acceptance when a new version is applied. The CloudDomainJoin script fails to process the return correctly, leaving the device unjoined.
This issue can be reproduced easily by enabling Terms of Use in Intune. Any change to the Terms of Use version will break the next enrollment. Once the acceptance is registered, enrollment proceeds as expected.
Workarounds are simple: accept the Terms of Use beforehand, or restart the device after the failure. Once acceptance is on record, enrollment continues successfully.