Installer Windows Server comme un pro : rôles, mises à jour et durcissement en 60 minutes

Règles de base pour une installation pro en 60 minutes

Une build « pro » n’est pas un ensemble magique de modifications du registre. C’est une séquence qui vous évite de commettre des erreurs irréversibles
(mauvaise disposition des disques, édition incorrecte, identité erronée, mauvais placement des rôles) et qui vous laisse un serveur que vous pouvez comprendre.

Règle 1 : Décidez à quoi cette machine sert, et à quoi elle ne sert pas

Un serveur, un travail—du moins au début. Contrôleur de domaine + serveur de fichiers + SQL + « ah et aussi imprimeur » est la façon dont on
transforme la maintenance en négociation sous contrainte. Choisissez la charge principale et construisez autour.

Règle 2 : Traitez les paramètres par défaut comme « temporaires », pas « bons »

Les valeurs par défaut sont optimisées pour « démarrer correctement pour tout le monde », pas pour « survivre dans votre environnement ». Votre posture de sécurité, cadence de mise à jour,
et profil de stockage sont votre responsabilité. Microsoft vous donne une ligne de départ, pas une ligne d’arrivée.

Règle 3 : Si vous ne pouvez pas le reconstruire, vous n’en êtes pas propriétaire

Prenez des notes au fur et à mesure. Encore mieux : scriptz-le. Mais même une checklist serrée vaut mieux que « je me souviens avoir cliqué quelque chose ». Le jour où il faudra reconstruire
vite, votre mémoire deviendra du folklore.

Idée paraphrasée attribuée à Werner Vogels : « Tout échoue ; concevez pour que le système continue et récupère rapidement. »
Cet état d’esprit s’applique aux serveurs Windows autant qu’à des flottes de microservices.

Faits et contexte intéressants (ce qui explique les choix par défaut actuels)

• Server Core n’est pas nouveau. Microsoft l’a introduit à l’époque de Windows Server 2008 pour réduire la surface d’attaque et le nombre de correctifs ; c’est toujours l’option « l’ennuyeux gagne ».
• Le journal NTFS est ancien, et c’est une qualité. NTFS est le format par défaut depuis les années 1990 ; il est éprouvé, mais Windows pousse aussi ReFS pour certains scénarios.
• Le chiffrement et la signature SMB sont devenus courants pour une raison. Le mouvement latéral et le vol d’identifiants ont fait des partages de fichiers « rapides mais confiants » une responsabilité.
• PowerShell est devenu l’interface d’administration réelle depuis des années. Depuis Windows Server 2012, l’administration « GUI d’abord » est silencieusement devenue « fondée sur PowerShell ».
• Windows Defender n’est plus un jouet. L’antivirus intégré a mûri en une base de sécurité endpoint sérieuse ; l’ignorer est généralement pire que l’activer.
• L’évolution de Hyper-V a changé le placement des rôles. Une fois la virtualisation devenue standard, le vieux modèle « une application par serveur physique » est mort—mais « un travail par VM » reste sensé.
• Les biais de conception d’Active Directory influencent encore les installations. Synchronisation temporelle, DNS, et hypothèses d’identité rendent l’ordre de configuration initial plus important sur Windows que beaucoup ne l’imaginent.
• Patch Tuesday est une politique, pas une suggestion. La cadence est institutionnelle. Si votre stratégie de mise à jour n’en tient pas compte, vous dériverez jusqu’à revenir brutalement lors d’un incident.

Plan des 60 minutes (quoi faire, dans quel ordre)

L’objectif n’est pas de tout faire en 60 minutes. L’objectif est d’effectuer le travail irréversible et à fort effet en premier,
puis de laisser le système dans un état sécurisé, patchable et maintenable. C’est le chemin qui évite des ennuis au futur vous.

Minute 0–10 : Installer avec des choix d’édition et de disque sensés

• Choisir la bonne édition et le mode de déploiement (Server Core sauf raison valable).
• Confirmer UEFI vs BIOS, Secure Boot et TPM si vous prévoyez BitLocker.
• Partitionner sensément : séparer l’OS des données et des logs quand c’est possible.

Minute 10–25 : Identité et bases d’accès

• Définir le nom d’hôte, l’adressage IP, le DNS et la passerelle.
• Corriger la synchronisation temporelle et le fuseau horaire (Kerberos vous punira plus tard si vous ne le faites pas).
• Faire fonctionner l’administration à distance (WinRM/PowerShell Remoting), puis durcir le RDP.

Minute 25–40 : Patch et redémarrage comme un adulte

• Appliquer les dernières mises à jour cumulatives avant d’ajouter des rôles.
• Confirmer que la source de mise à jour (WSUS, Windows Update for Business, ou Microsoft Update direct) correspond à la politique.
• Redémarrer jusqu’à « pas de mises à jour restantes ». Un seul redémarrage est un espoir, pas un processus.

Minute 40–55 : Installer les rôles et fonctionnalités (minimum)

• Ajouter uniquement les rôles nécessaires aujourd’hui.
• Confirmer que les services, ports d’écoute et règles de pare-feu correspondent à l’intention.
• Valider les journaux d’événements pour les avertissements d’installation de rôle maintenant, pas trois mois plus tard.

Minute 55–60 : Appliquer le durcissement de base et prendre un instantané (ou une sauvegarde)

• Activer Defender, appliquer le pare-feu, désactiver les éléments inutiles.
• Activer BitLocker si supporté et planifié opérationnellement.
• Créer un point de contrôle/instantané « état doré » si virtualisé, ou au moins une sauvegarde et une exportation de configuration.

