Étiquette : Migration

Migrez vos données 365 avec BitTitan !

Ayant récemment écrit un article sur l’outil de migration ShareGate, je trouvais l’exercice intéressant à continuer au travers d’autres outils connus sur le marché. J’ai donc pris l’opportunité de tester MigrationWiz, proposé par BitTitan, afin de comprendre un peu plus ses différents fonctionnement, et ses possibilités de migration de données depuis un environnement Microsoft 365 vers un autre.

Qui est BitTitan ?

BitTitan est une entreprise spécialisée dans la migration de données vers le cloud. Elle propose notamment MigrationWiz, un outil qui facilite le transfert de données entre diverses plateformes comme Microsoft 365 et Google Workspace. Aujourd’hui nous avons la possibilité de tester cet outil au travers d’une migration de tenant à tenant.

Quelles sont les différences entre MSPComplete et MigrationWiz ?

MSPComplete et MigrationWiz sont 2 solutions proposées par BitTitan, mais répondant à des besoins différents :

  • MSPComplete est une plateforme de gestion complète destinée aux prestataires de services gérés (MSP) qui automatise l’ensemble des processus commerciaux (de l’onboarding à la facturation et au suivi des projets).
  • MigrationWiz est un outil spécialisé dans la migration de données, permettant de transférer de manière sécurisée et automatisée emails, documents et autres contenus d’une plateforme cloud à une autre, sans gérer l’ensemble des opérations d’un MSP.

Comment fonctionne le modèle de licence MigrationWiz ?

A la différence de ShareGate, le modèle de licence de MigrationWiz repose sur l’achat de licences spécifiques adaptées à chaque type de migration, comme par exemple :

  • User Migration Bundle License (UMB) : Permet de migrer la boîte aux lettres, les archives et les documents d’un utilisateur avec une capacité de transfert illimitée, et inclut la configuration d’Outlook via DeploymentPro.
  • Mailbox Migration License : Conçue pour les migrations de boîtes aux lettres uniquement, avec une limite de 50 Go de données transférées par licence.
  • Public Folder License : Spécifique aux migrations de dossiers publics sur Exchange, chaque licence prenant en charge jusqu’à 10 Go de données.
  • Collaboration (per Team) Migration License : Destinée aux migrations de Microsoft Teams, avec une capacité de 100 Go de données par licence (pour une équipe).
  • MigrationWiz: Hybrid License : Adaptée aux environnements hybrides (mélange d’Exchange sur site et Exchange Online) avec des spécificités liées à l’authentification et aux agents migratoires.
  • Shared Document License : Pour migrer des référentiels de documents (SharePoint, Google Shared Drives), avec des tailles pouvant varier (50 Go ou 100 Go selon la licence).
  • Tenant Migration Bundle : Une solution groupée pour les migrations de tenants Microsoft 365, combinant une User Migration Bundle License et une Flex Collaboration License.

Chaque licence est donc affectée à un utilisateur ou à un élément particulier et est consommée au lancement d’une migration réussie, avec une restauration automatique en cas d’échec ou d’arrêt de la migration.

De plus, ces licences restent disponibles pendant 12 mois après leur achat et peuvent être acquises via le tableau de bord de MigrationWiz.

Combien coûte BitTitan MigrationWiz ?

Le coût de MigrationWiz varie alors selon le type de migration et la licence choisie.

Par exemple, pour une migration de boîtes aux lettres, le tarif est d’environ 12 $ par utilisateur, tandis que la licence User Migration Bundle (qui inclut boîte aux lettres, archives et documents) coûte environ 15 $ par utilisateur :

Pour les migrations de tenant à tenant, le Tenant Migration Bundle est proposé à environ 57 $ par utilisateur, avec des tarifs spécifiques pour d’autres charges (Teams, dossiers partagés, etc.) et des remises possibles pour les gros volumes ou pour les organismes à but non lucratif.

Qu’est-ce que MigrationWiz peut à migrer de tenant à tenant ?

Dans une migration de tenant à tenant, MigrationWiz transfère l’ensemble des données critiques d’un environnement Microsoft 365 :

  • Les boîtes aux lettres : emails, calendriers, contacts, tâches, notes, règles et archives.
  • Les données personnelles et collaboratives : documents et fichiers sur OneDrive, ainsi que le contenu SharePoint (sites, bibliothèques et permissions).
  • Les éléments collaboratifs d’équipes : données Microsoft Teams (équipes, canaux, conversations et fichiers)

Qu’est-ce que MigrationWiz n’arrive pas à migrer de tenant à tenant ?

MigrationWiz ne migre pas :

  • Les paramètres et configurations du tenant lui-même (politiques de sécurité, configurations d’Active Directory, licences, groupes, paramètres de domaine, etc.), qui doivent être recréés manuellement dans le nouveau tenant.
  • Certains éléments spécifiques ou personnalisés, tels que les signatures Outlook, les profils utilisateur et les listes d’auto-complétions, ainsi que certaines règles côté client non supportées par les API.

Ces limitations sont dues aux contraintes techniques des API utilisées et au fait que certains éléments relèvent de la configuration intrinsèque du tenant plutôt que du contenu utilisateur.

Est-ce que BitTitan peut nous aider sur la phase d’audit ?

MigrationWiz intègre une également phase de découverte qui permet d’évaluer l’état de l’environnement source. Cela inclut l’identification d’éventuels problèmes ou incompatibilités avant la migration. Ce processus permet de dresser un état des lieux qui peut être considéré comme un audit fonctionnel préalable :

Dois-je installer BitTitan MigrationWiz sur mon ordinateur ?

Non, MigrationWiz est une solution 100% cloud (SaaS) accessible via un navigateur web, il donc n’est pas nécessaire de l’installer sur votre ordinateur. Vous pouvez lancer et gérer vos projets de migration directement en ligne, depuis n’importe quel appareil connecté à Internet.

Quelles sont les formules de support pour MigrationWiz ?

Les licences MigrationWiz sont accompagnées d’un support technique dédié disponible 24h/24 et 7j/7 pour répondre aux questions et assister lors des migrations.

Pour des projets particulièrement complexes ou d’envergure (notamment pour les migrations de tenant à tenant), BitTitan propose également des formules d’assistance « aux entreprises » ou « premium » incluant des conseils d’experts, un accompagnement personnalisé et parfois une intégration plus poussée.

Dans cet article, je vous propose donc de tester la migration d’un tenant à un autre via l’application MigrationWiz de BitTitan :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de tester la migration de tenant à tenant, il vous faudra disposer de :

  • Une ou plusieurs licences BitTitan selon migrations souhaitées.
  • Un premier tenant de test, appelé tenant source, et contenant différentes données 365.
  • Un second tenant, appelé tenant de destination et ne contenant pas de données 365.

Commençons par créer notre accès à l’outil de BitTitan :

Etape I – Configuration de MigrationWiz:

Rendez-vous sur la page web suivante, puis cliquez-ici pour vous authentifier :

Si vous n’avez pas encore de compte chez BitTitan, cliquez-ici pour vous enregistrer pour la première fois :

Renseignez tous les champs, cochez la case suivante, puis cliquez-ici pour créer votre compte BitTitan :

Attendez quelques minutes la création du compte, puis vérifiez l’arrivée d’un e-mail de confirmation dans votre boite aux lettres :

Cliquez sur le lien présent dans l’e-mail reçu, puis configurez votre mot de passe :

Une fois la compte correctement configuré, la page web vous affiche le tableau de bord de l’outil MigrationWiz :

Avez-vous pouvoir utiliser l’outil MigrationWiz, il est nécessaire de provisionner des licences.

Je suis donc passé par le menu suivant pour renseigner les codes coupons de licences d’essai MigrationWiz :

Une fois les codes coupons de licence activés, les soldes des différentes licences sont visibles sur la partie droite du tableau de bord de MigrationWiz :

Les informations sur les licences MigrationWiz acquises sont aussi accessibles via la console principale de BitTitan :

Notre application SaaS est maintenant prête, nous allons pouvoir nous focaliser sur la configuration des 2 tenants Microsoft 365 :

  • tenant source
  • tenant de destination

Etape II – Préparation des 2 tenants :

Dans mon exemple de migration, 2 tenants Microsoft 365 ont été créés pour les tests de migration :

  • Un environnement Microsoft 365 avec des utilisateurs et des données fictives.
  • Un environnement Microsoft 365 vide d’utilisateurs et de données.
  • Un environnement Microsoft 365 avec des équipes Teams.
  • Un environnement Microsoft 365 vide d’équipes Teams.
  • Un environnement Microsoft 365 avec des sites SharePoint.
  • Un environnement Microsoft 365 vide de sites SharePoint.

BitTitan ne s’occupera pas de copier les utilisateurs présents dans le tenant de départ vers le tenant de destination. Pour cela, exportez la liste des utilisateurs du tenant source depuis le portail Entra :

Cliquez-ici pour déclencher le téléchargement du fichier au format CSV :

Le fichier CSV généré contient les informations sur les identités Cloud de vos utilisateurs :

Sur le tenant de destination, cliquez-ici pour préparer l’importation des utilisateurs :

Cliquez-ici pour télécharger le fichier d’exemple pour l’importation des utilisateurs :

Remplissez le fichier en reprenant les informations présentes dans le fichier d’extraction provenant de votre tenant source :

Enregistrez votre fichier au format CSV, chargez ce dernier sur le portail Azure du tenant de destination, puis cliquez-ici pour démarrer la création des utilisateurs :

Attendez quelques secondes la fin de l’importation :

Sur le tenant de destination, rafraîchissez la page afin de voir les utilisateurs sur votre tenant de destination :

Afin de configurer plus facilement les différents projets de migration MigrationWiz, créez un utilisateur dédié à BitTitan dans chacun des 2 tenants, et ayant comme rôle Global Reader :

Rajoutez-leur des licences Microsoft 365 :

Créez également un groupe de sécurité, appelé MigrationWiz, dans chacun des 2 tenants avec pour membre les utilisateurs précédemment créés :

Désactivez la MFA pour ces 2 utilisateurs via des polices d’accès conditionnels :

Notre tenant de destination est maintenant prêt pour migrer les données du tenant source. Commençons par celles présentes dans les boîtes aux lettres.

Etape III – Copie de données Exchange :

MigrationWiz assure migration du courrier électronique depuis les principaux environnements, comme Exchange, Microsoft 365, Lotus Notes et Google/G Suite.

Voici une vidéo détaillant tout le processus de migration des boîtes aux lettres Microsoft 365 avec MigrationWiz et proposée par The Cloud Geezer :

Avant de démarrer la migration via MigrationWiz, assignez des licences Microsoft 365 aux utilisateurs présents dans le tenant de destination afin de lancer la création de leurs boîtes aux lettres :

Retournez sur la page web de l’application MigrationWiz, puis cliquez-ici pour créer un projet de migration :

Choisissez le projet de migration concernant les boites aux lettres :

Définissez un nom de projet, puis cliquez sur Suivant :

Ajoutez les informations demandées pour votre tenant Source, puis cliquez sur Sauvegarder :

Cliquez sur Suivant :

Cliquez-ici pour créer un nouveau point de terminaison à notre tenant Source :

Renseignez le compte Microsoft 365 de notre utilisateur MigrationWiz présent dans notre tenant Source, puis cliquez sur Sauvegarder :

Retournez sur la page suivante du portail Entra de votre tenant source, puis cliquez-ici pour créer un nouvel enregistrement d’application :

Nommez votre application, puis cliquer sur Enregistrer :

Dans l’onglet de l’Authentification, activez l’option suivante, puis cliquez sur Sauvegarder :

Dans l’onglet des permissions API, cliquez-ici pour ajouter des permissions supplémentaires :

Cliquez sur le menu des permissions suivant :

Recherchez la permission suivante, puis cliquez sur Ajouter les permissions :

Retournez dans le menu des permissions une seconde fois, recherchez la permission suivante, puis cliquez sur Ajouter les permissions :

Cliquez sur le bouton ci-dessous afin de mettre en place le consentement de l’administrateur global :

Confirmez votre action en cliquant sur Oui :

Ajoutez un secret via le menu suivant :

Copiez la valeur du secret :

Copiez également l’ID de votre application, ainsi que l’ID de votre tenant :

Collez toutes ces informations sur l’écran de configuration MigrationWiz pour votre tenant source, puis cliquez sur Suivant :

Créez la même inscription d’application, avec les mêmes options et permissions API, sur le tenant de destination :

Ajoutez-lui également un secret :

Collez toutes ces informations sur l’écran de configuration MigrationWiz pour votre tenant de destination, puis cliquez sur Suivant :

Cliquez sur Sauvegarder :

Cliquez à nouveau sur Sauvegarder :

Utilisez la fonction d’auto-découverte pour laisser MigrationWiz rechercher par lui-même les boites aux lettres présentes dans le tenant source :

Cliquez-ici pour démarrer la fonction auto-découverte :

Attendez quelques secondes le déclenchement de cette dernière, l’affichage des résultats obtenus, puis cliquez-ici pour importer les résultats :

Rafraîchissez la page au besoin pour voir apparaître l’importation des résultats de l’auto-découverte :

Cliquez sur le bouton suivant afin de faire correspondre le nom de domaine des boîtes aux lettres créées dans le tenant de destination :

Commencez par la première étape, appelée vérifier les informations d’identification, afin de valider le bon accès aux ressources par MigrationWiz sur les 2 tenants :

Confirmez votre action en cliquant sur OK :

Attendez environ 10 minutes la vérification des accès de MigrationWiz :

Avant d’assigner une licence MigrationWiz à un utilisateur du tenant source, cliquez-ici pour tester la migration, via la fonction essai de migration :

Constatez l’absence de consommation d’une licence MigrationWiz pour cette essai de migration, puis cliquez sur Démarrer la migration :

Confirmez votre action en cliquant sur Démarrer :

Attendez environ 10 minutes le succès de votre essai de migration, puis cliquez sur la boite aux lettres du tenant source pour avoir plus de détail sur cette étape :

Constatez les détails et les différents indicateurs remontés par MigrationWiz :

Sur les 2 tenants, ouvrez la boite aux lettres de votre utilisateur de test afin de constater l’apparition partielle de certains e-mails :

Naviguez dans le dossier des brouillons :

