Error 0xC004F074: "No se pudo contactar con ningún servicio de administración de claves (KMS)

Applies to: ✔️ máquinas virtuales de Windows

Resumen

En este artículo se explica cómo resolver el error 0xC004F074 que se produce al intentar activar una máquina virtual (VM) de Windows en Microsoft Azure.

Requisitos previos

• PowerShell
• El script Administrador de licencias de software (slmgr.vbs)
• La herramienta PsPing

Síntomas

Al intentar activar una máquina virtual de Microsoft Azure Windows, aparece el siguiente mensaje de error en el Host de secuencias de comandos de Windows:

**Error: 0xC004F074** The Software Licensing Service reported that the computer could not be activated. No Key Management Service (KMS) could be contacted. Please see the Application Event Log for additional information.

Causa

La máquina virtual no se puede conectar al servicio KMS para la activación. Si usa un KMS de Azure para la activación (la selección predeterminada), la solicitud de activación debe provenir de una dirección IP pública de Azure. Entre las posibles causas de este error de conectividad se incluyen las siguientes:

• Tunelización forzada, en la que enruta todo el tráfico fuera de Azure (normalmente a un entorno local) mediante Azure ExpressRoute o una aplicación virtual de red.

• Tráfico bloqueado por una aplicación virtual de red o un equilibrador de carga interno estándar.

Investigación

Para determinar la causa específica del problema, siga estos pasos.

Paso 1: Configurar la clave de configuración del cliente kmS adecuada

slmgr.vbs /dlv

Para la VM que cree a partir de una imagen personalizada, debe configurar la clave de configuración del cliente KMS adecuada para la VM.

1. En una ventana del símbolo del sistema con privilegios elevados, ejecute el siguiente comando de script del Administrador de licencias de software:

   cscript c:\windows\system32\slmgr.vbs /dlv
   

2. Compruebe el valor Description en la salida para determinar si la máquina virtual se creó desde medios con licencia de minorista (RETAIL canal) o de volumen (VOLUME_KMSCLIENT).

3. Si la salida del comando anterior indica el RETAIL canal, ejecute los siguientes comandos de script del Administrador de licencias de software. El primer comando establece la clave de configuración del cliente KMS para la versión de Windows Server que use. El segundo comando fuerza otro intento de activación.

   cscript c:\windows\system32\slmgr.vbs /ipk <kms-client-setup-key>
   cscript c:\windows\system32\slmgr.vbs /ato
   

   Por ejemplo, si usa Windows Server 2016 Datacenter, el primer comando aparece de la siguiente manera:

   cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG
   

Paso 2: Comprobar si la máquina virtual está detrás de un equilibrador de carga interno Standard SKU.

Para comprobar si la máquina virtual está detrás de un equilibrador de carga interno de SKU estándar que bloquea el tráfico saliente de Internet de forma predeterminada, siga estos pasos:

1. En el portal Azure, busque y seleccione Máquinas virtuales.

2. En la lista de máquinas virtuales, seleccione el nombre de la máquina virtual.

3. En el panel de menús de la máquina virtual, busque el encabezado Redes y, a continuación, seleccione Equilibrio de carga. Si ve un mensaje que indica No hay recursos de balanceo de carga para mostrar, la máquina virtual no está detrás de ningún balanceador de carga. En este caso, puede ir a Paso 3: Comprobar la conectividad entre la máquina virtual y Azure servicio KMS.

4. Si ve un recurso de equilibrador de carga, seleccione el nombre del equilibrador para ir a la página de Vista general del equilibrador de carga.

5. En el panel de menús del equilibrador de carga, seleccione Propiedades.

6. En la página Propiedades , busque los valores de SKU y Tipo de equilibrio de carga y, a continuación, vea la tabla siguiente para obtener conclusiones.

   Valores de SKU y tipo de equilibrio de carga	Conclusión
   El valor de SKU es Estándar y el valor tipo de equilibrio de carga es Privado.	La máquina virtual está detrás de un equilibrador de carga interno de SKU estándar que bloquea el tráfico saliente de Internet de forma predeterminada. Para habilitar la conectividad saliente, vaya a la solución 2 (para el equilibrador de carga interno estándar): use una puerta de enlace de traducción de direcciones de red (NAT) o un equilibrador de carga público estándar.
   El valor de SKU no es Estándar y el valor del tipo de equilibrio de carga es Público.	La máquina virtual no está detrás de un equilibrador de carga interno de SKU estándar y el tráfico saliente de Internet no está bloqueado de forma predeterminada. Vaya a Paso 3: Compruebe la conectividad entre la máquina virtual y Azure servicio KMS.

