Migração Windows Server 2019 do VMware para Proxmox: corrigindo o erro de ativação 0xC004F00F

Após migrar um Windows Server 2019 de um host VMware para o Proxmox, não é raro a ativação ser perdida e surgir o erro 0xC004F00F. Este guia explica o motivo técnico, como identificar o tipo de licença (MAK/KMS/Retail/OEM) e traz um passo a passo confiável para reativar com segurança.

Índice

Visão geral do problema e do erro 0xC004F00F

Depois de converter a VM do VMware para o Proxmox, o Windows pode exibir a mensagem de que a chave está bloqueada (“the product key is blocked”) junto ao código 0xC004F00F — que, em termos simples, significa “Hardware ID binding is beyond level of tolerance”. Em outras palavras, o HWID (identificador de hardware usado para validar a licença) mudou tanto que o Windows passou a considerar a VM um “computador diferente”.

Essas mudanças decorrem de diferenças entre as plataformas de virtualização (controladores de disco e rede, BIOS/UEFI virtual, chipset, UUID/SMBIOS, recursos de CPU etc.). Se a variação exceder a tolerância, a ativação anterior deixa de valer e é necessário reativar.

Por que a migração VMware → Proxmox altera o HWID

Mesmo mantendo o mesmo disco do sistema, a VM “vista” pelo Windows no Proxmox não é idêntica à do VMware. Alguns exemplos de alterações que pesam no HWID:

Chipset e BIOS/UEFI virtual: VMware e Proxmox (KVM/QEMU) usam implementações diferentes (ex.: PC‑i440fx/Q35, SeaBIOS/OVMF UEFI).
Controladores de armazenamento: LSI Logic SAS ou PVSCSI no VMware vs. VirtIO‑SCSI, LSI SAS (megasas) ou SATA no Proxmox.
Placas de rede: VMXNET3 (VMware) vs. VirtIO, E1000/E1000e (Proxmox) e novos endereços MAC.
SMBIOS/UUID/Serial: a VM ganha novos identificadores se não forem preservados.
CPU exposta à VM: a identidade de CPU (vendor/features) difere entre “kvm64” e “host‑passthrough”.
Ordem/quantidade de dispositivos: mudar número de NICs, controladores e a ordem dos discos altera o perfil de hardware.

Somadas, essas diferenças elevam o “score” de mudança do HWID e disparam o erro 0xC004F00F.

Diagnóstico rápido: entenda qual licença você tem

Antes de agir, descubra o canal de licenciamento (MAK, KMS, Retail ou OEM) e verifique itens básicos de ambiente.

Identifique o tipo de chave

slmgr /dlv

Na janela exibida, procure por “Tipo de chave de licença” (MAK, KMS, Retail ou OEM). Como alternativa em PowerShell:

