VM Azure : anticipez les dépréciations !

Depuis quelques mois, à l’heure où j’écris ces lignes fin juillet 2026, vous avez peut-être déjà reçu un ou plusieurs mails d’Azure au sujet de certaines de vos machines virtuelles : des annonces sur les Reserved Instances, sur des séries qui partent à la retraite, et vous vous demandez ce qui va réellement vous tomber dessus, et surtout quand ? Cet article est fait pour vous.

Car ces annonces ne forment pas un seul événement, mais trois vagues distinctes qui convergent sur la même période. On va les démêler une par une, poser le calendrier noir sur blanc, puis dérouler, capture après capture, ce que vous devez vérifier et faire dès maintenant dans le portail Azure. Objectif : que vous ressortiez de cette lecture avec un plan d’action clair, pas juste une vague inquiétude.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

Pour rappel : de quoi on parle ?
Vague 1 : la fin des Reserved Instances (1er juillet 2026)
Vague 2 : le gel de la croissance de capacité (31 juillet 2026)
Vague 3 : le calendrier de retraite des séries v1 à v4
Vers quoi migrer ? Les séries cibles v5, v6, v7
Ce que vous devez faire, concrètement
En résumé : les pièges à retenir

Pour rappel : de quoi on parle ?

Les annonces Azure mélangent plusieurs vocabulaires, et la plupart des malentendus viennent de leur confusion. Le cycle de vie d’une taille de VM passe par quatre états successifs :

Génération courante : la série recommandée, avec capacité garantie.
Previous-gen (génération précédente) : encore pleinement supportée, mais sans garantie de capacité supplémentaire. Deux nuances, next-gen available (pas encore de date de retraite) et capacity limited (plus aucune capacité déployée).
Retraite annoncée : une date de fin est fixée, la VM tourne encore mais il faut migrer.
Retirée : la taille n’est plus disponible, impossible d’en provisionner.

Deux autres termes, financiers cette fois, reviennent sans arrêt :

Reserved Instance (RI) : un engagement d’un ou trois ans sur une série de VM précise, en échange d’une remise. C’est un dispositif de facturation, pas un état de la VM.
Quota : le plafond de cœurs que votre abonnement peut déployer pour une série donnée, dans une région donnée.

Le fil rouge de tout l’article tient en deux phrases : previous-gen ne veut pas dire retirée, et fin des RI ne veut pas dire retraite de la VM. Gardez ces distinctions en tête, elles évitent la grande majorité des paniques inutiles.

Voici d’ailleurs pour info un portail très utile des décommissionnements prévus par Microsoft, accessible directement depuis le portail Azure Advisor :

Vague 1 : la fin des Reserved Instances (1er juillet 2026)

Première vague dans l’ordre chronologique, et elle est déjà passée. Depuis le 1er juillet 2026, Azure ne vend plus et ne renouvelle plus certaines Reserved Instances. Mais l’histoire a commencé bien avant cette date, car les réservations 1 an et 3 ans ne s’arrêtent pas au même moment. Voici le tableau complet des échéances :

Séries	RI 3 ans : plus d’achat ni de renouvellement depuis	RI 1 an : plus d’achat ni de renouvellement depuis
D, Ds, Dv2, Dsv2, Ls	1er mai 2025	1er juillet 2026
Av2, Amv2, Bv1, F, Fs, Fsv2, G, Gs, Lsv2	15 novembre 2025	1er juillet 2026
Dv3, Dsv3, Ev3, Esv3	1er juillet 2026	1er juillet 2026

Ce qu’il faut lire dans ce tableau : pour la plupart de ces séries, les réservations 3 ans ne sont déjà plus renouvelables depuis 2025 (mai pour la famille D et Ls, novembre pour les autres). Seules les réservations 1 an tenaient encore, et c’est cette dernière porte qui s’est refermée le 1er juillet 2026. Pour Dv3, Dsv3, Ev3 et Esv3, les deux durées s’arrêtent le même jour, le 1er juillet 2026.

Bon à savoir : cette date du 1er juillet 2026 pour les RI 1 an a été avancée. Elle était initialement fixée au 15 novembre 2027 (Azure Update 500682). Microsoft l’a donc rapprochée de plus d’un an, ce qui laisse encore moins de marge que ce qui était annoncé au départ.

Un point capital pour Dv3, Dsv3, Ev3 et Esv3 : ces séries ne sont pas retirées, elles restent « product active ». Ce sont seulement leurs réservations qui s’arrêtent. Ne confondez pas les deux.

Le piège classique : croire que le renouvellement automatique vous protège. Il ne joue plus pour ces séries. Vos réservations existantes restent valables jusqu’au bout de leur terme, un contrat 3 ans en cours court par exemple jusqu’à sa date de fin, mais à leur expiration, la charge bascule automatiquement en tarif pay-as-you-go, souvent bien plus cher, même si l’option de renouvellement automatique était cochée.

« July 1, 2026 does not terminate existing RIs. RIs remain valid until their individual expiration dates. »
Source : Transition guide for retired Azure Reserved VM Instances, Microsoft Learn

Attention : le 1er juillet 2026 ne résilie aucune réservation en cours. Une RI reste honorée jusqu’à sa date d’expiration individuelle. Le risque n’est pas une coupure, c’est une hausse de facture silencieuse le jour où elle expire.

Trois leviers, selon votre situation :

Passer à l’Azure savings plan for compute : un engagement basé sur la dépense horaire, flexible entre familles de VM et entre régions. C’est la recommandation numéro un de Microsoft.
Migrer vos charges vers une série récente, qui redonne accès aux RI comme aux Savings Plans.
Ne rien faire et assumer le pay-as-you-go, mais que ce soit un choix conscient, pas un oubli.

Note : la possibilité de renouveler une dernière fois les réservations 1 an existait jusqu’au 30 juin. Depuis le 1er juillet, cette porte est fermée pour les séries listées ci-dessus, et celle des réservations 3 ans l’était déjà depuis 2025 :

Vague 2 : le gel de la croissance de capacité (31 juillet 2026)

Deuxième vague, et de loin la plus imminente puisque la première est déjà derrière nous. À compter du 31 juillet 2026, Azure gèle la croissance de capacité des anciennes séries. Concrètement, les demandes suivantes ne seront plus approuvées :

les nouveaux déploiements de VM sur ces séries,
les opérations de scale-out qui réclament de la capacité supplémentaire,
les demandes d’augmentation de quota,
vos plans de croissance future sur ces séries.

Ce qui n’est pas touché, et c’est la bonne nouvelle : vos déploiements existants continuent de tourner dans la limite de la capacité déjà allouée. Aucune interruption, aucune VM coupée du jour au lendemain à cause de ce gel.

Les séries concernées se répartissent en deux groupes. D’abord celles qui partent à la retraite et sont soumises au gel :

Compute optimisé : F, Fs, Fsv2
Usage général : D, Ds, Dv2, Dsv2, Av2, Amv2, B, Bs
Mémoire : G, Gs
Stockage : Ls, Lsv2

Ensuite celles qui ne sont pas (encore) retirées mais déjà soumises au contrôle de croissance :

Usage général : Dv3, Dsv3, Dv4, Dsv4, Ddv4, Ddsv4, Dav4, Dasv4
Mémoire : Ev3, Esv3, Ev4, Esv4, Edv4, Edsv4, Eav4, Easv4

Attention : le gel ne coupe rien, mais il vous enferme. Si demain vous avez besoin d’ajouter des VM sur une de ces séries (montée en charge, nouveau projet, reprise d’activité dans une autre région), la demande peut être refusée. C’est précisément le scénario à anticiper avant le 31 juillet.

Je vous propose de regarder en exemple une machine virtuelle en série Bs avant la date du 31 juillet 2026. Le redimensionnement de celle-ci vers différentes tailles de la même famille est possible :

Et celui-ci fonctionne bien :

Par contre, j’avais déjà eu un refus de la part de Microsoft sur une demande d’augmentation de quota pour cette série :

Je vous referai dans quelques jours d’autres copies d’écran afin de comparer le changement à partir du 1er août.

Vague 3 : le calendrier de retraite des séries v1 à v4

Troisième vague, la plus étalée dans le temps. Voici le calendrier consolidé des retraites, de la plus ancienne (déjà effective) à la plus lointaine.

