🌐 Aussi en: English · Deutsch · Español
L’heure des aveux. Après le journal de bataille de la migration Nextcloud, un nombre à deux chiffres d’exécutions de playbooks, un jeu de règles nftables qui a joyeusement vidé les propres tables de K3s et plus de YAML qu’un être humain ne devrait en lire en une seule semaine, j’en avais officiellement ras-le-bol de Nextcloud, d’Ansible et de tout ce qui contient le mot « migration ». Mais alors vraiment.
J’ai donc fait ce que fait tout nerd Linux raisonnable quand il sature de Linux : je suis passé de l’autre côté. Trois serveurs, trois installations fraîches de Windows Server 2025 et quelques soirées d’Active Directory, de DNS, de DHCP, de stratégies de groupe, de Storage Spaces et de BitLocker. Pas de YAML. Juste beaucoup de Get- et de Set-.
Soyons clairs : ce n’est pas un récit de conversion. Je mène désormais deux voies de front. Linux reste là où il est et continue d’abattre le gros du travail, tandis qu’à titre privé je veux vraiment apprendre le côté Microsoft, et plus précisément le serveur. Pas « cliquer sur Suivant jusqu’à ce que ça marche ». Comprendre ce que fait un contrôleur de domaine au démarrage, pourquoi le basculement DHCP a la forme qu’il a, et ce qu’une stratégie de groupe écrit réellement dans le registre. Le homelab sert de salle de classe.
Ou, moins solennellement : j’ai simplement envie de jouer un moment avec une vraie infrastructure Windows. Domaine, stratégies, services de fichiers, correctifs, chiffrement, virtualisation, le paquet complet, avec assez de machines pour que l’ensemble se comporte comme une petite entreprise et non comme une VM de test isolée que je supprimerai au bout d’une heure.
🖥️ La composition de l’équipe
Trois machines HP, toutes avec iLO, toutes désormais sous Windows Server 2025, toutes promues contrôleurs de domaine dans la même forêt :
- HP1 : contrôleur de domaine, émulateur PDC, DNS, DHCP
- HP2 : contrôleur de domaine, DNS, DHCP (partenaire de basculement de HP1)
- HP3 : contrôleur de domaine, DNS, plus trois SSD dans un pool Storage Spaces, et futur serveur de fichiers central de la maison
Le domaine s’appelle muench.home.arpa. home.arpa est la zone que la RFC 8375 réserve exactement à cet usage : les réseaux domestiques. Fini le faux .local qui se bat avec mDNS, et pas besoin d’enregistrer un domaine public juste pour baptiser un lab.
Trois DC pour un foyer, c’est objectivement excessif. C’est justement le but. Avec trois, je peux en arrêter un, le redémarrer ou le casser, et regarder les deux autres continuer comme si de rien n’était. Il s’est avéré que c’est exactement ce que j’ai pu observer (plus de détails plus bas).
Et oui, les vieilles habitudes ont suivi. Pas question de cliquer dans le Gestionnaire de serveur sur trois machines. Tout est piloté à distance via WinRM depuis ma machine de rebond Linux, avec pywinrm. Les vieilles habitudes ont la vie dure, mais au moins elles parlent maintenant PowerShell.
Premier piège du voyage : WinRM envoie le script en base64 sur la ligne de commande, et Windows limite une ligne de commande à 8191 caractères. Au-delà, rien n’échoue. Il ne se passe simplement rien, en silence. La parade : envoyer les scripts par petits morceaux, vérifier un SHA256 sur la cible, puis exécuter. Très Windows, très instructif.
Deuxième piège : j’ai activé le serveur OpenSSH comme solution de secours manuelle, et le port 22 tombait en timeout depuis l’extérieur alors que le service tournait et que la règle de pare-feu affichait « activée ». La règle créée automatiquement ne couvrait que le profil Privé. Un serveur membre du domaine fonctionne avec le profil Domaine. Un Set-NetFirewallRule -Profile Domain,Private plus tard, ça marchait.
🤖 Mon co-admin est une IA (et non, ce n’est pas du « vibe admin »)
En toute transparence sur ce pipeline WinRM : je ne suis pas le seul à l’utiliser. Quand je bloque, Claude (l’IA d’Anthropic, qui tourne sous forme de Claude Code sur la machine de rebond Linux) se connecte aux serveurs par exactement cette interface WinRM et m’aide pour la configuration. Il lit l’état actuel, propose des modifications, les explique, les applique une fois que j’ai dit oui, puis vérifie le résultat.
Voici comment cela fonctionne en pratique, car il n’y a aucune magie là-dedans : Claude tourne dans un terminal sur la machine Linux et peut y exécuter des commandes shell. Pour les commandes rapides en une ligne, il interroge directement les serveurs via pywinrm. Pour tout ce qui est plus gros, le déroulement ressemble à ceci :
1. write a PowerShell script locally (check_hp2.ps1, gpo_bitlocker.ps1, …)
2. open a WinRM session to the server (HTTP 5985, NTLM, message-encrypted)
3. upload the script in ~1200-char base64 chunks → C:\Temp\
4. compare SHA256 locally vs. on the server → abort if they differ
5. execute it, collect stdout + errors (unwrapping PowerShell's CLIXML error stream)
6. read the output, decide the next step → back to 1L’envoi en morceaux et la somme de contrôle sont là à cause de la limite de 8191 caractères du piège ci-dessus : un script tronqué en cours de route est pire qu’un script qui n’arrive pas du tout. Les scripts sont des fichiers .ps1 ordinaires, je peux donc lire chacun d’eux avant ou après son exécution. C’est d’ailleurs l’effet secondaire agréable : à la fin d’une session, il me reste une pile de PowerShell lisible qui montre exactement ce qui a été fait, et je peux en tirer des leçons.
Vous avez sans doute entendu parler du vibe coding. Andrej Karpathy a inventé le terme début 2025 pour désigner une manière de programmer où l’on décrit ce que l’on veut en langage courant, où l’on laisse l’IA écrire le code et où l’on accepte plus ou moins tout ce qui en sort sans le lire attentivement. Il s’agit de code, et la partie « vibe » désigne précisément l’absence de vérification.
Ce que je fais ici, c’est la version admin de la première moitié, mais délibérément pas de la seconde. Laisser une IA tirer des commandes non relues sur ses contrôleurs de domaine, ce serait du « vibe admin », et c’est un excellent moyen de faire connaissance de très près avec sa stratégie de sauvegarde. Les règles de base sont donc les suivantes :
- D’abord lire, ensuite modifier. Chaque tâche commence par un inventaire en lecture seule de ce qui est réellement configuré, et non de ce que nous croyons être configuré.
- Je décide, l’IA exécute. Les modifications ont lieu après mon accord, et tout ce qui est destructif fait l’objet d’une question explicite au préalable.
- Vérifier depuis l’autre côté. Une GPO n’est pas terminée quand
New-GPOrend la main. Elle l’est quand la valeur de registre apparaît sur la machine cible. Le basculement DHCP n’est pas réparé tant que les deux partenaires ne signalent pas le nouveau réglage. - Expliquer le pourquoi. Je veux apprendre Windows Server, pas l’externaliser. Je pose donc beaucoup de questions du genre « pourquoi est-ce comme ça ? », et certaines des meilleures parties de cet article sont nées de ces réponses.
Un exemple réel tiré de la session pendant laquelle j’ai écrit cet article : nous voulions activer la reprise automatique dans la relation de basculement DHCP. Sur HP1, l’applet de commande a répondu par un simple PermissionDenied, malgré des droits d’administrateur du domaine. Claude a reconnu le schéma : le classique double saut (double hop). J’étais connecté à HP1 à distance, l’applet doit modifier en même temps le réglage sur HP2, et HP1 n’a pas le droit de transmettre mes identifiants à une troisième machine. La solution : une tâche planifiée ponctuelle qui s’exécute localement sur HP1 avec une vraie ouverture de session, puis qui est supprimée. Ensuite, nous avons vérifié le réglage sur les deux partenaires. J’aurais passé une heure à chercher sur Google. À la place, j’ai eu droit à une leçon de dix minutes sur le fonctionnement de la délégation d’identifiants sous Windows.
Cela ne remplace pas la compréhension. L’IA est rapide et sait beaucoup de choses, mais elle se trompe aussi : pendant ce voyage, elle a écrasé une variable PowerShell parce qu’elle avait oublié que les noms de variables n’y sont pas sensibles à la casse. C’est plutôt comme du pair programming avec un collègue qui aurait lu tous les articles Microsoft Learn jamais écrits, qui ne se lasse jamais des questions, et dont on relit quand même le travail.
🌐 DNS : la partie sans laquelle AD ne peut pas vivre
Active Directory est, au fond, un consommateur de DNS aux opinions très arrêtées. Les clients trouvent leurs contrôleurs de domaine grâce aux enregistrements SRV (_ldap._tcp.dc._msdcs...) ; si le DNS est faux, tout est faux, et généralement de manière déroutante. Le vieux haïku des sysadmins s’applique : Ce n’est pas le DNS. / Impossible que ce soit le DNS. / C’était le DNS.
Les trois DC font tourner un DNS intégré à AD, les zones se répliquent donc avec l’annuaire lui-même au lieu de passer par des transferts de zone. Les trois sont aussi catalogues globaux, et le DHCP distribue les trois comme serveurs DNS, si bien que n’importe lequel peut disparaître sans que les clients s’en aperçoivent :
PS> Get-DhcpServerv4OptionValue -ScopeId $scope -OptionId 6
OptionId Name Type Value
-------- ---- ---- -----
6 DNS Servers IPv4Address {…, …, …}Trois entrées. L’ordre des résolveurs est de toute façon l’affaire du client, mais au moins chaque client connaît les trois portes.
📦 La FritzBox est rétrogradée
Jusqu’ici, ma FritzBox faisait ce que fait toute box grand public : DHCP et DNS pour toute la maison. Avec Active Directory, ça ne marche pas. Les membres du domaine doivent utiliser les contrôleurs de domaine comme serveurs DNS, car seuls les DC connaissent les enregistrements SRV qui indiquent à un client où vit son domaine. Distribuer la box comme DNS, c’est l’erreur de configuration AD classique : la jonction au domaine échoue, les GPO ne s’appliquent pas sans rien dire, et les ouvertures de session prennent cinq minutes sans raison apparente.
Le serveur DHCP de la FritzBox est donc désactivé, le DHCP tourne désormais comme rôle sur les serveurs Windows (voir plus bas), et il distribue les trois DC comme serveurs DNS, pas la FritzBox.
La FritzBox n’est pas au chômage pour autant. Elle reste la passerelle par défaut : tout le trafic Internet quitte toujours la maison par elle. Et les DC transfèrent chaque requête DNS dont ils ne sont pas responsables, c’est-à-dire tout ce qui est en dehors de muench.home.arpa, à la FritzBox, qui interroge le monde extérieur. Une division du travail nette : Windows connaît la maison, la FritzBox connaît Internet.
client ──DHCP────► HP1 / HP2 address, gateway = FritzBox, DNS = the 3 DCs
client ──DNS─────► any DC ──┬─ *.muench.home.arpa → answers itself
└─ everything else → forwards to FritzBox → internet
client ──traffic─► FritzBox (default gateway) ──────────────────────────► internetLa FritzBox est passée de « fait tourner la maison » à « garde la porte d’entrée ». Elle l’a étonnamment bien pris.
📡 Basculement DHCP : la surprise du fonctionnement par paires
Mon plan était simple : trois serveurs, trois nœuds DHCP, tous réunis dans un joyeux cluster de basculement.
Windows avait d’autres projets. Le basculement DHCP fonctionne strictement par paires. Une relation de basculement a exactement deux partenaires, et une étendue ne peut appartenir qu’à une seule relation. Pas de mode à trois, pas de quorum, pas de maillage. Le DHCP de Windows est strictement monogame. Le troisième rôle DHCP a donc été désinstallé, et HP1 et HP2 se partagent maintenant l’étendue en mode équilibrage de charge : ils divisent le pool d’adresses à 50/50 et synchronisent les baux entre eux.
PS> Get-DhcpServerv4Failover | Select Name, Mode, State
Name Mode State
---- ---- -----
hp1-…-hp2 LoadBalance NormalLe pool lui-même est volontairement ennuyeux : un /24, avec une plage dynamique de .70 à .245. Cela fait 176 adresses pour les portables, téléphones, téléviseurs et tout ce qui franchit la porte. Tout ce qui est en dessous de .70 est configuré en statique et reste hors du pool : la box, les serveurs, leurs interfaces iLO et le reste de l’infrastructure qui ne doit jamais bouger. Le haut de la plage reste libre en réserve.
PS> Get-DhcpServerv4Scope | Select ScopeId, StartRange, EndRange, LeaseDuration
ScopeId StartRange EndRange LeaseDuration
------- ---------- -------- -------------
192.168.10.0 192.168.10.70 192.168.10.245 8.00:00:00
Option 3 Router
Option 6 DNS Servers (all three DCs)
Option 15 DNS Domain Name muench.home.arpaQuelques détails bons à savoir :
- Baux de 8 jours. Dans un foyer où les mêmes appareils reviennent chaque jour, des baux longs signifient moins de bavardage. Ils signifient aussi qu’une panne DHCP passe inaperçue pendant des jours au lieu de quelques minutes.
- Équilibrage de charge 50/50. Les deux serveurs répondent, et chacun est responsable de la moitié des clients (déterminée par un hachage de l’adresse MAC). Si un partenaire disparaît, l’autre continue de servir tout le monde et renouvelle aussi les clients de son partenaire, par paliers limités par la MCLT. Après 60 minutes sans contact, il passe automatiquement en
PartnerDownet reprend l’intégralité du pool. (Ce passage automatique était désactivé par défaut, et je ne l’ai activé qu’en écrivant cet article.) - MCLT d’une heure. La Maximum Client Lead Time limite la durée dont un serveur peut prolonger un bail au-delà de ce que son partenaire en sait. C’est la marge de sécurité qui empêche deux serveurs de distribuer la même adresse après avoir perdu le contact.
- Mises à jour DNS dynamiques. Les clients s’enregistrent eux-mêmes dans les zones AD, chaque portable est donc joignable par son nom, et le DHCP supprime l’enregistrement à l’expiration du bail.
- Autorisation dans AD. Un serveur DHCP Windows ne distribue des baux qu’une fois autorisé dans Active Directory. Un serveur DHCP pirate branché par une personne bien intentionnée reste muet, tant qu’il s’agit d’un serveur Windows.
Au moment où j’écris ces lignes, le pool affiche un taux d’utilisation vertigineux de 3 %. Une planification de capacité digne d’une grande entreprise.
Autre petite leçon : je voulais garder une trace de tous les appareils configurés en statique sous la plage dynamique, sous forme de « réservations de documentation » directement dans la console DHCP. Raté. Add-DhcpServerv4Reservation n’accepte que des adresses à l’intérieur de la plage de l’étendue. Le DHCP n’est pas une CMDB, et il vous le fait savoir.
🔐 Secure Boot, ou regarder un DC attendre ses copains
Les trois machines ont été installées en UEFI/GPT avec un TPM 2.0 embarqué, mais Secure Boot était encore désactivé dans le firmware. Aujourd’hui, c’était donc la tournée des BIOS : un serveur à la fois, basculer l’option, redémarrer, vérifier.
« Un à la fois » est devenu une petite leçon à part entière. HP2 est revenu alors que HP1 était encore en plein redémarrage, et pendant environ sept minutes, HP2 répondait au ping, avait tous ses ports ouverts… et rejetait chaque connexion avec un HTTP 401. Il y a de la lumière, mais personne à la maison.
Rien n’était cassé. Un contrôleur de domaine fraîchement démarré veut terminer une synchronisation initiale avec ses partenaires de réplication avant d’assumer pleinement son rôle de DC. L’un de ces partenaires fixait encore un écran POST, alors HP2 a poliment attendu un timeout. Dès que HP1 est revenu, tout est repassé au vert : réplication sans erreur, basculement DHCP revenu de CommunicationInterrupted à Normal.
Leçon retenue : ne redémarrez pas vos contrôleurs de domaine en parallèle. Ce qui mène directement au sujet suivant.
🪦 WSUS : installé dans ma tête, déprécié dans la réalité
Pour tout admin Windows d’un certain âge, « gestion des correctifs » veut dire WSUS. C’était sur ma liste : l’installer sur HP2, synchroniser le catalogue, approuver les mises à jour, se sentir comme une vraie entreprise, et regarder SUSDB gonfler comme un levain que personne n’a demandé.
Puis j’ai lu les petites lignes. En 2024, Microsoft a officiellement placé WSUS sur la liste des fonctionnalités dépréciées. Il est toujours livré avec Server 2025 et continue de fonctionner, mais il ne recevra plus de nouvelles fonctionnalités, et tout l’effort de développement va au cloud : Windows Autopatch, Intune et Azure Update Manager. Apprendre un produit l’année où on l’inscrit sur la liste des départs à la retraite, c’était comme réviser pour un examen déjà annulé. (Et puis, faire tourner WSUS avec sa base de données et IIS sur un contrôleur de domaine n’est pas vraiment une bonne pratique.)
Les mises à jour viennent donc directement de Microsoft, et ce sont les stratégies de groupe qui décident quand. Ce qui nous amène à la vraie star de cet article.
📜 Stratégies de groupe : le YAML du monde Windows
Si Ansible, c’est « décrire l’état souhaité et laisser un outil l’imposer », les stratégies de groupe sont la même idée, intégrée au système d’exploitation depuis 2000. En plus, elles sont distribuées par les contrôleurs de domaine eux-mêmes et réappliquées toutes les 90 minutes, sans aucune exécution de playbook. Je l’avoue, je suis un peu impressionné. Surtout, ne le dites pas à mes rôles Ansible.
Voici ce qui est actif dans le domaine à présent, le tout créé en PowerShell (New-GPO, Set-GPRegistryValue, New-GPLink) puis vérifié en relisant les vraies valeurs de registre sur les machines cibles :
1. Lecteurs réseau mappés. HP3 a un dossier et un partage SMB par utilisateur (\\HP3\user1, \\HP3\user2, …). Chaque utilisateur possède son propre dossier avec le contrôle total, aussi bien dans les autorisations NTFS que dans celles du partage, plus l’énumération basée sur l’accès, si bien que l’on ne voit même pas les dossiers que l’on ne peut pas ouvrir. Les comptes utilisateurs vivent dans leur propre OU, et une seule GPO mappe les lettres de lecteur. Les préférences de stratégie de groupe avec ciblage au niveau de l’élément décident qui reçoit quoi : user1 (c’est moi, l’admin de la maison) reçoit tous les lecteurs, et user2 uniquement le sien. Les chemins utilisent le nom du serveur au lieu de l’IP, pour que l’authentification passe par Kerberos au lieu de se rabattre sur NTLM.
2. Windows Update pour les clients. Mon ordinateur de bureau et mon portable tournent rarement la nuit, donc « installer à 3 h du matin » ne sert à rien chez eux. À la place :
- mises à jour de qualité différées de 3 jours, pour que le reste d’Internet trouve les mauvais correctifs en premier
- version de fonctionnalité figée, donc pas de mise à niveau surprise vers la prochaine version de Windows 11
- échéances de 3 jours (qualité) et 7 jours (fonctionnalité), plus 2 jours de grâce, après quoi le redémarrage a lieu, que cela me plaise ou non. Windows Update a toujours été un produit « que cela vous plaise ou non » ; maintenant, au moins, c’est moi qui choisis la date
- heures d’activité de 07:00 à 23:00
- « Mettre à jour et arrêter » dans le menu d’alimentation, pour que l’arrêt du soir fasse le travail
- Optimisation de la distribution limitée au LAN, pour que les mises à jour ne soient téléchargées qu’une fois pour toute la maison
3. Windows Update pour les serveurs : en décalé. Une GPO de base sur l’OU Domain Controllers (téléchargement automatique, installation planifiée), plus une petite GPO de planification par serveur avec filtrage de sécurité, pour que chacune s’applique à exactement une machine :
HP3 Saturday 03:00 ← the canary
HP1 Sunday 03:00
HP2 Sunday 05:00HP3 est le canari dans la mine des correctifs : il reçoit les mises à jour un jour avant les autres. Si une mise à jour cumulative casse quelque chose, je le découvre le samedi et j’ai encore un jour pour arrêter le reste. Et HP1 et HP2 ne redémarrent jamais en même temps. La section précédente explique pourquoi c’est important.
Petit piège annexe dans le filtrage de sécurité : quand on retire « Utilisateurs authentifiés » du filtre, le groupe a quand même besoin du droit Lecture sur la GPO, sinon plus personne ne peut la lire (MS16-072 vous passe le bonjour). L’ordinateur lui-même reçoit Appliquer, et Utilisateurs authentifiés garde Lecture.
4. Mode sombre, et adieu Spotlight. Purement cosmétique, et tout à fait à mon goût : chaque utilisateur de la maison reçoit le mode sombre pour Windows et les applications, plus un bureau tout noir. Pas de Windows Spotlight, et pas de photos tournantes du genre « saviez-vous que cette montagne se trouve en Norvège ? » avec un point cliquable qui vous invite à en savoir plus. Spotlight, c’est en gros un économiseur d’écran doté d’un service marketing.
Le hic, ici, c’était l’édition. La stratégie officielle « Turn off all Windows spotlight features » ne fonctionne que sous Windows Enterprise et Education. Mes clients tournent sous Windows 11 Pro, où la stratégie est tout simplement ignorée. La parade, ce sont les préférences de stratégie de groupe : au lieu d’une stratégie officielle, la GPO écrit les valeurs de registre que l’application Paramètres définirait elle-même :
HKCU\…\Themes\Personalize AppsUseLightTheme = 0 # dark apps
HKCU\…\Themes\Personalize SystemUsesLightTheme = 0 # dark taskbar/start
HKCU\…\Explorer\Wallpapers BackgroundType = 1 # solid color, kills Spotlight
HKCU\Control Panel\Colors Background = "0 0 0" # black
HKCU\Control Panel\Desktop Wallpaper = ""L’action est réglée sur Mettre à jour : un utilisateur peut donc changer le fond d’écran, mais la prochaine actualisation des stratégies le remet en noir. Par-dessus, la GPO définit la stratégie officielle « Turn off Spotlight collection on Desktop », ceinture et bretelles pour le jour où une machine passera en Enterprise. Les changements prennent effet à la prochaine ouverture de session.
5. BitLocker. Celui-là mérite sa propre section.
🔒 BitLocker : contre quoi protège-t-il vraiment ?
Avant d’activer quoi que ce soit, je voulais un modèle de menace clair, parce que « chiffrement = sécurité », c’est trop simple.
BitLocker protège les données au repos. Son rôle, c’est le portable volé, le disque retiré d’un serveur ou le SSD qui repart sous garantie. Ce qu’il ne fait pas : protéger un système en marche et déverrouillé. Un malware, un compte compromis ou un mot de passe faible voient tout en clair, exactement comme avant.
Vient ensuite la question de savoir comment la clé est déverrouillée :
- TPM seul : le TPM libère la clé si la chaîne de démarrage est inchangée. C’est pratique et cela protège le disque retiré. Mais la machine démarre toute seule jusqu’à l’écran de connexion, donc si la machine entière est volée, le seul obstacle du voleur est l’ouverture de session Windows.
- TPM + PIN : en plus, un code PIN avant même le démarrage de Windows. L’appareil volé n’est plus qu’une brique avec un disque chiffré, ou un cale-porte très coûteux équipé d’un ventilateur. Moins pratique, mais pour un portable qui voyage avec moi, c’est le bon choix.
Le plus drôle : j’avais déjà activé BitLocker sur mon portable la veille, en TPM seul et sans PIN. Bonne nouvelle : le PIN peut être ajouté après coup. Ce n’est qu’un protecteur de clé supplémentaire, et rien n’est rechiffré :
manage-bde -protectors -add C: -TPMAndPINLe hic : Windows n’autorise un PIN de prédémarrage que si une stratégie le permet. Alors, surprise, encore une GPO. Il y a désormais deux stratégies BitLocker dans le domaine :
- Tous les clients : BitLocker est activé automatiquement sur le lecteur système, et la clé de récupération est sauvegardée dans Active Directory. Fini les clés dans un fichier texte sur un partage quelconque, ou sur un post-it sous le clavier. Nous l’avons tous vu. Certains d’entre nous l’ont écrit.
- Le portable : TPM + PIN est obligatoire au démarrage, via sa propre GPO avec filtrage de sécurité sur exactement cette machine.
Une fois les GPO en place, les étapes suivantes sont gpupdate /force, l’ajout du protecteur PIN, puis la vérification que la clé de récupération apparaît vraiment dans l’objet ordinateur dans AD. Une sauvegarde jamais vérifiée est un espoir, pas une sauvegarde.
Les serveurs viendront ensuite, en commençant par HP3. En tant que futur serveur de fichiers central, il aura aussi son volume Storage Spaces chiffré, et les clés iront dans AD. Pour un serveur qui doit redémarrer sans surveillance, le TPM seul est le choix pragmatique, car personne n’a envie de taper un PIN dans l’iLO à 3 h du matin après un redémarrage de correctifs.
💾 Storage Spaces : le RAID 5 à la sauce Microsoft
HP3 a reçu trois SSD SATA de 2 To pour les données (le système vit sur un SSD séparé). Sous Linux, j’aurais pris mdadm ou OpenZFS RAIDZ1. Sous Windows, l’équivalent, c’est Storage Spaces : un pool constitué des disques physiques, un disque virtuel avec une résilience par parité par-dessus (parité simple avec trois disques, donc du RAID 5 dans l’esprit), formaté en ReFS :
PS> New-StoragePool -FriendlyName BackupPool -PhysicalDisks $disks ...
PS> New-VirtualDisk -StoragePoolFriendlyName BackupPool -ResiliencySettingName Parity ...
PS> Format-Volume -FileSystem ReFS ...
D:\ ReFS ~3.6 TB usableEnsuite, bien sûr, place au benchmark, avec DiskSpd, le générateur de charge de stockage maison de Microsoft et en gros sa réponse à fio. Une fois de plus par la voie IA-via-WinRM. La méthode :
- Récupérer l’outil : rien n’est installé. Le serveur télécharge lui-même le
DiskSpd.zipofficiel depuis les releases GitHub de Microsoft dansC:\Temp, le décompresse et utilise le binaireamd64. C’est un unique.exeportable. - Fichier de test : un fichier de 20 Go directement sur le volume à parité
D:. - Quatre profils classiques : séquentiel avec des blocs de 1 Mo (un thread, profondeur de file 8) et aléatoire avec des blocs de 4 Ko (quatre threads, profondeur de file 32 chacun), chacun une fois en lecture et une fois en écriture.
- Conditions équitables : 5 secondes de préchauffage, 30 secondes de mesure,
-Shpour contourner à la fois le cache de fichiers Windows et le cache d’écriture des disques (sinon, c’est la RAM que l’on mesure),-Lpour les percentiles de latence. - Nettoyage : ensuite, l’outil et le fichier de test sont supprimés, et il ne reste sur le serveur qu’un volume libre.
# sequential write, 1 MB blocks
diskspd.exe -b1M -d30 -W5 -o8 -t1 -si -w100 -Sh -L D:\disktest.dat
# random read, 4 KB blocks, 4 threads x QD32
diskspd.exe -b4K -d30 -W5 -o32 -t4 -r -w0 -Sh -L D:\disktest.datUn petit script d’aide côté Linux lance chaque profil via WinRM et n’extrait que la ligne total: et le 99e percentile du rapport très bavard de DiskSpd. Et bien sûr, le premier benchmark m’a menti, exactement comme dd sur la machine ZFS :
Sequential read (1 MB) 20997 MiB/s ← three SATA SSDs. Sure.
Random read (4 KB) 739327 IOPSVingt gigaoctets par seconde avec trois disques SATA dont la limite d’interface combinée tourne autour de 1,6 Go/s. Le coupable : l’option -c de DiskSpd recrée le fichier de test à chaque exécution, et ReFS sait que les plages jamais écrites ne contiennent que des zéros. Il répond donc à ces lectures à partir des métadonnées, sans jamais toucher un disque. Un benchmark ultrarapide de rien du tout. Le SSD de Schrödinger : d’une rapidité fulgurante, tant que personne ne regarde les données.
On remplit le fichier une fois avec de vraies données, puis on mesure sans -c, et la réalité apparaît :
Profile Throughput IOPS avg latency 99th pct
Sequential read (1 MB) 1169 MiB/s 1169 6.8 ms 24 ms
Random read (4 KB, 4x32) 633 MiB/s 162,109 0.55 ms 7.3 ms
Sequential write (1 MB) 88 MiB/s* 88 90.6 ms 427 ms
Random write (4 KB, 4x32) 1.8 MiB/s 461 276 ms 1095 ms
* up to 163 MiB/s in a separate 60-second runLes lectures sont excellentes. Les écritures sont… de la parité. Chaque petite écriture se transforme en lecture-modification-écriture des données et de la parité, et sans niveau de cache en écriture différée sur SSD/NVMe, la parité de Storage Spaces est notoirement lente à ce jeu. La colonne de latence raconte la même histoire : une petite écriture sur cent attend plus d’une seconde. De quoi remettre en question ses choix de vie. Pour un serveur de fichiers et une cible de sauvegarde, où les données sont écrites une fois et lues souvent, ça va. Pour tout ce qui fait beaucoup de petites écritures aléatoires, c’est rédhibitoire.
Mise à jour (6 octobre 2026) : la parité n’était que la moitié de l’histoire. Le firmware HPE avait désactivé au démarrage le cache d’écriture des trois SSD, et le -Sh de DiskSpd a mesuré exactement cet état, qui se trouvait être celui dans lequel le serveur tournait au quotidien. Avec le cache activé, une restauration sur les mêmes disques (désormais sous Linux) a été environ trois fois plus rapide. L’histoire complète (en anglais) : Two Things My SSDs Were Missing: TRIM After BitLocker, and a Write Cache My HPE Server Quietly Switched Off.
(Par souci d’équité : la mesure a coïncidé avec une grosse copie sur le même volume, une nouvelle mesure propre est donc encore sur ma liste. Mais la tendance est claire.)
🧪 Prochaine étape : un hyperviseur et mes propres certificats
« Tout ce qui fait beaucoup de petites écritures aléatoires », c’est bien sûr une façon polie de décrire les machines virtuelles. Et c’est justement la prochaine chose avec laquelle je veux jouer : Hyper-V. Windows Server 2025 l’embarque de toute façon, et je veux voir ce qu’il vaut comparé à l’univers Proxmox que je connais : migration à chaud entre hôtes, points de contrôle, commutateurs virtuels et virtualisation imbriquée pour un lab de test à l’intérieur du lab.
Le benchmark ci-dessus a déjà répondu à une question de conception avant même que je commence. Les disques des VM n’iront pas sur le pool à parité. Avec ~460 IOPS en écriture aléatoire, une VM Windows passerait sa vie à fixer un cercle qui tourne. Le cercle de chargement comme art de vivre. Une vraie installation d’hyperviseur demande donc une autre organisation du stockage : miroir au lieu de parité, ou NVMe local. De quoi alimenter le prochain article.
Deuxième point sur la liste : émettre mes propres certificats. Windows Server embarque sa propre PKI, les services de certificats Active Directory (AD CS). Côté Linux, cert-manager et Let’s Encrypt s’occupent de tout ce qui est exposé à Internet. En interne, en revanche, il y a tout un zoo que personne ne signera jamais publiquement : interfaces web iLO, RDP, LDAPS sur les contrôleurs de domaine et pages d’administration d’appareils divers. Chacun m’accueille actuellement avec un avertissement de certificat que j’ai appris à fermer d’un clic. C’est exactement le réflexe qu’on ne veut pas avoir.
Le plan : une petite autorité de certification interne, dont le certificat racine est déployé sur chaque membre du domaine via (bien sûr) une stratégie de groupe. Avec les modèles de certificats et l’inscription automatique, les machines demandent et renouvellent elles-mêmes leurs certificats, comme cert-manager, version Microsoft. La conception de manuel, c’est une AC racine hors ligne avec une AC émettrice en dessous. Reste à voir si un homelab a vraiment besoin de deux niveaux, ou si c’est le moment où l’apprentissage vire au cosplay.
🎯 Ce que j’en retiens
Il y a une semaine, je vous aurais dit que l’administration Windows consistait à cliquer dans des assistants. En réalité, avec PowerShell et WinRM, elle se scripte étonnamment bien, et les stratégies de groupe sont en gros de la gestion de configuration autour de laquelle on a construit un système d’exploitation.
Les leçons du parcours étaient les mêmes que sous Linux : lire les petites lignes (le basculement DHCP fonctionne par paires, WSUS est déprécié), ne pas croire le premier benchmark (ReFS et ses zéros) et ne pas tout redémarrer en même temps (les contrôleurs de domaine sont des créatures sociables).
Deux voies, donc. Linux continue de faire tourner la production, et Windows Server a le droit d’être le terrain de jeu où j’apprends. Et franchement ? Après une semaine de YAML, Get-ADReplicationPartnerMetadata avait un goût de vacances. 🏖️
P.-S. : Maintenant, si vous voulez bien m’excuser, je dois aller expliquer à la famille pourquoi leur fond d’écran est soudain devenu noir. « C’est une stratégie de groupe » n’a encore jamais fonctionné comme explication à la maison.
