ADBA vs KMS : activer Windows Server 2022 et Windows 11 dans deux domaines (workgroup inclus)

Deux domaines, ~23 Windows Server 2022 et 16 postes Windows 11 dont 8 en workgroup : faut‑il choisir ADBA ou KMS ? Voici une recommandation claire, un plan d’implémentation pas‑à‑pas, des tableaux d’aide au choix et des commandes prêtes à l’emploi pour activer 100 % de votre parc.

Sommaire

Vue d’ensemble de l’environnement et de la question

Vous devez activer :

≈ 23 serveurs Windows Server 2022 (membres de domaine)
8 postes Windows 11 (membres de domaine)
8 portables Windows 11 en workgroup (hors domaine)

Questions clés : ADBA ou KMS ? Seuils KMS (≥ 25 clients, ≥ 5 serveurs/Office), activation des machines hors domaine, rôle Volume Activation sur contrôleurs de domaine, pérennité et simplicité opérationnelle.

Réponse courte et actionnable

Machines jointes au domaine (serveurs + 8 postes) : ADBA (Active Directory‑Based Activation) recommandé.
Machines hors domaine (8 portables en workgroup) : MAK (clé d’activation multiple), idéalement via VAMT en proxy pour centraliser.
KMS : non nécessaire pour les clients aujourd’hui (vous êtes à ~16 clients au total, en‑dessous du seuil 25). Optionnel pour les serveurs (seuil 5 atteint), mais redondant si ADBA est en place.

Pourquoi ce choix est le plus sûr

Seuils KMS par catégorie : le compteur des clients (Windows 10/11) est distinct du compteur des serveurs. Avoir 23 serveurs n’active pas le volet « clients » qui exige ≥ 25.
ADBA : activation transparente pour toute machine membre du domaine avec une clé GVLK (KMS client key). Pas de dépendance DNS ni de port spécifique à exposer ; l’objet d’activation est publié dans l’AD et répliqué dans la forêt.
Workgroup : une machine hors domaine ne peut pas profiter d’ADBA. Sans atteindre le seuil KMS « clients », la voie fiable est MAK (activation directe ou par VAMT).
Évolutif : si vous atteignez un jour ≥ 25 clients, vous pourrez introduire KMS pour ces postes (ou rester en ADBA s’ils sont joints au domaine).

Comparatif rapide des méthodes d’activation

Critère	ADBA	KMS	MAK	VAMT (proxy MAK)
Périmètre	Membres du domaine	Tout poste joignable réseau	Tout poste (en ligne/hors ligne)	Tout poste (y compris isolé)
Seuils	Aucun	≥ 25 clients, ≥ 5 serveurs/Office	Aucun	Aucun (consomme le quota MAK)
Dépendances	Active Directory	DNS SRV `_vlmcs._tcp`, TCP 1688	Accès internet ou téléphone	Poste d’admin avec VAMT
Administration	Très faible	Moyenne (hôte KMS, compteurs)	Faible (mais suivi du quota)	Faible à moyenne (inventaire centralisé)
Idéal pour	Parcs AD stables	Grands parcs >= seuils	Machines isolées / workgroup	Activations offline/à distance

Architecture cible recommandée

Deux domaines dans la même forêt : un objet d’activation ADBA publié dans la forêt suffit, quel que soit le domaine de rattachement des machines.
Deux domaines dans deux forêts distinctes : publier ADBA dans chaque forêt.
Workgroup : activer via MAK (en direct ou par VAMT), sans dépendance à l’AD.

Plan de mise en œuvre pas‑à‑pas

ADBA dans vos domaines

Installer le rôle Volume Activation Services sur au moins un contrôleur de domaine par forêt (serveur membre possible, mais un DC simplifie l’accès au schéma). # Sur Windows Server 2022 Install-WindowsFeature -Name VolumeActivation -IncludeManagementTools
Lancer l’assistant Volume Activation Tools et choisir Active Directory‑Based Activation.
Renseigner vos clés CSVLK (KMS Host) issues du contrat volume : une pour Windows Server 2022, une pour Windows 11 si besoin. L’assistant publie l’objet d’activation dans la partition Configuration de l’AD.
Vérifier/poser les GVLK sur les machines membres du domaine (souvent présent par défaut sur médias VL). Exemple : slmgr /ipk <GVLK_edition> slmgr /ato
Contrôler sur un échantillon : slmgr /dlv slmgr /xpr En ADBA, l’activation est automatiquement renouvelée tant que la machine contacte le domaine (renouvellement périodique comparable à KMS).

