Automate Windows Installation in a Modern IT Environment with the Unattend.xml file

The Unattend.xml file , also known as an answer file, allows for complete automation of the installation and configuration of the Windows operating system, eliminating the need for manual intervention during deployment. This guide, based on official Microsoft documentation and practical experience, explains in detail the purpose, structure, key components, and best practices for using the Unattend.xml file, with a special emphasis on enterprise deployments, security, and maintenance.

Overview and purpose of the Unattend.xml file

What is Unattend.xml?

Unattend.xml is an XML configuration file that contains answers to questions and options that Windows Setup typically asks the user during installation. This file allows you to automate the entire installation process, from language selection and disk partitioning to user account creation and driver integration.

Using the Unattend.xml file has a number of advantages:

• Speed ​​and efficiency : Install Windows on multiple computers simultaneously, without the need for manual data entry.
• Consistency : All systems are configured identically, which makes maintenance and support easier.
• Automation : Ability to integrate additional scripts, drivers and applications.
• Error Reduction : Eliminating the human factor during implementation.
• Security : Centralized control over settings and user accounts.

Where is Unattend.xml used?

The Unattend.xml file is used in various scenarios:

• Mass deployment in a business environment (via MDT, SCCM/ConfigMgr, Autopilot)
• OEM and integrator installations
• Preparing custom Windows images
• Automation of installations in virtual environments (VMware, Hyper-V, VirtualBox, Proxmox)
• Testing and development (development/testing laboratories)

Configuration passes in Unattend.xml

Overview of configuration phases

The Unattend.xml file is structured around so-called configuration passes – the stages that Windows Setup goes through during installation. Each stage allows you to configure certain settings:

Detailed explanation of the phases:

• windowsPE : Allows automation of the earliest steps of the installation, including language, disk partitioning, product key entry, and EULA acceptance. Critical boot drivers required for disk or network access are often added here.
• OfflineServicing : This phase is used to integrate drivers, language packs, and update packages into an offline image using DISM. It is ideal for preparing the master image before deployment.
• generalize : Removes unique identifiers (SIDs, drivers) from the image, preparing it for cloning to multiple computers. Key for enterprise deployments where Sysprep is used.
• specialize : The first phase after the image is installed on a new computer. This is where the computer name, network settings, domain join, regional settings, and other hardware-specific configurations are set.
• auditSystem and auditUser : Used in audit mode for additional configuration, testing, and installation of drivers or applications before the system enters the OOBE phase.
• oobeSystem : The last stage before the user uses the system for the first time. This is where user accounts are created, the OOBE experience, localization, and other user settings are set.

Key parts and elements of the Unattend.xml file

Structure of the Unattend.xml file

The Unattend.xml file is hierarchically structured and contains multiple sections, the most important of which are:

<settings pass=windowsPE>
<settings pass=offlineServicing>
<settings pass=specialize>
<settings pass=oobeSystem>
<settings pass=generalize>
<settings pass=auditSystem>
<settings pass=auditUser>

Within each section are components (e.g. Microsoft-Windows-Setup, Microsoft-Windows-Shell-Setup, Microsoft-Windows-PnpCustomizationsNonWinPE), and each component contains elements that define specific settings.

Most commonly used components and elements

Microsoft-Windows-Installation (windowsPE)

• Disk Configuration : Defines disk partitioning and formatting.
• ImageInstall/OSImage : Specifies which image and on which partition Windows is installed.
• User data : Product key entry, EULA acceptance, organization.
• ComplianceCheck : Hardware compatibility check.

Microsoft-Windows-International-Core-WinPE (windowsPE)

• UILanguage, InputLocale, SystemLocale, UserLocale : Language, keyboard, regional settings.

Microsoft-Windows-Shell-Setup (specialization, oobeSystem)

• ComputerName : Computer name.
• WeatherZone : WeatherZone.
• Registered Organization/Owner : Owner information.
• OEM Information : OEM information, logo, support.
• User accounts : Creating local accounts.
• OOBE : Configure the OOBE screen (hide EULA, online account, etc.).
• AutoLogon : Automatic user login.
• FirstLogonCommands : Scripts that are executed on first logon.

Microsoft-Windows-PnpNonWinPE (Offline Servicing) Customizations

• DriverPaths : Driver integration immediately after installation.

Microsoft-Windows-Implementation (auditUser, specialize)

• RunAsynchronousCommand / RunSynchronousCommand : Running scripts and commands during deployment.

Create and edit the Unattend.xml file using Windows System Image Manager (WSIM)

Introduction to Windows System Image Manager

Windows System Image Manager (WSIM) is not your Photos app. It is an official Microsoft tool, part of the Windows Assessment and Deployment Kit (ADK), designed to create and validate Unattend.xml files. WSIM allows for visual addition of components and settings, syntax validation, and generation of catalog files for specific Windows images.