Série	Catégorie	Statut	Date de retraite
NCv3, NCv3-NC24rs	GPU	Retirée	30/09/2025
NVv3, NVv4	GPU	Annoncée	30/09/2026
M192idms_v2, M192ids_v2, M192ims_v2, M192is_v2	Mémoire	Annoncée	31/03/2027
NP-series	FPGA	Annoncée	31/05/2027
D, Ds, Dv2, Dsv2	Usage général	Annoncée	01/05/2028
Ls	Stockage	Annoncée	01/05/2028
Av2, Amv2	Usage général	Annoncée	15/11/2028
B-series (V1)	Usage général	Annoncée	15/11/2028
F, Fs, Fsv2	Compute optimisé	Annoncée	15/11/2028
G, Gs	Mémoire	Annoncée	15/11/2028
Lsv2	Stockage	Annoncée	15/11/2028

Deux lectures à retenir. D’une part, certaines séries GPU sont déjà retirées depuis septembre 2025 : si vous tournez encore dessus, vous êtes hors support et hors SLA. D’autre part, le gros des séries généralistes (D, Ds, Av2, F, G et compagnie) part en 2028, ce qui vous laisse du temps pour planifier, à condition de commencer maintenant. Le lot du 15 novembre 2028 (F, Fs, Fsv2, Lsv2, G, Gs, Av2, Amv2 et la série B) fait d’ailleurs l’objet d’une annonce dédiée, l’Azure Update 500682.

Attention : la date de retraite n’est pas le seul mur. Dès qu’une série passe en capacity limited, vous pouvez vous heurter à un manque de capacité bien avant la date officielle. Le gel du 31 juillet, c’est exactement ça. Ne calez pas votre migration sur 2028 en pensant être tranquille.

Vers quoi migrer ? Les séries cibles v5, v6, v7

Bonne nouvelle, Microsoft fournit une table de correspondance claire. Voici les cibles recommandées, série par série.

Séries actuelles	Cibles recommandées	À noter
D, Ds, Dv2, Dsv2	Dsv5/Ddsv5/Dasv5/Dadsv5, Dsv6/Ddsv6/Dasv6/Dadsv6, Dasv7/Dadsv7	Contrôleur de disque SCSI en v5, NVMe en v6 et v7
Av2, Amv2	Bsv2/Basv2, Dsv5/Dasv5, Esv5/Easv5, Dsv6/Dasv6, Esv6/Easv6	SCSI en v5, NVMe en v6
Bv1	Bsv2/Basv2, Dlsv5/Dalsv5, Dlsv6/Dalsv6	Débit de stockage distant plus élevé
F, Fs, Fsv2	Falsv6, Dlsv6/Daldsv6, Dlsv5/Dsv5/Ddsv5	NVMe en v6
G, Gs	Lsv3/Lasv3, Lsv4/Lasv4	Stockage local NVMe, débit distant nettement supérieur
Ls, Lsv2	Lsv3/Lasv3, Lsv4/Lasv4	Lsv4 et Lasv4 sont la dernière génération L
Dv3, Dsv3 (RI arrêtées)	Dsv5/Ddsv5/Dasv5, Dsv6/Ddsv6/Dasv6	Pas retirées, mais plus de RI
Ev3, Esv3 (RI arrêtées)	Esv5/Edsv5/Easv5, Esv6/Edsv6/Easv6	Pas retirées, mais plus de RI

Attention : la génération v6 impose des prérequis. Elle exige le NVMe activé (donc un OS supporté), fonctionne uniquement avec des VM de Génération 2, et requiert l’adaptateur réseau MANA avec un OS compatible. Si l’un de ces points bloque, repliez-vous provisoirement sur la v5. Et vérifiez la capacité régionale de la cible, elle n’est pas garantie partout.

Ce que vous devez faire, concrètement

Assez de théorie. Voici la marche à suivre, étape par étape, capture après capture. Comptez une petite heure pour un premier inventaire propre.

Étape 1 : inventorier vos VM par série

Direction le portail Azure. Dans la barre de recherche, tapez Virtual machines pour ouvrir la liste de vos VM. Ajoutez la colonne Size (bouton Manage view puis Edit columns) pour voir d’un coup d’œil la taille de chaque machine, puis repérez celles dont la série figure dans les tableaux ci-dessus :

Vous pouvez aussi utiliser le rapport Service Retirement Workbook disponible dans Azure Advisor :

Étape 2 : auditer vos Reserved Instances

Toujours dans le portail, recherchez Reservations. Filtrez par Product type réglé sur Virtual machines, puis examinez deux colonnes, la VM family et la date d’expiration. Toute réservation dont la famille figure dans la liste de la vague 1 est concernée :