Paso 3: Comprobación de la conectividad entre la máquina virtual y Azure servicio KMS

1. Borre las configuraciones existentes del servidor KMS y asegúrese de que la máquina virtual está configurada para usar el servidor kmS de Azure correcto. Para realizar esta comprobación, ejecute el siguiente comando de script del Administrador de licencias de software:

   slmgr.vbs /ckms
   Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms azkms.core.windows.net:1688"

Este comando devuelve el texto siguiente:

El nombre de máquina del Servicio de administración de claves se ha establecido correctamente en azkms.core.windows.net:1688.

1. Asegúrese de que el firewall de la máquina virtual no bloquea el tráfico de red saliente al punto de conexión de KMS en el puerto 1688. Para comprobar este estado, aplique una de las siguientes opciones:

• Compruebe la conectividad mediante la ejecución del cmdlet Test-NetConnection en PowerShell:

     Test-NetConnection azkms.core.windows.net -port 1688

Si se permite el intento de conexión, el cmdlet muestra "TcpTestSucceeded: True" en el texto de salida.

• Compruebe la conectividad mediante la ejecución de la herramienta PsPing:

     .\psping.exe azkms.core.windows.net:1688

En la salida del comando, la segunda a la última línea es similar al texto siguiente:

Sent = 4, Received = 4, Lost = 0 (0% loss)

Si el Lost valor es mayor que 0, la máquina virtual no tiene conectividad con el servidor KMS. En esta situación, si la máquina virtual está en una red virtual y tiene un servidor DNS personalizado especificado, asegúrese de que el servidor DNS pueda resolver el nombre de azkms.core.windows.net dominio. Si no es posible, cambie el servidor DNS a uno que pueda resolver azkms.core.windows.net.

1. Utilice una prueba de próximo salto de Azure Network Watcher para comprobar que el tipo de próximo salto es Internet desde la máquina virtual afectada hacia destinos concretos. Para aplicar la prueba del próximo salto, siga estos pasos:

   1. En el portal Azure, busque y seleccione Máquinas virtuales.

   2. En la lista de máquinas virtuales, seleccione el nombre de la máquina virtual.

   3. En el panel de menús de la máquina virtual, busque el encabezado Ayuda y seleccione Solución de problemas de conexión.

   4. En la página Solución de problemas de conexión de la máquina virtual, especifique los siguientes valores de campo.

      Campo	Valor
      Tipo de destino	Especificar manualmente
      URI, FQDN o dirección IP	20.118.99.224, 40.83.235.53 (para azkms.core.windows.net) o la dirección IP del punto de conexión de KMS adecuado que se aplica a su región
      Puerto de destino	1688
      Puerto de origen	1688
      Pruebas de diagnóstico	Próximo salto

   5. Seleccione Ejecutar pruebas de diagnóstico.

   6. Una vez finalizadas las pruebas de diagnóstico, revise el cuadro Resultados que aparece debajo del botón. La prueba del próximo salto (de origen) debe tener un valor de estado de Éxito y el valor de detalles debe incluir el tipo de próximo salto: Internet en el texto. Si el tipo de próximo salto es Internet, repita la prueba del próximo salto para cada una de las direcciones IP restantes. Sin embargo, si el tipo de próximo salto se muestra como VirtualAppliance, VirtualNetworkGateway o cualquier otro que no sea Internet, probablemente se produzca uno de los escenarios siguientes:

      • Existe una ruta predeterminada que enruta el tráfico fuera de Azure antes de enviar el tráfico al punto de conexión de KMS de Azure.

      • El tráfico se bloquea en algún lugar a lo largo de la ruta de acceso.

      En estos escenarios, vaya a Solution 1: (para la tunelización forzada) Use la ruta personalizada de Azure para enrutar el tráfico de activación al servidor KMS de Azure.

2. Después de comprobar que una conexión a azkms.core.windows.net se realiza correctamente, ejecute el siguiente comando en la ventana de PowerShell con privilegios elevados Windows. Este comando intenta activar la máquina virtual Windows varias veces:

   1..12 | ForEach-Object {
       Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato";
       Start-Sleep 5
   }

Si el intento de activación se realiza correctamente, el comando muestra un mensaje similar al ejemplo siguiente:

Activating Windows(R), Server Datacenter edition (<kms-client-product-key>) ... Product activated successfully.

