Checklist d’installation complète de Windows Server 2022 : une configuration sans blabla qui prévient les problèmes

Principes : considérer une nouvelle installation comme une infrastructure de production

Une « nouvelle installation » n’est pas une toile vierge. C’est un ensemble de paramètres par défaut, dont beaucoup ont été choisis pour la compatibilité, pas pour votre disponibilité. Votre travail est de remplacer le mystère par l’intention.

Principe 1 : rendre chaque dépendance explicite

Nommer les serveurs selon leur fonction. Verrouiller le DNS. Décider des sources NTP. Définir la cadence des correctifs. Définir la rétention des journaux. Déterminer où vont les sauvegardes et comment vous testez les restaurations. Si ce n’est pas écrit et observable, ça n’existe pas.

Principe 2 : optimiser en dernier

Le réglage des performances sans données de référence n’est que de la superstition avec des étapes supplémentaires. Obtenez d’abord une base stable : pilotes corrects, disposition de stockage prévisible, journaux d’événements propres et firmware connu bon. Ensuite mesurez. Ensuite ajustez.

Principe 3 : si vous ne pouvez pas diagnostiquer en 10 minutes, vous l’avez mal construit

Dans les dix premières minutes d’un incident en production, vous devriez pouvoir répondre : qu’est-ce qui a changé, qu’est-ce qui est saturé, et qu’est-ce qui échoue. Cela nécessite un travail préparatoire : tailles de journaux, compteurs, réglages de dump en cas de plantage, et quelques commandes standard que tout le monde utilise.

Une citation à garder sur vous : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan. En exploitation, l’espoir, c’est ce que vous faites quand vous avez sauté la checklist.

Faits intéressants et contexte historique (pourquoi Windows est comme il est)

• Le journal NTFS remonte à l’époque de Windows NT ; c’est pourquoi Windows survit souvent mieux aux pertes de courant que des systèmes de fichiers plus anciens, mais le journal n’est pas synonyme de cohérence applicative.
• Windows Server Core existe parce que les composants GUI augmentent la surface d’attaque et la fréquence des redémarrages. Core s’est répandu après que les administrateurs ont réalisé que « moins installé » signifie souvent « moins cassé ».
• Sensibilité temporelle d’Active Directory : c’est une héritage qui ne disparaît pas : les tickets Kerberos sont limités dans le temps, donc une synchronisation horaire négligente devient des « échecs d’authentification mystérieux ».
• Réputation de SMB améliorée au fil des versions ; SMB 3.x a apporté chiffrement et meilleures performances par rapport au vieux stéréotype « partage de fichiers = lent ».
• Le pare-feu Windows était autrefois vu comme une gêne côté client. Aujourd’hui, c’est un contrôle de première ligne dans le durcissement des serveurs, et il s’intègre bien avec la politique à grande échelle.
• ReFS a été conçu pour gérer l’intégrité des données et de grands volumes, mais sa matrice de support (fonctionnalités, démarrage, déduplication) a toujours été plus une question de « politique d’entreprise » que de « tout est permis ».
• Journalisation des événements devenue plus structurée avec le temps, mais les tailles par défaut reflètent encore un monde optimiste où les pannes sont brèves et les auditeurs indulgents.
• UEFI et GPT ne sont pas qu’une mode moderne. Ils réduisent les risques d’avoir des limitations de démarrage étranges et des dispositions de partition fragiles héritées de l’ère BIOS/MBR.

Décisions pré-installation qu’on ne peut pas « corriger plus tard »

Choisir l’édition et le mode d’installation adaptés

Utilisez Server Core sauf si vous avez une exigence incontournable pour des composants GUI (certains agents fournisseurs, flux de travail MMC hérités ou rôles spécifiques). Core réduit les correctifs et la surface d’attaque. Si votre organisation n’est pas prête, d’accord — installez Desktop Experience mais considérez-le comme une dette technique temporaire.

Décider : joindre le domaine maintenant ou plus tard

Joindre plus tard est parfois plus sûr quand vous êtes encore en train de construire le stockage/le réseau et que vous ne voulez pas que la stratégie de groupe vous empêche d’avancer. Mais joindre tôt peut appliquer des contrôles de sécurité de base et vous donner une gestion centralisée. Les deux sont valides — ne vous « joignez » pas accidentellement puis ne vous demandez pas pourquoi les paramètres locaux se réinitialisent.

Plan de stockage : disque OS vs disque de données, et ce que vous optimisez

Séparez l’OS des données. Toujours. Gardez le volume OS ennuyeux : taille prévisible, beaucoup d’espace libre pour les mises à jour et les dumps, aucune donnée applicative. Placez les données sur des volumes dédiés avec des étiquettes qui disent la vérité (pas « New Volume »). Si vous utilisez Storage Spaces, choisissez miroir vs parité selon le profil I/O et les attentes de reconstruction, pas selon les impressions.

Plan réseau : IP, DNS et règles de routage

