Imagens do Windows Server 2022 com .NET 6 deprecadas no Azure: o que para e como migrar

Se você tem VMs Windows no Azure, é bem provável que tenha recebido um e-mail com o assunto “Migrate from deprecated Microsoft Marketplace Windows Server 2022 images to supported images now to avoid service disruptions”. Ele avisa que as imagens do Windows Server 2022 que vinham com o .NET 6 pré-instalado foram deprecadas, lista 14 SKUs e manda migrar para uma oferta nova. O e-mail não responde as perguntas que importam: minha VM vai parar? O que exatamente quebra? Como eu descubro quais recursos estão afetados?

Neste artigo eu respondo essas perguntas com a documentação oficial e com consultas reais feitas no Azure em 22 de setembro de 2026. No caminho aparece um detalhe que o e-mail não conta: a depreciação das imagens do Windows Server 2022 é por versão, e não da oferta inteira de uma vez.

Sumário

• O que mudou nas imagens do Windows Server 2022
• O que para de funcionar e o que continua
• A depreciação é por versão: o que o Azure mostra hoje
• Como descobrir se você é afetado
• Laboratório: migrando um VMSS de verdade
• Como migrar: VM, VMSS e Terraform
• E o .NET? Não troque o 6 pelo 8
• Checklist
• Referências oficiais

O que mudou nas imagens do Windows Server 2022

Durante anos, as imagens do Windows Server 2022 publicadas no Azure Marketplace vieram com o .NET 6 embutido. O .NET 6 chegou ao fim do suporte em 12 de novembro de 2024, e a Microsoft não pode continuar distribuindo uma imagem “oficial” com um runtime sem correção de segurança. A linha do tempo ficou assim:

• Outubro de 2024: anúncio da mudança no blog de Azure Compute.
• 9 de março de 2025: passa a existir a oferta nova windowsserver2022, com as mesmas SKUs e sem nenhum .NET embutido.
• 2026: os primeiros avisos citavam 9 de junho de 2026; o e-mail enviado em setembro informa que a depreciação das imagens com .NET 6 aconteceu em 14 de julho de 2026.

A mudança no código é pequena: só o campo offer troca. Publisher e SKU continuam iguais.

# Antes (oferta antiga, versões com .NET 6)
MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:latest

# Depois (oferta nova, sem .NET embutido)
MicrosoftWindowsServer:windowsserver2022:2022-datacenter-azure-edition:latest

As 14 SKUs citadas no e-mail existem nas duas ofertas com o mesmo nome: 2022-datacenter, 2022-datacenter-g2, 2022-datacenter-core, 2022-datacenter-azure-edition, as variações -smalldisk, -core e -hotpatch, e assim por diante. Dá para conferir com:

az vm image list-skus -l eastus -p MicrosoftWindowsServer -f windowsserver2022 --query "[].name" -o tsv

O que para de funcionar e o que continua

Uma VM já criada não depende mais da imagem do Marketplace: ela dá boot pelo próprio disco de sistema operacional. Por isso a depreciação só afeta operações que precisam recriar o disco a partir da imagem. Segundo o FAQ oficial de imagens deprecadas:

Cuidado com respostas que circulam em fóruns dizendo que o restore de backup para de funcionar: para as imagens do Windows Server 2022, que são da própria Microsoft e não têm purchase plan, o FAQ oficial diz o contrário. O risco real está no VMSS. Um conjunto de escala que tenta adicionar instâncias num pico de acesso e não consegue é exatamente a “interrupção de serviço” de que o e-mail fala.

A depreciação é por versão: o que o Azure mostra hoje

O e-mail dá a impressão de que a oferta WindowsServer inteira acabou para o 2022. Não é bem assim. Consultei o status das versões das imagens do Windows Server 2022 na oferta antiga (SKU 2022-datacenter-azure-edition, região eastus) em 22 de setembro de 2026. São 112 versões publicadas, e o status varia conforme a data de cada build:

$ az vm image show --location eastus \
    --urn MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:20348.4648.260108 \
    --query imageDeprecationStatus

ERROR: (ImageVersionDeprecated) VM Image from publisher: MicrosoftWindowsServer with -
Offer: WindowsServer, Sku: 2022-datacenter-azure-edition, Version: 20348.4648.260108 is deprecated.

# Versões de junho a agosto de 2026
20348.5256.260607  {"imageState":"ScheduledForDeprecation","scheduledDeprecationTime":"2027-01-12T00:00:00+00:00"}
20348.5386.260711  {"imageState":"ScheduledForDeprecation","scheduledDeprecationTime":"2026-12-11T00:00:00+00:00"}
20348.5499.260809  {"imageState":"ScheduledForDeprecation","scheduledDeprecationTime":"2026-12-11T00:00:00+00:00"}

# Versão mais recente (setembro de 2026)
20348.5622.260906  {"imageState":"Active"}

Na prática, isso quer dizer duas coisas:

• Quem fixou uma versão específica (comum em pipelines que exigem build reproduzível) já está quebrado se a versão for de antes de julho: o deploy falha com ImageVersionDeprecated.
• Quem usa latest na oferta antiga ainda consegue criar VM hoje, mas está vivendo de versões com data marcada para serem deprecadas. E tem um detalhe pior, que o laboratório abaixo mostra: essa versão “Active” mais recente ainda vem com o .NET 6 instalado. Não é um lugar seguro para ficar.

Para ver o status de qualquer imagem antes de usar, filtre só as versões ativas:

az vm image list --location eastus \
  --publisher MicrosoftWindowsServer --offer windowsserver2022 --sku 2022-datacenter-azure-edition \
  --all --query "[?imageDeprecationStatus.imageState=='Active'].version" -o tsv

Como descobrir se você é afetado

O e-mail traz um tracking ID e o aviso também aparece em Service Health > Health advisories e no Azure Advisor. Mas a forma mais direta de listar tudo é o Azure Resource Graph, que olha todas as subscriptions de uma vez. Esta consulta traz VMs e VMSS com imagens do Windows Server 2022 e mostra a oferta e a versão exata de cada uma:

az graph query -q "
resources
| where type in~ ('microsoft.compute/virtualmachines','microsoft.compute/virtualmachinescalesets')
| extend img = iff(type =~ 'microsoft.compute/virtualmachines',
                   properties.storageProfile.imageReference,
                   properties.virtualMachineProfile.storageProfile.imageReference)
| where tostring(img.publisher) =~ 'MicrosoftWindowsServer' and tostring(img.sku) startswith '2022'
| project tipo = split(type, '/')[1], name, resourceGroup, subscriptionId,
          oferta = tostring(img.offer), sku = tostring(img.sku), versao = tostring(img.exactVersion)
" --first 1000 -o table

Tudo que voltar com oferta = WindowsServer precisa de plano de migração. Priorize nesta ordem: VMSS (escala bloqueada), depois templates e pipelines que criam VMs novas, e por último VMs isoladas que você reimagia com frequência. Se preferir PowerShell, a Microsoft mantém o script Get-AzVMImageDeprecationStatus.ps1 no repositório azure-support-scripts, que varre VMs e VMSS de uma subscription.

Um detalhe: o e-mail vai para quem tem papel de Owner na subscription. Se o time que cuida das VMs não é Owner, ele não recebe nada. Vale criar um alerta do Azure Advisor com um action group para o e-mail do time. E, se você já usa Azure Policy para padronizar as VMs, como mostrei em Azure Policy DeployIfNotExists: Boot Diagnostics automático nas VMs, dá para criar uma policy de auditoria sobre o alias Microsoft.Compute/imageOffer e acompanhar pelo painel de conformidade quem ainda usa a oferta antiga.

Laboratório: migrando um VMSS de verdade

Para não ficar só na teoria, montei um laboratório no Azure em 22 de setembro de 2026 (região East US, resource group isolado, apagado no final) com um VM Scale Set de uma instância, simulando a camada web da loja virtual que acompanha as séries do blog.

1. Tentar criar a partir de uma versão deprecada. O deploy nem começa, e nenhum recurso é criado:

$ az vm create ... --image MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:20348.4648.260108

ERROR: (ImageVersionDeprecated) VM Image from publisher: MicrosoftWindowsServer with -
Offer: WindowsServer, Sku: 2022-datacenter-azure-edition, Version: 20348.4648.260108 is deprecated.

2. Criar o VMSS pela oferta antiga com latest, como muita gente ainda faz. Funciona, e a instância nasce na versão mais recente (setembro de 2026). Olhando dentro dela com az vmss run-command invoke:

Build do SO: 20348.5622
Microsoft.AspNetCore.App 6.0.46
Microsoft.NETCore.App 6.0.46

Esse é o achado do laboratório: a versão marcada como Active da oferta antiga ainda traz o .NET 6.0.46, um runtime sem correção de segurança desde novembro de 2024. Ficar na oferta antiga com latest não é só adiar o problema: é continuar colocando .NET 6 em cada instância nova.

3. Trocar a oferta no modelo do VMSS. O modelo muda na hora, mas a instância existente continua na imagem antiga, e o portal passa a mostrar Latest model: No:

$ az vmss update ... --set virtualMachineProfile.storageProfile.imageReference.offer=windowsserver2022 \
                          virtualMachineProfile.storageProfile.imageReference.version=latest

Oferta         Versao             UltimoModelo
-------------  -----------------  --------------
WindowsServer  20348.5622.260906  False

4. Aplicar o modelo nas instâncias com az vmss update-instances. O disco de SO é recriado a partir da oferta nova:

Oferta             Versao             UltimoModelo
-----------------  -----------------  --------------
windowsserver2022  20348.5622.260906  True

Build do SO: 20348.5622
Pasta C:\Program Files\dotnet\shared nao existe: nenhum runtime .NET (Core) instalado

Repare no resultado: o build do Windows é exatamente o mesmo (20348.5622). No laboratório, a diferença que apareceu entre as duas ofertas foi só o .NET. Na prática, a migração não mexe no sistema operacional. O que muda é que a sua aplicação deixa de encontrar um runtime pronto, e isso você precisa resolver antes de trocar a imagem em produção.

