After returning to the lab from Christmas 2023 break, I noticed that a significant number of the Microsoft Windows Server 2022 virtual machines I was deploying from template were failing to complete the guest customization process as defined by a VM Customization Specificiation – one that I had been using for quite a long time. Symptoms were the guests were not assuming their newly assigned computer name and were not joining the Active Directory domain in the lab. After verifying the health of the Active Directory domain, I felt the sysprep process was failing at some point.
I hadn’t looked at sysprep log files in eons. VMware KB2001932 Locations of sysprep log files reveals their location. For Windows Server 2022, that’s going to be the setupact.log and setuperr.log files located in C:\Windows\System32\Sysprep\Panther\.
What I found is that sysprep was being invoked and was running. However, without getting into specifics, it a critical portion of it was failing and not being executed. Not surprisingly, this is the reason the computer name wasn’t being changed, the computer wasn’t being joined to the Active Directory domain, the time zone wasn’t being set, etc.
But what was the cause? Why the recent change in behavior which had been rock solid for… well since forever. Well I know of one recent change: A batch of Microsoft Windows Updates had been applied to the template:
- Security Update for Microsoft Windows (KB5034129)
- Release Date 1/9/2024
- Long list of security updates
- Servicing Stack 10.0.20348.2200
- Confusion as to what this specific version is, when it was released, and what it contains
- Update for Microsoft Windows (KB5033914)
- Release Date 1/9/2024
- Cumulative Update for .NET Framework 3.5 and 4.8 for Windows Server 2022
Network rules in this particular lab environment require patching and provide no allowance for running unpatched Windows operating systems.
I happened along VMware KB82615 Sysprep Fails for Linked Clones after Installing Latest Windows Patches. Although it addresses VMware Horizon 7 and 8 linked clones only, there was a hope and a prayer as I read through it.
Cause:
The problem tends to manifest when installing the latest windows patches. New behaviour seen after installing the new patches, the guestOS-respecialize operation is triggering the reboot operation when it detects the hardware. The triggered reboot operation is interrupting the Horizon Sysprep customization operation and that is causing an issue.
Not sure if this is my specific case but it’s a lab workload and I’m willing to attempt the workaround.
Workaround:
Add in a delayed start to tools to allow a grace period for the guestOS-respecialize process to complete
The delay interval may vary based on the GuestOs-Image and the interval setting can be modified using registry settings. These registry changes can be set in the parent VM and provisioned out as as a fresh snapshot to your impacted pools.[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VMTools]
“DelayedAutostart”=dword:00000001 ————->DelayedAutoStart Enabled
“AutoStartDelay”=dword:00000014 ————->20 secs(in decimal)
Although VMware Tools takes longer to start, this solved the problem.
