Technical Anshu
Tutorials Blog
📄 Answer File Anatomy

Autounattend XML Structure Explained One Setup Pass at a Time

An answer file is not one long list of settings — it is seven separate conversations with Windows Setup, called passes, and each setting only works in the pass that owns it. Learn the passes and the file stops being magic.

✍️ Technical Anshu🪟 Windows 10 / 11⏱️ 9 minute read
🎥 Watch the complete video — building a custom Windows ISO, removing unwanted components and setting the bypass options step by step

Part 1 of this series showed how an autounattend.xml next to your custom ISO makes Windows install itself. This page is the layer underneath: the structure of the file. Every setting lives inside a named configuration pass, and Setup reads each pass at a different moment of the install. Put a valid setting in the wrong pass and it is silently ignored — the number one reason hand-written answer files “do nothing”. Once you can read the skeleton below, any generated file becomes something you can audit instead of something you blindly trust.

autounattend.xml — minimal skeleton, passes marked

<settings pass="windowsPE"> language, disk, EULA, bypass commands

<settings pass="offlineServicing"> packages applied to the image

<settings pass="specialize"> computer name, network, domain

<settings pass="oobeSystem"> user account, OOBE screens, first logon

Status: each setting sits in the pass that runs it

Most real files use three or four of the seven passes. Order in the file follows the order Setup runs them.
1

The Seven Passes in the Order Setup Runs Them

  1. windowsPE — runs inside the setup environment, before anything is installed: language and keyboard, disk partitioning, product key entry, EULA acceptance, and synchronous commands such as the registry values that bypass hardware checks
  2. offlineServicing — applies packages and drivers to the image while it is still offline on the disk
  3. generalize — used when you capture a prepared image with Sysprep; most builders never write it by hand
  4. specialize — runs at first boot of the installed system: computer name, workgroup or domain join, network location
  5. auditSystem / auditUser — OEM factory audit mode only; skip them for normal deployment
  6. oobeSystem — the out-of-box experience: which screens are hidden, the first user account, time zone, and FirstLogonCommands
2

A Minimal Skeleton You Can Copy

This trimmed file accepts the EULA, sets the language, and hides two OOBE screens. It is deliberately small — audit value over size — and every tag is plain ASCII, ready to copy:

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <unattend xmlns="urn:schemas-microsoft-com:unattend">
  3. <settings pass="windowsPE"> containing the Microsoft-Windows-Setup component with <UserData><AcceptEula>true</AcceptEula></UserData>, plus the Microsoft-Windows-International-Core-WinPE component with your UILanguage, InputLocale, SystemLocale and UserLocale values
  4. <settings pass="oobeSystem"> containing the Microsoft-Windows-Shell-Setup component with <OOBE><HideEULAPage>true</HideEULAPage><ProtectYourPC>3</ProtectYourPC></OOBE>
  5. </unattend>

Every component block also needs its architecture attributes — for a 64-bit image that is processorArchitecture="amd64" together with the standard publicKeyToken="31bf3856ad364e35", language="neutral" and versionScope="nonSxS" values. Generators fill these in automatically; if you hand-edit, never delete them.

3

The Rules That Keep the File Valid

  1. Exact file name: it must be autounattend.xml at the root of the install media — Setup searches for that name and no other
  2. Settings are case- and pass-sensitive: a correct value in the wrong pass is ignored, and a misspelled element fails the whole file
  3. Validate before you deploy: Windows System Image Manager (in the Windows ADK) checks every setting against your actual image and is the only tool that truly validates — visual/XML editors only check that tags are balanced
  4. Escape XML characters in values: a password or name containing & or < must be written as an entity, or the parse fails
4

When Setup Says It Could Not Parse the Answer File ⭐

  1. The error names the pass and often the setting — read it instead of guessing; it appears as "Windows could not parse or process the unattend answer file"
  2. Remove the whole file and confirm the base ISO installs cleanly — that splits "bad image" from "bad answer file" in one test
  3. Rebuild the file with a generator or WSIM rather than patching it by hand, then reintroduce your custom settings in small groups
  4. Never ship an answer file that contains disk-wipe instructions without testing it — in a VM first, always. A correct file with the wrong disk number erases data completely silently

🎥 Watch the Complete Video Guide

Every checkbox, removal and bypass option from this page is shown live in the full video — watch it end to end before you build your own ISO.

▶️ Watch Full Video
❓ Frequently Asked Questions

Why did my answer file get ignored completely?

The three usual causes are the file name (it must be exactly autounattend.xml), the location (root of the install media, not inside a folder), and settings placed in a pass Setup does not read for that stage. Check those before rewriting anything.

Do I need all seven passes in my file?

No. A typical deployment file uses windowsPE, specialize and oobeSystem only. Passes you omit simply run with defaults — the file only overrides what it actually contains.

Can the answer file create a local account and skip the Microsoft account screens?

On many builds, yes — the oobeSystem pass can define a local user and hide the online account screens. Microsoft adjusts OOBE behaviour between builds, so test on your exact build; the bypass page in this series covers the additional registry route.

This guide is based on the Technical Anshu video on building your own Windows ISO and removing unwanted components • Stuck on a step? Ask in the video comments — you will get help 🙏