Every Autopilot-provisioned device carries a single number that records which out-of-box-experience screens its deployment profile decided to skip. It is a bitmask called CloudAssignedOobeConfig, and if you have ever inherited a device and wondered why it did or did not show the licence terms, or why the first user ended up a local administrator, this one value holds part of the answer. It is also a good lesson in reading a number honestly rather than confidently.
CloudAssignedOobeConfig is a REG_DWORD under HKLM:\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot that packs several OOBE decisions into one integer. Five bits are publicly documented: 0x01 SkipCortanaOptIn, 0x02 OobeUserNotLocalAdmin, 0x04 SkipExpressSettings, 0x08 SkipOemRegistration, 0x10 SkipEula. A real device in this series returned 1308, which decodes cleanly for three documented bits - and leaves 0x500 (1280) set that Microsoft has never published a meaning for. This post shows how to decode it, and why you should report undocumented bits as unknown rather than inventing an explanation.
1308 -band 16 returns 16, the "skip EULA" bit is on. If it returns 0, it is off. That is the entire mechanic - no PowerShell wizardry required.The problem: a single number nobody can read
You open Autopilot diagnostics on a device, or dump the Provisioning registry hive during troubleshooting, and find CloudAssignedOobeConfig sitting there as something like 1308. It clearly means something. The Intune portal shows the deployment profile with friendly toggles - Skip privacy settings: Yes, User account type: Standard - but the device stores the outcome as one integer, and the mapping is not in the portal.
This matters in three real situations: you are handed a device and need to know what its profile did without access to the tenant that built it; you are reconciling "the profile says X but the device did Y"; or you are writing fleet reporting and want the device's own record rather than the portal's intent.
Why it happens: OOBE settings are packed into a bitmask
The Autopilot deployment service sends the profile down as JSON. Rather than a long list of booleans, the OOBE-related decisions are collapsed into one integer field, which Windows then writes to the registry verbatim. It is compact and cheap to evaluate during OOBE, which is when it matters.
The publicly documented bits come from Microsoft's own archived Autopilot troubleshooting material. Five are named:
| Bit | Name | Meaning when set |
|---|---|---|
0x01 (1) | SkipCortanaOptIn | The Cortana opt-in screen is suppressed |
0x02 (2) | OobeUserNotLocalAdmin | The first user is not made a local administrator - this is the "Standard" user account type |
0x04 (4) | SkipExpressSettings | The express/privacy settings screen is suppressed |
0x08 (8) | SkipOemRegistration | The OEM registration screen is suppressed |
0x10 (16) | SkipEula | The licence terms screen is suppressed |
0x100 (256) and 0x400 (1024) set - together 0x500, or 1280 - which are not in any public list. They are genuinely set by the profile and they genuinely mean something. What you must not do is guess. Report them as undocumented and confirm the corresponding behaviour from the profile in the portal instead.How to verify: read and decode the value
Reading the raw value takes one line:
Decoding it by hand is just a bitwise AND per bit. Here is the "is the EULA screen skipped?" test, and what good looks like:
0x02 is not set, the profile made the first user a local administrator - which is a genuinely useful thing to be able to prove on a device you did not build, especially during a security review.The fix: decode the documented bits, flag the rest
Context: there is nothing to repair - this is a diagnostic value. "The fix" here is a decoding method you can trust, and a rule for handling what you cannot verify.
- Decode the five documented bits and report each as set or not set.
- Mask off those five bits from the value. Anything left over is undocumented.
- Report the leftover as an explicit unknown, with its hex value, and stop there. Do not assign it a meaning.
- If you need to know what an undocumented bit corresponds to, read the deployment profile in the Intune portal - the friendly toggles are the source of truth for intent, the bitmask is only the device's record of the outcome.
CloudAssignedOobeConfig to change OOBE behaviour. It is a record of a decision the deployment service already made and OOBE already acted on - the screens it describes were shown or skipped long before you could edit it. Changing the number changes your own diagnostics, not the device's history, and it will make future troubleshooting actively misleading.Registry reference
| Value name (type) | Healthy / expected | What it tells you |
|---|---|---|
CloudAssignedOobeConfig (REG_DWORD) | Any value - decode it, do not judge it | Which OOBE screens the profile suppressed, packed as bits. Mask off 0x1F to find undocumented bits |
CloudAssignedForcedEnrollment (REG_DWORD) | 1 on a normal Autopilot device | Whether enrollment was mandatory during OOBE - 0 means the user could have skipped it |
DeploymentProfileName (REG_SZ) | Matches a profile in your tenant | Which profile produced the bitmask above - pair the two when reporting |
CloudAssignedTelemetryLevel (REG_DWORD) | Matches your profile's configured level | The telemetry level the profile assigned during provisioning |
IsDevicePersonalized (REG_DWORD) | 0 for a corporate self-deploying or user-driven device | Distinguishes a personalised (consumer-style) OOBE path from a managed one |
Proof it worked: 1308 decoded on a real device
A genuine run of Decode-AutopilotOobeConfig.ps1 from this series, against a real Autopilot-provisioned device:
What this device tells us, honestly: express settings, OEM registration and the licence terms screens were all suppressed. The first user was made a local administrator, because OobeUserNotLocalAdmin is not set. Cortana opt-in was not explicitly skipped by this bit. And two further bits are set whose meaning is not public - so the report says so, plainly, instead of inventing a fourth and fifth conclusion.
One implementation note from writing the script, because it is an easy trap: do not build the bit map as [ordered]@{1='SkipCortanaOptIn'; 2='OobeUserNotLocalAdmin'}. An OrderedDictionary with integer keys resolves \$map[1] as the element at index 1, not the value for key 1 - which silently shifts every label by one position and produces a decoder that is confidently wrong. The first version of this script did exactly that and reported "SkipEula" against bit 0x04. Use an array of objects, or string keys, instead.
References
- Microsoft (archived blog) - Troubleshooting improvements in Windows Autopilot - the source of the documented bit values, written by the then-Autopilot program manager. Archived, so treat the bit list as accurate but not necessarily complete for current builds.
- Microsoft Learn - Configure Windows Autopilot deployment profiles
- Microsoft Learn - outOfBoxExperienceSettings (Graph API resource) - the modern, named properties behind the portal toggles
Microsoft MVP community deep-dives
Verified and genuinely on-topic - each URL was fetched and confirmed before being cited here, not copied on trust:
| Author | Post | What it adds |
|---|---|---|
| Rudy Ooms (MVP, call4cloud.nl) | Step by Step: How Windows Retrieves the Autopilot Profile | Traces the full eight-step token-and-profile retrieval flow, and independently documents both the AutopilotPolicyCache registry key and the wmansvc on-disk cache this post relies on |
Script for this post is in Windows-Autopilot-Scripts.