Blague n°1 : Si vous sautez le patching parce que « c’est tout neuf », félicitations—votre serveur est maintenant une pièce de musée avec malware interactif.

Choix d’installation qui comptent (et ceux qui n’en valent pas la peine)

Server Core vs Expérience Bureau

Si vous construisez des rôles d’infrastructure (AD DS, DNS, DHCP, hôte Hyper-V, serveur de fichiers) et que vous n’avez pas une dépendance stricte à une GUI locale,
choisissez Server Core. Moins de binaires signifie moins de correctifs, moins de chemins d’attaque, et moins de « viande mystérieuse » installée pour supporter
des fonctionnalités UI que vous n’utilisez pas.

Utilisez l’Expérience Bureau quand une application fournisseur exige des outils UI locaux ou des anciens snap-ins MMC qui se comportent mal à distance.
Mais considérez-le comme un coût : plus de patching, plus de services, plus d’éléments à durcir.

UEFI, Secure Boot et TPM : décider tôt

UEFI + Secure Boot + TPM vous donnent un récit de confiance matérielle qui tient en audit et en réponse à incident. Si vous voulez BitLocker
sur le volume OS sans gestion manuelle de clés étrange, vous voulez un TPM.

Ne prévoyez pas d’ajouter le TPM plus tard. Les décisions matérielles et de TPM ont des répercussions sur le chiffrement, les processus de récupération et la posture de conformité.

Disposition des disques : séparer les domaines de défaillance

Le volume OS doit être ennuyeux. Gardez-le plus petit, plus facile à imageer, plus facile à sauvegarder, et moins susceptible d’être rempli par des logs d’application
qu’on oublie de faire tourner.

Une disposition pragmatique dans beaucoup d’équipes :

• C: OS uniquement (plus outils minimaux).
• D: Binaries d’apps / services (optionnel).
• E: Données.
• F: Logs et temp (surtout pour IIS, staging de sauvegarde, jobs ETL).

Les lettres exactes n’ont pas d’importance. La séparation, oui.

Choix du système de fichiers : NTFS vs ReFS

NTFS reste le choix sûr par défaut pour une compatibilité large. ReFS a des avantages d’intégrité et pour certains scénarios de stockage à grande échelle, mais ce n’est
pas un remplacement universel pour toutes les charges (certaines apps et outils de sauvegarde ont encore des préférences).

Si vous ne savez pas pourquoi vous auriez besoin de ReFS, vous n’en avez probablement pas besoin. Si vous le savez, vous avez déjà un plan de test.

Post-installation : identité, réseau, temps et accès à distance

Nommez-le comme si vous deviez le rechercher à 3 h du matin

Les noms d’hôtes doivent encoder l’environnement et le rôle de manière que les humains comprennent rapidement. Gardez-les suffisamment courts pour les outils et les certificats.
Évitez les jeux de mots. Les noms « intelligents » vieillissent mal.

Réseau : statique là où ça compte, documenté là où ça ne compte pas

Les contrôleurs de domaine, serveurs DNS, hôtes Hyper-V, nœuds de stockage et tout ce qui est une dépendance doivent avoir une adresse statique. Les serveurs applicatifs
peuvent souvent être en DHCP avec réservations, selon votre environnement. Quoi qu’il en soit, faites en sorte que le DNS soit correct et cohérent.

Synchronisation temporelle : la dépendance invisible qui casse l’authentification

Kerberos est extrêmement poli jusqu’à ce que vos horloges dérivent, puis il devient extrêmement strict. Réglez le fuseau horaire, confirmez la source NTP, et vérifiez l’écart.
Faites-le avant de joindre un domaine ou de promouvoir un DC, pas après.

Administration à distance : WinRM d’abord, RDP ensuite

Si vous pouvez gérer le serveur via PowerShell Remoting et MMC/RSAT depuis une station d’administration, vous avez beaucoup moins besoin du RDP. Gardez RDP disponible
pour le break-glass, mais réduisez son exposition. Ne traitez pas RDP comme votre plan de contrôle principal.

Rôles et fonctionnalités : n’installez que ce que vous pouvez défendre

Les rôles ne sont pas des « fonctionnalités », ce sont des contrats

Installer un rôle revient à s’engager à le patcher, le surveiller et comprendre ses modes de défaillance. La façon la plus rapide de ruiner un nouveau serveur est d’
« installer un peu de tout » pour décider plus tard.

Schémas de rôles communs qui vous feront moins regretter la vie

• Contrôleur de domaine (AD DS + DNS) : gardez-le propre. Pas d’apps supplémentaires. Pas de partages de fichiers. Pas de SQL.
• Serveur de fichiers : isolez-le des DC, imposez la signature/chiffrement SMB lorsque c’est approprié, et planifiez quotas/FSRM tôt.
• Hôte Hyper-V : traitez l’hôte comme du firmware. Rôles minimaux, connexions minimales, patching prévisible.
• IIS : verrouillez les modules, limitez les privilèges des pools d’applications, et maintenez TLS/chiffrements conformes à la politique.

Installer les rôles avec PowerShell pour être explicite

Les installations GUI cachent des détails. PowerShell affiche ce qu’il a modifié. C’est mieux pour les notes de ticket, les revues de changement et les reconstructions futures.

Mises à jour : patcher sérieusement

Choisissez un modèle de mise à jour et tenez-vous-y

