Clonez votre Windows 365

Windows 365 est un service de Cloud PC créé par Microsoft et disponible via un système licence mensuelle fixe. Le service Windows 365 est en évolution constante depuis sa sortie en 2021. Très proche d’Azure Virtual Desktop, Windows 365 se distingue principalement par l’absence de connaissances nécessaires sur Azure. Mais que se passe-t-il quand un utilisateur rencontre des difficultés sur son poste Windows 365 ?

J’ai écrit cet article à la suite d’un souci technique sur un poste Windows 365. Pour des questions de commodités, nous avons pris la décision de cloner ce Cloud PC afin de l’analyser et de le redéployer par la suite.

Avant d’aller plus loin, et si Windows 365 nous vous semble pas familier, voici quelques articles très intéressants et disponibles sur ce blog :

Voici ce que Microsoft en dit en quelques mots :

Windows 365 est un service cloud qui crée automatiquement un nouveau type de machine virtuelle Windows (PC cloud) pour vos utilisateurs finaux. Chaque PC cloud est attribué à un utilisateur et devient ainsi son appareil Windows dédié. Windows 365 offre les avantages de productivité, de sécurité et de collaboration de Microsoft 365.

Microsoft Learn

Saviez-vous que votre Cloud PC est accessible avec un simple smartphone comme ressource local ?

Disons-le franchement, la documentation Microsoft ne m’a pas vraiment aidé 😥. Je vous propose donc ici de suivre un exercice étape par étape concernant le clonage du poste Windows 365 déjà en place, dans le but de l’analyser en dehors de l’environnement de production.

Pour des questions de confidentialité, l’environnement présent ci-dessous sera une copie approchante de l’environnement réel du client concerné.

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
  • Une licence Windows 365

Commençons par recréer un environnement Windows 365 fonctionnel

Etape I – Environnement Windows 365 de départ :

Pour cela, commencez par créer un groupe Entra ID dans lequel votre utilisateur de test Windows 365 est présent :

Assignez à cet utilisateur une licence Windows 365 :

Depuis le portail Azure, recherchez le service des réseaux virtuels :

Créez un réseau virtuel Azure, ce dernier sera utilisé pour créer le poste Windows 365 :

Renseignez les champs de base de votre nouveau réseau virtuel, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre réseau virtuel :

Environ 30 secondes plus tard, votre réseau virtuel Azure est créé :

Retournez sur la page dédiée à Windows 365 sur le portail Intune, puis lancez la création d’une connexion vers Azure :

Renseignez les champs relatifs au réseau virtuel Azure créé précédemment, puis cliquez sur Suivant :

Démarrez la validation Intune, puis lancez la création de la connexion Azure :

La création de la connexion vers Azure apparaît alors, et les premiers contrôles de conformité démarrent automatiquement :

Attendez environ 5 minutes que les contrôles sur la connexion Azure soit terminés :

Cliquez-ici pour définir les paramètres utilisateurs :

Choisissez parmi les options suivantes :

Assignez les paramétrages utilisateurs au groupe Entra ID, puis lancez la création :

Afin de créer le premier poste Windows 365, cliquez sur le menu suivant afin d’assigner une police de provisionnement à votre utilisateur de test :

Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :

Choisissez une image déjà présente dans la galerie Microsoft, puis cliquez sur Suivant :

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

Assignez la police de provisionnement à votre groupe Entra ID, puis cliquez sur Suivant :

Lancez la création de votre police de provisionnement Windows 365 :

Vérifiez la bonne apparition de celle-ci :

Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre Cloud PC assigné à votre utilisateur de test :

Environ 15 minutes plus tard, le provisionnement du poste Windows 365 est terminé :

Sur votre poste local, téléchargez l’application Remote Desktop depuis la page officielle Microsoft, installez-là, puis ouvrez une session avec votre utilisateur de test :

Acceptez en cliquant sur Oui :

Ouvrez une session Windows 365 afin de constater le bon fonctionnement du Cloud PC :

Téléchargez le logiciel Google Chrome depuis la page officielle suivante :

Choisissez la version MSI, puis démarrez le téléchargement :

Une fois téléchargé, ouvrez l’exécutable :

Lancez l’installation de Google Chrome :

Notre environnement de départ est en place et fonctionne correctement. Nous allons maintenant nous intéresser au clonage du poste Windows 365.

Etape II – Sauvegarde du poste Windows 365 :

Afin de stocker l’image de notre Cloud PC Windows 365, commençons par rechercher le service de compte de stockage sur le portail Azure :

Cliquez-ici pour créer le compte de stockage :

Renseignez les informations de base dont le nom unique de votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre ressource Azure :

Environ 30 secondes plus tard, cliquez-ici pour ouvrir la page de votre compte de stockage :

Ajoutez un role RBAC sur votre compte stockage par le menu suivant :

Recherchez le rôle Azure RBAC ci-dessous, puis cliquez sur Suivant :

Ajoutez l’application Windows 365, puis lancez la validation :

Lancez l’assignation RBAC par le bouton suivant :

Ajoutez également le rôle RBAC suivant sur la souscription Azure contenant le compte de stockage :

Depuis le portail Intune, retournez sur le Cloud PC afin de déclencher la création d’un point des restauration manuel par le menu suivant :

Confirmez votre choix en cliquant sur Oui :

Quelques minutes plus tard, votre point de restauration apparaît dans la liste ci-dessous. Cliquez-ici pour copier ce dernier sur votre compte de stockage :

Sélectionnez la souscription Azure et le compte de stockage correspondants, puis cliquez sur Partager :

L’ordre de copie est déclenché, attendez maintenant quelques minutes :

Le status du partage est consultable ici :

