Les services de calcul représentent souvent l’essentiel des coûts sur Azure. Pour les charges de travail qui fonctionnent en continu, les instances réservées apportent une réduction notable des tarifs à la carte. En s’engageant sur une durée d’un ou trois ans, il est possible de réaliser jusqu’à grosses économies par rapport au modèle pay‑as‑you‑go. Mais est-on alerté quand ces réductions sont disponibles pour notre environnement Azure, ou qu’elles expirent ?
Dans cet article, nous revenons sur le fonctionnement des instances réservées, leur gestion (notamment le renouvellement automatique) et sur la création d’alertes Azure Advisor pour être notifié lorsqu’une réservation devient pertinente ou expire.
Qu’est-ce qu’une instance réservée Azure ?
Une instance réservée est un engagement de capacité : vous acceptez d’utiliser un type d’instance ou une famille d’instances dans une région spécifique pendant une durée déterminée, en échange d’un prix réduit. Les réservations s’achètent pour un an ou trois ans :
Quand acheter une réservation ?
Les instances réservées sont particulièrement adaptées aux charges stables et prévisibles. La documentation Microsoft recommande d’opter pour une réservation lorsque vous prévoyez d’utiliser le même type d’instance ou la même famille dans une région donnée pendant toute la durée de l’engagement.
À l’inverse, si vos applications changent fréquemment de configuration ou de région, les savings plans peuvent être plus appropriés car ils s’appliquent à un montant horaire sur plusieurs services et régions. Néanmoins, une instance réservée reste l’option la plus économique lorsque son utilisation est maximale.
Que doit-on faire pour appliquer la remise ?
Une fois la réservation achetée, la remise est appliquée automatiquement aux machines virtuelles, SQL Database, Cosmos DB ou d’autres services éligibles qui correspondent aux attributs choisis (SKU, région, étendue).
Les réservations n’affectent pas l’état d’exécution des ressources : si une machine est mise à l’arrêt ou redimensionnée, le rabais se reporte sur une autre ressource compatible, sinon la portion inutilisée est perdue :
Quid d’une machine virtuelle dont la taille varie ?
Une instance réservée s’applique sur une famille de machines virtuelles : même si le SKU d’une RI correspond à un SKU spécifique d’une VM, il peut s’appliquer à d’autres tailles d’une même famille via un ratio :
Le tableau ci-dessus affiche des instances réservées pour des machines virtuelles. Comment fonctionne une instance réservée ? Il faut simplement voir celle-ci comme une place de parking, louée pour un ou trois ans chez Microsoft :
Comme le montre ce schéma, la taille de l’instance réservée doit être en relation avec la taille de la ressources Azure.
Il est donc possible d’optimiser votre réservation pour la flexibilité de taille. Dans ce mode, la remise s’applique à toutes les tailles d’instances d’un même groupe. Par exemple, une réservation achetée pour une instance de la série DSv2 (par exemple Standard_DS3_v2) peut s’appliquer aux autres tailles de ce groupe : Standard_DS1_v2, Standard_DS2_v2, Standard_DS3_v2 et Standard_DS4_v2
Quid de la durée et la fréquence de paiement ?
Le choix de la durée dépend de la stabilité de votre charge. Les engagements d’un an offrent plus de flexibilité tandis que les engagements de trois ans maximisent les économies. Vous pouvez régler la réservation en une seule fois ou mensuellement ; le coût total reste identique et aucune pénalité n’est appliquée en cas de paiement échelonné, sauf le taux de change qui varie dans le temps :
Qu’est-ce qui n’est pas couvert par la RI ?
La remise porte uniquement sur les coûts de calcul. Pour les machines virtuelles, elle concerne les cœurs et la mémoire mais ne couvre pas les licences Windows ni les frais de stockage, réseau ou logiciels.
Les licences peuvent être prises en charge via l’Azure Hybrid Benefit, et les autres coûts sont facturés séparément. En revanche, de nombreux services Azure disposent de capacités réservées pour réduire leurs propres coûts de calcul.
Qu’est-ce qu’Azure Hybrid Benefit ?
Azure Hybrid Benefit est un avantage en matière de licences qui vous permet de réduire considérablement les coûts d’exécution de vos charges de travail dans le cloud. Son fonctionnement consiste à vous autoriser à utiliser vos licences Windows Server et SQL Server compatibles sur Azure.
Il est donc possible d’acheter des licences en souscriptions annuelles ou pluriannuelles. Les économies représentent des sommes non négligeables.
Cet avantage permet donc d’utiliser les licences Windows Server ou SQL Server existantes éligibles, et ainsi de ne payer que le tarif de base des machines virtuelles.
Que se passe-t-il à la fin du contrat de la RI ?
Lorsque vous achetez une réservation, le renouvellement automatique est souvent activé par défaut. Cette fonction permet de racheter automatiquement une réservation équivalente à l’expiration de la précédente, afin de continuer à bénéficier de la remise sans surveillance quotidienne.
Vous pouvez activer ou désactiver cette option à tout moment dans le portail Azure. Le prix du renouvellement est disponible 30 jours avant la date d’expiration. Si la réservation n’est pas renouvelée, vos ressources continuent de fonctionner, mais elles repassent en facturation à l’usage.
Peut-on annuler une instance réservée en cours d’engagement ?
Oui, Microsoft permet l’annulation d’une RI pendant sa durée d’engagement, sous conditions :
Les remboursements sont calculés en fonction du prix le plus bas de votre prix d’achat ou du prix actuel de la réservation.
Nous ne facturons actuellement aucun frais de résiliation anticipée, mais des frais de résiliation anticipée de 12 % pourraient s’appliquer à l’avenir en cas d’annulation.
L’engagement total annulé ne peut pas dépasser 50 000 USD dans une période de 12 mois pour un profil de facturation ou une inscription unique.
Lorsqu’une réservation est échangée ou annulée, le remboursement est calculé en fonction du nombre de jours restants dans la période de réservation. Le calcul est effectué au format UTC et utilise une formule cohérente pour garantir l’équité et la transparence.
Par exemple, si vous avez acheté une réservation le 10 juillet 2024 et que vous l’avez échangée le 9 juillet 2025, seulement 1 jour reste dans la réservation. Vous recevrez un petit remboursement pour ce seul jour.
Instances réservées vs. Savings Plan ?
Bien que les savings plans partagent l’objectif de réduire les coûts, ils fonctionnent différemment. Une instance réservée vous engage sur un type ou une famille d’instances dans une région donnée et vous apporte la remise la plus élevée lorsque vos machines fonctionnent en continu.
À l’inverse, un savings plan fixe un montant horaire applicable sur plusieurs services de calcul et dans toutes les régions. Cette flexibilité est utile pour les charges de travail qui évoluent et qui se déplacent entre régions, mais les économies sont généralement moindres que celles d’une instance réservée utilisée à 100 %.
Dans la majorité des cas, un utilisateur qui connaît ses besoins à moyen terme gagnera à privilégier la réservation et à activer le savings plan seulement pour les charges variables.
Qu’est-ce qu’Azure Advisor ?
Azure Advisor est un assistant cloud personnalisé qui analyse en continu ta configuration Azure et ton usage pour te fournir des recommandations proactives afin d’optimiser :
la fiabilité
la sécurité
la performance
les coûts
l’excellence opérationnelle
Peut-on y créer des alertes concernant le besoin de RI ?
Comme montré dans une copie d’écran plus haut, Azure Advisor affiche des conseils sur les économies financières possibles sur votre infrastructure Azure. Ces conseils portent également sur l’achat d’instances réservées pour vos services de calcul.
Azure Advisor analyse l’utilisation de vos ressources et émet donc des recommandations lorsqu’il détecte des économies potentielles.
Lorsque Advisor identifie une nouvelle recommandation (par exemple l’achat d’une instance réservée), un événement est enregistré dans le journal d’activité. Il est possible de déclencher une alerte à chaque nouvelle recommandation afin d’être averti par courriel ou via un webhook :
Comme vous pouvez le voir, j’ai créé cette nouvelle alerte sur le type de recommandation suivant :
Consider virtual machine reserved instance to save over the on-demand costs
Comme les alertes configurées dans Azure Monitor, un groupe d’action peut y être affecté :
Une fois l’alerte en place, chaque nouvelle recommandation Advisor se traduira par une notification. Cela vous permet d’acheter les réservations appropriées dès qu’elles sont pertinentes et de réagir lorsque l’une d’elles arrive à expiration.
Ayant configuré une adresse email sur ce groupe d’action, et une fois l’alerte déclenchée, l’email suivant me parvient :
Un clic sur le lien présent dans l’email nous affiche la recommandation concernée dans le portail Azure :
Il ne me reste plus alors qu’à acheter, ou racheter, l’instance réservée appropriée 😎
Conclusion
La maîtrise des coûts est un volet essentiel de l’architecture cloud. En engageant vos ressources sur une durée ferme, les instances réservées vous permettent de réduire significativement vos dépenses tout en conservant la flexibilité de changer de taille ou d’échanger votre réservation en cas d’évolution de vos besoins.
Les fonctionnalités de renouvellement automatique garantissent la continuité des remises, et les alertes Azure Advisor vous aident à prendre les bonnes décisions au bon moment. En combinant analyse de l’utilisation (Advisor), estimation des coûts (calculateur de tarification) et stratégie d’engagement, vous disposez de tous les outils pour optimiser votre facture Azure.
Le chiffrement des disques Azure existe depuis longtemps, mais il reste souvent mal compris : SSE, Encryption at Host, ADE… tout ne fonctionne pas au même niveau, et tout n’a pas le même impact. Je vous propose ici un tour d’horizon concret : explications, tests de performance et retour d’expérience sur la migration depuis Azure Disk Encryption.
Avant d’aller plus loin dans notre sujet, gardez toujours en tête que le processus de chiffrement concerne plusieurs états possibles de la donnée :
Dans cet article, nous aurons pour objectif de parler de la protection des données « au repos » sur les disques, afin qu’elles restent inexploitables en cas d’accès non autorisé, extraction de disque virtuel ou compromission de stockage.
Vue d’ensemble des options de chiffrement des disques de VM :
À ce jour, il existe plusieurs mécanismes de chiffrement disponibles pour vos disques de vos machines virtuelles Azure. Voici un premier récapitulatif des différents mécanismes de chiffrement disponibles sur Azure :
Azure Disk Storage Server-Side Encryption (SSE) : ce premier niveau de chiffrement est toujours activé pour les données au repos. Il chiffre automatiquement les données stockées sur les disques gérés Azure (disques OS et disques de données, à l’exception des disques temporaires et des caches disque).
Il est même possible de travailler avec d’autres clés que celles gérées par Microsoft :
Confidential disk encryption : ce mécanisme lie les clés de chiffrement des disques au TPM de la machine virtuelle et rend le contenu protégé du disque accessible uniquement à la machine virtuelle et ne permet pas que l’hyperviseur puisse déchiffrer les données.
Encryption at host : option au niveau de la machine virtuelle qui améliore le chiffrement côté serveur Azure Disk Storage afin de garantir que tous les disques temporaires et les caches disque sont chiffrés au repos et transférés chiffrés vers les clusters de stockage.
Azure Disk Encryption (ADE) : ce mécanisme chiffre le système d’exploitation et les disques de données des machines virtuelles Azure (VM) à l’intérieur de vos VM à l’aide de la fonctionnalité DM-Crypt de Linux ou de la fonctionnalité BitLocker de Windows. Azure Key Vault permet de contrôler et gérer les clés et les secrets de chiffrement de disque.
Quand ADE est activé, chaque disque de la machine virtuelle affiche alors cette information :
Une extension ADE est sur la machine virtuelle :
Est-ce que Azure Disk Encryption est déprécié ?
Azure Disk Encryption présente actuellement plusieurs limites importantes :
Le chiffrement réalisé directement dans l’OS peut entraîner une consommation CPU supplémentaire dans la VM.
ADE n’est pas compatible avec l’ensemble des types de disques ni toutes les distributions Linux.
Son intégration étroite avec l’OS et l’agent Azure le rend plus sensible et plus complexe à maintenir.
Partant de ce constat, je suppose que Microsoft a fait son choix et que ADE sera officiellement retiré le 15 septembre 2028, et propose même une stratégie de migration vers Encryption at host :
Azure Disk Encryption pour les machines virtuelles et les Virtual Machine Scale Sets sera mis hors service le 15 septembre 2028. Les nouveaux clients doivent utiliser le chiffrement sur l’hôte pour toutes les nouvelles machines virtuelles.
Les clients existants doivent planifier la migration des machines virtuelles ADE actuelles vers le chiffrement sur l’hôte avant la date de mise hors service pour éviter toute interruption de service.
Encryption at Host est un mécanisme de chiffrement fourni par la plateforme Microsoft Azure permettant de chiffrer les disques de machines virtuelles au niveau de l’hôte (l’hyperviseur), avant que les données ne soient écrites sur le stockage.
Plutôt que de chiffrer les disques directement dans la machine virtuelle via BitLocker ou DM-Crypt, ce mode déplace le chiffrement sur l’hyperviseur Azure lui-même.
Cela permet de chiffrer l’ensemble des composants associés à la VM (disques OS, disques de données, disques temporaires et cache) tout en évitant la charge CPU dans la VM :
Quelles sont les restrictions liées à cette migration ?
Microsoft rappelle ici les différents points et limitations à prendre lorsque vous souhaitez migrer d’Azure Disk Encryption à Encryption at host, Voici quelques-unes d’entre elles :
Temps d’arrêt requis : le processus de migration nécessite un temps d’arrêt de machine virtuelle pour les opérations de disque et la recréation des machines virtuelles.
Aucune migration sur place : vous ne pouvez pas convertir directement des disques chiffrés par ADE en chiffrement sur l’hôte. La migration nécessite la création de disques et de machines virtuelles.
Machines virtuelles jointes à un domaine : si vos machines virtuelles font partie d’un domaine Active Directory, d’autres étapes sont requises :
La machine virtuelle d’origine doit être supprimée du domaine avant la suppression
Après avoir créé la machine virtuelle, elle doit être jointe au domaine
Pour les machines virtuelles Linux, la jonction de domaine peut être effectuée à l’aide d’extensions Azure AD
Pour réaliser cet exercice sur les différentes méthodes de chiffrements, il faut disposer de :
Un tenant Microsoft
Une souscription Azure valide
La suite se passera par la création d’une machine virtuelle depuis le portail Azure.
Etape I – Création de la machine virtuelle Azure :
Je commence par créer une machine virtuelle Windows Server 2025 avec 32 cœurs, afin d’éviter toute limitation liée aux performances de la VM pendant les tests :
Une fois la VM créée, j’ajoute un disque de données supplémentaire en plus du disque système. À ce stade, les deux disques utilisent le chiffrement au repos par défaut de type SSE, appliqué automatiquement par la plateforme :
Sur l’écran de configuration des disques, des Paramètres supplémentaires sont disponibles :
Je constate que le chiffrement au niveau de l’hôte n’est pas activé à ce stade. La VM utilise uniquement le chiffrement SSE, sans mécanisme supplémentaire de type ADE ou Encryption at Host :
Je me connecte à la machine virtuelle via Azure Bastion :
Je vérifie que le service BDESVC associé à BitLocker n’est pas actif et qu’aucun chiffrement au niveau du système d’exploitation n’a été configuré :
Get-Service BDESVC
manage-bde -status
Cela confirme que seul le chiffrement SSE au niveau du stockage est en place, et qu’aucune couche de chiffrement, au niveau de la machine virtuelle ou de l’hyperviseur est activée :
Afin d’étoffer mon analyse, il est intéressant de comparer les performances (IOPS, Débits et CPU) entre plusieurs types de chiffrement de stockage. Pour cela j’utiliserai l’outil de mesure Diskspd et les métriques disponibles sur le portail Azure.
Etape II – Installation de l’outil de mesure Diskspd :
L’installation de Diskspd se fait directement sur la machine virtuelle à tester :
DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.
Microsoft recommande d’utiliser l’utilitaire DiskSpd pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.
J’ouvre Task Manager afin d’observer en temps réel l’activité du disque :
Je surveille l’utilisation CPU de la VM depuis le portail Azure :
Une fois les deux tests terminés, les fichiers sont générés dans le dossier courant :
le premier fichier TXT généré est pour consigner les résultats IOPS :
Le second fichier TXT est généré pour consigner les résultats débits :
Etape VI – Comparaison des performances de chiffrement :
Les mesures montrent que les performances des disques restent globalement équivalentes entre les trois modes, mais que l’usage CPU varie nettement, notamment lorsque le chiffrement est exécuté dans le système d’exploitation comme avec Azure Disk Encryption :
Mode de chiffrement
CPU moyen (%)
SSE (Storage Service Encryption)
1.5 %
Encryption at Host
1.0 %
ADE (Azure Disk Encryption)
2.8 %
SSE et Encryption at Host ont un impact CPU faible et comparable.
ADE présente une charge CPU sensiblement supérieure, liée au chiffrement effectué par BitLocker dans la VM, ce qui correspond à l’architecture même de ce mode.
La surcharge induite par ADE reste faible, mais l’hétérogénéité des latences confirme qu’il reste plus sensible que les modes opérés directement par la plateforme.
Etape VII – Migration d’ADE vers Encryption at host :
La migration depuis ADE vers Encryption at host sur une machine virtuelle n’est pas possible pour des raisons techniques. Voici ce qui se produit lorsqu’on tente d’activer Encryption at Host sur une VM, qui était auparavant configurée avec Azure Disk Encryption :
Microsoft liste donc ici les différentes étapes nécessaires pour réaliser cette migration. Nous allons commencer par désactiver Azure Disk Encryption.
Sur l’écran de configuration des disques, je désactive Azure Disk Encryption, puis je sauvegarde :
Une tâche Azure se déclenche, j’attends quelques minutes que celle-ci se termine :
Je me reconnecte à la machine via Azure Bastion, puis je vérifie que le service BDESVC est toujours activé et qu’une phase de déchiffrement vient de démarrer :
Get-Service BDESVC
manage-bde -status
Quelques minutes plus tard, le déchiffrement est entièrement terminé :
Malgré cela, l’extension ADE est toujours présente sur ma machine virtuelle :
Je la désinstalle depuis le portail Azure :
Quelques minutes plus tard, la notification Azure suivante apparaît :
Lancez la commande PowerShell suivante depuis Azure Cloud Shell pour chacun des disques afin de créer des disques qui ne portent pas sur les métadonnées de chiffrement ADE :
Attention : Ce script ne fonctionne pas sur les disques Premium SSDv2 et Ultra.
# Get source disk information
$sourceDisk = Get-AzDisk -ResourceGroupName "MyResourceGroup" -DiskName "MySourceDisk"
# Create a new empty target disk
# For Windows OS disks
$diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512) -OsType Windows -HyperVGeneration "V2"
# For Linux OS disks (if not ADE-encrypted)
# $diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload # -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512) -OsType Linux # -HyperVGeneration "V2"
# For data disks (no OS type needed)
# $diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload # -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512)
$targetDisk = New-AzDisk -ResourceGroupName "MyResourceGroup" -DiskName "MyTargetDisk" -Disk $diskConfig
# Generate SAS URIs and copy the data
# Get SAS URIs for both disks
$sourceSAS = Grant-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $sourceDisk.Name -Access Read -DurationInSecond 7200
$targetSAS = Grant-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $targetDisk.Name -Access Write -DurationInSecond 7200
# Copy the disk data using AzCopy
azcopy copy $sourceSAS.AccessSAS $targetSAS.AccessSAS --blob-type PageBlob
# Revoke SAS access when complete
Revoke-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $sourceDisk.Name
Revoke-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $targetDisk.Name
Pour mon disque data configuré en premium SSDv2, je crée un snapshot manuellement :
Depuis le nouveau disque OS créé via le script plus haut, je relance la création d’une nouvelle machine virtuelle :
Je configure cette nouvelle machine virtuelle, en y intégrant le disque de data issu du snapshot, puis je lance sa création :
Une fois la machine virtuelle créée, j’éteins celle-ci, puis j’active Encryption at host dans les paramétrages des disques :
Je redémarre la machine virtuelle, puis je constate dans l’affichage du diagnostic le bon démarrage de celle-ci :
Conclusion
Au final, SSE et Encryption at Host couvrent aujourd’hui l’essentiel des besoins, avec un impact quasi nul sur la VM et une gestion simplifiée. SSE reste la base, toujours activée, tandis qu’Encryption at Host ajoute une couche complète de protection sans coût CPU notable.
ADE fonctionne encore, mais son intégration à l’OS et sa charge CPU supplémentaire en font une solution plus lourde à exploiter. Avec les résultats obtenus et sa dépréciation annoncée, il devient clairement le mécanisme à éviter pour les nouvelles machines virtuelles.
SSE : excellente base, impact minimal, tout est géré par la plateforme.
Encryption at Host : même niveau de performance que SSE, avec la garantie que toutes les couches (OS, data, cache, disque temporaire) sont chiffrées directement par l’hyperviseur.
ADE : Performances disque similaires, mais CPU plus élevé, dû au chiffrement dans la VM. Cela confirme pourquoi ce mode est progressivement remplacé par les autres mécanismes gérés par la plateforme.
Pour la majorité des workloads, Encryption at Host apparaît désormais comme l’option la plus propre, la plus simple et la plus pérenne.
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.
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.
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
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 😎💪
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 :
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.
De mon côté, l’aventure IT a commencé en décembre 1995 avec mon tout premier ordinateur : un 486 SX-33 développé par Intel. Je ne saurais me rappeler de sa quantité de mémoire vive, mais je pense que je pouvais les compter sur les doigts d’une seule main 🤣.
Plus sérieusement, que ce passe-t-il si une application métier, toujours fonctionnelle et devant perdurer, doit être migrée au plus vite pour une raison X ?
Microsoft a peut-être une réponse grâce au le service Azure Migrate :
Azure Migrate offre un service simplifié de migration, de modernisation et d’optimisation pour Azure. Toutes les étapes de pré-migration telles que la détection, les évaluations et le dimensionnement des ressources locales sont incluses pour l’infrastructure, les données et les applications. L’infrastructure extensible d’Azure Migrate permet d’intégrer des outils tiers, ce qui augmente l’étendue des cas d’utilisation pris en charge.
Pour vous faire une meilleure idée d’Azure Migrate, un atelier exercice dédié à la migration vers Azure conçu par Microsoft avait déjà été détaillé sur ce blog juste ici.
Comme le montre le schéma ci-dessous, l’objectif de cet exercice est de migrer plusieurs serveurs virtuels gérés sous un serveur Hyper-V vers le Cloud Azure :
Qu’est-ce que Disk2vhd ?
Il s’agit d’un petit utilitaire très pratique développé par Mark Russinovich et disponible dans la suite Sysinternals :
Disk2vhd est un utilitaire qui crée des versions VHD (Virtual Hard Disk – Microsoft’s Virtual Machine disk format) de disques physiques à utiliser dans Microsoft Virtual PC ou Microsoft Hyper-V virtual machines (VMs). La différence entre Disk2vhd et d’autres outils physiques à virtuels est que vous pouvez exécuter Disk2vhd sur un système en ligne.
Disk2vhd utilise la capacité d’instantané de volume de Windows, introduite dans Windows XP, pour créer des instantanés cohérents à un instant donné des volumes que vous souhaitez inclure dans une conversion. Vous pouvez même demander à Disk2vhd de créer les VHD sur des volumes locaux, même ceux en cours de conversion (bien que les performances soient meilleures lorsque le VHD se trouve sur un disque différent de ceux en cours de conversion).
Au travers de ce nouvel article, je souhaitais tester avec vous la copie de plusieurs serveurs physiques fonctionnant sous d’anciens OS afin de tester un portage rapide et simple vers Azure :
Windows XP Professional
Windows 7 Professional x64
Windows 10 Enterprise x64
Windows Server 2008 R2 x64
Windows Server 2012 R2 x64
Windows Server 2016 x64
Pour cela, cet article repose sur la méthode de préparation d’un fichier VHD proposée par Microsoft et exposée juste ici, dont les principales commandes de préparation sont disponibles sur mon GitHub.
Pour réaliser cet exercice de migration individuelle, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
N’ayant pas d’anciens serveurs physiques à disposition, j’ai choisi de les simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.
Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.
Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées :
Conservez les options par défaut, puis cliquez sur OK :
Cliquez ensuite sur Suivant :
Retirez l’adresse IP publique pour des questions de sécurité, 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 hôte (Hyper-V) :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :
Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :
Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Terminer :
L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.
Etape II – Création de la machine virtuelle invitée :
Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :
Stockez le fichier ISO sur le disque F de votre VM hôte (Hyper-V) :
Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :
Cliquez-ici pour créer votre machine virtuelle invitée :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :
Choisissez Génération 1 :
Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :
Une fois la machine virtuelle invitée créée, modifiez sa configuration comme ceci :
Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows, puis cliquez sur OK :
Répétez les mêmes opérations pour les autres OS dont vous souhaitez tester la migration vers Azure :
Double-cliquez sur votre machine virtuelle invitée :
Cliquez-ici pour lancer le démarrage de la VM invitée :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows :
Attendez que le démarrage de l’installation se lance, puis cliquez-ici pour ne pas renseigner de clef de licence Windows :
Choisissez une version Desktop de Windows, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Sélectionnez l’installation personnalisée de Windows :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Attendez maintenant que l’installation de Windows commence :
Lancez le redémarrage de la machine virtuelle invitée :
Donnez à nom si nécessaire à votre compte local Windows et un mot de passe :
La machine virtuelle invitée avec l’ancien OS Windows est maintenant en place. Comme pour une machine physique, nous allons maintenant générer un fichier VHD afin de pouvoir préparer l’OS à être remonté sur Azure.
Avant cela, quelques modifications sont nécessaires.
Etape III – Génération du fichier VHD :
Sur votre VM hôte (Hyper-V), créez un nouveau dossier contenant une ou plusieurs versions de l’outil Disk2vhd selon l’ancienneté de l’OS concerné :
Créez un second dossier dédié au VHD généré par l’outil Disk2vhd, puis partagez ce dossier sur le réseau :
Depuis la machine virtuelle invitée, ouvrez l’application Disk2vhd depuis le premier partage, puis sauvegardez votre fichier VHD sur le second partage :
Le traitement VSC peut prendre entre 5 minutes et 2 heures :
Le message de succès apparaît alors à la fin du traitement :
Effectuez ces mêmes opérations de génération du fichier VHD pour chacun des OS comme ceci :
Fermez la session utilisateur de votre machine virtuelle invitée :
Eteignez également votre machine virtuelle invitée :
Effectuez ces opérations d’arrêt pour chacune des machines virtuelles invitées :
Les machines virtuelles de départ sont maintenant toutes éteintes. Avant de pouvoir transférer le fichier VHD vers Azure, il est nécessaire d’effectuer plusieurs opérations au niveau de l’OS, mais également du fichier VHD.
Etape IV – Préparation du fichier VHD :
Pour cela, nous allons recréer de nouvelles machines virtuelles identiques, dans lesquelles nous allons passer plusieurs commandes PowerShell.
Toujours sur Hyper-V Manager, cliquez-ici pour créer une nouvelle machine virtuelle invitée :
Cliquez sur Suivant :
Modifier les informations suivantes, puis cliquez sur Suivant :
Choisissez Génération 1 :
Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :
Utilisez le même switch que précédemment, puis cliquez sur Suivant :
Rattachez le nouveau disque VHD généré via Disk2vhd, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :
Une fois la machine virtuelle invitée créée, modifiez le nombre de processeurs virtuels, puis cliquez sur OK :
Répétez les mêmes opérations pour les autres OS, puis double-cliquez sur une nouvelle machine virtuelle invitée :
Cliquez-ici pour lancer le démarrage de la VM invitée :
Depuis le menu Démarrer, recherchez Windows PowerShell ISE en mode administrateur :
Confirmez le risque sécuritaire en cliquant sur Oui :
Ouvrez le fichier de script suivant, disponible sur mon GitHub :
Lancez la commande System File Checker (SFC) afin de vérifier les fichiers systèmes Windows :
sfc.exe /scannow
Quelques minutes plus tard, SFC vous confirme le succès du contrôle :
Lancez la commande netsh afin de réinitialiser les paramètre proxy :
netsh.exe winhttp reset proxy
Ouvrez via CMD en mode administrateur afin de lancez l’utilitaire Diskpart :
Retournez sur le groupe de ressources Azure créé précédemment, constatez la présence d’un disque managé, puis cliquez dessus :
Cliquez ici pour créer la machine virtuelle :
Renseignez les informations de base :
Choisissez la taille de votre VM, puis cliquez sur Suivant :
Sur l’onglet Réseau, reprenez le même réseau virtuel que celui utilisé pour votre machine virtuelle Hyper-V, puis lancez la validation Azure :
Une fois la validation Azure passée, lancez la création des ressources :
Attendez quelques minutes le succès de la création de votre VM, puis cliquez ici :
Attendez quelques minutes le démarrage complet de votre VM :
Vérifiez le bon démarrage de votre VM en actualisant si besoin plusieurs fois le screenshot suivant :
Constatez la présence de l’avertissement Azure suivant :
Renseignez les identifiants renseignés lors de la création de votre VM invitée :
Constatez la bonne ouverture de session Windows :
Une fois la session Windows ouverte, installez l’agent pour les machines virtuelles Azure disponible sur cette page GitHub :
Exécutez le fichier MSI d’installation depuis une session PowerShell avec les droits administrateurs :
Cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Attendez quelques minutes la fin de l’installation de l’agent :
Cliquez sur Terminer :
Quelques minutes plus tard, constatez la disparition de l’alerte Azure sur votre VM :
Vérifiez la bonne relation entre le management Azure et votre VM via le menu suivant :
La commande suivante doit vous retourner la configuration IP renseignée sur votre VM :
Effectuez un test d’arrêt de votre machine virtuelle :
Confirmez votre action en cliquant sur Oui :
Effectuez un test de démarrage de votre machine virtuelle :
Vérifiez le succès des 2 opérations via les notifications Azure :
Cliquez-ici pour rouvrir la session Windows ouverte précédemment via Azure Bastion :
Effectuez les mêmes opérations pour les autres anciens OS à tester :
Conclusion
Par cette démonstration, un portage rapide et en urgence de certaines anciennes versions Windows, client ou serveur, est parfaitement possible. Quelques manipulations de préparation sont nécessaires, mais ces dernières sont fonctionnelles pour les OS suivants :
Grâces à la Marketplace Azure, il est très facile de trouver son bonheur quand on recherche une image particulière, déjà mise à jour et surtout adaptée au contexte du Cloud. Seulement, certaines personnalisations ultérieures sont souvent nécessaires, comme par exemple : la langue affichée. Certains vous diront que fois basique, mais c’est souvent essentiel pour de nombreux utilisateurs non anglophones.
Ayant récemment travaillé sur un environnement Azure Virtual Desktop aux exigences de langues spécifiques, je souhaitais trouver un moyen simple de changer la langue OS d’une machine virtuelle image template fonctionnant sous Windows 11.
Microsoft préconise cette approche pour AVD :
À compter de Windows 11, les comptes d’utilisateur non-administrateurs peuvent désormais ajouter la langue d’affichage et les fonctionnalités de langue correspondantes. Cette fonctionnalité signifie que vous n’aurez pas besoin de préinstaller des modules linguistiques pour les utilisateurs d’un pool d’hôtes personnel.
Pour les pools d’hôtes mis en pool, nous vous recommandons quand même d’ajouter les langues que vous prévoyez d’ajouter à une image personnalisée. Vous pouvez utiliser les instructions de cet article pour les versions à session unique et à plusieurs sessions de Windows 11 Entreprise.
La méthode proposé par Microsoft pour les environnements Azure Virtual Desktop multisessions semble très convaincante et fera l’objet d’un prochain article sur ce blog.
En parallèle de cette méthode, je souhaitais vous en proposer une autre plus ancienne, mais toujours fonctionnelle, pour une VM Azure Virtual Desktop ou non.
Plein de choses sont d’ailleurs déjà possibles via des GPOs, mais je souhaitais configurer la langue directement dans mon image VM template.
Voici donc les quelques chapitres dans mon article :
Pour réaliser mon test, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Commençons par créer une machine virtuelle sous Windows 11.
Etape I – Création d’une machine virtuelle :
Comme vous pouvez le voir dans la copie d’écran ci-dessous, il n’est pas possible de choisir précisément la langue ou le pack de langues de notre OS :
Comme attendu, l’écran de démarrage est par défaut en anglais :
L’interface utilisateur l’est également :
Allons voir dans Language et région :
Seule la langue Anglais (USA) est disponible pour notre utilisateur administrateur :
Seul le pack Anglais (USA) semble installé :
Cela se confirme par la commande suivante :
Get-InstalledLanguage
Toutes les features et le clavier correspondant semblent déjà installés pour ce pack de langue :
Le pays est là encore défini sur USA, peu importe le région Azure utilisée :
De façon logique, le formatage Anglais (USA)y est également appliqué :
Continuons avec l’administration des paramètres de la langue :
Un clic pour consulter les 3 types de paramétrage :
Que ce soit pour l’utilisateur actuel, l’écran d’accueil ou pour un nouvel utilisateur, tout est configuré en Anglais (USA):
Maintenant, notre but est donc de modifier la configuration en Anglais vers une configuration Français (Suisse). Pour cela, je me suis inspiré de l’article suivant écrit par Alexandre Verkinderen pour y parvenir.
Etape II – Modification de la langue via script :
Commençons par ouvrir une fenêtre PowerShell ISE :
Vérifions une seconde fois le ou les packs de langue installés par la commande suivante :
Get-InstalledLanguage
Exécuter le script PowerShell suivant en prenant soin de modifier certaines variables :
$regionalsettingsURL (ne pas modifier) : méhode automatisée ancienne, mais toujours valable et basée sur un fichier XML de configuration source
$RegionalSettings (ne pas modifier) : fichier XML de configuration de destination
$Language : modifier au besoin le language (liste)
Azure est une excellente plateforme pour déployer rapidement et facilement des ressources IT. Seulement, la phase de déploiement de ressources ne représente que la première partie du travail d’une infrastructure. Bien souvent, plusieurs agents ou équipes interviendront sur ces mêmes ressources Azure. Un système de suivi des changements apparait alors comme très utile pour traquer efficacement les modifications faites par les uns et par les autres.
Qu’est-ce que le Suivi des modifications et inventaire (Change Tracking et Inventory) ?
En quelques mots, le Suivi des modifications et inventaire va vous permettre de comprendre les modifications faites sur vos ressources Azure, mais aussi à l’intérieur de celles-ci.
Voici un exemple de 2 vues disponibles retraçant différents types de modifications :
Le Suivi des modifications et inventaire effectue le suivi des modifications apportées aux machines virtuelles hébergées sur Azure, locales et d’autres environnements cloud pour vous aider à identifier les problèmes opérationnels et environnementaux liés aux logiciels gérés par le gestionnaire de package de distribution.
On y retrouve donc des modifications de registres, de fichiers, de programmes et bien d’autres encore.
Que pouvons-nous traquer dans le Suivi des modifications et inventaire ?
A ce jour, plusieurs éléments sont traçables au travers du Suivi des modifications et inventaire. Voici la liste des modifications traçables :
Logiciels Windows
Logiciel Linux (packages)
Fichiers Windows et Linux
Clés de Registre Windows
Services Windows
Démons Linux
Doit-on payer pour utiliser Suivi des modifications et inventaire?
Oui. En effet, le Suivi des modifications et inventaire est un service payant. Il repose sur stockage appelé Log Analytics Workspace pour stocker les données liées aux modifications. Comme à chaque fois, le Log Analytics Workspace est facturé au Go de données écrites.
Niveau agent : AMA ou MMA, lequel choisir ?
Microsoft avait annoncé la préversion de Suivi des modifications et inventaire via l’agent AMA en janvier 2023. L’agent AMA prend le pas sur l’agent LOA pour des raisons de sécurité, de fiabilité, et facilite également les multi-environnements. De plus, il n’est plus nécessaire d’intégrer un compte Azure Automation.
D’ailleurs Microsoft a également annoncé une date de retrait pour MMA/LOA :
Actuellement, le suivi des modifications et l’inventaire utilisent Log Analytics Agent et son retrait est prévu d’ici le 31 août 2024. Nous vous recommandons d’utiliser Azure Monitoring Agent comme nouvel agent de prise en charge.
Il existe des différences entre un agent et une extension. Microsoft apporte sur cette page quelques infos bien utiles :
Agent : Il s’agit d’une application légère, toujours en cours d’exécution (le plus souvent exécutée en tant que service/daemon), qui collecte des informations auprès de la machine et les transmet quelque part ou maintient l’état de la machine elle-même en fonction d’une certaine configuration.
Extension : Dans Azure, les extensions fournissent des tâches de configuration et d’automatisation post-déploiement sur les VM Azure. Les extensions peuvent faire partie de la définition de la VM elle-même, et donc être utilisées pour déployer quelque chose dans le cadre du déploiement de la ressource hôte elle-même. Dans le cas d’Azure Monitor, il existe des extensions qui déploient l’agent de surveillance dans le cadre du déploiement de la VM/VMSS.
AzureMonitoringWindowsAgent : Il s’agit de l’extension la plus récente et la plus recommandée d’Azure Monitor Agent (AMA) pour une VM. Elle est disponible pour les VM Windows avec le nom AzureMonitoringWindowsAgent. De même, AzureMonitorLinuxAgent est le nom de l’extension pour l’AMA sur la VM Linux.
MMAExtension : C’est le nom de l’extension qui installe l’ancien agent sur la VM Windows. L’agent lui-même est appelé Log Analytics Agent ou LA Agent, également appelé « Microsoft Monitoring Agent » ou MMA. Pour les machines virtuelles Linux, cette extension installe un paquetage d’agent appelé OMSAgentforLinux.
Enfin, cette page détaille les différences techniques des agents en relation avec Azure Monitor.
Afin de bien comprendre ce que le Suivi des modifications et inventaire d’Azure est capable de faire avec un agent AMA, je vous propose de suivre ce petit exercice :
Pour réaliser cet exercice sur le Suivi des modifications et inventaire d’Azure, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer une machine virtuelle.
Etape I – Préparation de l’environnement :
Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :
Cliquez-ici pour commencer la création de la machine virtuelle :
Renseignez les informations de base relatives à votre VM :
Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :
Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :
Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Les notifications suivantes devraient apparaitre :
Sans attendre la fin du déploiement d’Azure Bastion, recherchez le service Log Analytics Workspace :
Cliquez-ici pour déployer votre Log Analytics Workspace :
Renseignez tous les champs dont son nom devant être unique sur Azure :
Attendez maintenant que le Log Analytics Workspace et Azure Bastion soient entièrement déployés pour continuer cet exercice.
Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :
Notre environnement de base est maintenant en place. Nous allons pouvoir continuer en activant le service Suivi des modifications et inventaire.
Etape II – Activation du Suivi des modifications et inventaire :
Pour cela, retournez sur votre machine virtuelle afin d’activer le Suivi des modifications et inventaire en utilisant un agent AMA :
La mise en place de ce service déploie 2 extensions sur votre machine virtuelle et vous invite à patienter :
Quelques minutes plus tard, consultez les extensions installées sur votre machine virtuelle :
Afin que toutes les modifications soient bien prises en compte dans le Suivi des modifications et inventaire, je vous conseille d’attendre 30 minutes avant de continuer la suite de cet exercice.
Etape III – Sauvegarde des évènements Azure :
La sauvegarde d’évènements Azure est utile afin de bien comprendre par exemple les modifications faites directement sur les ressources Azure.
Pour cela, cliquez sur le menu suivant dans votre machine virtuelle :
Puis cliquez-ici :
Enfin cliquez-ici pour connecter votre journal d’activité Azure :
Quelques secondes plus tard, constatez le bon changement du statut de la connexion :
Effectuez ensuite un changement de taille de votre machine virtuelle :
Attendez que le redimensionnement soit terminé :
Quelques minutes plus tard, constatez l’apparition d’une ligne d’évènement dans le Suivi des modifications et inventaire :
Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi des fichiers Windows.
Etape IV – Sauvegarde du suivi de fichiers Windows :
Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :
Ajoutez la règle de fichiers Windows, puis cliquez sur Ajouter :
Sur votre machine virtuelle de test, créez le fichier correspondant à votre règle de suivi :
Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :
Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi du registre Windows.
Etape V – Sauvegarde du suivi du registre Windows :
Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :
Ajoutez la règle de registre Windows, puis cliquez sur Ajouter :
Sur votre machine virtuelle de test, créez la clef de registre correspondante à votre règle :
Quelques minutes plus tard, constatez l’apparition d’une ligne de changement dans le Suivi des modifications et inventaire :
Continuons les tests du Suivi des modifications et inventaire en ajoutant le suivi des services Windows.
Etape VI – Sauvegarde du suivi de services Windows :
Modifiez si besoin la fréquence des remontées d’informations sur les services Windows :
Sur votre machine virtuelle de test, lancez le script PowerShell d’installation suivant :
Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :
Continuons les tests du Suivi des modifications et inventaire en modifiant la sauvegarde du suivi des modifications du contenu de fichiers.
Etape VII – Sauvegarde du suivi des modifications du contenu de fichiers :
Avant d’activer la fonction du suivi des modifications de fichiers, recherchez le service des comptes de stockage Azure :
Créez un compte de stockage dédié à la fonction du suivi de modification des fichiers :
Nommez votre compte de stockage, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du compte de stockage, puis attendez environ 1 minute :
Une fois le compte de stockage créé, retournez dans la configuration du Suivi des modifications et inventaire afin d’y ajouter ce dernier :
Choisissez votre compte de stockage, puis cliquez sur Sauvegarder :
Retournez sur votre compte de stockage, puis ouvrez le conteneur suivant créé automatiquement par le Suivi des modifications et inventaire :
Cliquez-ici pour ajouter des droits RBAC sur ce conteneur blob :
Choisissez le rôle ci-dessous, puis cliquez sur Suivant :
Ajoutez l’identité managée de votre machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de l’assignation RBAC :
Modifiez le contenu d’un fichier de texte présent sur votre machine virtuelle de test, puis retournez sur votre compte de stockage afin de constater le téléversement du fichier modifié quelques minutes plus tard :
Terminons les tests du Suivi des modifications et inventaire en installant un logiciel sur la machine virtuelle.
Etape VIII – Inventaire des logiciels :
Téléchargez par exemple Google Chrome depuis une source officielle :
Lancez son installation :
Quelques minutes plus tard, Google Chrome apparait bien dans le Suivi des modifications et inventaire en tant qu’application installée :
Conclusion
Bien que le Suivi des modifications et inventaire soit très intéressant dans certains scénarios, je ne sais pas ce que l’avenir va donner sur cet outil Microsoft.
Un autre outil très intéressant et accessible sans aucun déploiement est le Change Analysis. Cet outil ne fait pas la même chose que le Suivi des modifications et inventaire.
Comme la copie d’écran ci-dessous le montre, Change Analysis est un moyen simple et rapide de voir les changement de propriétés effectués sur une ressources Azure :
Pour rester sur le sujet, John Savill a également fait une vidéo très intéressante sur la gestion des modifications Azure et les alertes possibles :
Enfin, un autre outil présent nativement dans Azure pourra vous aider dans votre investigation Azure, il appelé Resource Explorer :
Il y a quelques jours, Microsoft vient d’annoncer une nouvelle fonctionnalité de migration très intéressante pour les machines virtuelles déjà en place : la possibilité de déplacer une machine virtuelle, actuellement non zonée, vers une zone précise de la région Azure.
Pourquoi faire ? Pour accroitre la résilience de l’infrastructure 🙏
En revanche, la possibilité d’utiliser ce type de migration dépendra de votre scénario actuel :
Scénario
Assistance technique
Détails
Machine virtuelle à instance unique
Prise en charge
Le déplacement régional vers zonal de machines virtuelles à instance unique est pris en charge.
Machines virtuelles au sein d’un groupe à haute disponibilité
Non pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration uniforme
Non pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexible
Non pris en charge
Régions prises en charge
Prise en charge
Seules les régions prises en charge par la zone de disponibilité sont prises en charge. En savoir plus sur les détails de la région.
Machines virtuelles déjà situées dans une zone de disponibilité
Non pris en charge
Le déplacement interzone n’est pas pris en charge. Seules les machines virtuelles qui se trouvent dans la même région peuvent être déplacées vers une autre zone de disponibilité.
Extensions de machine virtuelle
Non pris en charge
Le déplacement de machine virtuelle est pris en charge, mais les extensions ne sont pas copiées sur une machine virtuelle zonale cible.
Machines virtuelles avec lancement fiable
Prise en charge
Réactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentielles
Prise en charge
Réactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles de 2e génération (démarrage UEFI)
Prise en charge
Machines virtuelles dans des groupes de placement de proximité
Prise en charge
Le groupe de placement de proximité source (PPG) n’est pas conservé dans la configuration zonale.
VM spot (machines virtuelles de basse priorité)
Prise en charge
Machines virtuelles avec hôtes dédiés
Prise en charge
L’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activée
Prise en charge
Machines virtuelles créées à partir d’images de la Place de marché
Prise en charge
Machines virtuelles créées à partir d’images personnalisées
Prise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)
Prise en charge
Stratégies RBAC de machine virtuelle
Non pris en charge
Le déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible.
Pour réaliser cet exercice sur la bascule d’une VM dans une zone d’Azure, il vous faudra disposer des éléments suivants :
Un tenant Microsoft
Une souscription Azure valide
Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle non Zonée (ou Régionale).
Etape I – Préparation de la VM Régionale :
Pour cela, rechercher le service Machines virtuelles sur le portail Azure :
Cliquez-ici pour commencer la création de la première machine virtuelle :
Renseignez les informations de base relatives à votre VM en choisissant aucune redondance :
Choisissez la taille de votre VM, définissez un compte administrateur local, bloquer les ports entrants, puis cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :
Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :
Ouvrez une ou plusieurs applications en enregistrant le travail effectué :
Notre première machine virtuelle non-zonée ou régionale est maintenant opérationnelle. Nous pouvons dès à présent lancer le processus de migration vers la zone souhaitée.
Etape II – Déplacement de la VM Régionale dans une Zone :
Pour commencer ce processus, rendez-vous dans l’un des 2 menus suivants :
Cliquez sur le menu à gauche appelé Disponibilité + dimensionnement.
Cliquez sur le bouton d’édition à droite pour modifier la Zone de disponibilité.
Cliquez-ici pour démarrer le processus de migration :
Choisissez la zone cible pour la migration :
Il est possible que certaines zones cibles vous soit refusées pour des questions de capacités.
Attendez environ 2-3 minutes afin qu’Azure mette en place les droits RBAC nécessaires pour procéder à la migration :
Une notification Azure apparaît également :
Un nouveau groupe de ressources est créé par cette même occasion :
Des droits RBAC sont également générés au niveau de la souscription Azure concernée :
Une fois le traitement terminé, l’écran suivant apparait, modifiez les champs au besoin :
Dans mon cas, j’ai modifié les valeurs suivantes, puis j’ai cliqué sur Valider :
Création d’un nouveau groupe de ressources
Création de nouvelles ressources pour tous les objets existants
Modification des noms des ressources
La validation entraine une seconde vérification des paramètres modifiés :
Une nouvelle notification Azure apparait indiquant que le traitement est en cours :
Environ 30 secondes plus tard, le traitement de validation se termine :
Lancez le déplacement des ressources en cochant la case ci-dessous, puis en cliquant sur Déplacer :
Le traitement démarre et vous informe que celui-ci durera plusieurs minutes :
Le nouveau groupe de ressources Azure se créé avec les ressources commencent également à y apparaître :
La session de bureau à distance ouverte via Azure Bastion sur la première machine virtuelle se ferme, comme attendu :
Un rapide contrôle du statut de la première machine virtuelle nous montre que cette dernière s’est bien arrêtée :
Le groupe de ressource créé par le service de déplacement nous montre la présence d’une collection de points de restauration :
Il s’agit d’un snapshot de la VM créé provisoirement.
Celle-ci contient bien un point de restauration lié au traitement de migration de la VM :
Environ 5 minutes plus tard, l’écran nous indique que le traitement est terminé. On y apprend également plusieurs choses :
La première machine virtuelle a bien été arrêtée, mais n’a pas été supprimée
La seconde machine virtuelle est bien démarrée et est localisée dans la zone 3
Des consignes post-déploiement sont même affichées afin de vous guider sur la suite :
Le nouveau groupe de ressources créé par la migration montre bien toutes les ressources configurées selon les options renseignées :
De retour dans le groupe de ressources précédent, la collection des points de restauration a disparu après la migration :
Etape III – Contrôle de la VM zonée :
Les deux machines virtuelles sont bien présentes et visibles, cliquez sur la nouvelle VM :
Vérifiez la présence de la zone 3, puis cliquez sur le Editer :
Microsoft vous indique qu’il n’est pas encore possible de déplacer des ressources entre les zones dans une région Azure :
Cette information de zone de notre machine virtuelle est aussi disponible ici :
Comme un nouveau réseau virtuel a été recréé dans mon exemple, pour me connecter en RDP, je dois effectuer une des actions suivantes :
Redéployer un service Azure Bastion
Utiliser l’adresse IP publique
Appairer les 2 réseaux virtuels entre eux
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la première VM :
Vérifiez la présence du travail effectué précédemment :
Etape IV – Nettoyage des ressources non zonées :
Important : l’infrastructure existante telle que les VNET, les sous-réseaux, les NSG, les LB, … tirent déjà parti d’une configuration zonale, nous aurions pu les garder au lieu d’en recréer.
Si tout est OK pour vous, il ne vous restera qu’à supprimer les deux groupes de ressources suivants :
Groupe de ressources contenant l’ancienne machine virtuelle
Groupe de ressource contenant les composants liés à la migration
La suppression d’un groupe de ressources Azure s’effectue très simplement :
Confirmez l’ordre de suppression :
Conclusion
Microsoft automatise tous les jours un peu plus certaines tâches manuelle au fil des améliorations faites à Azure. Tous les gains d’efficacité doivent également profiter aux ressources déjà déployées.
On pourra peut-être bientôt voir le même type de processus automatisé intégrer des machines virtuelles existantes dans des Availability Sets ou des Proximity placement groups 😎
En cas de sinistre informatique, il n’y a aucun moyen de savoir ce qui peut frapper ou comment votre l’infrastructure peut en être affectée. Toutefois, en adoptant une approche réfléchie de la planification en cas de catastrophe, vous créer une tranquillité d’esprit si votre entreprise devait être confrontée à un sinistre.
Azure Site Recovery : permet d’assurer la continuité de l’activité en maintenant l’exécution des charges de travail et applications métier lors des interruptions. Site Recovery réplique les charges de travail s’exécutant sur des machines virtuelles et physiques depuis un site principal vers un emplacement secondaire.
En cas d’interruption au niveau de votre site principal, vous basculez vers un emplacement secondaire, depuis lequel vous pouvez accéder aux applications. Quand l’emplacement principal est de nouveau fonctionnel, vous pouvez effectuer une restauration automatique vers celui-ci.
Pour réaliser cet exercice sur Azure Site Recovery, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Important : Pour cela, je vous propose de simuler deux serveurs sous Windows Server 2019 grâce à un environnement virtualisé de type Hyper-V hébergé lui sur Azure
Dans Azure, il est en effet possible d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.
Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :
Renseignez tous les champs de base de votre machine virtuelle Hyper-V :
Choisissez une taille de machine virtuelle présent dans la famille Dsv3 :
Définissez un compte administrateur local, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la machine virtuelle invitée (Windows 11),créée plus tard dans notre machine virtuelle hôte (Hyper-V) :
Conservez les options par défaut, puis cliquez sur OK :
Cliquez ensuite sur Suivant :
Retirez l’adresse IP publique (pour des questions de sécurité), puis cliquez sur Suivant :
Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 3 minutes :
Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle Hyper-V :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Attendez environ 5 minutes qu’Azure Bastion soit déployé pour continuer cet exercice :
La notification suivante vous indique alors le succès de la création d’Azure Bastion :
La configuration Azure est maintenant terminée, la suite va se passer sur la machine virtuelle Hyper-V.
Etape II – Configuration Hyper-V :
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :
Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble deux machine virtuelles :
Windows Server 2019 pour jouer le rôle d’Appliance Azure Site Recovery
Windows Server 2019 pour jouer le rôle d’un serveur on-premise
Etape III – Création des machines virtuelles (Appliance / SRV) :
Pour cela, il est nécessaire de récupérer une image au format ISO de Windows Server 2019 afin de créer la machine virtuelle Appliance, puis d’y installer l’OS.
Toujours sur la machine virtuelle hôte (Hyper-V), ouvrez le navigateur internet Microsoft Edge.
Rendez-vous sur la page suivante pour télécharger l’ISO de Windows Server 2019, puis effectuez les actions suivantes :
Attendez quelques minutes pour que le téléchargement de l’ISO se termine :
Depuis votre VM hôte (Hyper-V), rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre première machine virtuelle Appliance :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :
Pensez à bien choisir Génération 2 :
Modifier la taille de la mémoire vive allouée à la VM Appliance, puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO de Windows Server 2019 téléchargé précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle archive :
Modifiez le nombre de processeurs virtuels, puis cliquez sur OK :
Cliquez-ici pour lancer le démarrage de la VM archive :
Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows Server 2019 :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows Server 2019 :
Choisissez une version suivante de Windows Server 2019, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Sélectionnez l’installation personnalisée de Windows Server 2019 :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Attendez maintenant que l’installation de Windows Server 2019 commence :
En attentant que l’installation de Windows Server 2019 se finisse sur la machine virtuelle Appliance, créez une seconde machine virtuelle appelée et SRV de génération 1 :
De la même manière que pour la VM appliance, lancez l’installation de Windows Server 2019 sur la VM SRV :
Une fois les deux installations terminées, définissez un mot de passe pour le compte administrateur local :
Sur les 2 VMs, renseignez le mot de passe administrateur pour ouvrir une sessions Windows :
Désactivez la sécurité Internet Explorer, puis cliquez sur OK :
Depuis Internet Explorer, recherchez puis installez Edge :
Nous deux machines virtuelles sont correctement installées. La suite consiste à mettre en place l’appliance d’Azure Site Recovery.
Etape IV – Configuration Azure Site Recovery :
Retournez sur le portail Azure afin de créer le Coffre de restauration (Azure Recovery Vault) :
Renseignez les informations de base de votre Coffre de restauration, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de Coffre de restauration, puis attendez environ 1 minute :
Une fois le déploiement terminé, cliquez-ici pour commencer la configuration de Coffre de restauration :
Préparer l’infrastructure on-premise en cliquant ici :
Cliquez sur le lien suivant afin d’ouvrir la documentation Microsoft :
Copiez le lien ci-dessous (ou ici) afin de télécharger l’appliance dédiée à Azure Site Recovery :
Collez ce lien dans la machine virtuelle Appliance, puis attendez la fin du téléchargement :
Une fois l’archive ZIP téléchargé, ouvrez le dossier contenant celle-ci :
Avant de décompresser l’archive ZIP, débloquez celle-ci grâce à la case suivante, puis cliquez sur OK :
Lancez l’extraction dans le dossier de votre choix :
Attendez environ 3 minutes que l’archive ZIP se décompresse en totalité :
Sur la machine virtuelle Appliance, ouvrez une session PowerShell, puis positionnez-vous le dossier où l’archive ZIP a été extraite :
Lancez la commande PowerShell suivante :
.\DRInstaller.ps1
Confirmez la réponse avec Y :
Attendez environ 2 minutes que le traitement PowerShell se termine :
Vérifiez qu’aucune erreur n’a été remontée dans la fenêtre PowerShell :
Toujours sur la VM Appliance, retrouvez le dossier Software créé à la racine du disque Q afin de modifier ses propriétés :
Dans l’onglet Partage, cliquez sur le bouton Partager :
Confirmez les utilisateurs voulus, puis cliquez sur Partager :
Copiez le chemin du partage puis fermez la fenêtre de configuration du partage :
Lancez les 2 actions suivantes respectivement sur les deux VMs :
Sur la machine virtuelle Appliance, ouvrez Microsoft Azure Appliance Configuration Manager (présent sur le bureau )
Sur la machine virtuelle SRV, utilisez l’explorateur Windows pour vous rendre sur le chemin du partage activé précédemment
Sur la VM Appliance, vérifiez le bon fonctionnement réseau ainsi que les préconisations minimales, puis cliquez sur Continuer :
Attendez le contrôle de version, puis cliquez sur Continuer :
Cliquez sur Sauvegarder :
Cliquez sur Continuer :
Coller la clef précédemment présentée sur votre Coffre de restauration Azure, puis cliquez sur Login :
La fenêtre suivante s’ouvre afin que vous puissiez copier le code d’identification dans Azure :
Renseignez ce code dans la fenêtre d’authentification Azure, puis cliquez sur Suivant :
Renseignez vos identifiants Azure :
Réussissez le challenge MFA si nécessaire :
Cliquez sur Continuer afin d’autoriser la configuration avec Azure :
Vérifiez la confirmation Azure :
Attendez que l’enregistrement sur Azure se termine :
Cliquez sur Continuer :
Cochez la case suivante puis cliquez sur Continuer :
Ajoutez les informations relatives (identifiants / IP) à la machine virtuelle SRV :
Une fois ces informations renseignées, cliquez sur Continuer :
Comme indiqué, attendez jusqu’à 30 minutes que le traitement se termine :
En attendant, lancez l’installation de l’agent sur la machine virtuelle SRV disponible sur le partage réseau activé précédemment :
Cliquez sur Suivant :
Attendez environ 2 minutes que l’installation se termine :
Une fois l’installation terminée, cliquez ici pour configurer l’agent :
Copiez les détails de la machine virtuelle SRV dans le bloc-notes :
Créez sur le partage réseau un fichier texte contenant les détails de la machine virtuelle SRV, collez le contenu de ce fichier texte sur la machine virtuelle Appliance, puis téléchargez le fichier de configuration :
Sauvegardez le fichier de configuration téléchargé précédemment sur le partage réseau, puis insérez le dans la configuration de la machine virtuelle SRV :
Lancez le traitement de configuration, puis attendez environ 1 minute :
Cliquez sur terminer une fois tous les voyants au vert :
De retour sur Azure, vérifiez la bonne configuration de l’infrastructure de reprise dans le Coffre de restauration :
La configuration d’Azure Site Recovery est maintenant terminée. La prochaine étape consiste en la mise en place de la réplication vers Azure.
Etape V – Activation de la réplication :
Activez la réplication de votre VM SRV via le menu suivant :
Choisissez votre VM SRV dans la liste des machines à répliquer, puis cliquez sur Suivant :
Cliquez sur Suivant :
Renseignez tous les champs ci-dessous, puis cliquez sur Suivant :
Activez la réplication Azure :
Une première notification Azure apparaît pour vous signaler la mise en place des ressources :
Puis une seconde notification Azure apparaît pour vous indiquer le démarrage de la réplication de votre VM SRV :
Un clic sur cette notification nous affiche toutes les étapes et travaux réalisés au sein du Coffre de restauration :
Environ 10 minutes, une nouvelle notification nous indique le succès de la configuration de réplication :
Cliquez ici pour suivre l’avancement de la réplication des données vers Azure :
La machine virtuelle SRV est maintenant répliquée dans Azure. Nous allons maintenant pouvoir tester la réplication ASR via la fonction de bascule (failover).
Etape VI – Test de la réplication :
Environ 45 minutes après, la machine virtuelle SRV est enfin répliquée dans Azure et son statut change en Protégée :
Environ 30 secondes plus tard, le traitement est exécuté avec succès :
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les mêmes identifiants administrateurs :
Réouvrez le fichier image créé précédemment avant la bascule :
Conclusion :
Malgré une mise en place un peu longue et des exigences de puissance CPU / Mémoire concernant la machine virtuelle appliance, la mise en place d’Azure Site Recovery a bien fonctionné. Que demandez de plus 😎🥳
Peu importe l’architecture IT choisie, celle-ci coûtera toujours « trop cher » aux yeux de clients potentiels. Le Cloud n’échappe pas à cette règle, et demande donc tous les efforts possibles pour maitriser au mieux les coûts des ressources déployées. Microsoft annonce en préversion publique une fonctionnalité dédiée à la mise en veille des machine virtuelles : l’hibernation.
Qu’est-ce que l’hibernation ?
Hibernation : état d’hypothermie régulée, durant plusieurs jours ou semaines qui permet aux animaux de conserver leur énergie pendant l’hiver. Durant l’hibernation, les animaux ralentissent leur métabolisme jusqu’à des niveaux très bas, abaissant graduellement la température de leur corps et leur taux respiratoire, et puisent dans les réserves de graisse du corps qui ont été stockées pendant les mois actifs.
Azure voit les VMs de la même manière que les mammifères 🤣:
Lorsqu’on hiberne une VM Azure : ce dernier échange avec l’OS afin de stocker le contenu de la mémoire de la VM sur le disque du système d’exploitation, puis désalloue la VM.
Lorsque la VM est redémarrée et sort d’hibernation : le contenu de la mémoire est retransféré du disque OS vers la mémoire. Cela permet alors de retrouver les applications et processus en cours d’exécution.
En quelques lignes, une machine virtuelle allumée regroupe les principaux coûts suivants :
Le Calcul (CPU/Mémoire): le coût du service calcul va dépendre de sa taille, donc de sa technologie, de son nombre de coeurs et de sa taille de mémoire.
Le Stockage (Disques): Bien souvent, de l’information a besoin d’être stockée dans une architecture. Qu’elle soit utilisée par le service de calcul, mise à disposition pour des accès externes ou pour des besoins de sauvegarde, le stockage disposera généralement de 3 variables : taille (Go; To), débit (Mo/sec; Go/sec) et puissance transactionnelle (IOPS).
Le Réseau (Carte réseau): Une VM Azure a besoin de communiquer avec des utilisateurs ou d’autres ressources IT. Comme pour le stockage, la tarification réseau repose sur des variables : taille de la bande passante et le volume de données en transition.
La licence logicielle (OS): Là encore, la VM Azure sera souvent exploitée par un système d’exploitation et/ou logiciel, dont certains fonctionnent sous licence payante. Dans l’exemple des licences Microsoft, comme Windows Server ou SQL Server, la tarification Azure repose sur la taille du service de calcul, comme le nombre de coeurs des machines virtuelles.
Combien coûte une machine virtuelle éteinte ?
Une machine virtuelle même si les ressources sont désallouées coûte toujours :
Le Stockage (Disques) est une resource constamment allouée.
Le Réseau (Carte réseau): certaines ressources, comme les adresses IP publiques, peuvent être constamment allouées.
Combien coûte une machine virtuelle en hibernation ?
De la même manière que dans un état désalloué, la machine virtuelle continuera de coûter pour le stockage utilisé par les disques et aussi certaines ressources réseaux.
Pourquoi utiliser l’hibernation au lieu d’éteindre la VM ?
Microsoft nous détaille des scénarios envisageables pour ce mode Pause :
Les postes de travail virtuels, le développement/test et d’autres scénarios où les machines virtuelles n’ont pas besoin de fonctionner 24 heures sur 24 et 7 jours sur 7. Les systèmes dont les temps de démarrage sont longs en raison d’applications gourmandes en mémoire.
Quelles sont les VMs compatibles avec le mode Hibernation ?
Plusieurs limitations à l’hibernation sont ainsi actuellement en vigueur, et vont certainement évoluer par la suite :
Ne s’active pas sur des VMs déjà déployées
Aucun redimensionnement SKU possible sur des VMs ayant la fonctionnalité hibernation
Fonction d’hibernation est non désactivable après l’activation
Limitations de compatibilité selon l’OS :
Linux (dépourvue de Trusted Lunch) :
Ubuntu 22.04 LTS
Ubuntu 20.04 LTS
Ubuntu 18.04 LTS
Debian 11
Debian 10 selon noyau
Windows (page file hors disque D):
Windows Server 2022
Windows Server 2019
Windows 10/11 (Pro / Enterprise / multisession)
Uniquement certains SKUs supportent actuellement l’hibernation :
Dasv5-series
Dadsv5-series
Dsv5-series
Ddsv5-series
Important : Comme pour une VM désallouée, le risque est toujours présent lors du redémarrage si la VM hibernée, car elle nécessite des ressources potentiellement non disponibles à l’instant T.
Afin de se faire une meilleure idée sur l’hibernation d’Azure, je vous propose de réaliser un petit exercice combinant 2 exemples de VMs. Nous allons détailler toutes les étapes nécessaires, de la configuration aux tests :
Pour réaliser cet exercice sur l’hibernation de machines virtuelles Azure, il vous faudra disposer des éléments suivants :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Préparation de l’environnement Azure :
Avant de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’activer cette dernière sur la souscription Azure concernée.
Pour cela, rendez-vous dans le portail Azure, sur la page des fonctionnalités en préversion de votre souscription, puis effectuez une activation en recherchant celle-ci comme ci-dessous :
Attendez environ une minute que votre demande soit acceptée par Microsoft :
La notification suivante vous indique alors le succès de l’opération :
La suite consiste maintenant à créer une première machine virtuelle compatible et avec l’hibernation activée.
Etape II – Création d’une machine virtuelle compatible :
Pour cela, rechercher le service Machines virtuelles sur le portail Azure :
Cliquez-ici pour commencer la création de la première machine virtuelle :
Renseignez les informations de base relatives à votre VM en choisissant bien une image OS Windows 11 Pro, puis cliquez ici pour afficher les tailles de VMs :
Choisissez la taille de votre VM parmi l’une des séries suivantes :
Dasv5-series
Dadsv5-series
Dsv5-series
Ddsv5-series
Si la case d’hibernation est toujours grisée, attendez encore 10-20 minutes avant de retenter l’opération de création :
Si la case d’hibernation est disponible, cochez celle-ci, définissez un compte administrateur local, bloquer les ports entrants, cochez la case concernant le droit de licence, puis cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Créez un nouveau réseau virtuel, retirez l’adresse IP publique, puis cliquez sur Suivant :
Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 3 minutes :
Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :
Consultez l’extension automatiquement installée sur votre VM pour rendre fonctionnel l’Hibernation d’Azure :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Attendez environ 5 minutes qu’Azure Bastion soit déployé pour continuer cet exercice :
La notification suivante vous indique alors le succès de la création d’Azure Bastion :
Notre première machine virtuelle est enfin prête. Afin de bien mesurer l’impact de l’hibernation d’Azure, connectons-nous à la VM pour y ouvrir différents programmes.
Etape III – Test de l’hibernation :
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :
Attendez que la session Windows 11 s’ouvre avec le compte local :
Cliquez sur Suivant :
Cliquez sur Accepter :
Ouvrez plusieurs applications sans enregistrer les travails effectués :
Rendez-vous sur la page Azure de votre machine virtuelle, puis cliquez sur Hiberner :
Confirmez votre choix en cliquant sur Oui :
Attendez environ 1 minute :
La session ouverte via Bastion se retrouve alors automatiquement déconnectée, cliquez sur Fermer :
La notification suivante vous indique alors le succès de l’opération d’hibernation :
Un nouveau statut apparaît alors sur votre première machine virtuelle :
Afin de redémarrer la première VM, cliquez-ici :
Attendez environ 1 minute que la première VM soit redémarrée :
Réouvrez à nouveau une session via Azure Bastion avec les mêmes identifiants :
Constatez la réapparition des applications ouvertes avec les travails non enregistrés :
Cette première étape nous montre la facilité de mise en place de l’hibernation et l’intérêt potentiel pour les charges de travail variables ou discontinues.
Continuons cet exercice avec une seconde machine virtuelle créée cette fois-ci sans l’option d’hibernation.
Etape IV – Création d’une machine virtuelle incompatible :
Renseignez les informations de base relatives à votre seconde VM en choisissant bien une image OS Windows 11 Pro, puis en ne cochant pas la case hibernation :
Une fois la seconde VM créée, vérifiez que la fonction Hiberner est bien grisée pour celle-ci :
Ouvrez la page Azure du disque OS de celle-ci afin de créer un snapshot de ce dernier :
Renseignez les informations de base relatives à votre snapshot, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du snapshot, puis attendez environ 1 minute :
Une fois le déploiement terminé, cliquez-ici pour consulter le snapshot de votre disque :
Cliquez-ici pour créer un nouveau disque OS à partir de ce snapshot :
Renseignez les informations de base relatives à ce nouveau disque OS, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du disque OS, puis attendez environ 1 minute :
Continuons avec une troisième machine virtuelle créée cette fois-là avec l’option d’hibernation :
Arrêtez cette troisième machine virtuelle via la fonction d’arrêt :
Confirmez votre choix en cliquant sur Oui :
Toujours sur cette troisième VM, allez sur la page des disques afin de basculer vers le disque précédemment généré depuis le snapshot de la seconde VM :
Choisissez le seul disque disponible et issu du snapshot, puis cliquez sur OK :
La notification suivante vous indique alors le succès de l’opération de bascule des disques OS :
Redémarrer la troisième machine virtuelle Azure :
Une fois redémarrée, vérifiez la présence de la fonctionnalité Hiberner :
Consultez l’extension installée sur votre troisième VM :
Afin de vérifier que l’hibernation Azure fonctionne bien sur cette nouvelle VM issue du snapshot de la seconde, connectons-nous à celle-ci pour y ouvrir différents programmes.
Etape V – Test de l’hibernation :
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la seconde VM :
Attendez que la session Windows 11 s’ouvre avec le compte local :
Cliquez sur Suivant :
Cliquez sur Accepter :
Ouvrez une ou plusieurs applications sans enregistrer les travails effectués :
De retour sur la page Azure de votre troisième machine virtuelle, puis cliquez sur Hiberner :
Confirmez votre choix en cliquant sur Oui :
Encore une fois, la session ouverte via Bastion se retrouve automatiquement déconnectée, cliquez sur Fermer :
La notification suivante vous indique alors le succès de l’opération d’hibernation :
Le statut apparaît alors sur votre troisième machine virtuelle, cliquez-ici afin de la redémarrer :
Attendez environ 1 minute que la VM soit redémarrée :
Réouvrez à nouveau une session via Azure Bastion avec les mêmes identifiants :
Constatez là encore la réapparition des applications ouvertes et les travails non enregistrés :
Conclusion
La fonction d’hibernation marque ici une vraie différence dans la gestion offline de machine virtuelle. Plus pratique que l’arrêt complet dans bon nombre de situations, l’hibernation pourrait devenir la norme en s’intégrant de la manière native dans beaucoup de service Azure, comme les groupe de machines virtuelles identiques ou encore Azure Virtual Desktop.
La date 10 octobre 2023 arrive à grand pas ! Non ce n’est pas l’anniversaire d’un de vos proche que vous auriez oublié … mais bien la Fin de support programmée pour Windows Server 2012 et 2012R2. A partir de cette date, plus aucune mise à jour de sécurité ne sera disponible sans l’achat des ESUs (Extended Security Updates), ou suite à une migration vers Azure ou Azure Stack HCI (solution de Cloud hybride proposé par Microsoft). 😥😥
0
Years
:
0
Months
:
0
J
:
0
H
:
0
M
:
0
S
Pour continuer de plomber l’ambiance, voici d’ailleurs le calendrier des échéances passées et futures :
Que peut-on faire dans ce cas ?
Comme déjà indiqué dans cet article, plusieurs solutions s’offrent déjà à vous :
Migrer vers une nouvelle version Windows ou SQL plus récente.
Acheter les Mises à jour de sécurité étendue (ESUs).
Migrer les serveurs vers Azure pour recevoir gratuitement les ESUs.
Un article dédié aux ESUs devrait arriver sous peu, tandis que 2 autres concernant la migration vers Azure existent déjà :
Il nous reste donc à parler de la mise à jour de l’OS lui-même. Cela tombe bien, car Dean Cefola de l’Azure Academy vient justement de publier une vidéo traitant de ce sujet :
Important : Bien évidement, les opérations décrites dans cette vidéo et dans mon article ne concernent que la seule mise à jour de l’OS. Il est certain que tous les projets comporteront éventuellement une migration vers le Cloud, mais également d’innombrable tests de compatibilité pour les applications déjà en place.
Aussi, je vous propose dans cet article de vous intéresser aux différentes méthodes de mise à jour possibles et décrites par Dean. Voici les grandes étapes de cet exercice :
Ces étapes sont également disponibles dans l’article de Microsoft Learn :
Une mise à niveau sur place vous permet de passer d’un ancien système d’exploitation à un plus récent, tout en conservant inchangés vos paramètres, vos rôles serveur et vos données. Cet article vous explique comment faire passer vos machines virtuelles Azure à une version ultérieure de Windows Server en utilisant une mise à niveau sur place.
Pour cela, commencez par déployer une première machine virtuelle sur Azure. Rendez-vous sur le portail d’Azure, puis utilisez la barre de recherche :
Cliquez-ici pour créer votre première machine virtuelle Azure :
Renseignez les informations de base relatives à votre VM en choisissant bien une image Windows Server 2012 R2 :
Définissez un compte administrateur local, bloquer les ports entrants (nous utiliserons le service Azure Bastion), puis cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Créez un nouveau réseau virtuel, retirez l’adresse IP publique, puis cliquez sur Suivant :
Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources de la VM, puis attendez environ 2 minutes :
Sans attendre que le déploiement soit entièrement terminé, il vous est possible, depuis le réseau virtuel Azure de déployer le service Azure Bastion :
Inutile d’attendre qu’Azure Bastion soit déployé pour continuer cet exercice :
Continuez en déployant 3 autres machines virtuelles Azure afin de pouvoir effectuer les 4 tests. Vous devriez avoir les VMs suivantes :
Windows Server 2012R2 x 3
Windows Server 2016 x 1
Notre environnement de départ est maintenant en place, nous allons pouvoir préparer nos VMs à installer la mise à jour OS Windows Server 2012.
Etape II – Sauvegarde et Préparation :
Mais avant cela, il est vivement conseillé de faire une sauvegarde. Depuis la machine virtuelle de votre choix, il est facile de faire une sauvegarde d’un disque via la fonction Snapshot.
Pour cela, recherchez le disque OS d’une VM de test, puis cliquez dessus :
Sur ce disque OS, cliquez-ici pour créer un snapshot de celui-ci :
Donnez-lui un nom et une performance, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du snapshot de la VM, puis attendez environ 30 secondes :
Le snapshot est maintenant visible comme un élément indépendant de la machine virtuelle Azure. Nous nous en servirons plus tard dans le cadre d’une restauration vers Windows Server 2012R2 :
Comme le rappelle la documentation Microsoft, la mise à niveau sur place nécessite l’ajout d’un second disque contenant les éléments d’installation.
Depuis le portail Azure, cliquez sur Azure Cloud Shell, puis configurez-le à votre guise :
Une fois Azure Cloud Shell démarré en mode PowerShell, lancez le script ci-dessous en prenant soin de modifier si besoin le groupe de ressources et la région Azure :
#
# Customer specific parameters
# Resource group of the source VM
$resourceGroup = "vmmigrate-rg"
# Location of the source VM
$location = "WestEurope"
# Zone of the source VM, if any
$zone = ""
# Disk name for the that will be created
$diskName = "WindowsServer2022UpgradeDisk"
# Target version for the upgrade - must be either server2022Upgrade or server2019Upgrade
$sku = "server2022Upgrade"
# Common parameters
$publisher = "MicrosoftWindowsServer"
$offer = "WindowsServerUpgrade"
$managedDiskSKU = "StandardSSD_LRS"
#
# Get the latest version of the special (hidden) VM Image from the Azure Marketplace
$versions = Get-AzVMImage -PublisherName $publisher -Location $location -Offer $offer -Skus $sku | sort-object -Descending {[version] $_.Version }
$latestString = $versions[0].Version
# Get the special (hidden) VM Image from the Azure Marketplace by version - the image is used to create a disk to upgrade to the new version
$image = Get-AzVMImage -Location $location `
-PublisherName $publisher `
-Offer $offer `
-Skus $sku `
-Version $latestString
#
# Create Resource Group if it doesn't exist
#
if (-not (Get-AzResourceGroup -Name $resourceGroup -ErrorAction SilentlyContinue)) {
New-AzResourceGroup -Name $resourceGroup -Location $location
}
#
# Create Managed Disk from LUN 0
#
if ($zone){
$diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
-CreateOption FromImage `
-Zone $zone `
-Location $location
} else {
$diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
-CreateOption FromImage `
-Location $location
}
Set-AzDiskImageReference -Disk $diskConfig -Id $image.Id -Lun 0
New-AzDisk -ResourceGroupName $resourceGroup `
-DiskName $diskName `
-Disk $diskConfig
Note : J’ai également modifié le script de Microsoft pour créer le disque en Standard SSD et non en Standard HDD. Cela me permet d’activer la fonction de disque partagé pour pouvoir l’utiliser en simultané sur 3 VMs maximum :
Lancez le script, attendez environ 30 secondes, puis constatez le succès de déploiement de celui-ci :
Sur ce nouveau disque, activez la fonction de disque partagé afin de l’utiliser sur plusieurs VMs :
Retournez sur votre première machine virtuelle afin de l’ajouter en tant que disque de données, puis cliquez sur Appliquer :
Faites-en de même pour une seconde machine virtuelle :
Enfin, faites-en de même pour une troisième machine virtuelle :
Nos 3 premières virtuelles sous Windows Server 2012R2 sont enfin prêtes. Il ne nous reste qu’à lancez les installations de Windows Server 2022 sous différentes formes.
Etape III – Tests d’installation sur place de Windows Server 2022 :
Test A – Windows Server 2012R2 + Installation GUI :
Commençons par l’installation depuis l’interface GUI.
Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :
Constatez la présence du disque F, correspondant au média d’installation de Windows Server 2022 :
Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante
cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable
Attendez environ 1 minute que l’installation se mette en route :
L’installation passe en revue la configuration de votre machine virtuelle :
Attendez encore une fois une minute environ :
Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :
Attendez encore une fois une minute environ :
L’installation se poursuit en vous avertissant de redémarrages possibles :
L’utilisateur est naturellement déconnecté durant la suite du processus de mise à jour :
Cliquez sur Reconnecter et attendez environ 15 bonnes minutes que l’installation se termine :
Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :
Constatez la nouvelle version de votre Windows Server depuis Server Manager :
Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :
Notre première machine virtuelle est bien mise à jour en version Windows Server 2022.
Nous allons pouvoir tester un second cas de mise à jour lancée depuis le portail Azure.
Test B – Windows Server 2012R2 + Installation via Azure Run Command :
Sur votre seconde machine virtuelle de test, rendez-vous dans le menu suivant :
Lancez la commande suivante, puis cliquez sur Exécuter :
cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet
Attendez environ 15 minutes, sans vous fier au statut Complet de l’écran ci-dessous :
Suivez si besoin la charge CPU de votre VM depuis la fenêtre des métriques :
Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :
Constatez la nouvelle version de votre Windows Server depuis Server Manager :
Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :
Notre seconde machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.
Nous allons pouvoir tester un troisième cas de mise à jour lancée depuis une extension de machine virtuelle.
Test C – Windows Server 2012R2 + Installation via Virtual Machine Extension :
Préparer localement un fichier de script PS1 avec le code suivant :
cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet
Sur votre troisième machine virtuelle de test, rendez-vous dans le menu suivant :
Choisissez Custom Script Extension, puis cliquez sur Suivant :
Cliquez-ici :
Choisissez le compte de stockage utilisé pour Azure Cloud Shell :
Créez un nouveau conteneur pour le stockage objet :
Nommez-le, puis cliquez sur Créer :
Téléversez votre script :
Sélectionnez votre script :
Cliquez-ici :
Attendez que le déploiement du script se termine :
Suivez si besoin son statut :
Environ 15 minutes plus tard, le statut du script est terminé :
Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :
Constatez la nouvelle version de votre Windows Server depuis Server Manager :
Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :
Notre troisième machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.
Nous allons pouvoir tester un dernier cas de mise à jour lancée depuis une machine virtuelle déjà sous Windows Server 2016.
Test D – Windows Server 2016 + Installation GUI :
Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :
Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante :
cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable
Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :
L’installation se poursuit en vous avertissant de redémarrages possibles :
Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :
Constatez la nouvelle version de votre Windows Server depuis Server Manager :
Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :
Notre machine virtuelle en 2016 est correctement mise à jour en version Windows Server 2022.
Etape IV – Retrait du disque d’installation :
Une fois l’installation terminée, il ne nous reste plus qu’à retirer le disque d’installation monté sur les machines virtuelles mises à jour :
Cliquez sur Appliquer :
Attendez quelques secondes la notification Azure :
Constatez la disparition du disque F :
Etape V – Restauration de la sauvegarde :
Dans le cas d’un bug au moment de la mise à jour ou après tout autre déconvenue, il est possible de repartir du snapshot généré avant la mise à jour.
Commencez par éteindre la machine virtuelle à restaurer :
Attendez quelques secondes la notification Azure :
Depuis le snapshot, cliquez-ici pour créer un nouveau disque OS :
Nommez-le, choisissez sa taille et sa performance, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du disque :
Retournez sur une des machines virtuelles de test, puis cliquez-ici pour intervertir les disques OS :
Choisissez le nouveau disque, puis lancez le traitement en cliquant sur OK :
Attendez quelques secondes la notification Azure :
Redémarrer la machine virtuelle restaurée :
Ouvrez une session via Azure Bastion :
Attendez la fin de chargement de session :
Constatez le retour à l’ancienne version de Windows Server depuis Server Manager :
Conclusion
Le processus de mise à jour depuis une VM déjà sur Azure vers une version plus récente de Windows Server est des plus simples. Nul doute que la mise à jour de l’OS est la partie émergée de l’iceberg. D’autres tests avant la mises à jour devront être effectués pour vérifier la bonne compatibilité des applications et des services installés.