Solución

Solución 1 (para la tunelización forzada): use la ruta personalizada de Azure para enrutar el tráfico de activación al servidor kmS de Azure

Si un escenario de tunelización forzada enruta el tráfico fuera de Azure, trabaje con el administrador de red para determinar el curso de acción correcto. Una posible solución se describe en la sección Solución de Error de activación de Windows en el escenario de tunelización forzada. Aplique esta solución si es coherente con las directivas de su organización.

Solución 2 (para equilibrador de carga interno estándar): use una puerta de enlace de traducción de direcciones de red (NAT) o un equilibrador de carga público estándar

Si un equilibrador de carga interno estándar bloquea el tráfico, dos enfoques diferentes pueden corregir el problema, como se describe en Traducción de direcciones de red de origen (SNAT) en conexiones salientes:

• Asocie una puerta de enlace de traducción de direcciones de red (NAT) a la subred.

• Cambie a un equilibrador de carga público estándar y defina reglas de salida.

En las implementaciones de producción, use una configuración nat de Azure Virtual Network para la conectividad saliente. Para obtener más información sobre Azure NAT Gateway, consulte ¿Qué es Azure NAT Gateway?

Sin embargo, si tiene que bloquear todo el tráfico de Internet, asegúrese de denegar el acceso saliente a Internet mediante una regla de grupo de seguridad de red (NSG) en la subred de la máquina virtual que tiene que activar. El tráfico de activación del sistema operativo a las direcciones IP de KMS en el puerto 1688 permanece habilitado debido a las reglas internas de la plataforma.

Solución 3 (para el equilibrador de carga interno estándar): salida centralizada a través de Azure Firewall sin tunelización forzada

Como se mencionó en Solution 2, para superar las limitaciones del puerto SNAT para la conectividad saliente, use una configuración nat de Azure Virtual Network para la administración de tráfico saliente escalable y resistente.

Si la implementación usa un equilibrador de carga interno y enruta todo el tráfico saliente a través de Azure Firewall, esta solución es aplicable. Úselo si:

• Necesita un control de tráfico saliente centralizado.
• No se requiere la tunelización forzada hacia instalaciones locales.
• Una puerta de enlace NAT no es necesaria, a menos que se produzca el agotamiento de puertos SNAT.

Este patrón es común en entornos en los que las máquinas virtuales de back-end detrás de un equilibrador de carga interno tienen que acceder a servicios externos (como servidores KMS) a través de Azure Firewall a la vez que se mantiene la simplicidad del enrutamiento interno. Para obtener más información, consulte Integrar Azure Firewall con Azure Load Balancer Interno Estándar.

Resumen de flujo para el tráfico entrante y saliente

• Entrante: cliente → equilibrador de carga interno → máquina virtual de back-end → cliente
• Salida: máquina virtual de back-end → ruta definida por el usuario (0.0.0.0/0) → Azure Firewall → Internet

Pasos para realizar la activación de Windows a través de Azure Firewall

1. Compruebe la configuración de enrutamiento saliente. Asegúrese de que el tráfico saliente de la subred de la máquina virtual se enruta a Azure Firewall mediante una ruta definida por el usuario (UDR). Por ejemplo: 0.0.0.0/0 → Azure Firewall.

2. Agregue una regla de red en Azure Firewall para permitir el tráfico saliente al servidor KMS.

   Campo	Valor
   Destino	El nombre de dominio completo (FQDN) del servidor KMS: azkms.core.windows.net, la dirección IP que azkms.core.windows.net se resuelve en: 20.118.99.224 o 40.83.235.53, la dirección IP que kms.core.windows.net se resuelve en: 23.102.135.246o la dirección IP del punto de conexión de KMS adecuado que se aplica a su región.
   Puerto	1688
   Protocolo	TCP
   Acción	Allow

3. Compruebe que la resolución DNS de la máquina virtual finaliza correctamente y devuelve las direcciones IP correctas.

4. Active Windows ejecutando el siguiente comando en una ventana del símbolo del sistema con privilegios elevados:

   slmgr.vbs /ato
   

5. Si se produce un error en la activación, compruebe los diagnósticos del Firewall de Azure.

   • Compruebe los registros de reglas de red para comprobar que se permite el tráfico en el puerto 1688.
   • Compruebe que la regla coincide con la dirección IP, el puerto y el protocolo resueltos.
   • Compruebe que no haya ninguna denegación implícita ni prioridades de regla mal configuradas.