Naviguez dans le dossier des éléments envoyés :

Naviguez dans le dossier des archives :

Naviguez dans un dossier personnel :

Constatez la migration des évènements présents sur le calendrier de l’utilisateur :

Constatez la migration des contacts présents dans les contacts de l’utilisateur :

Constatez la migration des règles de messagerie de l’utilisateur :

Constatez l’absence de migration des e-mails présents dans la boite aux lettres archive :

Une fois les vérifications terminées, cliquez-ici pour assigner une licence User Migration Bundle à votre utilisateur afin d’effectuer l’étape suivante, appelée migration préalable :

Vérifiez les calculs d’assignation ainsi que le nombre de licences restantes, puis cliquez sur Appliquer :

L’utilisateur est prêt pour la migration préalable et doit avoir le statut suivant à Oui :

Il est possible d’effectuer une première passe de migration, via la fonction migration préalable, afin d’alléger le reste de données à migrer le jour J :

Cette migration préalable nécessite elle-aussi l’utilisation des licences utilisateurs comme l’indique l’écran suivant, puis cliquez sur Démarrer :

La consommation des licences par MigrationWiz est aussi visible via la console principale de BitTitan :

Un détail de l’affectation par utilisateur est disponible sur l’onglet suivant :

Attendez environ 10 minutes le succès de votre migration préalable, puis cliquez sur la boite aux lettres du tenant source pour avoir plus de détail :

Constatez les détails et les différents indicateurs remontés par MigrationWiz :

Nous pouvons terminer nos essais de migration d’une boîtes aux lettres par la fonction de migration complète :

Cette migration complète utilise la même licence que celle utilisée par l’étape de migration préalable et assignée à notre utilisateur de test, cliquez sur Démarrer :

Attendez environ 10 minutes le succès de votre migration complète, puis cliquez sur la boite aux lettres du tenant source pour avoir plus de détail :

Constatez le volume de données transférées :

Constatez les différentes étapes effectuées, ainsi que les moyennes de transfert :

Sur les 2 tenants, réouvrez la boite aux lettres de votre utilisateur de test afin de constater l’apparition de tous ses e-mails :

Notre premier essai concernant la copie de boites aux lettres d’un tenant 365 à autre s’est avéré concluant.

Concernant la migration complète d’une messagerie, d’autres actions concernant la bascule du nom de domaine personnalisé, le changement des noms d’utilisateurs, les modifications d’enregistrements DNS etc… sont toujours à prévoir.

Continuons avec la migration de données Microsoft Teams.

Etape IV – Copie de données Teams :

Migrer une environnement Teams d’un tenant Microsoft 365 doit permettre de retrouver toutes les équipes Teams, tous leurs canaux, tous les fichiers ainsi que toutes les autorisations.

Voici une vidéo détaillant tout le processus de migration de Microsoft avec MigrationWiz et proposée par The Cloud Geezer :

Retournez sur la page web de l’application MigrationWiz, puis cliquez-ici pour créer un second projet de migration :

Choisissez le projet de migration concernant Microsoft Teams :

Définissez un nom de projet, choisissez le nom du tenant source présent dans la liste, puis cliquez sur Suivant :

Cliquez-ici pour créer un nouveau point de terminaison à notre tenant Source :

Avant de commencer à renseigner les champs, cliquez sur le lien suivant pour accéder à la documentation BitTitan (disponible ici) :

Pour le tenant source, choisissez parmi les 2 approches de permissions possibles :

Pour ma part, je suis parti sur le second choix :

Assurez-vous d’être connecté en tant qu’administrateur global du tenant source :

Consentez à l’accès à l’application :

Depuis le portail Entra, constatez la création de l’application avec les droits consentis :

De retour sur votre projet MigrationWiz, renseignez le compte Microsoft 365 de notre utilisateur de migration de notre tenant Source, puis cliquez sur Ajouter :

Cliquez sur Suivant :

Cliquez-ici pour créer un nouveau point de terminaison à notre tenant de destination :

Avant de commencer à renseigner les champs, cliquez sur le lien suivant pour accéder à la documentation BitTitan (disponible ici) :

Pour le tenant de destination, une seule approche est possible :

Assurez-vous d’être connecté en tant qu’administrateur global du tenant de destination :

Consentez à l’accès à l’application :

Depuis le portail Entra, constatez la création de l’application et les droits consentis :

Renseignez le compte Microsoft 365 de notre utilisateur de migration de notre tenant de destination, et si besoin un compte de stockage Azure personnalisé, puis cliquez sur Ajouter :

Cliquez sur Sauvegarder :

Cliquez à nouveau sur Sauvegarder :

Utilisez la fonction d’auto-découverte pour laisser MigrationWiz rechercher par lui-même les équipes Teams :

Cliquez-ici pour démarrer la fonction auto-découverte :

Attendez quelques secondes le déclenchement de cette dernière, l’affichage des résultats obtenus, puis cliquez-ici pour importer les résultats :

Commencez par la première étape, appelée vérifier les informations d’identification, afin de valider le bon accès de MigrationWiz de la ou les équipes Teams à migrer sur les 2 tenants :

Confirmez votre action en cliquant sur OK :

Attendez environ 10 minutes la vérification des accès de MigrationWiz :

Nous pouvons terminer notre test de migration Teams par la fonction migration complète :

Cette migration complète utilise la licence appelée MigrationWiz-Collaboration (per Team), conservez l’option sur Mise en place des équipes, puis cliquez sur Démarrer :

Attendez environ 10 minutes le succès de votre migration complète :

Retournez une seconde fois sur la fonction de migration complète :

Choisissez cette fois de migrer les données Teams, puis cliquez sur Démarrer :

Attendez environ 10 minutes le succès de votre migration complète, puis cliquez sur une équipe Teams du tenant source pour avoir plus de détail :

Cliquez au besoin pour voir les erreurs ou les manques liés à cette migration de données Teams :

Un détail des erreurs est également disponible :

Ayant utilisé un compte de stockage Azure personnalisé, des conteneurs objets ont bien été créés pour le transfert :

On voit au travers des métriques les pics de transferts entrants et sortants :

Grâce à votre utilisateur de test, connectez-vous à Microsoft Teams pour effectuer des comparaisons entre le tenant source et celui de destination :

Vérifiez les données présentes dans différents canaux d’équipes :

Vérifiez les données présentes dans différents onglets de canaux d’équipes :

Un onglet appelé historique de la conversation est également présent sur le tenant de destination :

Ce lien ouvre un fichier au format HTML présent sur le site SharePoint de l’équipe Teams. Il retrace de façon plus présentable les échanges de conversation Teams du canal concerné :

Vérifiez les tâches présentes sur votre utilisateur de test :

Ouvrez un site SharePoint sur les 2 tenants afin de constater la présence du site et de ses fichiers :

Continuons nos tests avec la copie de sites SharePoint.

Etape V – Copie de données SharePoint :

Cette étape concernant la migration des documents pour des environnements courants tels que SharePoint, SharePoint Online, OneDrive for Business et Google Drive. Il est également possible de migrer des pages de sites de Google Sites vers site Microsoft SharePoint.

Voici une vidéo détaillant tout le processus de migration des sites SharePoint Online avec MigrationWiz et proposée par The Cloud Geezer :

Choisissez le projet de migration concernant SharePoint :

Définissez un nom de projet, choisissez le nom du tenant source présent dans la liste, puis cliquez sur Suivant :

Cliquez-ici pour créer un nouveau point de terminaison à notre tenant Source :

Avant de commencer à renseigner les champs, cliquez sur le lien suivant pour accéder à la documentation BitTitan (disponible ici) :

Pour le tenant source, choisissez parmi les 2 approches de permissions possibles :

Pour ma part, je suis parti sur le second choix :

Assurez-vous d’être connecté en tant qu’administrateur global du tenant source :

Consentez à l’accès à l’application :

Depuis le portail Entra, constatez la création de l’application et des droits consentis :

De retour sur votre projet MigrationWiz, renseignez le compte Microsoft 365 de notre utilisateur de migration de notre tenant Source, puis cliquez sur Ajouter :

Cliquez sur Suivant :

Cliquez-ici pour créer un nouveau point de terminaison à notre tenant de destination :

Avant de commencer à renseigner les champs, cliquez sur le lien suivant pour accéder à la documentation BitTitan (disponible ici) :

Pour le tenant de destination, choisissez parmi les 2 approches de permissions possibles :

Pour ma part, je suis encore parti sur le second choix :

Assurez-vous d’être connecté en tant qu’administrateur global du tenant de destination :

Consentez à l’accès à l’application :

Renseignez le compte Microsoft 365 de notre utilisateur de migration de notre tenant de destination et si besoin un compte de stockage Azure personnalisé, puis cliquez sur Ajouter :

Cliquez sur Sauvegarder :

Cliquez à nouveau sur Sauvegarder :

Petite anecdote : ayant fait des erreurs de configuration dans ma migration SharePoint, j’ai ouvert un ticket de support via le lien suivant :

  • Le délai entre l’ouverture du ticket et la première réponse technique de la part du support fut inférieur à 3 heures.
  • les échanges suivants ont été adressés en moins d’une heure à chaque fois.

De retour à notre migration, cliquez sur Options avancées :

Renseignez les options suivantes via la fonction d’import multiple, validez les options, puis Sauvegardez :

TestSharePointWithProjectConfigUrl=1
InitializationTimeout=48.
DestMetadataReadTimeoutInHrs=48
LargeFileMigrations=1
LargeFileMigrationsTimeout=7200000
UseApplicationPermission=1

Utilisez la fonction d’auto-découverte pour laisser MigrationWiz rechercher par lui-même les sites SharePoint :

Cliquez-ici pour démarrer la fonction auto-découverte :

Attendez quelques secondes le déclenchement de cette dernière, l’affichage des résultats obtenus, puis cliquez ici pour importer les résultats :

Commencez par la première étape, appelée vérifier les informations d’identification, afin de valider le bon accès de MigrationWiz pour la ou les bibliothèques des sites SharePoint à migrer sur les 2 tenants :

Attendez environ 10 minutes la vérification des accès de MigrationWiz :

Une fois cette étape confirmée, nous pouvons terminer notre test de migration SharePoint par la fonction de migration complète :

Cette migration complète utilisera les licences appelées MigrationWiz-Shared Document 100GB, conservez l’option sur Mise en place de SharePoint, puis cliquez sur Démarrer :

Attendez environ 10 minutes le succès de votre migration complète :

Rendez-vous dans la console d’administration de SharePoint afin de constater la création des 2 sites dans cette première phase de MigrationWiz :

Retournez encore une fois sur MigrationWiz afin de lancer la seconde partie de la fonction de la migration complète :

Choisissez cette fois de migrer toutes les données SharePoint, puis cliquez sur Démarrer :

Attendez le temps qu’il faut pour que votre migration soit complète, puis cliquez sur une ligne de la liste SharePoint afin d’avoir plus de détail sur les erreurs ou manques liés à cette copie de données SharePoint :

Un détail des erreurs est également disponible :

Une option de rattrapage des erreurs est même disponible :

Cette seconde a bien permis de migrer les autres données :

Je n’ai pas testé et parlé de la migration des sites OneDrive, mais des vidéos détaillées sont déjà disponibles sur internet :

Continuons avec la migrations du contenus des boîtes aux lettres archives.

Etape VI – Copie de données archives Exchange :

Cette étape permet de migrer les fichiers d’archives personnelles, les boîtes aux lettres d’archives ou les fichiers PST d’un serveur de fichiers ou d’un compte d’utilisateur vers la destination. Cette action est généralement réalisée en conjugaison avec les migrations de boîtes aux lettres.

Assurez-vous que la fonction de boîtes aux lettres d’archive est activée pour votre utilisateur de test sur les 2 tenants :

Connectez-vous à votre utilisateur de test afin de créer une arborescence de dossiers et d’e-mails dans sa boîtes aux lettres archive :

Retournez sur la page web de l’application MigrationWiz, puis cliquez-ici pour créer un projet de migration :

Choisissez le projet de migration concernant les boites aux lettres archives :

Définissez un nom de projet, puis cliquez sur Suivant :

Copiez les informations liées à votre inscription d’application du tenant source utilisée durant la migration des boîtes aux lettres classiques :

Collez toutes ces informations sur l’écran de configuration MigrationWiz pour votre tenant source, puis cliquez sur Suivant :

Copiez les informations liées à votre inscription d’application du tenant de destination utilisée durant la migration des boîtes aux lettres classiques :

Collez toutes ces informations sur l’écran de configuration MigrationWiz pour votre tenant de destination, puis cliquez sur Suivant :

Cliquez sur Sauvegarder :

Utilisez la fonction suivante pour laisser MigrationWiz reprendre les boîtes aux lettres précédemment découvertes :

Sélectionnez dans la liste la ou les boîtes aux lettres ayant une boîte aux lettres archive à migrer, puis cliquez sur Sauvegarder :

Cliquez sur le bouton des options avancées :

Vérifiez bien que les boîtes aux lettres de source et de destination sont bien de type archive, Vérifiez, puis Sauvegardez les paramètres avancés :

Cliquez sur le bouton suivant afin de faire correspondre le nom de domaine des boîtes aux lettres déjà créées dans le tenant de destination, puis cliquez sur Sauvegarder :

Commencez par la première étape, appelée vérifier les informations d’identification, afin de valider le bon accès de MigrationWiz aux boîtes aux lettres sur les 2 tenants :

Confirmez votre action en cliquant sur OK :

Attendez environ 10 minutes la vérification des accès de MigrationWiz :

Cliquez-ici pour effectuer la migration complète des boîtes aux lettres archives :

Démarrez la migration :

Attendez environ 10 minutes le succès de votre migration complète, puis cliquez sur une boîte aux lettres du tenant source pour avoir plus de détail :

Sur les 2 tenants, réouvrez les boîtes aux lettres de votre utilisateur de test afin de constater l’apparition de tous les e-mails dans la boîte aux lettres archive :

Terminons nos tests par la copie des messages privés Teams d’un tenant Microsoft 365 à un autre.

Etape VII – Copie de messages privés Teams :

Cette étape assure la migration des chats privés pour les utilisateurs de Teams d’un tenant Microsoft 365 à un autre. Ce projet migre les chats 1:1, les chats de groupe et les chats de réunion en tant que chats de groupe à destination et les hydrate pour permettre aux utilisateurs de continuer à collaborer.