The process of creating the Unattend.xml file

Steps:

1. Starting WSIM and opening the Windows image (install.wim)
   Open WSIM, select File > Select Windows Image , and select the appropriate install.wim file.
   If necessary, WSIM will generate a catalog file (.clg) for the selected image.
2. Creating a new response file
   File > New Answer File .
3. Adding components to the appropriate configuration passes
   Find the desired component (e.g. Microsoft-Windows-Setup) and right-click to add it to the appropriate stage (e.g. windowsPE).
4. Configuring values ​​in the Properties panel
   For each component, enter the desired values ​​(e.g. language, partitions, product key).
5. Response file validation
   Tools > Validate Response File – WSIM checks the syntax and compatibility of the settings.
6. Save the response file
   File > Save Response File – required according to autounattend.xmlor unattend.xmldepending on the scenario.

Practical advice
Create and test Unattend.xml on a reference virtual machine before mass deployment.
Use validation in WSIM to avoid syntax and logic errors.
For different hardware configurations, create multiple variants of the Unattend.xml file.
Use versioning and documentation to track changes in response files.

Installation Automation: Autounattend.xml and File Locations

Difference between autounattend.xml and unattend.xml

• autounattend.xml : Used during the boot phase of the installation (windowsPE). It must be located in the root directory of the USB or media from which the installation is booted.
• unattend.xml : Used for later stages (e.g. OOBE, specialization), often copied C:\Windows\Panther during C:\Windows\System32\Sysprep deployment.

Locations where Windows Setup looks for an answer file

Windows Setup automatically searches the following locations (the order is important):

1. Root directory of USB or DVD media (autounattend.xml)
2. C:\Windows\Panther\unattend.xml
3. C:\Windows\System32\Sysprep\unattend.xml

To deploy from a USB, it is sufficient to copy autounattend.xml to the root directory of the USB. To deploy from a network or via DISM, unattend.xml is copied to the Panther folder or specified via the command line ( setup.exe /unattend:path\to\unattend.xml).

Disk partitioning and ImageInstall settings

Automating disk partitioning

Unattend.xml allows for fully automated disk partitioning and formatting via the DiskConfiguration section :

<DiskConfiguration>
  <Disk wcm:action=add>
    <DiskID>0</DiskID>
    <WillWipeDisk>true</WillWipeDisk>
    <CreatePartitions>
      <CreatePartition wcm:action=add>
        <Order>1</Order>
        <Type>EFI</Type>
        <Size>100</Size>
      </CreatePartition>
      <CreatePartition wcm:action=add>
        <Order>2</Order>
        <Type>MSR</Type>
        <Size>16</Size>
      </CreatePartition>
      <CreatePartition wcm:action=add>
        <Order>3</Order>
        <Type>Primary</Type>
        <Extend>true</Extend>
      </CreatePartition>
    </CreatePartitions>
    <ModifyPartitions>
      <ModifyPartition wcm:action=add>
        <Order>1</Order>
        <PartitionID>1</PartitionID>
        <Label>System</Label>
        <Format>FAT32</Format>
      </ModifyPartition>
      <ModifyPartition wcm:action=add>
        <Order>3</Order>
        <PartitionID>3</PartitionID>
        <Label>Windows</Label>
        <Letter>C</Letter>
        <Format>NTFS</Format>
      </ModifyPartition>
    </ModifyPartitions>
  </Disk>
</DiskConfiguration>

This configuration creates an EFI, MSR, and Windows partition on a GPT disk, formats them, and assigns drive letter C for the Windows partition.

Image Installation and Installation in

The ImageInstall/OSImage/InstallTo section determines which partition Windows is installed on:

< ImageInstall > 
  < OSImage > 
    < InstallTo > 
      < DiskID > 0 </ DiskID > 
      < PartitionID > 3 </ PartitionID > 
    </ InstallTo > 
  </ OSImage > 
</ ImageInstall >

For deployment on multiple hardware platforms, it is recommended to use the InstallToAvailablePartition option or dynamic partitioning scripts.

Automatic acceptance of the EULA agreement, entering the product key and selecting an image

Automatic acceptance of the EULA agreement and entry of the product key

The UserData section defines key information:

<UserData>
  <AcceptEula>true</AcceptEula>
  <ProductKey>
    <Key>VK7JG-NPHTM-C97JM-9MPGT-3V66T</Key>
    <WillShowUI>Never</WillShowUI>
  </ProductKey>
  <FullName>Amilma Digital</FullName>
  <Organization>Amilma</Organization>
</UserData>

• AcceptEula : Automatically accepts the license terms.
• ProductKey : Enters the installation key (can be generic for KMS activation).
• WillShowUI : Controls the display of the user interface during keystrokes (recommended: Never).

Image selection

