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é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.
Machines virtuelles utilisant l’accélération réseau	Prise 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 :

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 😎

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). 😥😥

Years

Months

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 Windows 365 dans une autre région Azure

Microsoft continue d’apporter toujours plus de fonctionnalités à son service Windows 365. Cette fois, vous allez pouvoir très facilement déplacer vos Cloud PCs d’une région Azure à une autre en quelques clics. Que Microsoft ouvre de nouveaux centres de données ou que vos utilisateurs se déplacent à travers le globe, Azure déménage pour vous !

Plusieurs articles ont déjà été écrits sur ce blog à propos de Windows 365 depuis sa sortie durant l’été 2021 :

Mais la question du déplacement d’un ou plusieurs Cloud PCs Windows 365 n’avait pas encore été abordée par Microsoft. Ils corrigent donc le tir pour automatiser ce processus de déplacement de ressources Cloud.

D’ailleurs, où est hébergé son Cloud PC ?

Comme tous les services Cloud de Microsoft, les Cloud PCs sont hébergés dans un de leurs nombreux centres de données répartis à travers le Cloud.

Windows 365 est donc disponible à ce jour dans la liste de centres données suivante, et celle-ci continue de s’agrandir :

Amériques
- Brésil Sud (restreint)
- USA Centre
- USA Centre Sud
- USA Est
- USA Est 2
- USA Ouest 2 (restreint)
- USA Ouest 3
Asie
- Asie Est
- Asie Sud-Est
- Inde Centre
- Japon Est
- Corée Centre
Océanie
- Australie Est
Canada
- Canada Centre
Europe
- Europe Nord
- Europe Ouest
- France Centre
- Centre Ouest de l’Allemagne
- Norvège Est
- Suède Centre
- Suisse Nord
- Sud du Royaume-Uni
Afrique / Moyen Orient
- Afrique du Sud Nord
- Émirats arabes unis Nord

Pourquoi migrer son Cloud PC ?

Tout service Cloud étant par nature accessible depuis internet, il n’est pas évident de comprendre l’intérêt de migrer son Cloud PC vers une autre région Azure. Plusieurs raisons pourraient alors l’expliquer :

Déplacer le Cloud PC au plus près de son utilisateur pour améliorer les performances et diminuer la latence réseau.
Intégrer son Cloud PC dans une infrastructure réseau existante, mais présente dans une autre région Azure.
Maitriser le lieu de résidence des données de son Cloud PC.

Y a-t-il un risque à déplacer son Cloud PC ?

Non, Microsoft est très clair sur le processus de migration du Cloud PC :

Tous les PC cloud du déplacement sont sauvegardés avant d’être déplacés vers la nouvelle région. Cette sauvegarde, qui peut prendre un certain temps, peut commencer lorsque l’utilisateur est connecté et actif.
Microsoft Learn

Par contre, le processus de migration peut prendre un certain temps, et donc occasionner une interruption de service pour l’utilisateur :

Le meilleur moment pour effectuer des déplacements est pendant le week-end pour s’assurer que l’impact sur les utilisateurs est réduit. Les PC cloud étant arrêtés pendant le processus de déplacement, vous devez avertir vos utilisateurs avant le déplacement afin qu’ils puissent enregistrer leur travail et se déconnecter.
Microsoft Learn

Afin de comprendre le processus de déplacement, je vous propose de tester ensemble cette fonctionnalité de Windows 365 sur deux cas de figure :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Windows 365, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide
Deux licences Windows 365

Commençons par le scénario le plus simple à tester, à savoir le déplacement d’un Cloud PC uniquement joint à Entra ID.

Scénario A – Cloud PC Windows 365 joint uniquement à Entra ID :

Afin de mettre en place le premier Windows 365, il est nécessaire d’assigner une licence à un utilisateur de test :

Rendez-vous sur le portail d’Intune afin de créer une police de provisionnement :

Ici, notre jointure est simple et directe :

Environ 30 minutes plus tard, la page suivante vous affiche la bonne mise à disposition du Cloud PC pour son utilisateur :

Avant de lancer le processus de déplacement du Cloud PC, cliquez sur le lien suivant, authentifiez-vous avec votre utilisateur de test, puis lancez une session Cloud PC :

Attendez quelques secondes que la sessions Windows s’ouvre :

Ouvrez la commande suivante et l’adresse web s uivante afin de constater votre configuration de jointure et votre adresse IP actuelle :

dsregcmd /status

Notre PC actuellement hébergé aux USA est maintenant prêt à être migré dans un centre de données Suisse.

Pour cela, retournez dans la liste des polices de provisionnement, puis cliquez sur celle-ci :

Cliquez sur le lien suivant pour en modifier le contenu :

Changez la Géographie Microsoft et la Région Azure selon vos souhaits, puis cliquez sur Suivant :

Qu’est-ce qu’une Géographie Microsoft ?
La réponse est juste ici.

Cliquez-ici pour mettre à jour votre première police de provisionnement :

La notification suivante apparaît alors :

Enfin, cliquez-ici pour déclencher la bascule de région Azure selon les nouvelles règles de la police de provisionnement modifiée :

Confirmez votre choix en cliquant ici :

L’ordre de bascule est maintenant pris en compte par Azure. Les Cloud PCs rattachés à cette police de provisionnement voient leur statut changer :

Quelques minutes plus tard, la connexion Windows 365 de notre utilisateur de test se termine :

Et environ 1 heure et 30 minutes plus tard, le Cloud PC retrouve son précédent statut :

Rouvrez une session de bureau à distance de votre utilisateur de test.

La réouverture d’Edge indique la possibilité de restaurer les onglets précédent ouverts :

Cette fois-ci, la page de IP2location indique bien une nouvelle adresse IP et un nouveau positionnement estimé sur la Suisse :

Pour les Clouds PC de Windows 365 joints uniquement à Entra ID, la migration vers une nouvelle région Azure a été des plus simples.

Intéressons-nous maintenant aux Clouds PC Windows 365 de joints à Entra ID et à Active Directory (jointe hybride).

Scénario B – Cloud PC Windows 365 joints à Entra ID et à Active Directory (hybride) :

Cette seconde liaison est surtout utile dans le cadre d’infrastructure existante dans Azure ou on-premise car elle permet de :

Joindre les Cloud PCs à un domaine Active Directory existant
Permettre un accès réseau à des ressources locales via une passerelle Azure VPN ou autre

Une liaison réseau doit être établie dans Azure avant le premier déploiement des Cloud PCs. Il nous est également nécessaire de disposer d’un domaine Active Directory.

Dans mon cas, j’ai déployé une machine virtuelle Azure en Windows Server, et Azure Bastion pour m’y connecter plus facilement :

*N’oubliez pas de configurer également l’adresse IP locale de votre VM en tant que DNS sur votre réseau virtuelle Azure.*

Azure Bastion est donc un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient Windows ou Linux. Un article en parle juste ici.

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez sur Connecter :

Installer les rôles suivants pour créer votre domaine Active Directory :

Active Directory Domain Services
Serveur DNS

Créez une OU et un utilisateur dédié à vos tests Windows 365 :

Installer Azure AD Connect sur votre serveur Active Directory de test via ce lien. Un article dédié à Azure AD Connect est disponible juste ici.

Le gestionnaire des synchronisations d’Azure AD Connect affiche la bonne remontée de notre utilisateur de test dans Entra ID :

Dans Azure AD Connect, n’oubliez pas d’également configurer la jointure hybride par le menu suivant :

Cochez la case ci-dessous, puis cliquez sur Suivant :

Cochez la case ci-dessous, puis cliquez sur Suivant :

Renseignez les informations d’identifications d’Active Directory, puis cliquez sur Suivant :

Une fois la configuration terminée, retournez sur le portail des utilisateurs d’Entra ID afin de constater l’apparition de notre utilisateur AD correctement synchronisé :

Veillez à lui assigner également une licence Windows 365 :

Retournez sur le portail d’Intune pour créer une connexion réseau Azure :

Configurez celle-ci en tenant compte à la fois des informations d’Azure et d’Active Directory :

Attendez quelques minutes que le processus de vérification de Windows 365 n’affiche pas d’erreur bloquante :

Créez une seconde police de provisionnement dédiée à ce scénario B :

Configurez celle-ci pour qu’elle utilise la connexion réseau créée précédemment dans le cadre de notre jointure hybride :

Retournez sur l’onglet suivant afin de constater l’apparition d’un second Cloud PC en cours de provisionnement :

Attendez environ une heure que le provisionnement se termine :

Vérifiez sur la page des périphériques d’Entra ID que le nouveau Cloud PC y figure bien :

Vérifiez dans l’OU d’Active Directory que le nouveau Cloud PC y figure également :

Notre environnement de départ pour notre Scénario B est enfin prêt. Nous allons pouvoir commencer la migration du Cloud PC dans une autre région Azure.

Pour cela, commencez par créer un second réseau virtuel Azure :

Veillez à choisir une région et un adressage IP différents du premier réseau virtuel :

Une fois le réseau virtuel créé, cliquez-ici pour lui ajouter un appairage vers le premier réseau virtuel :

Configurez l’appairage comme ceci, puis cliquez sur Créer :

Attendez quelques secondes que le statut de l’appairage indique Connecté :

Comme pour le premier réseau virtuel, renseignez l’adresse IP locale de votre machine virtuelle ayant le rôle d’Active Directory, puis cliquez sur Sauvegarder :

Retournez sur le portail d’Intune afin d’ajouter une seconde connection réseau Azure hybride :

Choisissez le second réseau virtuel Azure :

Reproduisez les mêmes éléments d’identification de votre Active Directory, puis cliquez sur Suivant :

Lancez la création de votre connection réseau Azure hybride en cliquant ici :

Attendez quelques minutes que le processus de vérification de Windows 365 n’affiche pas d’erreur bloquante sur la nouvelle connection réseau Azure hybride :

Retourner dans la liste des polices de provisionnement, puis cliquez sur celle-ci :

Cliquez sur le lien suivant pour en modifier le contenu :

Changez la connection réseau Azure hybride, puis cliquez sur Suivant :

Cliquez-ici pour mettre à jour votre seconde police de provisionnement :

La notification suivante apparaît alors :

Enfin, cliquez-ici pour déclencher la bascule de région Azure selon les nouvelles règles de la police de provisionnement :

Confirmez votre choix en cliquant ici :

L’ordre de bascule est maintenant pris en compte par Azure. Les Cloud PCs rattachés à cette police de provisionnement voient leur statut changer :

Environ 1 heure et 30 minutes plus tard, le Cloud PC retrouve son précédent statut :

Ouvrez la session de bureau à distance de votre utilisateur de test :

Là encore, la page de IP2location indique bien une adresse IP et un positionnement estimé sur la Suisse :

Conclusion

En seulement quelques clics, Microsoft propose encore une fois d’automatiser des opérations qui pouvaient prendre plusieurs heures en opérations IT. L’ajout réguliers de fonctionnalités apporte toujours plus de souplesse au service managé Cloud PC.

Voici d’ailleurs une vidéo de Dean sur le sujet est disponible juste ici 😎:

Azure Migrate – Exercice 1 Création du projet + démarrage de l’estimation :

Notre environnement de départ Hyper-V est prêt et fonctionnel. L’exercice 1 va nous permettre d’en savoir un peu plus sur la phase d’estimation.

Pour qu’Azure Migrate vous propose une architecture cible dans le Cloud, il a besoin de sonder les ressources à migrer. Le but est de connaître l’OS, la puissance utilisée ou encore les interactions réseaux.

Tâche 1 – Créez le projet Azure Migrate :

Nous allons pouvoir démarrer les étapes liées à l’estimation sur Azure Migrate. Pour cela, recherchez le service Azure Migrate grâce à la barre de recherche présente dans votre portail Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-214.png.

Sur la page d’accueil du service Azure Migrate, cliquez sur la première tuile à gauche :

L’attribut alt de cette image est vide, son nom de fichier est image-215.png.

Cliquez-ici pour créer votre Projet de migration. Celui-ci englobera les différentes phases (estimations et migration) de notre atelier :

L’attribut alt de cette image est vide, son nom de fichier est image-216.png.

Remplissez les champs en créant un nouveau groupe de ressources nommé AzureMigrateRG, si possible dans la même géographie Azure que celle dont dépend la région utilisée lors du déploiement :

L’attribut alt de cette image est vide, son nom de fichier est image-217-1024x416.png.

Pour info, la création de ce projet se retrouve bien dans la liste des ressources Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-218-1024x368.png.

La création de ce projet vous ouvre automatiquement celui-ci dans Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-219-1024x510.png.

Note : Remarquez bien la présence deux sections précédemment rappelées dans cet article : Estimation / Migration.

Tâche 2 – Déployez l’appliance d’Azure Migrate :

Pour estimer au mieux l’architecture Azure cible, Azure Migrate propose d’installer sur notre environnement Hyper-V une appliance sous forme de machine virtuelle.

Cette dernière va analyser les données relatives aux autres machines virtuelles sur notre environnement et remontera toutes les informations (métriques) nécessaires au service Azure Migrate via le protocole HTTPS.

Cliquez ici pour démarrer l’installation :

L’attribut alt de cette image est vide, son nom de fichier est image-220.png.

Choisissez Hyper-V, nommez votre appliance Azure Migrate SmartHotelAppl, puis cliquez ici pour générer une clef d’association (entre l’Appliance et votre projet d’Azure Migrate) :

L’attribut alt de cette image est vide, son nom de fichier est image-221-1024x334.png.

Une fois la clef générée, copiez la dans votre bloc-notes sans fermez cet onglet Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-222.png.

Note : Dans cet atelier Microsoft, le téléchargement de l’appliance d’Azure Migrate n’est pas nécessaire car cette dernière est déjà présente sur notre serveur Hyper-V.

Ouvrez un second onglet Azure, puis recherchez la machine virtuelle Hyper-V appelée SmartHotelHost :

L’attribut alt de cette image est vide, son nom de fichier est image-223.png.

Téléchargez le fichier RDP pour démarrer une session de bureau à distance :

L’attribut alt de cette image est vide, son nom de fichier est image-224.png.

Utilisez les identifiants RDP suivants :

L’attribut alt de cette image est vide, son nom de fichier est image-225.png.

Acceptez le risque sécuritaire :

L’attribut alt de cette image est vide, son nom de fichier est image-226.png.

Une fois la session à distance ouverte, ouvrez le gestionnaire Hyper-V :

L’attribut alt de cette image est vide, son nom de fichier est image-227-1024x539.png.

Cliquez ici pour créer l’Appliance d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-228.png.

Cliquez sur Suivant, puis choisissez le répertoire suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-229.png.

Cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-230.png.

Cliquez encore sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-231.png.

Cliquez encore sur Suivant en conservant ce choix :

L’attribut alt de cette image est vide, son nom de fichier est image-232.png.

Choisissez la connexion Azure Migrate Switch, puis cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-233.png.

Cliquez sur Finaliser :

L’attribut alt de cette image est vide, son nom de fichier est image-234.png.

Cliquez ici pour démarrer l’appliance d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-235-1024x667.png.

Tâche 3 – Configurez l’appliance Azure Migrate :

Cette appliance a maintenant besoin d’une configuration pour remonter toutes les informations au bon projet créé dans Azure Migrate. Pour cela, connectez-vous à celle-ci :

L’attribut alt de cette image est vide, son nom de fichier est image-236-1024x667.png.

Une fois la fenêtre de connexion ouverte, acceptez les Termes et conditions :

L’attribut alt de cette image est vide, son nom de fichier est image-238.png.

Configurez le mot de passe du compte administrateur avec le mot de passe demo!pass123, puis cliquez sur Finaliser :

L’attribut alt de cette image est vide, son nom de fichier est image-240.png.

Note : Attention, bien souvent, cette machine virtuelle utilise un clavier américain. De ce fait le symbole du point d’exclamation est la combinaison MAJ+1.

Cliquez sur Connecter :

L’attribut alt de cette image est vide, son nom de fichier est image-242.png.

Changez le clavier au besoin, puis connectez-vous avec le mot de passe configuré juste avant : demo!pass123

L’attribut alt de cette image est vide, son nom de fichier est image-243-1024x653.png.

Attendez quelques minutes pour voir automatiquement s’ouvrir le navigateur internet suivant, puis acceptez les Termes et conditions :

L’attribut alt de cette image est vide, son nom de fichier est image-244-1024x693.png.

Collez la clef de votre projet Azure Migrate, puis cliquez sur Vérifier :

L’attribut alt de cette image est vide, son nom de fichier est image-245-1024x425.png.

Une fois vérifiée, attendez quelques minutes pour constater d’éventuelles mises à jour de l’appliance :

L’attribut alt de cette image est vide, son nom de fichier est image-246-1024x125.png.

Rafraichissez la page au besoin si le système vous le demande :

L’attribut alt de cette image est vide, son nom de fichier est image-247.png.

Authentifiez-vous avec votre compte Azure utilisé pour la création des ressources de cet atelier :

L’attribut alt de cette image est vide, son nom de fichier est image-248-1024x207.png.

Cliquez ici pour utiliser le mécanisme d’authentification Azure PowerShell pour l’appliance d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-249.png.

Collez le code donné précédemment, puis cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-250.png.

Choisissez le compte Azure AD adéquat :

L’attribut alt de cette image est vide, son nom de fichier est image-252.png.

Cliquez sur Continuer pour autoriser l’authentification :

L’attribut alt de cette image est vide, son nom de fichier est image-253.png.

Fermez la fenêtre de navigation :

L’attribut alt de cette image est vide, son nom de fichier est image-254.png.

Attendez quelques minutes le temps de l’enrôlement de l’appliance dans Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-255-1024x153.png.

L’attribut alt de cette image est vide, son nom de fichier est image-256.png.

Afin que l’appliance puisse découvrir les machines virtuelles en fonctionnement sur Hyper-V cliquez ici pour ajouter les informations d’identification locales :

L’attribut alt de cette image est vide, son nom de fichier est image-257-1024x333.png.

Ajoutez l’utilisateur suivant, puis cliquez sur Sauvegarder :

L’attribut alt de cette image est vide, son nom de fichier est image-258.png.

Cliquez ici pour ajouter des informations sur les VMs d’Hyper-V à analyser :

L’attribut alt de cette image est vide, son nom de fichier est image-259-1024x332.png.

Indiquez l’adresse IP locale ou le FQDN de l’hôte Hyper-V ainsi que le nom de l’identifiant sauvegardé précédemment, puis cliquez sur Sauvegarder :

L’attribut alt de cette image est vide, son nom de fichier est image-260.png.

Vérifiez que la validation s’est effectuée avec succès :

L’attribut alt de cette image est vide, son nom de fichier est image-261-1024x259.png.

Comme nous n’avons pas besoin d’effectuer d’analyse d’applications particulières, désactivez cette fonction juste ici :

L’attribut alt de cette image est vide, son nom de fichier est image-262-1024x389.png.

Cliquez ici pour démarrer la découverte des machines virtuelles sur notre Hyper-V :

L’attribut alt de cette image est vide, son nom de fichier est image-263-1024x130.png.

Attendez quelques minutes, puis retournez sur votre projet Azure Migrate et actualisez :

L’attribut alt de cette image est vide, son nom de fichier est image-264-1024x516.png.

Quelques petits rafraichissements plus tard, les serveurs commencent à faire leur apparition :

L’attribut alt de cette image est vide, son nom de fichier est image-265.png. — Notez l’apparition de 5 serveurs.
Oui, l’appliance d’Azure Migrate se découvre elle-même ????.

Note Microsoft : Si le processus de découverte prend un temps excessif ou si les ressources sources ne permettent pas à l’appliance de découvrir les ressources dans un délai approprié, vous pouvez importer manuellement les systèmes via ce fichier CSV :

L’attribut alt de cette image est vide, son nom de fichier est image-266.png.

Tâche 4 – Créez l’estimation de la migration :

Une fois la découverte terminée, cliquez ici pour créer l’estimation des ressources Azure, avec pour cible des machines virtuelles Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-267.png.

Cliquez sur ce bouton pour affiner vos critères cibles des ressources Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-268.png.

Personnalisez tous les critères admissibles pour l’architecture cible sur Azure, puis sauvegardez les :

L’attribut alt de cette image est vide, son nom de fichier est image-269-1024x567.png.

Cliquez sur Suivant pour continuer sur la partie Serveur :

L’attribut alt de cette image est vide, son nom de fichier est image-270.png.

Donnez les noms SmartHotelAssessment et SmartHotel VMs, puis sélectionnez uniquement les 3 machines virtuelles suivantes :

L’attribut alt de cette image est vide, son nom de fichier est image-271.png. — La machine virtuelle **smarthotelSQL1** ne sera migrée sur Azure.
Le serveur SQL sera migré vers le service PaaS SQL Database.

Terminez la création de l’estimation :

L’attribut alt de cette image est vide, son nom de fichier est image-272.png.

Relancez un rafraîchissement du projet Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-273.png.

Assez rapidement, constatez l’apparition de l’estimation de machines virtuelles Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-274.png.

Cliquez dessus et constatez le premier niveau de détail d’informations :

L’attribut alt de cette image est vide, son nom de fichier est image-275-1024x292.png. — *Le taux de confiance d’Azure Migrate est faible au début de l’estimation.*

L’attribut alt de cette image est vide, son nom de fichier est image-276-1024x265.png.

L’attribut alt de cette image est vide, son nom de fichier est image-277-1024x339.png.

Tâche 5 – Configurez les dépendances :

La transition vers un nouveau système nécessite des contrôles poussés pour éviter les oublis. C’est aussi le cas pour la partie réseau des infrastructures IT. Bien souvent, plein de connexions entre les services existent et il impératif de ne pas les oublier.

Azure Migrate permet de visualiser ces dépendances afin de les appréhender et de trouver une solution dans la future architecture Azure.

Pour que ces dépendances soient visibles, il est nécessaire de déployer un Azure Log Analytics workspace et des agents sur les machines virtuelles à migrer.

Cliquez sur le groupe présent dans l’estimation Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-278-1024x436.png.

Puis cliquez sur son nom SmartHotel VMs :

L’attribut alt de cette image est vide, son nom de fichier est image-279-1024x289.png.

Avant toute action, les 3 machines virtuelles intégrées à ce groupe sont encore en attente d’installation de l’agent pour afficher leurs dépendances :

L’attribut alt de cette image est vide, son nom de fichier est image-280.png.

Cliquez sur l’une d’entre elle, puis cliquez ici pour créer l’Azure Log Analytics workspace :

L’attribut alt de cette image est vide, son nom de fichier est image-281-1024x261.png.

Donnez-lui un nom unique et une région Azure, puis cliquez sur Configurer :

L’attribut alt de cette image est vide, son nom de fichier est image-282.png.

Attendez quelques minutes que Log Analytics workspace d’Azure se déploie, puis ouvrez un nouvel onglet Azure sur ce dernier pour récupérer plusieurs informations utiles à la configuration des agents de dépendances :

L’attribut alt de cette image est vide, son nom de fichier est image-283-1024x578.png.

Ces informations sont également disponibles sur la page des dépendances d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-284-1024x357.png.

Copiez les 4 liens disponibles (agents + dépendances) :

Microsoft Monitoring Agent :
- Windows
- Linux
Agent de dépendance :
- Windows
- Linux

Sur la connection RDP de votre machine Hyper-V, connectez-vous au serveur smarthotelweb1 via la console Hyper-V :

L’attribut alt de cette image est vide, son nom de fichier est image-285-1024x667.png.

Cliquez sur Connecter :

L’attribut alt de cette image est vide, son nom de fichier est image-286.png.

Renseignez le mot de passe administrateur demo!pass123 :

L’attribut alt de cette image est vide, son nom de fichier est image-287-1024x685.png.

Ouvrez Internet Explorer, puis copiez le premier lien pour installer Microsoft Monitoring Agent (Windows) :

L’attribut alt de cette image est vide, son nom de fichier est image-288.png.

Lancez l’installation, puis validez tous les écrans en cochant cette case :

L’attribut alt de cette image est vide, son nom de fichier est image-289.png.

Renseignez le Workspace ID et la clef qui lui est associée, puis cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-290.png.

Laissez cette option comme ceci, puis cliquez sur Suivant et lancez l’installation :

L’attribut alt de cette image est vide, son nom de fichier est image-291.png.

Une fois l’installation terminée, copiez le second lien pour installer l’agent de dépendance (Windows) :

L’attribut alt de cette image est vide, son nom de fichier est image-292.png.

Effectuez les mêmes opérations que précédemment sur la machine virtuelle nommée smarthotelweb2.

Pour la machine Linux appelée UbuntuWAF, l’installation des agents peut s’effectuer via une connexion SSH.

Depuis la machine Hyper-V, ouvrez l’exécuteur de commande Windows, puis saisissez celle-ci :

ssh demouser@192.168.0.8

L’attribut alt de cette image est vide, son nom de fichier est image-293.png.

Saisissez le mot de passe demo!pass123, puis Valider :

L’attribut alt de cette image est vide, son nom de fichier est image-295-1024x582.png.

Obtenez une élévation des privilèges par la commande suivante :

sudo -s

Saisissez le mot de passe demo!pass123, puis Validez :

L’attribut alt de cette image est vide, son nom de fichier est image-296-1024x582.png.

Saisissez la commande suivante pour télécharger l’agent Microsoft Monitoring Agent (Linux) en prenant soin de modifier au prélable les deux variables suivantes :

<Workspace ID>
<Workspace Key>

wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w f4fda077-1c65-4680-93d4-e884d4164427 -s 4DFqRZKoi94QSe3piXhvr0vyIYk12n5zGiBJ4VDOoaWU9d4M0dBniKENBJBjyT6vgN/S8v23lXk/RYFxKDzsrw==

L’attribut alt de cette image est vide, son nom de fichier est image-298-1024x582.png.

A cette question, répondez Oui :

L’attribut alt de cette image est vide, son nom de fichier est image-297-1024x582.png.

L’attribut alt de cette image est vide, son nom de fichier est image-299-1024x582.png.

Redémarrer le service en prenant soin de modifier au prélable la variable suivante :

<Workspace ID>

/opt/microsoft/omsagent/bin/service_control restart f4fda077-1c65-4680-93d4-e884d4164427

L’attribut alt de cette image est vide, son nom de fichier est image-300-1024x582.png.

Entrez la commande suivante pour lancer le téléchargement de l’agent de dépendance :

wget --content-disposition https://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin

L’attribut alt de cette image est vide, son nom de fichier est image-302-1024x582.png.

Lancez l’installation de l’agent de dépendance :

sh InstallDependencyAgent-Linux64.bin -s

L’attribut alt de cette image est vide, son nom de fichier est image-303-1024x582.png.

L’installation de tous les agents est maintenant terminée, retournez sur le projet d’Azure Migrate et constatez la disparition de l’alerte, après quelques minutes et plusieurs rafraîchissements :

L’attribut alt de cette image est vide, son nom de fichier est image-304.png.

