Vous administrez un cluster NLB pour IIS sous Windows Server 2012 R2 et vous voulez migrer vers Windows Server 2019 sans interruption perceptible ? Voici un mode opératoire détaillé pour réussir une mise à niveau in‑place, nœud par nœud, en maîtrisant les risques techniques et la disponibilité.
Vue d’ensemble
Deux serveurs IIS opèrent derrière un équilibrage de charge Network Load Balancing (NLB) en haute disponibilité. L’objectif : mettre à niveau chacun des nœuds de 2012 R2 vers 2019, l’un après l’autre, tout en garantissant la continuité de service, la compatibilité applicative et la sécurité. Les interrogations portent sur l’impact pour les utilisateurs, les risques (réplication AD, authentification, pilotes, modules IIS, réseau), ainsi que les bonnes pratiques.
Réponse et stratégie recommandée
- La mise à niveau in‑place 2012 R2 → 2019 est supportée et conserve rôles, paramètres et données. Toutefois, une installation “propre” reste la référence en termes de fiabilité. Ici, nous décrivons une démarche rolling robuste pour l’in‑place upgrade.
- Indisponibilité : quasi nulle si vous retirez proprement un nœud avec
drainstop(les sessions actives se terminent) avant d’appliquer l’upgrade, l’autre nœud continuant à servir la charge. - Pré‑requis impératifs : sauvegardes complètes, tests en recette/VM clonée, compatibilité pilotes NIC et antivirus, vérification du mode NLB (unicast/multicast) et de l’affinité.
- Plan B clair : image système ou sauvegarde bare‑metal, sauvegarde IIS, export des certificats et configuration NLB, procédure de restauration documentée et testée.
Chemin de mise à niveau et support
Microsoft prend en charge la mise à niveau sur place de Windows Server 2012 R2 vers Windows Server 2019. Le processus conserve les rôles installés (IIS, NLB), les comptes de service, les certificats et la configuration réseau. En contrepartie, une in‑place upgrade transporte l’historique du système : pilotes, clés de registre héritées et logiciels tiers peuvent influer sur la stabilité. Si un serveur fait aussi office de contrôleur de domaine, appliquez scrupuleusement l’ordre de mise à niveau Active Directory et sauvegardez l’état du système.
Sauvegardes, tests et prérequis
| Volet | Actions recommandées | Validation attendue |
|---|---|---|
| Sauvegardes | Image système/bare‑metal, données applicatives, System State si AD, export IIS (appcmd), export certificats en .pfx. | Restauration testée (VM de labo), mot de passe PFX confirmé. |
| Capacité | Confirmer que le nœud restant peut absorber 100 % de la charge durant la maintenance. | Tests de charge ciblés sans dégradation majeure. |
| Périmètre | Inventorier modules IIS (ARR, URL Rewrite, compression), agents (antivirus, EDR), drivers NIC, dépendances applicatives. | Versions compatibles Windows Server 2019 disponibles. |
| NLB | Relever VIP, port rules, affinité (AUCUNE/SINGLE/CLASS C), mode unicast/multicast, état de convergence. | Convergence OK, documentation prête pour reconstruction si besoin. |
| Hyperviseur | Pour VMs, vérifier paramètres réseau spécifiques à NLB (ex. MAC spoofing sous Hyper‑V, politiques VMware). | Conformité confirmée sur le nœud en production. |
Commandes utiles pour préparer
# Vérifier rôles/Features installés
Get-WindowsFeature | ? Installed
# Sauvegarde IIS
& "$env:windir\system32\inetsrv\appcmd.exe" add backup "pre-upgrade"
# Export des sites et appPools (optionnel)
& "$env:windir\system32\inetsrv\appcmd.exe" list site /config /xml > C:\IIS\sites.xml
& "$env:windir\system32\inetsrv\appcmd.exe" list apppool /config /xml > C:\IIS\apppools.xml
# Export certificats (exemple)
$pwd = ConvertTo-SecureString "MotDePassePFXFort" -AsPlainText -Force
Get-ChildItem Cert:\LocalMachine\My | ForEach-Object {
$thumb = $_.Thumbprint
Export-PfxCertificate -Cert "Cert:\LocalMachine\My$thumb" -FilePath "C:\Certs$thumb.pfx" -Password $pwd
}
# Module NLB (si absent, ajouter la fonctionnalité "NLB" + outils de gestion)
Import-Module NetworkLoadBalancingClusters
Get-NlbCluster | Format-List *
Get-NlbClusterNode | Select HostName, InterfaceName, State
Get-NlbClusterPortRule Approche rolling upgrade avec NLB
Le principe : isoler un nœud, laisser les sessions actives se terminer (drainstop), effectuer la mise à niveau, valider et réintégrer le nœud, puis répéter sur le second. Contrairement à un stop brutal, drainstop évite de couper des transactions en cours (paiement, téléchargement, formulaires). Le trafic est maintenu par l’autre serveur.
Impact sur la disponibilité
- Sessions HTTP stateless (contenu statique/API idempotente) : impact nul.
- Sessions avec état en mémoire (InProc) : conservez une affinité NLB adaptée (SINGLE par exemple) et laissez un délai de drainage suffisant.
- Sessions centralisées (StateServer/SQL) : aucun impact notable, prévoir tout de même un délai de drainage.
Procédure détaillée pas à pas
Préparation juste avant la fenêtre
- Confirmer l’état de santé de l’application et la convergence NLB.
- Mettre à jour l’antivirus/EDR compatible 2019 et désactiver les protections “auto‑remédiation” intrusives pendant l’upgrade.
- Vérifier que les certificats TLS et les bindings IIS sont bien sauvegardés.
- Informer supervision et support : trafic temporairement en n-1 nœud.
Isolation du nœud A
Au choix : GUI NLB Manager ou PowerShell.
# Drainer le nœud A
Import-Module NetworkLoadBalancingClusters
$nodeA = Get-NlbClusterNode -HostName "NODE-A"
$nodeA | Stop-NlbClusterNode -Drain
# Suivre l'état
do {
Start-Sleep -Seconds 5
$state = (Get-NlbClusterNode -HostName "NODE-A").State
Write-Host "Etat actuel: $state"
} until ($state -eq "Stopped" -or $state -eq "Suspended") Attendez la fin des sessions longues (téléchargements, batchs). Vérifiez via vos métriques applicatives (connexions actives, requêtes/s).
Mise à niveau in‑place du nœud A
- Monter l’ISO de Windows Server 2019 et lancer
setup.exe. - Choisir Conserver fichiers, paramètres et applications.
- Appliquer les mises à jour dynamiques si proposé. Prévoir plusieurs redémarrages.
- Après la montée, vérifier la version (
winverouGet-ComputerInfo).
Validation post‑upgrade du nœud A
- Rôles/Features :
Get-WindowsFeaturepour confirmer IIS et NLB. - Modules IIS : réinstaller si nécessaire URL Rewrite, ARR, compresseurs Gzip/Brotli, agents APM.
- Certificats et bindings : contrôler
netsh http show sslcertet les site bindings IIS. - Réseau : pilotes NIC, VLAN, teaming/LBFO ou SET, MTU, offloads. S’assurer que le mode NLB (unicast/multicast) est inchangé.
- Journalisation : vérifier l’absence d’erreurs critiques dans Observateur d’événements (Système, Application, Microsoft‑Windows‑IIS‑Logging).
- Fonctionnel : exécuter votre smoke test (URL de santé, authentification, upload, cache, compression, HTTP/2 si utilisé).
Réintégration du nœud A
# Démarrer le nœud A dans le cluster
Start-NlbClusterNode -HostName "NODE-A"
# Vérifier la convergence et la répartition de charge
Get-NlbClusterNode | Select HostName, State
Get-NlbClusterPortRule Surveillez quelques minutes la stabilité (logs, métriques, latence). Lorsque tout est nominal, répétez la même séquence pour le nœud B.
Tableau de marche opérationnel
| Étape | Objectif | Points de contrôle | Sortie/Évidence |
|---|---|---|---|
| Pré‑upgrade | Sauvegardes, inventaire, compatibilité | Backups valides, espace disque > 20 % | Rapport d’inventaire, captures appcmd, exports PFX |
| Drainstop nœud A | Éviter les coupures de session | État nœud A = Stopped/Suspended | Écran NLB Manager, sortie PowerShell |
| Upgrade nœud A | Passage en 2019 | Setup OK, reboot final | winver, Get-ComputerInfo |
| Validation A | Qualité technique et fonctionnelle | Tests OK, absence d’erreurs critiques | Journal de tests, captures Observateur |
| Réintégration A | Retour en production | Convergence OK, trafic équilibré | Métriques NLB/IIS |
| Répétition B | Montée du second nœud | Mêmes contrôles que pour A | Dossier de preuve complété |
Commandes NLB et IIS de référence
| Tâche | GUI | PowerShell | Remarques |
|---|---|---|---|
| Drainer un nœud | NLB Manager → Control Host → Drainstop | Stop-NlbClusterNode -HostName "NODE-A" -Drain | Attendre la fin des connexions actives |
| Démarrer un nœud | NLB Manager → Control Host → Start | Start-NlbClusterNode -HostName "NODE-A" | Vérifier la convergence |
| État des nœuds | NLB Manager → Affichage | Get-NlbClusterNode \| Select HostName,State | Doit être Converged/Started |
| Sauvegarde IIS | IIS Manager → Server → Backups | appcmd add backup "pre-upgrade" | Permet un retour rapide |
| Liste des bindings | IIS Manager → sites → bindings | appcmd list site /config | Comparer avant/après |
Points de vigilance techniques
- Contrôleurs de domaine : si un nœud héberge AD DS, respectez l’ordre de mise à niveau, le niveau fonctionnel et exécutez une sauvegarde de l’état du système. Évitez les clichés instantanés non coordonnés.
- Pilotes réseau : installez des versions certifiées pour 2019 (cartes physiques ou vNIC). Validez offloads (RSS, RSC, TOE), jumbo MTU si utilisé, et teaming (LBFO/SET).
- Mode NLB : en unicast, le changement d’OS peut réinitialiser l’adresse MAC virtuelle ; en multicast, vérifiez les entrées ARP statiques et la configuration des commutateurs/routeurs.
- Hyper‑V/VMware : avec NLB, certains environnements exigent l’activation du MAC spoofing (Hyper‑V) ou des politiques de sécurité spécifiques (VMware). Alignez les deux nœuds.
- IIS 8.5 → IIS 10 : HTTP/2 sur TLS, changements de suites chiffrées et paramètres Schannel. Vérifiez la compatibilité des clients et librairies (TLS 1.2/1.3).
- Antivirus/EDR : utilisez des exclusions officielles pour IIS (
%SystemRoot%\System32\inetsrv,%SystemDrive%\inetpub, logs) et réactivez les protections après validation. - Fin de support 2012 R2 : profitez de l’opération pour planifier le passage vers 2022/2025 ou une réinstallation propre à plus court terme.
Plan de test et critères d’acceptation
| Test | Méthode | Succès attendu |
|---|---|---|
| URL de santé | Appel /health//status depuis chaque nœud et via la VIP | HTTP 200, latence stable |
| Authentification | NTLM/Negotiate/Basic selon contexte | Connexion sans erreurs, tickets valides |
| Upload/Download | Fichier > 100 Mo | Aucun reset, débit correct |
| Affinité NLB | Requêtes successives d’un même client | Colle au même nœud si requis |
| Compression/Cache | Vérifier en-têtes, tailles, Vary | Comportement identique à avant |
| Journaux | Analyse logs IIS/Windows | Absence d’erreurs critiques |
Plan de retour arrière
- Avant l’upgrade : valider une restauration complète en labo (image système/bare‑metal, sauvegarde IIS, PFX, scripts).
- En cas d’échec : retirer à nouveau le nœud via
drainstop(si encore dans le cluster), restaurer l’image 2012 R2 ou réinstaller proprement, puis ré‑joindre le cluster. - Après retour : analyser la cause racine (pilote, module, GPO, sécurité) avant de retenter.
Spécificités IIS à connaître
- AppCmd Backups : outre la sauvegarde, vous pouvez
appcmd restore backup "pre-upgrade"si la configuration diffère. - Web.config : attention aux handlers, modules non natifs et directives obsolètes.
- Modules : réinstaller URL Rewrite, ARR et modules custom compatibles 2019.
- Logs : chemins ou formats personnalisés ? Assurez-vous que l’outil d’ingestion (SIEM, APM) supporte l’environnement post‑migration.
Bonnes pratiques de sécurité post‑upgrade
- Appliquer les mises à jour cumulatives de Windows Server 2019 et d’IIS immédiatement après validation fonctionnelle.
- Vérifier les protocoles et suites TLS activés, forcer TLS 1.2/1.3 si possible.
- Revoir les ACL des répertoires applicatifs, les droits des app pools et les stratégies d’audit.
- Réactiver et valider l’antivirus/EDR avec les bonnes exclusions.
NLB : unicast, multicast et affinité
| Aspect | Unicast | Multicast | Points clés |
|---|---|---|---|
| MAC virtuelle | Remplace la MAC du NIC | MAC supplémentaire | Sur upgrade, vérifier la persistance de la MAC et les politiques de commutation |
| Réseau | Peut nécessiter ports dédiés/switch config | Peut nécessiter ARP statiques | Aligner la configuration des deux nœuds |
| Affinité | AUCUNE, SINGLE, CLASS C : choisissez selon la gestion de session | Sessions InProc : privilégier SINGLE | |
Automatiser les contrôles
Un script minimal pour tracer les étapes et éviter les oublis :
# Variables
$Node = "NODE-A"
$BackupName = "pre-upgrade"
$Log = "C:\Upgrade\$Node-$(Get-Date -f yyyyMMdd-HHmm).log"
New-Item -ItemType Directory -Force -Path (Split-Path $Log) | Out-Null
# Journalisation
"=== Début $(Get-Date) ===" | Tee-Object -FilePath $Log
try {
Import-Module NetworkLoadBalancingClusters
"Sauvegarde IIS..." | Tee-Object -FilePath $Log -Append
& "$env:windir\system32\inetsrv\appcmd.exe" add backup $BackupName
"Etat cluster avant drainage:" | Tee-Object -FilePath $Log -Append
Get-NlbClusterNode | Select HostName,State | Tee-Object -FilePath $Log -Append
"Drainstop du nœud $Node..." | Tee-Object -FilePath $Log -Append
Get-NlbClusterNode -HostName $Node | Stop-NlbClusterNode -Drain
do {
Start-Sleep 5
$state = (Get-NlbClusterNode -HostName $Node).State
"Etat: $state" | Tee-Object -FilePath $Log -Append
} until ($state -ne "Started")
"==> Effectuez maintenant l'upgrade OS via setup.exe" | Tee-Object -FilePath $Log -Append
} catch {
"ERREUR: $($_.Exception.Message)" | Tee-Object -FilePath $Log -Append
} finally {
"=== Fin $(Get-Date) ===" | Tee-Object -FilePath $Log -Append
} FAQ rapide
Peut‑on vraiment éviter toute coupure ?
Avec drainstop, une capacité suffisante sur le nœud restant et une affinité adaptée, les utilisateurs ne voient généralement pas de coupure. Les sessions très longues peuvent prolonger le temps de drainage.
Faut‑il réinstaller NLB/IIS après upgrade ?
Non en principe : ils sont conservés. Mais validez que la feature NLB est bien présente et que les modules IIS tiers sont compatibles 2019.
Et si un pilote NIC n’est pas compatible ?
Installez la version 2019 fournie par l’éditeur. En dernier recours, revenez au nœud sain et appliquez le plan de retour arrière.
Pourquoi ne pas tout refaire “propre” ?
La réinstallation offre la meilleure hygiène technique (moins de dettes). Quand le contexte le permet, elle demeure la voie royale, quitte à migrer ensuite la configuration IIS et les certificats.
Résumé opérationnel
- Réaliser des sauvegardes complètes et tester leur restauration.
- Drainer proprement un nœud NLB (
drainstop) et vérifier la convergence. - Exécuter l’in‑place upgrade vers Windows Server 2019.
- Valider techniquement et fonctionnellement (IIS, certificats, réseau, sécurité).
- Réintégrer le nœud, observer la stabilité, puis répéter sur le second.
En appliquant cette méthode et en documentant chaque étape, vous obtiendrez une montée de version sécurisée, réversible et avec quasi‑zéro interruption pour vos utilisateurs.
Annexe : check‑list prête à l’emploi
- [ ] Sauvegardes système, données, IIS, certificats PFX
- [ ] Espace disque > 20 %, mises à jour préalables appliquées
- [ ] Compatibilité pilotes NIC, modules IIS, antivirus/EDR
- [ ] Inventaire NLB : VIP, port rules, affinité, mode
- [ ] Validation capacité en n‑1 nœud
- [ ] Fenêtre de maintenance & communication
- [ ] Script de drainage prêt, journalisation OK
- [ ] Plan de tests et critères d’acceptation définis
- [ ] Plan de retour arrière éprouvé en labo