Vous administrez un Windows Server 2016 entièrement à jour et vous vous demandez ce qui se passe si vous tentez d’y installer manuellement une mise à jour cumulative (LCU) plus ancienne. Voici une analyse détaillée, fondée sur le fonctionnement réel du moteur de maintenance Windows.
Contexte et portée
Windows Server 2016 (version 1607) suit un modèle de maintenance cumulatif. Chaque nouvelle LCU inclut les correctifs précédents et peut nécessiter la présence de la dernière Servicing Stack Update (SSU). Dans un serveur déjà à jour via Windows Update, l’introduction d’une LCU antérieure interagit avec le moteur CBS (Component‑Based Servicing), l’outil DISM et l’installateur autonome wusa. Comprendre cette interaction permet d’évaluer les risques, d’anticiper les messages d’erreur et d’appliquer les bonnes pratiques de production.
Vue d’ensemble de la question
Un administrateur dispose d’un Windows Server 2016 à jour via Windows Update et souhaite savoir ce qui se passerait s’il tentait d’installer manuellement une mise à jour cumulative (LCU) plus ancienne.
Il s’interroge notamment sur :
- Les risques de conflits avec des composants déjà mis à jour.
- Le mécanisme de détection automatique des versions de fichiers.
- Les conséquences possibles sur la stabilité et les performances.
- Les bonnes pratiques préconisées par Microsoft.
Réponse & solution
Point clé | Explication |
---|---|
Architecture cumulative | Les LCUs sont supersédées les unes par les autres : chaque nouvelle LCU contient la totalité des correctifs précédents. |
Tentative d’installation d’une LCU plus ancienne | Avec wusa ou DISM , le système renvoie en général « Cette mise à jour n’est pas applicable à votre système » ; aucun binaire plus récent n’est rétrogradé. Si l’installation est « forcée » dans un scénario atypique, le moteur CBS conserve les versions les plus élevées ; les plus anciennes sont ignorées au moment de la staging/render/commit. |
Conflits & stabilité | La logique de versionnement et de supersédance empêche qu’une version antérieure remplace une version plus récente. Les risques de régression sont donc très faibles. |
Performances | L’opération se termine vite (échec d’applicabilité ou copies minimales). Aucun impact mesurable et durable sur les performances. |
Bonnes pratiques Microsoft | Installer uniquement la dernière LCU disponible (elle inclut tout). Vérifier/installer la SSU la plus récente avant toute LCU, surtout dans les environnements où SSU et LCU sont distribuées séparément. Pour revenir à une LCU plus ancienne : désinstaller d’abord la LCU récente, puis installer la version souhaitée (uniquement en test/dépannage). |
Vérifications utiles | DISM /Online /Get-Packages /Format:Table pour lister les mises à jour et leurs états (Installed, Superseded, Staged). Analyse des CBS.log et DISM.log en cas d’échec d’installation. |
Information complémentaire | Redémarrage : même lorsqu’une LCU plus ancienne est « non applicable », un redémarrage peut être sollicité si des opérations sont en attente (catalogues, composants en file d’attente). Planifier hors production. Sauvegarde : conserver une image/snapshot avant tout scénario de rétro‑patching. |
Comment Windows décide qu’une LCU est « applicable »
Le moteur de maintenance Windows (CBS) s’appuie sur des manifests et des catalogues (fichiers .mum
et .cat
) pour évaluer l’applicabilité d’un package. Les étapes clés :
- Détection : l’identité du package (nom, version, architecture, culture) est lue. La pile de maintenance compare les identities avec celles déjà présentes dans le magasin WinSxS.
- Évaluation de supersédance : si la LCU présentée est supersedée par une LCU déjà installée, le package est marqué NotApplicable.
- Comparaison de version : pour chaque composant, la version est comparée ; la version la plus élevée l’emporte (highest‑version wins), évitant tout downgrade.
- Staging/Commit : si applicable, les payloads sont copiés en staging puis validés au redémarrage. Sinon, l’installation s’arrête proprement.
Signatures et composants
Une LCU comporte :
- Un catalogue signé (
.cat
) vérifié par la pile de maintenance. - Des manifests (
.mum
) qui décrivent les composants, dépendances et relations de supersédance. - Des payloads (binaires), déposés en magasin WinSxS et projetés dans le système actif selon les règles CBS.
Si les manifests indiquent qu’un composant livré est plus ancien que celui présent, il n’est ni projeté ni activé.
Ce qui se passe concrètement si vous lancez une LCU plus ancienne
- Avec wusa (.msu) : l’assistant se lance, calcule l’applicabilité et retourne un message proche de « Cette mise à jour n’est pas applicable à votre système ». Aucun fichier système n’est rétrogradé.
- Avec DISM (.cab ou .msu) :
DISM /Online /Add-Package
lit les manifests, constate la supersédance et inscrit dansDISM.log
etCBS.log
que le package est non applicable (NotApplicable). - Effets visibles : parfois un très court « staging » de meta‑données, puis arrêt. Un redémarrage peut être demandé si des opérations étaient déjà en attente (non pas à cause de la LCU ancienne elle‑même mais à cause de l’état du système au moment de l’essai).
Codes d’erreur fréquents et interprétation
Message / Code | Signification | Action recommandée |
---|---|---|
WU_E_NOT_APPLICABLE (0x80240017) | La mise à jour est supplantée ou ne correspond pas à l’édition/architecture. | Confirmer que le serveur est déjà à jour ; installer la LCU la plus récente uniquement. |
CBS_E_NOT_APPLICABLE (0x800F081E) | Le package ne s’applique pas à l’image en ligne (NotApplicable). | Vérifier les packages avec DISM ; ne pas poursuivre le rétro‑patching. |
0x800F0922 | Échec lors du commit (cas divers : espace, configuration, etc.). | Consulter CBS.log /DISM.log , vérifier l’espace disque et les prérequis. |
Conséquences sur la stabilité et les performances
Dans un serveur déjà entièrement à jour :
- Stabilité : très peu de risque de régression, car les binaires plus anciens ne remplacent pas les plus récents. Le moteur CBS protège la cohérence des composants.
- Performances : l’empreinte est limitée à l’évaluation d’applicabilité et, parfois, à une phase de staging très courte. Pas d’impact durable sur CPU, RAM ou I/O.
- Journalisation : seuls les logs (
CBS.log
,DISM.log
) croissent légèrement ; pensez au housekeeping si vous multipliez les tests.
Bonnes pratiques et gouvernance des correctifs
- Privilégier la dernière LCU : la plus récente contient tous les correctifs antérieurs et corrige les régressions connues.
- Servicing Stack Update (SSU) : assurez-vous d’avoir la SSU requise pour que l’installation de la LCU se déroule correctement, surtout sur des environnements qui n’ont pas adopté des packages combinés.
- Fenêtres de maintenance : testez en pré‑production, puis déployez par vagues (ex. anneaux pilote → généralisation), avec surveillance.
- Sauvegarde/snapshot : indispensable avant tout changement de niveau de patch, en particulier avant une désinstallation de LCU.
- Journalisation centralisée : collectez
CBS.log
,DISM.log
et l’événementiel pour corréler rapidement les échecs.
Procédures pas‑à‑pas
Vérifier l’état des packages
DISM /Online /Get-Packages /Format:Table
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
Ces commandes permettent d’inventorier les packages installés, d’identifier un magasin de composants corrompu et de lancer une réparation si nécessaire.
Tenter l’installation d’une LCU antérieure (pour test uniquement)
wusa.exe <chemin>\windows10.0-kbXXXXXXX-x64.msu /quiet /norestart
REM ou
DISM /Online /Add-Package /PackagePath:<chemin>\kbXXXXXXX.cab
Dans un système à jour, le résultat attendu est une non‑applicabilité, sans rétrogradation de fichiers.
Revenir à une LCU précédente (méthode contrôlée)
- Désinstaller la LCU actuelle :
wusa.exe /uninstall /kb:XXXXXXX /quiet /norestart
- Redémarrer si demandé.
- Installer la LCU cible (celle « plus ancienne »), puis redémarrer à nouveau.
Remarques importantes : certaines LCUs ne sont pas désinstallables selon les dépendances en place ; sur des rôles sensibles (ex. contrôleur de domaine, cluster), planifiez un basculement et validez en labo avant toute manipulation.
Vérifications et diagnostics
Objectif | Commande / Emplacement | Ce qu’il faut regarder |
---|---|---|
Inventorier les mises à jour | DISM /Online /Get-Packages | États Installed, Superseded, Staged; identités des KB. |
Lister les correctifs QFE | Get-HotFix (PowerShell) | Présence de la LCU actuelle (entrée « Security Update for Microsoft Windows »). |
Analyser le moteur CBS | C:\Windows\Logs\CBS\CBS.log | Mots‑clés : NotApplicable, Superseded, Install requested, Version. |
Vérifier DISM | C:\Windows\Logs\DISM\dism.log | Détails sur l’ajout/évaluation de packages, codes d’erreur. |
Reconstruire WindowsUpdate.log | Get-WindowsUpdateLog | Traçabilité du téléchargement/evaluation WU (si utilisé). |
Cas particuliers et points d’attention
- Images hors ligne : sur une image WIM hors ligne plus ancienne, l’ajout d’une LCU antérieure peut être acceptable si la chaîne de supersédance y correspond. Ce n’est pas transposable à un serveur déjà à jour.
- Server Core vs Desktop Experience : l’applicabilité dépend des composants installés. Une LCU peut être « applicable » à une édition et pas à une autre si des fonctionnalités ne sont pas présentes.
- Langues supplémentaires : installer les packs de langue avant la LCU cible pour éviter les incohérences de ressources.
- Espaces disques : même si l’installation échoue vite, assurez une marge pour les opérations de staging/log.
- Clusters & HA : appliquez les LCUs par nœud avec drain/évacuation de rôles et vérification d’état avant de poursuivre.
- Nettoyage du magasin de composants :
DISM /Online /Cleanup-Image /AnalyzeComponentStore
puis, si pertinent,/StartComponentCleanup
pour réduire l’empreinte WinSxS (à faire en maintenance planifiée).
FAQ rapide
Installer une LCU plus ancienne peut‑il casser des pilotes ou services ?
Non, la logique de supersédance empêche la rétrogradation de fichiers système. Les pilotes tiers ne sont pas remplacés par une LCU antérieure.
Puis‑je « forcer » l’installation ?
Forcer n’apporte rien : CBS ignore les versions inférieures. Vous obtenez au mieux un package marqué Superseded ou NotApplicable.
Dois‑je toujours installer la SSU avant ?
Oui, c’est une bonne pratique. Sans la SSU requise, la LCU récente peut échouer. Dans notre scénario (LCU antérieure), cela n’améliore pas l’applicabilité mais sécurise la pile de maintenance.
Pourquoi un redémarrage est parfois demandé alors que l’installation échoue ?
Le redémarrage peut être lié à des opérations en attente antérieures (autres correctifs) ou à des locks libérés uniquement au reboot. Ce n’est pas l’ancienne LCU qui impose un cycle lourd.
Résumé exécutif
Sur un Windows Server 2016 pleinement à jour, tenter d’installer une LCU antérieure aboutit quasi systématiquement à une non‑applicabilité. Le moteur CBS, en s’appuyant sur les manifests et la supersédance, protège contre les rétrogradations. L’impact opérationnel est négligeable (évaluation courte, pas de régression), mais on conserve les bonnes pratiques : déployer uniquement la dernière LCU, vérifier la SSU, planifier des fenêtres de maintenance et conserver des sauvegardes. Les outils de diagnostic (DISM, CBS.log) apportent la visibilité nécessaire si vous devez justifier le comportement observé auprès des équipes sécurité ou conformité.
Modèle d’exécution recommandé en production
- Évaluer : identifier la LCU cible approuvée, ses prérequis (SSU) et l’état actuel du serveur.
- Valider en pré‑production : test d’applicabilité, vérification des rôles critiques (AD DS, DNS, Hyper‑V, IIS, SQL Server, etc.).
- Déployer : anneaux de patching, surveillance, retour d’expérience.
- Remédier : en cas de besoin de retour arrière, désinstaller la LCU récente avant d’installer l’ancienne cible. Documenter les codes d’erreur et les journaux.
- Optimiser : nettoyage du magasin, revue de la stratégie WSUS/WUfB, alignement des drivers/firmwares.
Exemples de commandes prêtes à l’emploi
:: Lister les packages installés avec leur état
DISM /Online /Get-Packages /Format:Table
:: Vérifier la santé du magasin de composants
DISM /Online /Cleanup-Image /ScanHealth
:: Réparer si nécessaire
DISM /Online /Cleanup-Image /RestoreHealth
:: Installer silencieusement une LCU (pour test)
wusa.exe D:\patches\windows10.0-kb1234567-x64.msu /quiet /norestart
:: Désinstaller une LCU récente avant un rollback
wusa.exe /uninstall /kb:1234567 /quiet /norestart
:: Générer le journal Windows Update
PowerShell -Command "Get-WindowsUpdateLog"
Conclusion
Le modèle cumulé de Windows Server 2016 est conçu pour empêcher les retours en arrière accidentels. Essayer d’installer une LCU plus ancienne sur un serveur à jour ne dégrade pas l’état du système : l’installation est refusée ou neutralisée par la supersédance. La ligne directrice reste donc simple : installer la dernière LCU prise en charge, avec la SSU adéquate, et ne recourir au rétro‑patching que dans des scénarios de test ou de dépannage dûment encadrés.