Cliquez ici pour afficher les dépendances dans un rendu graphique :

L’attribut alt de cette image est vide, son nom de fichier est image-305-1024x104.png.

L’attribut alt de cette image est vide, son nom de fichier est image-306-1024x627.png.

Toujours avec moi ? Super !

Nous avons fini de mettre en place la partie Estimation d’Azure Migrate utilisée pour notre atelier.

Nous allons maintenant commencer la partie migration de la base de données SQL. Là encore, nous allons effectuer les mêmes deux phases :

Evaluation : analyse de la base SQL.
Migration : migration des schémas et des données à froid.

La seconde partie de cet atelier consistera à migrer la base de données SQL vers Azure SQL Database. Il s’agit donc de l’exercice 2, accessible juste ici.

Pour rappel, voici quelques liens utiles pour ne pas vous perdre :

Atelier Azure Migrate :
- Lien GitHub pour les consignes de l’atelier
- Lien GitHub pour le déploiement des ressources
Articles du blog sur l’atelier d’Azure Migrate :

Azure Migrate vous aide à … migrer 😁

C’est décidé, la migration vers le Cloud Azure est validée. Il ne vous reste plus qu’à tout migrer. Oui, mais comment faire ? Rassurez-vous ! Azure Migrate est un service qui va vous faciliter la vie dans le transfert de données et de ressources IT.

Bien évidemment, ce n’est pas la seule solution sur le marché. D’autres outils très spécialisés sont également très performants, et apporte une estimation plus poussée de l’infrastructure en place. Mais Azure Migrate est un outil gratuit et entièrement intégré à l’écosystème Azure. Rien que pour ces deux raisons, je le trouve très bien dans beaucoup de scénarios.

Dans cet article, nous allons répondre à quelques questions sur Azure Migrate, puis nous suivrons un atelier technique, proposé par Microsoft via leur plateforme GitHub, et dédié à ce service.

Concernant la migration vers le Cloud, beaucoup de vidéos sont déjà disponibles sur YouTube. Je vous en ai sélectionné 3, dont une en français :

Seyfallah Tagrerout

Que fait exactement Azure Migrate ?

En deux mots, Azure Migrate travaille sur deux phase, l’estimation et la migration.

Azure Migrate vous aide à découvrir, à évaluer et à migrer des applications, une infrastructure et des données de vos environnements locaux vers Azure. Vous pouvez suivre de manière centralisée la progression de votre migration grâce à plusieurs outils de Microsoft et de fournisseurs de logiciels indépendants (ISV).
Microsoft

John Savill

Comme son nom l’indique, Azure Migrate va vous accompagner dans le transfert de données à travers les différentes phases que compose une migration d’architecture IT.

Car oui, il ne s’agit pas uniquement d’un copier-coller de données vers Azure, et tout est terminé.

Il s’agit avant tout de recréer des ressources correctement configurées et fonctionnant avec des liaisons réseaux adaptées, de les protéger an niveaux des accès, et de les sauvegarder.

Vous l’avez compris, Azure Migrate vous aide pour un grand nombre d’actions dans le processus de migration IT. Mais certaines tâches sont toujours à prévoir en post-migration.

Comme annoncée plus haut, Azure Migrate décompose en deux principales actions :

Evaluation : analyse de l’environnement actuel et préparation des besoins Cloud.
Migration : migration des systèmes et des données, à froid ou à chaud.

Combien coûte Azure Migrate ?

Azure Migrate est disponible gratuitement sur Azure. Toutefois, des frais peuvent être facturés dans l’utilisation d’outils développés par des ISV tiers, comme par exemple :

Thomas Maurer

Pour vous faire une meilleure idée, rentrons dans le vif du sujet avec un atelier dédié à la migration vers Azure. Celui a été conçu par Microsoft et est sous la forme de 3 exercices liés, et sont disponibles sur GitHub.

Le but de cet atelier est de vous faire découvrir les différentes actions d’Azure Migrate par l’utilisation dans un cas réel de migration d’architecture IT.

Comme le montre le schéma ci-dessous, l’objectif est de migrer plusieurs serveurs virtuels actuellement gérés sous un serveur Hyper-V vers le Cloud Azure :

Il est même question de :

Convertir la machine virtuelle dédiée à la base de données SQL en un service PaaS (Platform-As-A-Service), appelé Azure SQL Database.
Convertir le serveur frontal Ubuntu en Application Gateway.

Comptez environ 3-4 heures pour réaliser la totalité des actions décrites dans le manuel. Comme les manipulations sont nombreuses, cet atelier a été découpé en exercices :

Exercice 0 : Déploiement des ressources de l’atelier
Exercice 1 : Création du projet + démarrage de l’estimation
Exercice 2 : Migration de la base de données SQL
Exercice 3 : Migration des serveurs et finalisation de la configuration Azure

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet atelier dédié à Azure Migrate. En effet, la première étape est de simuler un environnement on-premise sur Azure. Ensuite, migrer celles-ci vers nouvelles ressources Azure. Pour tout cela, il nous faut :

Un tenant Microsoft
Une souscription Azure active

Exercice 0 – Déploiement des ressources de l’atelier Azure Migrate :

Tâche 1 – Déployer l’environnement de l’atelier :

Cette page GitHub est notre point de départ. Cliquez sur le lien de la page GitHub, ou sur le bouton de déploiement Azure ci-dessous pour créer des ressources simulant notre environnement on-premise et quelques ressources pour l’architecture cible Azure :

Vérifiez que tous les champs suivants sont renseignés. Je vous conseille de ne pas les changer (région ou mot de passe) car cela pourrait vous déranger par la suite.

Une fois la validation terminée, lancez la création des ressources :

Comme indiqué dans le document Microsoft, le déploiement de ces ressources de simulation on-premise est assez rapide : environ 6 à 7 minutes.

Deux groupes de ressources méritent votre attention :

Note : le déploiement de l’application est toujours sur la machine virtuelle Hyper-V via des scripts. Prévoyez au moins une bonne heure, le temps que le tout se termine.

Tâche 2 – Vérifiez l’environnement on-premise :

Une fois le déploiement et les scripts internes terminés, il est facile de contrôler le bon déploiement de l’application on-premise.

Rendez-vous pour cela dans le groupe de ressources SmartHotelHostRG, puis cliquez sur la machine virtuelle Hyper-V appelée SmartHotelHost :

Copiez l’adresse IP publique de la machine virtuelle Hyper-V :

Ouvrez votre navigateur internet, puis collez l’adresse IP publique dans la barre d’adresse. Un site web en HTTP doit s’ouvrir en affichant des réservations fictives d’hôtel :

Note : Les données affichées varient selon le jour ou la période, le tableau peut même être vide.

Tâche 3 – Vérifiez l’environnement cible sur Azure :

Un second tour rapide dans l’autre groupe de ressources Azure SmartHotelRG vous affiche quelques futures ressources exploitées par la suite, dont la base SQL utilisée comme service PaaS :

Si tout est bon pour vous, bravo, vous pouvez continuer sur le prochain exercice (Exercice 1) juste ici????. Pour rappel, voici quelques liens utiles pour ne pas vous perdre :

Atelier Azure Migrate :
- Lien GitHub pour les consignes de l’atelier
- Lien GitHub pour le déploiement des ressources
Articles du blog sur l’atelier d’Azure Migrate :

Azure Migrate – Exercice 3 Migration des serveurs + finalisation

Nous voilà dans la dernière ligne droite de cet atelier. Il ne nous reste qu’à migrer les machines virtuelles restantes vers Azure, grâce à Azure Migrate.

Comme dit plus haut, nous devons donc encore migrer les machines virtuelles suivantes, déjà estimées par Azure Migrate :

SmartHotelWeb1
SmartHotelWeb2
UbuntuWAF

Tâche 1 – Créer un compte de stockage :

La transition des données des 3 machines virtuelles passe par un compte de stockage Azure. Pour cela, cliquez sur l’icône suivant dans la barre latérale gauche du portail Azure :

Cliquez-ici pour créer un compte de stockage Azure :

Renseignez tous les champs en prenant soin de reprendre la même région Azure que votre base de données SQL récemment migrée, puis cliquez sur Suivant :

Retirer la fonction de Soft Delete pour le stockage objet, puis passez directement à la validation :

Lancez la création de votre compte de stockage :

Attendez quelques secondes, puis constatez sa création :

Tâche 2 – Créer un point de terminaison privé :

Afin que l’application communique entre les serveurs et la base de données Azure SQL, nous avons besoin d’établir une seconde communication via un point privé.

Nous pourrions utiliser le point d’accès public à Azure SQL, mais le but est aussi d’apporter une couche de sécurité supplémentaire.

Dans le portail Azure, recherchez votre base de données SQL :

Cliquez sur le nom de votre serveur Azure SQL :

Comme pour la précédente tâche 4 de l’exercice 2, créez un point de terminaison privé :

Nommez-le différemment du premier point de terminaison privé, puis cliquez sur Suivant :

Validez les champs ci-dessous, puis cliquez sur Suivant :

Indiquez les éléments du futur réseau de votre application, puis cliquez sur Suivant :

Laissez à Oui la création d’une zone de DNS privée, puis cliquez sur Suivant :

Lancez la création du point de terminaison privé, puis attendez :

Cliquez ici pour voir les caractéristiques du nouveau point de terminaison privé :

Cliquez comme ceci pour retrouver le FQDN de ce point de terminaison privé :

Tâche 3 – Enregistrez l’hôte Hyper-V sur Azure Migrate :

Retournez sur votre projet d’Azure Migrate pour entamer les premières étapes de migration des serveurs. Cliquez ici pour ajouter le serveur Hyper-V dans le processus de migration :

Sélectionnez le type Hyper-V, puis choisissez la région de votre choix :

Cette étape créée les ressources Azure suivantes :

Copiez l’URL disponible juste ici :

Sur le même écran, cliquez-ici pour télécharger la clef de registre utilisée pour l’enrôlement.

Retournez sur la session de bureau à distance sur le serveur Hyper-V, lancez le navigateur Google Chrome, puis coller l’URL précédemment copiée :

Lancez l’installation de l’application Azure Site Recovery :

Lancez l’installation d’Azure Site Recovery :

Cliquez pour enregistrer le serveur Hyper-V :

Collez le fichier contenant la clef de registre d’Azure Site Recovery sur le bureau de la session Hyper-V :

Recherchez le fichier de clef de registre, puis cliquez sur Suivant :

Cliquez sur Suivant :

Attendez quelques minutes :

Une fois terminé, retournez sur le portail Azure, actualisez la page suivante plusieurs fois si nécessaire, puis finalisez l’enregistrement du serveur Hyper-V :

Attendez quelques minutes que le traitement se termine :

Retournez sur la page principale de votre projet d’Azure Migrate, puis constatez l’apparition des serveurs virtuels hébergés sur votre machine Hyper-V :

Tâche 4 – Activez la réplication de Hyper-V :

Les machines virtuelles présentes dans le serveur Hyper-V sont bien remontées dans Azure Migrate. Elles ont maintenant besoin d’être répliquées via Azure Site Recovery.

Pour démarrer la configuration, cliquez sur Répliquer :

Continuez la démarche :

Choisissez Hyper-V, puis cliquez sur Suivant :

Renseignez les champs, cochez les 3 machines virtuelles remontées depuis l’estimation Azure Migrate, puis cliquez sur Suivant :

Complétez tous les champs comme indiqué ici, puis cliquez sur Suivant :

Complétez les informations attendues des 3 machines virtuelles, dont la taille selon vos souhaits ou l’estimation d’Azure Migrate, puis cliquez sur Suivant :

Conservez tous les disques des 3 machines virtuelles, puis cliquez sur Suivant :

Cliquez sur Répliquer pour démarrer le processus :

La page d’accueil de votre projet d’Azure Migrate doit vous indiquer le démarrage de la réplication de 3 machines virtuelles :

Cliquez ici pour afficher plus d’informations sur la réplication :

Comme le status ci-dessous l’indique, le premier point de réplication est toujours en cours :

En attendant que cela se termine, une consultation dans le service Azure Site Recovery créé par Azure Migrate montre bien le démarrage de réplications des 3 machines virtuelles :

Le compte de stockage créé précédemment contient bien 3 contenaires, un par machine virtuelle, pour assurer le tampon dans la réplication :

Retournez sur Azure Migrate, puis attendez que le statut de réplication de vos 3 machines virtuelles change :

Tâche 5 – Configurez des adresses IP locale s des VMs Azure :

L’affectation d’adresses IP locales sur les machines virtuelles Azure est nécessaire pour maitriser les liaisons réseaux entre les composants de notre architecture cible.

Cliquez sur la machine virtuelle smarthotelweb1 :

Cliquez ici pour éditer la configuration réseau :

Cliquez sur la carte réseau de la machine virtuelle :

Renseignez l’adresse IP locale 192.168.0.4, cliquez sur OK, puis sauvegardez la configuration :

Répétez ces étapes pour configurer les adresses IP privées des 2 autres machines virtuelles :

smarthotelweb2 : utilisez l’adresse IP privée 192.168.0.5
UbuntuWAF : utilisez l’adresse IP privée 192.168.0.8

Tâche 6 – Migration des 3 serveurs :

L’heure est maintenant venue de faire la migration des 3 machines virtuelles Hyper-V vers des machines virtuelles sur Azure.

Cliquez sur Migrer depuis votre projet Azure Migrate :

Sélectionnez les 3 machines virtuelles, puis cliquez sur Migrer :

Le portail Azure vous affiche 3 nouvelles notifications en relation avec votre action :

Un tour dans le journal des travaux d’Azure Migrate nous montre la mise en route de la migration :

L’ordre d’arrêt donné par Azure Migrate a bien été respecté par Hyper-V :

Un peu moins de 10 minutes plus tard, le journal des évènements d’Azure Migrate nous indique le succès de la migration Azure :

L’affichage des machines virtuelles montre les 3 nouvelles VMs Azure selon les configurations établies dans Azure Migrate :

Il ne nous reste qu’à modifier la configuration de l’application pour envoyer les requêtes vers la nouvelle adresse IP locale de la base de données SQL.

Tâche 7 – Configurez la connexion à la base de données :

Dans le cadre de notre atelier, la modification de l’adresse IP mémorisée pour la base de données SQL se fait directement sur la machine web. Il vous faut donc s’y connecter.

L’atelier Azure Migrate contient le déploiement du service Azure Bastion. Pour rappel, voici l’utilisé de ce service pour se connecter à une machine virtuelle Windows ou Linux :

Avant de s’y connecter, récupérez les éléments de connexion de la base de données Azure SQL :

Copiez la chaîne de connexion :

Retournez sur la liste des machines virtuelles, puis cliquez sur smarthotelweb2 pour vous y connecter via Azure Bastion :

Une fois connecté dans la session de bureau à distance sur la machine virtuelle smarthotelweb2, ouvrez l’explorateur de fichier dans le dossier suivant :

C:\inetpub\SmartHotel.Registration.Wcf

Ouvrez le fichier Web.config avec Notepad, puis remplacer comme ceci sans oublier de modifier le mot de passe demo!pass123 :

Avant :

Après :

Sauvegardez le fichier de configuration Web.config :

Inutile d’effectuer la même opération sur la machine smarthotelweb1.

Pour que la résolution du nom de la base de données SQL se fasse bien, retournez sur la zone DNS privée créée par le point de terminaison privé, puis ajoutez le réseau virtuel contenant les 3 machines virtuelles :

Configurez le lien comme ceci, puis cliquez sur OK :

Tâche 8 – Configurez l’adresse IP publique et testez l’application SmartHotel :

La tâche 8 de l’atelier Azure Migrate vous propose de remplacer le serveur Linux par un service PaaS d’Azure : Application Gateway avec Web Application Firewall (WAF) juste ici.

Pour ma part, je vous propose de conserver le serveur Linux et de lui rajouter une adresse IP publique.

Pour cela, rendez-vous dans la configuration réseau de votre machine virtuelle Linux UbuntuWAF, puis cliquez sur sa carte réseau :

Cliquez sur la configuration IP de la carte réseau :

Ajoutez une adresse IP publique, cliquez sur OK, puis sauvegardez :

Retournez sur la page de la machine virtuelle UbuntuWAF, puis copier l’adresse IP publique :

Ouvrez un nouvel onglet de votre navigateur internet, puis constatez le bon fonctionnement de l’application :

L’application est bien fonctionnelle et les liaisons entre les composants Azure sont bien établies.

Tâche 9 – Étapes post-migration :

Un certain nombre d’étapes de post-migration doivent être réalisées avant que les services migrés soient prêts à être utilisés en production. Ces étapes comprennent :

L’installation de l’agent Azure VM
Nettoyage des ressources de migration
Activation de la sauvegarde et de la reprise après sinistre
Le chiffrement des disques de la VM
S’assurer que le réseau est correctement sécurisé
S’assurer que la bonne gouvernance des abonnements est en place, comme le contrôle d’accès basé sur les rôles et la politique Azure.
Examiner les recommandations d’Azure Advisor et du Security Center.

Conclusion

Cet atelier est un bon moyen de tester et comprendre le service Azure Migrate avec une architecture IT simple via un exercice facilement réalisable par tous.

Ayant réalisé celui-ci plusieurs fois, je vous conseille d’en faire de même afin de bien comprendre comment Azure Migrate opère par le biais de plusieurs services, compte le compte de stockage ou Azure Site Recovery.

Tâche 10 : Nettoyer les ressources Azure

Si vous ne supprimez pas les ressources créées pendant l’atelier, la facturation se poursuivra.

Pour cela, supprimez les groupes de ressources suivants :

SmartHotelHostRG contenant le SmartHotelHost.
BastionRG contenant le Bastion Azure.
SmartHotelRG contenant les VM migrées
AzureMigrateRG contenant les ressources Azure Migrate

Azure Migrate – Exercice 2 Migration de la base de données SQL

La seconde partie de cet atelier consiste à basculer la base de données SQL vers Azure. Il s’agit donc de l’exercice 2.

