Modern Windows Provisioning Internals – Part 2

Introduction

What if I told you that the most critical parts of Windows Autopilot provisioning happen before the user even types their first username — and almost none of it is visible on screen?

As I like to say, every IT admin working with modern Windows management knows the OOBE screens — but very few know what Windows is actually doing behind those screens.

The moment your Windows device connects to the internet during OOBE, everything changes. Behind the friendly welcome animation, Windows is already contacting cloud services, applying updates, creating trust anchors, and deciding whether this machine becomes a personal PC or a fully managed enterprise device.

In Part 1 of this series, we walked through the early stages of Windows provisioning — from the moment a device powers on, through UEFI and kernel initialization, into session creation, and finally to the point where the Out‑of‑Box Experience (OOBE) first appears.

That post established the foundation: how Windows boots, how it constructs the initial environment, and how CloudExperienceHost (CEH) begins rendering the very first screens the user sees.

With Part 2, we move past that welcome screen and into the cloud‑driven portion of modern provisioning — the part where Windows truly comes alive as a connected device. This phase is where most of the intelligence of Autopilot, attestation, and enterprise onboarding actually happens, yet very little of it is visible to the user.

In this post, we will unpack what Windows does immediately after it becomes network‑aware:

• How CloudExperienceHost orchestrates the network connection flow
• How zero‑day patches and quality updates are discovered and applied
• How Windows initializes and validates the TPM, prepares attestation keys, and signals hardware trust
• How Autopilot discovers its registration state and retrieves the deployment profile
• And finally, the pivotal decision point where Windows chooses between a consumer setup path and an enterprise Autopilot‑driven flow

This is the “invisible heart” of OOBE — a sequence of cloud calls, hardware verification steps, provisioning actions, and policy‑driven pivots that ultimately determine what kind of device the machine will become.

Let’s get started.

Quick Recap – OOBE begins rendering Initial pages

The CloudExperienceHost (CEH) process (a system UWP app), upon getting launched by OobeShellHost.exe, begins with rendering the initial OOBE Welcome screen that eventually cascades to the rest of the OOBE screens like OOBE Region, OOBE Language and OOBE Keyboard layout setup screens.

Each of the OOBE screen as rendered by CEH are essentially UWP web-apps implemented in HTML/JS with WinRT bridges, shipped under the CloudExperienceHost (CEH) system app.

If you’re curious about the assets and packages involved (e.g., CloudDomainJoin, moderndeployment.autopilot), you can see them in the Windows OOBE package contents for the recent builds, usually found here under the path C:\Windows\SystemApps\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy\

At this point, if the device is not already connected to an active Internet connection, CEH renders the Network connection screen.

Modern OOBE for Windows 11 strongly prefers internet connectivity as Microsoft has been actively moving away from offline OOBE for consumer editions lately. For enterprise provisioning, internet access is inherently required to reach Identity, Autopilot, MDM services, and other supporting services endpoints.

From here on,

• For consumer provisioning, OOBE follows the network connection flow which eventually cascades to sign-in with a personal Microsoft account to get the device setup for use. [Though you can still use a work or school account to sign-in and set it up as a work device!)

• For enterprise provisioning, OOBE follows the network connection flow which eventually cascades to sign-in with a Work or School account to get the device setup for use.

Phases 1-7, from power on to firmware to OS bootloader to Windows Kernel initialization is already covered in Part 1 where we ended right when the device started the OOBE flow displaying the OOBE welcome screen.

So here, we start from where we left off…

Phase 8: OOBE Network Connection Flow

Once online, CloudExperienceHost (CEH) starts executing a sequence of cloud actions — some of which is visible in the OOBE UI, while most are not.

msoobe.exe utilizing provengine.dll continues to maintain the role of OOBE orchestrator while CloudExperienceHost (CEH) works to provide a platform, either as the executioner or coordinator of these actions. OOBE transitions and CEH activity are observable in Shell‑Core and related logs which can be used for OOBE troubleshooting. [oofhours.com]

These actions are mentioned below.

Zero-day Patch (ZDP) updates