If install.wim contains multiple images (e.g. Pro, Home, Education), the selection can be automated via MetaData :

<InstallFrom>
  <MetaData wcm:action=add>
    <Key>/IMAGE/NAME</Key>
    <Value>Windows 11 Pro</Value>
  </MetaData>
</InstallFrom>

Adding scripts and RunAsynchronousCommand in the auditUser phase

Automation of additional tasks

Using RunAsynchronousCommand and RunSynchronousCommand it is possible to run scripts and commands during deployment:

<RunAsynchronous>
  <RunAsynchronousCommand wcm:action=add>
    <Order>1</Order>
    <Path>C:\Scripts\InstallApps.cmd</Path>
    <Description>Instalacija aplikacija</Description>
  </RunAsynchronousCommand>
</RunAsynchronous>

• RunAsynchronousCommand : Executes multiple commands in parallel (pass-through for auditUser or specialize).
• RunSynchronousCommand : Executes commands sequentially, waiting for the previous one to complete.

Practical applications

• Automatic installation of applications and drivers
• Configuring a registry entry
• Deleting temporary files
• Copy of OEM logo and information

Offline Servicing and Unattended File Deployment via DISM

Integrating drivers and packages into an offline image

DISM (Deployment Image Servicing and Management) allows you to apply an Unattend.xml file to an image offline:

Dism /Image:C:\mount\windows /Apply-Unattend:C:\AnswerFiles\unattend.xml

The offlineServicing pass is used to integrate drivers, language packs, and update packages.
The DriverPaths section Microsoft-Windows-PnpCustomizationsNonWinPEallows you to copy a driver to a driver store image.

Limitations and recommendations

• The Unattend.xml file used with DISM should contain only the offlineServicing section.
• It is recommended to validate the file in WSIM before applying.
• DISM does not cache the answer file on the target computer - which is a security advantage.

Driver integration and PnP customization, not for WinPE

Driver integration immediately after installation

To integrate drivers that are not critical to system startup, the Microsoft-Windows-PnpCustomizationsNonWinPE section is used :

<Microsoft-Windows-PnpCustomizationsNonWinPE>
  <DriverPaths>
    <PathAndCredentials wcm:action=add wcm:keyValue=1>
      <Path>C:\Drivers</Path>
    </PathAndCredentials>
  </DriverPaths>
</Microsoft-Windows-PnpCustomizationsNonWinPE>

Drivers are copied to the driver store during offlineServicing or auditSystem passes.
For boot-critical drivers, PnpCustomizationsWinPE is used in the windowsPE phase.

Practical advice

• Organize drivers by hardware model.
• Test the implementation on all target models.
• For enterprise environments, automate driver integration via MDT/SCCM task sequences.

Security and risks when using the Unattend.xml file in a business environment

Challenges with sensitive data

The Unattend.xml file often contains sensitive data such as local administrator passwords, Wi-Fi keys, and other confidential information. A serious security flaw has been discovered in recent versions of Windows (e.g. 11 24H2):

• After installation, copies of the Unattend.xml and unattend-original.xml files remain in the C:\Windows\Panther\.
• The unattend-original.xml file may contain the administrator password in clear text.
• These files can be read by any local user, which allows for privilege escalation and compromise of the entire network.

Recommended protective measures

• Automatically delete Unattend.xml and unattend-original.xml files after installation (via script or GPO).
• Using LAPS (Local Administrator Password Solution) to automatically generate and rotate unique passwords on each computer.
• Regular security audits : Verify the existence of these files and ensure that administrator passwords are protected.
• Avoid entering passwords in clear text whenever possible; use hashed or encrypted values.

Practical example of a deletion script

del /f /q C:\Windows\Panther\unattend.xml
del /f /q C:\Windows\Panther\unattend-original.xml

You can add this script as the last step in the deployment process or via SetupComplete.cmd.

Best practices for implementation and versioning in enterprises

Version and documentation

• Versioning Unattend.xml files : Every change should be documented and versioned (e.g. via Git or another VCS).
• Centralized storage and access control : Restrict access to answer files to authorized individuals only.
• Testing on reference machines : Every new version must be tested before mass deployment.

Modularity and maintenance

• Modularize configurations : Separate settings by functionality (e.g. drivers, applications, user accounts).
• Create templates for different scenarios : Different Unattend.xml files for different departments, locations, or hardware platforms.
• Automate deployment through tools like MDT, SCCM, Autopilot .

Validation and troubleshooting

• Regularly check Unattend.xml via WSIM .
• Tracking Records : Key records are located setupact.logboth in and during setuperr.logthe PE phase . C:\Windows\PantherX:\Windows\Panther
• Automate error tracking and reporting .

Integration with deployment tools: MDT, SCCM/ConfigMgr, Autopilot

Microsoft Deployment Toolkit (MDT)