Notez l’IP prévue, la passerelle, les serveurs DNS et si cette machine doit s’enregistrer dans DNS. Décidez si vous utilisez l’agrégation NIC (et quel mode). Décidez si vous faites du tagging VLAN dans l’hyperviseur ou dans l’OS. Un serveur avec deux passerelles par défaut « utiles » est une carrière de dépannage en boîte.

Stratégie de correctifs : WSUS, Windows Update for Business ou manuel

Décidez qui est responsable des correctifs et quand. Si c’est « on le fera quand on aura le temps », vous décidez en réalité de patcher pendant un incident. Choisissez une cadence, définissez des fenêtres de maintenance et créez un plan de retour arrière.

Blague #1 : Le nom par défaut du serveur, c’est comme laisser votre valise à l’aéroport étiquetée « bag ». Elle voyagera, juste pas là où vous vouliez.

Checklists / plan étape par étape (de zéro à prêt)

Phase 0 : sanity firmware et plateforme

• Mettre à jour BIOS/UEFI, firmware du contrôleur de stockage, firmware de la carte réseau et iDRAC/iLO équivalent avant l’installation de l’OS quand c’est possible.
• Activer le démarrage UEFI et confirmer le plan de partitionnement GPT.
• Confirmer les réglages de virtualisation si applicable (VT-x/AMD-V, SR-IOV si nécessaire).

Phase 1 : installation et post-install immédiat

• Installer Windows Server 2022 (Core si possible), choisir l’édition correcte, définir un mot de passe administrateur local robuste.
• Définir le nom d’hôte, l’IP, le DNS et la stratégie de synchronisation horaire.
• Installer intentionnellement les pilotes fournisseur (NIC/stockage), pas « tout ce que Windows a trouvé ».
• Lancer Windows Update et redémarrer jusqu’à propreté.

Phase 2 : configuration de base

• Configurer une base de politique de pare-feu Windows ; n’autoriser que ce dont vous avez besoin.
• Définir la politique de crash dump et la taille du fichier d’échange pour pouvoir déboguer les écrans bleus ultérieurement.
• Redimensionner les journaux d’événements et définir le comportement de rétention.
• Activer la gestion à distance correctement (WinRM, remoting PowerShell) avec un périmètre auditable.

Phase 3 : stockage et chemin de données

• Initialiser et formater les disques de données avec des étiquettes, tailles d’unité d’allocation appropriées au workload.
• Configurer Storage Spaces/RAID avec tolérance de panne documentée ; tester une défaillance si vous le pouvez (tirer un disque en labo).
• Valider la politique de cache d’écriture et la protection d’alimentation (BBU/cache flash).

Phase 4 : preuve de sauvegarde et restauration

• Installer l’agent de sauvegarde, définir les jobs et confirmer les sauvegardes application-aware quand nécessaire.
• Tester la restauration d’au moins un fichier et d’un chemin de restauration état-système/application.
• Documenter les attentes RPO/RTO en langage clair.

Phase 5 : supervision et crochets opérationnels

• Installer l(es) agent(s) de supervision, confirmer la couverture métrique/alertes (CPU, mémoire, latence disque, erreurs NIC, santé des services).
• Confirmer le forwarding des journaux d’événements ou l’ingestion SIEM.
• Établir un « bundle de preuves standard » de commandes pour les incidents.

Tâches de validation pratiques (commandes, sorties et décisions)

Ce sont le type de commandes que vous exécutez le jour 1 et à nouveau pendant les incidents. Chacune inclut ce que la sortie signifie et ce que vous décidez ensuite. Exécutez-les dans une invite PowerShell élevée sauf mention contraire.

Tâche 1 : Confirmer la version de l’OS, le build et le type d’installation

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, CsName"
WindowsProductName : Windows Server 2022 Standard
WindowsVersion     : 21H2
OsBuildNumber      : 20348
CsName             : FS-PRD-01

Ce que ça signifie : Vous vérifiez que vous avez réellement installé ce que vous pensez avoir installé (et ce que votre licensing et vos baselines supposent).

Décision : Si l’édition/la version est incorrecte, arrêtez maintenant et corrigez. Ne construisez pas la production sur du « suffisamment proche ».

Tâche 2 : Vérifier l’état de redémarrage en attente (avant d’accuser un comportement « aléatoire »)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending' -ErrorAction SilentlyContinue | Out-String"

Ce que ça signifie : Si cela renvoie du contenu (une clé existe), Windows est souvent en maintenance. Certains rôles/pilotes se comportent étrangement tant que ce n’est pas redémarré.

Décision : Si un redémarrage est en attente, planifiez-le maintenant — avant de « continuer la configuration » et créer un état à moitié appliqué.

Tâche 3 : Vérifier le nom d’hôte, l’adhésion au domaine et le statut du canal sécurisé

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

cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Verbose"
True

Ce que ça signifie : L’état d’adhésion au domaine est correct et le compte machine a une confiance intacte.

Décision : Si Test-ComputerSecureChannel échoue, corrigez la confiance (souvent le temps/DNS) avant d’installer des services dépendants du domaine.

