How to Create a Windows Server 2025 Standard Cloud-Init Template in Proxmox

Creating a Windows Server 2025 Cloud-Init template in Proxmox lets you deploy fully configured Windows virtual machines without manually setting the Administrator password or network configuration after every clone.

This step-by-step guide shows how to build a Windows Server 2025 Standard Proxmox template using Cloudbase-Init so Proxmox can automatically configure the Administrator password, static IPv4 address, gateway, DNS servers, and hostname when a new VM boots for the first time.

The process uses Proxmox’s native Windows Cloud-Init support with configdrive2, the VirtIO drivers, QEMU Guest Agent, Cloudbase-Init, and Microsoft Sysprep. Once the template is tested, the same workflow can be used for manual deployments or automated provisioning through the Proxmox API, WHMCS, Terraform, Ansible, or other provisioning systems.

What the Windows Server 2025 Cloud-Init Template Will Do

At the end you will have a generalized Windows Server 2025 Standard template that can be deployed like this:

qm clone 9005 105 --name ws2025-web01 --full
qm set 105 --ostype win11
qm set 105 --citype configdrive2
qm set 105 --cipassword 'Use-A-Real-Strong-Password-Here!'
qm set 105 --ipconfig0 ip=192.0.2.105/24,gw=192.0.2.1
qm set 105 --nameserver "192.0.2.53 192.0.2.54"
qm cloudinit update 105
qm start 105

After Windows completes its first-boot initialization, the built-in Administrator account will use the password supplied by Proxmox and the VirtIO NIC will use the IP configuration supplied by Proxmox.

How Windows Cloud-Init Works in Proxmox

Windows does not use the Linux cloud-init agent. Instead, the Windows guest runs Cloudbase-Init, which reads metadata generated by Proxmox from a ConfigDrive attached to the VM. Proxmox supplies the deployment values and Cloudbase-Init applies them inside Windows during first boot.

Current Proxmox releases include Windows-specific Cloudbase-Init handling. Proxmox generates Windows-compatible metadata and network data and uses the ConfigDrive2 format for Windows guests. A normal Windows Server 2025 password-and-network deployment therefore does not require editing Proxmox Perl files such as Cloudinit.pm or PVE/API2/Qemu.pm.

Requirements

• Proxmox VE 9.x. This article was written against the current Proxmox 9.x/qemu-server behavior.
• Windows Server 2025 Standard ISO.
• Windows Server 2025 product key or your normal activation method.
• Current VirtIO Windows driver ISO.
• Current 64-bit Cloudbase-Init installer.
• A Proxmox storage that can hold VM disks and a Cloud-Init disk.
• Administrative access to the Proxmox node and Windows guest.

Official downloads

• Microsoft Windows Server 2025 Evaluation Center
• Proxmox Windows VirtIO Drivers documentation
• Cloudbase-Init download page
• Cloudbase-Init stable x64 MSI

Step 1 — Create the Windows Server 2025 VM

Create a normal Windows VM first. Do not convert it to a template yet.

In the Proxmox GUI choose Create VM and use settings similar to the following:

If you prefer the CLI, this is an example. Change VMID, storage names, bridge, ISO names, RAM, and disk size for your environment:

VMID=9005
STORAGE=local-lvm
ISO_STORAGE=local

qm create $VMID \
  --name ws2025-cloudbase-build \
  --ostype win11 \
  --machine q35 \
  --bios ovmf \
  --cpu host \
  --sockets 1 \
  --cores 4 \
  --memory 8192 \
  --scsihw virtio-scsi-single \
  --agent enabled=1 \
  --net0 virtio,bridge=vmbr0

qm set $VMID --efidisk0 ${STORAGE}:1,efitype=4m,pre-enrolled-keys=1
qm set $VMID --scsi0 ${STORAGE}:64,iothread=1,discard=on,ssd=1
qm set $VMID --ide2 ${ISO_STORAGE}:iso/Windows_Server_2025.iso,media=cdrom
qm set $VMID --sata0 ${ISO_STORAGE}:iso/virtio-win.iso,media=cdrom
qm set $VMID --boot order=ide2\;scsi0

