Architecture technique de l'activation par protocole KMS

Le protocole Key Management Service (KMS) repose sur un mécanisme d'activation en réseau local qui permet aux postes clients de Windows et Office d'obtenir une licence volume en communiquant avec un serveur émulé. Contrairement aux clés MAK (Multiple Activation Key), qui nécessitent une connexion directe aux serveurs Microsoft, KMS utilise un cycle de validation de 180 jours. Un script d'administration系统化 peut automatiser la configuration du client, l'installation de la clé GVLK appropriée et la planification d'une tâche récurrente pour garantir la pérennité de l'état activé.

L'outil automatisé présenté dans ce guide s'appuie sur l'interpréteur de commandes Windows (cmd.exe) et utilise des utilitaires natifs comme slmgr.vbs et cscript.exe pour interroger le registre des licences, modifier les serveurs KMS cible et gérer le service sppsvc (Software Protection Platform Service). Cette approche élimine les dépendances vers des exécutables tiers non vérifiés.

Configuration modulaire et gestion des variables

Pour éviter les modifications manuelles récurrentes, il est préférable de structurer le script avec un bloc de configuration centralisé. Le modèle suivant remplace les variables globales plates par un système de chargement conditionnel et de noms explicites, tout en conservant la compatibilité avec les environnements Windows modernes.

:: ==========================================
::  BLOC DE CONFIGURATION D'ACTIVATION
:: ==========================================
@echo off
setlocal EnableExtensions

:: Contrôle du ciblage des produits
set "OS_LICENSE_TARGET=ENABLED"
set "OFFICE_SUITE_TARGET=ENABLED"
set "CONVERT_RETAIL_TO_VOL=1"

:: Paramètres de planification KMS
set "RENEWAL_CYCLE_DAYS=180"
set "TASK_SCHEDULE_INTERVAL=1440"
set "KMS_SERVER_PORT=1688"
set "ACTIVATION_RETRIES=3"

:: Options de journalisation et de déploiement
set "SILENT_MODE=0"
set "ENABLE_LOGGING=1"
set "LOG_OUTPUT_PATH=%temp%\kms_activation.log"

:: Vérification des droits administrateur
net session >nul 2>&1
if %errorLevel% neq 0 (
    echo ERREUR: Droits administrateur requis. Relancez en tant qu'administrateur.
    exit /b 1
)

:: Logique de chargement
if "%OS_LICENSE_TARGET%"=="ENABLED" call :configure_windows_sku
if "%OFFICE_SUITE_TARGET%"=="ENABLED" call :configure_office_sku
exit /b

:configure_windows_sku
    echo [INFO] Configuration du SKU Windows en cours...
    :: Ici s'insère la détection automatique de l'edition et l'application du GVLK correspondant
    cscript //nologo %windir%\system32\slmgr.vbs /skms 127.0.0.1:%KMS_SERVER_PORT%
    cscript //nologo %windir%\system32\slmgr.vbs /ato
    schtasks /create /tn "KMS_Renewal_Win" /tr "cscript //nologo %windir%\system32\slmgr.vbs /ato" /sc daily /mo %TASK_SCHEDULE_INTERVAL% /f
    goto :eof

:configure_office_sku
    echo [INFO] Configuration du SKU Office en cours...
    if "%CONVERT_RETAIL_TO_VOL%"=="1" (
        :: Conversion automatique des licences retail vers volume
        for /f "tokens=*" %%p in ('dir /b /s "%ProgramFiles%\Microsoft Office\root\Licenses16\*.xrm-ms" 2^>nul') do (
            cscript //nologo "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /inslic:"%%p"
        )
    )
    cscript //nologo "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /sethst:127.0.0.1
    cscript //nologo "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /act
    goto :eof

Déploiement silencieux et intégration système

Dans un contexte de parc informatique, l'activation doit pouvoir s'exécuter sans intervention utilisateur. La configuration silencieuse repose sur la désactivation des interactions console et la redirection des sorties vers un fichier de journalisation structuré.

• Mode silencieux : L'indicateur SILENT_MODE=1 supprime les pauses (pause) et les invites utilisateur. Le script s'exécute en arrière-plan via l'outil psexec ou une stratégie de groupe (GPO).
• Planification native : La tâche planifiée KMS_Renewal_Win et sa contrepartie Office assurent un renouvellement automatiqeu avant l'expiration du délai de 180 jours. L'intervalle est généralement configuré sur 7 à 14 jours pour anticiper les coupures réseau.
• Gestion des pare-feu : Le port TCP 1688 doit être autorisé en sortie vers l'adresse locale ou le serveur KMS distant. Une règle de pare-feu Windows avancée peut être injectée via netsh advfirewall pour éviter les blocages intempestifs.

Diagnostic et résolution des incidents

Les échecs d'activation proviennent généralement d'une désynchronisation horaire, d'un service de protection logiciel désactivé ou d'un SKU incompatible. Le tableau suivant recense les codes d'erreur courants et les correctifs techniques associés.

Vérification de l'état des licences

Une fois le script exécuté, il est indispensable de confirmer la validité des licences via les utilitaires natifs de Windows.

Contrôle Windows :

cscript //nologo %windir%\system32\slmgr.vbs /dli
cscript //nologo %windir%\system32\slmgr.vbs /xpr

La première commande affiche les détails de la licence (canal, ID d'activation, serveur KMS ciblé). La seconde confirme explicitement si l'activation est permanente ou périodique.

Contrôle Office :

cscript //nologo "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs /dstatus

Cette instruction liste les clés installées, leur date d'expiration et l'état actuel (LICENSED ou NOTIFICATIONS). Si le statut indique NOTIFICATIONS, un renouvellement manuel via /act est nécessaire.

Pour automatiser cette vérification, un script de monitoring peut interroger la sortie standard des commandes ci-dessus et alerter via eventcreate ou une API de supervision lorsque le champ Remaining descend en dessous de 30 jours. Cette approche garantit une maintenance proactive sans intervention directe sur les postes.