Mettre en place Active Directory‑Based activation sous Windows Server 2025

Activer un parc Windows machine par machine est long, peu fiable et difficile à auditer. Avec Active Directory-Based Activation, souvent abrégé ADBA, l’activation est distribuée par votre annuaire aux ordinateurs joints au domaine. Sous Windows Server 2025, cette approche convient particulièrement aux organisations déjà structurées autour d’Active Directory et de licences en volume.

Comprendre ce qu’ADBA fait, et ce qu’il ne fait pas

ADBA est un mécanisme d’activation Microsoft intégré à Active Directory Domain Services. L’administrateur crée dans la forêt un ou plusieurs objets d’activation, chacun associé à une clé hôte de licences en volume. Lorsqu’un ordinateur Windows compatible, joint au domaine, contacte un contrôleur de domaine, il peut obtenir son activation sans avoir à dialoguer directement avec Microsoft ni avec un hôte KMS sur le réseau.

Le rôle de Windows Server 2025 est ici celui d’outil d’administration: il sert à publier et activer l’objet dans Active Directory. Il ne transforme pas votre serveur en distributeur de licences ni en système de comptage. L’objet est ensuite répliqué avec la configuration Active Directory dans la forêt.

• ADBA active techniquement les éditions Windows prises en charge et correctement installées.
• ADBA ne remplace pas l’achat de licences Windows Server, de CAL Windows Server ou de droits d’accès client.
• ADBA ne gère pas les licences Microsoft 365, les applications métier ou les postes hors domaine.
• ADBA n’est pas Entra ID: il s’appuie sur un Active Directory local classique, avec des contrôleurs de domaine disponibles.

ADBA, KMS ou MAK: choisir le bon mécanisme

ADBA n’est pas systématiquement le meilleur choix. Il est très efficace pour des postes de travail et serveurs durablement joints à un domaine, mais il devient moins adapté aux appareils isolés, aux environnements multi-forêts sans administration commune ou aux machines rarement connectées au réseau interne. Avant de configurer quoi que ce soit, classez votre parc selon son mode de connexion et son canal de licence.

Vérifier les prérequis de licences et d’infrastructure

Le prérequis le plus souvent oublié est le canal de licence. Pour créer un objet ADBA, vous avez besoin d’une clé hôte KMS, aussi appelée CSVLK, obtenue via votre programme de licences en volume. Cette clé est différente d’une clé MAK, qui sert à activer individuellement des machines, et d’une clé OEM ou Retail livrée avec un ordinateur.

Les clients doivent, eux aussi, utiliser une édition compatible avec les droits en volume et une clé cliente générique de volume, ou GVLK, appropriée à leur produit. Un poste livré avec Windows OEM n’est pas automatiquement basculé dans votre modèle de licences en volume parce qu’il rejoint le domaine. De même, une édition d’évaluation de Windows Server doit d’abord être convertie vers une édition licenciée compatible avant de pouvoir être activée normalement.

• Un environnement Active Directory Domain Services opérationnel, avec une réplication de configuration fonctionnelle entre contrôleurs de domaine.
• Un serveur sous Windows Server 2025, membre du domaine ou contrôleur de domaine selon vos règles d’exploitation, pour installer les outils d’activation en volume.
• Un compte ayant les autorisations nécessaires au niveau de la forêt; pour une première mise en place, il s’agit souvent d’un compte d’administration de forêt.
• Une connectivité Internet ponctuelle pour activer l’objet auprès de Microsoft, ou la possibilité d’utiliser l’activation téléphonique si votre politique réseau l’impose.
• La validation de la matrice de compatibilité Microsoft pour les éditions exactes que vous souhaitez activer: Windows Server 2025, versions clientes de Windows et produits plus anciens éventuels.

ADBA ne nécessite généralement pas de serveur dédié: les outils peuvent être installés sur un serveur d’administration existant et durci. Le coût logiciel spécifique est donc en principe nul si vous disposez déjà des droits Windows et de l’infrastructure. Le vrai budget se situe dans les licences en volume, la vérification de conformité, le temps de préparation et les tests; il varie fortement selon les éditions, le nombre de cœurs serveur, les CAL et votre contrat.

Préparer le déploiement avant d’entrer la moindre clé

Un court inventaire évite la majorité des échecs. Relevez, pour chaque famille de machines, la version de Windows, son édition, son état d’activation actuel, son appartenance au domaine et le type de clé installé. Ne vous fiez pas uniquement au constructeur: Dell, HP ou Lenovo peuvent livrer des machines très différentes du point de vue du canal de licence.

Choisissez ensuite une forêt pilote, un petit groupe de serveurs non critiques et quelques postes représentatifs. Prévoyez un retour arrière simple: documentez l’état initial, exportez vos rapports d’inventaire et conservez les clés hôtes dans un coffre-fort de mots de passe ou une procédure d’accès restreinte. Ne diffusez jamais une CSVLK dans un script, une image système, une documentation partagée ou une capture d’écran.

Installer et configurer ADBA sur Windows Server 2025

La configuration s’effectue depuis le Gestionnaire de serveur de Windows Server 2025. Le composant à ajouter est le rôle Services d’activation en volume, puis ses outils d’administration. L’assistant vous guide vers l’option d’activation basée sur Active Directory. Évitez d’activer simultanément plusieurs solutions sans objectif clair: un parc peut techniquement utiliser différents mécanismes, mais la maintenance devient vite confuse.

1. 1. Contrôler l’annuaire et choisir le serveur d’administration
   Vérifiez la santé de la réplication Active Directory et DNS, puis sélectionnez un serveur Windows Server 2025 administré, sauvegardé et accessible aux équipes autorisées. Il n’a pas besoin d’être exposé à Internet en permanence.