Tâche 4 : Confirmer la configuration IP, les serveurs DNS et les pièges « multiples passerelles »

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DNSServer"
InterfaceAlias    : Ethernet0
IPv4Address       : 10.20.30.40
IPv4DefaultGateway: 10.20.30.1
DNSServer         : {10.20.0.10, 10.20.0.11}

Ce que ça signifie : Vous avez une passerelle par défaut (bon) et le DNS pointe vers des résolveurs internes (habituellement correct pour les serveurs joints au domaine).

Décision : Si vous voyez plusieurs passerelles par défaut sur différentes NIC, retirez-les et utilisez des routes statiques si vraiment nécessaire.

Tâche 5 : Valider la résolution DNS et l’enregistrement

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName -Name corp.example -Type A"
Name      Type TTL Section IPAddress
----      ---- --- ------- ---------
corp.example A   600 Answer  10.20.0.20

cr0x@server:~$ powershell -NoProfile -Command "ipconfig /registerdns"
Windows IP Configuration

Registration of the DNS resource records for all adapters of this computer has been initiated. Any errors will be reported in the Event Viewer in 15 minutes.

Ce que ça signifie : Le DNS de base fonctionne et le serveur peut enregistrer ses enregistrements (critique pour de nombreux workflows Windows).

Décision : Si des erreurs d’enregistrement apparaissent dans les événements Client DNS, corrigez les permissions/les paramètres de nettoyage et confirmez les suffixes DNS corrects.

Tâche 6 : Confirmer la source de synchronisation horaire et le décalage (Kerberos s’en soucie)

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

Ce que ça signifie : Vous synchronisez l’heure depuis un contrôleur de domaine (comportement typique des membres de domaine). Le stratum indique le niveau de qualité.

Décision : Si la Source est Local CMOS Clock ou si le décalage est important, corrigez l’heure avant que des problèmes d’authentification n’apparaissent comme « aléatoires ».

Tâche 7 : Vérifier l’état de Windows Update et les hotfixes installés

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn"
HotFixID  InstalledOn
--------  -----------
KB503xxxx 1/28/2026 12:00:00 AM
KB503yyyy 1/14/2026 12:00:00 AM
KB503zzzz 12/10/2025 12:00:00 AM

Ce que ça signifie : Vous pouvez prouver rapidement le niveau de correctifs. Cela compte quand les fournisseurs demandent « Êtes-vous à jour ? »

Décision : Si le dernier correctif est ancien, cessez de traiter cette machine comme « neuve » et considérez-la comme « déjà en retard ». Patch et redémarrez jusqu’à stabilité.

Tâche 8 : Vérifier le profil du pare-feu et les règles effectives

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

Ce que ça signifie : L’entrée par défaut est bloquée (bon). La sortie autorisée est courante ; vous pouvez la restreindre plus tard avec un proxy ou des listes d’autorisation.

Décision : Si le profil Public est actif sur une NIC serveur, corrigez la classification réseau sinon vous poursuivrez « pourquoi ce port n’écoute pas ? ».

Tâche 9 : Confirmer que les services critiques sont configurés correctement (et non lancés par accident)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object -First 10 Name, DisplayName, StartType"
Name    DisplayName                         StartType
----    -----------                         ---------
Dnscache DNS Client                         Automatic
LanmanServer Server                         Automatic
EventLog Windows Event Log                  Automatic
WinRM    Windows Remote Management (WS-Management) Automatic

Ce que ça signifie : Vous cherchez des « services surprise » (agents tiers, protocoles hérités, updaters fournisseurs aléatoires).

Décision : Si vous voyez un service non approuvé, identifiez la source de l’installation et supprimez/le désactivez avant qu’il ne devienne un passif non patché.

Tâche 10 : Inspecter la disposition des disques, le style de partition et l’espace libre

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Select-Object Number, FriendlyName, PartitionStyle, Size, OperationalStatus"
Number FriendlyName          PartitionStyle Size         OperationalStatus
------ ------------          -------------- ----         -----------------
0      NVMe RAID Controller  GPT            476.94 GB    Online
1      DataDisk01            GPT            3.64 TB      Online

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, SizeRemaining, Size"
DriveLetter FileSystemLabel FileSystem SizeRemaining Size
----------- -------------- --------- ------------- ----
C           OS             NTFS      120.45 GB     200 GB
D           DATA           NTFS      2.10 TB       3.64 TB

Ce que ça signifie : GPT est utilisé (bon). Vous avez un étiquetage clair et un espace libre adéquat.

Décision : Si C: est minuscule, corrigez-le maintenant. Les mises à jour Windows, le magasin de composants et les dumps puniront le « minimalisme ».

Tâche 11 : Vérifier les paramètres d’intégrité du système de fichiers et lancer une vérification rapide

cr0x@server:~$ powershell -NoProfile -Command "Repair-Volume -DriveLetter C -Scan -Verbose"
VERBOSE: The volume was scanned and no problems were found.

Ce que ça signifie : Vous confirmez que le volume ne commence pas sa vie avec une corruption ou des anomalies de stockage sous-jacentes.