En environnement d’entreprise vous aboutirez généralement dans l’un de ces modèles :

• WSUS (approbation centrale et contrôle on-prem) : bon quand vous avez besoin d’une gouvernance stricte.
• Windows Update for Business (contrôle cloud piloté par des politiques) : bon pour l’échelle et la cohérence.
• Microsoft Update direct : acceptable pour des serveurs isolés, labos, ou petites déploiements avec discipline de processus forte.

Ce qu’il ne faut pas faire : mélanger les modèles à la légère. C’est comme ça qu’on obtient « des serveurs patchés, d’autres non, personne ne sait pourquoi ».

Patch avant les rôles (généralement)

Un serveur fraîchement installé est en retard sur les mises à jour cumulatives. Patcher tôt réduit les risques de quirks lors de l’installation de rôles et les fenêtres d’exposition.
Oui, il y a des exceptions (certains rôles exigent un redémarrage en cours d’installation), mais la règle générale tient.

Les cycles de redémarrage font partie du patching, pas d’une gêne

Votre travail n’est pas « installer des mises à jour ». Votre travail est « arriver à un état propre sans redémarrages en attente et sans échecs de mise à jour ».
Les états de redémarrage en attente provoquent des bizarreries : services qui ne se lancent pas, pilotes à moitié appliqués, changements de politique inactifs.

Durcissement : réduire le rayon d’impact sans vous saborder

Principes de base

• Principe du moindre privilège : exécutez les services avec le minimum de droits. Évitez LocalSystem sauf si vous aimez vivre dangereusement.
• Réduire les services à l’écoute : chaque port ouvert est une promesse à défendre.
• Chiffrez où il le faut : données au repos (BitLocker) et en transit (TLS, chiffrement/signature SMB selon besoin).
• Rendre la journalisation complète et banale : journaux de sécurité, journalisation PowerShell, et transfert d’événements si vous l’avez.

Posture pare-feu : le mode « refuser par défaut » est un style de vie

Le Pare-feu Windows n’est pas une décoration optionnelle. Activez-le pour tous les profils. Créez des règles d’entrée explicites pour ce dont vous avez besoin. Puis vérifiez
ce qui écoute réellement. Si vous vous fiez à « c’est sur un VLAN interne », vous construisez pour 2009, pas pour aujourd’hui.

Durcissement du RDP : conservez-le, mais rendez-le plus difficile à abuser

Exigez l’authentification au niveau du réseau (NLA). Restreignez qui peut se connecter via RDP. Envisagez l’accès just-in-time via des outils d’accès privilégié si vous en disposez.
Au minimum, n’exposez pas RDP largement et n’autorisez pas accidentellement des groupes d’administrateurs aléatoires.

Configuration de Defender : le défaut est décent, le défaut ajusté est meilleur

Dans de nombreux environnements, activer la protection en temps réel de Defender et la protection cloud est une amélioration immédiate par rapport à « rien » ou un agent tiers périmé.
Si un fournisseur exige des exclusions, négociez : chemins étroits, processus restreints, et documentez pourquoi.

Désactivez ce que vous n’utilisez pas

Chaque fonctionnalité inutile augmente la surface de correctif et les surprises. Exemples : SMBv1 (ne pas activer), protocoles TLS legacy (ne pas activer), composants de serveur web aléatoires sur des serveurs non-web (pourquoi?), et comptes locaux avec mots de passe longue durée (arrêtez cela).

Stockage et systèmes de fichiers (réalités SRE)

Les problèmes de performance sont souvent des problèmes de stockage déguisés en CPU

Windows vous laissera construire un serveur sur un stockage thin-provisioned avec la mise en cache d’écriture désactivée, mettre les logs sur le disque OS, puis
« fonctionner lentement » sous charge. L’OS n’est pas mystérieux. Il est littéral.

Décidez quel type de stockage vous avez

• NVMe/SAS SSD local : le plus rapide, le plus simple. Idéal pour hôtes Hyper-V et charges standalone.
• SAN (FC/iSCSI) : partagé et gérable, mais la latence et la configuration multipath comptent.
• Stockage SMB / NAS : excellent pour les partages de fichiers et certains scénarios Hyper-V, mais nécessite un réglage SMB et une conception réseau soignés.

Alignement de partition et taille de bloc : oui, ça compte encore

Windows moderne fait généralement ce qu’il faut, mais vous devriez quand même vérifier. Les mauvaises hypothèses ici créent des douleurs à long terme :
fenêtres de sauvegarde prolongées, pics de latence SQL, et votre supervision vous dit « tout va bien » pendant que les utilisateurs se plaignent.

Planifiez l’emplacement et la croissance des logs

« On mettra simplement les logs sur C: pour l’instant » est une phrase classique pré-incident. Mettez les logs quelque part avec de l’espace et de la surveillance. Si une app remplit
son volume de logs, elle doit échouer d’une manière visible, pas corrompre l’OS.

Tâches pratiques avec commandes, sorties et décisions (12+)

Ce sont les vérifications de base que j’exécute sur un nouveau serveur. Chaque tâche inclut une commande, ce que la sortie signifie, et la décision à prendre.
Exécutez-les dans une session PowerShell élevée.

Tâche 1 : Confirmer l’édition et le type d’installation de l’OS

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName,WindowsEditionId,OsHardwareAbstractionLayer"
WindowsProductName                WindowsEditionId OsHardwareAbstractionLayer
-----------------                ----------------- --------------------------
Windows Server 2025 Datacenter    ServerDatacenter 10.0.26100.1