2. 2. Ajouter les services d’activation en volume
   Dans le Gestionnaire de serveur, utilisez l’assistant Ajout de rôles et de fonctionnalités, sélectionnez Services d’activation en volume et installez les outils d’activation en volume. Redémarrez uniquement si l’assistant le demande.
3. 3. Créer l’objet Active Directory
   Lancez les Outils d’activation en volume, sélectionnez Active Directory-Based Activation, puis saisissez la clé hôte KMS/CSVLK correspondant au produit visé. Utilisez un compte autorisé à écrire la configuration de la forêt.
4. 4. Activer l’objet auprès de Microsoft
   Choisissez l’activation en ligne si la politique réseau le permet, ou l’activation téléphonique. Cette étape active l’objet publié dans Active Directory; elle ne doit pas être répétée par chaque poste client.
5. 5. Attendre la réplication et tester
   Laissez la configuration se répliquer vers les contrôleurs de domaine concernés. Testez ensuite un appareil du pilote avec une édition en volume compatible, joint au domaine, avant d’étendre le dispositif.

Configurer les clients et vérifier que l’activation fonctionne

Sur les images de déploiement, utilisez l’édition prévue par vos droits de licence et assurez-vous que la clé cliente GVLK correspond au produit installé. Une fois la machine jointe au domaine, l’activation est normalement déclenchée automatiquement lorsqu’elle contacte un contrôleur de domaine. Pour un test immédiat, un administrateur peut lancer la commande slmgr /ato dans une invite élevée.

Pour contrôler le résultat sans dévoiler inutilement de clé, utilisez slmgr /xpr afin d’afficher l’état d’expiration, et slmgr /dlv pour obtenir des détails sur le canal et l’état de licence. Complétez ce contrôle par la page Activation des paramètres Windows. Sur un serveur, vérifiez aussi que l’édition réellement installée correspond bien à celle attendue dans votre standard d’exploitation.

• Testez au moins un poste Windows client et un serveur Windows Server 2025 si les deux familles sont concernées.
• Testez un ordinateur dans chaque domaine important de la forêt, après réplication.
• Vérifiez le comportement après un redémarrage et après une reconnexion au réseau de l’entreprise.
• Conservez un relevé anonymisé de l’état avant et après pilote pour votre dossier de changement.

Dépanner les échecs courants et maintenir le dispositif

Quand un client ne s’active pas, commencez par le plus simple: est-il réellement joint au bon domaine, peut-il joindre un contrôleur de domaine, son horloge est-elle correcte et l’édition installée relève-t-elle bien de votre licence en volume? Un poste en groupe de travail, un appareil connecté seulement à Internet ou une installation avec une clé OEM ne bénéficiera pas automatiquement d’ADBA.

Ensuite, vérifiez l’objet d’activation et sa réplication dans Active Directory. Il est stocké dans la partition de configuration de la forêt: ne le modifiez pas directement avec un outil bas niveau sauf procédure Microsoft documentée et sauvegarde préalable. Utilisez plutôt les Outils d’activation en volume pour consulter ou mettre à jour votre configuration. Une réplication incomplète explique fréquemment pourquoi l’activation fonctionne dans un site et échoue dans un autre.

Les ordinateurs portables restent un cas particulier. Ils n’ont pas besoin de contacter Microsoft à chaque usage, mais ils doivent rejoindre périodiquement le domaine pour renouveler leur activation. Une connexion VPN régulière ou un accès aux contrôleurs de domaine selon votre architecture est donc nécessaire. Pour des équipements durablement hors réseau, une stratégie MAK ou un autre dispositif adapté peut être plus réaliste.

• Échec sur une seule machine: contrôlez l’édition, la clé cliente, l’appartenance au domaine, l’heure et les journaux de licence.
• Échec dans un site entier: contrôlez d’abord la connectivité vers les contrôleurs de domaine, DNS et la réplication AD.
• Échec après clonage de VM: revoyez votre modèle d’image et utilisez Sysprep avec généralisation avant le déploiement, plutôt qu’un clonage d’une machine déjà activée.
• Échec après changement de contrat: vérifiez que la nouvelle clé hôte couvre toujours les produits ciblés avant de remplacer ou d’ajouter un objet.

Passer à l’action: un déploiement sûr en quatre décisions

Pour réussir, ne commencez pas par l’assistant Windows Server. Commencez par décider si votre parc est bien majoritairement joint au domaine, confirmez vos droits de licences en volume, identifiez les éditions réellement déployées et choisissez une forêt pilote. Ces quatre décisions séparent un déploiement propre d’une accumulation de contournements.

1. Valider le périmètre
   Séparez les machines jointes au domaine, les appareils nomades, les équipements isolés et les environnements hors forêt. Réservez ADBA au périmètre qui peut réellement en bénéficier.
2. Faire confirmer les clés et les droits
   Demandez à la personne en charge des licences ou à votre revendeur de confirmer la clé hôte et les éditions couvertes. Conservez cette confirmation avec votre inventaire.
3. Déployer un pilote mesurable
   Publiez l’objet, attendez la réplication et contrôlez l’activation sur un échantillon varié de postes et serveurs avant tout déploiement de masse.
4. Industrialiser et documenter
   Intégrez les GVLK compatibles dans vos images approuvées, surveillez les échecs d’activation et consignez chaque évolution de clé ou d’objet dans votre gestion de changements.

Bien mis en place, Active Directory-Based Activation simplifie l’exploitation sans ajouter de point de passage réseau dédié pour l’activation. Sa réussite repose moins sur un paramètre Windows Server 2025 que sur la cohérence entre votre annuaire, vos images systèmes et vos droits de licences.