Se sigue mostrando la referencia de activación de Windows
Se aplica a: ✔️ Máquinas virtuales Windows que ejecutan Windows Server 2022 Datacenter Azure Edition
En este documento se describe cómo resolver la presencia continua de una marca de agua de activación de Windows en máquinas virtuales de Microsoft Azure.
Requisitos previos
Síntomas
Cuando se usa una máquina virtual (VM) de Azure que ejecuta Windows Server 2022 Datacenter Azure Edition, se producen los siguientes síntomas:
Verá una marca de agua en el escritorio que contiene el siguiente mensaje:
Activar Windows. Vaya a Configuración para activar Windows.
Esta marca de agua indica que el estado de activación de Windows no es original.
Al abrir la aplicación Configuración y seleccionar Activación del sistema>, el campo Estado de la aplicación indica un error de activación.
Al abrir una ventana del símbolo del sistema con privilegios elevados y ejecutar el siguiente script de activación por volumen slmgr.vbs, la salida muestra que la activación de Servicio de administración de claves s (KMS) se realiza correctamente, pero los dos primeros síntomas permanecen:
cscript c:\windows\system32\slmgr.vbs /dlvAl reiniciar o iniciar sesión en la máquina virtual, se muestra una ventana emergente con el mensaje siguiente:
La máquina virtual de Windows Server 2022 Datacenter Azure Edition se ha desactivado porque no se está ejecutando en Azure o en un hipervisor de Azure Stack compatible o que no ha habilitado las ventajas de Azure en Azure Stack compatibles. Para habilitar las ventajas de Azure, vaya a la configuración del clúster en Windows Admin Center > Habilitar ventajas de Azure.
Causa 1: Problema de conexión de Azure Instance Metadata Service
La máquina virtual de Azure no puede establecer una conexión con el punto de conexión de Azure Instance Metadata Service (IMDS), que es esencial para obtener el token de activación.
Cómo determinar si el sistema operativo invitado de la máquina virtual puede comunicarse correctamente con IMDS
Ejecute el siguiente script de PowerShell en función de la versión de PowerShell para comprobar si los metadatos se reciben de IMDS.
PowerShell 6 y versiones 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 y versiones 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
Si recibe una respuesta correcta, verá la información de metadatos de la máquina virtual, como la siguiente salida:
compute
-------
@{azEnvironment=AzurePublicCloud; customData=; evictionPolicy=; isHostCompatibilityLayerVm=true; licenseType=; location=eastus; name=testWs2022; offer=WindowsServer; ...
Si no es así, significa que la conexión al servidor de conexión IMDS está bloqueada en algún lugar y se debe permitir el acceso a él. La dirección IP del servidor IMDS es 169.254.169.254. Para corregir el problema de conexión, vaya a Solución 1: Omitir servidores proxy web dentro de la máquina virtual.
Causa 2: Problema relacionado con el certificado
Los certificados intermedios que son cruciales para el proceso de activación han expirado.
Para más información, consulte Azure Instance Metadata Service-Attested data TLS: Los cambios críticos se encuentran aquí.
Cómo determinar si faltan certificados
Ejecute el siguiente script de PowerShell para comprobar si faltan certificados:
# 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
}
Si faltan certificados, verá una salida similar a la siguiente:
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 corregir el problema del certificado, vaya a Solución 2: Asegúrese de que los firewalls y servidores proxy están configurados para permitir descargas de certificados.
Solución 1: Omitir servidores proxy web dentro de la máquina virtual
IMDS es una API REST que está disponible en una dirección IP no enrutable conocida (169.254.169.254). Solo se puede acceder al punto de conexión de IMDS desde la máquina virtual en el siguiente URI: http://169.254.169.254/metadata/instance. La comunicación entre la VM e IMDS nunca sale del host. Haga que los clientes HTTP omitan los servidores proxy web dentro de la máquina virtual mientras consultan IMDS. Además, asegúrese de que los clientes tratan la 169.254.169.254 dirección IP de la misma manera que tratan la dirección IP 168.63.129.16. Para comprobar que existe esta conexión de red directa, siga estos pasos:
Nota:
168.63.129.16 es una dirección IP pública virtual propiedad de Microsoft que se usa para comunicarse con los recursos de Azure.
Para ver la tabla de enrutamiento local en la máquina virtual, ejecute el comando route print :
route printPara buscar la entrada de enrutamiento del destino IMDS, vaya a la
Active Routessección de laIPv4 Route Tablesalida y busque la fila que contiene la169.254.169.254dirección IP de laNetwork Destinationcolumna.Destino de red Máscara de red Gateway Interfaz Métrica 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 Vínculo en línea 127.0.0.1 331 127.0.0.1 255.255.255.255 Vínculo en línea 127.0.0.1 331 127.255.255.255 255.255.255.255 Vínculo en línea 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 ... ... ... ... ... En la salida de la tabla de rutas de ejemplo, la entrada de destino IMDS se encuentra en la última fila y la interfaz de red correspondiente es el valor de la
Interfacecolumna dentro de esa fila. (En este ejemplo, la interfaz de red es172.16.69.7.Para ver la configuración de IP de la máquina virtual, ejecute el comando ipconfig :
ipconfig /allEn la salida del comando ipconfig, busque la configuración ip en la que el
IPv4 Addresscampo coincide con el valor de la interfaz de red de la 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 ...En la salida ipconfig de ejemplo, la configuración de IP que contiene el valor de la interfaz de red de la entrada IMDS es
Ethernet adapter Ethernet.En la configuración de IP que ha localizado, copie la dirección de Control de acceso multimedia (MAC) y la dirección IP privada principal que usa la máquina virtual. La dirección MAC se muestra en el
Physical Addresscampo y la dirección IP privada principal se muestra en elIPv4 Addresscampo . En este ejemplo, la dirección MAC y la dirección IP privada principal son00-0D-3A-E5-1C-C0y172.16.69.7, respectivamente.Compruebe si las direcciones IP privadas mac y principal que Usa Azure para la máquina virtual coinciden con la dirección MAC y la dirección IP privada principal que el sistema operativo invitado de la máquina virtual usa realmente (las direcciones que encontró en el paso anterior). Para determinar qué usa Azure como dirección MAC, use la CLI de Azure. Para determinar qué usa Azure como dirección IP privada principal, examine la configuración de red en Azure Portal.
Búsqueda de la dirección MAC (mediante la CLI de Azure en un script de PowerShell)
Ejecute el siguiente script de PowerShell que invoca comandos de la CLI de Azure. Este script invoca el comando az vm nic list para recopilar los nombres de las interfaces de red en la máquina virtual. A continuación, invoca el comando az vm nic show para mostrar el nombre de cada interfaz de red, si esa interfaz de red es la interfaz de red principal (
TrueoFalse) y la dirección MAC de la interfaz de red:Nota:
En los comandos, "nic" representa la interfaz de red, no una tarjeta de interfaz de red.
# 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-C0Busque la dirección IP privada principal (mediante Azure Portal):
En el portal Azure, busque y seleccione Máquinas virtuales.
En la lista de máquinas virtuales, seleccione el nombre de la máquina virtual.
En la pestaña Propiedades de la página Información general de la máquina virtual, busque el encabezado Redes.
En el campo Dirección IP privada, copie la dirección IPv4 mostrada.
Si las direcciones MAC o las direcciones IP privadas principales no son idénticas entre Azure y el sistema operativo invitado de la máquina virtual, use varios comandos de ruta para actualizar la tabla de enrutamiento para que la interfaz de red principal y la dirección IP estén dirigidas.
Solución 2: Asegúrese de que los firewalls y servidores proxy están configurados para permitir descargas de certificados
Compruebe si kb 5036909 está instalado. Si no es así, instálela. Puede obtenerlo desde el catálogo de Microsoft Update.
Si ha instalado la actualización pero sigue teniendo el problema, compruebe que los firewalls y servidores proxy del sistema están configurados para permitir la descarga de certificados. Para obtener más información, consulte Descargas de certificados y listas de revocación.
Como alternativa, puede descargar e instalar todos los certificados directamente desde las cadenas raíz y subordinada de la entidad de certificación.
Nota:
Asegúrese de seleccionar la ubicación del almacén como Máquina local en el Asistente para la instalación.
Abra el símbolo del sistema como administrador, vaya a c:\windows\system32 y ejecute fclip.exe.
Reinicie la máquina virtual o cierre la sesión y vuelva a iniciar sesión. Verá que la marca de agua de la página principal ya no se muestra y el campo Estado de la aplicación en la pantalla Activación de configuración>informa de que se ha realizado correctamente.
Más información
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.