A marca-d'água de ativação do Windows continua sendo exibida

Artigo
07/30/2024

Aplica-se a: ✔️ VMs do Windows que executam o Windows Server 2022 Datacenter Azure Edition

Este documento discute como resolver a presença contínua de uma marca d'água de ativação do Windows em máquinas virtuais do Microsoft Azure.

Pré-requisitos

CLI do Azure

Sintomas

Ao usar uma VM (máquina virtual) do Azure que executa o Windows Server 2022 Datacenter Azure Edition, você encontra os seguintes sintomas:

Você verá uma marca d'água na área de trabalho que contém a seguinte mensagem:

Ative o Windows. Vá para Configurações para ativar o Windows.

Essa marca d'água indica que o status de ativação do Windows não é original.
Quando você abre o aplicativo Configurações e seleciona Ativação do sistema>, o campo Estado do aplicativo indica uma falha de ativação.
Quando você abre uma janela de Prompt de Comando com privilégios elevados e executa o seguinte script de ativação de volume slmgr.vbs, a saída mostra que a ativação do KMS (Serviços de Gerenciamento de Chaves) foi bem-sucedida, mas os dois primeiros sintomas permanecem:
```
cscript c:\windows\system32\slmgr.vbs /dlv
```
Quando você reinicia ou entra na VM, uma janela pop-up com a seguinte mensagem é exibida:

Sua VM do Windows Server 2022 Datacenter Azure Edition foi desativada porque você não está executando no Azure ou em um hipervisor do Azure Stack com suporte ou que você não habilitou os benefícios do Azure no Azure Stack com suporte. Para habilitar os benefícios do Azure, acesse as configurações do cluster no Windows Admin Center > Habilitar benefícios do Azure.

Causa 1: problema de conexão do Serviço de Metadados de Instância do Azure

A VM do Azure não pode estabelecer uma conexão com o ponto de extremidade do IMDS (Serviço de Metadados de Instância do Azure), que é essencial para obter o token de ativação.

Como determinar se o sistema operacional convidado da VM pode se comunicar com êxito com o IMDS

Execute o script do PowerShell a seguir, dependendo da sua versão do PowerShell, para verificar se os metadados são recebidos do IMDS.

PowerShell 6 e versões posteriores

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri 
http://169.254.169.254/metadata/attested/document?api-version=2020-09-01
| Format-List * | Out-File "IMDSResponse1.txt"

PowerShell 5 e versões anteriores

$Proxy=New-object System.Net.WebProxy
$WebSession=new-object Microsoft.PowerShell.Commands.WebRequestSession
$WebSession.Proxy=$Proxy
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/instance?api-version=2021-02-01" -WebSession $WebSession

Se você obtiver uma resposta bem-sucedida, verá as informações de metadados da VM, como a seguinte saída:

compute                                                                                                                                                                  
-------                                                                                                                                                                  
@{azEnvironment=AzurePublicCloud; customData=; evictionPolicy=; isHostCompatibilityLayerVm=true; licenseType=; location=eastus; name=testWs2022; offer=WindowsServer; ...

Caso contrário, significa que a conexão com o servidor de transmissão do IMDS está bloqueada em algum lugar e o acesso a ele precisa ser permitido. O IP do servidor IMDS é 169.254.169.254. Para corrigir o problema de conexão, vá para Solução 1: ignorar proxies da Web na VM.

Os certificados intermediários que são cruciais para o processo de ativação expiraram.

Para obter mais informações, consulte TLS de dados atestados pelo serviço de metadados da instância do Azure: alterações críticas estão aqui.

Como determinar se algum certificado está ausente

Execute o seguinte script do PowerShell para verificar se há certificados ausentes:

# Get the signature
# Powershell 5.1 does not include -NoProxy
$attestedDoc = Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri http://169.254.169.254/metadata/attested/document?api-version=2018-10-01
#$attestedDoc = Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri http://169.254.169.254/metadata/attested/document?api-version=2018-10-01
 
# Decode the signature
$signature = [System.Convert]::FromBase64String($attestedDoc.signature)
 
# Get certificate chain
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]($signature)
$chain = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Chain
 
if (-not $chain.Build($cert)) {
   # Print the Subject of the issuer
   Write-Host $cert.Subject
   Write-Host $cert.Thumbprint
   Write-Host "------------------------"
   Write-Host $cert.Issuer
   Write-Host "------------------------"
   Write-Host "Certificate not found: '$($cert.Issuer)'" -ForegroundColor Red
   Write-Host "Please refer to the following link to download missing certificates:" -ForegroundColor Yellow
   Write-Host "https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-ca-details?tabs=certificate-authority-chains" -ForegroundColor Yellow
} else {
   # Print the Subject of each certificate in the chain
   foreach($element in $chain.ChainElements) {
       Write-Host $element.Certificate.Subject
       Write-Host $element.Certificate.Thumbprint
       Write-Host "------------------------"
   }
 
   # Get the content of the signed document
   Add-Type -AssemblyName System.Security
   $signedCms = New-Object -TypeName System.Security.Cryptography.Pkcs.SignedCms
   $signedCms.Decode($signature);
   $content = [System.Text.Encoding]::UTF8.GetString($signedCms.ContentInfo.Content)
   Write-Host "Attested data: " $content
   $json = $content | ConvertFrom-Json
}

Se algum certificado estiver ausente, você verá uma saída semelhante à seguinte:

CN=metadata.azure.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US
3ACCC393D3220E40F09A69AC3251F6F391172C32
------------------------
CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US
------------------------
Certificate not found: 'CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US'
Please refer to the following link to download missing certificates:
https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-ca-details?tabs=certificate-authority-chains

Para corrigir o problema do certificado, vá para Solução 2: verifique se os firewalls e proxies estão configurados para permitir downloads de certificados.

Solução 1: Ignorar proxies da Web na VM

O IMDS é uma API REST disponível em um endereço IP conhecido e não roteável (169.254.169.254). O ponto de extremidade do IMDS pode ser acessado de dentro da VM somente no seguinte URI: http://169.254.169.254/metadata/instance. A comunicação entre a VM e a IMDS nunca sai do host. Faça com que seus clientes HTTP ignorem os proxies da Web na VM enquanto consultam o IMDS. Além disso, certifique-se de que os clientes tratem o 169.254.169.254 endereço IP da mesma maneira que tratam o endereço IP 168.63.129.16. Para verificar se essa conexão de rede direta existe, siga estas etapas:

Observação

168.63.129.16 é um endereço IP público virtual de propriedade da Microsoft usado para se comunicar com recursos do Azure.

Para exibir a tabela de roteamento local em sua VM, execute o comando route print :
```
route print
```

Para localizar a entrada de roteamento para o destino IMDS, vá para a Active Routes seção da IPv4 Route Table saída e localize a linha que contém o 169.254.169.254 endereço IP na Network Destination coluna.

Destino da rede	Netmask	Gateway	Interface	Metric
0.0.0.0	0.0.0.0	172.16.69.1	172.16.69.7	10
127.0.0.0	255.0.0.0	No link	127.0.0.1	331
127.0.0.1	255.255.255.255	No link	127.0.0.1	331
127.255.255.255	255.255.255.255	No link	127.0.0.1	331
168.63.129.16	255.255.255.255	172.16.69.1	172.16.69.7	11
169.254.169.254	255.255.255.255	172.16.69.1	172.16.69.7	11
...	...	...	...	...

Na saída da tabela de rotas de exemplo, a entrada de destino do IMDS está na última linha e a interface de rede correspondente é o valor na Interface coluna dentro dessa linha. (Neste exemplo, a interface de rede é 172.16.69.7.)

Para exibir a configuração de IP da VM, execute o comando ipconfig :
```
ipconfig /all
```

Na saída do comando ipconfig, localize a configuração de IP na qual o IPv4 Address campo corresponde ao valor da interface de rede da entrada IMDS (172.16.69.7):

...
Ethernet adapter Ethernet:

Connection-specific DNS Suffix  . : xic3mnxjiefupcwr1mcs1rjiqa.cx.internal.cloudapp.net
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 00-0D-3A-E5-1C-C0
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::3166:ce5a:2bd5:a6d1%3(Preferred)
IPv4 Address. . . . . . . . . . . : 172.16.69.7(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
...

Na saída ipconfig de exemplo, a configuração de IP que contém o valor da interface de rede da entrada IMDS é Ethernet adapter Ethernet.

Na configuração de IP que você localizou, copie o endereço MAC (Controle de Acesso à Mídia) e o endereço IP privado primário que a VM usa. O endereço MAC é mostrado no Physical Address campo e o endereço IP privado principal é mostrado no IPv4 Address campo. Neste exemplo, o endereço MAC e o endereço IP privado primário são 00-0D-3A-E5-1C-C0 e 172.16.69.7, respectivamente.
Verifique se o MAC e os endereços IP privados primários que o Azure usa para a VM correspondem ao endereço MAC e ao endereço IP privado primário que o sistema operacional convidado da VM realmente usa (os endereços encontrados na etapa anterior). Para determinar o que o Azure usa como endereço MAC, use a CLI do Azure. Para determinar o que o Azure usa como o endereço IP privado primário, examine a configuração de rede no portal do Azure.
- Localizar o endereço MAC (usando a CLI do Azure em um script do PowerShell)
  
  Execute o script do PowerShell a seguir que invoca comandos da CLI do Azure. Esse script invoca o comando az vm nic list para coletar os nomes dos adaptadores de rede em sua VM. Em seguida, ele invoca o comando az vm nic show para exibir o nome de cada adaptador de rede, se esse adaptador de rede é o adaptador de rede primário (True ou False) e o endereço MAC do adaptador de rede:
  
  Observação
  
  Nos comandos, "nic" representa a interface de rede, não uma placa de interface de rede.
```
# Placeholder variable definitions
$ResourceGroup = "<resource-group-name>"
$VmName = "<virtual-machine-name>"

# Code
$NicNames = az vm nic list --resource-group $ResourceGroup --vm-name $VmName |
    ConvertFrom-Json | Foreach-Object { $_.id.Split('/')[-1] }
foreach($NicName in $NicNames)
{
    az vm nic show --resource-group $ResourceGroup --vm-name $VmName --nic $NicName |
        ConvertFrom-Json | Format-Table -Property name, primary, macAddress
}
```
```
name       primary macAddress
----       ------- ----------
wintest767    True 00-0D-3A-E5-1C-C0
```
- Localize o endereço IP privado primário (usando o portal do Azure):
  1. No portal do Azure, procure e clique em Máquinas virtuais.
  2. Na lista de VMs, selecione o nome da sua VM.
  3. Na guia Propriedades da página Visão geral da VM, localize o cabeçalho Rede.
  4. No campo Endereço IP privado, copie o endereço IPv4 exibido.
Se os endereços MAC ou os endereços IP privados primários não forem idênticos entre o Azure e o sistema operacional convidado da VM, use vários comandos de rota para atualizar a tabela de roteamento para que o adaptador de rede primário e o endereço IP sejam direcionados.

Solução 2: verifique se os firewalls e proxies estão configurados para permitir downloads de certificados

Verifique se o KB 5036909 está instalado. Caso contrário, Instale-o. Você pode obtê-lo no Catálogo do Microsoft Update.
Se você instalou a atualização, mas ainda encontrou o problema, verifique se os firewalls e proxies do seu sistema estão configurados para permitir o download de certificados. Para obter mais informações, consulte Downloads de certificados e listas de revogação.

Como alternativa, você pode baixar e instalar todos os certificados diretamente das cadeias de autoridade de certificação raiz e subordinada.

Observação

Certifique-se de selecionar o local da loja como Máquina Local no assistente de instalação.
Abra o Prompt de Comando como administrador, navegue até c:\windows\system32 e execute fclip.exe.
Reinicie a VM ou saia e entre novamente. Você verá que a marca d'água na home page não é mais exibida e o campo Estado do aplicativo na tela Ativação de configurações>relata sucesso.

Mais informações

Solucionar problemas de ativação de máquina virtual do Microsoft Azure

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.

Partilhar via

A marca-d'água de ativação do Windows continua sendo exibida

Pré-requisitos

Sintomas

Causa 1: problema de conexão do Serviço de Metadados de Instância do Azure

Como determinar se o sistema operacional convidado da VM pode se comunicar com êxito com o IMDS

Como determinar se algum certificado está ausente

Solução 1: Ignorar proxies da Web na VM

Solução 2: verifique se os firewalls e proxies estão configurados para permitir downloads de certificados

Mais informações

Entre em contato conosco para obter ajuda

Comentários

Recursos adicionais

Partilhar via

A marca-d'água de ativação do Windows continua sendo exibida

Pré-requisitos

Sintomas

Causa 1: problema de conexão do Serviço de Metadados de Instância do Azure

Como determinar se o sistema operacional convidado da VM pode se comunicar com êxito com o IMDS

Causa 2: problema relacionado ao certificado

Como determinar se algum certificado está ausente

Solução 1: Ignorar proxies da Web na VM

Solução 2: verifique se os firewalls e proxies estão configurados para permitir downloads de certificados

Mais informações

Entre em contato conosco para obter ajuda

Comentários

Recursos adicionais