En esta guía práctica aprenderás a retirar con seguridad un servidor KMS antiguo y a poner en marcha uno nuevo sin interrumpir la activación de Windows y Office. Incluye comandos SLMGR listos para usar, ajustes DNS vlmcs.tcp, comprobaciones, automatización y un checklist de migración.

Resumen de la pregunta

• ¿Cómo retirar un KMS antiguo y poner en marcha uno nuevo para que todos los equipos lo usen?
• ¿Es necesario quitar la clave del KMS actual si se va a desmantelar?
• ¿Qué servicio usa KMS?

Respuesta corta

Migración sin corte: prepara el nuevo host KMS, instala y activa su clave, publica (o actualiza) el registro DNS SRV vlmcs.tcp apuntando al nuevo FQDN y, si algún cliente tiene un host KMS fijado manualmente, límpialo o redirígelo. Cuando todos los clientes conmutan, elimina el SRV del host antiguo y desinstala su clave.

¿Debes quitar la clave del KMS viejo? No es obligatorio si la máquina se desmantela de inmediato, pero es altamente recomendable ejecutar /upk (y opcionalmente /cpky) para evitar activaciones accidentales o confusiones.

¿Qué servicio usa KMS? KMS forma parte de la tecnología de activación de Microsoft y se ejecuta bajo el servicio Software Protection Service (sppsvc) en Windows, que escucha por defecto en TCP/1688.

Plan recomendado (alto nivel)

1. Preparar el nuevo host KMS
   • Garantiza conectividad desde los clientes al puerto TCP 1688 del nuevo servidor (firewall/ACL/VPN).
   • Ten a mano la clave de host KMS (CSVLK) que cubre la versión más alta de Windows a activar (las versiones inferiores quedan cubiertas).
   • Asegura hora y zona horaria correctas (NTP) y resolución DNS del nuevo FQDN.
2. Instalar y activar la clave en el nuevo KMS slmgr.vbs /ipk <CLAVEHOSTKMS> slmgr.vbs /ato slmgr.vbs /dlv :: (opcional: ver detalles del host KMS)
3. Publicar/actualizar el SRV de KMS en DNS
   • KMS usa vlmcs.tcp en DNS (puerto 1688). Si el DNS permite actualizaciones dinámicas, el host lo publicará automáticamente; de lo contrario, créalo o actualízalo manualmente al nuevo FQDN.
   • Verificación rápida: nslookup -type=SRV vlmcs.tcp.<tu-dominio>
4. Redirigir clientes al nuevo KMS
   • Autodetección (por defecto): con el SRV actualizado, los clientes descubrirán el nuevo host sin tocar nada.
   • Clientes con KMS fijado a mano: cambia o limpia ese valor: slmgr.vbs /skms nuevo-kms.midominio.com:1688 :: o para volver a autodetección por DNS: slmgr.vbs /ckms slmgr.vbs /ato :: fuerza reactivación
5. Retirar el KMS antiguo
   • Recomendable desinstalar la clave del host: slmgr.vbs /upk :: desinstala la clave del host KMS slmgr.vbs /cpky :: (opcional) limpia la clave del registro
   • Elimina/expira su SRV vlmcs.tcp en DNS y apaga/desmantela el servidor.

Requisitos previos y buenas prácticas

• Clave correcta: usa una CSVLK (clave de host KMS) apta para la edición/versión más alta de Windows que necesites activar. Los clientes usan GVLK (claves genéricas) y normalmente no requieren cambios.
• Red y seguridad: permite TCP/1688 desde subredes internas; no expongas el servicio a Internet. Registra quién puede administrar la clave.
• DNS “limpio”: evita múltiples SRV apuntando a hosts antiguos; utiliza TTL bajo durante la transición para acelerar la convergencia.
• Tiempo y sincronización: desfases de reloj provocan errores de activación. Usa NTP coherente.
• Pruebas previas: valida en laboratorio con una muestra de clientes (Windows y Office) antes de tocar producción.

Puertos y servicios implicados

Componente	Servicio/Proceso	Puerto	Notas
KMS (host)	Software Protection Service (sppsvc)	TCP 1688 (escucha)	Por defecto; se puede cambiar, aunque no es habitual.
Clientes Windows	Software Protection Platform	Salida TCP 1688	Necesitan alcanzar el FQDN publicado en vlmcs.tcp.
DNS	SRV vlmcs.tcp	—	Prioridad/Peso/TTL para control de preferencia y convergencia.

Cómo publicar el SRV vlmcs.tcp en DNS

Si no hay actualizaciones dinámicas o quieres control fino, crea el registro manualmente:

:: Con dnscmd (en un DNS Windows)
dnscmd <ServidorDNS> /recordadd midominio.local vlmcs.tcp SRV 0 0 1688 nuevo-kms.midominio.com.

\:: Con PowerShell (DnsServer)
Add-DnsServerResourceRecordSrv -Name "\vlmcs.\tcp" -ZoneName "midominio.local" `  -DomainName "nuevo-kms.midominio.com" -Priority 0 -Weight 0 -Port 1688`
-TimeToLive 00:10:00

Campo SRV	Valor habitual	Descripción
Nombre	vlmcs.tcp	Servicio y protocolo del KMS.
Prioridad	0	Menor = mayor preferencia (permite failover si hay varios KMS).
Peso	0	Balanceo entre registros con igual prioridad.
Puerto	1688	Puerto TCP de escucha
Destino	nuevo-kms.midominio.com.	FQDN del nuevo KMS.
TTL	600 s (recomendado en transición)	Reducir durante la migración acelera el refresco de clientes.

Verificaciones esenciales

:: Alcance de red/puerto
Test-NetConnection nuevo-kms.midominio.com -Port 1688

\:: SRV en DNS
nslookup -type=SRV \vlmcs.\tcp.midominio.com

\:: Estado del host KMS
slmgr.vbs /dli
slmgr.vbs /dlv

\:: En un cliente, forzar reactivación y ver expiración
slmgr.vbs /ato
slmgr.vbs /xpr

Umbrales y comportamiento de activación

• Windows cliente (10/11): umbral KMS = 25 equipos.
• Windows Server: umbral KMS = 5 equipos.
• Office (KMS): umbral = 5 equipos.
• Renovaciones: los clientes renuevan cada ~7 días; la validez es hasta 180 días desde la última activación correcta.

Automatización y despliegue masivo

Si tienes equipos que fijaron un host KMS con /skms, puedes normalizarlos con GPO (preferible) o script.

Mediante GPO (preferido)

Usa Preferencias de directiva para establecer en los equipos:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\KeyManagementServiceName = nuevo-kms.midominio.com
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\KeyManagementServicePort = 1688 (REG_SZ)

Para volver a autodetección por DNS, elimina esos valores o usa slmgr /ckms.

Script de corrección remota (PowerShell)

$computers = Get-Content .\lista-equipos.txt
$script = {
  cscript.exe //Nologo C:\Windows\System32\slmgr.vbs /ckms
  cscript.exe //Nologo C:\Windows\System32\slmgr.vbs /ato
}
Invoke-Command -ComputerName $computers -ScriptBlock $script -AsJob

Migración sin interrupciones: estrategia paso a paso

1. Preparación
   • Instala la clave CSVLK y activa el nuevo host (/ipk + /ato).
   • Abre y verifica TCP/1688.
   • Reduce TTL del SRV existente (si lo hay) a 10–15 minutos.
2. Publicación
   • Modifica el SRV vlmcs.tcp para que apunte al nuevo FQDN.
   • Si mantienes ambos KMS temporalmente, usa prioridad menor para el nuevo y aumenta progresivamente su peso.
3. Observación
   • Revisa el Event Log en Applications and Services Logs → Microsoft → Windows → Security-SPP (Operational) tanto en el host como en varios clientes.
   • Comprueba activaciones nuevas y errores.
4. Corrección
   • Para clientes con KMS fijado, corrige con /skms o /ckms según política.
   • Vacía caché DNS en clientes problemáticos: ipconfig /flushdns.
5. Retirada
   • Cuando la carga esté en el nuevo host, elimina el SRV del KMS antiguo, ejecuta slmgr /upk y (opcional) /cpky, y apágalo.

Diagnóstico: errores típicos y solución

Código/Indicio	Causa probable	Acción recomendada
0xC004F074 (no se pudo contactar KMS)	DNS SRV incorrecto, firewall, FQDN erróneo o puerto cerrado	Verifica nslookup, Test-NetConnection y reglas en 1688.
0xC004F038 (umbral no alcanzado)	Pocos clientes contactando al nuevo host	Mantén ambos KMS hasta superar el umbral; fuerza /ato en una muestra.
0xC004F042 (host no válido o versión)	Clave CSVLK no cubre la versión a activar o host desautorizado	Instala la clave de host adecuada; revisa slmgr /dlv en el KMS.
Fecha/hora desalineada	Skew de reloj > 5 minutos	Corrige NTP en host y clientes.
Clientes “anclados” a KMS viejo	Uso previo de /skms o configuración por script	slmgr /ckms para volver a DNS, o actualiza /skms al nuevo FQDN.

Office por KMS: consideraciones

