Activer des licences Windows Server

l’histoire d’un problème qui n’en était pas un

La mission : dix-sept serveurs et une deadline

Pendant mon stage chez Novalink, alors que nous assurions l’infogérance complète d’un client dont nous avions migré l’infrastructure quelques mois auparavant, mon responsable m’a confié une mission qui semblait relativement simple en apparence. Dix-sept machines virtuelles Windows Server 2022 devaient être activées avant la fin de leur période d’essai de trois mois accordée par Microsoft. La tâche m’a été confiée en toute autonomie avec une consigne claire et directe : « Débrouille-toi, il faut que ces serveurs soient activés avant la deadline. »

À ce moment-là de mon stage, j’étais déjà assez à l’aise avec l’administration Windows Server. J’avais réalisé plusieurs projets personnels où j’avais déployé des contrôleurs de domaine, des serveurs DNS et DHCP, et des serveurs de fichiers. Je comprenais donc l’importance de cette situation. Ces dix-sept serveurs n’étaient pas de simples machines de test, ils hébergeaient des services absolument critiques pour l’entreprise cliente : le contrôleur de domaine Active Directory, les applications métier, les serveurs RDS qui permettaient aux employés de travailler à distance. Sans ces machines correctement activées, c’était toute l’activité de l’entreprise qui risquait d’être impactée.

Ce projet traînait depuis un moment déjà parce qu’il y avait d’autres priorités plus urgentes, et la période d’essai de trois mois offrait une marge confortable. Mais maintenant que la deadline approchait, il fallait vraiment s’en occuper.

Le premier contact avec le problème : un message qui ne mène nulle part

J’ai commencé par ouvrir les paramètres d’activation Windows sur l’un des serveurs non activés pour voir exactement quel était le message d’erreur et comprendre quelle serait la procédure à suivre. C’est là que j’ai découvert un message qui me demandait d’ouvrir l’application « Obtenir de l’aide » pour contacter le support Microsoft et procéder à l’activation. Cette application, selon le message, était disponible via le Microsoft Store.

Sur le moment, je me suis dit que c’était la procédure officielle recommandée par Microsoft, donc logiquement c’était probablement la meilleure approche à suivre. J’ai cherché le Microsoft Store sur le serveur pour ouvrir cette fameuse application d’aide. Et là, rien. Pas de Microsoft Store visible nulle part dans le système. J’ai vérifié dans le menu démarrer, j’ai cherché dans les applications installées, j’ai même essayé de le lancer via la ligne de commande. Rien du tout.

C’est à ce moment-là que je me suis posé une question qui ne m’avait jamais traversé l’esprit auparavant : est-ce que le Microsoft Store existe sur Windows Server ? Cette question peut sembler évidente pour quelqu’un d’expérimenté, mais à l’époque, ce n’était pas du tout une évidence pour moi. J’utilisais Windows Server pour des tâches d’administration système, et je n’avais jamais eu besoin du Microsoft Store, donc je ne m’étais jamais vraiment demandé s’il était présent ou non sur ce système d’exploitation.

La recherche sur Internet : une fausse piste tentante

J’ai donc fait ce que tout technicien fait face à une question dont il ne connaît pas la réponse : j’ai cherché sur Internet. Assez rapidement, je suis tombé sur une discussion Reddit où un utilisateur posait exactement la même question qui me trottait dans la tête : peut-on avoir le Microsoft Store sur Windows Server ?

La réponse que j’ai trouvée était claire : non, le Microsoft Store n’est pas inclus par défaut dans Windows Server. Mais ce qui a immédiatement attiré mon attention, c’est qu’un des participants à cette discussion avait partagé un lien vers un repository GitHub contenant un script d’installation du Microsoft Store sur Windows Server.

Sur le moment, j’avoue que j’ai été tenté. Voilà une solution toute faite qui semblait résoudre mon problème. J’installe le Microsoft Store via ce script, j’ouvre ensuite l’application d’aide, et je suis la procédure officielle de Microsoft pour activer mes serveurs. Simple, rapide, efficace.

