Custom offline ISO Windows deployment method as a packer alternative

Background

For 2022, it was time to start using the packer automation I learned / wrote about in 2022, however, when I first tried to use it with my first 2 clients, it failed, in each case, for a different reason. On a third attempt to use it, I didn’t have access to the client’s environment, so had to talk the client’s on-site staff through filling out the required entries in the related packer XML/JSON/HCL files. By the time we were done filling out verifying the details, 30 mins had elapsed, the avg time to build a new Win 1x, Win Server 20xx image with windows updates is about 25 mins. At this point, I was 0/3 on using packer for my client work. As per this post, I’m often only with a client for 5-10 business days, burning an hour or more troubleshooting / prepping packer where it won’t be used again is not a good use of time. As such, the offline/custom ISO method was born!

This blog post will describe how I made it work, as of April 5, 2022, i’m 3/3 on new deployments with the new method. Sorry, Packer bros

Comparison of packer vs custom offline ISO method

For many years, windows installations have been driven by esoteric config file called ‘autounattend.xml’. For my packer based methods, I included samples, my new offline method also uses these files. however, the key difference is in the work flow:

Packer method

  • You download the latest Windows ISO to your desktop: 10 mins
  • You upload the ISO to the Hypervisor datastore: 10 mins
  • Packer > Creates VM on Hypervisor ( I only got it working on VMware env): 30 seconds
  • Packer copies over autounattend.xml / ps1 scripts to newly created shell: 10 seconds
  • Windows install starts: 10 seconds
  • Packer waits for WinRM to be enabled on new windows install: 15 mins
  • Packer shuts down VM: 10 seconds
  • You boot the VM again to apply any run once / scheduled tasks you set in previous steps: 15 minutes

All of the above is 100% dependent on properly formatted Packer JSON/HCL files, one mistake, even a lowercase/UPPERCASE character and your build is hooped

Let’s look at the method i’m now using for all my builds, which is a custom ISO injected with all the same scripts I was using on my packer-based builds

  • You download the latest Windows ISO to your desktop: 10 mins
  • You create a shell on the hypervisor ( tested as of today on VMware/Nutanix): 2 mins
  • You inject the latest window ISO with the required custom files (hypervisor drivers/XML/PS scripts): 5 mins
  • You upload the custom ISO to the Hypervisor datastore: 10 mins
  • You start the shell and boot it to custom ISO: 10 seconds
  • The rest is completely automated, as well, you don’t have to edit JSON/HCL configs, deal with network / firewall issues / or type-os where you or the client chose the wrong datastore / host / network / etc: 15 mins
  • Time to completion: Roughly the same, the difference, no 🙉🙊🐵business to deal with

The process / steps to get it done

  • Download ISO for Win 10 / Server 2019 / Server 2022 on your jump server / desktop, ensure you’ve got a fast link to your Nutanix Prism/VMware vCenter, don’t do this over VPN, son!
  • Mount ISO on your desktop
  • Run DISM to capture IMAGE INDEX as per Take Inventory of an Image or Component Using DISM | Microsoft Docs, this value will be required to amend the autounattend.xml that we will inject into the custom ISO
  • Dism /Get-ImageInfo /imagefile:D:\sources\install.wim (PATH TO YOUR WIM)
  • Download a sample Win 10/server autounattend.xml from my git hub here:

    https://github.com/getvpro/Standard-WinBuilds/tree/master/Offline_Builds/Autounattend_xml
  • Open it with a proper text editor: notepad3, VS code, NotePad++ , etc
  • CTRL+H to search/replace through all entries that state “CHANGE ME”, password / organization, save it
  • Search for IMAGE/INDEX, amend as required based on above screenshot, each index represents a different type of OS install, choose the one you want so you don’t have to do it twice
  • Install AnyBurn: https://www.anyburn.com/download.php
  • Open AnyBurn, brose to the ISO you downloaded, choose EDIT ISO
  • Open Powershell as admin and run the following

new-item -ItemType Directory -Path c:\admin
new-item -ItemType Directory -Path C:\admin\Offline_ISO
new-item -ItemType Directory -Path C:\admin\Offline_ISO\hypervisor_drivers
new-item -ItemType Directory -Path C:\admin\Offline_ISO\Langpack
new-item -ItemType Directory -Path C:\admin\Offline_ISO\Scripts

  • Upload ISO to hypervisor datastore
  • Start VM and ensure it’s set to boot to the ISO you uploaded

The rest of the install will proceed in a similarly automated fashion to the packer business. HyperVisor drivers for VMware / Nutanix / Citrix Xen Hypervisor will be installed, some basic post-windows install tasks will be run, including installing any language .cab files you might have populated into the Lang_Pack folder. When this part is done, scheduled tasks to cover starting / monitoring the windows update process will be run

That’s it!

As I said, my last 3 projects I’ve used this, in each case, I was able to finish my work early/on-time

Owen



One thought on “Custom offline ISO Windows deployment method as a packer alternative

  1. Could you explain the steps where you edit iso and run those Powershell commands? Are those folders being creating in the ISO you are editing? Where are you injecting the drivers and updates?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: