2026 : KB5126646 de Windows Server 2025 affecte-t-il les hôtes Hyper-V AMD ?

La mise à jour KB5126646 de Windows Server 2025 a été publiée le 13 octobre 2026 (historique des mises à jour Microsoft). Décision : ne considérez le problème AMD confirmé que si l’hôte ou le cluster est géré par SCVMM et rencontre un échec d’actualisation après les mises à jour d’octobre ; la notice Microsoft ne permet pas de conclure que tous les hôtes Hyper-V AMD sont touchés (avis Microsoft sur SCVMM). Vérifiez d’abord la version du système, la présence de la mise à jour et la relation avec SCVMM, puis appliquez uniquement les indications Microsoft en vigueur. Ne désinstallez pas systématiquement une mise à jour de sécurité.

Cet article s’adresse aux administrateurs de serveurs ou de clusters AMD gérés par SCVMM qui évaluent l’incidence des mises à jour d’octobre 2026.
Il est également destiné aux équipes qui investiguent un échec d’actualisation et doivent distinguer un problème de mise à jour de Windows d’un problème de gestion SCVMM.
Si vous préparez un serveur physique AMD sous Windows Server et Hyper-V, les critères de périmètre ci-dessous vous aideront à ne pas confondre ce cas avec une panne générale de l’hyperviseur.

KB5126646, Hyper-V et AMD : le périmètre confirmé

L’avis publié par Microsoft le 3 novembre 2026 décrit plusieurs incidences possibles des mises à jour mensuelles d’octobre dans des environnements SCVMM. Pour le cas AMD, le symptôme signalé concerne l’actualisation d’un hôte ou d’un cluster géré par SCVMM. La condition déterminante n’est donc pas seulement la présence d’un processeur AMD ou de Hyper-V : l’administration par SCVMM fait partie du scénario décrit par Microsoft (avis officiel).

Il faut également éviter de fusionner deux symptômes mentionnés dans la communication. L’échec d’actualisation associé aux hôtes AMD et le problème de transfert de modèles dans SCVMM ne constituent pas une seule et même panne. Le processeur, le rôle de l’hôte dans SCVMM, les mises à jour effectivement installées et le symptôme observé doivent être consignés séparément avant de choisir une intervention.

Cette distinction évite deux erreurs opérationnelles : attribuer à Windows un problème de gestion qui relève peut-être de SCVMM, et appliquer à un hôte autonome une mesure conçue pour un environnement géré. Les discussions de la communauté Hyper-V au cours d’octobre et de novembre peuvent signaler que d’autres administrateurs examinent le sujet ; elles ne définissent toutefois ni le périmètre officiel ni le correctif à appliquer.

KB5126646 peut-il affecter un hôte Hyper-V sans SCVMM ?

La documentation Microsoft fournie pour cet incident ne confirme pas que les hôtes Hyper-V indépendants sont concernés par le problème d’actualisation décrit pour les hôtes AMD gérés par SCVMM. L’absence de SCVMM ne prouve pas qu’aucun incident n’est possible après une mise à jour ; elle signifie que vous ne devez pas attribuer automatiquement un incident à ce scénario précis ni lui appliquer une solution réservée à SCVMM.

Si une machine virtuelle ne démarre plus, si sa gestion est instable ou si un hôte autonome présente une erreur, relevez d’abord le message exact, le moment de son apparition et les modifications récentes. Vérifiez ensuite les journaux pertinents et l’état des mises à jour. Recherchez une notice Microsoft qui correspond à la fois au système, au symptôme et à la configuration réellement utilisée, plutôt que de déduire une cause à partir du seul processeur AMD.

Une mise à jour ultérieure, KB5134137, figure dans l’historique de Windows Server 2025 à la date du 26 octobre 2026 (notice Microsoft pour KB5134137). Sa présence dans l’historique ne suffit pas à démontrer qu’elle corrige votre incident particulier. Pour connaître son applicabilité et l’état du problème, confrontez la notice de cette mise à jour à l’avis SCVMM et aux informations Microsoft les plus récentes.

Comment vérifier la présence de KB5126646 ?

Commencez sur l’hôte concerné, pas sur une console d’administration supposée refléter l’état de toutes les machines. Dans l’interface de Windows Server, ouvrez Paramètres, puis Windows Update et Historique des mises à jour. Notez la mise à jour cumulative affichée, son état et la date indiquée ; un affichage incomplet ou une erreur d’installation doit être consigné comme tel, et non interprété comme une confirmation que la mise à jour est absente.

Vous pouvez ensuite vérifier les correctifs visibles par PowerShell. La documentation Microsoft précise l’usage de Get-HotFix pour interroger les correctifs enregistrés par le système (référence de Get-HotFix) :

Get-HotFix -Id KB5126646

Une sortie contenant le numéro recherché indique que cette entrée de correctif est présente dans les résultats de la commande. Une absence de résultat ne suffit pas à conclure que le serveur n’a reçu aucune mise à jour cumulative : comparez l’historique Windows Update, l’état de maintenance et la notice Microsoft de KB5126646 (notice de la mise à jour KB5126646). Conservez les sorties et les captures d’écran dans le dossier de diagnostic.

Les commandes doivent être exécutées avec les droits nécessaires et dans le contexte d’administration approprié. Get-SCVMHost est une commande du module Virtual Machine Manager ; elle n’est pas disponible sur un serveur qui n’a pas accès aux composants d’administration correspondants. La documentation décrit les paramètres et les résultats de cette commande (documentation Microsoft de Get-SCVMHost).

Un échec d’actualisation d’un hôte AMD vient-il forcément de Windows Server 2025 ?

Non. Le fait qu’un hôte AMD échoue à s’actualiser rend l’avis pertinent seulement si les autres conditions correspondent, notamment la gestion par SCVMM et l’installation des mises à jour concernées. Une panne de communication, un état incohérent dans l’inventaire SCVMM, un problème intervenu lors d’une opération distincte ou une autre mise à jour peuvent nécessiter une investigation différente. Les éléments disponibles ne justifient ni une estimation de la fréquence de l’incident ni une durée de rétablissement garantie.

Pour distinguer ces pistes, comparez les versions des hôtes, les états remontés par SCVMM et la chronologie des opérations. Si seul un hôte est concerné, cherchez les différences de configuration ou d’état avec les autres hôtes gérés ; si plusieurs hôtes présentent le même symptôme après une mise à jour, consignez les éléments communs sans transformer cette corrélation en preuve de causalité. Dans les deux cas, ne remplacez pas de fichiers système et ne suivez pas une procédure communautaire non confirmée par Microsoft.

Première étape : figer les éléments avant toute modification

Avant de modifier un hôte ou de retirer une mise à jour, rassemblez des éléments qui permettront de comparer l’état initial et l’état après intervention. Une sauvegarde ou une exportation de la configuration utile à votre environnement doit précéder les changements ; vérifiez également que vous disposez d’une procédure de retour arrière réellement exploitable. La recommandation générale de Microsoft pour les problèmes liés aux mises à jour consiste à collecter les informations de diagnostic et à suivre une démarche adaptée au problème, plutôt qu’à appliquer une désinstallation indifférenciée (guide Microsoft de dépannage des mises à jour Windows Server).

Utilisez la liste de contrôle suivante pour décider de la suite :

• [ ] Confirmez le nom du serveur, le système installé et le numéro de build ; consignez-les avant toute intervention.
• [ ] Vérifiez sur l’hôte l’historique Windows Update et recherchez KB5126646 avec PowerShell ; conservez les résultats, y compris si la recherche ne renvoie aucune ligne.
• [ ] Confirmez dans la console SCVMM si l’hôte est effectivement géré et si l’incident correspond à une opération d’actualisation.
• [ ] Distinguez l’actualisation d’un hôte ou d’un cluster d’un échec de transfert de modèle ; notez le texte d’erreur précis pour chaque symptôme.
• [ ] Comparez l’avis SCVMM, l’historique Windows Server 2025 et la notice de toute mise à jour ultérieure applicable ; ne déduisez pas qu’un correctif résout l’incident sans confirmation Microsoft.
• [ ] Sauvegardez les données et les éléments de configuration pertinents, puis consignez la procédure permettant de revenir à l’état précédent.
• [ ] Choisissez entre appliquer une correction officiellement indiquée, observer si le périmètre n’est pas confirmé, ou poursuivre le diagnostic avec les journaux si le symptôme persiste.