Mais quelque chose me gênait dans cette approche. D’abord, je me suis dit que si Microsoft avait volontairement choisi de ne pas inclure le Microsoft Store dans Windows Server, c’était probablement pour de bonnes raisons techniques ou de sécurité. Installer quelque chose que l’éditeur du système a délibérément exclu me semblait être une mauvaise idée. Ensuite, et c’est peut-être le plus important, je n’avais aucune garantie sur la fiabilité et la sécurité de ce script trouvé sur GitHub. C’était juste un script créé par quelqu’un sur Internet, sans certification officielle, sans garantie de qualité ou de sécurité. Faire confiance à un script inconnu sur une infrastructure de production, surtout sur des serveurs critiques hébergeant le contrôleur de domaine et les applications métier d’un client, c’était ajouter un risque inutile à une situation qui n’en avait pas besoin.

De plus, j’ai réfléchi à l’utilité réelle de cette démarche. Même si j’installais le Microsoft Store et que j’arrivais à ouvrir l’application d’aide, qu’est-ce que cela m’apporterait concrètement ? Probablement juste un formulaire de contact avec le support Microsoft qui me donnerait des instructions que je pouvais très certainement trouver moi-même dans la documentation officielle. Ce n’était pas le Microsoft Store qui allait activer magiquement mes serveurs, c’était juste un intermédiaire pour accéder au support.

J’ai donc pris la décision d’écarter cette piste et de chercher une autre solution.

La vraie découverte : comprendre comment fonctionne réellement l’activation

Puisque la méthode recommandée dans l’interface Windows ne fonctionnait pas et que je refusais d’utiliser un script non officiel pour installer le Microsoft Store, j’ai décidé de creuser plus profondément et de chercher directement dans la documentation officielle de Microsoft comment fonctionnait réellement l’activation des licences Windows Server en environnement virtualisé.

C’est là que j’ai découvert quelque chose de fondamental que j’ignorais complètement. Microsoft propose effectivement un système d’activation automatique pour les machines virtuelles Windows Server, mais ce système ne fonctionne que dans un contexte très spécifique : quand on utilise Hyper-V, l’hyperviseur de Microsoft, et qu’on possède une licence Windows Server Datacenter sur le serveur physique hôte.

Dans ce scénario, les machines virtuelles créées sur cet hyperviseur Hyper-V sont censées s’activer automatiquement grâce à la licence Datacenter de l’hôte physique. Mais, et c’est là que tout s’éclairait soudainement, cette activation automatique ne fonctionne qu’avec Hyper-V. Si on utilise un autre hyperviseur, comme VMware vSphere ESXi qui était justement celui utilisé dans l’infrastructure de notre client, cette activation automatique ne se déclenche pas.

À ce moment précis de ma recherche, j’ai compris que j’avais passé du temps à chercher une solution à un problème qui n’était pas vraiment celui que je pensais résoudre. Le vrai problème n’était pas que Windows ne me donnait pas accès au support Microsoft faute de Microsoft Store. Le vrai problème était que nous étions dans une configuration où l’activation automatique ne pouvait tout simplement pas fonctionner à cause de l’hyperviseur utilisé.

Cette découverte m’a aussi fait réaliser quelque chose de plus large sur la stratégie commerciale de Microsoft. Le fait que l’activation automatique soit limitée à Hyper-V n’est probablement pas un hasard technique. Hyper-V est gratuit, donc Microsoft ne perd rien financièrement à offrir cette fonctionnalité pratique exclusivement sur son propre hyperviseur. Mais en faisant cela, ils créent une incitation forte pour les entreprises à migrer vers leur écosystème complet plutôt que d’utiliser des solutions concurrentes comme VMware. C’est une stratégie de verrouillage propriétaire assez classique, et sur le moment, je dois avouer que je l’ai trouvée assez frustrante et même un peu malhonnête de la part de Microsoft. Pourquoi limiter artificiellement une fonctionnalité qui pourrait très bien fonctionner sur n’importe quel hyperviseur, si ce n’est pour favoriser commercialement sa propre technologie au détriment de ses concurrents ?