After network connect, Windows checks if any critical ZDP updates is available or applicable for the device and proceeds to download and apply any if found during this phase of the OOBE. A reboot can occur.

Microsoft’s OOBE docs explicitly note critical updates during OOBE once you’re online. [learn.microsoft.com], [learn.microsoft.com]

On eligible Entra‑joined devices, admins can also govern quality updates during OOBE via ESP policy. See Version Notes. [learn.microsoft.com]

About “quality updates during OOBE”: Microsoft announced admin‑controlled Quality Updates in OOBE (NDUP) to allow monthly quality updates to install before first sign‑in on eligible Entra‑joined/hybrid devices, delivered via an Enrollment Status Page (ESP) settings toggle.  The feature went through multiple timeline changes through late 2025. As of January 2026, Microsoft’s messaging clarifies the policy is available but disabled by default.  [techcommunity.microsoft.com]

Community deep‑dives track the registry and CEH plugin behavior. [call4cloud.nl]

While Windows does the ZDP update check, the OOBE renders the screen showing “Please wait…”

Components involved: Windows Update agent and services (e.g., wuauserv, wuaueng.dll, wups.dll, msoobeplgin.dll) backing CEH’s “update” view.

TPM initialization & readiness for attestation

Windows auto‑provisions the TPM (unless disabled by policy), initializes TPM, sets owner authorization to a random high‑entropy value, and discards it by default (Windows 10, 1607+). It creates the Storage Root Key (SRK) (final result of take ownership action) and finally prepares attestation keys (AIK).

On modern Intel platforms, the EK certificate chain is in TPM NV via Intel ODCA, retrievable with tpmdiagnostics ekchainnv — no EK Online Provisioning needed unlike the older generations which relied on EKOP online services to get the EK validated and EK cert provisioned; similar shift exists on the newer gen AMD chips. These hardware signals later enable Autopilot attestation and Windows enrollment attestation in Intune. [learn.microsoft.com], [community.intel.com], [tpm2-tools…thedocs.io]

Microsoft documents Windows enrollment attestation(MDM hardening) that adds an additional TPM‑backed check during Intune enrollment (separate from Autopilot pre‑provision attestation). [learn.microsoft.com]

Components involved: TPM APIs (tpmcore.dll, wintrust.dll) and communication with Microsoft Device Identity Service.

Windows Activation Checks

OS licensing components validate digital entitlement/KMS in the background. (Usually invisible unless activation fails.) (General behavior; no special enterprise steps here.)

Components involved: Software Protection Service (sppsvc.exe) and licensing APIs/services (e.g., slc.dll, sppcomapi.dll)

Autopilot Discovery & Profile Retrieval

Windows Autopilot is a cloud‑driven provisioning framework integrated deeply into the Windows OS and Microsoft’s cloud identity/MDM layers

CEH triggers Autopilot flow to check if the device is registered, retrieves the tenant‑assigned Windows Autopilot profile (WAP) — a JSON payload that instructs OOBE which screens to skip, the join method, naming pattern, etc. The profile gets cached locally and is mirrored in the registry. [learn.microsoft.com]

Components involved: Autopilot stack which includes “moderndeployment.autopilot” components (like autopilot.dll, etc.)

Component	Role in Provisioning	Verified Source
ModernDeployment subsystem (onecoreuap/admin/moderndeployment)	Provisioning engine for OOBE, Autopilot, diagnostics.	Error paths in autopilot.dll logs reference it. [thewindowsclub.com]
autopilot.dll	Core Autopilot runtime, diagnostics, state mgmt.	Defined as key OS component. [thewindowsclub.com]
CloudExperienceHost (CEH)	Renders OOBE HTML/JS screens.	Microsoft documentation on OOBE/Autopilot flow. [learn.microsoft.com]
login.live.com (MSA Token service)	Performs device authentication, issues RST2.srf security token, provides X‑Device‑Token.	Autopilot backend flow shows deviceAddCredential.srf + RST2.srf. [call4cloud.nl]
X‑Device‑Token (MSA Ticket)	Device identity artifact used to retrieve Autopilot profile.	Returned by login.live.com and sent to ZTD/DDS service. [call4cloud.nl]
Autopilot Cloud Service ztd.dds.microsoft.com	Provides Autopilot profile (JSON) to device.	Autopilot profile retrieval flow. [call4cloud.nl]   Confirmed via Microsoft troubleshooting FAQ. [learn.microsoft.com]
Microsoft Entra ID STS	Handles user authentication and token issuance.	Entra credential validation during user auth. [learn.microsoft.com]
Intune MDM	Applies apps/policies post‑enrollment.	Autopilot/Intune integration documentation. [learn.microsoft.com]

