Reading AutopilotConfigurationFile.json: Every Documented Field Mapped Back to the Intune Switch

A user-driven Windows Autopilot deployment goes sideways. The licence terms screen appears when the profile says to hide it, or the device gets the wrong name, or a user from the wrong tenant is told to start over. The portal shows a profile that looks correct. So you go to the device for ground truth, open AutopilotConfigurationFile.json, and find nine properties with names that appear nowhere in the Intune admin center. Then you check a second device and the file is not there at all. Neither of those things is a fault. Both are documented behaviour, and this post is the reference table that makes them make sense.

The problem: nine field names that match no portal label

The Intune admin center gives you roughly a dozen switches when you build a Windows Autopilot deployment profile. Deployment mode. Join type. Microsoft Software License Terms. Privacy settings. Hide change account options. User account type. Allow pre-provisioned deployment. Language (Region). Automatically configure keyboard. Apply device name template. Plus a separate Enrollment Status Page, or ESP, profile that most people mentally file under the same feature.

Here is the path you took to set them.

Now here is what Microsoft documents inside the JSON file. Nine properties, and not one of them uses a portal label as its name.

Three things in that output cause most of the confusion. The first is that Test-Path returned False on your healthy device. The second is that a whole screen of portal switches has collapsed into a single number, 28. The third is that the two settings you cared about most, Language (Region) and Automatically configure keyboard, are simply absent. There is no property for them.

Why it happens: three surfaces, three vocabularies

An Autopilot deployment profile is expressed on three different surfaces. Each one was designed at a different time for a different consumer. They do not share a naming convention, because they were never meant to be read side by side.

The JSON is a fallback, not an export

This is the point that unlocks everything else. Microsoft documents AutopilotConfigurationFile.json under Windows Autopilot for existing devices. That is the Configuration Manager task sequence scenario. You wipe an existing domain-joined machine, lay down a fresh Windows image, and inject a JSON file so the first OOBE run behaves like an Autopilot deployment without the hardware hash having been uploaded in advance.

Because it is a fallback, it only needs the fields required to bootstrap that one flow. It needs to know which tenant to talk to. It needs to know whether to Entra join or hybrid join. It needs to know which OOBE screens to suppress. It does not need to carry the Enrollment Status Page configuration, because that arrives later from Intune over the wire.

Two limits on the JSON that admins get wrong

The first limit is scenario coverage. Microsoft documents that the JSON file only supports user-driven Microsoft Entra ID and user-driven hybrid Microsoft Entra profiles. Self-deploying and pre-provisioning profiles are not supported through a JSON file, because those scenarios require Trusted Platform Module attestation. If you have read elsewhere that the JSON is the pre-provisioning artefact, that is wrong. Pre-provisioning needs a registered device and a service-assigned profile.

The second limit is lifetime. Windows deletes the file when Sysprep.exe runs with the /Generalize parameter. The Prepare Windows for Capture task in a Configuration Manager task sequence does exactly that. This is why the documented workaround is to remove that task and run a plain sysprep /oobe /reboot instead.

Graph renamed half its properties in May 2024

The Graph surface has its own trap. Microsoft published a second generation of property names and marked the originals deprecated. Both still appear in the resource documentation, which makes it easy to write a script against the wrong one. The current name is the one to use.

The singular outOfBoxExperienceSetting is the current shape, and it exists in the Graph v1.0 endpoint rather than only in beta. The plural outOfBoxExperienceSettings is documented as read-only and deprecated. Notice the rename pattern: the old shape used verb-first names such as hideEULA, and the new shape uses noun-first names such as eulaHidden. Once you see the pattern you can predict the rest.

How to verify: file, registry, event log and Graph

Check all the surfaces, in this order, because each answers a different question. The file tells you what was injected. The registry tells you what the operating system accepted. The event log tells you the sequence of how it got there. Graph tells you what you authored.

Step 1: the file, if the scenario calls for one

The current Microsoft articles are precise about the file name and encoding, but they do not spell out the on-device folder. The path used by the documented task sequence step, and shown in Microsoft's own archived engineering blog, is the Provisioning folder under the Windows directory.

Two file-level requirements matter more than any property inside it. The file name must be exactly AutopilotConfigurationFile.json, and the encoding must be ASCII or ANSI. Microsoft states that OOBE will not follow the Autopilot experience if the file is saved as Unicode, as UTF-8, or under any other name. That is why the documented command uses Set-Content -Encoding Ascii rather than Out-File, which defaults to Unicode and can also truncate long lines.

Step 2: the registry, which is the real ground truth

On any device that received a profile from the Windows Autopilot deployment service, the settings land in the registry. This is the surface to check on a normal cloud-registered device. Microsoft documents six values under one key.

Step 3: the event log, for the sequence

Autopilot writes its own channel. In Event Viewer, expand Applications and Services Logs.

These are the documented IDs for that channel. Read them as a story rather than as isolated errors, because a single warning early in the sequence is normal.

Step 4: the Graph object, for what you actually authored

The portal blade is a view over the Graph resource, so reading Graph directly removes the label translation step entirely.

The @odata.type is doing real work here. An azureADWindowsAutopilotDeploymentProfile is an Entra join profile. An activeDirectoryWindowsAutopilotDeploymentProfile is a hybrid join profile, and it is the only one of the two that carries hybridAzureADJoinSkipConnectivityCheck and a domainJoinConfiguration relationship. That type distinction is what the JSON compresses into the single digit in CloudAssignedDomainJoinMethod.