The exact ISO filenames will differ on your server.

Step 2 — Install Windows Server 2025 Standard

Start the VM and install Windows Server 2025 Standard. Choose Desktop Experience if you want the normal GUI, or Server Core if that is what you deploy. The Cloudbase-Init concept works with either, although this article shows GUI-oriented administration.

When Windows Setup reaches the disk selection page, the VirtIO SCSI disk may not appear until you load the storage driver from the VirtIO ISO.

1. Click Load driver.
2. Browse the VirtIO ISO.
3. For Windows Server 2025, select the matching AMD64 storage driver directory on the VirtIO ISO. Depending on the current VirtIO ISO layout this is normally under the Server 2025 directory for vioscsi.
4. After the driver loads, select the VirtIO disk and complete installation.

Set a temporary local Administrator password during installation. This password is only for building the image. The password supplied by Proxmox will replace it on deployed clones.

Step 3 — Install all VirtIO drivers and the QEMU Guest Agent

After Windows boots, open the VirtIO ISO. The easiest approach on current driver media is to run the VirtIO guest tools installer, which installs the common VirtIO drivers and QEMU Guest Agent.

You can also install drivers individually from Device Manager if that better matches your environment. At a minimum the final template should have a working VirtIO storage controller and VirtIO network adapter.

Verify the QEMU Guest Agent service from an elevated PowerShell window:

Get-Service QEMU-GA -ErrorAction SilentlyContinue
Get-Service | Where-Object {$_.DisplayName -match "QEMU"} | Format-Table Name,DisplayName,Status,StartType

After the agent is installed, make sure the Proxmox VM has the agent enabled:

qm set 9005 --agent enabled=1

Step 4 — Patch Windows and prepare the base image

Before installing Cloudbase-Init, bring the base VM to the state you want every new server to inherit.

• Install Windows Updates and reboot until no required updates remain.
• Install your normal monitoring, backup, security, or management agents if they belong in every image.
• Enable Remote Desktop if your deployment uses RDP.
• Apply baseline firewall and security policy.
• Do not join the template to Active Directory.
• Do not configure a production static IP in the image. Leave the adapter on DHCP before final Sysprep.
• Do not store customer-specific secrets in the template.

For RDP, for example:

Set-ItemProperty `
  -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' `
  -Name fDenyTSConnections `
  -Value 0

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Step 5 — Make sure the built-in Administrator account is active

Windows Server normally has the built-in Administrator account available, but verify it before installing Cloudbase-Init:

net user Administrator /active:yes
Get-LocalUser -Name Administrator | Format-List Name,Enabled,SID

This article intentionally uses the built-in account named Administrator. Current Proxmox Windows Cloudbase-Init handling uses the administrator configured inside cloudbase-init.conf; the Proxmox ciuser field is not a reliable way to select a different Windows account. For a simple hosting template, keep username=Administrator.

Step 6 — Install Cloudbase-Init

Download the current 64-bit Cloudbase-Init stable MSI. Cloudbase-Init installs a Windows service, its own Python environment, configuration files, logs, and support for ConfigDrive metadata.

PowerShell download example:

$url = "https://www.cloudbase.it/downloads/CloudbaseInitSetup_Stable_x64.msi"
$out = "C:\Windows\Temp\CloudbaseInitSetup_Stable_x64.msi"

Invoke-WebRequest -Uri $url -OutFile $out
Start-Process msiexec.exe -Wait -ArgumentList "/i `"$out`""

When the Cloudbase-Init installer wizard asks for options:

• Use Administrator as the username.
• Use the Administrators group.
• Run the Cloudbase-Init service as LocalSystem unless you have a specific reason not to.
• Do not run Sysprep from the installer yet.

The normal 64-bit installation path is:

C:\Program Files\Cloudbase Solutions\Cloudbase-Init\

