Windows Unattended Provisioning

Problem

A working Autounattend.xml can automate Windows installation, but it is not automatically safe to reuse, publish, or operate at scale.

An answer file may contain local administrator passwords, Wi-Fi material, domain-join credentials, environment-specific paths, and setup behavior that remains active after installation. Copying the same operational file between deployments also makes credential rotation, review, validation, and incident response harder.

The engineering problem was therefore broader than unattended installation: how can a validated Windows setup be converted into a reusable provisioning pipeline without placing production secrets in source control?

Solution

Windows Unattended Provisioning separates the public source tree from the sensitive deployment artifact.

The repository contains a sanitized compressed answer-file template, environment configuration examples, PowerShell build and endpoint scripts, validation logic, security guidance, and bilingual documentation. A trusted administrator supplies the delegated domain-join credential and provisioning Wi-Fi password only during a local build.

The build process then creates a deployment-specific output/Autounattend.xml, generates a unique bootstrap Administrator password when one is not supplied, validates the XML and embedded scripts, and reports the output SHA-256.

The generated file is intentionally treated as sensitive deployment media. It is excluded from Git and must not be archived, emailed, or broadly shared.

Provisioning architecture

The workflow spans two execution boundaries.

Build-time boundary

On the trusted build workstation, Build-Autounattend.ps1:

1. loads non-secret environment configuration;
2. requests the delegated domain-join credential and Wi-Fi secret;
3. generates or accepts the bootstrap Administrator password;
4. embeds the first-logon, Hybrid Join, and cleanup scripts;
5. escapes values for PowerShell and XML contexts;
6. rejects unresolved placeholders and invalid XML;
7. writes the sensitive answer file and its SHA-256.

The public repository remains generic, while the generated deployment artifact becomes specific to one environment and deployment batch.

Endpoint-time boundary

During Windows Setup and first logon, the embedded scripts:

1. start the Wi-Fi service and request connection to the provisioning profile;
2. discover an Active Directory domain controller through DNS SRV records;
3. verify LDAP availability before attempting domain join;
4. join the device to the configured domain and organizational unit using Add-Computer;
5. register a deferred task for Hybrid Microsoft Entra join;
6. schedule cleanup after restart;
7. persist operational state and logs under C:\ProgramData\WindowsDomainProvisioning.

The Hybrid Join task retries Group Policy processing and the native Automatic-Device-Join workflow independently from the initial domain join.

Security controls

The project does not claim that the current v1 workflow eliminates secret exposure. Instead, it defines and reduces the exposure window through layered controls:

• production secrets are absent from the public repository;
• local configuration and generated output are ignored by Git;
• the domain-join account must be delegated only to the target OU;
• the bootstrap Administrator password is unique per build;
• deployment media is treated as short-lived sensitive material;
• answer files, Wi-Fi XML, credential-bearing scripts, and autologon values are removed after provisioning;
• operational logs are designed not to contain passwords or generated XML;
• Windows LAPS rotation is expected from Microsoft Intune after enrollment;
• failed domain join stops automatic restart, records failure state, clears autologon, and schedules cleanup.

Offline Domain Join is the planned architectural direction for reducing reusable credential exposure in a future version.

Validation and observability

Test-Autounattend.ps1 validates:

• XML parsing;
• unresolved placeholders;
• required embedded scripts;
• domain-join behavior markers;
• cleanup registration;
• known configuration warnings.

GitHub Actions performs the build with dummy credentials, validates the generated XML, and verifies that sensitive output and local configuration are not tracked.

On the endpoint, a non-secret state document records the provisioning phase using values such as:

• domainJoin: Running, Succeeded, or Failed;
• hybridJoin: Pending, Succeeded, Disabled, or WaitingForDomain;
• cleanup: Pending, Scheduled, or Succeeded;
• lapsManagement: IntunePolicy.

The complete workflow was validated on a corporate pilot device through Windows Setup, Active Directory domain join, Microsoft Entra registration, Intune policy processing, and Windows LAPS rotation.

Current limitations

Version 1.0.0 deliberately preserves parts of the tested answer-file baseline, including opinionated application removal, Windows requirement bypasses, Remote Desktop enablement, a temporary local standard account, and system-drive ACL changes.

These settings are not universal defaults. The template must be reviewed against the target organization’s security baseline, Windows release, hardware policy, and application inventory.

The current structural validator proves expected document and embedded-script properties, but it does not replace pilot deployment and negative testing in a representative environment.

Current state

The public repository includes:

• a sanitized compressed answer-file template;
• local build and validation scripts;
• domain join, Hybrid Join, cleanup, state, and logging workflows;
• example configuration;
• GitHub Actions validation;
• English and Brazilian Portuguese documentation;
• security policy, MIT license, changelog, and semantic versioning.

Version 1.0.0 is an operationally validated foundation for controlled Windows provisioning, not a universal zero-touch deployment product.