Mais bon, qu’importe mes opinions sur les stratégies commerciales de Microsoft, je devais maintenant trouver une solution concrète pour activer mes dix-sept serveurs.

L’évaluation des solutions possibles

Une fois que j’avais compris la vraie nature du problème, j’ai exploré les différentes solutions techniques qui s’offraient à moi.

La première option était d’utiliser un serveur de licences, aussi appelé KMS (Key Management Service). C’est un système qui permet de centraliser la gestion des activations de licences Microsoft dans une infrastructure. Au lieu d’activer chaque machine individuellement, on configure un serveur KMS qui distribue les activations à toutes les machines du réseau. C’est une solution élégante et automatisée qui fonctionne très bien dans les grandes infrastructures.

Mais quand j’ai consulté l’infrastructure du client, j’ai découvert qu’il existait déjà un serveur KMS en place, mais il était exclusivement dédié aux licences CAL RDS, c’est-à-dire les licences de connexion au bureau à distance. Je n’étais pas autorisé à modifier la configuration de ce serveur ou à y ajouter la gestion des licences Windows Server, probablement pour éviter de créer des conflits ou des problèmes sur un système qui fonctionnait déjà correctement. Cette option était donc écartée.

La deuxième option était de créer un script d’activation et de le déployer automatiquement via une GPO (Group Policy Object) qui s’exécuterait au démarrage de chaque serveur. Techniquement, c’est une solution qui aurait parfaitement fonctionné. Je crée la GPO, j’y attache mon script d’activation, je l’applique à l’OU (Organizational Unit) contenant mes dix-sept serveurs, et au prochain redémarrage, tous les serveurs s’activent automatiquement. Simple, propre, automatisé.

Mais là encore, quelque chose me gênait dans cette approche. D’abord, cette GPO nécessitait un redémarrage des serveurs pour s’appliquer, ou au minimum un gpupdate forcé sur chaque machine. Or, ces serveurs hébergeaient des services de production critiques. Les redémarrer en pleine journée n’était pas envisageable, il aurait fallu planifier une fenêtre de maintenance en dehors des heures de bureau, coordonner avec le client, s’assurer qu’aucune opération critique n’était en cours. Tout cela pour activer des licences semblait disproportionné.

Mais surtout, et c’est ce qui a vraiment motivé ma décision, je me suis dit qu’ajouter une GPO pour une opération ponctuelle qui ne se répéterait probablement jamais était une mauvaise pratique. C’est quelque chose que j’avais observé en entreprise : cette tendance à créer des GPO pour absolument tout et n’importe quoi, y compris pour des besoins ponctuels ou des dépannages temporaires. Le résultat, c’est qu’au fil des années, on se retrouve avec trente, quarante, parfois même plus de GPO qui s’appliquent à chaque démarrage, ce qui surcharge les machines et rallonge considérablement les temps de démarrage. De plus, beaucoup de ces GPO sont des scripts de dépannage qui restent actifs indéfiniment alors qu’ils ne servent plus à rien depuis longtemps, simplement parce que personne ne pense à les désactiver ou à les supprimer.

Les GPO sont un outil formidable pour gérer des politiques qui doivent s’appliquer de manière permanente et systématique à un ensemble de machines. Mais les utiliser pour une action ponctuelle, c’est comme utiliser un marteau-piqueur pour planter un clou. Techniquement ça fonctionne, mais c’est disproportionné et cela crée des effets secondaires indésirables.

J’ai donc décidé d’opter pour une troisième solution, beaucoup plus simple et pragmatique : créer un script d’activation et l’exécuter manuellement sur chacun des dix-sept serveurs.

La solution finale : simplicité et efficacité

La solution technique elle-même était finalement assez simple. J’ai créé un petit script qui modifiait la clé de licence de chaque machine virtuelle pour y insérer la clé Windows Server Datacenter que nous possédions, puis qui déclenchait l’activation auprès des serveurs de Microsoft.

Pour organiser mon travail, j’ai d’abord établi un ordre logique d’activation en fonction de l’importance et des dépendances entre les serveurs. J’ai commencé par le contrôleur de domaine Active Directory, parce que c’est le serveur le plus critique de toute l’infrastructure et que tous les autres serveurs en dépendent pour fonctionner correctement. Ensuite, j’ai activé les serveurs hébergeant les applications métier essentielles au fonctionnement quotidien de l’entreprise. Puis le serveur RDS qui était le service le plus utilisé par les employés pour travailler à distance. Et ainsi de suite en suivant une logique de criticité décroissante.

J’ai créé un ticket dans notre système de gestion pour documenter mon intervention. Ce n’était pas une obligation, personne ne m’avait demandé de le faire, mais j’ai trouvé important de tracer mon travail pour plusieurs raisons. D’abord, cela permettait au client de voir exactement ce qui était fait sur son infrastructure. Ensuite, cela permettait à mon maître de stage de suivre ma progression sans avoir besoin de me déranger constamment pour me demander où j’en étais. Et enfin, cela créait une documentation qui pourrait servir à l’avenir si quelqu’un rencontrait le même type de problème.

Dans ce ticket, j’ai documenté non seulement la solution finale qui a fonctionné, mais aussi les différentes pistes que j’avais explorées et pourquoi elles n’avaient pas abouti. J’ai notamment expliqué la tentative avec le Microsoft Store et pourquoi j’avais décidé de ne pas installer le script GitHub. Cette documentation des fausses pistes peut sembler inutile puisqu’elles n’ont pas mené à la solution, mais en réalité c’est très précieux. Cela évite que quelqu’un d’autre dans l’équipe ne perde du temps à explorer cette même avenue en pensant qu’elle pourrait mener quelque part. C’est une approche collaborative de la documentation où on partage non seulement ce qui a fonctionné mais aussi ce qui n’a pas fonctionné et pourquoi.

Au fur et à mesure que j’activais chaque serveur, je mettais à jour le ticket avec ma progression. De ma propre initiative, j’envoyais aussi régulièrement de courts comptes rendus à mon responsable pour le tenir informé de l’avancement du projet.

L’exécution : treize minutes pour dix-sept serveurs

Une fois mon processus bien rodé et mon script testé sur les premiers serveurs, l’activation proprement dite s’est déroulée de manière très fluide. Pour chaque serveur, je me connectais, je lançais mon script, j’attendais quelques instants le temps que l’activation se propage dans le système, puis j’ouvrais les paramètres d’activation pour vérifier visuellement que tout était correct. Cette dernière vérification était importante parce que l’activation ne s’affichait pas immédiatement après l’exécution du script, il fallait patienter un petit moment que le système se synchronise avec les serveurs d’activation de Microsoft.

Au total, pour activer les dix-sept serveurs en incluant toutes les vérifications, j’ai mis environ treize minutes. C’est finalement ironique quand on y pense. J’avais passé beaucoup plus de temps à chercher et à comprendre quelle était la bonne approche qu’à exécuter la solution elle-même. Mais c’est exactement comme ça que fonctionne le travail d’administration système en environnement réel. La majorité du temps n’est pas passée à exécuter des commandes, mais à réfléchir, à comprendre, à évaluer les risques, et à choisir la meilleure approche parmi plusieurs options possibles.

La validation et les leçons apprises