The configuration files are normally:

C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.conf
C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init-unattend.conf
C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\Unattend.xml

Step 7 — Configure Cloudbase-Init for Proxmox ConfigDrive2

This is the part that determines whether Proxmox can actually set the password and IP address.

Back up the original configuration first:

$conf = "C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf"
Copy-Item "$conf\cloudbase-init.conf" "$conf\cloudbase-init.conf.original"
Copy-Item "$conf\cloudbase-init-unattend.conf" "$conf\cloudbase-init-unattend.conf.original"
Copy-Item "$conf\Unattend.xml" "$conf\Unattend.xml.original"

Recommended cloudbase-init.conf

Edit cloudbase-init.conf. The following is a focused Proxmox configuration for hostname, network, password, disk extension, and optional user-data execution:

[DEFAULT]
username=Administrator
groups=Administrators
inject_user_password=true
first_logon_behaviour=no
rename_admin_user=false

config_drive_raw_hhd=true
config_drive_cdrom=true
config_drive_vfat=true

metadata_services=cloudbaseinit.metadata.services.configdrive.ConfigDriveService

plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,cloudbaseinit.plugins.common.networkconfig.NetworkConfigPlugin,cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin,cloudbaseinit.plugins.common.userdata.UserDataPlugin,cloudbaseinit.plugins.common.setuserpassword.SetUserPasswordPlugin

allow_reboot=true
stop_service_on_exit=false
check_latest_version=false
verbose=true
debug=false

The important values are:

• username=Administrator — tells Cloudbase-Init which Windows administrator receives the injected password.
• inject_user_password=true — permits the metadata password to be applied.
• first_logon_behaviour=no — prevents Windows from forcing the customer to change the injected password at the first interactive logon.
• metadata_services=...ConfigDriveService — makes Cloudbase-Init immediately inspect the Proxmox ConfigDrive instead of wasting time probing unrelated metadata services.
• NetworkConfigPlugin — applies the static IP/gateway/DNS supplied by Proxmox.
• SetUserPasswordPlugin — applies the password supplied by Proxmox.
• SetHostNamePlugin — applies the hostname and can require a reboot.
• ExtendVolumesPlugin — useful when clones are deployed with a larger OS disk than the base image.

Recommended cloudbase-init-unattend.conf

Cloudbase-Init is a two-stage process around Sysprep. The -unattend.conf file is used during the Sysprep/unattend stage; the normal cloudbase-init.conf is then used for the deployed VM initialization stage.

Use a minimal unattended configuration so the image can generalize cleanly without consuming the final clone’s password/network metadata prematurely:

[DEFAULT]
username=Administrator
groups=Administrators
inject_user_password=true
first_logon_behaviour=no
rename_admin_user=false

config_drive_raw_hhd=true
config_drive_cdrom=true
config_drive_vfat=true

metadata_services=cloudbaseinit.metadata.services.configdrive.ConfigDriveService

plugins=cloudbaseinit.plugins.common.mtu.MTUPlugin,cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin

allow_reboot=false
stop_service_on_exit=false
check_latest_version=false
verbose=true
debug=false

If your installed Cloudbase-Init version already generated a functional cloudbase-init-unattend.conf, you can keep its other defaults and make sure the username, password behavior, and ConfigDrive service are correct.

Step 8 — Verify the Cloudbase-Init service

Before Sysprep, verify that the service exists and is configured to start automatically:

Get-Service cloudbase-init | Format-List Name,DisplayName,Status,StartType
Set-Service cloudbase-init -StartupType Automatic

Do not repeatedly start Cloudbase-Init against your build VM once you are preparing the final image. The goal is for the deployed clone to consume its own Proxmox metadata.

Step 9 — Add the Proxmox Cloud-Init drive

Shut down the VM if necessary and add a Cloud-Init drive.

GUI: VM → Hardware → Add → CloudInit Drive.

CLI example:

qm set 9005 --ide2 local-lvm:cloudinit
qm set 9005 --citype configdrive2
qm set 9005 --ostype win11

For Windows, configdrive2 is the correct Cloud-Init format. Current Proxmox automatically defaults Windows guests to ConfigDrive2, but setting it explicitly makes the template’s intent obvious.

Step 10 — Inspect exactly what Proxmox will inject

One of the best troubleshooting tools is qm cloudinit dump. Before Sysprep, set temporary test values on the build VM and inspect the generated metadata.

Again, make absolutely sure the VM already has ostype=win11 before you set cipassword.

qm set 9005 --ostype win11
qm set 9005 --citype configdrive2

qm set 9005 --cipassword 'Temporary-Cloudbase-Test-Password!'
qm set 9005 --ipconfig0 ip=192.0.2.50/24,gw=192.0.2.1
qm set 9005 --nameserver "192.0.2.53 192.0.2.54"

qm cloudinit update 9005

qm cloudinit dump 9005 meta
qm cloudinit dump 9005 network
qm cloudinit dump 9005 user

This lets you confirm Proxmox is actually generating the network and metadata that Cloudbase-Init will see.

After testing, clear any build-only Cloud-Init values you do not want inherited as defaults. You can leave harmless defaults on a template if your provisioning platform always overwrites them, but a clean template is less error-prone.

Step 11 — Prepare Unattend.xml

Cloudbase-Init installs an Unattend.xml used by Sysprep. On Windows Server, upstream Proxmox documentation notes that the supplied Cloudbase-Init unattend process should normally work without the Windows-client workaround needed to re-enable Administrator.

Still, inspect:

C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\Unattend.xml

If you want an extra safeguard ensuring the built-in Administrator account is active on first boot, you can place this command in the appropriate specialize / RunSynchronous block, making sure its order number does not conflict with existing Cloudbase-Init commands:

<RunSynchronousCommand wcm:action="add">
  <Path>net user Administrator /active:yes</Path>
  <Order>1</Order>
  <Description>Enable Administrator User</Description>
</RunSynchronousCommand>

If Cloudbase-Init’s own synchronous command is already order 1, move it to order 2 or another unused order. Do not blindly replace the entire Cloudbase-provided Unattend.xml; modify only what you understand and keep a backup.

Step 12 — Final cleanup before Sysprep

Do the final maintenance before generalizing the image:

# Confirm Windows is not domain joined
(Get-CimInstance Win32_ComputerSystem).PartOfDomain

# Confirm Administrator is enabled
Get-LocalUser Administrator

# Confirm Cloudbase-Init is automatic
Get-Service cloudbase-init

# Confirm NICs
Get-NetAdapter

# Optional component cleanup
DISM /Online /Cleanup-Image /StartComponentCleanup

Reboot one final time if updates or drivers require it. Log back in, verify Device Manager has no relevant missing VirtIO devices, and then stop making normal image changes.

Step 13 — Run Sysprep correctly

Microsoft requires a generalized Windows image when it will be reused as a template. Run Sysprep with /generalize, /oobe, and the Cloudbase-Init answer file.

From an elevated Command Prompt or PowerShell:

cd "C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf"

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown /unattend:Unattend.xml

The VM should shut down when Sysprep finishes.

Step 14 — Convert the VM to a Proxmox template

In the GUI, right-click the powered-off VM and choose Convert to Template.

CLI:

qm template 9005

You now have a Windows Server 2025 Standard Cloudbase-Init template.

Step 15 — Deploy and test a clone

Do not assume the template works until you test a real clone with a unique password and static IP.

TEMPLATE=9005
VMID=105

qm clone $TEMPLATE $VMID --name ws2025-test105 --full

# Be explicit on Windows type BEFORE setting cipassword.
qm set $VMID --ostype win11
qm set $VMID --citype configdrive2

qm set $VMID --cipassword 'Example-Only-Change-Me-105!'
qm set $VMID --ipconfig0 ip=192.0.2.105/24,gw=192.0.2.1
qm set $VMID --nameserver "192.0.2.53 192.0.2.54"

qm cloudinit update $VMID

# Inspect the generated data before booting.
qm cloudinit dump $VMID meta
qm cloudinit dump $VMID network

qm start $VMID

Give Windows time to complete the Cloudbase-Init/Sysprep first boot. A hostname change can require a reboot. If Cloudbase-Init is configured with allow_reboot=true, it can reboot automatically.

After initialization, verify:

hostname
ipconfig /all
Get-NetIPConfiguration
Get-DnsClientServerAddress
Get-Service cloudbase-init

Then log in as:

Administrator

using the password you supplied to qm set ... --cipassword.

Setting the hostname

When a VM is cloned with a Proxmox VM name, current Windows Cloudbase-Init metadata generation can use the VM’s generated hostname metadata. Use a Windows-compatible DNS name: short, predictable, and without characters Windows cannot use.

Example:

qm clone 9005 106 --name ws2025-sql01 --full

If your automation stack requires a specific hostname independent of the Proxmox object name, verify the generated metadata with:

qm cloudinit dump 106 meta

DHCP deployments

If you want the deployed VM to use DHCP instead of a static IP:

qm set 106 --ipconfig0 ip=dhcp
qm cloudinit update 106
qm start 106

Static IPv4 deployments

Typical static IPv4 example:

qm set 106 --ipconfig0 ip=203.0.113.106/24,gw=203.0.113.1
qm set 106 --nameserver "203.0.113.53 203.0.113.54"
qm cloudinit update 106

IPv6

Proxmox supports IPv6 values in ipconfig0. Whether your exact Windows/Cloudbase-Init combination applies every IPv6 option the way you expect should be tested in your network before customer deployment.

qm set 106 --ipconfig0 \
  ip=203.0.113.106/24,gw=203.0.113.1,ip6=2001:db8:100::106/64,gw6=2001:db8:100::1

DNS search domains: know the limitation

Current Proxmox’s Windows-specific Cloudbase-Init network generation intentionally differs from Linux ConfigDrive2. Upstream Proxmox removed DNS search-domain generation from the Cloudbase-Init ENI path because Cloudbase-Init’s ENI parser does not handle it correctly. DNS server addresses are supported; do not build your Windows template around searchdomain being applied the same way as a Linux cloud-init guest.

Security note about cipassword

Windows password injection via the Proxmox ConfigDrive workflow necessarily differs from Linux SSH-key-first deployments. Treat access to the Proxmox API, VM configuration, Cloud-Init data, and Cloud-Init drive as privileged infrastructure access.

Use strong unique passwords, limit Proxmox permissions, and avoid leaving long-lived template passwords as defaults. In an automated hosting environment, generate a unique password for each provisioned VM and deliver it through your normal secure customer workflow.

Troubleshooting

Problem: the Administrator password does not work

Check these in order:

1. Was ostype=win11 set before cipassword?
2. Is citype=configdrive2?
3. Does cloudbase-init.conf contain username=Administrator?
4. Is inject_user_password=true?
5. Does the plugin list contain cloudbaseinit.plugins.common.setuserpassword.SetUserPasswordPlugin?
6. Is the Cloudbase-Init service running or configured Automatic?
7. Did you accidentally boot the source VM after its final Sysprep?

On Proxmox:

qm config 105
qm cloudinit dump 105 meta
qm cloudinit dump 105 network
qm cloudinit dump 105 user

Inside Windows, inspect:

C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\

and:

Get-Content "C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log" -Tail 200

Problem: Windows forces a password change at first login

Set this in cloudbase-init.conf:

first_logon_behaviour=no

The Cloudbase-Init password plugin documentation specifically supports this behavior.

Problem: Windows gets DHCP instead of the static IP

Check:

qm cloudinit dump 105 network
qm config 105

Inside Windows verify the NIC is the same VirtIO NIC Cloudbase-Init is targeting:

Get-NetAdapter
Get-NetIPConfiguration