Voici une vidéo détaillant tout le processus de migration des messages privées Teams avec MigrationWiz et proposée par The Cloud Geezer :

Retournez sur la page web de l’application MigrationWiz, puis cliquez-ici pour créer un nouveau projet de migration :

Choisissez le projet de migration concernant les messages privées Microsoft Teams :

Définissez un nom de projet, choisissez le nom du tenant source présent dans la liste, puis cliquez sur Suivant :

Cliquez-ici pour créer un nouveau point de terminaison à notre tenant Source :

Avant de commencer à renseigner les champs, cliquez sur le lien suivant pour accéder à la documentation BitTitan (disponible ici) :

Pour le tenant source, une seule option de permissions est possible :

Assurez-vous d’être connecté en tant qu’administrateur global du tenant source :

Consentez à l’accès à l’application :

Renseignez les identifiants, puis lancez le traitement de vérification des accès Microsoft 365 du tenant source :

Attendez l’apparition de la notification MigrationWiz suivante :

Nommez votre point de terminaison source, puis cliquez sur Ajouter :

Depuis le portail Entra, constatez la création de l’application et des droits consentis :

De retour sur votre projet MigrationWiz, cliquez sur Suivant :

Cliquez-ici pour créer un nouveau point de terminaison à votre tenant de destination :

Avant de commencer à renseigner les champs, cliquez sur le lien suivant pour accéder à la documentation BitTitan (disponible ici) :

Pour le tenant de destination, une seule option de permissions est possible :

Assurez-vous d’être connecté en tant qu’administrateur global du tenant de destination :

Consentez à l’accès à l’application :

Renseignez les identifiants, puis lancez le traitement de vérification des accès Microsoft 365 du tenant de destination :

Attendez l’apparition de la notification MigrationWiz suivante :

Nommez votre point de terminaison de destination, puis cliquez sur Ajouter :

Depuis le portail Entra, constatez la création de l’application et des droits consentis :

De retour sur votre projet MigrationWiz, cliquez sur Sauvegarder :

Utilisez la fonction d’auto-découverte pour laisser MigrationWiz rechercher par lui-même les messages privés Teams :

Cliquez-ici pour démarrer la fonction auto-découverte :

Attendez quelques secondes le déclenchement de cette dernière, l’affichage des résultats obtenus, puis cliquez ici pour importer les résultats :

Commencez par la première étape, appelée vérifier les informations d’identification, afin de valider le bon accès de MigrationWiz aux messages privés Teams à migrer sur les 2 tenants :

Confirmez votre action en cliquant sur OK :

Attendez environ 10 minutes la vérification des accès de MigrationWiz, puis lancez la fonction migration complète :

Cochez la case suivante, puis cliquez sur Démarrer :

Attendez environ 10 minutes le succès de votre migration complète :

Connectez-vous à Microsoft Teams avec votre utilisateur de test, puis effectuez des comparaisons entre le tenant source et celui de destination sur des chats de réunion Teams :

Effectuez des comparaisons entre le tenant source et celui de destination sur des chats 1:1 :

Conclusion

En résumé, mon test de MigrationWiz a été une expérience globalement très positive. L’outil se distingue par sa puissance et sa complétude, facilitant une migration tenant-à-tenant de bout en bout pour Microsoft 365.

La documentation, bien que parfois trop dense et entachée de quelques liens inopérants, offre néanmoins un accompagnement détaillé qui aide à démarrer et à suivre le processus de migration.

Malgré la latence inhérente aux solutions SaaS, l’efficacité et la réactivité du support technique viennent renforcer l’expérience utilisateur.

Je vous encourage vivement à réaliser vos propres tests afin de constater par vous-même la robustesse et les capacités de MigrationWiz.

Windows 365 Move v2

Microsoft continue de faire évoluer Windows 365 en y apportant la possibilité de pouvoir déplacer vos Cloud PCs encore plus facilement d’une région Azure à une autre en seulement 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 vos ressources pour vous !

Plusieurs articles ont déjà été écrits sur ce blog à propos de Windows 365 depuis sa sortie en 2021, dont un premier article parlait déjà de cette fonctionnalité de migration :

Qu’est-ce qui a changé par rapport à la première version ?

Dans la version initiale de Windows 365, le déplacement des Cloud PC se faisait de manière globale via la police de provisionnement, impactant ainsi l’ensemble des machines associées à cette même politique.

Avec la version 2, Microsoft a apporté une évolution majeure en permettant une sélection ciblée des machines à migrer. Désormais, les administrateurs peuvent opérer des modifications ou des déplacements sur des Cloud PC spécifiques sans affecter l’ensemble du parc lié à une seule politique, offrant ainsi une plus grande flexibilité et un contrôle opérationnel optimisé.

Cette amélioration facilite la gestion des environnements et permet d’adapter les déploiements aux besoins précis de l’organisation tout en minimisant les risques d’erreurs ou de perturbations sur le système global.

Pour rappel, 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 monde.

Cela permet à Microsoft de proposer Windows 365 dans de nombreuses régions Azure. Windows 365 est donc à ce jour disponible dans la liste de centres données suivante, et celle-ci continuera de s’agrandir au fil du temps :

  • Asie
    • Asie Est
    • Asie Sud-Est
  • Australie
    • Australie Est
  • Canada
    • Canada Centre
  • Union européenne
    • Europe Nord
    • Europe Ouest
    • Italie Nord
    • Pologne Centre
    • Suède Centre
  • France
    • France Centre
  • Allemagne
    • Centre Ouest de l’Allemagne
  • Inde
    • Centre de l’Inde
  • Japon
    • Japon Est
    • Japon Ouest
  • Moyen-Orient
    • Israël Centre
  • Norvège
    • Norvège Est
  • Afrique du Sud
    • Nord de l’Afrique du Sud
  • Amérique du Sud
    • Brésil Sud (restreint)
  • Corée du Sud
    • Corée du Sud
  • Suisse
    • Suisse Nord
  • Émirats arabes unis
    • UAE Nord
  • Royaume-Uni
    • Sud du Royaume-Uni
  • USA Centre
    • USA Centre
    • USA Centre Sud
  • USA Est
    • USA Est
    • USA Est 2
  • USA Ouest
    • USA Ouest 2 (restreint)
    • USA Ouest 3

Pourquoi migrer son Cloud PC ?

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

  1. Réduction de la latence : En plaçant les ressources plus près des utilisateurs finaux, on peut améliorer les performances et réduire le temps de réponse, ce qui est crucial pour des applications interactives.
  2. Conformité et souveraineté des données : Certaines réglementations imposent que les données restent dans une zone géographique spécifique. Migrer vers une région appropriée permet de respecter ces exigences légales et normatives.
  3. Résilience et reprise après sinistre : En répartissant les ressources sur plusieurs régions, on renforce la tolérance aux pannes et la continuité des services en cas de défaillance régionale ou de catastrophe.
  4. Optimisation des coûts : Les tarifs et la disponibilité des services peuvent varier d’une région à l’autre. Une migration peut permettre de bénéficier d’une structure tarifaire plus avantageuse ou de capacités plus adaptées à la demande.
  5. Amélioration des performances locales : Certaines régions peuvent offrir des services ou des infrastructures plus récents, permettant d’accéder à des fonctionnalités optimisées ou à une meilleure capacité de traitement.

Ces points illustrent que même si l’accès aux services Cloud se fait principalement via une connexion sécurisée transitant via Internet, la localisation géographique des ressources peut avoir un impact significatif sur la qualité de service, la conformité, la résilience et les coûts globaux.

Avant et après la migration, il est recommandé de suivre certains indicateurs clés comme la latence, le temps de réponse et le débit. Des outils de monitoring tels qu’Azure Monitor ou des solutions tierces peuvent être utilisés pour comparer les performances et valider l’amélioration de l’expérience utilisateur. Cela permet également de détecter rapidement d’éventuels problèmes de connectivité ou de performance dans la nouvelle région.

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

Microsoft met en œuvre des mécanismes de sécurité robustes pendant le processus de migration. Les Cloud PCs sont sauvegardés et les données sont protégées par des protocoles de chiffrement avancés. De plus, l’intégrité des sauvegardes est vérifiée avant le déplacement, garantissant ainsi que les données restent sécurisées et intactes tout au long du processus.

Donc non, Microsoft est 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 temps que la nouvelle machine soit reprovisionnée dans la nouvelle région Azure :

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

Cela obligera à anticiper le déplacement des Cloud PCs durant des périodes creuses afin de ne pas perturber ou diminuer l’expérience utilisateur.

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une licence Windows 365 valide

Etape I – Test avant migration :

Avant de lancer le processus de déplacement d’un Cloud PC, cliquez sur le lien suivant, authentifiez-vous avec un utilisateur de test :

Lancez une session Cloud PC, puis attendez quelques secondes que la sessions Windows s’ouvre :

Ouvrez l’adresse web suivante afin de constater votre adresse IP publique actuelle ainsi qu’une estimation de votre localisation géographique :

Le Cloud PC est actuellement provisionné en Suisse :

Créez un fichier sur le disque local de votre Cloud PC afin de constater sa future réplication :

Le Cloud PC est maintenant prêt à être migré vers une autre région Azure.

Etape II – Migration :

Toujours depuis le portail Intune, retournez dans la liste des polices de provisionnement Windows 365, puis cliquez sur celle-ci pour la modifier :

Comme la copie d’écran ci-dessous le montre, notre police point actuellement l’hébergement des Cloud PCs en Suisse :

Afin de migrer le Cloud PC vers un centre de données Azure situé au Canada, cliquez-ici pour modifier la police de provisionnement :

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

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

La notification Intune suivante apparaît alors :

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

Une nouvelle option apparaît alors, elle vous laisse le choix sur les actions à entreprendre sur les Cloud PC déjà provisionnés.

Choisissez le dernier choix de la liste, puis cliquez sur Appliquer :

Sélectionnez le Cloud PC souhaité, puis cliquez sur Sélectionner :

Confirmez votre action de migration en cliquant sur Continuer :

La notification Intune suivante apparaît alors, cliquez sur le lien vers le rapport des migrations :

Ce rapport est aussi disponible via le menu suivant :

Une nouvelle ligne de migration apparaît alors dans la liste avec un statut en attente :

L’ordre de migration est maintenant pris en compte par Azure. Le Cloud PC concerné voit lui aussi son statut changer :

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

Une tentative de reconnexion de notre utilisateur de test affichera le message d’erreur suivant :

Et environ 2 heures, le Cloud PC retrouve son précédent statut :

Dans le rapport des migrations Windows 365, l’action de migration est maintenant terminé :

La migration est maintenant terminée, nous allons pouvoir maintenant contrôler la présence de notre fichier stocké sur le disque local de notre Cloud PC.

Etape III – Test après migration :

Rouvrez une session de bureau à distance Windows 365 pour votre utilisateur de test.

Cette fois-ci, la page de IPlocation indique bien une nouvelle adresse IP et un nouveau positionnement estimé au Canada :

Pour les autres Clouds PC non migrés restants, la bascule de région est toujours possible en appliquant à nouveau la police de configuration :

Enfin, j’ai effectué un mouvement de retour pour mon Cloud PC parti au Canada, qui n’a lui non plus posé de souci.

J’ai également effectué un changement de réseau afin de le remettre sur ma connexion Azure créée spécialement pour mes Cloud PCs :

Cette reconnexion à Azure sans déplacement de région a lui été beaucoup rapide :

A la suite de ces différentes opérations, j’ai toujours retrouvé mon Cloud PC et mes données sauvegardées localement :

Conclusion

La migration des Cloud PCs avec Windows 365 Move v2 offre une meilleure flexibilité, permettant d’adapter le déploiement de vos environnements à vos besoins spécifiques, sans impacter l’ensemble du parc. En adoptant une approche progressive – grâce aux tests préliminaires, à une planification minutieuse et à l’application de meilleures pratiques – vous minimisez les interruptions et assurez une transition en douceur.

Les améliorations en matière de sécurité, de performance et d’optimisation des coûts font de cette solution un levier stratégique pour les entreprises souhaitant renforcer leur agilité tout en répondant aux exigences de conformité et de résilience. Les retours d’expérience démontrent que, grâce à une migration bien orchestrée, il est possible de réduire significativement la latence et d’améliorer l’expérience utilisateur, tout en maîtrisant les coûts.

Migrez vos données 365 avec ShareGate !

Comme beaucoup d’entre vous, je suis régulièrement amené à discuter migration pour Microsoft 365. Et même que, de temps à autre, il s’agit de migrations de données depuis un tenant Microsoft vers un autre. Ayant justement l’opportunité de tester ShareGate Migrate grâce au programme Microsoft MVP, je souhaitais vous en faire partager via un article en mode découverte sur plusieurs de ses fonctionnalités.

Qu’est-ce que ShareGate ?

ShareGate est un outil de gestion et de migration pour SharePoint et Microsoft 365 (y compris OneDrive for Business et Teams). Il est principalement utilisé pour :

  • Migrer des sites, bibliothèques, documents et permissions entre différentes versions de SharePoint (On-Premise vers Online, entre tenants, etc…)
  • Gérer et administrer SharePoint en facilitant l’audit, l’organisation et la gouvernance des contenus et permissions.
  • Simplifier la gestion des espaces collaboratifs (Teams, SharePoint, OneDrive) en automatisant certaines tâches d’administration et en assurant la conformité des espaces.

ChatGPT

Vers où ShareGate peut migrer les données ?

Comme le montre l’image ci-dessous, ShareGate est capable de traiter de nombreux scénarios de migration de données :

Dans cet article, nous réaliserons des tests de fonctionnalité dans le cadre d’une migration de données depuis un tenant 365 vers un autre.

Combien coûte ShareGate ?

ShareGate propose plusieurs plans tarifaires adaptés aux besoins des entreprises en matière de migration et de gestion de Microsoft 365 :

  • Migrate Essentials : 1 activation de machine pour des migrations essentielles, à partir de 5 995 $ par an.
  • Migrate Pro : 5 activations de machine pour des migrations accélérées, incluant des formations pour les utilisateurs finaux et la migration des boîtes aux lettres, à partir de 9 995 $ par an.
  • Migrate Enterprise : 25 activations de machine pour des projets de migration à grande échelle, avec les mêmes avantages que le plan Pro, à partir de 17 995 $ par an.