Signification : Confirme que vous n’avez pas accidentellement installé Standard alors que vous aviez besoin des fonctionnalités Datacenter, ou installé l’Expérience Bureau alors que vous vouliez Core.

Décision : Si l’édition/le mode d’installation est incorrect, arrêtez maintenant et réinstallez. « Corriger plus tard » est généralement une reconstruction complète de toute façon.

Tâche 2 : Vérifier l’état de redémarrage en attente (le fauteur silencieux)

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'"
True

Signification : True indique que Windows considère qu’un redémarrage est en attente à cause du servicing.

Décision : Redémarrez et revérifiez avant d’installer des rôles ou de dépanner des « problèmes aléatoires ».

Tâche 3 : Valider le nom d’hôte et l’appartenance au domaine

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Name,Domain,PartOfDomain"
Name     Domain        PartOfDomain
----     ------        ------------
FS01     corp.example  True

Signification : Confirme que vous avez rejoint le domaine prévu et que vous n’êtes pas dans WORKGROUP sur un serveur « production ».

Décision : Si l’appartenance au domaine est incorrecte, corrigez-la avant d’installer des rôles dépendant d’AD (et avant d’émettre des certificats).

Tâche 4 : Vérifier la configuration NIC (IP, DNS, et si DHCP se glisse)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Select-Object InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias IPv4Address    IPv4DefaultGateway DnsServer
-------------- -----------    ------------------ ---------
Ethernet0      10.20.5.21     10.20.5.1         {10.20.1.10, 10.20.1.11}

Signification : Confirme que le serveur a la bonne adresse et pointe le DNS vers vos résolveurs (pas le routeur, pas 8.8.8.8, pas lui-même sauf s’il est DNS).

Décision : Si le DNS est incorrect, corrigez-le maintenant. Les bugs de résolution de noms font perdre des jours et font accuser AD à tort.

Tâche 5 : Confirmer la synchronisation temporelle et l’écart

cr0x@server:~$ powershell -NoProfile -Command "w32tm /query /status"
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 8:41:22 AM
Source: time.corp.example
Poll Interval: 6 (64s)

Signification : Montre votre source temporelle et si la dernière synchronisation a réussi.

Décision : Si la source est « Local CMOS Clock » sur un serveur joint au domaine qui n’est pas l’émulateur PDC, corrigez le NTP. Les problèmes d’authentification adorent la dérive d’horloge.

Tâche 6 : Confirmer que le Pare-feu Windows est activé pour tous les profils

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Signification : Vous bloquez les entrées par défaut, ce qui force des règles explicites.

Décision : Si un profil est désactivé, activez-le et créez les règles d’autorisation nécessaires. Ne comptez pas sur des mythes périmés.

Tâche 7 : Voir ce qui écoute réellement sur le réseau

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess | Sort-Object LocalPort | Select-Object -First 10"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      135       968
0.0.0.0      445       4
0.0.0.0      3389      1440
::          445       4
::          3389      1440

Signification : Les ports ouverts sont une surface d’attaque réelle. Cela vous dit ce qui est exposé.

Décision : Si vous voyez des écouteurs inattendus (anciens agents, services fournisseur, serveurs web), identifiez-les et supprimez/désactivez ou pare-feulez-les.

Tâche 8 : Cartographier les ports à l’écoute vers les services/processus

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id 1440 | Select-Object Id,ProcessName,Path"
Id   ProcessName Path
--   ----------- ----
1440 TermService C:\Windows\System32\svchost.exe

Signification : Confirme ce qui possède le port (ici, RDP via Terminal Services).

Décision : Si un processus est inattendu ou s’exécute depuis un chemin étrange, traitez-le comme suspect jusqu’à preuve du contraire.

Tâche 9 : Vérifier la santé de Defender et la protection en temps réel

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMServiceEnabled,AntispywareEnabled,AntivirusEnabled,RealTimeProtectionEnabled,IoavProtectionEnabled"
AMServiceEnabled AntispywareEnabled AntivirusEnabled RealTimeProtectionEnabled IoavProtectionEnabled
---------------- ------------------ --------------- ------------------------- --------------------
True             True               True            True                      True

Signification : Confirme que Defender n’est pas désactivé par accident ou par une ancienne GPO.

Décision : Si désactivé, trouvez pourquoi. Si un AV tiers est requis, vérifiez qu’il est installé et sain au lieu de laisser une lacune.

Tâche 10 : Confirmer l’état des mises à jour et les dernières dates d’installation

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5"
Source Description      HotFixID  InstalledBy          InstalledOn
------ -----------      --------  -----------          -----------
FS01   Update           KB503xxxx NT AUTHORITY\SYSTEM  2/5/2026
FS01   Security Update  KB503yyyy NT AUTHORITY\SYSTEM  2/5/2026
FS01   Update           KB503zzzz NT AUTHORITY\SYSTEM  2/5/2026
FS01   Update           KB502aaaa NT AUTHORITY\SYSTEM  1/14/2026
FS01   Update           KB502bbbb NT AUTHORITY\SYSTEM  1/14/2026

Signification : Vous pouvez rapidement dire si le serveur est à jour ou en retard de plusieurs mois.

Décision : Si les derniers correctifs sont anciens, réparez votre pipeline de mises à jour avant d’installer d’autres rôles. La dette technique démarre instantanément.