Cette liste n’autorise pas une modification automatique. Elle sert à déterminer si l’environnement correspond au problème confirmé et à préserver une trace exploitable. En particulier, une désinstallation générale de mises à jour de sécurité n’est pas une réponse par défaut : elle peut modifier l’exposition du serveur sans résoudre une incohérence de gestion SCVMM.

Que vérifier d’abord dans SCVMM lorsque l’hôte AMD échoue à l’actualisation ?

Commencez par établir que SCVMM gère bien l’hôte concerné et que l’erreur rapportée est celle de l’actualisation, plutôt qu’un incident survenu pendant une opération différente. Vérifiez ensuite la version de SCVMM et ses mises à jour cumulatives, puis comparez-les aux versions et aux correctifs que Microsoft indique comme applicables dans son avis. Les versions de génération et les mises à jour cumulatives de VMM sont répertoriées dans la documentation Microsoft sur les versions et numéros de build (tableau des versions de VMM et mises à jour cumulatives).

L’interface de SCVMM doit vous permettre de relever l’état de l’hôte et le détail de l’opération en échec ; PowerShell peut compléter cette vérification avec Get-SCVMHost. Comparez l’enregistrement remonté par SCVMM à l’état observé directement sur l’hôte, sans supposer qu’une seule console fournit toute la preuve nécessaire. Si la version de SCVMM ne correspond pas à la plage visée par les indications Microsoft, demandez-vous d’abord si l’avis s’applique réellement, au lieu d’installer une mise à jour VMM au hasard.

L’avis Microsoft et l’historique des mises à jour sont susceptibles d’évoluer. Vérifiez la version de la notice au moment de votre intervention, notamment si une mise à jour ultérieure ou une nouvelle indication SCVMM a été publiée ; l’existence de KB5134137 ne prouve pas, à elle seule, qu’elle constitue le correctif de l’échec que vous observez (notice Microsoft de KB5134137).

Lors d’un nouveau déploiement, séparez serveur et gestion de cluster

Un serveur physique AMD exécutant Windows Server et Hyper-V n’est pas, à lui seul, un service SCVMM ni une plateforme de gestion de cluster. Si vous déployez une nouvelle machine, définissez séparément le système à installer, les applications, les sauvegardes, l’administration de l’hyperviseur et, si votre organisation en a besoin, les composants de gestion SCVMM. Cette séparation évite d’acheter un serveur en pensant que l’incident décrit par Microsoft correspond à une limitation matérielle générale.

OSFP Cloud propose des choix de Windows Server qui comprennent les versions 2019, 2022 et 2025, avec des éditions Standard et Datacenter ainsi que des options de langue disponibles dans le catalogue ; vérifiez les possibilités affichées au moment de préparer votre commande (options serveur sur le site OSFP Cloud). Les choix de disque et de configuration doivent également être validés dans le catalogue plutôt que déduits d’une notice de mise à jour ; vous pouvez consulter les informations publiées sur les configurations de mémoire et de stockage.

Un serveur dédié peut convenir si vous souhaitez contrôler votre environnement Windows et disposer de ressources physiques non partagées, mais ce choix ne fournit pas SCVMM, la gestion d’un cluster ni l’administration des correctifs. Avant de commander, vérifiez aussi les limites de service et les responsabilités qui restent à votre équipe (périmètre des services OSFP Cloud). Si votre environnement actuel repose sur des machines virtuelles partagées, la concurrence pour les ressources, une capacité processeur susceptible d’être surallouée, une facturation réseau moins prévisible ou des choix limités de système et de stockage peuvent compliquer une charge durable ; une machine physique dédiée peut alors être plus adaptée, sans pour autant corriger automatiquement un problème SCVMM.

Dernière mise à jour : 6 novembre 2026. Les faits relatifs au périmètre AMD et SCVMM ont été vérifiés dans l’avis Microsoft publié le 3 novembre 2026 ; les références aux mises à jour ont été recoupées avec l’historique Windows Server 2025 et les notices KB5126646 et KB5134137.

Si vous évaluez un nouvel hôte Windows Server AMD, comparez les options réellement affichées par OSFP Cloud à vos exigences de système, de stockage et d’administration, puis vérifiez qui prendra en charge SCVMM et les correctifs après livraison. La location d’un serveur physique dédié peut répondre à un besoin de ressources non partagées et de contrôle de l’environnement ; elle ne remplace ni un service de gestion SCVMM ni une prestation de maintenance des mises à jour.