Now, from the above set of activities as performed by CloudExperienceHost (CEH) immediately after the device establishes a network connection during OOBE provisioning, two activities — TPM provisioning and Autopilot check — warrant a closer, more detailed analysis, which is provided in the sections below.

TPM Activation & Attestation Sub Flow

Trigger: Windows hardware security initialization and any workflow that requires TPM trust (e.g., Autopilot/MDM enrollment or certificate issuance).

Trusted Platform Module (TPM) can be of three types –

• Discrete – Stand‑alone security chip on the board (physically separate and independently evaluated).
• Integrated – TPM logic integrated into a larger chipset/package (e.g., platform security controller) but logically isolated per TCG requirements; sits between the discrete and firmware models.
• Firmware – TPM 2.0 implemented in firmware/TEE on the platform’s security engine (e.g., Intel PTT in CSME; AMD fTPM in PSP/firmware), not a separate chip.

Discrete TPM and Integrated TPM are common in business‑class devices and servers, but are less typical for mass‑market consumer systems. On most modern Windows PCs (consumer laptops/desktops), the TPM implementation is firmware TPM.

Irrespective of the type of TPM, Windows follows the same high‑level provisioning and attestation flow as below.

• Initialize -> Validate Endorsement Key (EK) evidence  (EK/EKCert and, on modern Intel, EK chain from ODCA in NV. New gen AMDs also follow the same.)
• Take ownership -> Generate Storage Root Key (SRK)  (Owner auth is randomized and not retained by default (can be forced via OSManagedAuthLevel, but Microsoft does not recommends doing it)
• Ready for attestation -> Create AIK (via MakeCredential/ActivateCredential; optionally obtain AIK cert from a Privacy CA (enterprise). Process model consistent with TCG tooling and Windows flows.)

Initialize -> Validate EK evidence

Every TPM contains a unique Endorsement Key (EK) injected/burned at the time of manufacture. The private EK never leaves the TPM. Some also carry an EK certificate (EKCert) and a platform certificate in NV storage; others obtain or expose the chain during provisioning.

• Discrete TPMs – The EKCert is typically embedded at manufacturing (e.g., STMicroelectronics), so Windows can read it immediately.

• Firmware TPMs – On recent platforms (11th Gen and later), Intel uses an On‑Die Certificate Authority (ODCA) and stores the EK chain in TPM NV. The chain can be read locally (e.g., tpmdiagnostics ekchainnv), rather than relying on the older EKOP service that was used for previous-generation platforms. Modern AMD processors have also shifted from relying on external EKOP service for TPM initialization to having the Endorsement Key Certificate (EKCert) stored within the TPM NVRAM during manufacturing or initialized locally upon the first boot.

Why EK evidence matters: A relying service (or Privacy CA) needs to verify that EK_Pub belongs to a genuine TPM via the manufacturer‑signed EKCert (or a trusted list of EKPub hashes/CA issuers).

Take ownership -> Generate SRK

Windows sets the owner authorization to a random high‑entropy value and discards it (i.e., it does not retain the owner password by default, starting with Windows 10, version 1607). This prevents remote misuse of the owner authorization. You can explicitly retain it via policy, but Microsoft does not recommend this. [learn.microsoft.com]

As part of ownership, the TPM creates the Storage Root Key (SRK) — the root of the key hierarchy for sealing/binding. The SRK’s private portion never leaves the TPM.

Ready for Attestation -> Create Attestation Identity Key (AIK)

With EK evidence and SRK in place, Windows (or your enterprise tooling) requests an Attestation Identity Key (AIK) to be generated inside the TPM. The AIK is a restricted signing key used to sign TPM‑originated structures (e.g., PCR quotes) instead of using EK (privacy and role separation).

The AIK is bound to a genuine TPM via credential activation (the EK proves the AIK belongs to the same TPM). In practice this uses the MakeCredential/ActivateCredential flow: the CA creates a credential using EK_Pub, and only the TPM holding EK_Priv can activate (decrypt) it — transferring trust from EK to the new AIK.

Optionally, the AIK can be certified by a Privacy CA (or an enterprise CA) to issue an AIK certificate. This lets relying parties verify that a quote (signed digest of PCRs) comes from a real TPM and not a software impostor.

TPM End State

• Initialized: TPM is active, SRK generated, EK evidence available.
• Owned: Windows holds (and discards) owner authorization; TPM is under OS control.
• Attestation‑ready: AIK exists (and may be AIK‑certified), enabling remote attestation (PCR quote signing) and TPM‑protected key attestation for enterprise certificates.

Autopilot Sub Flow

Trigger: Windows provisioning logic, during the device first‑boot, as soon as the device enters OOBE. Requires internet connectivity.

Network prerequisites: Device must be able to reach Autopilot/Identity/MDM endpoints over TCP 443, without SSL interception. Key FQDNs include:

• Autopilot service: ztd.dds.microsoft.com, cs.dds.microsoft.com [github.com]
• Identity/STS: login.live.com (device add + token issuance) [learn.microsoft.com]
• Entra device registration & join (used during OOBE):
  • enterpriseregistration.windows.net
  • device.login.microsoftonline.com
  • autologon.microsoftazuread-sso.com (Seamless SSO) [docs.azure.cn]
• Intune/MDM service endpoints (policy/app delivery, ESP):
  • manage.microsoft.com, graph.microsoft.com, *.azureedge.net (content delivery) [learn.microsoft.com]

These aren’t web pages; test port 443 reachability instead of HTTP browsing.

Microsoft doesn’t support SSL interception of management endpoints. If your proxy enforces auth and inspection, create explicit bypasses (or a machine‑tunnel) for the FQDNs above. Further, Windows can learn proxy settings before the user signs in via WPAD (DHCP Option 252 and/or wpad DNS record) that points to a PAC file (e.g., http://intranet/wpad.dat). Use PAC logic to DIRECT Microsoft management/Autopilot FQDNs and send everything else via proxy.

CloudExperienceHost (CEH), as the OOBE host process, calls into the Autopilot stack to start the Autopilot check.

It is essentially autopilot components (like autoPilot.js and others) located at C:\Windows\SystemApps\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy\* which utilizes functions as implemented in “moderndeployment.autopilot” components (like autopilot.dll, etc.) via WinRT calls.

Simplified sequence (thanks to @Rudy) is as follows:

1. Device makes DeviceAddRequest to STS — https://login.live.com/ppsecure/deviceaddcredential.srf with hardware identity. MS Account Sign‑In Assistant (WLID) components participate.
2. STS returns HWDeviceID/GlobalDeviceID.
3. Device makes request to obtain Security Token — https://login.live.com/RST2.srf for Autopilot service scope.
4. Receive X‑Device‑Token (MSA ticket) — stored under HKCU\Software\Microsoft\IdentityCRL\Immersive...\Token; used to authenticate to DDS.
5. Device makes call to Autopilot service — ztd.dds.microsoft.com using X‑Device‑Token (+ Autopilot marker on newer builds) to fetch profile JSON.
6. Profile retrieved and cached locally — on disk under C:\Windows\ServiceState\wmansvc\... and in the registry under HKLM\SOFTWARE\Microsoft\Provisioning\AutopilotPolicyCache\PolicyJsonCache. [techcommun…rosoft.com], [smbtothecloud.com]

If registered but no profile assigned: The device may receive the tenant’s default Autopilot profile. However, if no applicable Autopilot profile exists in the tenant at that time, a blank profile gets cached locally on the device. Rebooting during OOBE triggers a re‑fetch. Microsoft’s troubleshooting guidance explicitly notes that a profile is downloaded “as soon as possible and again after each reboot,” and a blank profile can be replaced on subsequent attempts. [learn.microsoft.com]

What’s inside the WAP JSON (highlights you’ll see in the cache):

• CloudAssignedTenantId / CloudAssignedTenantDomain — tenant identity (also mirrored under HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot).
• CloudAssignedOobeConfig — bitmask controlling OOBE suppression (e.g., SkipEULA, SkipExpressSettings, etc.).
• CloudAssignedDomainJoinMethod — join method (Entra vs Hybrid).
• CloudAssignedDeviceName — naming template with tokens like %SERIAL%.

To learn more about the fields contained in the JSON as shown above, check here.

If you work with Autopilot for existing devices, you will need this JSON to be used offline; Microsoft’s “Create JSON file” article is still the starting point.)

Autopilot settings, as received from the Windows Autopilot deployment service, helps to curate the next phases of OOBE. You can find them under registry node HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

Provisioning Engine reads bitmapvalue of CloudAssignedOobeConfig to determine which OOBE screens to skip or omit. Example flags in CloudAssignedOobeConfig:

• SkipEULA
• SkipExpressSettings

These flags instruct CloudExperienceHost to bypass unnecessary screens through the enterprise setup phase.

OOBE Decision Pivot — Consumer vs Enterprise Provisioning

During the autopilot sub-flow as explained above, Windows evaluates:

• Is the device registered to Autopilot?
• If yes, is there an Autopilot profile available?

Possible Outcomes

• Device NOT registered with Autopilot

CloudExperienceHost (CHE) defaults to Consumer setup flow (Home/Personal experience) rendering the Microsoft account sign-in screen.

• Device IS registered, but NO Profile assigned

Autopilot check returns empty profile. CEH falls back to Consumer setup flow because there’s no enterprise configuration.

• Device IS registered, having Profile assigned

CEH uses the configuration as retrieved from the AP profile to curate the OOBE flow and starts Enterprise setup flow:

• Skip certain pages (e.g., region, EULA, privacy settings).
• Applies enterprise branding to render branded Enterprise sign-in screen.

Phase 9: Enterprise Setup Flow

Branded Sign-In screen & user Auth pipeline

Cloud Experience Host (CEH) calls in CloudDomainJoin (CDJ) webapp which takes over to render the sign‑in UI (for both consumer and enterprise flow).

Under the hood, it utilizes CloudAP (Cloud Authentication Provider) in LSASS to handle Entra token flows.  CEH’s web views hand off to CloudAP via LSA. [learn.microsoft.com], [learn.microsoft.com], [syfuhs.net]

Why CEH downloads “CloudDomainJoin” on the fly?

The CDJ JavaScript package is fetched during OOBE and cached under the defaultuser0 profile so Microsoft can improve enrollment without a full OS update. The trade‑off is that regressions in those web packages have occasionally caused OOBE stalls (e.g., “Unexpected page” after ToU in 2025)—triage often uses Shell‑Core Operational logs to confirm CEH/CDJ transitions. [patchmypc.com]

Outcome — On successful sign‑in, the device gets an ID token for the authenticating user with which Windows provisioning then proceeds to the next stages of provisioning — Entra join (device join via Entra DRS) and automatic MDM enrollment per tenant settings.

Phase 10: Post Sign-In Actions

After successful user sign-in:

• msoobe.exe (utilizing provengine.dll) continues to remain as the main OOBE orchestrator and initiates creation of the local account linked to Azure AD.
  • winlogon.exe (Session 1, context defaultuser0) calls lsass.exe (Session 0, SYSTEM) to get logon token.
    • Creates a pending interactive session for the user. [The session remains blocked till ESP completion]
    • A local profile folder (C:\Users\<username>) is created for the user.
    • A SID is generated for the user account linked to the user’s Azure AD identity.
    • Registry entries under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList gets updated with the new profile information.
    • A temporary Logon buffer gets created using Winlogon + LSASS containing:
      • Security token
      • Session environment variables
      • User Profile path

If the MDM Terms of Use (TOU) is configured, it is during this time that the same gets rendered on the screen, and the user needs to accept the TOU to proceed further with device provisioning.

At this point, the OOBE provisioning is not completed yet and as such does not switches over to a new user session using the newly created user account. Instead, the logon buffer is kept in memory waiting for ESP to signal completion of device setup phase. Till then, defaultuser0 stays in control.

The switchover delay is intentional and tied to privilege requirements during provisioning.

Here’s why:

Keeping OOBE under defaultuser0 context ensures full control is retained for provisioning tasks until the device is actually ready to run under the intended user account context.

Microsoft’s ESP troubleshooting + Autopilot deep‑dives align to this model of keeping OOBE work in system/defaultuser0 until the device is ready. [learn.microsoft.com], [msendpointmgr.com]

If you ever hit defaultuser0 artifacts after unexpected reboots during OOBE or pre‑provisioning reseal, you’ll see community threads about it. Root causes vary (reboots, update timing, hybrid specifics), but logs will always point you back to CEH/ESP sequencing. [sccmentor.com]

TL;DR / Cheat‑sheet

What must be open

• 443 to ztd.dds.microsoft.com, cs.dds.microsoft.com (Autopilot), login.live.com (DeviceAdd/RST2), plus Entra/MDM endpoints. [learn.microsoft.com]

Sample script for quick Network test (device OOBE shell → Shift+F10):

PowerShell
$endpoints = @(
   'ztd.dds.microsoft.com','cs.dds.microsoft.com',
   'login.live.com','enterpriseregistration.windows.net',
   'device.login.microsoftonline.com','autologon.microsoftazuread-sso.com',
   'manage.microsoft.com','graph.microsoft.com'
	)
$endpoints | ForEach-Object {
 Test-NetConnection $_ -Port 443 | Select-Object ComputerName, TcpTestSucceeded
}

Remember these are service endpoints; look for 443 reachability — not HTTP 200s. Also no SSL inspection for these FQDNs.

Where the Autopilot profile lives

• File cache: C:\Windows\ServiceState\wmansvc\…
• Registry: HKLM\SOFTWARE\Microsoft\Provisioning\AutopilotPolicyCache\PolicyJsonCache
• Tenant & OOBE flags: HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot\*

Which flag skips OOBE pages

• CloudAssignedOobeConfig (bitmask) — inside the profile JSON and visible in Diagnostics\Autopilot.

TPM facts that matter

• Windows randomizes & discards owner auth (1607+); don’t keep it unless you absolutely must.
• On 11th‑gen+ Intel, ODCA puts the EK chain in TPM NV; read with tpmdiagnostics ekchainnv.

ZDP vs Quality updates during OOBE

• ZDP (critical) is always pulled after network connection gets established in OOBE.
• Quality updates in OOBE are admin‑controlled via ESP, available Jan‑2026, disabled by default. [learn.microsoft.com], [m365admin….sontek.net]

Where to look when it breaks

Event Logs

• CEH navigation )CEH/CDJ page flow): Shell‑Core/Operational Events
• Autopilot stages: ModernDeployment‑Diagnostics‑Provider/Autopilot Events
• MDM/ESP: DeviceManagement‑Enterprise‑Diagnostics‑Provider/Admin Events
• One‑shot log collection: mdmdiagnosticstool.exe -area Autopilot; TPM -cab <path>

Registry

• HKLM\SOFTWARE\Microsoft\Provisioning\AutopilotPolicyCache\PolicyJsonCache (WAP JSON cache)
• HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot\* (tenant & OOBE flags e.g., CloudAssignedTenantId, CloudAssignedOobeConfig)

Files

• C:\Windows\ServiceState\wmansvc\AutopilotDDSZTDFile.json and related cache files (profile/artifacts)

To be Contd…

I will keep it till this for today.

By now the device is online, serviced, attestation‑ready, and has either pivoted to a consumer flow or fully committed to enterprise provisioning.

In the next and the final part — Part 3 — we’ll pick up from right after the branded sign‑in and follow the chain through Entra Join → MDM Enrollment → ESP → to user finally getting to the Desktop screen.”