Déplacez votre VM dans une Zone Azure

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 🙏

Annoncé le 12 décembre dernier sur blog Azure, cette fonctionnalité dédié aux machines virtuelles vient compléter la récente annonce datée d’octobre sur l’Expansion zonale des Azure VMSS.

Voici d’ailleurs un schéma montrant l’intégration de 3 zones au sein d’une seule région Azure :

Microsoft a déjà mis à disposition la documentation sur ce nouveau type de migration :

En revanche, la possibilité d’utiliser ce type de migration dépendra de votre scénario actuel :

ScénarioAssistance techniqueDétails
Machine virtuelle à instance uniquePrise en chargeLe 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 uniformeNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexibleNon pris en charge
Régions prises en chargePrise en chargeSeules 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 chargeLe 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 virtuelleNon pris en chargeLe 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 fiablePrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentiellesPrise en chargeRé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 chargeLe 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ésPrise en chargeL’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activéePrise 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éesPrise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)Prise en charge
Stratégies RBAC de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible.
Machines virtuelles utilisant l’accélération réseauPrise en charge

Pourquoi migrer dans une Zone de disponibilité Azure ?

Les avantages à utiliser les zones de disponibilité Azure sont les suivants:

  • Pour des raisons de besoins de fiabilité et de performance.
  • Pour une reprise après sinistre sans compromettre la résidence des données.

Pour rappel, la SLA sera différente si la VM est toute seule, ou si elle est accouplée à une autre VM dans une Availability Set ou Availability Zone :

Afin de se faire une meilleure idée sur cette migration, je vous propose de réaliser un petit exercice, dont les tâches seront les suivantes :

Etape 0 – Rappel des prérequis :

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 :

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 :

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 😎

Azure Site Recovery pour des serveurs sur site

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.

Microsoft Learn

Voici une vidéo qui parle des mécanismes d’Azure Site Recovery :

Afin de se faire une meilleure idée sur l’hibernation d’Azure, je vous propose de réaliser un petit exercice combinant Azure Site Recovery et Hyper-V :

Etape 0 – Rappel des prérequis :

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 :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

Attendez environ une minute que l’installation des rôles se termine :

Lancez la commande suivante pour lancer un redémarrage de votre VM hôte (Hyper-V) :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour se reconnecter à celle-ci, toujours via Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V, et de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, et le serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

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 :

Consultez les informations dont le RPO :

Consultez le schéma complet de réplication ASR :

Vérifiez et modifiez ci-dessous les informations VM et réseau :

Vérifiez et modifiez ci-dessous les informations des disques :

De retour sur la machine virtuelle SRV, créez un fichier image, puis enregistrez-le sur le bureau :

Attendez environ 10 minutes, puis lancez l’opération de bascule vers Azure :

Cochez la case suivante, plus cliquez-ici :

Confirmez votre action en cliquant ici :

Une nouvelle notification Azure apparaît pour vous indiquer la création de la machine virtuelle SRV dans Azure :

Consultez le nouveau groupe de ressources Azure créé pour la réplication :

Attendez la seconde notification Azure vous indiquant le succès du traitement de bascule :

Rafraichissez la page du groupe de ressources créé par ASR afin de constate la présence de la nouvelle machine virtuelle SRV :

Vérifiez la configuration CPU / Mémoire :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

Lancez le script PowerShell suivant afin d’activer le service de bureau à distance :

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

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 😎🥳

❄️Faites hiberner vos VMs ⛄

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.

Wikipedia

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.

Combien coûte une machine virtuelle démarrée ?

Pour rappel, les coûts d’une machine virtuelle avaient déjà été détaillés dans cet article : Comprenez les coûts d’une ressource Azure.

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.

Microsoft Learn

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 :

Etape 0 – Rappel des prérequis :

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.

Attendons de voir la suite 😎💪

Updatez vos VMs vers Windows Server 2022

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.

Microsoft Learn

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la mise à jour vers Windows Server 2022, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Je vous propose de créer plusieurs machines virtuelles dans le but de réaliser 4 tests :

Etape I Création de l’environnement de test :

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.

Migrez votre AD 2012R2 vers Azure

Microsoft nous prévient déjà depuis assez longtemps : la fin du support de Windows Server 2012 R2 et SQL 2012 sont prévues pour le 10 octobre 2023 😖. Après cette date, ces produits ne recevront plus de mise à jour, sécurités incluses ! Trois s’options s’offrent alors à vous :

  • Migrer vers une nouvelle version Windows ou SQL plus récente.
  • Acheter les Mises à jour de sécurité étendue (ESU).
  • Migrer les serveurs vers Azure pour recevoir gratuitement les ESUs.

Pas de panique !

Microsoft vous aide à planifier la fin de support Windows Server 2012/2012 R2 et SQL Server 2012. Plusieurs ressources sont mises à disposition :

En plus de la documentation Microsoft, Dean Cefola de l’Azure Academy nous propose un petit exercice d’upgrade d’un Active Directory, actuellement hébergé sur un serveur Windows 2012R2 vers un Azure en version 2022 :

La vidéo est vraiment bien faite et très explicative, je souhatais donc vous proposer en détail l’explicatif étape par étape en français afin que vous puissiez le tester par vous-même :

Enfin, Microsoft met aussi à disposition un article dédié à ce sujet : Déployer AD DS dans un réseau virtuel Azure

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la migration Active Directory vers Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un environnement Active Directory on-premise (point de départ)

De mon côté, j’ai simulé mon environnement Active Directory on-premise sur Azure. Voici donc les ressources Azure déjà en place :

  • Machine virtuelle en Windows Server 2012R2
  • Azure Bastion
  • Azure VPN Site à Site

En me connectant à mon serveur AD (nous l’appellerons DC2012R2), nous y retrouvons mon domaine on-premise, ainsi que la version de l’OS : Windows Server 2012R2.

Actuellement, mon environnement de test ne comporte qu’un seul serveur en tant que contrôleur de domaine AD :

Nous allons donc maintenant déployer un nouvel environnement sur Azure afin de simuler la transition AD vers le Cloud de Microsoft.

Etape I – Déploiement des ressources Azure :

Pour cela, commencez par déployer une machine virtuelle sur Azure. Rendez-vous sur le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer votre première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

Définissez un compte administrateur local, bloquer les ports entrants (question de sécurité pour un DC), puis cliquez sur Suivant :

Comme le Microsoft le recommande, il est nécessaire de stocker les informations AD (base de données, les journaux et le dossier sysvol) séparées du disque OS.

Pour cela, rajoutez un second disque en cliquant ici :

Cliquez sur OK :

Définissez le paramètre Host Cache sur le disque de données sur None, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliqu