terraform-provider-azurerm: azurerm_windows_virtual_machine fails to create when referencing a "specialised" shared gallery image.

FWIW, I was able to get a specialised image working with the azurerm_virtual_machine resource type (as mentioned by both @burnedikt and @ChrisPetr0 above), but ONLY when using a base VM that used a “Standard” security type (as opposed to “Trusted Launch” security type, which is becoming the norm). I believe Gen 1 VMs always use Standard security, and Gen 2 VMs usually use Trusted Launch security by default (the Azure CLI will be updated in November).

To prove this out, it is possible to force deployment of a Windows 11 Gen 2 Standard Security VM as a base image using the Azure CLI on which we can customise and specialise, for example:

az group create --name myResourceGroup --location eastus
az vm create --resource-group myResourceGroup --name myVM --image "MicrosoftWindowsDesktop:windows-11:win11-22h2-pro:22621.2134.230801" --public-ip-sku Standard --admin-username testadmin --admin-password Password1234! --security-type Standard

Then, I modify and capture a specialised image in the Azure Compute Gallery. I can then use something like this Terraform to deploy a working VM from this specialised image:

resource "azurerm_virtual_machine" "windows" {
  name                        = "testingvm"
  resource_group_name         = "${data.azurerm_resource_group.main.name}"
  location                    = "${data.azurerm_resource_group.main.location}"

  vm_size                     = "Standard_B2s"
  network_interface_ids       = [azurerm_network_interface.winnic.id]

  storage_image_reference {
    id                        = "/subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/resourceGroups/myComputeGallery_RG/providers/Microsoft.Compute/galleries/myComputeGallery/images/Win11Gen2StandardSecuritySpecialised"
  }

  storage_os_disk {
    name                      = "${var.prefix}-osdisk"
    caching                   = "ReadWrite"
    create_option             = "FromImage"
    managed_disk_type         = "Standard_LRS"
  }
}

If we do the same process but instead deploy a Windows 11 Gen 2 VM with Trusted Launch security, then customise and capture the specialised image to the Azure Compute Gallery, subsequent VMs fail to deploy from the image. Essentially, the only thing that changes in the Terraform snippet above is the reference to the storage_image_reference. The error thrown is something like this:

Error: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="The provided gallery image only supports the creation of VMs and VM Scale Sets with 'TrustedLaunch' security type."

  with azurerm_virtual_machine.windows,
  on user-script.tf line 80, in resource "azurerm_virtual_machine" "windows":
  80: resource "azurerm_virtual_machine" "windows" {

I do not believe the azurerm_virtual_machine resource type supports (or will ever support) the “Trusted Launch” security options, hence our failure.

It seems you cannot change the VM security type once it has been deployed, so instead, you would need to start from scratch using this method. Capturing an image of a VM retains the security type. Of course (and as pointed out), the azurerm_virtual_machine resource type is now deprecated, and the Trusted Launch security type will only ever become more widespread, so you are potentially painting yourself into a corner.

When generalising a Gen 2 VM that uses the Trusted Launch security type, I can use some Terraform similar to:

resource "azurerm_windows_virtual_machine" "windows" {
  admin_password            = "Password1234!"
  admin_username            = "testadmin"
  name                      = "testingvm"
  resource_group_name       = "${data.azurerm_resource_group.main.name}"
  location                  = "${data.azurerm_resource_group.main.location}"

  size                      = "Standard_B2s"
  network_interface_ids     = [azurerm_network_interface.winnic.id]
  secure_boot_enabled   	= true
  vtpm_enabled              = true

  source_image_id           = "/subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/resourceGroups/myComputeGallery_RG/providers/Microsoft.Compute/galleries/myComputeGallery/images/Win11_Gen2_TurstedLaunch_Generalised"
  
  identity {
    type                    = "SystemAssigned"
  }
  
  os_disk {
    name                    = "${var.prefix}-osdisk"
    caching                 = "ReadWrite"
    storage_account_type    = "Standard_LRS"
  }
  
  depends_on = [
    azurerm_network_interface.winnic,
  ]
}

This uses the newer azurerm_windows_virtual_machine resource type, and we can specify the secure_boot_enabled and vtpm_enabled parameters to signify a Trusted Launch security VM (although these settings are independent within Azure - you can have a Trusted Launch VM without either Secure Boot or TPM enabled).

However, when switching to use a specialised image in the same Terraform snippet, we get another failure:

Error: creating Windows Virtual Machine: (Name "testingvm" / Resource Group "apr-0ymlynte2ggae"): compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidParameter" Message="Parameter 'osProfile' is not allowed." Target="osProfile"

  with azurerm_windows_virtual_machine.windows,
  on user-script.tf line 80, in resource "azurerm_windows_virtual_machine" "windows":
  80: resource "azurerm_windows_virtual_machine" "windows" {

This is, of course, what @woter1832 initially reported above.

When deploying a VM from a specialised image in the portal, the Admin username and password fields are greyed out. However, we can’t remove the admin_username and admin_password parameters from the Terraform as they are a requirement by the azurerm_windows_virtual_machine resource type. I’m unsure if this is the cause of the issue in this case. Maybe it’s trying to change something in the OS profile that cannot be changed (hence the error).

Whatever, this is super frustrating as Gen 2 VMs using the Trusted Launch security type can be deployed from specialised images via the Azure portal and all other Azure command line options.

this issue seems last more than 2 years, no final solution until now, is there any workaround , thanks in advance

Hi, Is there any news on this? I ran into this issue today while trying to create VMs using some internal custom images.

Terraform v1.3.8
on linux_amd64
+ provider registry.terraform.io/hashicorp/azuread v2.33.0
+ provider registry.terraform.io/hashicorp/azurerm v3.43.0
+ provider registry.terraform.io/hashicorp/random v3.4.3