VMware has released a fix for this problem in the form of ESXi 7.0 Update 3k:
If you already face the issue, after patching the host to ESXi 7.0 Update 3k, just power on the affected Windows Server 2022 VMs. After you patch a host to ESXi 7.0 Update 3k, you can migrate a running Windows Server 2022 VM from a host of version earlier than ESXi 7.
We've been working lately to use HashiCorp Packer to standardize and automate our VM template builds, and we found a need to pull in all of the contents of a specific directory on an internal web server. This would be pretty simple for Linux systems using wget -r, but we needed to find another solution for our Windows builds.
A coworker and I cobbled together a quick PowerShell solution which will download the files within a specified web URL to a designated directory (without recreating the nested folder structure):
Connecting a deployed Windows VM to an Active Directory domain is pretty easy; just apply an appropriately-configured customization spec and vCenter will take care of it for you. Of course, you'll likely then need to move the newly-created computer object to the correct Organizational Unit so that it gets all the right policies and such.
Fortunately, vRA 8 supports adding an Active Directory integration to handle staging computer objects in a designated OU.
In the same vein as my script to automagically resize a Linux LVM volume to use up free space on a disk, I wanted a way to automatically apply Windows updates for servers deployed by my vRealize Automation environment. I'm only really concerned with Windows Server 2019, which includes the built-in Windows Update Provider PowerShell module. So this could be as simple as Install-WUUpdates -Updates (Start-WUScan) to scan for and install any available updates.
I was pretty excited to get WSL2 and Docker working on my Windows 10 1909 laptop a few weeks ago, but I quickly encountered a problem: WSL2 had no network connectivity when connected to my work VPN.
Well, that's not entirely true; Docker worked just fine, but nothing else could talk to anything outside of the WSL environment. I found a few open issues for this problem in the WSL2 Github with suggested workarounds including modifying Windows registry entries, adjusting the metrics assigned to various virtual network interfaces within Windows, and manually setting DNS servers in /etc/resolv.
Microsoft's Windows Subsystem for Linux (WSL) 2 was recently updated to bring support for less-bleeding-edge Windows 10 versions (like 1903 and 1909). WSL2 is a big improvement over the first iteration (particularly with better Docker support) so I was really looking forward to getting WSL2 loaded up on my work laptop.
WSL2 Step Zero: Prereqs You'll need Windows 10 1903 build 18362 or newer (on x64). You can check by running ver from a Command Prompt: