Azure VM Resize failing because `hardwareProfile.vmSizeProperties` silently gets set

I was hitting the same error when resizing an older VM:

“requested vCPUs are not supported for the specified VM size”

This was on a VM created in 2019 with a now‑deprecated microsoftwindowsdesktop / office‑365 / 1903‑evd‑o365pp image. The VM had hardwareProfile.vmSizeProperties enforced and would not resize to smaller B‑series SKUs. Setting:

PowerShell$vm.HardwareProfile.VmSizeProperties = $null

was accepted by ARM but immediately reverted back to 20 vCPUs. What did work was explicitly setting a constrained vCPU value, not nulling the property:

$vm = Get-AzVM -ResourceGroupName <rg> -Name <vm>
$vm.HardwareProfile.VmSizeProperties.VCPUsAvailable = 1
$vm.HardwareProfile.VmSizeProperties.VCPUsPerCore = 1
Update-AzVM -ResourceGroupName <rg> -VM $vm 

After that, I was able to resize successfully (for example, from B20ms to B4ms). The VM ended up running as Standard_B4ms with 16 GB RAM but only 1 vCPU, which is valid under constrained‑core rules. Important notes:

• Billing remains based on the full VM size.
• This seems to rely on vCore customization being supported by the target SKU.
• Clearing VmSizeProperties entirely did not work for me; setting a valid value did.

Posting this in case it helps others stuck on older VMs.

Hello Julian

Greetings!

Thanks for raising this question in Q&A forum.

The reason this is happening is that your VMs have the hardwareProfile.vmSizeProperties field set (either silently by a policy/configuration in your Azure account, or via Terraform), which enables the VM vCore Customization (Preview) feature. Once this property is set on a VM, Azure enforces that the target resize SKU must support the exact vCPUsAvailable value that was configured — and most standard resize operations don't account for this, causing the error you're seeing.

Here's how you can resolve this step by step:

Step 1: Deallocate the VM first

Before making any changes, always deallocate the VM:

az vm deallocate --resource-group <ResourceGroupName> --name <VMName>

Step 2: Clear the vmSizeProperties via Azure REST API or PowerShell

The Azure CLI doesn't yet have a direct flag to null out this property cleanly, so use the REST API approach. Run this via PowerShell:

$vm = Get-AzVM -ResourceGroupName "<ResourceGroupName>" -Name "<VMName>"
$vm.HardwareProfile.VmSizeProperties = $null
Update-AzVM -ResourceGroupName "<ResourceGroupName>" -VM $vm

This clears the custom vCore property so the VM behaves like a standard VM again.

Step 3: Resize the VM

Now resize it normally:

az vm resize --resource-group <ResourceGroupName> --name <VMName> --size <NewVMSize>

Step 4: For Terraform-managed VMs

If your VMs are created via Terraform, check your configuration for any block like:

additional_capabilities {
  ultra_ssd_enabled = ...
}

or any vm_size_properties block, and remove it. Also check if your Azure account has any Policy assignments that auto-apply this setting at provisioning time — that could be the "silent" cause here.

Step 5: Check for Azure Policy

Go to Azure Portal → Policy → Assignments and look for any policy related to "vCore" or "SMT" that might be automatically injecting this property on VM creation. If found, consult your admin about exempting your VMs or disabling it for your scope.

Since this is still a Preview feature, Microsoft may not have full CLI/Terraform parity yet — so the PowerShell or REST API approach is currently the most reliable path forward.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.