Depuis le portail Azure, retournez sur votre compte de stockage puis lancez plusieurs rafraichissements si besoin :

Constatez la création d’un nouveau conteneur blob, puis cliquez sur celui-ci :

Constatez la création d’un nouveau blob au format VHD :

Une image de notre poste Windows 365 est maintenant présente dans Azure. La prochaine étape sera de créer une machine virtuelle reprenant ce VHD.

Etape III – Création d’une machine virtuelle Azure :

Avant de créer directement la machine virtuelle, commencez par créer un disque OS via le service Azure suivant :

Cliquez-ici pour créer le disque OS :

Renseignez les informations de base pour votre disque OS, dont l’URL de votre blob VHD :

Vérifiez les champs suivants, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre disque OS :

Environ 1 minute plus tard, cliquez-ici pour consulter la page de votre disque OS :

Cliquez-ici pour réutiliser votre disque OS dans la création d’une machine virtuelle Azure :

Renseignez les champs de base votre machine virtuelle, dont le disque OS :

Choisissez la taille de votre VM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :

Décochez la case d’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre machine virtuelle :

Environ 2 minutes plus tard, votre VM est créée, cliquez-ici :

Vérifiez le bon démarrage de votre VM par le biais du menu suivant :

Déployez Azure Bastion de pouvoir vous y connecter en RDP de façon sécurisée :

Afin de vous connecter à votre VM en utilisant le compte Entra ID de votre utilisateur de test via Azure Bastion, passez la commande PowerShell suivante via le menu dédié :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '0' # was before 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '0' # was before 1

Attendez la confirmation de la bonne exécution de votre script PowerShell :

Ouvrez une connexion RDP à distance depuis Azure Bastion avec votre utilisateur de test, toujours précédé de la mention AzureAD\ :

Constatez la bonne ouverture de votre session Windows :

Constatez la présence de l’icône Google Chrome sur le bureau de la VM :

Notre machine virtuelle Azure est maintenant en place. Nous pourrions alors effectuer tous les tests ou des modifications nécessaires sur celle-ci. Afin de donner un exemple banal, nous allons installer Mozilla sur notre VM.

Etape IV – Modification de la VM :

Rendez-vous sur la page officielle de Mozilla pour y télécharger et installer une version MSI du navigateur :

Constatez la présence de l’icône Firefox sur le bureau de la VM :

Profitez-en pour installer toutes les dernières mises à jour de Windows 11 :

Redémarrez la machine virtuelle Azure si nécessaire :

Vérifiez que Windows Update ne vous propose plus d’autres mises à jour Windows :

Depuis le portail Azure, relancez le script en sens inverse :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '2' # was before 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '1' # was before 0

Depuis la session RDP déjà ouverte via Azure Bastion, lancez la commande sysprep suivante en mode administrateur :

Sysprep /generalize /oobe /mode:vm /shutdown

Attendez qu’Azure Bastion vous indique une fermeture de session inattendue :

Une fois la machine virtuelle arrêtée au niveau OS, lancez un arrêt depuis le portail afin de désallouer les ressources Azure :

Une fois la machine virtuelle arrêtée et désallouée, lancez une capture de celle-ci :

Renseignez les champs de base de votre image, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre image :

Environ 3 minutes plus tard, constatez la bonne création de votre image :

Nous allons maintenant pouvoir recréer un second Cloud PC Windows 365 à partir de cette nouvelle image modifiée.

Etape V – Nouvel environnement Windows 365 :

Pour plus de facilité, j’ai recréé un second groupe Entra ID avec un second utilisateur de test que celui utilisé précédemment :

J’ai réassigné la licence Windows 365 précédemment assignée à mon nouvel utilisateur de test :

A partir du portail Intune, cliquez sur le menu suivant pour importer votre propre image Windows 365 :

Renseignez les informations de votre nouvelle image Windows 365, dont la source de votre image présente sur votre environnement Azure :

Le téléversement de votre image depuis Azure et vers Intune commence alors :

Environ 30 minutes plus tard, votre image personnalisée est bien chargée et reconnue par Intune :

Cliquez-ici pour créer une seconde police de provisionnement Windows 365 :

Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :

Choisissez votre image personnalisée, puis cliquez sur Suivant :

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

Assignez votre police de provisionnement à votre second groupe Entra ID, puis cliquez sur Suivant :

Lancez la création de votre police de provisionnement Windows 365 :

Vérifiez la bonne apparition de celle-ci :

Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre nouveau Cloud PC, assigné cette fois à votre second utilisateur de test :

Environ 15 minutes plus tard, le provisionnement du nouveau poste Windows 365 est terminé :

Depuis l’application Remote Desktop, ouvrez une session avec votre second utilisateur de test :

Acceptez en cliquant sur Oui :

Constatez la bonne ouverture de votre session Windows :

Constatez la présence de deux icônes Chrome et Firefox sur le bureau Windows :

😎

Troubleshooting Quelques erreurs possibles :

Voici quelques erreurs que j’ai pu rencontrer lors de cet exercice :

  • Erreur rencontrée lors du lancement de la commande sysprep car des mises à jour Windows étaient encore en attente :
  • Erreur rencontrée lors du téléversement de mon image créée directement depuis mon blob VHD, sans avoir créé de machine virtuelle Azure entre temps :
  • Erreur rencontrée lors de la création d’une VM depuis une image sans avoir créé le disque OS entre temps :

Conclusion :

Cette opération nous montre encore une fois les synergies fortes entre tous les outils Cloud de Microsoft. J’espère que ce petit exercice pourra en aider quelques-uns sur les interventions IT sur des postes Windows 365 🤘🙏

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-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) :

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 :

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 :

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 locales 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 :

URL disponible juste ici.

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 :