TL;DR#
Setting up a proper Windows testing environment for ICS/OT security tool development goes beyond spinning up a single VM. You need multiple Windows versions, from legacy Windows 7 through Server 2022, templated, sysprepped, and network-isolated so you can rapidly deploy clean test systems and tear them down when you’re done. This post summarizes my experience building a Proxmox-based development lab with automated VM management for testing Sysmon configurations and security scripts across every supported Windows version. The complete setup guide is available as a PDF download. We document these projects to both remember what we have done and also help others with similar projects.
AI-Assisted Planning#
Like the Framework Desktop build, this entire lab was planned and troubleshot with assistance from Claude, Anthropic’s AI assistant. The build conversation covered Proxmox networking, Windows template creation, Sysprep quirks across multiple Windows versions, and debugging issues like TLS failures on Windows 7, Sysmon’s silent failure modes in PowerShell, and Win11’s EFI clone boot problems. When something didn’t work as expected, as they typically do, Claude helped diagnose the problem and propose solutions.
The resulting setup guide captures every workaround and lesson learned so you don’t have to discover them yourself.
Why a Multi-Version Windows Lab?#
ICS/OT environments run everything. Windows 7 is still common in control system networks, Server 2016 runs plenty of historians and HMI servers, and newer deployments are moving to Server 2022 and Windows 11. When you’re developing security monitoring configurations or assessment scripts, you need to verify they work across all of these and not just the latest version on your laptop.
A Proxmox-based lab with templates and full clones gives you repeatable, isolated test environments. Clone a template, test your Sysmon config, verify the results, halt the clone, and move to the next Windows version. The Proxmox API lets you script this entire cycle, and with SSH access to each VM, you can push configurations and collect results without touching the Proxmox or Windows system GUIs.
Lab Architecture#
The lab runs on a two-node Proxmox cluster (Intel NUCs) with isolated virtual networking:
- Physical LAN (192.168.1.0/24) — the home/office network where the Proxmox cluster and the development server live
- Dev Network (vmbr1, 192.168.100.0/24) — an isolated virtual bridge with NAT to the internet, hosting all development VMs
- Future Networks — additional bridges for Active Directory labs, AI workloads, and other pool types
The development server on the physical LAN reaches the VMs via a static route through the Proxmox host, which acts as the router between networks. Each VM gets a static IP and SSH access with key-based authentication.
The resource constraint is real — the NUCs can’t run all VMs simultaneously. The test workflow starts one VM, runs the test via SSH, shuts it down, and moves to the next. The Proxmox API makes this scriptable.
Template Build Process#
Each Windows version gets a template VM built through a consistent process:
- Install Windows with VirtIO drivers (SCSI driver loaded during setup)
- Install VirtIO guest tools and QEMU Guest Agent
- Run Windows Update
- Disable Windows Defender real-time protection (isolated test VMs only)
- Install OpenSSH Server and configure for automatic start
- Install Sysmon (service only, no configuration — configs are pushed during testing)
- Sysprep with
/generalize /oobe /shutdownfor unique SIDs on clones - Convert to template (irreversible, read-only)
Clones are created as full clones (not linked) and assigned to the appropriate pool. This keeps each clone independent — no dependency on the template’s disk.
Lessons Learned the Hard Way#
Every Windows version had its own surprises. Here are the highlights:
Windows 7 is the most labor-intensive. Fresh installs can’t reach Windows Update or browse the web because they default to TLS 1.0 and have expired root certificates. You have to manually bootstrap three KB updates (KB3020369, KB3125574, KB3140245) and apply TLS 1.2 registry keys before anything network-related works. The latest VirtIO drivers do not work and you need to manually install all VirtIO drivers from a very old version of these drivers. And the current Sysmon doesn’t support Win7 at all; you need v10.42, which is only available via the Wayback Machine. (Another good reason to update, if possible).
Windows 11 requires proper configuration of TPM 2.0, Secure Boot (Pre-Enroll Keys), and UEFI. Miss any of these in the Proxmox VM settings and the installer refuses to proceed. BitLocker may silently encrypt the disk before you can Sysprep, making clones unbootable. Disable BitLocker immediately after reaching the desktop. And pre-installed apps can block Sysprep — you have to identify them from the log file and remove them one at a time.
Server 2016 needs PowerShell configured for TLS 1.2 via .NET Framework registry keys, or you’ll get silent failures from Invoke-WebRequest, NuGet, and Windows Update.
Server editions have a Shutdown Event Tracker that prompts for a reason on every shutdown, blocking remote and automated shutdowns. Disable it via Group Policy before Sysprep.
Downloaded files from the internet are blocked by Windows by default. Sysmon, configuration files, and update packages all need Unblock-File before they’ll execute properly.
And, more… Much, Much, More….
Download#
The complete setup guide with step-by-step instructions is available here: Proxmox Development Lab Setup Guide (PDF)
Go forth and do good things, Don C. Weber