Postes workgroup : activation en MAK

Deux approches, cumulables :

MAK direct sur chaque portable : slmgr /ipk <MAK> slmgr /ato
MAK Proxy via VAMT (recommandé) :
1. Installer VAMT sur un poste d’admin.
2. Importer la clé MAK dans VAMT (suivi de consommation inclus).
3. Découvrir les machines (IP, plage, CSV) ; déployer l’activation proxy, y compris hors ligne (VAMT gère les tickets et l’Confirmation ID).
4. Exporter un rapport d’activation (inventaire, dates, éditions).

Option KMS (facultatif, serveurs uniquement)

Utile si vous préférez un modèle KMS pour les serveurs (seuil 5) ou si vous anticipez ≥ 25 clients prochainement.

Sur un serveur, installer Volume Activation Services et choisir Key Management Service.
Entrer la CSVLK Windows Server 2022 et activer l’hôte.
Vérifier/Publier l’enregistrement DNS SRV _vlmcs._tcp.<domaine> vers le port 1688/TCP de l’hôte KMS.
Sur quelques serveurs clients, confirmer : slmgr /ato slmgr /dlv

Important : ne laissez pas d’ancien enregistrement DNS _vlmcs._tcp si vous n’opérez pas KMS pour les clients ; sinon des postes tenteront KMS et échoueront (en‑dessous du seuil 25).

Qui active quoi dans votre parc (résumé)

Famille	Quantité	État	Méthode	Clé à utiliser	Remarques
Windows Server 2022	≈ 23	Membres de domaine	ADBA (ou KMS facultatif)	GVLK sur clients, CSVLK publiée	Seuil KMS serveurs atteint (>= 5)
Windows 11	8	Membres de domaine	ADBA	GVLK	Activation automatique via AD
Windows 11	8	Workgroup	MAK (VAMT conseillé)	MAK	KMS clients non viable (< 25)

Bonnes pratiques, gouvernance et sécurité

Clés et stocks :
- CSVLK (KMS Host) : utilisée pour publier ADBA et/ou héberger KMS.
- GVLK : présente par défaut sur médias VL, nécessaire côté client (ADBA/KMS).
- MAK : à réserver aux machines hors domaine, aux DMZ isolées, aux lab éphémères.
GPO :
- Évitez de forcer un hôte KMS si vous standardisez ADBA pour les clients.
- Scripts slmgr via GPO : utiles pour harmoniser GVLK, faire un fallback MAK en cas d’exception, ou forcer un /ato après déploiement.
Disponibilité :
- ADBA : l’objet est répliqué sur tous les DC de la forêt ; pas de point unique critique.
- KMS : si vous l’utilisez, prévoyez au moins deux hôtes et surveillez les compteurs.
Réseau :
- ADBA : pas d’ouverture spécifique (communication AD standard).
- KMS : port 1688/TCP depuis les clients vers l’hôte KMS ; publier/maintenir _vlmcs._tcp en DNS.
Conformité & traçabilité : centralisez les preuves via VAMT (exports CSV), conservez les captures slmgr /dlv et l’historique des clés (coffre‑fort, gestion des accès).

Erreurs fréquentes et comment les éviter

Mélanger ADBA et un ancien KMS non maîtrisé : supprimez les enregistrements DNS KMS si vous n’opérez plus KMS pour les clients.
Images contenant une MAK : bannissez la MAK des images de référence ; utilisez GVLK + ADBA/KMS, et sysprep pour réinitialiser l’identifiant (CMID). Sinon, vous consommerez la MAK inutilement.
GVLK absente ou incorrecte : installez la GVLK correspondant à l’édition exacte (Pro, Enterprise, Datacenter, etc.).
Serveur KMS derrière un pare‑feu : n’oubliez pas 1688/TCP et le DNS SRV.
Machines off‑domain cherchant ADBA : normal qu’elles échouent. Utilisez MAK/VAMT.

Procédures et commandes utiles

# Afficher la licence et l’état d’activation
slmgr /dli
slmgr /dlv
slmgr /xpr

# Installer une clé (GVLK ou MAK) puis activer

slmgr /ipk \
slmgr /ato

# Retirer une clé produit de la machine

slmgr /upk

# Forcer une nouvelle tentative d’activation (post‑jointure au domaine)

slmgr /ato

# Fixer un hôte KMS spécifique (si vous optez pour KMS)

slmgr /skms kms.contoso.local:1688
slmgr /ato

# Revenir à la découverte auto (SRV DNS)

slmgr /ckms
slmgr /ato

Cas particuliers et réponses rapides

Deux domaines, même forêt : un seul déploiement ADBA dans la forêt suffit. Toutes les machines membres, quel que soit le domaine enfant, seront activées si elles ont une GVLK.
Deux forêts différentes : déployer ADBA dans chaque forêt (les objets d’activation ne traversent pas les frontières de forêt).
RODC : ADBA fonctionne, l’objet étant dans la partition Configuration répliquée. Les postes doivent pouvoir contacter un DC (lecture) pour l’activation.
Serveur Core : identique aux éditions GUI (utilisez slmgr en CLI).
VDI et fermes RDS : respectez les seuils KMS si vous optez pour KMS ; sinon ADBA reste idéal pour les VMs jointes au domaine.
Office volume : seuil KMS = 5. ADBA peut activer les versions compatibles en domaine ; sinon MAK/VAMT. Harmonisez avec la stratégie Windows choisie.

Checklist de déploiement express

✔️ Confirmer la topologie : deux domaines même forêt ? Sinon, deux forêts.
✔️ Récupérer les clés : CSVLK (Windows Server 2022, Windows 11 si nécessaire), MAK, GVLK (listes officielles).
✔️ Publier ADBA dans chaque forêt via Volume Activation Tools.
✔️ Vérifier que les images et GPO distribuent la GVLK adéquate par édition.
✔️ Activer les 8 portables workgroup en MAK (de préférence via VAMT).
✔️ Optionnel : si KMS pour serveurs, créer/purger l’enregistrement DNS SRV _vlmcs._tcp selon le cas.
✔️ Documenter : exports VAMT, captures slmgr, coffre‑fort des clés.

Plan d’évolution

Maintenant :
- ADBA pour tous les membres du domaine (23 serveurs + 8 postes).
- MAK pour les 8 portables en workgroup (VAMT conseillé).
À horizon 12‑24 mois :
- Si le parc clients atteint ≥ 25, possibilité d’introduire KMS pour ces clients (ou de rester en ADBA si tous sont joints au domaine).
- Standardiser les images et GPO pour éviter les clés MAK résiduelles.

FAQ ciblée

Faut‑il installer le rôle “Volume Activation Services” sur plusieurs DC ?
Ce n’est pas obligatoire pour ADBA : une fois l’objet d’activation publié, tous les DC de la forêt peuvent servir l’activation. Multiplier les serveurs n’apporte que du confort d’administration.

ADBA consomme‑t‑il des compteurs comme KMS ?
ADBA n’a pas de seuil. Les clients renouvellent périodiquement leur état d’activation via l’AD tant qu’ils restent membres du domaine.

Que se passe‑t‑il si un portable workgroup n’a pas Internet ?
Activez‑le via VAMT en mode proxy (prise en charge des activations hors ligne) ou par téléphone. Documentez la consommation MAK.

Peut‑on mélanger ADBA pour Windows et KMS pour Office ?
Oui, si cela répond à vos contraintes (par ex. postes non rejoints au domaine pour Office). Gardez une stratégie simple : ADBA pour membres du domaine, MAK ou KMS selon seuils pour le reste.

Conclusion

Dans une infrastructure à deux domaines, votre meilleur compromis coût‑simplicité‑robustesse est : ADBA pour tout ce qui est joint au domaine (serveurs et postes), MAK pour les portables en workgroup. KMS reste une option utile mais non nécessaire tant que vous n’atteignez pas 25 clients. Ce design couvre 100 % du parc, élimine les écueils de seuils, réduit la dette d’exploitation et se pilote aisément via VAMT, GPO et quelques commandes slmgr.

Rappel opérationnel : pensez à purger d’éventuels enregistrements DNS _vlmcs._tcp inutilisés, à bannir les MAK des images de référence, et à consigner toute activation via VAMT/exports pour la conformité.

ADBA vs KMS : activer Windows Server 2022 et Windows 11 dans deux domaines (workgroup inclus)