Tâche 11 : Vérifier si BitLocker est activé (et si le TPM est utilisable)

cr0x@server:~$ powershell -NoProfile -Command "Get-BitLockerVolume -MountPoint 'C:' | Select-Object MountPoint,VolumeStatus,ProtectionStatus,EncryptionPercentage"
MountPoint VolumeStatus    ProtectionStatus EncryptionPercentage
---------- ------------    ---------------- --------------------
C:         FullyEncrypted  On               100

Signification : Confirme que le chiffrement au repos est actif.

Décision : Si vous exigez le chiffrement et qu’il est désactivé, activez-le maintenant et consignez les clés de récupération selon la politique. Si vous n’avez pas de processus de gestion des clés, ne faites pas n’importe quoi.

Tâche 12 : Valider la disposition des disques et volumes (éviter le futur « C: plein »)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Select-Object DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size | Sort-Object DriveLetter"
DriveLetter FileSystemLabel FileSystem SizeRemaining Size
----------- -------------- ---------- ------------- ----
C           OS             NTFS       58.4 GB       120 GB
E           DATA           NTFS       1.6 TB        2.0 TB
F           LOGS           NTFS       350 GB        400 GB

Signification : Montre où il y a de l’espace et si votre plan de volumes correspond à la réalité.

Décision : Si les logs et les données vivent sur C:, changez cela avant la mise en production des apps. Déplacer plus tard est plus difficile et risqué.

Tâche 13 : Vérifier la santé du stockage (vue SMART via Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName,MediaType,HealthStatus,OperationalStatus,Size"
FriendlyName      MediaType HealthStatus OperationalStatus Size
------------      --------- ------------ ----------------- ----
NVMe Disk 0       SSD       Healthy      OK                1.8 TB
NVMe Disk 1       SSD       Healthy      OK                1.8 TB

Signification : Signal basique : Windows pense que les disques sont sains et opérationnels.

Décision : Si vous voyez « Warning » ou « Unhealthy », arrêtez et enquêtez avant de confier des données à cet hôte.

Tâche 14 : Confirmer les rôles installés (et repérer les accidentels)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsFeature | Where-Object { $_.Installed -eq $true } | Select-Object -First 15"
Display Name                                            Name                       Install State
------------                                            ----                       -------------
File and Storage Services                               FileAndStorage-Services    Installed
File Server                                             FS-FileServer              Installed
Windows Server Backup                                   Windows-Server-Backup      Installed
Windows Defender Features                               Windows-Defender-Features  Installed
Remote Server Administration Tools                      RSAT                       Installed

Signification : Confirme ce que vous avez réellement installé.

Décision : Si vous voyez des rôles inutiles (ex. Web-Server sur un serveur de fichiers), retirez-les. Moins de code, moins de problèmes.

Tâche 15 : Installer un rôle explicitement (exemple : serveur de fichiers) et vérifier

cr0x@server:~$ powershell -NoProfile -Command "Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools"
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {File Server}

Signification : Rôle installé avec succès et ne nécessite pas de redémarrage (cette fois).

Décision : Si Restart Needed est Yes, redémarrez maintenant—ne superposez pas d’autres changements sur un redémarrage en attente.

Tâche 16 : Vérifier les bases de la configuration SMB (signature, dialectes)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RequireSecuritySignature,EncryptData"
EnableSMB1Protocol EnableSMB2Protocol RequireSecuritySignature EncryptData
------------------ ------------------ ------------------------ -----------
False              True               True                     False

Signification : SMBv1 est désactivé (bien), SMBv2+ est activé, la signature est requise, et le chiffrement est actuellement optionnel.

Décision : Pour des partages sensibles ou des réseaux non fiables, activez le chiffrement SMB par partage ou globalement. Ne chiffrez pas tout sans mesurer l’impact CPU.

Blague n°2 : Désactiver le pare-feu parce qu’« il bloque mon appli » c’est comme enlever le détecteur de fumée parce qu’il est bruyant.

Mode d’action diagnosis rapide (trouver le goulot vite)

Quand un nouveau serveur semble lent, ne devinez pas. Ne réinstallez pas des pilotes par ennui. Faites un court triage qui vous dit où le temps est passé.
L’objectif est d’isoler le CPU, la pression mémoire, la latence stockage, le réseau ou l’identité/DNS.

Premier point : est-ce le stockage, et est-ce évident ?

• Vérifiez la file d’attente disque et la latence : si le stockage est lent, tout est lent.
• Vérifiez si le volume OS est presque plein : peu d’espace provoque des comportements pathologiques et des mises à jour échouées.
• Consultez les journaux d’événements : réinitialisations de disque, avertissements storport, problèmes NTFS.

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write' -SampleInterval 2 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:02:11 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.004
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.007
2/5/2026 9:02:13 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.005
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.009
2/5/2026 9:02:15 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.004
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.008

Signification : Des latences en millisecondes à un chiffre sont généralement saines pour beaucoup de charges. Des dizaines/centaines de ms indiquent un problème.

Décision : Si la latence est élevée, cessez de blâmer « Windows » et commencez à vérifier le backend stockage, les politiques de cache d’écriture, le multipath SAN, et les voisins bruyants.

Deuxième point : pression CPU et mémoire (vérifications simples d’abord)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Processor Time','\Memory\Available MBytes' -SampleInterval 2 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:03:01 AM       \\FS01\processor(_total)\% processor time : 12.4
                          \\FS01\memory\available mbytes : 18234
2/5/2026 9:03:03 AM       \\FS01\processor(_total)\% processor time : 10.1
                          \\FS01\memory\available mbytes : 18190
2/5/2026 9:03:05 AM       \\FS01\processor(_total)\% processor time : 11.7
                          \\FS01\memory\available mbytes : 18210

Signification : Le CPU n’est pas saturé et la mémoire n’est pas à court.

Décision : Si le CPU est élevé, identifiez les processus principaux et vérifiez les scans antivirus, la journalisation excessive, ou l’indexation mal configurée. Si la mémoire est faible, confirmez le comportement de pagination et le dimensionnement des apps.

Troisième point : DNS et identité (parce que tout en dépend)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName corp.example -Type SOA"
Name         Type TTL  Section    NameHost
----         ---- ---  -------    --------
corp.example SOA  3600 Answer     dns01.corp.example

Signification : La résolution DNS fonctionne et renvoie des infos autoritaires.

Décision : Si le DNS est lent ou échoue, réparez le DNS avant de dépanner les délais d’app. Les apps gèrent mal un DNS défaillant ; elles souffrent simplement de manière créative.

Quatrième point : bases réseau (ne pas benchmarker avec de l’optimisme)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName dns01.corp.example -Port 53"
ComputerName           : dns01.corp.example
RemoteAddress          : 10.20.1.10
RemotePort             : 53
InterfaceAlias         : Ethernet0
SourceAddress          : 10.20.5.21
TcpTestSucceeded       : True

Signification : La connectivité de base vers une dépendance fonctionne sur le port attendu.

Décision : Si cela échoue, vous avez des problèmes de routage/pare-feu/VLAN. Arrêtez de toucher à la construction du serveur et allez parler du chemin réseau.

Erreurs courantes : symptômes → cause racine → correction

1) « L’installation du rôle a réussi, mais les services échouent ou se comportent mal »

Symptômes : Les services ne démarrent pas ; fonctionnalités partiellement opérationnelles ; le Visualiseur d’événements montre des erreurs de servicing/CSI ; les redémarrages semblent parfois résoudre le problème.

Cause racine : État de redémarrage en attente dû à des mises à jour ou des installations de fonctionnalités.

Correction : Redémarrez jusqu’à ce que les états en attente disparaissent ; confirmez avec la vérification de registre de redémarrage en attente. Puis relancez l’installation/réparation du rôle.

2) « La jonction au domaine fonctionne, mais l’authentification est instable »

Symptômes : Erreurs Kerberos, GPO qui ne s’applique pas, accès refusé sporadique.

Cause racine : Dérive temporelle ou hiérarchie NTP incorrecte.

Correction : Vérifiez w32tm /query /status ; corrigez la source temporelle ; confirmez le fuseau horaire ; resynchronisez et retestez.

3) « Les partages de fichiers sont lents, surtout aux heures de pointe »

Symptômes : Les opérations de copie marquent des pauses ; l’Explorateur plante ; le CPU du serveur semble normal.

Cause racine : Pics de latence stockage (congestion SAN, thin provisioning, politique de cache d’écriture, snapshots en arrière-plan).

Correction : Mesurez les compteurs de latence disque ; vérifiez la performance du backend stockage ; séparez logs/temp ; envisagez QoS ou volumes dédiés.

4) « RDP est exposé et des tentatives de password spray apparaissent »

Symptômes : Bruit dans le journal de sécurité, verrouillages de comptes, IP aléatoires essayant de se connecter.

Cause racine : RDP autorisé largement ; règles de pare-feu trop permissives ; contrôles d’accès faibles.

Correction : Restreignez le RDP aux sous-réseaux d’administration/VPN ; exigez NLA ; limitez les groupes autorisés ; envisagez de désactiver RDP sur le profil public.

5) « Windows Update échoue sans cesse avec des erreurs obscures »

Symptômes : Les mises à jour se téléchargent mais ne s’installent pas ; échecs répétés ; erreurs du servicing stack.

Cause racine : Peu d’espace disque sur C:, configuration de source de mise à jour cassée, ou composants de servicing obsolètes.

Correction : Libérez de l’espace ; confirmez la politique de source de mise à jour ; redémarrez ; puis réessayez. Si persistant, vous êtes peut-être dans un cas de « réparation ou reconstruire » — décidez selon la reproductibilité de votre build.

6) « Après durcissement, une application casse en production »

Symptômes : L’application ne peut pas se lier à un port, n’écrit pas les logs, ou ne s’authentifie pas auprès de services distants.

Cause racine : Changements de durcissement appliqués sans modèle d’exceptions spécifique à l’application (droits du compte de service, ACLs de dossiers, règles de pare-feu).

Correction : Avancez avec des exceptions ciblées : règles pare-feu étroites, ACLs en moindre privilège, permissions documentées des comptes de service. Évitez les désactivations globales.

Trois mini-histoires d’entreprise (comment ça foire en vrai)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe a lancé une nouvelle VM Windows Server pour une application métier. L’ingénieur a supposé que « DHCP c’est bon ; l’IP restera la même » parce que la VM vivait sur un cluster stable.
Personne n’a créé de réservation. Personne n’a documenté l’adresse. Ça a passé les tests parce que l’IP n’a pas changé pendant des semaines.