Como migrar: VM, VMSS e Terraform

VM Scale Sets

É o caso mais urgente, e a atualização automática de SO não resolve: ela só troca a versão dentro da mesma oferta e SKU. É preciso alterar a oferta no modelo do VMSS e depois atualizar as instâncias:

az vmss update \
  --resource-group <resource-group> \
  --name <vmss> \
  --set virtualMachineProfile.storageProfile.imageReference.offer=windowsserver2022 \
        virtualMachineProfile.storageProfile.imageReference.version=latest

# Troca o disco de SO das instâncias existentes: faça backup do que estiver no disco C:
az vmss update-instances \
  --resource-group <resource-group> \
  --name <vmss> \
  --instance-ids "*"

Em produção, prefira uma política de rolling upgrade em vez de atualizar todas as instâncias de uma vez. E atenção: o exemplo de migração de oferta no próprio FAQ da Microsoft usa offer=WindowsServer com SKU 2022-datacenter. Para este caso, esse é justamente o destino errado. Use windowsserver2022.

VMs isoladas

Numa VM comum, a referência de imagem não pode ser trocada depois de criada. Se a VM é “pet” (configurada à mão, com estado no disco de SO), ela continua funcionando e você pode simplesmente parar de depender de reimage. Se ela é recriada com frequência, o caminho é criar a substituta a partir da oferta nova, migrar a aplicação e os dados e desligar a antiga. Se a VM nova não subir depois da troca, o troubleshooting com Boot Diagnostics mostra a tela do console e o log de inicialização.

Terraform: cuidado com o replace

No Terraform, a mudança é uma linha no bloco source_image_reference:

resource "azurerm_windows_virtual_machine" "app" {
  # ...
  source_image_reference {
    publisher = "MicrosoftWindowsServer"
    offer     = "windowsserver2022"   # antes: "WindowsServer"
    sku       = "2022-datacenter-azure-edition"
    version   = "latest"
  }
}

Só que, em azurerm_windows_virtual_machine, alterar source_image_reference força a recriação da VM. Rodar terraform apply numa VM de produção com essa mudança apaga e recria a máquina. Leia o terraform plan com atenção e procure por must be replaced. Para VMs existentes que você não quer recriar agora, uma saída é usar lifecycle { ignore_changes = [source_image_reference] } e deixar a oferta nova valendo só para as VMs criadas daqui para frente. Em azurerm_windows_virtual_machine_scale_set, a mesma mudança atualiza o modelo sem recriar o conjunto, e as instâncias seguem a política de upgrade configurada.

E o .NET? Não troque o 6 pelo 8

As imagens novas do Windows Server 2022 não trazem nenhuma versão do .NET. Se a sua aplicação rodava “de graça” porque o runtime já vinha na imagem, ela vai quebrar na primeira VM nova. A correção é instalar o runtime explicitamente no provisionamento (Custom Script Extension, DSC, imagem própria no Azure Compute Gallery ou o próprio pipeline de deploy).

Várias respostas por aí recomendam migrar a aplicação para o .NET 8. Cuidado: o suporte do .NET 8 termina em 10 de novembro de 2026, daqui a menos de dois meses. Quem migrar agora deve ir direto para o .NET 10, a versão LTS atual, que tem suporte até novembro de 2028. Não por acaso, o próprio e-mail da Microsoft orienta a abrir chamados de suporte escolhendo a versão .NET 10.

Checklist

1. Rodar a consulta do Resource Graph em todas as subscriptions e listar o que usa a oferta WindowsServer com SKU 2022.
2. Migrar primeiro os VMSS: trocar a oferta para windowsserver2022 e atualizar as instâncias com rolling upgrade.
3. Atualizar templates, módulos Terraform e pipelines que criam VMs novas. Trocar versões fixas por latest ou por uma versão ativa conferida.
4. Em VMs existentes gerenciadas por Terraform, revisar o plan antes de aplicar para não recriar máquina de produção sem querer.
5. Garantir que o runtime .NET é instalado no provisionamento, preferindo o .NET 10.
6. Criar um alerta do Azure Advisor para que avisos de depreciação cheguem ao time certo, e não só ao Owner da subscription.

Depreciação de imagem é uma coisa que vai se repetir: toda imagem do Marketplace um dia é aposentada. Quem tem a lista de VMs por imagem à mão e não fixa versão sem motivo resolve esse tipo de aviso em uma tarde, e não num incidente de sábado à noite, quando o VMSS precisa escalar e não consegue.

Referências oficiais

• Deprecated Azure Marketplace images FAQ — Microsoft Learn
• Breaking change for Windows Server 2022 image users with .NET 6 — Azure Compute Blog
• Migrate to new Marketplace Windows Server 2022 images — Microsoft Q&A
• Get-AzVMImageDeprecationStatus.ps1 — azure-support-scripts
• .NET support policy — Microsoft

Interessado em saber mais sobre esse assunto?