Solución de problemas de clientes de activación basada en Active Directory (ADBA) que no se activan

Nota:

Este artículo se publicó originalmente como blog de TechNet el 26 de marzo de 2018.

Recientemente, he ayudado a un cliente a implementar Windows Server 2016 en su entorno. Aprovechamos esta oportunidad para también migrar su metodología de activación desde un servidor de KMS a la activación basada en Active Directory.

Como procedimiento adecuado para realizar todos los cambios, iniciamos la migración en el entorno de prueba del cliente. Hemos iniciado la implementación siguiendo las instrucciones de Activación basada en Active Directory frente a Servicio de administración de claves s. Los controladores de dominio del entorno de prueba estaban ejecutando Windows Server 2012 R2, por lo que no era necesario preparar el bosque. Instalamos el rol en un controlador de dominio de Windows Server 2012 R2 y elegimos Activación basada en Active Directory como método de activación por volumen. Instalamos la clave KMS y le asignamos un nombre de "Activación de KMS AD (** LAB)." Hemos seguido la entrada de blog paso a paso.

Empezamos creando cuatro máquinas virtuales, dos Windows 2016 Server Standard y dos Windows 2016 Server Datacenter. En este momento todo fue genial. Hemos creado un servidor físico que ejecuta Windows 2016 Server Standard y la máquina se ha activado correctamente.

A decir verdad, la instalación y configuración fueron muy fáciles, así que esa parte fue sencilla y directa. Sin embargo, todas las máquinas virtuales que había creado la semana anterior mostraron que no estaban activadas. Volví a la máquina física y estaba bien. Fui con el cliente para conversar sobre lo sucedido. La primera pregunta fue "¿Qué cambió durante el fin de semana?" Y como de costumbre la respuesta era "nada". Esta vez, no se había cambiado realmente nada, y tuvimos que averiguar lo que estaba pasando.

Fui a uno de los servidores de problemas, abrió un símbolo del sistema y comprobó la salida del slmgr /ao-list comando. El /ao-list modificador muestra todos los objetos de activación en Active Directory.

Los resultados muestran que tenemos dos objetos de activación: uno para Windows Server 2012 R2 y la activación de KMS AD (** LAB) recién creada, que es la licencia de Windows Server 2016. Esto confirma que Active Directory está configurado correctamente para activar clientes de KMS de Windows.

Sabiendo que el comando es para la slmgr activación de licencias, proseguí con diferentes opciones. He probado el /dlv modificador, que mostrará información detallada sobre la licencia. Esto parecía correcto, estaba ejecutando la versión estándar de Windows Server 2016, hay un identificador de activación, un identificador de instalación, una dirección URL de validación, incluso una clave de producto parcial.

¿Alguien ve lo que me estaba perdiendo en este momento? Volveremos a ella después de mis otros pasos de solución de problemas, pero basta con decir que la respuesta está en esta captura de pantalla.

Mi pensamiento ahora es que, por alguna razón, la clave está rota, así que uso el /upk modificador, que desinstala la clave actual. Aunque esto fue eficaz para quitar la clave, generalmente no es la mejor manera de hacerlo. ¿Debe reiniciarse el servidor antes de obtener una nueva clave que puede dejar el servidor en un estado incorrecto? He encontrado que el uso del /ipk modificador (que hago más adelante en mi solución de problemas) sobrescribe la clave existente y es una ruta más segura para tomar.

He vuelto a ejecutar el /dlv modificador para ver la información detallada de la licencia. Desafortunadamente, eso no me dio ninguna información útil, simplemente un error de clave de producto no encontrado. Porque no hay ninguna clave desde que lo desinstale.

Pensé que era una larga toma, pero intenté el /ato conmutador, que debería activar Windows en los servidores KMS conocidos (o Active Directory como puede ser el caso). De nuevo, solo un error de producto no encontrado.

El siguiente pensamiento fue que a veces detener e iniciar un servicio hace el truco, así que lo intenté a continuación. Tengo que detener e iniciar el Servicio de plataforma de protección de software de Microsoft (servicio SPPSvc). Desde un símbolo del sistema administrativo, uso los comandos y net start confianzanet stop. Noto al principio que el servicio no se está ejecutando, así que creo que esto debe serlo.