The fix: the complete three-surface field map

This is the table to keep. Every documented JSON property, its Graph counterpart, the portal control that produces it, and what it actually does at OOBE time.

Where the bitmask fits, and where to stop

Microsoft documents five bits for CloudAssignedOobeConfig, and the same five appear in the registry documentation. Three map to portal controls. OobeUserNotLocalAdmin corresponds to User account type set to Standard. SkipExpressSettings corresponds to hiding Privacy settings. SkipEula corresponds to hiding Microsoft Software License Terms. The other two documented bits, SkipCortanaOptIn and SkipOemRegistration, have no portal switch at all. They are set by the service.

Rather than repeating the bit table here, decode the number using the dedicated walkthrough: CloudAssignedOobeConfig Decoded: Which OOBE Screens Your Profile Actually Skipped. The important point for field mapping is the direction of the relationship. Portal switches feed the bitmask. The bitmask does not enumerate portal switches, so you cannot reconstruct a profile from the number alone.

The settings that are not in the JSON at all

This is the list nobody writes down, and it is longer than the documented property table. Every row here is a portal control with no JSON representation.

The console walkthrough that produces each surface

To set the portal controls that feed the profile:

1. Sign in to the Microsoft Intune admin center.
2. Select Devices in the left hand pane.
3. Under By platform, select Windows.
4. Under Device onboarding, select Enrollment.
5. Under Windows Autopilot, select Deployment Profiles.
6. Select Create Profile, then select Windows PC.
7. On the Basics page, enter a Name and optional Description, then set Convert all targeted devices to Autopilot.
8. On the Out-of-box experience (OOBE) page, set Deployment mode, then Join to Microsoft Entra ID as.
9. Set Microsoft Software License Terms, Privacy settings, Hide change account options, User account type, Allow pre-provisioned deployment, Language (Region), Automatically configure keyboard and Apply device name template.
10. On the Assignments page, choose Selected groups and pick the groups to include or exclude.
11. On the Review + Create page, select Create.

To produce the JSON file for the existing-devices scenario, Microsoft documents the conversion through the WindowsAutopilotIntune module. Two details in that command are load-bearing. The profile is written into a per-profile subfolder, and the encoding is forced to ASCII.

Proof it worked: a clean read of all three surfaces

The companion script reads all three surfaces on the local device and prints each documented field with a plain-English explanation. It is read-only, it never writes, and it redacts tenant identifiers unless you explicitly ask for them.

Read the verdict line first, then work upward. If the documented registry count is below six on a device you believe is Autopilot-registered, the profile download is the thing to investigate, and event IDs 100, 160 and 815 will tell you which part failed.

Two of those undocumented values are worth naming because they explain a common false conclusion. CloudAssignedLanguage and CloudAssignedRegion exist in the registry even though there is no matching JSON property, which is why people assume the JSON must carry language settings somewhere. It does not. The service delivered those values over the wire.

One last framing makes the whole mapping easier to remember. The JSON file answers how to make an unregistered machine behave like an Autopilot device once. The Graph object answers what every device in a group should experience. The registry answers what this specific device actually got. Nine properties, roughly twenty Graph properties and six registry values are not three views of one thing. They are three answers to three different questions, and choosing the right surface first is most of the troubleshooting.

References

Microsoft official documentation:

• Windows Autopilot for existing devices — the documented JSON file property table, the file name and encoding requirements, and the precedence rule against a service-assigned profile.
• Configure Windows Autopilot profiles — every portal control on the OOBE page, and the exact click path.
• windowsAutopilotDeploymentProfile resource type — the Graph properties, plus the May 2024 deprecation notes for language, outOfBoxExperienceSettings, extractHardwareHash and enableWhiteGlove.
• outOfBoxExperienceSetting resource type, v1.0 — the current OOBE complex type, with the userType and deviceUsageType enum values.
• Windows Autopilot troubleshooting FAQ — the Provisioning diagnostics registry values and the Autopilot event ID catalog.
• Windows Autopilot known issues — why Sysprep /Generalize deletes the JSON file, and the ANSI or ASCII encoding failure mode.
• Create Windows Autopilot task sequence in Configuration Manager — the task sequence change that stops Sysprep removing the file.
• Speeding up Windows Autopilot for existing devices, archived Microsoft blog — the on-device Provisioning and Autopilot destination folder.

Community deep-dives, each fetched and verified as on topic:

Related posts on this site:

• CloudAssignedOobeConfig Decoded: Which OOBE Screens Your Profile Actually Skipped — the full bit table for the one numeric field in the JSON.
• Autopilot Language, Region and Keyboard: The Profile Skips a Screen, It Does Not Install a Language — what locale and keyboardSelectionPageSkipped really do.
• Your Autopilot Profile Edit Didn't Apply: The Cache Nobody Checks — why a corrected profile does not reach an enrolled device.
• The ZTDID: The One Attribute That Proves a Device Is Really Autopilot-Registered — the identifier behind ZtdCorrelationId.

The companion script Get-AutopilotProfileFieldReport.ps1 is read-only, ASCII-only, and runs on both Windows PowerShell 5.1 and PowerShell 7. It redacts tenant identifiers by default.