Nous aurions pu migrer la machine virtuelle contenant le serveur SQL vers Azure en utilisant une machine virtuelle Azure (IaaS). Mais l’atelier se veut innovant et vous propose une migration vers le service PaaS, Azure SQL Database.

Il existe de nombreux avantages à l’utilisation d’un service managé par Microsoft, comme

Réduction possible de certains coûts.
Gestion par Microsoft des mises à jour du serveur SQL.

Par contre, certaines fonctionnalités sont inaccessibles dans un service PaaS. Prenez le temps de comparer les solutions disponibles avec vos besoins.

Pour réaliser la migration de données vers Azure, nous allons utiliser le service Azure Database Migration Service. Celui-ci propose deux niveaux de tarification :

Standard : prend en charge les migrations hors connexion (également appelées « migrations uniques »). Le niveau tarifaire Standard, qui offre des options à 1, 2 et 4 vCores, est généralement disponible gratuitement pour les clients.
Premium : prend en charge les migrations hors connexion et en ligne (également appelées « migrations continues ») pour les charges de travail critiques pour l’entreprise nécessitant un temps d’arrêt minimal.

Tâche 1 : Enregistrez le fournisseur de ressources Microsoft.DataMigration

Avant de pouvoir effectuer la migration de la base de données, il est nécessaire de vérifier l’enregistrement du fournisseur de ressources adéquat.

En effet, Azure Database Migration Service fonctionne avec le fournisseur de services Microsoft.DataMigration.

Allez sur la page de votre souscription Azure, recherchez le menu Fournisseurs de ressources et enregistrez Microsoft.DataMigration si cela n’est pas déjà fait :

Note : Cela peut également être fait par une commande Power Shell via Azure Cloud Shell :

Register-AzResourceProvider -ProviderNamespace Microsoft.DataMigration

Attendez quelques minutes, puis réactualisez la page :

Tâche 2 – Créez le service Database Migration Service :

Les fournisseurs de services sont eux aussi divisés en plusieurs ressources. L’activation antérieure d’un fournisseur de ressources n’active pas systématiquement tous leurs nouveaux services. C’est pour cela que les fonctions Désenregistrer / Enregistrer existent.

Dans le doute, vous pouvez le Désenregistrer :

Puis l’Enregistrer à nouveau :

Ce contrôle d’enregistrement des services d’un fournisseur de ressources est possible via une commande PowerShell :

Get-AzResourceProvider -ProviderNamespace Microsoft.DataMigration | Select-Object ProviderNamespace, RegistrationState, ResourceTypes

Ensuite, utilisez la base de recherche du portail Azure pour retrouver le service Azure Database Migration Service :

Cliquez sur Créer :

Pour cet atelier, utilisez le Service de migration de base de données classique :

Remplissez les champs suivants en lui donnant le nom SmartHotelDBMigration, puis allez sur l’onglet Réseaux :

Sélectionnez le réseau / sous réseau suivant, puis pour lancer la création :

Attendez quelques minutes que la création se termine :

Une fois le service créé sous Azure, nous allons avoir besoin d’un outil pour gérer la partie migration au niveau des serveurs on-premise. La tâche 3 va vous montrer cela.

Tâche 3 – Evaluez la base de données à l’aide de Data Migration Assistant :

Data Migration Assistant (DMA) est lui aussi un outil d’estimation, mais dédié aux bases de données.

Retournez sur le service Azure Migrate, puis cliquez-ici pour ajouter l’outil DMA :

Sélectionnez-le, puis cliquez sur Ajoutez l’outil :

Celui-ci apparaît alors dans la section base de données sous votre projet Azure Migrate :

Faites-en de même pour l’outil DMA dans la partie Migration :

Retournez sur la connexion RDP de la machine virtuelle Hyper-V on-premise SmartHotelHost, puis ouvrez le menu Démarrer pour lancer Google Chrome :

Allez sur la page web suivante, puis téléchargez la version Runtime .NET v4.8 :

Ouvrez l’exécutable d’installation :

Attendez que la décompression se termine :

Acceptez les Termes et Conditions, puis lancez l’installation :

Attendez quelques minutes :

Terminez l’installation, puis acceptez le redémarrage de la machine Hyper-V :

Retournez dans le menu Bases de données d’Azure Migrate, puis cliquez sur Estimer :

Copiez l’URL de téléchargement de DMA :

Attendez deux minutes environ, puis reconnectez-vous à la machine Hyper-V en RDP :

Réouvrez Google Chrome, puis rentrez l’URL de DMA précédemment copiée pour lancer son téléchargement :

Lancez l’installation de DMA, puis cliquez sur Suivant :

Acceptez les Termes et conditions :

Lancez l’installation de DMA :

Terminez l’installation sans cocher la case de lancement de DMA :

Toujours depuis la machine virtuelle Hyper-V, ouvrez l’explorateur de fichiers, puis rendez-vous dans le dossier suivant :

C:\Program Files\Microsoft Data Migration Assistant

Ouvrez le fichier Dma.exe.config avec Notepad :

Recherchez la chaîne de texte Azure Migrate :

Retirez les commentaires sur la clef EnableAssessmentUploadToAzureMigrate comme ceci, puis sauvegardez le fichier Dma.exe.config :

Avant :

<!-- <add key="EnableAssessmentUploadToAzureMigrate" value="true"/> -->

Après :

<add key="EnableAssessmentUploadToAzureMigrate" value="true"/>

Toujours sur votre session RDP de la machine Hyper-V, lancez le programme DMA depuis l’icône ajouté automatiquement sur le bureau :

Cliquez-ici pour démarrer un nouveau projet DMA :

Nommez le projet SmartHotelAssessment, puis configurez-le comme ceci :

Cliquez sur Suivant :

Créez une connexion au serveur SQL avec le mot de passe demo!pass123 :

Cochez les deux cases, puis cliquez sur Ajouter :

Démarrez l’estimation de la base de données SQL on-premise :

Attendez que le traitement se termine :

Quelques secondes plus tard, car la base de données de l’atelier est très petite, l’estimation est terminée, cliquez sur Téléverser dans Azure Migrate :

Cliquez sur Connecter dans la section Azure :

Renseignez votre identifiant Azure utilisé pour cet atelier :

Remplissez les champs, puis cliquez sur Téléverser :

Retournez sur Azure Migrate, puis lancez un rafraîchissement de la page :

Constatez l’apparition de l’estimation de la base de données SQL :

L’estimation de la base de données SQL est bien incorporé à notre projet Azure Migrate. Fort de ce résultat, il nous est maintenant possible de la migrer grâce à DMS.

Tâche 4 : Créez un projet de migration DMS

Ayant créé le service Azure Database Migration Service (DMS) en Tâche 2, nous allons pouvoir migrer notre base de données SQL grâce à lui. Avant cela, nous avons besoin d’établir une connexion réseau entre le futur serveur SQL (Azure SQL) et Azure DMS.

Pour cela, depuis le portail Azure, rendez-vous dans le groupe de ressources SmartHotelRG, puis sélectionnez votre serveur SQL :

Dans la section Réseaux, cliquez sur Accès privé pour en ajouter un nouveau :

Donnez-lui le nom SmartHotel-DB-for-DMS, puis cliquez sur l’onglet Ressource :

Remplissez les champs comme ci-dessous, puis cliquez sur l’onglet Réseau virtuel :

Sélectionnez le réseau virtuel DMSvnet, puis cliquez sur l’onglet DNS :

Créez une nouvelle Zone DNS privée, puis continuez :

Lancez la création :

Une fois la création terminée, vérifiez dans la zone DNS privée que le serveur de la base de données Azure SQL a bien l’adresse IP privée 10.1.0.5 :

Pour des questions de sécurité, retirez l’accès publique au serveur Azure SQL, que l’on n’utilisera pas dans notre atelier :

Retournez sur le service Azure Database Migration Service (DMS), puis cliquez sur Nouveau projet de migration :

Renseignez les champs du projet comme ceci, puis cliquez sur Créer :

Renseignez les informations sur la source SQL avec le mot de mot de passe demo!pass123 :

*Le service DMS se connecte à l’hôte Hyper-V, qui a été préconfiguré avec une règle NAT pour transmettre les demandes SQL entrantes (port TCP 1433) à la VM SQL Server.*

Choisissez la seule base de données disponible :

Renseignez le nom unique votre serveur Azure SQL avec le mot de passe demo!pass123 :

Cliquez sur Sauvegarder le projet :

La création du projet dans DMS est maintenant terminée, il nous reste plus qu’à passer à l’action pour la migration de données.

Cette opération va s’effectuer sur deux tâches :

migration du schéma des tables de la base de données, puis migration des données en elles-mêmes.

Il est donc bien possible d’effectuer les deux actions en une, ou aussi d’espacer ces deux tâches dans le temps, pour migrer les données définitive le jour J.

Tâche 5 – Migrez le schéma de la base de données SQL :

Comme indiqué précédemment, cette étape est nécessaire pour le transfert de données. Pour cela, cliquez-ici pour créer et démarrer cette nouvelle activité :

La configuration étant déjà faite lors de la création du projet, il ne vous reste qu’à remettre le mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Pour la base de données cible, même mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Sélectionnez la base de données cible et reprenez le schéma de la source, puis cliquez sur Suivant :