Décision : Si des erreurs apparaissent, arrêtez d’installer des applications et examinez le stockage/firmware/pilotes immédiatement.

Tâche 12 : Valider rapidement les compteurs de performance du stockage (la latence dit la vérité)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\LogicalDisk(D:)\Avg. Disk sec/Read','\LogicalDisk(D:)\Avg. Disk sec/Write' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path, CookedValue"
Path                                          CookedValue
----                                          -----------
\\FS-PRD-01\logicaldisk(D:)\avg. disk sec/read 0.0021
\\FS-PRD-01\logicaldisk(D:)\avg. disk sec/write 0.0045

Ce que ça signifie : La latence est basse (millisecondes). Pour beaucoup de workloads, des lectures/écritures soutenues au-delà de ~20–30ms sont le début des problèmes.

Décision : Si la latence est élevée au repos, suspectez les pilotes, la politique de cache, un RAID mal configuré ou des problèmes SAN sous-jacents.

Tâche 13 : Confirmer le support TRIM pour les volumes sur SSD

cr0x@server:~$ powershell -NoProfile -Command "fsutil behavior query DisableDeleteNotify"
NTFS DisableDeleteNotify = 0  (Disabled)
ReFS DisableDeleteNotify = 0  (Disabled)

Ce que ça signifie : « 0 » signifie que les notifications de suppression (TRIM/UNMAP) sont activées, ce qui aide la longévité et les performances des SSD dans de nombreuses piles.

Décision : Si activé mais que votre backend de stockage ne gère pas bien UNMAP (certains SAN thin-provisioned), validez avec l’équipe stockage avant de modifier aveuglément les paramètres.

Tâche 14 : Confirmer les versions des pilotes pour la NIC et le contrôleur de stockage

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object {$_.Status -eq 'OK'} | Select-Object -First 3 FriendlyName, InstanceId"
FriendlyName                    InstanceId
------------                    ----------
Intel(R) Ethernet Server Adapter PCI\VEN_8086&DEV_1592&SUBSYS...

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceName -like '*Ethernet*'} | Select-Object -First 1 DeviceName, DriverVersion, DriverDate"
DeviceName                               DriverVersion DriverDate
----------                               ------------ ----------
Intel(R) Ethernet Server Adapter         2.1.3.0       2024-11-02

Ce que ça signifie : Vous pouvez prouver la provenance et l’ancienneté des pilotes.

Décision : Si vous utilisez des pilotes inbox pour du matériel critique en production, envisagez les pilotes fournisseur. Mais ne « mettez pas à niveau » pendant un incident sans plan de retour arrière.

Tâche 15 : Vérifier les tailles et la rétention des journaux d’événements (parce que les valeurs par défaut sont chiches)

cr0x@server:~$ powershell -NoProfile -Command "wevtutil gl System | findstr /i \"maxSize retention\""
maxSize: 20971520
retention: false

Ce que ça signifie : 20Mo, c’est minuscule en conditions réelles. retention=false signifie écraser quand nécessaire.

Décision : Augmentez les tailles et/ou forwardez les journaux. Sinon, vous perdrez la preuve avant d’ouvrir l’Observateur d’événements.

Tâche 16 : Confirmer la configuration des crash dumps (l’assurance « on ne peut pas le reproduire »)

cr0x@server:~$ powershell -NoProfile -Command "wmic recoveros get DebugInfoType, MinidumpDirectory, OverwriteExistingDebugFile"
DebugInfoType  MinidumpDirectory           OverwriteExistingDebugFile
7              %SystemRoot%\Minidump       TRUE

Ce que ça signifie : DebugInfoType 7 indique typiquement un dump mémoire automatique. Le répertoire des minidumps est défini.

Décision : Assurez-vous d’avoir suffisamment d’espace libre et que les dumps sont collectés par vos outils. Si vous ne pouvez pas capturer de dumps, vous ne pouvez pas faire de post-mortems correctement.

Configuration du stockage qui ne vous trahira pas

Volume OS : garder propre, dimensionné et ennuyeux

Donnez de l’espace à C:. Pas « juste assez ». De l’espace. Le magasin de composants Windows grandit, les rollups de correctifs évoluent, et les crash dumps nécessitent de l’espace. Si vous êtes virtualisé, le thin provisioning peut aider — jusqu’à ce que non. Dans tous les cas, surveillez l’espace libre et définissez des alertes.

Volumes de données : étiqueter, séparer et choisir l’unité d’allocation intentionnellement

La plupart des workloads Windows se comportent bien avec les unités d’allocation NTFS par défaut, mais pas tous. Les bases de données et systèmes à haut débit peuvent bénéficier de clusters plus grands, mais c’est une décision liée au workload. Ne copiez pas bêtement « 64K clusters » parce que quelqu’un l’a dit à une conférence.

Pour les serveurs de fichiers, considérez comment vous gérerez quotas, dédup et politiques d’antivirus. Pour SQL, alignez-vous sur les recommandations du fournisseur et mesurez. Pour le stockage de VM, faites attention aux schémas d’écriture aléatoire et au churn des métadonnées.

