Windows server builds on Azure through runbooks and Packer images

The problem

Windows server delivery ran inside a regulated cloud environment, but builds depended on manual request handling, manual logins after provisioning, and image inputs that operators had to remember. Each server build carried steps that lived outside the delivery path.

This brownfield starting point also guides our Azure cloud engineering work.

How we worked

1. Assess. The starting point was manual request handling, post-build steps run by hand, and image inputs spread across the vSphere and Azure build paths.

2. Codify. We built Packer baselines for Windows Server 2019 and 2022 with PowerShell provisioning, bootstrap files, certificate setup, Windows Update passes, restarts, and cleanup. The Azure path used Packer azure-arm builds and image-gallery publication, so provisioning started from a governed image baseline.

3. Operationalize. Windows VM provisioning runbooks replaced manual request handling. They used managed identity with explicit Az context selection, and handled VM size and image, region and zone placement, network targeting, disk encryption, tagging, boot diagnostics, and domain placement. Post-build work ran through Azure VM extensions instead of manual logins: disk preparation, Windows activation, BitLocker cleanup, domain join, environment setup, and the configuration-management handoff. The workflow removed the temporary extensions after they completed.

4. Enable. Image definitions, runbook parameters, and post-build steps became repeatable inputs in the delivery path, instead of knowledge held by individual operators.

The outcome

Windows server builds on Azure started from governed image baselines, ran post-build configuration through the delivery path instead of manual logins, and used managed identity so fewer long-lived automation credentials were needed.