Migración de KMS a ADBA en Windows Server: Guía completa

Actualizar la infraestructura de licenciamiento sin interrumpir las operaciones puede parecer arriesgado; sin embargo, con una correcta planificación es posible sustituir un KMS extinto por un nuevo servidor KMS o, mejor aún, dar el salto a ADBA para automatizar la activación sin sobresaltos.

Índice

Situación inicial y diagnóstico

Antes de mover una sola pieza conviene conocer el punto de partida:

KMS huérfano en DNS: al ejecutar nslookup -type=all vlmcs.tcp el servidor devuelto responde a una IP o FQDN que ya no existe. Ese registro SRV es el que buscaban originalmente los clientes para renovarse.
Sin aviso de “Activate Windows”: los equipos usan la backup key (BackupProductKeyDefault) del registro (HKLM\Software\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform) para mantener un estado licenciado.
Conclusión: aun careciendo de un host KMS operativo, los dispositivos continúan validados. Sustituir el servicio no impactará de inmediato en los usuarios.

Limpieza del registro DNS _VLMCS

Un DNS ordenado es la base de una migración limpia. El registro SRV obsoleto provoca que los clientes inviertan tiempo en resolver y contactar con un servidor inexistente, retrasando la activación y llenando los registros de errores.

Procedimiento en DNS Manager

Abrir la consola DNS Manager.
Navegar a Forward Lookup Zones → seleccionar la zona que contiene vlmcs.tcp.
En el panel derecho, clic derecho sobre el registro SRV → Delete.
Confirmar la eliminación.

Al retirar el registro:

No se afecta a las máquinas ya activadas.
Se evita el tráfico inútil hacia un servidor fantasma.
Se prepara el terreno para publicar el nuevo host KMS o el Activation Object de ADBA.

Implantación de un nuevo KMS o ADBA

Comparativa de impacto según tipo de cliente

Tipo de cliente	Comportamiento tras publicar el nuevo servicio	Acción recomendada
Clave MAK	El equipo sigue usando su clave MAK; no consulta al nuevo KMS.	Ninguna. Si se desea migrar, desplegar `slmgr /ipk <clave‑KMS>` seguido de `slmgr /ato`.
Clave KMS antigua	Permanece activado hasta agotar su periodo de 180 días; en la próxima renovación intentará contactar al nuevo host.	Verificar que el nuevo KMS responde y que el SRV apunta correctamente.
Nuevos equipos vía ADBA	Reciben una clave genérica KMS desde Active Directory en cuanto se unen al dominio.	Asegurar la publicación del Activation Object y que los controladores de dominio ejecutan el rol de volumen activation.

Paso a paso para desplegar un nuevo KMS

Instalar la Volume Activation Services (GUI) o ejecutar:
DISM /online /Enable-Feature /FeatureName:VolumeActivation /All
Ejecutar slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX con la clave pública KMS correcta (GVLK).
Activar el equipo servidor frente a Microsoft mediante slmgr /ato o por teléfono si no dispone de Internet.
Publicar el registro SRV:
dnscmd /recordadd <zona> vlmcs.tcp SRV 0 0 1688 <FQDN-servidor>
Comprobar la disponibilidad desde un cliente:
nslookup -type=all vlmcs.tcp y luego slmgr /ato.

Paso a paso para habilitar ADBA

Desde Server Manager, añadir la característica Volume Activation Services y seleccionar Active Directory-Based Activation.
Agregar la licencia con Add Product Key → introducir la GVLK o la clave CSVLK si aplica.
Completar el asistente; se crea automáticamente un objeto Activation Objects en la partición de configuración de AD.
Replicar AD y verificar con Get-ADObject -LDAPFilter "(userAccountControl=532480)" -SearchBase "CN=Activation Objects,CN=Microsoft,DC=... ".
Unirse un equipo de prueba al dominio y ejecutar slmgr /dli; la línea “AD Activation” debe aparecer como Licensed.

Requisitos de comunicación y expiración

Clientes KMS tradicionales

Renovación automática cada 7 días (Renewal Interval).
Si la renovación falla, permanecen activados hasta 180 días.
Transcurridos los 180 días sin contactar, el sistema entra en Notification Mode.

Clientes ADBA

La primera activación se produce al cruzar una autenticación Kerberos con un DC autorizado.
Si el equipo está fuera de la red más de 180 días, cambia a estado Unlicensed y dispone de 30 días de gracia con recordatorios frecuentes.
Tras esos 30 días, ciertas características se deshabilitan (fondo negro, marca de agua, reinicios).

Clientes MAK

Activación puntual; no necesitan reconexión.
El contador MAK disminuye una vez por equipo reimaginado (cuidado con reinstalaciones).
Si se alcanza el límite, es necesario solicitar un incremento a Microsoft.

Buenas prácticas recomendadas

Publicar con precisión el registro vlmcs.tcp; un TTL de 1 hora simplifica la corrección de errores.
Eliminar registros huérfanos antes de migrar para que los clientes no aprendan rutas incorrectas.
Clasificar equipos: prolongar MAK para servidores aislados, usar KMS/ADBA en portátiles y estaciones de trabajo.
Automatizar con GPO: script de inicio cscript slmgr.vbs /ato y WMI filter que detecte edición de Windows.
Supervisar el contador de activaciones con slmgr /dlv y Event ID 12288 en el registro Security-SPP.
Planificar la conectividad: usuarios remotos requieren VPN o Azure AD Join con Hybrid Activate.
Documentar el proceso y mantener un runbook con fechas de renovación semestral.

Preguntas frecuentes (FAQ)

¿Puedo tener KMS y ADBA al mismo tiempo?

Sí, ambos métodos pueden coexistir. Los equipos con clave GVLK consultarán primero KMS; si no obtienen respuesta y están unidos al dominio, intentarán ADBA.
¿Qué puertos necesito abrir?

KMS usa TCP 1688. ADBA no requiere puertos nuevos; depende de la comunicación LDAP/Kerberos estándar con los controladores de dominio.
¿Cómo fuerzo la detección inmediata del nuevo KMS?

Ejecute ipconfig /flushdns seguido de slmgr /skms <FQDN>:1688 y slmgr /ato. Esto anula el SRV y apunta directamente al host.

Scripts de ejemplo

Validar activaciones KMS en todos los equipos de un OU

Get-ADComputer -SearchBase "OU=PCs,DC=contoso,DC=com" -Filter * |
 ForEach-Object {
   Invoke-Command -ComputerName $_.Name -ScriptBlock {
     $status = cscript.exe //nologo slmgr.vbs /dli
     Write-Output "$env:COMPUTERNAME : $status"
   }
 }

Publicar SRV mediante PowerShell

Add-DnsServerResourceRecord -ZoneName "contoso.com" `
  -Srv -Name "vlmcs.tcp" -DomainName "kms.contoso.com" `
  -Priority 0 -Weight 0 -Port 1688 -TimeToLive 01:00:00

Conclusiones

Limpiar DNS, desplegar un nuevo KMS o dar el salto definitivo a ADBA no solo mantiene el cumplimiento de licencias: reduce ruido en los registros, acelera el arranque de los equipos y evita llamadas de soporte por activaciones fallidas. Siguiendo la secuencia descrita—diagnóstico, saneamiento, implantación y buenas prácticas—garantizarás un entorno de activación robusto, preparado para los próximos años de servicio.