Then inspect the Cloudbase-Init log for NetworkConfigPlugin and ConfigDrive errors.

Problem: Cloudbase-Init takes several minutes to start configuring

Restrict metadata probing to ConfigDrive in both relevant configurations:

metadata_services=cloudbaseinit.metadata.services.configdrive.ConfigDriveService

Otherwise Cloudbase-Init can spend time probing metadata services that do not exist in your Proxmox environment.

Problem: the Cloud-Init drive is visible, but nothing is applied

Confirm:

Get-Service cloudbase-init
Get-Volume
Get-Disk

Verify ConfigDriveService is configured and that the Cloudbase-Init log reports finding the ConfigDrive. Also confirm the Proxmox VM really is Windows ostype=win11 and not other or Linux.

Problem: the clone has the wrong or old IP configuration

Do not hard-code a production static address into the template. Before final Sysprep, leave the source NIC on DHCP. Every clone should receive its address from ipconfig0.

Problem: DNS servers work but DNS search domain does not

This is an upstream limitation in the Windows Cloudbase-Init ENI path. Do not assume Proxmox’s Linux searchdomain behavior is available on Windows through the same parser.

Problem: Sysprep fails

Read Microsoft’s Sysprep logs:

C:\Windows\System32\Sysprep\Panther\setupact.log
C:\Windows\System32\Sysprep\Panther\setuperr.log

Also check the Windows event logs and remove or repair any application package explicitly identified as blocking generalization. Do not use random registry hacks before reading the actual Sysprep error.

Useful Proxmox commands for administrators

Show template/VM configuration

qm config 9005

Force Windows OS type and ConfigDrive2

qm set 9005 --ostype win11
qm set 9005 --citype configdrive2

Add a Cloud-Init drive

qm set 9005 --ide2 local-lvm:cloudinit

Update generated Cloud-Init media

qm cloudinit update 105

Inspect generated data

qm cloudinit dump 105 meta
qm cloudinit dump 105 network
qm cloudinit dump 105 user

Configure static IP and DNS

qm set 105 --ipconfig0 ip=192.0.2.105/24,gw=192.0.2.1
qm set 105 --nameserver "192.0.2.53 192.0.2.54"

Configure DHCP

qm set 105 --ipconfig0 ip=dhcp

Set the Administrator password

# ostype must already be Windows!
qm set 105 --ostype win11
qm set 105 --cipassword 'A-Unique-Strong-Password!'

Clone and boot

qm clone 9005 105 --name ws2025-test105 --full
qm set 105 --ostype win11
qm set 105 --citype configdrive2
qm set 105 --cipassword 'A-Unique-Strong-Password!'
qm set 105 --ipconfig0 ip=192.0.2.105/24,gw=192.0.2.1
qm set 105 --nameserver "192.0.2.53 192.0.2.54"
qm cloudinit update 105
qm start 105

Optional: use the Proxmox GUI instead of qm

Everything above can be done from the web interface for a manually deployed VM:

1. Clone the template.
2. Open the clone.
3. Confirm Options → OS Type is the Windows 11/2022/2025 type.
4. Open Cloud-Init.
5. Set the password.
6. Set IPv4 to DHCP or Static.
7. For Static, enter the CIDR address and gateway.
8. Set DNS servers as appropriate.
9. Regenerate the Cloud-Init image if the UI presents that action, then boot the VM.

The CLI examples remain useful because they show the exact Proxmox property names used by automation systems such as WHMCS modules, Terraform providers, scripts, and API integrations.

Using this with WHMCS or other provisioning software

Once the template works manually, a provisioning system should do the same operations in the same logical order:

1. Clone the Windows Server 2025 template.
2. Keep/set the guest OS type as Windows Server 2025’s Proxmox type: win11.
3. Keep/set Cloud-Init type to configdrive2.
4. Set the unique Administrator password.
5. Set ipconfig0 and DNS.
6. Regenerate/update the Cloud-Init drive.
7. Boot the clone.