Sin embargo, después de iniciar el servicio e intentar activar Windows de nuevo, todavía obtengo el error del producto no encontrado.

Luego, examino el registro de eventos de aplicación en uno de los servidores con problemas. Encuentro un error relacionado con la activación de la licencia, el Id. de evento 8198, que tiene un código de 0x8007007B.

Al buscar este código, he encontrado un artículo que indica que el código de error significa que la sintaxis del nombre de archivo, nombre de directorio o etiqueta de volumen es incorrecta. Al leer los métodos descritos en el artículo, no parece que ninguno de ellos se ajuste a la situación. Cuando ejecuté el nslookup -type=all _vlmcs._tcp comando, encontré el servidor KMS existente (todavía muchos equipos de Windows 7 y Server 2008 en el entorno, por lo que era necesario mantenerlo alrededor), pero también los cinco controladores de dominio. Esto indicó que no era un problema de DNS y los problemas estaban en otro lugar.

Así que sé que el DNS está bien. Active Directory está configurado correctamente como origen de activación de KMS. El servidor físico se ha activado correctamente. ¿Podría tratarse de un problema solo con las VM? Como nota colateral interesante en este momento, mi cliente me informa que alguien de otro departamento ha decidido crear también más de una decena de máquinas virtuales de Windows Server 2016. Así que ahora supongo que tengo otras docenas de servidores para tratar con eso no se activará. Sin embargo, esos servidores se activaron muy bien.

Bueno, volví al slmgr comando para averiguar cómo activar estos monstruos. Esta vez voy a usar el /ipk modificador, que me permitirá instalar una clave de producto. Fui al Apéndice A: Claves de configuración del cliente kmS para obtener las claves adecuadas para la versión estándar de Windows Server 2016. Algunos servidores son Datacenter, pero necesito corregirlo primero.

He usado el /ipk modificador para instalar una clave de producto, eligiendo la clave Estándar de Windows Server 2016.

De aquí en más, solo capturé los resultados de las experiencias de Datacenter, pero eran los mismos. He usado el /ato modificador para forzar la activación. Obtenemos el mensaje impresionante que el producto se ha activado correctamente.

Con el /dlv modificador de nuevo, podemos ver que ahora hemos sido activados por Active Directory.

Ahora, ¿qué ha ido mal? ¿Por qué tengo que quitar la clave instalada y agregar esas claves genéricas para que estas máquinas se activen correctamente? ¿Por qué la otra decena de máquinas se activó sin problemas? Como dije anteriormente, me perdí de algo fundamental en las etapas iniciales del análisis del problema. Me confundí exhaustivamente, así que se puso en contacto con el póster del blog inicial. El póster vio el problema inmediatamente y me ayudó a entender lo que había perdido temprano.

Cuando ejecuté el primer /dlv conmutador, en la descripción era la clave. La descripción era Windows® Operating System, RETAIL Channel. Había visto eso y pensé que RETAIL Channel significaba que se había comprado y era una clave válida.

Cuando veamos la salida del /dlv modificador desde un servidor activado correctamente, observe que la descripción ahora indica el canal VOLUME_KMSCLIENT. Esto nos permite saber que es realmente una licencia por volumen.

Entonces, ¿qué significa ese RETAIL Channel? Bueno, significa que el medio que se usó para instalar el sistema operativo era una ISO de MSDN. Volví con el cliente y le pregunté si, por alguna oportunidad, había una segunda ISO de Windows Server 2016 flotante en la red. Resultó que sí, había otra imagen ISO en la red y se había usado para crear la otra decena de máquinas. Compararon las dos ISO y, lo más probable es que la que me dieron para crear los servidores virtuales fuera, de hecho, una ISO de MSDN. Quitaron que MSDN ISO de su red y ahora tenemos todos los servidores existentes activados y no más preocupaciones sobre el error de activación en futuras compilaciones.