Une version d’essai de 15 jours est même disponible sur leur site internet :

ShareGate a également mis à disposition beaucoup de contenus pour vous aider dans vos différents projets de migration :

Enfin, quand on recherche du contenu parlant de la migration entre tenants :

Est-ce qu’il existe des limitations / restrictions à la migration ?

Oui, malgré sa puissance, ShareGate Migration a certaines limitations à prendre en compte lors de la migration de sites SharePoint, OneDrive, et Microsoft Teams. Voici les principales :

CatégorieLimitation
Boîtes mail– Vitesse maximale de migration : 1,5 Go/heure par boîte.
– Types de boîtes pris en charge : utilisateur et partagé.
– Boîtes aux lettres d’archive, chiffrées, invitées ou externes non prises en charge.
– Permissions des dossiers, dossiers partagés/publics/archivés non préservés.
– Politiques de rétention des e-mails non conservées.
– Composants Loop, pièces jointes de référence, en-têtes de messages non pris en charge.
– Événements de calendrier uniques passés non migrés.
– Listes de contacts, catégories de contacts, statuts favoris non copiés.
– Règles de flux de messagerie non prises en charge.
– Paramètres de boîte aux lettres, comme le fuseau horaire, partiellement pris en charge.
Teams– Les équipes avec confidentialité « Organisation » deviennent « Publique » à la destination.
– Seul le modèle d’équipe standard est pris en charge.
– Image de l’équipe, paramètres spécifiques, balises personnalisées non migrés.
– Demandes en attente pour les équipes privées non migrées.
– Canaux supprimés, webhooks entrants/sortants, applications personnalisées non migrés.
– Équipes et canaux archivés migrés comme non archivés.
– Images copiées/collées non visibles à la destination.
– OneNote par défaut recréé lors du renommage de l’équipe à la destination.
OneDrive– Noms contenant des codes Alt non pris en charge.
– Noms d’équipe avec une barre oblique (/) créent des dossiers imbriqués.
– Certains caractères spéciaux dans les noms de fichiers remplacés par un underscore (_).
SharePoint– Les personnalisations, telles que les solutions tierces et les fonctionnalités personnalisées, peuvent ne pas être entièrement prises en charge.
– Les éléments liés à l’apparence, comme les mises en page de page et les pages maîtres, ne sont pas migrés.
– Les sites en lecture seule ne peuvent pas être migrés correctement et doivent être déverrouillés avant la migration.
Planner– Le fond d’écran, les paramètres de notification et les plans favoris des utilisateurs ne sont pas préservés.
– Les e-mails d’affectation de tâches et de commentaires sont envoyés par défaut et ne peuvent pas être désactivés.
– Les auteurs des tâches, des commentaires et les horodatages ne sont préservés que dans les commentaires.
– Les restrictions de Planner s’appliquent, par exemple : maximum de 200 plans par équipe et environ 2 400 tâches par plan.

Dans cet article, je vous propose donc de tester la migration d’un tenant à un autre via l’application ShareGate Migration :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de tester la migration de tenant à tenant, il vous faudra disposer de :

  • Une licence ShareGate
  • Un premier tenant de test, appelé tenant de départ et contenant des données 365
  • Un second tenant de test, appelé tenant de destination et ne contenant pas ou peu de données 365

Commençons par configurer l’application ShareGate Migration sur un poste local.

Etape I – Configuration de ShareGate :

Afin de profiter des services de ShareGate pour migrer des données, nous allons devoir créer un compte chez eux et installer l’application ShareGate Migrate sur le poste local.

Pour enregistrer le produit, connectez-vous sur la page d’authentification de ShareGate, et si vous ne disposez pas encore de compte, cliquez sur ce bouton pour en créer un :

Une fois votre compte validé et connecté, votre tableau de bord de ShareGate se présente de la façon suivante :

Les souscriptions ShareGate sont visibles sur cette page :

Plusieurs ressources de formation sont également disponibles via ce lien :

Comme précédemment, de nombreuses documentations y sont disponibles :

Cliquez-ici pour télécharger le client local ShareGate Migrate :

Une fois l’installeur téléchargé sur votre poste, ouvrez-le, puis cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Terminer :

Ouvrez l’application ShareGate Migrate :

Authentifiez-vous avec le compte disposant de la licence ShareGate :

L’application locale s’ouvre alors avec différents menus :

L’activation de notre licence sur notre poste local est bien affichée sur la console web de ShareGate :

Notre poste local est maintenant configuré. Nous allons pouvoir nous focaliser sur les 2 tenants Microsoft 365 : départ et destination.

Etape II – Préparation des 2 tenants :

Dans mon exemple de migration, 2 tenants Microsoft 365 sont créés pour les tests de migration :

  • Un environnement Microsoft 365 avec des utilisateurs ayant des données fictives
  • Un environnement Microsoft 365 vide d’utilisateurs
  • Un environnement Microsoft 365 avec des équipes Teams ayant des données fictives
  • Un environnement Microsoft 365 vide d’équipes Teams
  • Un environnement Microsoft 365 avec des sites SharePoint ayant des données fictives
  • Un environnement Microsoft 365 vide de sites SharePoint

ShareGate ne s’occupe pas de copier les utilisateurs présents dans le tenant de départ vers le tenant de destination.

Pour cela, exportez la liste des utilisateurs depuis le portail Entra :

Cliquez-ici pour déclencher le téléchargement du fichier au format CSV :

Le fichier CSV généré contient les informations sur les identités Cloud de vos utilisateurs de test :

Sur le tenant de destination, cliquez-ici pour préparer l’importation des utilisateurs :

Cliquez-ici pour télécharger le fichier d’exemple pour l’importation des utilisateurs :

Remplissez le fichier en prenant les informations présentes dans le fichier d’extraction provenant de votre tenant de départ :

Chargez ce nouveau fichier CSV, puis cliquez-ici pour démarrer la création des utilisateurs :

Attendez quelques secondes la fin de l’importation :

Sur le tenant de destination, rafraîchissez la page plusieurs fois si besoin afin de voir apparaître les utilisateurs avec leur nouvel identifiant provisoire :

Si besoin, faites la même opération de création avec les groupes de sécurité que vous souhaitez reprendre dans le tenant de destination.

Notre tenant de destination est déjà prêt pour copier les e-mails contenus dans les boîtes aux lettres du tenant de départ.

Etape III – Copie de données Exchange :

Avant de démarrer la copie via ShareGate Migrate, assignez des licences aux utilisateurs dans le tenant de destination afin de lancer la création des boîtes aux lettres Outlook :

Depuis la console Exchange du tenant de destination, recréez également les boîte aux lettres partagées devant être migrées :

Ajoutez-y les autorisations de délégations aux utilisateurs concernés :

Si nécessaire, activez les boîtes aux lettres archives aux personnes concernées sur le tenant de destination :

Retournez sur l’application ShareGate Migration, puis cliquez sur le menu suivant :

Ajoutez-y une première connexion vers le tenant de départ via le menu suivant :

Cliquez-ici pour vous authentifier :

Renseignez les identifiants d’un administrateur global du tenant de départ :

ShareGate déploie alors une application sur le tenant de départ, et vous demande d’accepter les droits de celle-ci :

Attendez quelques secondes la finalisation de la configuration de l’application sur votre tenant de départ :

Vous pouvez consultez cette première application et ses droits via la page suivante d’Entra :

Sélectionnez alors les boîte aux lettres devant être migrées vers le tenant de destination, puis cliquez-ici :

Ajoutez-y une seconde connexion vers le tenant de destination :

Cliquez-ici pour vous authentifier :

Renseignez les identifiants d’un administrateur global du tenant de destination :

ShareGate déploie également une application sur le tenant de destination, et vous demande d’accepter les droits de celle-ci :

Attendez quelques secondes la finalisation de la configuration de l’application sur votre tenant de destination :

Vous pouvez consultez cette seconde application et ses droits via la page suivante d’Entra :

Choisissez les éléments à copier, puis continuez :

ShareGate Migrate effectue d’abord une correspondance automatique entre les boîtes aux lettres des 2 tenant.

Dans mon cas, n’ayant pas assigné de licence Microsoft 365 à Brian, aucune boîte aux lettres ne lui avait été générée sur le tenant de destination :

Modifiez à votre guise les correspondances entre les boîtes aux lettres des 2 tenants, puis continuez :

ShareGate Migrate effectue ensuite une seconde correspondance automatique entre destinataires internes des 2 tenant :

Dans mon cas, le tenant de départ contenait des adresses e-mails rattachées à des comptes de ressource :

Recréez si nécessaire ces dernières dans le tenant de destination :

Relancez la correspondance automatique :

Confirmez votre choix :

ShareGate retrouve alors toutes les adresses des destinataires internes, puis continuez :

Vérifiez toutes les informations avant la migration, puis démarrez la copie :

Attendez quelques minutes, constatez la fin de l’opération de copie, puis cliquez pour exporter le rapport :

Ouvrez le premier fichier Excel afin de retrouver un récapitulatif de chaque boîte aux lettres avec les informations suivantes :

  • Succès
  • Avertissements
  • Erreurs

D’autres fichiers Excel sont également générés par boîte aux lettres. Dans mon cas, la majorité des erreurs était dues aux calendriers :

Constatez la bonne copie des messages en ouvrant un utilisateur de test sur les tenants de départ et de destination :

Vérifiez le dossier des messages envoyés :

Vérifiez le calendrier, puis constatez la recopie des réunions Teams avec la recréation d’un nouveau lien propre au tenant de destination :

Vérifiez un autre dossier créé par l’utilisateur :

Vérifiez la présence des contacts :

Vérifiez la présence des règles de gestion des messages :

Vérifiez la présence de messages sur une boîte aux lettres partagée :

Retournez sur ShareGate Migration afin de provoquer une nouvelle copie d’une ou plusieurs boîtes aux lettres :

Constatez à chaque traitement de copie la génération d’une tâche depuis le menu suivant :

Notre premier essai concernant la copie de boites aux lettres d’un tenant 365 à autre s’est avéré concluant.

D’autres actions concernant la bascule du nom de domaine personnalisé, le changement des noms d’utilisateurs, les modifications d’enregistrements DNS etc… sont encore à prévoir.

Continuons avec la copie des données des équipes Teams.

Etape IV – Copie de données Teams :

Retournez sur l’application ShareGate Migration, puis cliquez sur le menu suivant :

Ajoutez-y une première connexion vers le tenant de départ via le menu suivant :

Renseignez les identifiants d’un administrateur global du tenant de départ :

Sélectionnez alors les équipes Teams/canaux devant être migrés vers le tenant de destination, puis cliquez-ici :

Ajoutez-y une seconde connexion vers le tenant de destination :

Renseignez les identifiants d’un administrateur global du tenant de destination :

Cliquez-ici pour consulter les options possibles lors de cette copie :

Définissez les options de copie souhaitées, puis cliquez sur Sauvegarder :

Cliquez-ici pour détailler les canaux recréés dans le tenant de destination :

Cliquez-ici pour programmer la copie ultérieurement afin d’anticiper les périodes creuses en termes d’usages et de performances :

Définissez la date et l’heure précise de votre copie, puis cliquez sur Programmer :

Retrouvez cette tâche non démarrée dans l’écran suivant :

Une fois tâche terminée, retrouvez cette dernière dans l’historique des tâches :

La tâche vous informe de la durée de la copie ainsi que du détail des éléments copiés par équipes Teams :

Chaque objets d’équipe Teams est visible et dispose d’un statut de copie :

  • Succès
  • Avertissements
  • Erreurs

En cas d’erreur, des informations sont disponibles sur celle-ci ainsi que sur la marche à suivre :

Comme attendu, SharePoint Migrate ne copie pas les messages Teams :

Constatez la bonne copie des équipes Teams et de leurs canaux en ouvrant un utilisateur de test sur les tenants de départ et de destination :

Vérifiez la présence de messages republiés sur les canaux Teams :

Un onglet spécifique fait son apparition dans le tenant de destination :

Celui-ci affiche les posts Teams dans une présentation plus facile à visualiser :

Constatez la reprise de plans liés à des équipes Teams :

Constatez la reprise de documents hébergés sur le site SharePoint de l’équipe Teams :

Depuis la console Teams du tenant de destination, constatez la présence des équipes Teams :

Depuis la console SharePoint du tenant de destination, constatez la présence de sites SharePoint liés aux équipes Teams :

Retournez sur ShareGate Migrate, puis cliquez sur cette fonction de gestion des équipes Teams :

Cliquez-ici pour vous authentifier :

Renseignez les identifiants d’un administrateur global du tenant de départ :

ShareGate déploie alors une autre application sur le tenant de destination, et vous demande d’accepter les droits de celle-ci :

Cela ouvre une console gérée par ShareGate en relation avec votre tenant Teams de destination afin de vous faciliter certaines opérations :

Retournez sur ShareGate Migrate, puis cliquez sur la fonction de copie incrémentale :

Sélectionnez alors les équipes Teams/canaux devant être copiés de façon incrémentale, puis démarrer la copie :

Attendez quelques minutes la fin de la copie incrémentale :

La tâche vous informe de la durée ainsi que du détail des éléments copiés en incrémental :

Continuons avec la copie de données Planner.

Etape V – Copie de données Planner :

Retournez sur l’application ShareGate Migration, puis cliquez sur le menu suivant :

Sélectionnez le tenant de départ ainsi que les équipes/plans à copier :

Sélectionnez le tenant de destination :

Sélectionnez le groupe de destination, puis démarrez la copie :

Attendez quelques minutes, constatez la fin de l’opération de copie, puis cliquez pour exporter le détail :

Constatez la copie de tous les plans en ouvrant un utilisateur de test sur les tenants de départ et de destination :

Vérifiez la présence de tâches sur les plans copiés :

Continuons nos tests avec la copie de sites SharePoint.

Etape VI – Copie de données SharePoint :

Lorsque vous utilisez ShareGate Migration, l’assignation automatique en tant qu’administrateur de collection de sites est essentielle, même si vous êtes Global Admin dans Microsoft 365. En effet, les droits d’administrateur global ne garantissent pas l’accès automatique à toutes les collections de sites SharePoint ou OneDrive.