If a third-party module imports your template metadata, do not add arbitrary custom cicustom data unless the module specifically requires it. Native Proxmox Windows ConfigDrive2 is enough for the basic password/IP workflow described here.

Video walkthrough

A useful visual companion is House of Logic’s How to Deploy Windows using Cloud-Init on Proxmox. It demonstrates Cloudbase-Init, the Cloud-Init settings, Sysprep behavior, password handling, and network configuration:

Watch: How to Deploy Windows using Cloud-Init on Proxmox

The video predates some current Proxmox 9.x changes, so use this article’s current Proxmox settings as the source of truth when the video differs.

Authoritative references

• Proxmox qemu-server source — current OS type and Cloud-Init schema
• Proxmox upstream Windows Cloudbase-Init documentation patch
• Proxmox applied Windows Cloudbase-Init implementation
• Cloudbase-Init official tutorial
• Cloudbase-Init configuration reference
• Cloudbase-Init metadata services
• Cloudbase-Init plugin reference
• Cloudbase-Init official downloads
• Proxmox Windows VirtIO driver documentation
• Microsoft Sysprep command-line options
• Microsoft — Generalize a Windows installation

Final checklist

• Windows Server 2025 Standard installed and patched.
• Proxmox VM ostype=win11.
• VirtIO storage and network drivers installed.
• QEMU Guest Agent installed and enabled.
• Administrator account active.
• Cloudbase-Init installed.
• username=Administrator.
• inject_user_password=true.
• first_logon_behaviour=no.
• ConfigDriveService is the metadata service.
• NetworkConfigPlugin and SetUserPasswordPlugin enabled.
• Proxmox Cloud-Init drive attached.
• citype=configdrive2.
• Final Sysprep run with /generalize /oobe /shutdown.
• Source VM not booted again after Sysprep.
• VM converted to a template.
• A real clone tested with a new password, new IP, gateway, and DNS.

Windows Server 2025 Cloud-Init Template FAQ

Does Proxmox support Cloud-Init on Windows Server 2025?

Yes. Proxmox generates the VM metadata, while Cloudbase-Init inside Windows reads that metadata from a ConfigDrive and applies the Windows configuration. For Windows Server 2025, use ostype=win11 and citype=configdrive2.

Can Proxmox set the Windows Server 2025 Administrator password automatically?

Yes. Set the Windows guest type before setting cipassword, configure Cloudbase-Init with username=Administrator and inject_user_password=true, and enable SetUserPasswordPlugin.

Can Proxmox assign a static IP to a Windows Server 2025 clone?

Yes. Configure ipconfig0 with the IPv4 address and gateway, set the DNS servers, and enable Cloudbase-Init’s NetworkConfigPlugin.

Should I use cloud-init or Cloudbase-Init for Windows?

Use Cloudbase-Init inside Windows. Proxmox still calls the configuration interface and disk Cloud-Init because Proxmox generates the metadata.

What Proxmox OS type should Windows Server 2025 use?

Use ostype=win11. In current Proxmox releases, that guest type covers Windows 11 as well as Windows Server 2022 and Windows Server 2025.

Why must ostype be set before cipassword?

Proxmox handles Windows Cloud-Init passwords differently from Linux passwords. Setting the Windows guest type first ensures the password is generated in the format expected by Cloudbase-Init.

Conclusion

A current Proxmox installation no longer needs the old Windows Cloud-Init Perl patches for basic Cloudbase-Init provisioning. The reliable recipe is to build and Sysprep a clean Windows Server 2025 Standard image, configure Cloudbase-Init to consume ConfigDrive metadata, keep the Windows guest type set to win11, and use Proxmox’s native cipassword and ipconfig0 properties.

Once the template passes a manual clone test, the same template can be used by the Proxmox API, WHMCS provisioning modules, Terraform, Ansible workflows, or ARPHost’s own automation to deploy Windows Server 2025 instances with unique Administrator passwords and networking.