Nommez l’activité SchemaMigration, puis lancez le démarrage de celle-ci :

Suivrez l’évolution de celle-ci, cliquez sur Rafraîchir :

Environ une minute plus tard, vérifiez que le statut de l’activité change en Complété :

Sur la base de données Azure SQL Database, vous pouvez voir le tout petit pic provoqué par cette activité :

Il nous reste maintenant qu’à migrer les données vers la base de données Azure SQL Database. Comme rappelé plus haut, la version gratuite d’Azure Database Migration Service ne nous autorise que des migrations à froid. Ce qui ira très bien dans le cadre de notre atelier.

Tâche 6 – Migrez les données sur site :

Toujours dans Azure Database Migration Service, cliquez-ici pour démarrer la seconde activité de migration des données :

De la même façon que lors de la première activité, la configuration est déjà faite, il ne vous reste qu’à remettre le mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Pour la base de données cible, toujours le même mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Vérifiez que la base de données de notre application d’hôtellerie est bien cochée, puis cliquez sur Suivant :

Pour la base de données cible, même mot de passe que pour l’utilisateur sa : demo!pass123, puis cliquez sur Suivant :

Sélectionnez la base de données cible, puis cliquez sur Suivant :

Ne cochez qu’une seule table sur deux car seule celle-ci contient les réservations d’hôtels :

Nommez l’activité DataMigration, puis lancez le démarrage de celle-ci :

Environ une minute plus tard, vérifiez que le statut de l’activité change en Complété :

Si tout s’est bien passé, les données de notre application sont maintenant chargées dans Azure SQL Database. Il ne nous reste qu’à retirer la connection privée établie entre DMS et Azure SQL Database.

Retournez sur le serveur Azure SQL et retirer cette liaison comme ceci :

La migration des données est la première véritable étape de transfert de notre architecture dans Azure.

Pourquoi avoir transféré les données avant les autres serveurs ?

Car le transfert de serveur sera directement précédé de la bascule de notre application. Et comme l’application a besoin des données pour fonctionner, c’est pour cela que les opérations sont ordonnées dans cet ordre.

Nous voilà dans la dernière ligne droite de cet atelier. Il ne nous reste qu’à migrer les machines virtuelles restantes vers Azure, toujours grâce à Azure Migrate : Exercice 3.

Pour rappel, voici un rappel des liens de cet atelier pour ne pas vous perdre :

Atelier Azure Migrate :
- Lien GitHub pour les consignes de l’atelier
- Lien GitHub pour le déploiement des ressources
Articles du blog sur l’atelier d’Azure Migrate :

Changez la résidence de vos données 365

Bonne nouvelle en ce début du mois de novembre, Microsoft a réouvert le processus gratuit de migration de données 365 pour les tenants existants. De quoi parle-t-on exactement ? En quelques mots, ces dernières années, Microsoft a ouvert de plus en plus de centres de données, et cela allonge donc automatiquement la liste des pays. Cet avantage permet aux entreprises de choisir dans quel pays les données 365 seront stockées.

Qu’est-ce que la résidence des données 365 ?

Avant toute chose, Microsoft liste leurs termes et définitions en relation avec la résidence de données 365 juste ici.

Important : les services 365 s’exécutent sur l’ensemble des centres de données Microsoft. A ce titre, les données peuvent donc être stockées dans plusieurs centres de données dans le cadre de transit :

La résidence des données fait ici donc référence à l’emplacement géographique où les données 365 sont stockées au repos.

Pourquoi s’intéresser à la résidence des données 365 ?

La résidence des données est cruciale pour les gouvernements, les entreprises du secteur public, les organismes d’éducation ou encore les entreprises travaillant dans des secteurs réglementés. Cette exigence est alors indispensable afin d’accroître la protection des informations personnelles et/ou sensibles.

Quelle est la résidence des données 365 par défaut ?

Lorsqu’on créé un nouveau tenant, il vous est systématiquement demandé de spécifier un pays durant le processus de création.

Important : Une fois le tenant créé, la zone géographique par défaut ne peut plus être modifiée.

Pourquoi changer la résidence des données ?

De plus, de nombreux pays exigent de leurs entreprises afin qu’elles se conforment aux lois, aux réglementations ou aux normes de secteur qui régissent explicitement l’emplacement du stockage des données.

Changer la résidence des données 365 est alors utile pour se conformer à ces règles, mais offre une également proximité entre le stockage des données et les utilisateurs finaux.

Qu’est-ce que le programme de déplacement hérité Data Residency ?

Coïncidant avec le lancement du module complémentaire Microsoft 365 Advanced Data Residency, le programme de déplacement n’est plus proposé lors du lancement de nouvelles régions de centre de données locales.
Microsoft Learn

Cette ouverture permettait donc de pouvoir migrer gratuitement les données de la région macro vers une région de centre de données locale qui correspond au pays d’inscription initial.

Autrement dit, de l’Europe vers la Suisse, la France, …

Comment activait-on cette demande de migration ?

Les clients éligibles voyaient cette option dans leur Centre d’administration Microsoft 365. Cocher cette case permettra de demander que leurs données applicables soient déplacées vers leur nouvelle région de centre de données :

Quand est-ce que la migration allait être opérée ?

Comme le monde la copie d’écran du tenant ci-dessus, la migration du tenant pouvait prendre jusqu’à 24 mois, à partir de la date d’échéance de la demande. La bonne nouvelle est que Microsoft a réouvert ce service gratuit, et ce pour une dernière fois !

Pendant combien de temps je peux activer cette option ?

Le tableau ci-dessous affiche la liste des pays éligibles et les dates associées. Il faut donc cocher la case précédente avant la fin de la période du pays qui vous concerne :

Important : Il s’agit de la dernière fenêtre de migration gratuite possible !!! Après ces dates, ce service existera toujours, mais sera payant ????

Et si j’ai d’autres questions concernant la migration ?

Microsoft met à disposition une FAQ concernant ce service et peut déjà répondre à certaines de vos interrogations ????

Bonne migration !

Vous déménagez de région ? Utilisez Azure Resource Mover

Dans cet article, nous allons détailler l’outil appelé Azure Resource Mover et regarder les étapes nécessaires à la migration de ressources Azure d’une région A à une région B.

Qu’est-ce qu’Azure Resource Mover ?

Microsoft a mis à disposition un outil très pratique, appelé Azure Resource Mover. Cet outil vous sera utile si vous souhaitez déplacer des ressources d’une région Azure à une autre. Vous trouverez l’article de documentation Microsoft via ce lien.

Voici également un petit rappel sur « Qu’est-ce qu’une région Azure ?«

Région Azure : Une région Azure est un ensemble de centres de données, déployés dans un périmètre défini par la latence et reliés par un réseau régional dédié. Avec plus de régions mondiales que tout autre fournisseur de cloud, Azure offre à ses clients la flexibilité de déployer des applications là où ils en ont besoin. Une région Azure a une tarification et une disponibilité de service distinctes.
Source Microsoft

*Carte des régions Azure à travers le monde. Cette carte évolue très régulièrement.*

Qu’apporte Azure Resource Mover dans un processus de migration intra-région ?

Ce nouvel outil facilite grandement le processus de migration puisqu’il fournit une interface unique avec un système d’étapes et de contrôle des dépendances. Cela permet donc de :

Réduire la complexité et le temps de migration
Identifier les dépendances des ressources Azure
Déplacer les ressources de manière groupée
Nettoyer automatiquement les ressources dans la région initiale
Fonctionner en mode Test : vous pouvez encore annuler si vous ne souhaitez pas effectuer la migration

Les autres types de migration sur Azure

Il existe des besoins autres que la migration sur une autre région. Microsoft met donc à disposition deux autres types de migration :

Déplacement de ressources Azure sur un autre groupe de ressources
Déplacement de ressources Azure sur une autre souscription Azure

Ce dernier cas peut s’avérer intéressant si l’on souhaite justement abandonner le paiement PAYG (Pay-As-You-Go ou encore appelé paiement à la demande par carte bancaire) pour s’orienter vers d’autres canaux de distribution, tels que le CSP ou encore EA.

Grandes étapes

Voici la liste des grandes étapes que vous allez déclencher dans Azure Resource Mover :

Création du projet de migration
Configuration des ressources de destination
Validation des dépendances
Migration (Préparation / Initiation / Confirmation)
Suppression des ressources initiales

Dans certains cas et également dans mon exemple plus bas, il est possible de relancer l’étape 4 à plusieurs reprises sous forme de cycle. Azure Resource Mover apporte donc une excellente visibilité sur les étapes et les cycles restants et leur ordonnancement.

Liste des ressources migrables avec Azure Resource Mover

À l’aide de Resource Mover, vous pouvez actuellement déplacer les ressources suivantes d’une région à une autre :

Machines virtuelles Azure et disques associés
Cartes réseau
Groupes à haute disponibilité
Réseaux virtuels Azure
Adresses IP publiques
Groupes de sécurité réseau
Équilibreurs de charge internes et publics
Bases de données Azure SQL et pools élastiques