Storage Spaces vs RAID matériel vs LUNs SAN

RAID matériel offre un comportement prévisible, mais vous devez valider la politique de cache et la protection batterie/flash. Storage Spaces peut être excellent, mais il est sensible à la configuration : colonnes, interleave, résilience et awareness des baies comptent. Les LUNs SAN transfèrent la complexité vers l’array — super quand l’équipe storage est compétente, dangereux quand « quelqu’un d’autre » détient la vérité.

Cache d’écriture : le moyen le plus rapide de perdre des données, aussi le plus rapide pour briller dans les benchmarks

Le cache d’écriture sans protection contre la perte d’alimentation est un pari contre la physique. Parfois ça passe. Parfois non. Décidez quelle histoire vous voulez raconter dans le post-mortem.

Choix du système de fichiers : NTFS vs ReFS (et quand ne pas chercher l’originalité)

NTFS est toujours le défaut pour une raison : compatibilité large, support de démarrage, outils matures. ReFS a des forces pour l’intégrité et certains scénarios de virtualisation, mais sa matrice de fonctionnalités peut vous surprendre selon le SKU et le rôle. Si vous ne pouvez pas expliquer pourquoi vous choisissez ReFS, choisissez NTFS et passez à autre chose.

Réseau : rester volontairement ennuyeux

Une passerelle par défaut par hôte (presque toujours)

Si vous avez besoin de plusieurs réseaux, utilisez des VLANs et du routage correctement. Plusieurs passerelles par défaut font choisir le chaos au trafic. Si vous avez besoin de chemins d’egress différents, utilisez des routes statiques avec métriques et documentation.

Agrégation NIC : faites-le avec intention

Le teaming peut améliorer la résilience, mais ajoute aussi une couche qui casse de façons nouvelles et excitantes. Si vous agrégez, documentez le mode (switch independent vs LACP), le hashing et où le tagging VLAN est fait. Puis testez la défaillance : débranchez un câble et regardez le trafic.

Paramètres DNS : ne vous « aidez » pas vers un split-brain

Les serveurs joints au domaine doivent utiliser des serveurs DNS internes. Les résolveurs publics sur un membre de domaine sont une source classique de bizarreries (SRV non résolus, zones AD ignorées, résolution intermittente). Si vous avez besoin de résolution internet, configurez le forwarding sur votre infrastructure DNS, pas des serveurs aléatoires.

Identité, heure et chaînes de confiance

Synchronisation horaire : décider qui est l’autorité

Dans un domaine, la hiérarchie temporelle compte. Les membres doivent synchroniser depuis les DC. Les DC doivent synchroniser depuis une source de temps fiable. Les DC virtualisés ajoutent des complications si la synchronisation hyperviseur lutte avec le temps Windows.

Certificats : planifier si vous terminez TLS localement

Si le serveur héberge des endpoints HTTPS (IIS, WinRM over HTTPS, services custom), décidez tôt de la stratégie de certificats. PKI interne ? CA publique ? Comment renouvelez-vous automatiquement ? Les certificats expirés sont la panne qui arrive par une invitation calendrier ignorée.

Administrateur local : uniquement pour break-glass, et monitoré

Ayez un compte administrateur local pour la récupération, mais ne l’utilisez pas au quotidien. Appliquez le principe du moindre privilège et l’accès just-in-time si votre organisation peut le gérer. Sinon, au moins rendez l’utilisation de l’admin local bruyante dans les journaux.

Base de sécurité : verrouiller sans se verrouiller dehors

Commencez avec moins de rôles et de fonctionnalités

Installez seulement ce dont vous avez besoin. Chaque rôle ajoute une surface de correctif, des services et des possibles mauvais réglages. Si vous n’êtes pas sûr, n’installez pas encore. Vous pouvez toujours ajouter des fonctionnalités. Les surprises résident dans la suppression ultérieure.

Pare-feu : allow-list inbound, documenter les exceptions

Définissez l’inbound par défaut sur blocage (comme montré plus tôt) et créez des règles explicites pour les services requis. Nommez les règles comme un humain : « Allow SMB from FileServerSubnet », pas « New Rule 47 ». Gardez le périmètre serré : IP/source, profils et ports.

Gestion à distance : WinRM est acceptable ; WinRM non géré ne l’est pas

Activez PowerShell remoting pour les opérations, mais restreignez qui peut l’utiliser. Envisagez des listeners HTTPS quand c’est approprié. Si vous exposez WinRM largement sans contrôles, vous offrez une surface d’attaque.

Hygiène SMB : désactiver ce dont vous n’avez pas besoin

SMBv1 doit être mort. Si un fournisseur en a encore besoin, la vraie correction est : remplacer ce fournisseur. Si vous ne pouvez pas encore, isolez ce système et documentez le risque par écrit.

Blague #2 : SMBv1, c’est comme un fax : parfois ça marche encore, et c’est exactement pourquoi c’est terrifiant.

Journalisation, télémétrie et conservation des preuves

Redimensionnez les journaux maintenant, pas pendant la panne