• MDT uses Unattend.xml for each task sequence.
• It enables centralized deployment management, integration of drivers, applications, and scripts.
• The Unattend.xml file can be customized for each deployment scenario via WSIM or directly from the MDT console.

System Center Configuration Manager (SCCM/ConfigMgr)

• SCCM uses Unattend.xml in the OSD task sequence.
• OOBE and other settings can be configured directly through task sequence steps, which can override settings from the Unattend.xml file.
• It is recommended to test the interaction between TS and the Unattend.xml file to avoid collisions.

Windows Autopilot

• Autopilot uses Unattend.xml for advanced automation of the OOBE phase, specifically for self-deploying and reconfiguring devices before handing them over to the end user.
• It is recommended to dynamically generate the Unattend.xml file through the deployment tool.

Storage and maintenance of OEM information and customization (OEMInformation)

Original Equipment Manufacturer (OEM) Information Section

The OEMInformation section in the Unattend.xml file allows OEM data to be displayed in the Control Panel and Settings application:

<OEMInformation>
  <SupportProvider>Amilma Digital Help Center</SupportProvider>
  <SupportURL>https://help.amilma.digital</SupportURL>
  <Logo>C:\Windows\System32\oemlogo.bmp</Logo>
</OEMInformation>

• SupportProvider : Name of the support or manufacturer.
• Support URL : Support URL.
• Logo : Path to BMP logo (maximum 120x120 px, 32-bit color).

Practical recommendations

• Prepare the logo in advance and copy it to the image during implementation.
• Update your original equipment manufacturer (OEM) information when changing brands or support.
• This information is useful for customer support and end users.

Examples of ready-made Unattend.xml files and generators

Online generators

• Schneegans.de Unattend Generator : Interactive web tool to generate autounattend.xml files for Windows 10/11, including the latest versions (24H2, 25H2). Allows configuration of languages, partitions, user accounts, drivers and scripts.
• DISMTools : A desktop application with a wizard for quickly creating answer files, suitable for beginners and advanced users.

Practical examples

• GitHub repositories : Contains sample Unattend.xml files for various scenarios (VMware, Hyper-V, physical machines, enterprise deployment).
• Microsoft Learn : The official documentation contains XML examples for each component and scenario.

Troubleshooting and validating the Unattend.xml file (logs, setupact.log, setuperr.log)

Key diagnostic records

Validation and debugging

• WSIM validation : The first step in detecting syntax and logic errors.
• View logs : Analyze setupact.log and setuperr.log for detailed error information.
• Common errors : Wrong partition order, incompatible values, wrong paths to drivers or scripts, collision between InstallTo and InstallToAvailablePartition.

Retaining settings via reset/refresh and Retaining settings via recovery

Challenges when resetting and refreshing the system

Some settings from the Unattend.xml file may be lost during reset/refresh operations (e.g. via Windows Recovery Environment). To save the settings:

• Use scripts that are executed after the recovery process .
• Implement critical settings via Group Policy where possible .
• Follow Microsoft's recommendations for maintaining settings through recovery .

Practical examples of use in business scenarios

Mass adoption of new computers

• Preparing a reference image with all necessary applications and drivers.
• Creating an Unattend.xml file that automatically partitions the disk, installs Windows, creates a local administrator, and joins the computer to a domain.
• Deployment via MDT or SCCM, with automatic deletion of the Unattend.xml file after installation for security reasons.

Customized image for different departments

• Different Unattend.xml files for each department (e.g. sales, development, support), with specific applications and settings.
• Centralized control through shared deployment and versions.

Automation in virtual environments

• Using the Unattend.xml file to automatically install Windows on virtual machines (VMware, Hyper-V, Proxmox).
• Integration of VMware tools, VirtIO drivers and other specific components via offline service pass.

Maintaining security and compliance

• LAPS implementation for automatic rotation of local administrator passwords.
• Regular audits and monitoring of the existence of sensitive files after implementation.
• Automate the deletion of Unattend.xml files via SetupComplete.cmd or GPO.

Unattend.xml as the basis of modern Windows automation

Using the Unattend.xml file is an indispensable practice for every IT professional and system administrator who wants to achieve high efficiency, consistency, and security when deploying Windows operating systems. A properly structured and maintained Unattend.xml file enables complete automation, error reduction, and centralized control over all aspects of installation and configuration.

Key recommendations:

• Always check and test Unattend.xml before mass deployment.
• Restrict access to response files and regularly delete sensitive files after installation.
• Follow security recommendations and use tools like LAPS to protect administrator accounts.
• Document and version all configuration changes.
• Leverage tools like MDT, SCCM, and Autopilot for centralized deployment management.

By following these guidelines, Unattend.xml becomes a powerful tool for professional, secure, and scalable automation of Windows deployments in any business environment.