Note : Vous ne pouvez pas sélectionner des disques managés comme ressources à déplacer entre des régions. Les disques sont cependant copiés lors d’un déplacement d’une machine virtuelle. Vous pourrez retrouver la liste complète avec tous les types de ressources Azure ici, accompagnés des 3 possibilités de migration.

*Processus de migration via Azure Resource Mover.*

Etape I : Création du projet de migration

Cette étape s’effectue directement dans le groupe contenant des ressources Azure à migrer. Il suffit alors de sélectionner les ressources et d’utiliser la fonction correspondante dans la barre d’action.

*Pour simplifier les étapes, il est préférable de regrouper au préalable toutes les ressources à migrer dans un seul et même groupe de ressources.*

L’écran suivant nous présente les informations de base sur les ressources sélectionnées et nous demande également de choisir la région de destination.

Il est indiqué dans les annotations que la migration des ressources sur une autre souscription peut être faite dans un second temps. Prenez donc le temps de la réflexion sur votre meilleur « itinéraire de migration ».

L’écran ci-dessous reprend la liste des ressources précédemment sélectionnées dans le groupe de ressources :

Dans mon exemple, une ressource est manquante dans cette liste, je peux cliquer sur le lien pour avoir plus d’informations.

Un encadré s’ouvre à droite et liste les ressources exclues par Azure Resource Mover. Cette information est précieuse car elle vous permet directement d’écarter ou de repenser certains projets de migration.

*Pas d’inquiétude dans mon cas puisque le disque rattaché à ma machine virtuelle sera bien copié.*

La confirmation sur l’écran suivant va lancer le projet et de vous proposer le démarrage de la phase suivante, déclenchée elle aussi à votre demande :

*Ce bouton ne déclenche aucun traitement irréversible 🙂*

Une fois ce traitement validé, l’étape II va pouvoir être déclenchée dans Azure Resource Mover.

Etape II : Configuration des ressources de destination

Cette étape est facultative. Elle permet néanmoins d’effectuer des modifications aux ressources créées. Dans mon exemple, je dispose d’une machine n’ayant pas de zone de disponibilité. Je veux migrer cette machine virtuelle en lui précisant sur quelle zone de disponibilité je la souhaite : Région « North Europe Zone 3 ».

*Un clique sur la configuration de la machine virtuelle m’ouvre l’écran ci-dessous.*

*Je spécifie ici la zone 3 au sein de la région North Europe.*

Je profite également pour faire une modification sur l’adresse IP publique rattachée à ma machine virtuelle. Souhaitant mettre en place cette VM dans une de zone de disponibilité, je dois changer le SKU de cette dernière en Standard pour que la migration se fasse sans souci :

Changement de SKU pour l’adresse IP publique en standard.

Etape III : Validation des dépendances

Comme dans beaucoup de cas, les ressources Azure sont interconnectées entre elles. L’exemple le plus évident est bien la machine virtuelle. De base, une machine virtuelle créé les ressources Azure suivantes :

Machine virtuelle
Disque OS
Carte réseau
Disque de données (facultatif)
Groupe de sécurité réseau (facultatif)
Adresse IP publique (facultative)

Le processus de validation des dépendances va donc vérifier que rien n’est oublié dans ce projet de migration.

*A partir de cet écran et comme indiqué en haut à gauche, nous sommes bien dans Azure Resource Mover.*

Une fois la validation des dépendances effectuée, il arrive que certaines erreurs remontent afin d’être résolues avant la migration. Un clique sur le lien vous donne toutes les informations nécessaires pour les comprendre.

*Dans le cas présent, cette erreur est considérée comme « normale » puisque cette alerte concerne le disque OS. Le processus va se donc régler de lui-même cette erreur par la suite.*

*D’autres erreurs peuvent aussi remonter. Ici par exemple une migration vers l’Asie m’est bloquée à cause de la taille de ma machine virtuelle.*

Etape IV : Migration

Comme vous le voyez dans la colonne Status sur toutes mes ressources Azure, il est indiqué que ces dernières sont en attente de la préparation au déplacement. Dans mon exemple de machine virtuelle, je dois effectuer la migration en deux cycles pour palier l’erreur du disque managé :

Cycle A : migration du groupe de ressources uniquement
Cycle B : migration des autres ressources

Cycle A – Préparation à la migration

Il s’agit de la première étape de la migration à proprement parlé.

Je commence donc mon cycle A avec uniquement mon groupe de ressources et clique sur **Prépare**.

Pour continuer, je clique sur **Prépare**.

A ce moment-là et après un court traitement de la part d’Azure, je constate que le statut de mon groupe de ressources a changé :

*Le statut est passé de **Prépare** à **Initialisation de la migration**.*

Cycle A – Initialisation de la migration

Je continue donc le processus de migration du groupe de ressources en le sélectionnant à nouveau et en cliquant sur Initier la migration :

*L’erreur sur la machine est toujours présente mais cela ne gêne pas en soi.*

*Peu de choix sont possibles sur les écrans de confirmation 🙂*.

Une fois l’initialisation lancée, je peux déjà constater la création d’un nouveau groupe de ressources sur ma région de destination :

*La présence d’un second groupe de ressources est aussi constatée sur la région de destination.*

*Le statut est passé d’**Initialisation de la migration** à **Confirmation de la migration**.*

Cycle A – Confirmation de la migration

Cette dernière étape est nécessaire pour valider la migration des ressources sélectionnées. Je reste donc sur mon groupe de ressources et la déclenche dans la foulée :

Azure Resource Mover créé dans cette étape de nouvelles ressources. On retrouve dans le groupe de ressources de destination le disque qui sera utilisé pour la nouvelle machine virtuelle :

*Le disque de la machine virtuelle est lui aussi créé dans le futur groupe de ressources.*

De plus, d’autres ressources sont créées dans le second groupe vu précédemment. Ce groupe de ressources va donc servir à la transition des données de la machine virtuelle :

*Est présent dans ce groupe un coffre et un compte de stockage pour le cache de transition.*

*Le groupe de ressources a encore changé de statut. L’erreur sur la machine virtuelle a disparu.*

Je vais pouvoir attaquer le cycle B avec les autres ressources à migrer. J’effectuerai la suppression de toutes les ressources sur la région initiale une fois que la migration sera entièrement terminée.

Cycle B – Préparation à la migration

Comme pour le premier cycle, nous répétons les mêmes étapes avec les autres ressources Azure que nous souhaitons migrer.

*Vous ne pouvez pas vous tromper dans les étapes à suivre.*

*L’étape de préparation prendra plus de temps que lors du cycle A.*

Cycle B – Initialisation de la migration

En seconde étape, je continue le processus de migration en sélectionnant les ressources et en cliquant sur Initier la migration :

Une fois cette étape terminée, un tour dans le nouveau groupe de ressources montre que les autres ressources sont venues se rajouter au disque. A noter que la copie d’écran ci-dessous nous montre maintenant deux disques dont un appelé réplica :

*La présence de 2 disques nous rappelle le fonctionnement d’Azure Site Recovery dans le cadre d’un DR.*

Cycle B – Confirmation de la migration

Nous lançons donc la dernière étape encore une fois pour valider la migration des ressources sélectionnées :

Un rapide contrôle dans la liste des machines virtuelles nous montre que la VM de la première région a bien été éteinte, tandis que celle dans la seconde région est maintenant allumée :

Point important : L’adresse IP publique de la seconde machine virtuelle dans la seconde région ne sera jamais identique à la première. Les adresses IP publiques ne se transfèrent pas entre régions. Il s’agit ici d’une nouvelle adresse IP publique.

*Un second contrôle sur la machine virtuelle de la seconde région indique bien la zone 3, comme paramétré dans Azure Resource Mover.*

Etape V : Suppression des ressources

La dernière étape de ce processus de migration comprend la suppression des anciennes ressources encore présentes dans la première région. Elle peut être faite via Azure Ressource Mover ou directement via le groupe de ressource en lui-même :

A ce point, toutes les ressources présentes ici se retrouve dans le même status final.

Le message d’erreur vous indique que le groupe de ressources initial ne peut être supprimé via Azure Ressources Mover :

*Vous pouvez malgré tout continuer cette étape de suppression avec les autres ressources.*

Les ressources sélectionnées précédemment ont donc terminé le processus d’Azure Resource Mover :

*Il ne reste plus qu’à s’occuper du groupe de ressources.*

Une suppression manuelle reste donc à faire dans la première région Azure :

*Le groupe de ressources non supprimé contient encore la dépendance de la machine virtuelle pris en compte par Azure Resource Mover.*

Une seconde suppression est également à faire pour entièrement terminer le processus. il s’agit ici du projet créé par Azure Resource Mover, mais aussi du compte de stockage et du coffre créé pour assurer la copie des données du disque de la machine virtuelle entre les deux régions.

A noter que la suppression de l’ensemble ne peut se faire qu’après le retrait des verrous posés sur les ressources :

Conclusion

Au final, Azure Resource Mover est un très bon outil de migration entre différentes régions Azure. Gardez encore en tête que certaines limitations subsistent et que les migrations très complexes à étapes sensibles seront peut-être gérées en dehors de cet outil.

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Resource Mover ????