Este explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
Se aplica a: ✔️ Máquinas virtuales de Windows
En este artículo se describe cómo resolver el error de 0xC004F074 que se produce al intentar activar una máquina virtual Windows en Microsoft Azure.
Al intentar activar una máquina virtual Windows de Azure, aparece el siguiente mensaje de error en El host de script de Windows:
Error: 0xC004F074 el servicio de licencias de software notificó que no se pudo activar el equipo. No se pudo establecer contacto con ningún Servicio de administración de claves (KMS). Consulte el registro de eventos de la aplicación para obtener más información.
La máquina virtual no se puede conectar al servicio KMS para la activación. Si se usa un KMS de Azure para la activación (la selección predeterminada), la solicitud de activación debe originarse desde 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 todo el tráfico se enruta 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
Para determinar la causa específica del problema, siga el procedimiento de tres partes en las secciones siguientes.
Nota
Esta parte no es necesaria para las máquinas virtuales que ejecutan sesiones múltiples de Windows 10 Enterprise (también conocidas como Windows 10 Enterprise para escritorios virtuales) en Azure Virtual Desktop).
Para determinar si la máquina virtual ejecuta la edición de varias sesiones, ejecute el siguiente comando de script del Administrador de licencias de software:
slmgr.vbs /dlv
Si la salida contiene la Name: Windows(R), ServerRdsh edition cadena, la máquina virtual ejecuta la edición de varias sesiones y puede omitir el resto de esta parte.
Nota
Si implementas una máquina virtual de sesión múltiple de Windows 10 Enterprise y, a continuación, actualizas la clave de producto a otra edición, no puedes revertir la máquina virtual a la sesión múltiple de Windows 10 Enterprise. En su lugar, debe volver a implementar la máquina virtual. Para obtener más información, consulte ¿Puedo actualizar una MV Windows a una sesión múltiple de Windows Enterprise?
Para la máquina virtual que se crea a partir de una imagen personalizada, debe configurar la clave de configuración del cliente KMS adecuada para la máquina virtual. Siga estos pasos:
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
Compruebe el Description valor de la salida para determinar si la máquina virtual se creó a partir de medios de licencia de minoristas (RETAIL canal) o volumen (VOLUME_KMSCLIENT).
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 se usa y 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 aparecerá de la siguiente manera:
cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG
Siga estos pasos 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:
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 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 se muestran recursos de equilibrio de carga, la máquina virtual no está detrás de ningún equilibrador de carga. En este caso, puede continuar con la parte 3: Comprobar la conectividad entre la máquina virtual y el servicio KMS de Azure.
Si ve un recurso de equilibrador de carga, seleccione el nombre del equilibrador de carga para ir a la página Información general del equilibrador de carga.
En el panel de menús del equilibrador de carga, seleccione Propiedades.
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, consulte Solución 2: (Para el equilibrador de carga interno estándar) Uso de una puerta de enlace NAT o un equilibrador de carga público estándar. |
| El valor de SKU no es Estándar y el valor 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. Continúe con la parte 3: Compruebe la conectividad entre la máquina virtual y el servicio KMS de Azure. |
Asegúrese de que la VM está configurada para usar el servidor de KMS de Azure correcto. Para ello, ejecute el siguiente comando de script del Administrador de licencias de software:
Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms azkms.core.windows.net:1688"
Este comando debe devolver 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.
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 ello, 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 debe ser similar al texto siguiente:
Sent = 4, Received = 4, Lost = 0 (0% loss)
Si Lost es mayor que 0 (cero), 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, debe asegurarse 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.
Nota
Si quita todos los servidores DNS de una red virtual, las máquinas virtuales usan el servicio DNS interno de Azure. Este servicio pude resolver kms.core.windows.net.
Use una prueba de próximo salto de Azure Network Watcher para comprobar que el tipo de próximo salto es Internet de la máquina virtual afectada a destinos concretos. Para aplicar la prueba del próximo salto, siga estos pasos:
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 el panel de menús de la máquina virtual, busque el encabezado Ayuda y seleccione Solución de problemas de conexión.
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 |
Seleccione el botón Ejecutar pruebas de diagnóstico.
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 status de Success y el valor Details 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 Azure KMS.
El tráfico se bloquea en algún lugar a lo largo de la ruta de acceso.
Para estos escenarios, consulte Solución 1: (Para la tunelización forzada) Uso de la ruta personalizada de Azure para enrutar el tráfico de activación al servidor kmS de Azure.
Después de comprobar que una conexión a azkms.core.windows.net se realiza correctamente, ejecute el siguiente comando en ese símbolo del sistema de Windows PowerShell con privilegios elevados. 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 texto siguiente:
Activar Windows(R), Server Datacenter Edition (<kms-client-product-key>) ... El producto se ha activado correctamente.
Si la causa es un escenario de tunelización forzada en el que el tráfico se enruta 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.
Si un equilibrador de carga interno estándar bloquea el tráfico, hay dos enfoques diferentes para corregir el problema, como se describe en Uso de la traducción de direcciones de red de origen (SNAT) para las 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.
Se recomienda usar una configuración nat de Azure Virtual Network para la conectividad saliente en implementaciones de producción. Para más información sobre Azure NAT Gateway, consulte ¿Qué es Azure NAT Gateway?
Sin embargo, si hay un requisito para 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. Observe que 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.
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.
Cursos
Módulo
Seleccionar las ediciones de Windows Server, las opciones de mantenimiento y la activación
Certificación
Microsoft Certified: Windows Server Hybrid Administrator Associate - Certifications
Como administrador híbrido de Windows Server, integra los entornos de Windows Server con servicios de Azure y administra Windows Server en redes locales.