• Si además activas Office mediante KMS, instala en el nuevo host el Volume License Pack correspondiente y activa su clave de host KMS para Office.
• En clientes Office: :: Ver estado/forzar cscript "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /dstatus cscript "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /act \:: Apuntar a un KMS concreto (si no usas DNS) cscript "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /sethst\:nuevo-kms.midominio.com cscript "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /setprt:1688

Seguridad y cumplimiento

• Limita el acceso al puerto 1688 a subredes internas conocidas.
• Audita cambios sobre las claves CSVLK y el SRV en DNS.
• Documenta quién puede ejecutar slmgr con privilegios.

Escenarios especiales

• Varios dominios/bosques: publica SRV en cada zona DNS pertinente o usa /skms para equipos fuera de la zona.
• Redes segmentadas o VPN: asegúrate de que la ruta al puerto 1688 no se filtre en firewalls intermedios.
• Clientes no unidos a dominio: también descubren por SRV; si no resuelven, usa /skms.
• Cambio de puerto: si cambias 1688, refleja el valor en el SRV y en clientes fijados (no recomendado salvo necesidad).
• Alta disponibilidad: puedes publicar varios SRV con distinta prioridad/peso para failover y balanceo básico.

Comparativa breve: KMS vs ADBA

Característica	KMS	ADBA
Descubrimiento	DNS SRV vlmcs.tcp	Objetos en Active Directory
Umbral de activación	Sí (25/5)	No
Compatibilidad	Amplia (Windows y Office por volumen)	Requiere versiones más recientes y AD
Uso típico	Entornos mixtos y/o sin AD	Clientes unidos a AD homogéneos

Checklist de migración

• ✅ Nuevo host KMS con CSVLK instalada y activada (slmgr /ato).
• ✅ sppsvc en ejecución y escuchando en TCP/1688.
• ✅ SRV vlmcs.tcp actualizado con TTL bajo durante la transición.
• ✅ Conectividad verificada desde redes de clientes (Test-NetConnection).
• ✅ Muestreo de clientes activando correctamente (slmgr /ato, /xpr).
• ✅ Limpieza de clientes con /skms heredado (o GPO/registro).
• ✅ Retiro del KMS antiguo: slmgr /upk, /cpky (opcional), eliminación de SRV.
• ✅ Documentación y captura de pantallas (/dlv) para auditoría.

Preguntas frecuentes

¿Tengo que reinstalar claves en los clientes?
No. Los clientes por volumen suelen tener GVLK y descubren el host por DNS. Solo ajusta /skms en quienes estén anclados a un KMS concreto.

¿Cuánto tarda en “propagarse”?
Depende del TTL del SRV y cachés DNS de clientes. Durante la migración, usa TTL 10–15 min para acelerar.

¿Qué pasa si no alcanzo el umbral?
Mantén el KMS antiguo hasta que suficientes clientes contacten al nuevo. Fuerza /ato en una muestra para “elevar” el conteo.

¿Puedo cambiar el puerto?
Sí, pero añade complejidad. Si lo haces, refleja el puerto en el SRV y en clientes configurados con /skms.

¿Cómo verifico que el host KMS está activo y qué ediciones cubre?
Ejecuta slmgr /dlv en el host para ver el estado, recuento y productos compatibles.

Comandos útiles (Windows/KMS)

:: Host KMS
slmgr.vbs /ipk <CLAVEHOSTKMS>
slmgr.vbs /ato
slmgr.vbs /dli
slmgr.vbs /dlv
slmgr.vbs /upk
slmgr.vbs /cpky

\:: Cliente Windows
slmgr.vbs /ckms
slmgr.vbs /skms nuevo-kms.midominio.com:1688
slmgr.vbs /ato
slmgr.vbs /xpr

\:: Servicio y puerto
sc query sppsvc
netstat -ano | findstr :1688

\:: DNS y conectividad
ipconfig /flushdns
nslookup -type=SRV \vlmcs.\tcp.midominio.com
Test-NetConnection nuevo-kms.midominio.com -Port 1688

Retirada segura del KMS antiguo

1. Confirma que no hay clientes activos apuntando al host viejo (logs Security‑SPP en ese host y consultas de DNS).
2. Elimina o caduca su SRV vlmcs.tcp en DNS.
3. Ejecuta slmgr /upk y, si procede, slmgr /cpky.
4. Desconecta el servidor y actualiza documentación/CMDB.

Conclusión

Migrar o reemplazar un servidor KMS es un proceso directo si controlas tres palancas: la clave CSVLK del host, el registro SRV vlmcs.tcp en DNS y el estado de los clientes (autodetección vs. /skms). Con el plan anterior, podrás realizar la transición sin cortes, mantener la activación de Windows/Office y retirar el host antiguo con seguridad.