Les tailles de journaux par défaut sont réglées pour « un admin unique vérifie parfois l’Observateur d’événements », pas pour une vraie réponse à incident. Augmentez System, Application, Security et tous les journaux spécifiques aux rôles (DNS Server, DFSR, Hyper-V, Failover Clustering, etc.).

Forwarder les journaux hors de la machine

Les journaux locaux sont fragiles. Les attaquants les effacent, les disques se remplissent et la rotation écrase. Forwardez vers un collecteur central/SIEM. Si vous n’en avez pas, au moins forwardez les journaux critiques vers un Windows Event Collector. Quand le serveur est en feu, vous voulez des preuves ailleurs.

Baseliner les compteurs de performance

Au minimum, surveillez CPU, mémoire, latence disque, longueur de file d’attente disque (avec contexte), erreurs/drops réseau et la santé des services clés. La latence bat l’utilisation comme prédicteur de douleur : un disque à 20% d’utilisation peut toujours bloquer votre appli si les schémas I/O sont pathologiques.

Sauvegardes et récupération : rendre ça réel

Des sauvegardes sans tests de restauration ne sont que des sentiments coûteux

Faites un test de restauration tôt. Pas des mois plus tard en se disant « on planifiera ». Restaurez un fichier. Restaurez une configuration. Restaurez un objet applicatif si pertinent. Confirmez que les permissions survivent. Confirmez que vous pouvez réellement accéder au stockage de sauvegarde pendant un incident (identifiants, chemins réseau, règles de pare-feu).

Définir RPO et RTO en termes clairs

Quelles données pouvez-vous perdre (RPO) ? Combien de temps le service peut-il être indisponible (RTO) ? Si vous ne pouvez pas répondre, vous n’avez pas une stratégie de sauvegarde ; vous avez un hobby de sauvegarde.

Protéger les sauvegardes depuis le serveur

La séparation des identifiants compte. Si un ransomware prend le serveur, il ne doit pas automatiquement posséder les sauvegardes. Utilisez des comptes séparés, un stockage immuable quand possible, et une segmentation réseau qui reflète la réalité.

Mode d’emploi pour diagnostic rapide (trouver le goulot vite)

Ceci est le « drill des dix minutes ». Utilisez-le quand les utilisateurs signalent lenteur, erreurs ou timeouts. Ne commencez pas par réinstaller des choses. Commencez par observer.

Premier point : confirmer le rayon d’impact et ce qui a changé

• Est-ce un serveur ou plusieurs ?
• Est-ce un rôle (partage de fichiers, web, AD, SQL) ou tout ?
• Des patchs, redémarrages, mises à jour de pilotes, changements de stratégie, renouvellements de certificats ?

Second point : vérifier les quatre saturations courantes (CPU, mémoire, latence disque, réseau)

• CPU : utilisation élevée soutenue, longues files d’attente de ready en virtualisé.
• Mémoire : mémoire disponible faible, fort paging, trimming working set.
• Disque : pics de latence, accumulation de files d’attente, erreurs de contrôleur.
• Réseau : drops/erreurs, mismatch duplex, problèmes DNS, boucles de routage.

Troisième point : valider résolution de noms et heure

Les problèmes DNS et temporels se font passer pour des pannes applicatives en permanence. Si l’authentification ou la découverte de services est bizarre, vérifiez Resolve-DnsName et w32tm tôt.

Quatrième point : lire les journaux d’événements sérieusement

Cherchez des resets de contrôleur/disque, des avertissements NTFS, des basculements de cluster, des plantages de service et des échecs d’audit sécurité. Ne survolez pas. Filtrez par plage horaire autour du début signalé.

Cinquième point : isoler : est-ce l’hôte, la VM ou une dépendance ?

Si virtualisé, comparez les compteurs invités avec les métriques de l’hôte. Si le stockage est partagé, vérifiez si d’autres systèmes voient la latence. Si c’est une dépendance (AD/DNS/SAN), arrêtez de traiter ça comme un problème mono-serveur.

Erreurs courantes : symptômes → cause racine → correctif

1) « Tout est lent après l’installation »

Syndromes : latence élevée, gels sporadiques, services en timeout, mais CPU normal.

Cause racine : pilote contrôleur de stockage générique, cache d’écriture mal configuré, ou RAID en cours d’initialisation avec performance dégradée.

Correctif : Installer les pilotes/outils fournisseur, vérifier cache + BBU/flash, confirmer le statut d’initialisation RAID, mesurer les compteurs de latence disque et les journaux du contrôleur.

2) « L’adhésion au domaine fonctionne, mais l’authentification est instable »

Syndromes : erreurs Kerberos, RDP refusé, GPO incohérente, Test-ComputerSecureChannel échoue de façon intermittente.

Cause racine : dérive horaire ou mauvaise configuration DNS (DNS public sur un membre de domaine, mauvaise liste de suffixes ou enregistrements obsolètes).

Correctif : Corriger les serveurs DNS en internes, exécuter w32tm /resync, valider la hiérarchie temporelle des DC, nettoyer et réenregistrer les enregistrements DNS.

