En entornos mixtos con Windows Server 2022 y Windows 11, elegir el método de activación adecuado repercute directamente en la seguridad, la continuidad operativa y el cumplimiento de los términos de licenciamiento. A continuación encontrarás una guía completa, orientada a administradores, que compara ADBA, KMS y MAK y traza un plan paso a paso para que ningún dispositivo quede sin activar, incluso si no está unido a dominio.

Contexto de licenciamiento por volumen: panorama general

Microsoft ofrece tres grandes mecanismos de activación para licencias por volumen:

• Active Directory‑Based Activation (ADBA): usa los objetos y atributos del bosque para otorgar activaciones transparentes a los equipos que se autentican contra un controlador de dominio de Windows Server 2012 o posterior.
• Key Management Service (KMS): establece un servicio de claves hospedado en tu red que responde a las peticiones de activación periódicas. Exige un mínimo de equipos para desarrollar plenamente su función (25 clientes o 5 servidores).
• Multiple Activation Key (MAK): clave única que contacta directamente con los servidores de Microsoft una sola vez; ideal para escenarios con pocos dispositivos o sin conectividad frecuente.

Cómo funciona ADBA

ADBA amplía los atributos del esquema de Active Directory para almacenar los datos de la clave configuración de volumen (GVLK) y la versión de licencia. Cuando un equipo miembro del dominio inicia sesión, el controlador le concede un ticket de activación que se renueva automáticamente cada siete días; si el equipo pasa 180 días sin conectarse, volverá a solicitar la activación la próxima vez que contacte al DC.

Ventajas clave de ADBA

• Sin umbrales numéricos: un único servidor o una docena se activan igual; basta con pertenecer al dominio.
• Alta disponibilidad inherente: la información se replica entre todos los controladores de dominio.
• Cero intervención del usuario final: el proceso es imperceptible para el usuario y no requiere privilegios elevados en la estación.
• Compatibilidad con grupos de disponibilidad y Sites de AD: útil en entornos de múltiples sedes.

Limitaciones de ADBA

• No puede activar dispositivos fuera del dominio: ordenadores en grupo de trabajo, laboratorios aislados o redes de invitados quedan excluidos.
• Requiere al menos un DC con el rol Volume Activation Services y una clave de host de activación por volumen (CSVLK) válida para cada familia de sistema operativo.
• No permite controlar el conteo de activaciones usadas, porque todas se gestionan internamente en AD.

Cómo funciona KMS

KMS se basa en un servidor —físico o virtual— que presenta el servicio sppsvc. Los clientes “GVLK” preguntan al host KMS mediante una petición RPC sobre TCP/1688 e intentan acumular puntos de conteo: 1 punto por cliente Windows 10/11 y 1 punto por servidor. Solo cuando el host alcanza los siguientes umbrales se habilita la activación para ese tipo de sistema:

• ≥ 25 clientes de escritorio (Windows 10/11).
• ≥ 5 servidores (Windows Server 2022/2019, etc.).

Después de activarse, cada dispositivo renueva su estado cada 180 días —intentando hablar con el host KMS cada 7 días—. Si falla durante 180 días consecutivos, el sistema entra en grace period y advierte al usuario.

Ventajas clave de KMS

• Independencia de Active Directory: activa estaciones en grupo de trabajo, DMZ o incluso equipos Linux con licencias de cliente VDA.
• Escalabilidad: un único host puede manejar miles de peticiones sin sobrecarga notable.
• Soporte híbrido: convivir con ADBA en el mismo servidor es totalmente soportado.

Limitaciones de KMS

• Los umbrales de 25/5 son inamovibles; con menos máquinas no se activa ningún cliente.
• Requiere mantener registros DNS SRV (vlmcs.tcp) accesibles o configurar manualmente la dirección del host (slmgr /skms).
• Implica operaciones periódicas de renovación; si un portátil está 6 meses fuera de la red corporativa, perderá la activación.

Comparación rápida: ADBA vs KMS vs MAK

Aspecto	ADBA	KMS	MAK
A quién puede activar	Solo dispositivos unidos a dominio (cualquier bosque donde resida la clave)	Cualquier equipo que alcance el host KMS (dominio o grupo de trabajo)	Equipo individual; no requiere infraestructura
Requisitos de recuento	Ninguno	≥ 25 clientes o ≥ 5 servidores según tipo de SO	Ninguno
Renovación	Automática cada 7 días al contactar al DC	Automática cada 7 días al contactar al host	No requiere renovación (excepto tras reinstalar SO)
Gestión de claves	CSVLK almacenada en AD	CSVLK almacenada en el host KMS	MAK introducida localmente
Escenarios ideales	Redes con 100 % de máquinas unidas a dominio	Entornos mixtos, redes aisladas, puestos temporales	Equipos remotos permanentes, contingencia, baja escala

Análisis del entorno planteado

La organización dispone de dos dominios, 23 servidores Windows Server 2022 y 8 estaciones Windows 11 unidas al dominio. Además, gestiona 8 portátiles en grupo de trabajo que solo acceden esporádicamente a la red corporativa.