Cette option permet à ShareGate d’obtenir les permissions nécessaires pour accéder aux contenus, effectuer des migrations complètes et manipuler les métadonnées sans intervention manuelle, simplifiant ainsi les opérations et réduisant les risques d’erreur.

Pour cela, rendez-vous dans les paramétrages de l’application :

Dans le menu Sécurité, cochez l’option suivante :

Retournez dans le menu Copie, puis cliquez sur le menu suivant :

Ajoutez-y une première connexion vers le tenant de départ, puis cliquez sur Connecter :

Dérouler l’arborescence des collections de sites SharePoint :

Choisissez une collection de sites ou tous les sites SharePoint, puis cliquez sur Suivant :

Ajoutez-y une seconde connexion vers le tenant de destination, puis cliquez sur Connecter :

Choisissez une collection de sites ou tous les sites SharePoint, puis cliquez sur Suivant :

Sélectionnez un ou tous les sites à copier, puis cliquez sur le bouton Options :

Définissez les options de copie souhaitées, puis cliquez sur Sauvegarder :

Lancez un pré-check afin que ShareGate Migration regarde les informations à copier avant de lancer le traitement :

Constatez la génération de la tâche de pré-check visible depuis le menu suivant :

Attendez quelques minutes, puis, une fois le pré-check terminé, cliquez pour consulter le rapport :

Retournez sur l’action pour démarrer la copie vers le tenant de destination :

Patientez quelques minutes le temps du traitement de copie :

Une fois le traitement terminé, cliquez sur cette fonction de gestion des groupes 365 :

Là encore, cela ouvre une console gérée par ShareGate en relation avec votre tenant de destination afin de vous faciliter certaines opérations :

Depuis la console SharePoint ouverte sur les 2 tenants, constatez la présence des sites SharePoint :

Ouvrez le site racine de votre SharePoint :

Ouvrez un site annexe de votre SharePoint :

Terminons avec la migration des comptes OneDrive personnels.

Etape VII – Copie de données OneDrive :

Deux remarques importantes :

  • Le contenu d’une seule bibliothèque OneDrive ne peut être copié à la fois en utilisant l’interface utilisateur de ShareGate Migrate.
  • La copie de la structure n’est pas supportée.

Afin de résoudre ces 2 points, nous allons suivre la procédure via le module ShareGate sous PowerShell.

Afin de générer des comptes OneDrive pour tous les utilisateurs, créez un premier fichier CSV contenant tous les comptes OneDrive de destination comme ceci :

Ouvrez PowerShell avec le module ShareGate par le menu suivant :

Lancez le script ci-dessous en y renseignant les informations suivantes :

  • Login Global admin du tenant de destination
  • Mot de passe Global admin du tenant de destination
  • Adresse admin du site SharePoint du tenant de destination
  • Fichier CSV reprenant les compte OneDrive à générer
$myusername = "sharegate1@jloudev3.onmicrosoft.com"
$mypassword = ConvertTo-SecureString 'mymotdepasse' -AsPlainText -Force
$tenant = Connect-Site -Url "https://jloudev3-admin.sharepoint.com/" -Username $myusername -Password $mypassword
$csvFile = "C:\Azure\CSVfile.csv"
$table = Import-Csv $csvFile -Delimiter ","
foreach ($row in $table) {
    Get-OneDriveUrl -Tenant $tenant -Email $row.Email -ProvisionIfRequired -DoNotWaitForProvisioning
}

Afin de voir la création des différents comptes OneDrive, rendez-vous dans le menu suivant de SharePoint Migration :

Attendez la création de tous les espaces OneDrive avant de continuer :

Afin de récupérer les URLs des sites OneDrive du tenant de départ, lancez la génération d’un premier rapport personnalisé :

Cliquez comme ceci :

Choisissez le tenant de départ, puis cliquez sur Suivant :

Lancez la génération du rapport :

Sélectionnez tous les comptes OneDrive, puis cliquez sur Editer :

Ajoutez l’administrateur global de votre tenant de départ, puis cliquez sur Appliquer :

Cliquez sur Continuer :

Cliquez sur Retour :

Cliquez sur Retour :

Cliquez sur Exporter :

Sauvegardez l’export au format XLSX :

Cliquez sur Fermer :

Effectuez à nouveau TOUTES ces opérations pour le tenant de destination :

Créez un second fichier au format CSV, reprenant les URLs des comptes OneDrive avec :

  • en premières colonne ceux du tenant de départ
  • en seconde colonne ceux du tenant de destination

Ouvrez une fenêtre PowerShell, puis lancez le script suivant en y renseignant les informations suivantes :

  • Login Global admin du tenant de départ
  • Mot de passe Global admin du tenant de départ
  • Login Global admin du tenant de destination
  • Mot de passe Global admin du tenant de destination
  • Second fichier CSV reprenant les comptes OneDrive à copier / coller
Import-Module Sharegate

# Define the CSV file path
$csvFile = "C:\Azure\CopyContent.csv"

# Import the CSV file
$table = Import-Csv $csvFile -Delimiter ","

# Define source and destination credentials
$srcUsername = "admin@M365x72297931.onmicrosoft.com"
$srcPassword = ConvertTo-SecureString 'mymotdepasse' -AsPlainText -Force
$dstUsername = "sharegate1@jloudev3.onmicrosoft.com"
$dstPassword = ConvertTo-SecureString 'mymotdepasse' -AsPlainText -Force

# Set variables for site and list operations
Set-Variable srcSite, dstSite, srcList, dstList

# Loop through each row in the CSV
foreach ($row in $table) {
    # Clear previous values of variables
    Clear-Variable srcSite
    Clear-Variable dstSite
    Clear-Variable srcList
    Clear-Variable dstList

    # Connect to source and destination sites
    $srcSite = Connect-Site -Url $row.SourceSite -Username $srcUsername -Password $srcPassword
    $dstSite = Connect-Site -Url $row.DestinationSite -Username $dstUsername -Password $dstPassword

    # Get source and destination lists
    $srcList = Get-List -Site $srcSite -Name "Documents"
    $dstList = Get-List -Site $dstSite -Name "Documents"

    # Copy content from source list to destination list
    Copy-Content -SourceList $srcList -DestinationList $dstList

    # Remove site collection administrator permissions
    Remove-SiteCollectionAdministrator -Site $srcSite
    Remove-SiteCollectionAdministrator -Site $dstSite
}

Attendez quelques minutes la fin du traitement de copie des données OneDrive pour tous les comptes :

Constatez la bonne copie des données OneDrive en ouvrant un utilisateur de test sur les tenants de départ et de destination :

Conclusion

En somme, l’exploration de ShareGate Migrate nous a permis de constater que cet outil se positionne comme une solution complète et efficace pour orchestrer des migrations complexes entre tenants Microsoft 365.

Du transfert des boîtes aux lettres à la copie des équipes Teams, en passant par la migration des sites SharePoint, Planner et OneDrive, ShareGate offre une approche centralisée qui simplifie chaque étape du processus.

Bien que certaines limitations subsistent – notamment en ce qui concerne la migration de certains éléments spécifiques dans Exchange ou Teams – ShareGate se démarque par sa capacité à rendre le processus de migration transparent et maîtrisable.

Ce que nous avons découvert, c’est l’importance d’une préparation rigoureuse : la mise en place des prérequis, la vérification des permissions et la création des comptes adéquats constituent autant de facteurs déterminants pour le succès de la migration.

de VMware à Azure Local

La migration des machines virtuelles depuis VMware vers Azure Local via l’outil Azure Migrate a récemment été annoncée en préversion. Cette nouveauté chez Microsoft représente une avancée significative dans les migrations automatisées vers le cloud hybride. Cette nouvelle fonctionnalité d’Azure Migrate permet donc aux organisations de transférer leurs charges de travail sur site vers une infrastructure Azure Local tout en minimisant les interruptions.

Depuis quelques déjà, il existe sur le marché d’autres solutions externes qui proposent la migration de machines virtuelles hébergées sur VMware vers un cluster Azure Local :

Azure nous facilite donc la chose en l’intégrant dans Azure Migrate. En parlant d’Azure Migrate, un premier article sous forme d’exercice est disponible juste ici. Il vous permet de tester la migration de machines virtuelles Hyper-V vers Azure :

De façon générale, voici quelqu’un des principaux avantages à utiliser Azure Migrate :

  • Aucune préparation requise : La migration ne nécessite pas l’installation d’agents sur les machines virtuelles hébergés sous Hyper-V ou VMware.
  • Contrôle via le portail Azure : Les utilisateurs peuvent gérer et suivre toutes les étapes de leur migration directement depuis le portail Azure.
  • Flux de données local : Les données restent sur site pendant la migration, ce qui réduit les risques de latence.
  • Temps d’arrêt minimal : La solution permet de migrer les VMs avec un impact minimal sur les opérations en cours.

Aujourd’hui, nous sommes ravis d’annoncer l’avant-première publique de la fonctionnalité Azure Migrate permettant de migrer des machines virtuelles de VMware vers Azure Local, une amélioration significative de nos capacités de migration vers le cloud qui s’étend de manière transparente jusqu’à la périphérie, conformément à notre approche du cloud adaptatif.

Microsoft Tech Community

L’écran ci-dessous nous montre la section dédiée à la migration de ressources vers Azure Local :

Comment se passe la migration VMware -> Azure Local ?

Les grandes étapes d’une migration vers Azure Local sont très proches de celles vers Azure. Quelques étapes et composants nécessaires différent légèrement :

  • Un projet doit toujours être créé via Azure Migrate depuis le portail Azure
  • 2 appliances (VMware et Azure Local) doivent être créées et configurées
    • Une appliance virtuelle s’exécutant sur les serveurs VMware
    • Une seconde appliance virtuelle s’exécutant sur le cluster Azure Local

Voici les principales phases du processus de migration Azure Migrate :

Phase de migrationDescription
1. PréparationPréparez-vous à migrer en complétant les prérequis. Déployez et configurez votre cluster Azure Local. Créez un projet Azure Migrate et un compte de stockage Azure.
2. DécouverteCréez et configurez une appliance source Azure Migrate sur VMware pour découvrir vos serveurs.
3. RéplicationConfigurez l’appliance cible sur Azure Local et sélectionnez les VMs à répliquer.
4. Migration et vérificationMigrez les VMs vers Azure Local et vérifiez leur bon fonctionnement après la migration.

Quels sont les systèmes d’exploitation pris en charge ?

Pour que cette migration puisse fonctionner, seulement certaines versions d’OS sont actuellement prises en charge :

ComposantSystèmes d’exploitation pris en charge
Environnement VMware sourceVMware vCenter Server version 8.0
VMware vCenter Server version 7.0
VMware vCenter Server version 6.7

VMware vCenter Server version 6.5
Appliance VMware Windows Server 2022
Environnement Azure Local cibleAzure Local, version 23H2
Appliance Azure LocalWindows Server 2022
Machine virtuelle invitée (Windows)Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2*
Machine virtuelle invitée (Linux)Red Hat Linux 6.x, 7.x
Ubuntu Server et Pro. 18.x
CentOS 7.x
SUSE Linux Enterprise 12.x
Debian 9.x

Microsoft liste toutes les conditions requises pour envisager cette migration juste ici.

Puis-je créer mon projet Azure Migrate dans toutes les géographies Azure ?

Pour le moment, les métadonnées de votre projet Azure Migrate peuvent être uniquement stockées dans une des géographies Azure suivantes pour les migrations vers Azure Local :

GéographiesRégions
Asie-PacifiqueAsie Sud-Est, Asie Est
EuropeEurope Nord – Europe Ouest
États-UnisUSA Centre, USA Ouest2

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Azure Local via Azure Migrate. Pour tout cela, il nous faut :

  • Un tenant Microsoft
  • Une souscription Azure active
  • Un environnement Azure Local opérationnel
  • Un environnement VMware opérationnel

Commençons par la création du projet sur Azure Migrate, puis la configuration de l’appliance sur l’environnement VMware.

Etape I – Configuration VMware :

Pour cela, recherchez le service Azure Migrate grâce à la barre de recherche présente dans votre portail Azure :

Sélectionnez le menu suivant, puis cliquez-ici pour créer votre projet de migration :

Renseignez les différentes informations de votre projet en prenant en compte les géographies supportant ce scénario de migration, puis cliquez sur Créer :

Une fois le projet créé, cliquez-ici afin d’installer une appliance sur l’environnement VMware :

Définissez la cible de migration comme étant sur Azure Local, puis la source comme étant VMware :

Nommez votre appliance VMware, puis cliquez ici pour générer une clef d’association (entre l’appliance et votre projet d’Azure Migrate) :

Une fois la clef générée, copiez la dans votre bloc-notes :

Lancez le téléchargement de votre appliance afin de pouvoir en disposer par la suite sur votre environnement VMware :

Afin d’y accéder plus facilement sur vSphere, vous pouvez créer un compte de stockage publique :

Dans ce compte de stockage, créez un conteneur blob :

Une fois l’image de l’appliance téléchargée localement, utilisez l’outil azcopy afin de déposer votre image OVA sur votre compte de stockage blob :

Vérifiez la présence de l’image OVA sur votre compte de stockage, puis cliquez dessus :

Récupérez l’URL blob de votre image OVA accessible publiquement :

Depuis votre console vSphere, cliquez-ici pour créer une nouvelle machine virtuelle via la fonction de template OVF :

Collez l’URL de votre image OVA, puis cliquez sur Suivant :

Confirmez votre confiance en cliquant sur Oui :

Nommez votre machine virtuelle appliance, ainsi que son dossier, puis cliquez sur Suivant :

Sélectionnez la ressource de calcul VMware adéquate, cochez la case de démarrage après création, puis cliquez sur Suivant :

Vérifiez toutes les informations dont l’OS utilisé par l’appliance VMware, puis cliquez sur Suivant :

Définissez la ressource de stockage VMware adéquate, puis cliquez sur Suivant :

Choisissez le réseau virtuel VMware adéquat, puis cliquez sur Suivant :

Vérifiez toutes les informations avant la création de la machine virtuelle, puis cliquez sur Finir :