Puis une maintenance routine de l’hyperviseur a déplacé la VM vers un autre réseau d’hôte avec une configuration de scope DHCP différente.
Le serveur a démarré, demandé une adresse, et obtenu une nouvelle IP. Le nettoyage DNS a fini par supprimer l’ancien enregistrement et le remplacer par le nouveau.
L’app n’utilisait pas DNS, cependant. Elle avait l’ancienne IP codée en dur à trois endroits, y compris un connecteur fournisseur que personne ne connaissait.

Le mode de défaillance était cinématographique : les utilisateurs voyaient des erreurs intermittentes parce que la moitié des clients mettait en cache l’ancienne IP et l’autre moitié résolvait la nouvelle.
L’authentification semblait correcte. Le CPU et la RAM semblaient corrects. La supervision semblait correcte—parce que les sondes pointaient l’ancienne adresse.

La correction était ennuyeuse : IP statique (ou réservation), DNS correct, et une règle imposant que les dépendances soient adressées par nom DNS, pas par IP, sauf raison documentée.
La vraie leçon : « Ça marchait en test » n’est pas une preuve de conformité. C’est la preuve que le temps ne vous a pas encore puni.

Mini-histoire 2 : L’optimisation qui a mal tourné

Un autre service faisait tourner un serveur de fichiers chargé sur un stockage partagé. Quelqu’un a remarqué que l’activation du chiffrement SMB « améliorerait la sécurité », alors ils l’ont activé globalement.
Le changement a passé un test superficiel : quelques copies de fichiers ont fonctionné, et aucune alarme n’est apparue. L’ingénieur a écrit un joli compte-rendu et est rentré chez lui satisfait.

Deux jours plus tard, la performance en heures de pointe s’est dégradée. Pas catastrophiquement—juste assez pour provoquer des files d’attente, des temps de connexion plus longs et des tickets difficiles à corréler.
Le CPU du serveur de fichiers a augmenté. Le débit réseau semblait légèrement inférieur. La latence stockage a grimpé parce que les clients ont recommencé des opérations pendant la congestion.
Tout le monde a blâmé le SAN parce que tout le monde blâme toujours le SAN.

Le postmortem a trouvé le vrai coupable : le surcoût du chiffrement sur des clients anciens et un sous-ensemble de workflows à haut débit. Le serveur avait beaucoup de CPU, mais le schéma de sessions SMB chiffrées
augmentait le coût par connexion. Le changement a aussi interagi avec l’antivirus au moment d’ouvrir les fichiers, multipliant la surcharge d’une façon que les benchmarks n’avaient pas capturée.

Le rollback a amélioré la performance immédiatement. La correction forward était plus mature : activer le chiffrement seulement pour les partages sensibles, confirmer le support client, et tester avec des charges représentatives.
Les améliorations de sécurité sont bonnes. Les améliorations de sécurité sans test de performance sont la manière de créer un nouveau type d’incident.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise s’est standardisée sur une checklist stricte de build serveur : patcher à jour, vérifier l’état de redémarrage en attente, appliquer des règles pare-feu de base, exporter la configuration des rôles, et prendre un instantané propre.
Ce n’était pas glamour, donc personne n’en parlait. Ils le faisaient, tout simplement, à chaque fois.

Des mois plus tard, une mise à jour cumulative a déclenché une boucle de démarrage étrange sur un sous-ensemble de VMs à cause d’une interaction avec une configuration particulière de contrôleur de stockage virtuel.
Le symptôme ressemblait à « Windows est cassé ». Les tentatives de récupération ont été chaotiques sur des équipes qui n’avaient pas d’état connu bon ou de pattern de build cohérent.

Cette équipe a restauré l’instantané pris juste après la build de base. Ils ont comparé les exportations de configuration entre l’état bon et l’état mauvais.
Ils ont pu prouver ce qui avait changé, quand, et sur quels hôtes. Cela a rendu l’escalade vers l’équipe plateforme précise au lieu d’émotionnelle.

Le contournement a été simple : ajuster le paramétrage du contrôleur virtuel, appliquer la mise à jour à nouveau, et confirmer la stabilité.
La checklist n’a pas empêché le bug. Elle a empêché que l’incident ne devienne une fouille archéologique de plusieurs jours.

Checklists / plan étape par étape

Checklist pré-installation (5 minutes, épargne des heures)

• Confirmer le rôle du serveur : DC, serveur de fichiers, hôte Hyper-V, IIS, serveur applicatif, etc.
• Décider du mode d’installation : Server Core sauf si vous avez besoin d’outils GUI locaux.
• Décider du plan de disques : OS vs données vs logs ; dimensionnez-les en prévision de la croissance.
• Décider de la source de mise à jour : WSUS vs WUfB vs Microsoft Update direct.
• Décider de la baseline de sécurité : posture pare-feu, politique RDP, politique Defender, exigence BitLocker.
• Confirmer que vous disposez de procédures d’accès break-glass (admin local, console d’urgence).

Checklist d’installation (15 minutes)

• Installer l’édition Windows Server prévue.
• Utiliser UEFI + Secure Boot si supporté.
• Partitionner les volumes comme prévu ; étiqueter clairement les volumes (OS, DATA, LOGS).
• Définir un mot de passe administrateur local fort et le stocker dans votre gestionnaire de secrets selon la politique.

Checklist premier démarrage (20 minutes)

• Définir le nom d’hôte et redémarrer (faites-le maintenant pour qu’il ne vous surprenne pas plus tard).
• Configurer les NIC : IP statique pour les dépendances d’infrastructure ; serveurs DNS corrects.
• Régler le fuseau horaire et vérifier la source NTP/le temps.
• Activer WinRM/PowerShell Remoting comme méthode d’administration principale (si la politique le permet).
• Activer le pare-feu pour tous les profils ; créer des règles explicites pour les réseaux de management.