Get-CimInstance -ClassName SoftwareLicensingProduct `
  | Where-Object { $.PartialProductKey -and $.LicenseStatus -ne $null } `
  | Select-Object Name, Description, LicenseStatus, PartialProductKey `
  | Format-Table -Auto

Cheque hora, fuso e sincronização

Falhas de ativação on‑line são comuns quando a data/hora estão incorretas.

w32tm /query /status
tzutil /g
w32tm /resync

Verifique conectividade para KMS (se aplicável)

nslookup -type=srv vlmcs.tcp
Test-NetConnection -ComputerName &lt;kms-host&gt; -Port 1688

Se o KMS estiver inacessível ou não resolvido via SRV DNS, a ativação KMS falhará.

Registre identificadores atuais (útil para análise e auditoria)

wmic csproduct get uuid
wmic baseboard get product,serialnumber
Get-NetAdapter | Format-Table Name, MacAddress, Status
slmgr /dli

Consulte os logs da ativação

Event Viewer > Applications and Services Logs > Microsoft‑Windows‑Security‑SPP > Software Protection Platform Service. As entradas detalham códigos e causas.

Planos de ação por cenário de licenciamento

Escolha o fluxo conforme o canal de licença:

Cenário de licenciamento	Ações recomendadas	Observações
MAK (Multiple Activation Key)	1) Durante o período de carência (“Out‑of‑Tolerance”), tente ativar pela Internet ou via telefone. 2) Se a chave permanecer bloqueada, contate o Microsoft Licensing Activation Center para liberar nova ativação. 3) Se necessário, reinstale a chave: `slmgr /ipk <nova-chave MAK>` e execute `slmgr /ato`.	O MAK tem contador de ativações. Tenha em mãos ID de instalação (`slui 4`) e comprovantes de aquisição.
KMS (Key Management Service)	1) Reinicie o Windows para forçar reavaliação do HWID. 2) Execute `slmgr.vbs /ato`. 3) Se falhar, verifique SRV DNS `vlmcs.tcp` e porta 1688; opcionalmente aponte o host: `slmgr /skms kms.seudominio:1688` e repita `/ato`. 4) Se persistir, corrija DNS/Firewall/KMS host.	Exige alcance a um KMS válido e chave GVLK correspondente à edição (Standard/Datacenter).
Retail ou OEM	1) Reinstale a chave: `slmgr /ipk <chave-Retail-ou-OEM>`. 2) Ative: `slmgr /ato` ou `slui 4` para telefone. 3) Se bloqueada, contate o suporte para liberação.	Licenças OEM costumam ser vinculadas ao hardware original e podem não ser transferíveis entre hipervisores/hosts.

Passo a passo detalhado de correção

Fluxo MAK (Volume por múltiplas ativações)

Confirme a edição do Windows Server (Standard/Datacenter) e o canal MAK em slmgr /dlv.
Tente slmgr /ato. Se retornar “Out of Tolerance”, continue.
Reinstale a chave se necessário: slmgr /ipk <nova-chave MAK> slmgr /ato
Se a ativação on‑line falhar, use slui 4 para ativação telefônica. Tenha pronto:
- ID de instalação exibido pelo assistente;
- número do contrato de volume ou comprovante de compra;
- registro da migração (datas, origem VMware, destino Proxmox).
Se o contador MAK foi atingido, solicite liberação de uma nova ativação informando a substituição de hardware virtual.

Fluxo KMS

Garanta que a chave instalada é do tipo GVLK correspondente à edição do Windows Server 2019. Caso tenha uma Retail/MAK instalada, troque para a GVLK da sua edição: slmgr /ipk <chave-GVLK-da-sua-edição>
Permita que o cliente encontre o KMS por DNS (SRV vlmcs.tcp) ou defina manualmente: slmgr /skms kms.seudominio:1688
Ative: slmgr /ato
Se não ativar:
- Valide DNS e firewall (porta TCP 1688) com Test-NetConnection.
- Verifique o event log SPP e a saúde do host KMS (serviço em execução, contador de ativações, SKU suportados).
- Quando DNS estiver correto, remova override do KMS: slmgr /ckms e repita /ato.

Fluxo Retail/OEM

Se a chave atual for inválida para a VM migrada, reinstale: slmgr /upk slmgr /cpky  slmgr /ipk <chave-Retail-ou-OEM> slmgr /ato Atenção: /upk remove a chave; use apenas se você tem a chave correta para reinstalar.
Ativação por telefone (slui 4) é o caminho quando a validação on‑line acusa troca de hardware.
Em OEM, verifique a elegibilidade de transferência: muitas licenças ficam atreladas ao hardware original e podem não ser reatribuídas a outra VM/host.

Quando contatar a Microsoft

Você atingiu o limite de ativações MAK.
O erro persiste após corrigir hora, rede e KMS.
Houve divergência entre SKU/licença e edição instalada (ex.: Standard vs Datacenter).

Tenha em mãos o ID de instalação (slui 4), número do contrato de volume (se houver) e evidências da migração (logs, prints do slmgr /dlv).

Boas práticas de V2V para reduzir a chance do 0xC004F00F

Nem sempre é possível evitar a reativação ao trocar de hipervisor, mas estas medidas diminuem o “impacto” no HWID:

Preserve identificadores: copie o VMware UUID (na VM: wmic csproduct get uuid) e configure um UUID/SMBIOS estável no Proxmox. Replique MAC addresses quando possível (evite colisões na rede).
Mantenha número/ordem de dispositivos: preserve quantidade de NICs, controladores e a ordem dos discos (mesmo bus e index).
Escolha de controladores: se a VM no VMware usava LSI Logic SAS, considere usar LSI SAS (megasas) no Proxmox para reduzir mudanças bruscas; quando adotar VirtIO‑SCSI, instale previamente os drivers VirtIO no Windows.
Modelo de NIC: E1000/E1000e facilita a inicialização sem drivers adicionais; VirtIO oferece melhor desempenho, mas altera a “impressão” de hardware (instale o driver antes).
CPU: usar “host‑passthrough” no Proxmox geralmente expõe um conjunto de features mais próximo do host físico e evita mudanças dramáticas de assinatura de CPU.
UEFI vs BIOS: não altere de BIOS para UEFI (ou vice‑versa) durante a migração, a menos que seja um objetivo explícito com planejamento.
Drivers e ferramentas: instale VirtIO e, se aplicável, o QEMU Guest Agent antes da migração para minimizar problemas pós‑boot.
Snapshot/backup: crie snapshot/backup antes de tentar reativar ou trocar chaves.

Exemplos úteis no Proxmox (ajuste para seu ambiente)

# Definir MAC estável e VirtIO para a NIC 0
qm set <vmid> -net0 virtio=<MAC>,bridge=vmbr0

Definir controladora SCSI em VirtIO-SCSI e anexar disco já convertido

qm set \ -scsihw virtio-scsi-pci
qm set \ -scsi0 local-lvm\:vm-\-disk-0

Expor CPU do host (pass-through)

qm set \ -cpu host

Ajustar SMBIOS (UUID) — verifique o UUID da VM original e aplique

qm set \ -smbios1 uuid=\

Dica: converter o disco do VMware para QCOW2/RAW via qemu-img convert e importar com qm importdisk ajuda a preservar a ordem e nomes esperados pelo Windows.

Scripts práticos de verificação

Resumo de licenças ativas

Get-CimInstance -ClassName SoftwareLicensingProduct `
 | Where-Object { $.PartialProductKey -and $.LicenseStatus -eq 1 } `
 | Select-Object Name, Description, PartialProductKey `
 | Format-Table -Auto