Constatez la création de 2 tâches, puis attendez quelques minutes :

  • vSphere VMware rapatrie l’image OVA,
  • vSphere créé la machine virtuelle appliance

Une fois la VM créée, installez-y les outils VMware :

Cliquez sur Mettre à jour :

Une fois la VM démarrée, ouvrez la console web de celle-ci :

Attendez la finalisation de la préparation de Windows Server :

Acceptez les Termes et conditions :

Configurez le mot de passe du compte administrateur (clavier US), puis cliquez sur Finaliser :

Connectez-vous avec le mot de passe configuré juste avant :

Attendez quelques minutes pour voir automatiquement s’ouvrir le navigateur internet :

Acceptez les Termes et conditions d’Azure Migrate :

Laissez faire la connexion entre votre appliance VMware et Azure :

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

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

Rafraîchissez la page au besoin si le système vous le demande :

Authentifiez-vous avec votre compte Azure :

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

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

Choisissez le compte Azure aux droits RBAC adéquats :

Cliquez sur Continuer pour autoriser l’authentification Azure :

Fermez la fenêtre de navigation internet :

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

Comme indiqué récupérez l’applicatif VMware Virtual Disk Developpement Kit depuis une source internet, copiez le dossier, puis cliquez sur Vérifier :

Afin que l’appliance VMware puisse découvrir les machines virtuelles en fonctionnement sur vCenter, cliquez-ici pour ajouter les informations d’identification :

Cliquez ici pour ajouter des informations sur les VMs hébergées sur VMware à analyser :

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

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

Cliquez ici pour démarrer la découverte des machines virtuelles sur VMware :

Mais, avant de retourner sur Azure, n’oubliez pas de renseigner et de valider les informations d’identification de votre cluster Azure Local :

La découverte est terminée et les résultats sont disponibles sur Azure :

Retournez sur le portail Azure afin de rafraîchir la page de votre projet Azure Migrate :

Quelques rafraîchissements plus tard, les serveurs VMware commencent à faire leur apparition :

La configuration VMware est maintenant terminée, nous allons pouvoir nous concentrer sur la seconde partie de la configuration dédiée à Azure Local.

Etape II – Configuration Azure Local :

Toujours sur votre projet Azure Migrate, cliquez alors sur le bouton Répliquer :

Renseignez les informations suivantes, puis cliquez sur Continuer :

  • Sélectionnez le type de service : Serveurs ou machines virtuelles (VM)
  • Sélectionnez la destination : Azure Local
  • Sélectionnez la source : VMware vSphere
  • Pour l’appliance Azure Migrate : l’appliance créée sur votre vCenter

Renseignez les informations de votre cluster Azure Local, puis cliquez sur Suivant :

Indiquez un nom pour l’appliance Azure Local, générez la clé, puis copiez cette dernière dans un bloc note :

Télécharger le fichier ZIP de votre appliance Azure Local :

À l’aide d’Hyper-V Manager, créez une nouvelle VM sous Windows Server 2022, avec 80 Go (min) de stockage sur disque, 16 Go (min) de mémoire et 8 processeurs virtuels sur un de vos nœuds Azure Local, puis démarrez celle-ci :

Une fois authentifié en mode administrateur sur cette appliance Azure Local, copiez et collez le fichier zip téléchargé.

En tant qu’administrateur, exécutez le script PowerShell suivant à partir des fichiers extraits pour installer l’appliance Azure Local :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
.\AzureMigrateInstaller.ps1

Choisissez l’option 4 :

Choisissez l’option 1 :

Choisissez l’option 1 :

Confirmez votre action avec Y :

Attendez quelques minutes la fin du traitement :

Confirmez votre action avec l’option A :

Confirmez votre action avec N :

Redémarrez la VM, reconnectez-vous avec le même compte administrateur, ouvrez Azure Migrate Target Appliance Configuration Manager à partir du raccourci du bureau, puis collez la clef précédemment copiée :

Attendez quelques minutes le temps de l’enrôlement de l’appliance Azure Local dans votre projet Azure Migrate, puis authentifiez-vous via Azure PowerShell :

Une fois l’appliance Azure Local enregistrée, sous Gérer les informations du cluster Azure Local, sélectionnez Ajouter des informations de cluster, puis cliquez sur Configurer :

Attendez quelques minutes la fin de la configuration :

Retournez sur le projet Azure Migrate depuis le portail Azure, puis cliquez-ici :

Constatez l’apparition l’appliance Azure Local, puis cliquez sur Suivant :

Choisissez la machine virtuelle à migrer sur votre cluster Azure Local, puis cliquez sur Suivant :

Définissez la configuration réseau et stockage de votre machine virtuelle migrée, puis cliquez sur Suivant :

Configurez le nombre de vCPU et la RAM, puis cliquez sur Suivant :

Sélectionnez les disques que vous souhaitez répliquer, puis cliquez sur Suivant :

Dans ce dernier onglet, assurez-vous que toutes les valeurs sont correctes, puis sélectionnez Répliquer :

Restez sur cette page jusqu’à la fin du processus (cela peut prendre 5 à 10 minutes). Si vous quittez cette page, les objets liés à la réplication ne seront pas entièrement créés, ce qui entraînera un échec de la réplication et, par la suite, de la migration.

Les 2 notifications Azure suivantes devraient alors s’afficher :

De retour sur votre projet Azure Migrate, vous pouvez suivre votre réplication depuis le menu suivant :

Une section dédiée à Azure Local est disponibles et affiche les réplications, les opérations et les événements, cliquez-ici pour avoir plus de détail sur la réplication en cours :

Les différentes étapes de réplication se suivent :

La progression via un pourcentage est même visible :

La phase finale de synchronisation des données arrive par la suite :

La prochaine étape consistera justement à faire la migration pour basculer notre VM vers Azure Local.

Etape III – Migration VMware -> Azure Local :

Une fois la réplication terminée, la machine virtuelle répliquée sur Azure Local est visible en cliquant ici :

Cliquez alors sur le statut de la machine virtuelle vous indiquant que la migration est prête :

Déclenchez la migration vers Azure Local en cliquant ici :

La notification Azure suivante apparaît alors :

Le travail de bascule planifiée est visible dans le menu suivant :

Les différentes étapes de migration vers Azure Local se suivent :

Rafraîchissez cette fenêtre plusieurs fois afin de constater le succès du processus :

Constatez l’apparition de la machine virtuelle migrée sur la page Azure de votre cluster Azure Local, puis cliquez dessus :

Copiez l’adresse IP privée de cette nouvelle machine virtuelle créée sous Azure Local :

Etape IV – Actions post-migration :

Dans mon scénario, j’ai utilisé une connexion Azure Virtual Desktop hébergé sur mon cluster Azure Local :

Une fois sur le réseau de votre Azure Local, ouvrez une connexion RDP vers l’adresse IP de votre machine virtuelle migrée :

Rentrez les identifiants de l’administrateur local, puis cliquez sur OK :

Constatez la bonne ouverture de session Windows sur votre machine virtuelle migrée :

Si la migration vous semble réussie, retournez sur votre projet Azure Migrate afin de déclarer la migration vers Azure Local comme étant complète :

Confirmez votre choix d’arrêt de réplication en cliquant sur Oui :

La notification Azure suivante apparaît alors :

L’action de Terminer la migration ne fera que nettoyer la réplication en supprimant le travail de suppression de l’élément protégé – cela n’affectera pas votre VM migrée.

Une fois la ressource migrée supprimée, elle est également supprimée de la vue Réplications. Vous verrez également le travail de migration de la VM disparaître de la vue Réplications :

Retournez sur la machine virtuelle sous Azure Local afin de finaliser l’intégration de cette VM dans l’hyperviseur Azure Local :

Il nous faut donc activer la gestion des invités pour la machines virtuelle migrée en y attachant l’ISO.

Pour cela, connectez-vous à un serveur Azure Local, puis exécutez la commande CLI suivante dans une fenêtre PowerShell sur la VM migrée pour laquelle l’agent invité doit être activé :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-vm-config-agent true

Affichez les informations de l’installeur de l’agent :

Installez l’ISO de l’agent invité sur la VM migrée comme suit :