Pour aller plus loin, ouvrez le détail de la réservation concernée et vérifiez son taux d’utilisation ainsi que sa date de fin. Confirmez si la charge continuera au-delà de l’expiration : si oui, il faut agir avant :

Étape 3 : choisir votre stratégie de coûts

Pour chaque réservation ou VM concernée, tranchez entre trois options : basculer vers un Azure savings plan for compute, moderniser la VM, ou assumer le pay-as-you-go.

Le trade-in d’une réservation vers un Savings Plan se fait en libre-service depuis le portail :

Passez un instant sur le calculateur de prix Azure pour chiffrer l’écart entre votre coût actuel et la cible :

Étape 4 : vérifier le quota de la série cible

Avant de redimensionner, assurez-vous que votre abonnement dispose d’assez de quota pour la série visée. Ouvrez Subscriptions, sélectionnez votre abonnement, puis Usage + quotas :

Si le plafond est trop bas, cliquez sur Request increase pour demander une augmentation sur la série cible :

Étape 5 : redimensionner la VM

Dernière ligne droite. Le redimensionnement se fait en trois temps. Sur la VM, cliquez sur Stop pour la désallouer proprement avant :

Une fois la machine virtuelle arrêtée et désallouée, ouvrez le volet Size, choisissez la taille cible, validez avec Resize :

Une fois le redimensionnement réussi, cliquez sur Start pour redémarrer la machine :

Le piège classique : oublier que les données du disque temporaire et de la mémoire sont perdues à la désallocation. Les disques managés, eux, sont conservés. Prévenez donc les applications qui s’appuient sur le disque temporaire avant de lancer l’opération.

Mon retour terrain : planifiez ce chantier 6 mois avant chaque échéance, pas la veille. Alignez la bascule sur vos fenêtres de maintenance applicative et sur vos cycles d’achat de Savings Plan, et faites modéliser les coûts par votre équipe de compte Microsoft. Le faire dans l’urgence, c’est la garantie de payer plus cher et de casser quelque chose.

En résumé : les pièges à retenir

Voilà, en trois vagues, tout ce qui se joue sur vos anciennes VM Azure. Concrètement, qu’est-ce que vous devez garder en tête ?

Deux dates pivots : le 1er juillet 2026 (fin des RI 1 an, déjà passé, les RI 3 ans ayant même cessé dès 2025) et le 31 juillet 2026 (gel de capacité, imminent).
Previous-gen n’est pas retirée, mais capacity limited peut vous bloquer bien avant la date de retraite officielle.
Fin des RI n’est pas retraite de la VM : Dv3, Dsv3, Ev3 et Esv3 restent actives, seules leurs réservations s’arrêtent.
Le renouvellement automatique ne joue plus : à l’expiration, bascule silencieuse en pay-as-you-go.
La v6 impose des prérequis (NVMe, Génération 2, MANA) et une capacité régionale non garantie : testez avant.
À la désallocation, disque temporaire et mémoire perdus, disques managés conservés.

Le vrai message : aucune de ces vagues ne coupe vos VM du jour au lendemain, mais toutes récompensent ceux qui anticipent et punissent ceux qui attendent. Faites votre inventaire cette semaine, pendant que vous avez encore le temps de choisir plutôt que de subir.

Foncez auditer vos abonnements, et si cet article vous a fait gagner du temps, dites-le moi en commentaire.

Pour aller plus loin

Migrez vos VMs de Gen1 à Gen2

Début février, Microsoft vient d’annoncer une nouvelle fonctionnalité en préversion pour migrer une machine virtuelle, de première génération vers la seconde. Cette bascule de génération est l’occasion de renforcer la sécurité (via Secure Boot et vTPM), d’améliorer les performances (temps de démarrage plus rapides) et d’offrir un support de disques de plus grande capacité. Tout cela, sans avoir besoin de reconstruire la machine virtuelle et en quelques clics.

Depuis quand la génération 2 est disponible sur Azure ?

Microsoft a annoncé la prise en charge des machines virtuelles de génération 2 depuis 2019, avec une généralisation progressive de leur déploiement par la suite.

Il y a quelques jours, Microsoft a annoncé la prévisualisation publique des machines virtuelles de génération 2 sur Azure. Les machines virtuelles de génération 2 prennent en charge un certain nombre de nouvelles technologies telles que l’augmentation de la mémoire, les Intel Software Guard Extensions (SGX) et la mémoire persistante virtuelle (vPMEM), qui ne sont pas prises en charge par les machines virtuelles de génération 1. Mais nous y reviendrons plus tard.

Thomas Maurer

Les machines virtuelles Gen1 restaient toujours utiles pour la migration d’environnements legacy, ou lorsque la compatibilité avec d’anciennes images était nécessaire.

En revanche, les VM Gen 2, avec leur firmware UEFI, offrent la possibilité d’exécuter des fonctionnalités modernes comme la virtualisation imbriquée.

Qu’est-ce que le Trusted Launch ?

Azure propose le lancement fiable pour améliorer de manière fluide la sécurité des machines virtuelles (VM) de génération 2. Le lancement fiable protège contre les techniques d’attaque avancées et persistantes. Le lancement fiable se compose de plusieurs technologies d’infrastructure coordonnées qui peuvent être activées indépendamment. Chaque technologie offre une couche de défense supplémentaire contre les menaces sophistiquées.
Microsoft Learn

Concrètement, Trusted Launch combine plusieurs technologies :

Secure Boot : Assure que seuls des composants logiciels signés et vérifiés sont autorisés à se charger pendant le démarrage.
vTPM (TPM virtuel) : Fournit une zone sécurisée pour stocker des clés cryptographiques et d’autres informations sensibles.
Measured Boot : Enregistre et vérifie les mesures du processus de démarrage pour détecter toute modification non autorisée.

Qu’est-ce que le Secure Boot ?

Le Secure Boot est donc une fonctionnalité de sécurité intégrée au niveau du firmware qui garantit que, lors du démarrage du système, seuls des composants logiciels authentifiés et signés numériquement (bootloader, pilotes, etc.) sont chargés.

Cela permet de prévenir l’exécution de code malveillant dès le démarrage, protégeant ainsi le système contre des attaques telles que les bootkits. En vérifiant l’intégrité et l’authenticité des éléments critiques, Secure Boot contribue à renforcer la sécurité globale de la machine.

Quelles sont les différences entre les 2 générations ?

Ce tableau permet ainsi de choisir la génération en fonction des besoins spécifiques en termes de sécurité, performance et compatibilité :

Fonctionnalité	Machines virtuelles Gen 1	Machines virtuelles Gen 2	Exemple / Explication
1. Type de firmware	BIOS	UEFI	Gen 2 utilise l’UEFI, permettant par exemple l’activation du Secure Boot.
2. Support des systèmes d’exploitation	32 bits et 64 bits	Exclusivement 64 bits	Pour un déploiement Windows Server 2019, seule la Gen 2 est compatible en 64 bits.
3. Interface de disque de démarrage	Utilise un contrôleur IDE	Utilise un contrôleur SCSI	Le démarrage sur SCSI en Gen 2 offre de meilleures performances I/O.
4. Secure Boot	Non disponible	Disponible	La sécurité est renforcée grâce au Secure Boot dans les VM Gen 2.
5. Virtualisation imbriquée	Support limité	Support amélioré	Permet d’exécuter Hyper-V dans la VM Gen 2 pour des environnements de test.
6. Temps de démarrage	Démarrage plus classique	Démarrage généralement plus rapide	Une VM Gen 2 peut démarrer plus vite grâce à l’architecture UEFI optimisée.
7. Taille maximale du disque système	Limité selon les anciens standards	Support de disques système de plus grande taille	Idéal pour des OS nécessitant un volume de boot plus important.
8. Virtualisation basée sur la sécurité	Non supportée	Supportée	Permet d’utiliser des fonctionnalités telles que Windows Defender Credential Guard.
9. Gestion de la mémoire	Standard	Optimisée pour des performances supérieures	Amélioration dans la gestion de la mémoire et la réactivité du système dans la Gen 2.
10. Support des périphériques modernes	Compatible avec du matériel plus ancien	Conçu pour exploiter les dernières technologies matérielles	Par exemple, intégration possible d’un TPM virtuel pour renforcer la sécurité.
11. Déploiement et gestion	Basé sur des modèles plus anciens	Optimisé pour une gestion moderne via Azure Resource Manager	Facilite l’intégration avec les nouvelles options de déploiement automatisé dans Azure.
12. Compatibilité des images	Compatible avec un large éventail d’images anciennes	Restreint aux images récentes optimisées pour UEFI	Gen 1 permet d’utiliser des images plus anciennes, alors que Gen 2 cible les OS modernes.

En résumé, le choix entre Gen1 et Gen2 se fera principalement en fonction des exigences de compatibilité et de sécurité :

Gen1 convient aux scénarios où l’héritage et la compatibilité avec des images plus anciennes priment.
Gen2 est privilégiée pour bénéficier d’une meilleure sécurité et de performances optimisées, notamment grâce aux fonctionnalités comme Secure Boot et le vTPM.

Puis-je utiliser des Gen1/Gen2 avec toutes les familles de machines virtuelles Azure ?

Non. Et pour vous aider, Microsoft vous met à disposition cette liste, disponible via ce lien.

Toutes les images OS sont-elles compatible avec Gen2 ?

Non. Les machines virtuelles Gen2 prennent en charge que certaines images OS :

Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012
Windows 11 Professionnel, Windows 11 Entreprise
Windows 10 Professionnel, Windows 10 Entreprise
SUSE Linux Enterprise Server 15 SP3, SP2
SUSE Linux Enterprise Server 12 SP4
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS
RHEL 9,5, 9.4, 9.3, 9.2, 9.1, 9.0, 8.10, 8.9, 8.8, 8.7, 8.6, 8.5, 8.4, 8.3, 8.2, 8.1, 8.0, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0
Cent OS 8.4, 8.3, 8.2, 8.1, 8.0, 7.7, 7.6, 7.5, 7.4
Oracle Linux 9.3, 9.2, 9.1, 9.0, 8.9, 8.8, 8.7, 8.6, 8.5, 8.4, 8.3, 8.2, 8.1, 7.9, 7.9, 7.8, 7.7

Puis-je basculer une VM de Gen1 à Gen2, et inversement ?

Anciennement, il n’était pas possible de facilement convertir directement une VM existante de Gen1 vers Gen2, en raison des différences fondamentales au niveau du firmware et de la configuration des disques. Pour migrer vers une Gen2, il fallait alors bien souvent recréer la machine virtuelle dans la génération cible.

Qu’est-ce que MBR2GPT ?

MBR2GPT est un outil en ligne de commande de Microsoft qui permet de convertir un disque partitionné en MBR vers le format GPT sans perte de données, facilitant ainsi la transition d’un mode BIOS hérité vers un démarrage UEFI.

Depuis peu, Microsoft vient d’ajouter une fonctionnalité, encore en préversion, pour basculer de Gen1 à Gen2 en quelques clics, dont la source est disponible juste ici.

Enfin, voici d’ailleurs une vidéo de Microsoft parlant en détail de l’outil MBR2GPT :

Comme indiqué dans cette vidéo, l’outil MBR2GPT va travailler sur la conversation des partitions de l’OS :

Le processus sur Azure se fait en seulement quelques clics, et je vous propose de tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser ce test de conversation de génération (encore en préversion), il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Commençons par créer une machine virtuelle de première génération.

Etape I – Création de la machine virtuelle Gen1 :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle compatible à la fois Gen1 et Gen2 :

Renseignez les informations de l’administrateur local, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion pour continuer.

L’étape suivante consiste à lancer l’utilitaire intégré MBR2GPT afin de valider et de transformer la partition du disque OS au format GPT, et aussi d’ajouter la partition système EFI requise pour la mise à niveau en Gen2.

Etape II – Transformation du disque OS depuis MBR vers GPT :

Une fois Azure Bastion correctement déployé, saisissez les identifiants renseignés lors de la création de votre machine virtuelle :

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

Confirmez le statut du mode BIOS en Legacy :

Les propriétés du disque OS nous confirme l’utilisation du style de partition MBR (Master Boot Record) :

Depuis le menu Démarrer de votre machine virtuelle, puis cliquez sur Exécutez pour ouvrir le programme cmd :

Lancez la commande MBR2GPT suivante pour exécuter la validation MBR vers GPT :

MBR2GPT /validate /allowFullOS

Assurez-vous que la validation de l’agencement du disque se termine avec succès. Ne continuez pas si la validation du disque échoue :

Lancez la commande MBR2GPT suivante pour exécuter la conversion MBR vers GPT :

MBR2GPT /convert /allowFullOS

Obtenez le résultat suivant :

Cliquez-ici pour fermer votre session Windows :

Une fois la session Windows fermée, cliquez-ici pour fermer l’onglet ouvert pour Azure Bastion :

Depuis le portail Azure, arrêtez votre machine virtuelle :

Confirmez votre choix en cliquant sur Oui :

Quelques minutes plus tard, confirmez que la machine virtuelle est en état Arrêté (désallouée).

Encore en préversion, l’activation des mesures de sécurité sur la machine virtuelle n’est pas possible depuis le portail Azure. Il faut donc utiliser Azure Cloud Shell.

Etape III – Activation du vTPM et du Secure Boot :

Mais avant d’activer le vTPM et le Secure Boot sur notre machine virtuelle Azure, il est nécessaire d’activer la fonctionnalité Gen1ToTLMigrationPreview, encore en préversion, sur notre souscription Azure.

Pour cela, cliquez sur le bouton suivant pour ouvrir la fenêtre d’Azure Cloud Shell :

Une fois Azure Cloud Shell d’ouvert en mode PowerShell, saisissez la commande suivante afin de voir si celle-ci est déjà activée :

Get-AzProviderFeature -FeatureName "Gen1ToTLMigrationPreview" -ProviderNamespace "Microsoft.Compute"

Si la fonctionnalité Gen1ToTLMigrationPreview n’est pas encore activée, saisissez la commande suivante :

Register-AzProviderFeature -FeatureName "Gen1ToTLMigrationPreview" -ProviderNamespace "Microsoft.Compute"

Relancez la commande suivante afin de voir si celle-ci a fini son activation :

Get-AzProviderFeature -FeatureName "Gen1ToTLMigrationPreview" -ProviderNamespace "Microsoft.Compute"

Environ 10 minutes plus tard, le statut de la fonctionnalité devrait être comme ceci :

Toujours sur Azure Cloud Shell, saisissez la commande suivante afin de constater la présence de votre machine virtuelle Azure :

Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm

Activez le lancement UEFI en définissant -SecurityType sur TrustedLaunch :

Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Update-AzVM -SecurityType TrustedLaunch -EnableSecureBoot $true -EnableVtpm $true

Validez la mise à jour du profil de sécurité le dans la configuration de la VM :

# Following command output should be `TrustedLaunch 

(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.SecurityType

# Following command output should return `SecureBoot` and `vTPM` settings
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.Uefisettings

Le changement de génération de notre machine virtuelle est également visible sur le portail Azure :

De même que le profil de sécurité ainsi que les options activées (une fois que vous avez activé le Trusted launch, les machines virtuelles ne peuvent plus être ramenées au type de sécurité Standard) :

Ces options sont encore modifiables depuis l’écran ci-dessous (Microsoft recommande d’activer le Secure Boot si vous n’utilisez pas de pilotes personnalisés non signés) :

Redémarrez votre machine virtuelle :

Reconnectez-vous à celle-ci via le service Azure Bastion :

Constatez la bonne ouverture de session Windows :

Confirmez le statut du mode BIOS en UEFI, de même que l’activation du Secure Boot :

Relancer la validation de l’agencement du disque sur un disque déjà configuré en GPT provoquera une erreur logique :

Les propriétés du disque OS nous confirme l’utilisation du style de partition GUID (GPT), qui est un schéma de partitionnement moderne qui utilise des identifiants uniques (GUID) pour chaque partition :

Etape IV – Activation de services annexes :

Une fois la bascule en Gen2 effectuée, il n’est plus possible d’activer la sauvegarde via Azure Backup avec une police de type standard :

D’ailleurs, l’activation de la sauvegarde après le changement de Gen1 à Gen2 n’a posé aucun souci :

Il en a été de même pour l’activation de réplication pour une machine migrée de Gen1 à Gen2 :

Dans le cadre d’un test de failover, la nouvelle machine virtuelle, créée temporairement, est bien elle aussi en génération 2 :

La connexion via Azure Bastion sur cette machine virtuelle temporaire est bien fonctionnelle :

Conclusion

En conclusion, cette procédure toute simple et réalisée en quelques clics avec MBR2GPT nous démontre que migrer vos machines virtuelles de Gen1 à Gen2 représente bien plus qu’un simple changement de firmware :

Grâce à une sécurité renforcée avec Secure Boot et vTPM, des performances accrues et une prise en charge des disques de plus grande taille.
Adopter Gen2, c’est ainsi investir dans une plateforme plus robuste, performante et alignée avec les exigences actuelles de la sécurité informatique.