Une fois que tous les serveurs ont été activés et que j’ai vérifié que tout fonctionnait correctement, j’ai finalisé la documentation dans le ticket en y incluant tous les détails techniques, toutes les pistes explorées, et la solution finale retenue. J’ai utilisé des mots-clés et des catégories appropriées dans le ticket pour faciliter les futures recherches. Si dans quelques mois ou quelques années, quelqu’un chez Novalink cherche comment activer des licences Windows Server dans un environnement VMware, il pourra retrouver facilement ce ticket via la barre de recherche et bénéficier de toute mon expérience sans avoir à refaire le même parcours.

Mon responsable informatique chez Novalink a consulté le ticket et a approuvé ma méthodologie de travail et la façon dont j’avais géré la demande. Ce qui m’a particulièrement rassuré, c’est qu’il partageait complètement ma logique concernant le refus de créer une GPO pour cette opération ponctuelle. Il m’a même confirmé que de toute façon, il n’aurait jamais validé une GPO qui nécessitait de redémarrer les serveurs de production juste pour activer des licences. Savoir que mon raisonnement était aligné avec celui de professionnels plus expérimentés m’a confirmé que j’étais sur la bonne voie dans ma compréhension de ce qu’est une bonne gestion d’infrastructure.

Ce que j’en retiens

Ce projet, même s’il peut sembler banal comparé au déploiement d’une architecture IDS/IPS en environnement ultra-sécurisé, m’a appris des choses tout aussi importantes sur le métier d’administrateur système.

D’abord, j’ai compris que tous les problèmes ne sont pas là où on les cherche initialement. J’étais parti sur la piste du Microsoft Store et de l’application d’aide parce que c’est ce que l’interface Windows me suggérait, mais le vrai problème était en réalité l’incompatibilité entre la méthode d’activation automatique de Microsoft et l’hyperviseur VMware utilisé par le client. Cette expérience m’a appris l’importance de remettre en question mes hypothèses initiales et de chercher à comprendre vraiment comment les choses fonctionnent en profondeur plutôt que de suivre aveuglément les suggestions superficielles.

Ensuite, j’ai réalisé qu’une solution technique n’est pas bonne ou mauvaise dans l’absolu, elle est appropriée ou inappropriée selon le contexte. La GPO aurait techniquement résolu mon problème, mais elle aurait créé d’autres problèmes à long terme en ajoutant une couche de complexité inutile à l’infrastructure. Le script GitHub aurait peut-être fonctionné, mais il aurait introduit un risque de sécurité inacceptable sur une infrastructure de production. La solution manuelle était peut-être moins élégante techniquement qu’une automatisation complète, mais elle était la plus appropriée dans ce contexte spécifique.

J’ai aussi appris l’importance de documenter non seulement ce qui fonctionne, mais aussi ce qui ne fonctionne pas et pourquoi. Cette documentation des échecs et des fausses pistes est souvent négligée, mais elle a une valeur énorme pour éviter que d’autres ne perdent du temps sur les mêmes impasses.

Enfin, ce projet m’a sensibilisé à la question de la dette technique et de la maintenance à long terme des infrastructures. Il est tentant, face à chaque petit problème, de créer une nouvelle GPO, d’ajouter un nouveau script, d’installer un nouveau service. Mais au fil des années, toutes ces petites couches s’accumulent et finissent par créer des systèmes de plus en plus complexes et difficiles à maintenir. Apprendre à dire non à une solution technique qui fonctionne mais qui n’est pas appropriée, c’est une compétence professionnelle importante que ce projet m’a aidé à développer.

Ce projet illustre une réalité du métier d’administrateur système que les formations théoriques ne transmettent pas toujours bien. Le travail quotidien n’est pas fait uniquement de grands déploiements spectaculaires et de projets exceptionnels. C’est aussi, et peut-être surtout, fait de petites tâches apparemment banales qui nécessitent pourtant autant de réflexion, de rigueur et de professionnalisme que les grands projets. Savoir gérer ces tâches ordinaires avec le même sérieux et la même méthodologie que les missions extraordinaires, c’est ce qui différencie un bon professionnel d’un simple exécutant.