Forçar restauração de componentes de ativação (use com cautela)

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Execute apenas se suspeitar de corrupção de componentes. Não use slmgr /rearm indiscriminadamente (há limite de rearms).

Cliente KMS: diagnóstico em lote

$kms = "&lt;kms-host&gt;"
Test-NetConnection -ComputerName $kms -Port 1688
slmgr /dlv
slmgr /ato

Erros relacionados: como interpretar rapidamente

Código	Significado comum	Ação sugerida
0xC004F00F	Mudança de HWID além da tolerância após migração.	Reativar conforme o canal (MAK/KMS/Retail), considerar ativação telefônica, ou solicitar liberação.
0xC004F074	Cliente KMS não encontrou host KMS ou falha de comunicação.	Verificar DNS SRV `vlmcs.tcp`, porta 1688, apontar com `slmgr /skms`.
0xC004C003	Chave de produto bloqueada/invalidada.	Confirmar canal da chave, reinstalar chave correta, acionar suporte de licenciamento.
0xC004C008	Limite de ativações excedido.	Ativar via telefone e justificar substituição de hardware virtual ou solicitar liberação.

FAQ — Perguntas frequentes

OEM pode ser reaprovecida após migrar de VMware para Proxmox?
Na maioria dos casos, não. Licenças OEM de Windows Server costumam estar vinculadas ao hardware original. Para VMs, prefira Volume (KMS/MAK) ou Retail transferível, conforme seu contrato.

Usar VirtIO altera a ativação?
A troca de driver/controle influi no HWID. Instalar VirtIO antes da migração e manter número/ordem de dispositivos reduz o impacto.

Alterar de BIOS para UEFI (ou vice‑versa) é problema?
Sim, é uma mudança significativa do ponto de vista do HWID. Evite durante a migração a menos que seja necessário.

Preciso formatar para reativar?
Quase nunca. Na maioria dos casos, slmgr /ato, reinstalação da chave correta e/ou ativação telefônica resolvem.

Posso clonar a VM já ativada para várias VMs?
Não. Cada VM deve ter sua própria licença válida. Clonagem sem sysprep e sem adequação de licenças viola os termos e tende a quebrar a ativação.

Checklist de pré‑migração

Coletar: edição do SO, canal de licença, slmgr /dlv, UUID (wmic csproduct get uuid), MACs, ordem e bus dos discos, quantidade de NICs.
Instalar drivers VirtIO e (opcional) QEMU Guest Agent na VM ainda no VMware.
Planejar no Proxmox: chipset (i440fx vs Q35), BIOS/UEFI, controladores (VirtIO‑SCSI/LSI), modelo de NIC, CPU host‑passthrough.
Programar janela de manutenção e snapshot/backup completo.

Checklist de pós‑migração

Confirmar boot sem BSOD, serviços de rede e hora sincronizada.
Validar conectividade com KMS (se aplicável) e repetir slmgr /ato.
Se Retail/MAK: reinstalar chave e ativar; se bloqueada, usar slui 4.
Registrar o novo estado (slmgr /dli, /dlv) e arquivar com prints.
Criar snapshot após a ativação bem‑sucedida.

Resumo prático

O 0xC004F00F ocorre porque a migração VMware → Proxmox altera significativamente a “impressão” de hardware da VM. O caminho mais rápido para resolver é:

Descobrir o canal da licença com slmgr /dlv.
Corrigir hora e rede; para KMS, garantir DNS/porta 1688.
Executar slmgr /ato (KMS/MAK) ou reinstalar a chave correta (/ipk) e ativar.
Se a chave estiver bloqueada ou limite atingido, slui 4 e contato com o centro de licenciamento para liberação.
Para futuras migrações, preserve UUID/MAC, mantenha ordem/quantidade de dispositivos e planeje controladores e firmware para minimizar variações do HWID.

Com esses passos, a reativação do Windows Server 2019 após a migração para o Proxmox torna‑se previsível, auditável e muito mais rápida.