Observaciones:

• Los 31 equipos unidos a dominio pueden beneficiarse de ADBA sin restricciones.
• El licenciamiento de servidores (23 unidades) supera de sobra el umbral de 5 para KMS, pero los portátiles no alcanzan el umbral de 25 clientes, lo que impide su activación automática por KMS en la situación actual.
• Los portátiles rara vez están conectados y no participan en el dominio, lo que hace poco viable ADBA. Su número reducido aconseja MAK o un host KMS futuro cuando la flota crezca.

Estrategia paso a paso recomendada

1. Desplegar ADBA en cada dominio
   
   • Instalar el rol Volume Activation Services en al menos un DC (recomendable dos para alta disponibilidad).
   • Ejecutar Volume Activation Tools → seleccionar “Active Directory‑Based Activation”.
   • Introducir la CSVLK correspondiente (Windows Server 2022 en los DC; Windows 10/11 para clientes).
   • Verificar la creación del objeto Activation Objects mediante adsiedit.msc.
   • Probar con un cliente: slmgr /ato debería retornar “product activated successfully”.
2. Activar los portátiles en grupo de trabajo
   
   • Opción MAK (recomendada a corto plazo): aplicar la clave MAK en cada portátil (puede integrarse en la imagen de referencia o por script slmgr /ipk XXXX-...).
   • Opción KMS (viable a futuro): si la flota supera 25 unidades, implementar un host KMS expuesto en la red de acceso VPN.
3. Montar un host KMS como respaldo
   
   • Instalar el mismo rol Volume Activation Services en un servidor miembro o en un DC de menor carga.
   • Configurar DNS SRV o un registro CNAME para kms.contoso.local apuntando al host.
   • Importar las CSVLK de servidor y workstation. En la consola comprobar el conteo alcanzado.
   • Documentar el uso de slmgr /dlv para auditar el estado de activación.

Buenas prácticas de implementación

• Alta disponibilidad de ADBA: distribuye el rol en todos los controladores de dominio o, como mínimo, en uno por sitio de AD.
• Backups del host KMS: incluye la base de datos de licencias C:\Windows\System32\SPP en la estrategia de respaldo; perderla obliga a reactivar el host.
• Segregación de subredes: si hospedas KMS en la DMZ, filtra solo TCP/1688 y evita exponerlo a Internet.
• Uso de plantillas de GPO: distribuye los GVLK con una GPO de Preferences » Windows Settings » Registry para automatizar slmgr /ipk en clientes existentes.
• Monitorización proactiva: eventos 12288 y 8200 en el visor de eventos (Application and Services Logs » Microsoft » Windows » Software Protection Platform) alertan de fallos de activación.
• Plan de contingencia: documenta un proceso MAK de emergencia para escenarios desconectados prolongados (por ejemplo, portátiles de obra en zonas sin cobertura).

Preguntas frecuentes (FAQ)

¿Puedo mezclar ADBA y KMS en un mismo servidor?

Sí. Ambos sub‑roles coexisten sin conflicto. ADBA se publica en AD; KMS escucha en TCP/1688. Solo necesitas importar cada CSVLK una sola vez.

¿Qué ocurre si migro un servidor a otro dominio?

Si el nuevo dominio tiene ADBA, se reactivará al iniciar sesión. Si no, el servidor entrará en periodo de gracia hasta que lo apuntes a un host KMS o uses MAK.

¿La virtualización anula el recuento de KMS?

No. Cada VM cuenta igual que un equipo físico. Sin embargo, snapshots con retroceso pueden provocar solicitudes repetidas; usa la directiva skiprearm en tus golden images.

Checklist de verificación antes de poner en producción

• CSVLK correctas para cada familia de SO cargadas y validadas.
• Rol Volume Activation Services instalado y servicios iniciados.
• Objeto de activación presente en CN=Activation Objects,CN=Microsoft SPP,CN=Services,CN=Configuration,DC=….
• Registros DNS SRV vlmcs.tcp visibles desde clientes.
• Política de backup del host KMS revisada y probada.
• Scripts o GPO de distribución de GVLK documentados.
• Procedimiento de activación offline con MAK archivado.

Conclusiones

Para el escenario descrito, ADBA es la solución principal por su simplicidad y ausencia de umbrales. Los 31 equipos unidos a dominio se beneficiarán de activaciones automáticas y resilientes. Los 8 portátiles pueden activarse con MAK hasta que la flota crezca; llegado el momento, se justificará un host KMS público en la red corporativa o disponible vía VPN. Mantener ambos servicios (ADBA + KMS) en paralelo garantiza flexibilidad a largo plazo, cubre planes de contingencia ante desastres y evita sorpresas al incorporar nuevos dominios o laboratorios desconectados.

Implementa la estrategia anterior y podrás olvidarte de los avisos de “Windows no está activado”, cumplir las auditorías de software y dedicar tu tiempo a tareas de mayor valor añadido.