Windows Server 2025 on Cosmin.us

Configuring Cloudbase-Init for Windows Server 2025 on VM Service

Cosmin Trif — Tue, 03 Nov 2026 12:05:00 -0600

I leave the host name and IP address out of my Windows Server 2025 image. For a VM Service deployment, I configure Cloudbase-Init inside Windows to read VMware GuestInfo through VMware Tools. My VCF Automation 9.1 All Apps blueprint supplies the values when someone requests a VM.

Configure Cloudbase-Init inside Windows

On the existing Windows image, install VMware Tools with rpctool.exe. I used Tools 13.1.0 and the Cloudbase-Init x64 MSI. These installer settings select the Administrator account, disable metadata password injection and run the service as LocalSystem:

msiexec.exe /i .\CloudbaseInitSetup_1_1_8_x64.msi /qn /norestart `
 USERNAME=Administrator USERGROUPS=Administrators INJECTMETADATAPASSWORD=FALSE RUN_SERVICE_AS_LOCAL_SYSTEM=1

Set the cloudbase-init service to Automatic. Both configuration files below are in C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\.

cloudbase-init.conf (Windows service). Set the metadata service to VMware GuestInfo. For this request I need the plugins that set the host name, configure the NIC and process cloud-config user data:

[DEFAULT]
username=Administrator
groups=Administrators
inject_user_password=false
first_logon_behaviour=no
metadata_services=cloudbaseinit.metadata.services.vmwareguestinfoservice.VMwareGuestInfoService
plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,cloudbaseinit.plugins.common.networkconfig.NetworkConfigPlugin,cloudbaseinit.plugins.common.userdata.UserDataPlugin
allow_reboot=true
stop_service_on_exit=false

[vmwareguestinfo]
vmware_rpctool_path=%ProgramFiles%\VMware\VMware Tools\rpctool.exe

cloudbase-init-unattend.conf (Windows specialize pass). Use the same GuestInfo source and Tools path, but run only the host name plugin. The Windows service handles networking on first boot.

[DEFAULT]
metadata_services=cloudbaseinit.metadata.services.vmwareguestinfoservice.VMwareGuestInfoService
plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin
allow_reboot=false

[vmwareguestinfo]
vmware_rpctool_path=%ProgramFiles%\VMware\VMware Tools\rpctool.exe

Unattend.xml. In the Sysprep answer file used by your image, check the Microsoft-Windows-Deployment component of the specialize pass. Its RunSynchronous list needs this command once. If you already have other commands, use the next free order number.

<RunSynchronousCommand xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" wcm:action="add">
 <Order>1</Order>
 <Path>cmd.exe /c ""C:\Program Files\Cloudbase Solutions\Cloudbase-Init\Python\Scripts\cloudbase-init.exe" --config-file "C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init-unattend.conf" &amp;&amp; exit 1 || exit 2"</Path>
 <WillReboot>OnRequest</WillReboot>
</RunSynchronousCommand>

Pass the requested address through GuestInfo

In the blueprint’s CCI.Supervisor.Resource for the VM, these fields live under properties.manifest.spec. I set imageName to my generalized Windows image and used network to map the catalog inputs below. VM Operator writes the host name and NIC settings to guestinfo.metadata, where Cloudbase-Init matches the NIC by MAC address.

network:
 hostName: ${input.vmName}
 interfaces:
 - name: eth0
 network:
 apiVersion: crd.nsx.vmware.com/v1alpha1
 kind: Subnet
 name: ${input.subnetName}
 macAddr: ${input.macAddress}
 addresses:
 - ${input.ipAddress}/${input.prefixLength}
 gateway4: ${input.gateway}
 nameservers: ${input.dnsServers}

To send cloud-config to Windows, I selected cloudInit under spec.bootstrap. This excerpt tells VM Operator where to read the Administrator password: the encrypted catalog input supplies the password key of a per-VM Secret. The resulting cloud-config travels in guestinfo.userdata, which UserDataPlugin processes separately from the network metadata.

bootstrap:
 cloudInit:
 cloudConfig:
 users:
 - name: Administrator
 passwd:
 name: ${input.vmName}-admin
 key: password

For ws25-cbi-01 I requested 172.30.10.20/27 with MAC 00:50:56:3c:0a:14. Here is the decoded network metadata for that request:

I set wait.fields on the VCF Automation resource to wait for status.network.primaryIP4 to match the requested IP. VMware Tools also reported 172.30.10.20/27 on the Windows NIC with DHCP off. I verified the network settings; I did not test an Administrator login.

Windows Server 2025 on VM Service: Static IPs with Sysprep

Cosmin Trif — Tue, 03 Nov 2026 12:00:00 -0600

I wanted a Windows Server 2025 VM requested from the VCF Automation catalog to get its own host name and static IP, using the settings from my saved vCenter customization spec, ws2025-static. My Windows image had VMware Tools 13.1.0 running. I left it ungeneralized so vSphere could run Sysprep on each new VM.

Where does the customization spec name go?

VM Service has no field that takes a saved vCenter customization spec by name. My VCF Automation 9.1 All Apps blueprint uses a CCI.Supervisor.Resource with a VirtualMachine manifest. Its Sysprep provider takes the Windows settings themselves.

I used the spec name when writing the blueprint. For example, this PowerCLI lookup shows where my /27 default came from:

$spec = (Get-View CustomizationSpecManager).GetCustomizationSpec('ws2025-static').Spec
$spec.NicSettingMap[0].Adapter.SubnetMask # 255.255.255.224

Changing ws2025-static in vCenter later doesn’t update this blueprint. If you’re using a Cloud.vSphere.Machine instead, you can declare inputs.customizationSpec as a string and set customizationSpec: ${input.customizationSpec} under that machine’s properties. That’s the resource that can use the saved name directly.

Blueprint inputs for guest customization

The saved spec used the VM name as the computer name and prompted for an IP. In the catalog request I supplied the VM name, IPv4 address, a unique MAC for the NSX subnet, and an Administrator password. I used the spec’s subnet mask, gateway and DNS as form defaults. These are the relevant top-level inputs:

inputs:
 vmName: {type: string, maxLength: 15}
 ipAddress: {type: string}
 macAddress: {type: string}
 adminPassword: {type: string, encrypted: true, minLength: 12}

 subnetName: {type: string, default: win-static}
 prefixLength: {type: integer, default: 27}
 gateway: {type: string, default: 172.30.10.1}
 dnsServers:
 type: array
 items: {type: string}
 default: [10.1.1.1]

How the inputs reach Windows

Inside properties.manifest.spec, network connects the NIC to my NSX VPC subnet with static allocation. The same block tells guest customization which host name and address to apply:

network:
 hostName: ${input.vmName}
 interfaces:
 - name: eth0
 network:
 apiVersion: crd.nsx.vmware.com/v1alpha1
 kind: Subnet
 name: ${input.subnetName}
 macAddr: ${input.macAddress}
 addresses:
 - ${input.ipAddress}/${input.prefixLength}
 gateway4: ${input.gateway}
 nameservers: ${input.dnsServers}

I kept two values from the spec fixed in bootstrap.sysprep.sysprep: the WORKGROUP workgroup and time zone 35 (Eastern Standard Time). The Administrator password changes per request: the blueprint writes ${input.adminPassword} to the password key of a Secret named ${input.vmName}-admin. Sysprep reads that key:

bootstrap:
 sysprep:
 sysprep:
 guiUnattended:
 autoLogon: false
 password:
 name: ${input.vmName}-admin
 key: password
 timeZone: 35
 identification:
 joinWorkgroup: WORKGROUP

When I requested ws25-gosc-02 with 172.30.10.11, vCenter recorded CustomizationSucceeded. VMware Tools reported 172.30.10.11/27 on the Windows NIC with DHCP off.