3) « Les ports étaient ouverts hier, bloqués aujourd’hui »

Syndromes : l’appli fonctionne sur un réseau mais pas un autre ; le pare-feu semble incohérent.

Cause racine : le profil réseau a basculé (Domain vs Public) dû à NLA/problèmes de reachabilité DNS/DC ; les règles du pare-feu étaient limitées au profil Domain seulement.

Correctif : Restaurer la détection réseau de domaine (reachabilité DNS/DC), scoper les règles correctement et éviter de construire des règles qui ne fonctionnent que quand tout est parfait.

4) « L’espace disque disparaît sur C: »

Syndromes : C: se remplit, mises à jour échouent, serveur instable.

Cause racine : croissance du magasin de composants, journaux/dumps, fichiers temporaires, ou applications qui écrivent sur la volume OS parce que les valeurs par défaut n’ont pas été changées.

Correctif : Déplacer données/logs applicatives vers le volume de données, redimensionner C: si nécessaire, implémenter rotation/forwarding des logs et définir des alertes d’espace libre.

5) « Les sauvegardes réussissent mais les restaurations échouent »

Syndromes : job de sauvegarde vert, mais erreurs de restauration ou données restaurées incomplètes.

Cause racine : identifiants/permissions non validés, paramètres VSS/application-aware incorrects, ou dépôt de sauvegarde inaccessible en conditions d’incident.

Correctif : Faire des tests de restauration, valider les writers VSS, assurer l’accès au dépôt avec des identifiants séparés, documenter le runbook de restauration.

6) « Nous n’avons pas de journaux pendant la fenêtre d’incident »

Syndromes : Observateur d’événements sans rien d’utile ; journal Security écrasé ; trous dans la télémétrie.

Cause racine : tailles de journaux par défaut, comportement d’écrasement et absence de forwarding.

Correctif : Augmenter les tailles des journaux, forwarder centralement et ajouter des alertes quand les journaux approchent la capacité ou que le forwarding échoue.

Trois mini-histoires du monde de l’entreprise (ce qui arrive réellement)

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

Ils ont construit une nouvelle VM Windows Server 2022 pour héberger une petite application web interne. L’ingénieur a supposé, raisonnablement, que « le DNS est correct » parce que la VM pouvait résoudre des domaines publics. L’appli est mise en production et a immédiatement commencé à faire des timeouts quand elle essayait d’authentifier des utilisateurs.

L’équipe a cherché dans les logs applicatifs, puis dans les paramètres IIS, puis a réécrit une partie de la configuration. Rien de concluant. C’était intermittent, ce qui est le type de panne le plus coûteux.

Finalement, quelqu’un a exécuté Resolve-DnsName pour les enregistrements SRV du domaine et a obtenu du nonsense. La VM avait été pointée vers un résolveur public « temporairement » pendant la construction. Le DNS public ne peut pas répondre aux enregistrements de service internes AD. Kerberos a basculé, puis échoué, puis réussi selon le cache et le chemin de code exécuté.

La correction a été douloureusement simple : mettre les DNS vers les résolveurs du domaine, vider les caches, réenregistrer, confirmer la synchronisation horaire, et l’appli est redevenue banale. La leçon du postmortem n’était pas « le DNS compte ». C’était « prouver les dépendances avec des commandes, pas des hypothèses ».

Mini-histoire 2 : Une optimisation qui s’est retournée contre eux

Une migration de serveur de fichiers prenait du retard. Pour accélérer, quelqu’un a activé un cache d’écriture agressif et une poignée de réglages « performance » recommandés dans un forum de 2016. Les benchmarks étaient fantastiques. Tout le monde s’est détendu.

Deux semaines plus tard, il y a eu un court événement d’alimentation dans le rack. Pas une grosse panne — juste assez pour faire sauter une PDU. Les serveurs sont revenus. Le serveur de fichiers aussi, mais les utilisateurs ont commencé à signaler des fichiers corrompus et des « documents qui ne s’ouvrent pas ».

Le cache du contrôleur de stockage n’avait pas de protection adéquate contre la perte d’alimentation configurée. La configuration était possible, mais le module batterie était en état dégradé et les alarmes avaient été ignorées parce que « ça marche encore ». Le cache d’écriture est devenu un accélérateur de corruption des données.

La récupération a pris des jours de restaurations et de conversations embarrassantes. L’équipe a appris une vérité ennuyeuse : la performance est une fonctionnalité seulement quand l’intégrité est garantie. Si vous ne pouvez pas expliquer le mode de défaillance d’un changement de tuning, vous n’avez pas le droit de l’utiliser en production.

Mini-histoire 3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Un hôte Windows Server 2022 exécutant un service métier critique a fait un blue-screen deux fois en une semaine. Le fournisseur demandait des dumps et des journaux d’événements. Historiquement, c’est là que l’histoire finit par « on ne peut pas le reproduire » et une longue attente.

Mais cette équipe avait une politique terne : journaux dimensionnés, crash dumps activés et un agent qui envoyait les preuves hors de la machine. Ils avaient aussi un bundle d’incident standard : build OS, versions des pilotes, mises à jour récentes et événements du contrôleur de stockage.

Quand le troisième crash est arrivé, ils avaient déjà les dumps et l’historique des pilotes. Le pattern s’alignait sur une version spécifique de pilote NIC et un problème connu déclenché sous charge. Revenir au pilote précédent et planifier une mise à jour testée a résolu le problème.

Pas d’héroïsme. Pas de conjectures. Juste le genre de préparation qui paraît inutile jusqu’à ce qu’elle vous sauve la semaine.

FAQ

1) Dois-je installer Server Core ou Desktop Experience ?

Installez Server Core sauf si vous avez un blocage concret. Core réduit la surface de correctif et supprime beaucoup d’entropie liée à l’interface graphique. Si vos opérations dépendent encore d’outils GUI, utilisez Desktop Experience mais planifiez d’automatiser et de standardiser pour réduire cette dépendance.

2) Quelle taille pour le lecteur C: ?

Assez grand pour ne jamais y penser pendant un patch ou un crash. En pratique : allouez une marge significative pour les mises à jour, la croissance du magasin de composants, les journaux et les fichiers de dump. Si vous êtes virtualisé, vous pouvez étendre plus tard, mais le « plus tard » arrive souvent en plein incident.

3) NTFS ou ReFS pour les volumes de données ?

Par défaut NTFS sauf si vous pouvez justifier ReFS pour votre rôle spécifique et avez validé le support des fonctionnalités. ReFS peut être excellent dans certains scénarios de virtualisation et d’intégrité, mais ce n’est pas une amélioration universelle.

4) Dois-je installer les pilotes fournisseur, ou les pilotes Windows suffisent-ils ?

En production, envisagez fortement les pilotes/firmwares NIC et stockage fournisseur, surtout sur des serveurs physiques. Les pilotes inbox sont conçus pour une large compatibilité, pas nécessairement pour la meilleure performance ou le meilleur rythme de correction de bugs pour votre matériel.

5) Quel est le moyen le plus rapide pour dire si le stockage est mon goulot ?

Vérifiez les compteurs de latence disque (Avg. Disk sec/Read et Write), puis corrélez avec les journaux d’événements pour des resets de contrôleur et avec les timeouts applicatifs. Une latence élevée avec un CPU normal est une signature classique.

6) Pourquoi la synchronisation horaire est-elle dans la checklist ? Ce n’est pas automatique ?

Ça l’est jusqu’au jour où ça ne l’est plus. La dérive horaire casse Kerberos et rend les journaux peu fiables. En virtualisé, la synchronisation hyperviseur peut se battre avec le temps Windows. Vérifiez la source réelle et la dernière synchronisation.

7) Comment dimensionner les journaux d’événements ?

Dimensionnez-les pour la réponse à incident, pas pour l’esthétique. Si votre journal Security est écrasé en quelques heures lors d’une période chargée, il est trop petit. Si vous forwardez centralement, gardez quand même des journaux locaux assez grands pour couvrir les coupures du forwarding.

8) Quel est le test de sauvegarde minimum après installation ?

Restaurer un fichier et valider qu’il s’ouvre. Si le serveur héberge une appli, effectuez un test de restauration application-consistent (ou au moins validez que les writers VSS sont sains) et confirmez que permissions et métadonnées survivent.

9) Dois-je bloquer le trafic sortant dans le pare-feu Windows ?

Pas le jour 1 sauf si vous avez la maturité processus pour le gérer. Bloquer la sortie peut être un excellent contrôle, mais nécessite des allow-lists disciplinées et des compétences de dépannage. Commencez par l’allow-list inbound et ajoutez les contrôles outbound délibérément.

10) Comment éviter la « dérive de configuration mystère » après l’installation ?

Joignez le domaine avec des baselines GPO intentionnelles, gérez la configuration avec l’automatisation quand possible, et gardez un enregistrement des rôles/fonctionnalités installés et des agents approuvés. La dérive arrive quand personne ne possède « le standard ».

Conclusion : étapes suivantes dont vous vous remercierez

Après une nouvelle installation, votre objectif n’est pas « ça démarre ». Votre objectif est « c’est diagnostiquable, patchable, récupérable et ennuyeux ». Voilà la vraie définition de la stabilité.

Faites ceci ensuite :

1. Exécutez les tâches de validation ci-dessus et enregistrez les sorties comme preuve de base.
2. Redimensionnez les journaux d’événements et vérifiez le forwarding hors du serveur.
3. Prouvez les sauvegardes en restaurant quelque chose de réel.
4. Configurez la supervision pour la latence disque, l’espace libre et la santé des services avant que les utilisateurs trouvent des problèmes pour vous.
5. Documentez l’état final : configuration réseau, disposition du stockage, niveau de correctifs et toute déviation par rapport au standard.

Si vous faites ce travail maintenant, le prochain incident ne ressemblera pas à de l’archéologie. Ce sera de l’exploitation : observer, décider, réparer, et avancer.