Checklist patching (10–20 minutes, varie selon bande passante)

• Installer les dernières mises à jour.
• Redémarrer.
• Vérifier s’il y a encore des mises à jour.
• Répéter jusqu’à absence de mises à jour en attente et d’état de redémarrage.

Checklist rôles et durcissement (10–20 minutes)

• Installer uniquement les rôles requis avec PowerShell.
• Vérifier que les ports d’écoute et les règles pare-feu correspondent à l’intention.
• Confirmer l’état de Defender ; implémenter les exclusions nécessaires de manière ciblée.
• Activer BitLocker si requis et si vous avez des processus d’escrow/recouvrement des clés.
• Exporter un « reçu » de configuration (rôles, paramètres réseau) dans votre enregistrement de changement.
• Prendre un instantané/checkpoint ou réaliser une sauvegarde baseline.

FAQ

1) Dois-je utiliser Server Core pour Windows Server ?

Oui, sauf si vous avez une dépendance GUI spécifique. Core réduit la surface de correctif et tend à mieux se comporter avec une administration distante disciplinée.
Si votre équipe manque de maturité opérationnelle Core, améliorez les pratiques d’équipe—ne pénalisez pas le serveur.

2) Quand dois-je installer les rôles : avant ou après le patching ?

Après le patching, dans la plupart des cas. Patcher d’abord réduit les cas limites d’installation de rôle et réduit la fenêtre d’exposition.
Si un rôle exige des prérequis modifiant le servicing, installez les prérequis, redémarrez, patchez, puis poursuivez.

3) Windows Defender suffit-il sur les serveurs ?

Pour beaucoup d’environnements, Defender est une base solide—surtout comparé à « rien » ou à un agent tiers non maintenu.
Si la politique exige autre chose, d’accord ; assurez-vous simplement d’avoir une protection et une télémétrie effectives, pas une case cochée.

4) Dois-je activer BitLocker sur les serveurs ?

Si vous avez des exigences de conformité, des données sensibles, ou un risque d’exposition des disques (cloud, colo, laptops transformés en serveurs—oui, ça existe), alors oui.
Mais faites-le avec un escrow de clés et un processus de récupération. Le chiffrement sans récupération n’est pas de la sécurité ; c’est une perte de données auto-infligée.

5) Dois-je vraiment garder le pare-feu activé dans le datacenter ?

Oui. Les réseaux internes ne sont pas automatiquement fiables, et le mouvement latéral est une tactique d’attaquant classique.
Gardez le pare-feu activé, bloquez l’inbound par défaut, et autorisez explicitement les ports de management et applicatifs.

6) Comment choisir entre NTFS et ReFS ?

Si vous avez besoin de compatibilité maximale et pas de raison précise, choisissez NTFS.
Envisagez ReFS quand vous avez un cas d’utilisation validé et un plan de test incluant sauvegardes, restaurations et compatibilité applicative.

7) Quelle est la façon la plus rapide de dire si la « lenteur » vient du stockage ?

Vérifiez les compteurs de latence disque et les journaux liés au stockage. Si les lectures/écritures sont constamment à plusieurs dizaines de millisecondes ou plus sous charge normale,
le stockage est votre premier suspect, même si le CPU semble calme.

8) Dois-je autoriser RDP du tout ?

Autorisez-le comme chemin de break-glass contrôlé, pas comme outil d’administration quotidien.
Restreignez-le aux réseaux d’admin, exigez NLA, et limitez les personnes pouvant se connecter. Préférez PowerShell Remoting pour les opérations de routine.

9) Comment éviter les « serveurs flocons de neige » ?

Utilisez PowerShell pour les installations et configurations, maintenez une checklist de build, et stockez les exports de configuration dans vos enregistrements de changement.
Si un serveur ne peut pas être reconstruit à partir d’étapes documentées, c’est un flocon de neige—peu importe la confiance de l’installateur.

10) Quel est le minimum de vérifications après la première heure ?

Confirmer : pas de redémarrages en attente, mises à jour à jour, pare-feu activé, Defender sain, DNS/temps corrects, seuls les ports d’écoute attendus, et volumes avec de l’espace et logs hors de C:. C’est le seuil « safe to proceed ».

Prochaines étapes (faites simple)

Après la première heure, votre travail passe de « construire » à « exploiter ». Faites ce qui suit :

• Définir des seuils de supervision pour espace disque, latence disque, CPU, mémoire et mises à jour échouées. Si vous ne mesurez pas, vous le découvrirez via des tickets.
• Centraliser les logs si votre environnement le permet (transfert d’événements/SIEM). Les logs locaux sont bien tant que le serveur est en ligne.
• Documenter le contrat de rôle : quels ports sont ouverts, quels comptes de service existent, quelles sauvegardes s’exécutent, et quelle est la procédure de restauration.
• Tester une restauration. Des sauvegardes sans restauration ne sont que des dépenses émotionnelles.
• Planifier des fenêtres de patch et prouver que vous pouvez redémarrer sans drame. La peur du redémarrage est la raison pour laquelle des serveurs deviennent non patchables.

Votre but n’est pas de construire un serveur que vous puissiez admirer. C’est de construire un serveur que vous pouvez oublier—parce qu’il est patché, durci, observable,
et qu’il exécute sa tâche unique sans drame.