文章探讨了在2023年圣诞节假期后，Windows Server 2022虚拟机在通过VM Customization Specification进行部署时遇到的故障。虚拟机未能正确设置计算机名和加入Active Directory域。经过调查，发现问题出在sysprep进程，特别是微软Windows更新后导致的问题。文章提供了通过修改注册表来延迟VMware Tools启动的解决方案，从而解决了此问题。

🐛 问题的出现：在2023年圣诞节假期后，作者发现从模板部署的Windows Server 2022虚拟机无法完成客户机自定义过程，导致计算机名未正确设置，也未能加入Active Directory域。

🔍 问题定位：通过检查sysprep日志文件（C:\Windows\System32\Sysprep\Panther\setupact.log和setuperr.log），确认sysprep进程虽然被调用并运行，但关键部分未能执行，导致配置失败。

💡 问题根源：问题与最近应用于模板的一系列微软Windows更新有关，特别是KB5034129、KB5033914等更新。这些更新导致了客户机操作系统重新定制操作触发了重启，中断了Sysprep自定义操作。

🛠️ 解决方案：参考VMware KB82615，通过修改注册表来延迟VMware Tools的启动，给客户机操作系统重新定制过程提供一个缓冲期。具体是在注册表中添加DelayedAutostart并启用，同时设置AutoStartDelay为20秒，从而解决问题。

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/2024Long 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/2024Cumulative 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.