$d=Get-Volume -FileSystemLabel mocguestagentprov;$p=Join-Path ($d.DriveLetter+':\') 'install.ps1';powershell $p

Activez la gestion de l’invité après que l’agent de l’invité a été installé de la manière suivante :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-agent true

Cette dernière étape n’a malheureusement pas fonctionné chez moi, comme l’indique encore le statut du management invité :

Le sujet est encore en discussion sur le forum Tech Community de Microsoft :

Nul doute que le souci va être corrigé sous peu ! Une page de résolution des problèmes a aussi été créée par Microsoft juste ici, ainsi qu’une FAQ.

Conclusion

En choisissant de migrer de VMware vers Azure Local, les entreprises s’engagent dans une transformation stratégique qui allie flexibilité et modernité.

Cette transition permet non seulement de consolider les ressources locales avec la puissance d’Azure, mais aussi de réduire les coûts opérationnels et de simplifier la gestion des infrastructures hybrides.

Migrez un ancien OS Windows sur le Cloud Azure

De mon côté, l’aventure IT a commencé en décembre 1995 avec mon tout premier ordinateur : un 486 SX-33 développé par Intel. Je ne saurais me rappeler de sa quantité de mémoire vive, mais je pense que je pouvais les compter sur les doigts d’une seule main 🤣.

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

Plus sérieusement, que ce passe-t-il si une application métier, toujours fonctionnelle et devant perdurer, doit être migrée au plus vite pour une raison X ?

Microsoft a peut-être une réponse grâce au le service Azure Migrate :

Azure Migrate offre un service simplifié de migration, de modernisation et d’optimisation pour Azure. Toutes les étapes de pré-migration telles que la détection, les évaluations et le dimensionnement des ressources locales sont incluses pour l’infrastructure, les données et les applications. L’infrastructure extensible d’Azure Migrate permet d’intégrer des outils tiers, ce qui augmente l’étendue des cas d’utilisation pris en charge.

Microsoft Learn

Pour vous faire une meilleure idée d’Azure Migrate, un atelier exercice dédié à la migration vers Azure conçu par Microsoft avait déjà été détaillé sur ce blog juste ici.

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

Qu’est-ce que Disk2vhd ?

Il s’agit d’un petit utilitaire très pratique développé par Mark Russinovich et disponible dans la suite Sysinternals :

Disk2vhd est un utilitaire qui crée des versions VHD (Virtual Hard Disk – Microsoft’s Virtual Machine disk format) de disques physiques à utiliser dans Microsoft Virtual PC ou Microsoft Hyper-V virtual machines (VMs). La différence entre Disk2vhd et d’autres outils physiques à virtuels est que vous pouvez exécuter Disk2vhd sur un système en ligne.

Microsoft Learn

Disk2vhd utilise la capacité d’instantané de volume de Windows, introduite dans Windows XP, pour créer des instantanés cohérents à un instant donné des volumes que vous souhaitez inclure dans une conversion. Vous pouvez même demander à Disk2vhd de créer les VHD sur des volumes locaux, même ceux en cours de conversion (bien que les performances soient meilleures lorsque le VHD se trouve sur un disque différent de ceux en cours de conversion).

Microsoft Learn

Au travers de ce nouvel article, je souhaitais tester avec vous la copie de plusieurs serveurs physiques fonctionnant sous d’anciens OS afin de tester un portage rapide et simple vers Azure :

  • Windows XP Professional
  • Windows 7 Professional x64
  • Windows 10 Enterprise x64
  • Windows Server 2008 R2 x64
  • Windows Server 2012 R2 x64
  • Windows Server 2016 x64

Pour cela, cet article repose sur la méthode de préparation d’un fichier VHD proposée par Microsoft et exposée juste ici, dont les principales commandes de préparation sont disponibles sur mon GitHub.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de migration individuelle, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

N’ayant pas d’anciens serveurs physiques à disposition, j’ai choisi de les simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.

Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :

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

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

Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :

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

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

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

Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :

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

Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées :

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

Conservez les options par défaut, puis cliquez sur OK :

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

Cliquez ensuite sur Suivant :

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

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

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

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

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

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle hôte (Hyper-V) :

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

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

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

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

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

Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

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

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

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

Exécutez la commande suivante pour installer les deux rôles suivants :

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

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

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

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

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

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

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

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

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

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

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24
L’attribut alt de cette image est vide, son nom de fichier est image-22.png.

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

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver
L’attribut alt de cette image est vide, son nom de fichier est image-23.png.

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :

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

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

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

Sur celui-ci, créez un nouveau volume :

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

Cliquez sur Suivant :

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

Cliquez sur Suivant :

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

Cliquez sur Suivant :

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

Cliquez sur Suivant :

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

Cliquez sur Terminer :

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

L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.

Etape II – Création de la machine virtuelle invitée :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :

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

Stockez le fichier ISO sur le disque F de votre VM hôte (Hyper-V) :

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

Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :

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

Cliquez-ici pour créer votre machine virtuelle invitée :

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

Cliquez sur Suivant :

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

Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :

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

Choisissez Génération 1 :

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

Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

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

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

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

Cliquez sur Suivant :

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

Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :

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

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :

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

Une fois la machine virtuelle invitée créée, modifiez sa configuration comme ceci :

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

Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows, puis cliquez sur OK :

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

Répétez les mêmes opérations pour les autres OS dont vous souhaitez tester la migration vers Azure :

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

Double-cliquez sur votre machine virtuelle invitée :

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

Cliquez-ici pour lancer le démarrage de la VM invitée :

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

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

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

Lancez l’installation de Windows :

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

Attendez que le démarrage de l’installation se lance, puis cliquez-ici pour ne pas renseigner de clef de licence Windows :

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

Choisissez une version Desktop de Windows, puis cliquez sur Suivant :

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

Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :

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

Sélectionnez l’installation personnalisée de Windows :

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

Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :

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

Attendez maintenant que l’installation de Windows commence :

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

Lancez le redémarrage de la machine virtuelle invitée :

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

Donnez à nom si nécessaire à votre compte local Windows et un mot de passe :

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

La machine virtuelle invitée avec l’ancien OS Windows est maintenant en place. Comme pour une machine physique, nous allons maintenant générer un fichier VHD afin de pouvoir préparer l’OS à être remonté sur Azure.

Avant cela, quelques modifications sont nécessaires.

Etape III – Génération du fichier VHD :

Sur votre VM hôte (Hyper-V), créez un nouveau dossier contenant une ou plusieurs versions de l’outil Disk2vhd selon l’ancienneté de l’OS concerné :

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

Partagez ce dossier sur le réseau :

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

Créez un second dossier dédié au VHD généré par l’outil Disk2vhd, puis partagez ce dossier sur le réseau :

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

Depuis la machine virtuelle invitée, ouvrez l’application Disk2vhd depuis le premier partage, puis sauvegardez votre fichier VHD sur le second partage :

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

Le traitement VSC peut prendre entre 5 minutes et 2 heures :

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

Le message de succès apparaît alors à la fin du traitement :

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

Effectuez ces mêmes opérations de génération du fichier VHD pour chacun des OS comme ceci :

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

Fermez la session utilisateur de votre machine virtuelle invitée :

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

Eteignez également votre machine virtuelle invitée :

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

Effectuez ces opérations d’arrêt pour chacune des machines virtuelles invitées :

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

Les machines virtuelles de départ sont maintenant toutes éteintes. Avant de pouvoir transférer le fichier VHD vers Azure, il est nécessaire d’effectuer plusieurs opérations au niveau de l’OS, mais également du fichier VHD.

Etape IV – Préparation du fichier VHD :

Pour cela, nous allons recréer de nouvelles machines virtuelles identiques, dans lesquelles nous allons passer plusieurs commandes PowerShell.

Toujours sur Hyper-V Manager, cliquez-ici pour créer une nouvelle machine virtuelle invitée :

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

Cliquez sur Suivant :

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

Modifier les informations suivantes, puis cliquez sur Suivant :

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

Choisissez Génération 1 :

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

Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

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

Utilisez le même switch que précédemment, puis cliquez sur Suivant :

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

Rattachez le nouveau disque VHD généré via Disk2vhd, puis cliquez sur Suivant :

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

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :

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

Une fois la machine virtuelle invitée créée, modifiez le nombre de processeurs virtuels, puis cliquez sur OK :

Répétez les mêmes opérations pour les autres OS, puis double-cliquez sur une nouvelle machine virtuelle invitée :

Cliquez-ici pour lancer le démarrage de la VM invitée :

Depuis le menu Démarrer, recherchez Windows PowerShell ISE en mode administrateur :

Confirmez le risque sécuritaire en cliquant sur Oui :

Ouvrez le fichier de script suivant, disponible sur mon GitHub :

Lancez la commande System File Checker (SFC) afin de vérifier les fichiers systèmes Windows :

sfc.exe /scannow

Quelques minutes plus tard, SFC vous confirme le succès du contrôle :

Lancez la commande netsh afin de réinitialiser les paramètre proxy :

netsh.exe winhttp reset proxy

Ouvrez via CMD en mode administrateur afin de lancez l’utilitaire Diskpart :

diskpart.exe
san policy=onlineall
exit

Configurez l’heure UTC pour Windows :

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation -Name RealTimeIsUniversal -Value 1 -Type DWord -Force
Set-Service -Name w32time -StartupType Automatic

Modifiez le profil d’alimentation en performances hautes :

powercfg.exe /setactive SCHEME_MIN
powercfg /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOIDLE 0

Réinitialisez les variables systèmes par défaut :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name TEMP -Value "%SystemRoot%\TEMP" -Type ExpandString -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name TMP -Value "%SystemRoot%\TEMP" -Type ExpandString -Force

Réinitialisez par défaut certains services Windows :

Get-Service -Name BFE, Dhcp, Dnscache, IKEEXT, iphlpsvc, nsi, mpssvc, RemoteRegistry |
  Where-Object StartType -ne Automatic |
    Set-Service -StartupType Automatic

Get-Service -Name Netlogon, Netman, TermService |
  Where-Object StartType -ne Manual |
    Set-Service -StartupType Manual

Activez le service bureau à distance RDP :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name fDenyTSConnections -Value 0 -Type DWord -Force

Validez le port par défaut 3389 pour le protocole RDP :

L’auditeur écoute sur chaque interface réseau :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name LanAdapter -Value 0 -Type DWord -Force

Configurez le mode d’authentification au niveau du réseau (NLA) pour les connexions RDP selon l’OS :

Pour Windows Server 2012, 2016 et pour Windows 10 :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1 -Type DWord -Force

Pour Windows Server 2008 R2 et pour Windows 7 :

Set-Itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -value '0'
Set-Itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -value '0'

Définissez la valeur keep-alive :

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name KeepAliveEnable -Value 1  -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name KeepAliveInterval -Value 1  -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name KeepAliveTimeout -Value 1 -Type DWord -Force

Définissez les options de reconnexion :

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name fDisableAutoReconnect -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name fInheritReconnectSame -Value 1 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name fReconnectSame -Value 0 -Type DWord -Force

Limitez le nombre de connexions simultanées :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name MaxInstanceCount -Value 4294967295 -Type DWord -Force

Supprimez tous les certificats auto-signés liés à l’écoute RDP :

if ((Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp').Property -contains 'SSLCertificateSHA1Hash')
{
    Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SSLCertificateSHA1Hash -Force
}

Activez le pare-feu Windows sur les 3 profils réseaux (domaine, standard et public) :

Set-NetFirewallProfile -Profile Domain, Public, Private -Enabled True

Ouvrez l’explorateur de fichiers Windows, cliquez sur le menu Réseau, puis changez l’option suivante :

Activez l’option suivante :

Convertissez la connexion actuelle en réseau privé :

Activer le service à distance PowerShell :

Activez les règles de pare-feu suivantes pour autoriser le trafic RDP :

Activez la règle des requêtes ping à l’intérieur du réseau virtuel :

Créez les règles suivantes entrantes et sortantes point vers le service DNS d’Azure :

Ouvrez CMD en mode administrateur afin de lancer l’utilitaire Diskpart :

chkdsk.exe /f

Lancez le redémarrage de la machine virtuelle invitée :

N’appuyez sur aucune touche afin de lancer le contrôle du disque :

Attendez la fin de traitement :

Réouvrez la session Windows de votre machine virtuelle invitée :

Ouvrez CMD en mode administrateur afin de définir les paramètres des données de configuration de démarrage (BCD) :

cmd

bcdedit.exe /set "{bootmgr}" integrityservices enable
bcdedit.exe /set "{default}" device partition=C:
bcdedit.exe /set "{default}" integrityservices enable
bcdedit.exe /set "{default}" recoveryenabled Off
bcdedit.exe /set "{default}" osdevice partition=C:
bcdedit.exe /set "{default}" bootstatuspolicy IgnoreAllFailures

#Enable Serial Console Feature
bcdedit.exe /set "{bootmgr}" displaybootmenu yes
bcdedit.exe /set "{bootmgr}" timeout 5
bcdedit.exe /set "{bootmgr}" bootems yes
bcdedit.exe /ems "{current}" ON
bcdedit.exe /emssettings EMSPORT:1 EMSBAUDRATE:115200

exit

Réouvrez Windows PowerShell ISE en mode administrateur :

Activez la collecte des journaux d’erreur :

# Set up the guest OS to collect a kernel dump on an OS crash event
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Type DWord -Force -Value 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name DumpFile -Type ExpandString -Force -Value "%SystemRoot%\MEMORY.DMP"
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name NMICrashDump -Type DWord -Force -Value 1
# Set up the guest OS to collect user mode dumps on a service crash event
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
if ((Test-Path -Path $key) -eq $false) {(New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting' -Name LocalDumps)}
New-ItemProperty -Path $key -Name DumpFolder -Type ExpandString -Force -Value 'C:\CrashDumps'
New-ItemProperty -Path $key -Name CrashCount -Type DWord -Force -Value 10
New-ItemProperty -Path $key -Name DumpType -Type DWord -Force -Value 2
Set-Service -Name WerSvc -StartupType Manual

Vérifiez que le référentiel Windows Management Instrumentation (WMI) est toujours cohérent :

winmgmt.exe /verifyrepository

Assurez-vous qu’aucune autre application que TS n’utilise le port 3389 :

netstat.exe -anob | findstr 3389

Vérifiez les mises à jour Windows :

Lancez le redémarrage de la machine virtuelle invitée :

Depuis votre machine virtuelle hôte (Hyper-V), vérifiez la bonne ouverture de session RDP :

Eteignez votre machine virtuelle invitée :

Notre machine virtuelle invitée est maintenant prête à être migrée vers Azure. Pour cela, nous allons utilisez la commande PowerShell Add-AzVhd.

Etape V – Création de la machine virtuelle Azure :

Depuis le portail Azure, créez un nouveau groupe de ressources pour la machine virtuelle invitée dans le Cloud :

Depuis votre machine virtuelle hôte (Hyper-V), connectez-vous à votre environnement Azure via PowerShell ISE :

Lancez les commandes PowerShell Azure suivantes afin de créer un disque managé Azure depuis le fichier VHD local :

Add-AzVhd -LocalFilePath C:\data.vhd -ResourceGroupName rgname -Location eastus -DiskName newDisk

Une première étape de détection commence alors :

Suivi du calcul de Hash :

Pour finir par le transfert vers Azure :

Retournez sur le groupe de ressources Azure créé précédemment, constatez la présence d’un disque managé, puis cliquez dessus :

Cliquez ici pour créer la machine virtuelle :

Renseignez les informations de base :

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

Sur l’onglet Réseau, reprenez le même réseau virtuel que celui utilisé pour votre machine virtuelle Hyper-V, puis lancez la validation Azure :

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

Attendez quelques minutes le succès de la création de votre VM, puis cliquez ici :

Attendez quelques minutes le démarrage complet de votre VM :

Vérifiez le bon démarrage de votre VM en actualisant si besoin plusieurs fois le screenshot suivant :

Constatez la présence de l’avertissement Azure suivant :

Renseignez les identifiants renseignés lors de la création de votre VM invitée :

Constatez la bonne ouverture de session Windows :

Une fois la session Windows ouverte, installez l’agent pour les machines virtuelles Azure disponible sur cette page GitHub :

Exécutez le fichier MSI d’installation depuis une session PowerShell avec les droits administrateurs :

Cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Attendez quelques minutes la fin de l’installation de l’agent :

Cliquez sur Terminer :

Quelques minutes plus tard, constatez la disparition de l’alerte Azure sur votre VM :

Vérifiez la bonne relation entre le management Azure et votre VM via le menu suivant :

La commande suivante doit vous retourner la configuration IP renseignée sur votre VM :

Effectuez un test d’arrêt de votre machine virtuelle :

Confirmez votre action en cliquant sur Oui :

Effectuez un test de démarrage de votre machine virtuelle :

Vérifiez le succès des 2 opérations via les notifications Azure :

Cliquez-ici pour rouvrir la session Windows ouverte précédemment via Azure Bastion :

Effectuez les mêmes opérations pour les autres anciens OS à tester :

Conclusion

Par cette démonstration, un portage rapide et en urgence de certaines anciennes versions Windows, client ou serveur, est parfaitement possible. Quelques manipulations de préparation sont nécessaires, mais ces dernières sont fonctionnelles pour les OS suivants :

  • Windows 7 Professional x64
  • Windows 10 Enterprise x64
  • Windows Server 2008 R2 x64
  • Windows Server 2012 R2 x64
  • Windows Server 2016 x64

Déplacez votre VM dans une Zone Azure

Il y a quelques jours, Microsoft vient d’annoncer une nouvelle fonctionnalité de migration très intéressante pour les machines virtuelles déjà en place : la possibilité de déplacer une machine virtuelle, actuellement non zonée, vers une zone précise de la région Azure.

Pourquoi faire ? Pour accroitre la résilience de l’infrastructure 🙏

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

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

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

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

ScénarioAssistance techniqueDétails
Machine virtuelle à instance uniquePrise en chargeLe déplacement régional vers zonal de machines virtuelles à instance unique est pris en charge.
Machines virtuelles au sein d’un groupe à haute disponibilitéNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration uniformeNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexibleNon pris en charge
Régions prises en chargePrise en chargeSeules les régions prises en charge par la zone de disponibilité sont prises en charge. En savoir plus sur les détails de la région.
Machines virtuelles déjà situées dans une zone de disponibilitéNon pris en chargeLe déplacement interzone n’est pas pris en charge. Seules les machines virtuelles qui se trouvent dans la même région peuvent être déplacées vers une autre zone de disponibilité.
Extensions de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les extensions ne sont pas copiées sur une machine virtuelle zonale cible.
Machines virtuelles avec lancement fiablePrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentiellesPrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles de 2e génération (démarrage UEFI)Prise en charge
Machines virtuelles dans des groupes de placement de proximitéPrise en chargeLe groupe de placement de proximité source (PPG) n’est pas conservé dans la configuration zonale.
VM spot (machines virtuelles de basse priorité)Prise en charge
Machines virtuelles avec hôtes dédiésPrise en chargeL’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activéePrise en charge
Machines virtuelles créées à partir d’images de la Place de marchéPrise en charge
Machines virtuelles créées à partir d’images personnaliséesPrise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)Prise en charge
Stratégies RBAC de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible.
Machines virtuelles utilisant l’accélération réseauPrise en charge

Pourquoi migrer dans une Zone de disponibilité Azure ?

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

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

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

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

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la bascule d’une VM dans une zone d’Azure, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle non Zonée (ou Régionale).

Etape I – Préparation de la VM Régionale :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant aucune redondance :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquer les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

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

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

Ouvrez une ou plusieurs applications en enregistrant le travail effectué :

Notre première machine virtuelle non-zonée ou régionale est maintenant opérationnelle. Nous pouvons dès à présent lancer le processus de migration vers la zone souhaitée.

Etape II – Déplacement de la VM Régionale dans une Zone :

Pour commencer ce processus, rendez-vous dans l’un des 2 menus suivants :

  • Cliquez sur le menu à gauche appelé Disponibilité + dimensionnement.
  • Cliquez sur le bouton d’édition à droite pour modifier la Zone de disponibilité.

Cliquez-ici pour démarrer le processus de migration :

Choisissez la zone cible pour la migration :

Il est possible que certaines zones cibles vous soit refusées pour des questions de capacités.

Attendez environ 2-3 minutes afin qu’Azure mette en place les droits RBAC nécessaires pour procéder à la migration :

Une notification Azure apparaît également :

Un nouveau groupe de ressources est créé par cette même occasion :

Des droits RBAC sont également générés au niveau de la souscription Azure concernée :

Une fois le traitement terminé, l’écran suivant apparait, modifiez les champs au besoin :

Dans mon cas, j’ai modifié les valeurs suivantes, puis j’ai cliqué sur Valider :

  • Création d’un nouveau groupe de ressources
  • Création de nouvelles ressources pour tous les objets existants
  • Modification des noms des ressources

La validation entraine une seconde vérification des paramètres modifiés :

Une nouvelle notification Azure apparait indiquant que le traitement est en cours :

Environ 30 secondes plus tard, le traitement de validation se termine :

Lancez le déplacement des ressources en cochant la case ci-dessous, puis en cliquant sur Déplacer :

Le traitement démarre et vous informe que celui-ci durera plusieurs minutes :

Le nouveau groupe de ressources Azure se créé avec les ressources commencent également à y apparaître :

La session de bureau à distance ouverte via Azure Bastion sur la première machine virtuelle se ferme, comme attendu :

Un rapide contrôle du statut de la première machine virtuelle nous montre que cette dernière s’est bien arrêtée :

Le groupe de ressource créé par le service de déplacement nous montre la présence d’une collection de points de restauration :

Il s’agit d’un snapshot de la VM créé provisoirement.

Celle-ci contient bien un point de restauration lié au traitement de migration de la VM :

Environ 5 minutes plus tard, l’écran nous indique que le traitement est terminé. On y apprend également plusieurs choses :

  • La première machine virtuelle a bien été arrêtée, mais n’a pas été supprimée
  • La seconde machine virtuelle est bien démarrée et est localisée dans la zone 3

Des consignes post-déploiement sont même affichées afin de vous guider sur la suite :

Le nouveau groupe de ressources créé par la migration montre bien toutes les ressources configurées selon les options renseignées :

De retour dans le groupe de ressources précédent, la collection des points de restauration a disparu après la migration :

Etape III – Contrôle de la VM zonée :

Les deux machines virtuelles sont bien présentes et visibles, cliquez sur la nouvelle VM :

Vérifiez la présence de la zone 3, puis cliquez sur le Editer :

Microsoft vous indique qu’il n’est pas encore possible de déplacer des ressources entre les zones dans une région Azure :

Cette information de zone de notre machine virtuelle est aussi disponible ici :

Comme un nouveau réseau virtuel a été recréé dans mon exemple, pour me connecter en RDP, je dois effectuer une des actions suivantes :

  • Redéployer un service Azure Bastion
  • Utiliser l’adresse IP publique
  • Appairer les 2 réseaux virtuels entre eux

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la première VM :

Vérifiez la présence du travail effectué précédemment :

Etape IV – Nettoyage des ressources non zonées :

Important : l’infrastructure existante telle que les VNET, les sous-réseaux, les NSG, les LB, … tirent déjà parti d’une configuration zonale, nous aurions pu les garder au lieu d’en recréer.

Si tout est OK pour vous, il ne vous restera qu’à supprimer les deux groupes de ressources suivants :

  • Groupe de ressources contenant l’ancienne machine virtuelle
  • Groupe de ressource contenant les composants liés à la migration

La suppression d’un groupe de ressources Azure s’effectue très simplement :

Confirmez l’ordre de suppression :

Conclusion

Microsoft automatise tous les jours un peu plus certaines tâches manuelle au fil des améliorations faites à Azure. Tous les gains d’efficacité doivent également profiter aux ressources déjà déployées.

On pourra peut-être bientôt voir le même type de processus automatisé intégrer des machines virtuelles existantes dans des Availability Sets ou des Proximity placement groups 😎

Updatez vos VMs vers Windows Server 2022

La date 10 octobre 2023 arrive à grand pas ! Non ce n’est pas l’anniversaire d’un de vos proche que vous auriez oublié … mais bien la Fin de support programmée pour Windows Server 2012 et 2012R2. A partir de cette date, plus aucune mise à jour de sécurité ne sera disponible sans l’achat des ESUs (Extended Security Updates), ou suite à une migration vers Azure ou Azure Stack HCI (solution de Cloud hybride proposé par Microsoft). 😥😥

0
Years
:
0
Months
:
0
J
:
0
H
:
0
M
:
0
S

Pour continuer de plomber l’ambiance, voici d’ailleurs le calendrier des échéances passées et futures :

Que peut-on faire dans ce cas ?

Comme déjà indiqué dans cet article, plusieurs solutions s’offrent déjà à vous :

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

Un article dédié aux ESUs devrait arriver sous peu, tandis que 2 autres concernant la migration vers Azure existent déjà :

Il nous reste donc à parler de la mise à jour de l’OS lui-même. Cela tombe bien, car Dean Cefola de l’Azure Academy vient justement de publier une vidéo traitant de ce sujet :

Important : Bien évidement, les opérations décrites dans cette vidéo et dans mon article ne concernent que la seule mise à jour de l’OS. Il est certain que tous les projets comporteront éventuellement une migration vers le Cloud, mais également d’innombrable tests de compatibilité pour les applications déjà en place.

Aussi, je vous propose dans cet article de vous intéresser aux différentes méthodes de mise à jour possibles et décrites par Dean. Voici les grandes étapes de cet exercice :

Ces étapes sont également disponibles dans l’article de Microsoft Learn :

Une mise à niveau sur place vous permet de passer d’un ancien système d’exploitation à un plus récent, tout en conservant inchangés vos paramètres, vos rôles serveur et vos données. Cet article vous explique comment faire passer vos machines virtuelles Azure à une version ultérieure de Windows Server en utilisant une mise à niveau sur place.

Microsoft Learn

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

Renseignez les informations de base relatives à votre VM en choisissant bien une image Windows Server 2012 R2 :

Définissez un compte administrateur local, bloquer les ports entrants (nous utiliserons le service Azure Bastion), puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Créez un nouveau réseau virtuel, retirez l’adresse IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources de la VM, puis attendez environ 2 minutes :

Sans attendre que le déploiement soit entièrement terminé, il vous est possible, depuis le réseau virtuel Azure de déployer le service Azure Bastion :

Inutile d’attendre qu’Azure Bastion soit déployé pour continuer cet exercice :

Continuez en déployant 3 autres machines virtuelles Azure afin de pouvoir effectuer les 4 tests. Vous devriez avoir les VMs suivantes :

  • Windows Server 2012R2 x 3
  • Windows Server 2016 x 1

Notre environnement de départ est maintenant en place, nous allons pouvoir préparer nos VMs à installer la mise à jour OS Windows Server 2012.

Etape II – Sauvegarde et Préparation :

Mais avant cela, il est vivement conseillé de faire une sauvegarde. Depuis la machine virtuelle de votre choix, il est facile de faire une sauvegarde d’un disque via la fonction Snapshot.

Pour cela, recherchez le disque OS d’une VM de test, puis cliquez dessus :

Sur ce disque OS, cliquez-ici pour créer un snapshot de celui-ci :

Donnez-lui un nom et une performance, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du snapshot de la VM, puis attendez environ 30 secondes :

Le snapshot est maintenant visible comme un élément indépendant de la machine virtuelle Azure. Nous nous en servirons plus tard dans le cadre d’une restauration vers Windows Server 2012R2 :

Comme le rappelle la documentation Microsoft, la mise à niveau sur place nécessite l’ajout d’un second disque contenant les éléments d’installation.

Depuis le portail Azure, cliquez sur Azure Cloud Shell, puis configurez-le à votre guise :

Une fois Azure Cloud Shell démarré en mode PowerShell, lancez le script ci-dessous en prenant soin de modifier si besoin le groupe de ressources et la région Azure :

#
# Customer specific parameters 

# Resource group of the source VM
$resourceGroup = "vmmigrate-rg"

# Location of the source VM
$location = "WestEurope"

# Zone of the source VM, if any
$zone = "" 

# Disk name for the that will be created
$diskName = "WindowsServer2022UpgradeDisk"

# Target version for the upgrade - must be either server2022Upgrade or server2019Upgrade
$sku = "server2022Upgrade"


# Common parameters

$publisher = "MicrosoftWindowsServer"
$offer = "WindowsServerUpgrade"
$managedDiskSKU = "StandardSSD_LRS"

#
# Get the latest version of the special (hidden) VM Image from the Azure Marketplace

$versions = Get-AzVMImage -PublisherName $publisher -Location $location -Offer $offer -Skus $sku | sort-object -Descending {[version] $_.Version	}
$latestString = $versions[0].Version


# Get the special (hidden) VM Image from the Azure Marketplace by version - the image is used to create a disk to upgrade to the new version


$image = Get-AzVMImage -Location $location `
                       -PublisherName $publisher `
                       -Offer $offer `
                       -Skus $sku `
                       -Version $latestString

#
# Create Resource Group if it doesn't exist
#

if (-not (Get-AzResourceGroup -Name $resourceGroup -ErrorAction SilentlyContinue)) {
    New-AzResourceGroup -Name $resourceGroup -Location $location    
}

#
# Create Managed Disk from LUN 0
#

if ($zone){
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
                                   -CreateOption FromImage `
                                   -Zone $zone `
                                   -Location $location
} else {
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
                                   -CreateOption FromImage `
                                   -Location $location
} 

Set-AzDiskImageReference -Disk $diskConfig -Id $image.Id -Lun 0

New-AzDisk -ResourceGroupName $resourceGroup `
           -DiskName $diskName `
           -Disk $diskConfig

Note : J’ai également modifié le script de Microsoft pour créer le disque en Standard SSD et non en Standard HDD. Cela me permet d’activer la fonction de disque partagé pour pouvoir l’utiliser en simultané sur 3 VMs maximum :

Lancez le script, attendez environ 30 secondes, puis constatez le succès de déploiement de celui-ci :

Sur ce nouveau disque, activez la fonction de disque partagé afin de l’utiliser sur plusieurs VMs :

Retournez sur votre première machine virtuelle afin de l’ajouter en tant que disque de données, puis cliquez sur Appliquer :

Faites-en de même pour une seconde machine virtuelle :

Enfin, faites-en de même pour une troisième machine virtuelle :

Nos 3 premières virtuelles sous Windows Server 2012R2 sont enfin prêtes. Il ne nous reste qu’à lancez les installations de Windows Server 2022 sous différentes formes.

Etape III – Tests d’installation sur place de Windows Server 2022 :

Test A – Windows Server 2012R2 + Installation GUI :

Commençons par l’installation depuis l’interface GUI.

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Constatez la présence du disque F, correspondant au média d’installation de Windows Server 2022 :

Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable

Attendez environ 1 minute que l’installation se mette en route :

L’installation passe en revue la configuration de votre machine virtuelle :

Attendez encore une fois une minute environ :

Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :

Attendez encore une fois une minute environ :

L’installation se poursuit en vous avertissant de redémarrages possibles :

L’utilisateur est naturellement déconnecté durant la suite du processus de mise à jour :

Cliquez sur Reconnecter et attendez environ 15 bonnes minutes que l’installation se termine :

Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre première machine virtuelle est bien mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un second cas de mise à jour lancée depuis le portail Azure.

Test B – Windows Server 2012R2 + Installation via Azure Run Command :

Sur votre seconde machine virtuelle de test, rendez-vous dans le menu suivant :

Lancez la commande suivante, puis cliquez sur Exécuter :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet

Attendez environ 15 minutes, sans vous fier au statut Complet de l’écran ci-dessous :

Suivez si besoin la charge CPU de votre VM depuis la fenêtre des métriques :

Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre seconde machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un troisième cas de mise à jour lancée depuis une extension de machine virtuelle.

Test C – Windows Server 2012R2 + Installation via Virtual Machine Extension :

Préparer localement un fichier de script PS1 avec le code suivant :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet

Sur votre troisième machine virtuelle de test, rendez-vous dans le menu suivant :

Choisissez Custom Script Extension, puis cliquez sur Suivant :

Cliquez-ici :

Choisissez le compte de stockage utilisé pour Azure Cloud Shell :

Créez un nouveau conteneur pour le stockage objet :

Nommez-le, puis cliquez sur Créer :

Téléversez votre script :

Sélectionnez votre script :

Cliquez-ici :

Attendez que le déploiement du script se termine :

Suivez si besoin son statut :

Environ 15 minutes plus tard, le statut du script est terminé :

Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre troisième machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un dernier cas de mise à jour lancée depuis une machine virtuelle déjà sous Windows Server 2016.

Test D – Windows Server 2016 + Installation GUI :

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable

Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :

L’installation se poursuit en vous avertissant de redémarrages possibles :

Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre machine virtuelle en 2016 est correctement mise à jour en version Windows Server 2022.

Etape IV – Retrait du disque d’installation :

Une fois l’installation terminée, il ne nous reste plus qu’à retirer le disque d’installation monté sur les machines virtuelles mises à jour :

Cliquez sur Appliquer :

Attendez quelques secondes la notification Azure :

Constatez la disparition du disque F :

Etape V – Restauration de la sauvegarde :

Dans le cas d’un bug au moment de la mise à jour ou après tout autre déconvenue, il est possible de repartir du snapshot généré avant la mise à jour.

Commencez par éteindre la machine virtuelle à restaurer :

Attendez quelques secondes la notification Azure :

Depuis le snapshot, cliquez-ici pour créer un nouveau disque OS :

Nommez-le, choisissez sa taille et sa performance, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du disque :

Retournez sur une des machines virtuelles de test, puis cliquez-ici pour intervertir les disques OS :

Choisissez le nouveau disque, puis lancez le traitement en cliquant sur OK :

Attendez quelques secondes la notification Azure :

Redémarrer la machine virtuelle restaurée :

Ouvrez une session via Azure Bastion :

Attendez la fin de chargement de session :

Constatez le retour à l’ancienne version de Windows Server depuis Server Manager :

Conclusion

Le processus de mise à jour depuis une VM déjà sur Azure vers une version plus récente de Windows Server est des plus simples. Nul doute que la mise à jour de l’OS est la partie émergée de l’iceberg. D’autres tests avant la mises à jour devront être effectués pour vérifier la bonne compatibilité des applications et des services installés.

Migrez votre 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 suivante 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) :

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 :