Catégorie : Modern Work Place

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.

Autopilot v2 💪💻🚨

Vous commencez enfin à maîtriser le service Autopilot de Microsoft et vous vous en servez déjà pour déployer vos postes ? Cela tombe très bien ! Microsoft vient justement de sortir il y a quelques mois la Préparation de l’appareil Windows Autopilot. Peut-on parler de cette nouvelle fonctionnalité comme d’un Autopilot en version 2 ? Oui et non, mais cela va encore plus démocratiser Intune auprès des services IT.

Cet article est donc une suite logique à un autre article détaillant la méthode Autopilot v1, déjà en place depuis assez longtemps. Au travers de ce nouvel écrit, nous allons tester l’intégration d’un PC via cette nouvelle méthode Autopilot v2, dont le nom officiel chez Microsoft est Préparation de l’appareil Windows Autopilot.

Quelles sont les différences entre Autopilot v1 et Autopilot v2 ?

Le fait de les appeler v1 et v2 un choix personnel afin de gagner en clarté, ce qui ne veut pas dire que la seconde est un remplacement complet de la première. Voici d’ailleurs une comparaison v1/v2 rédigée par Microsoft :

FonctionnalitéWindows Autopilot
préparation de l’appareil (Autopilot v2)		Windows Autopilot (Autopilot v1)
FonctionnalitésPrise en charge des environnements Government Community Cloud High (GCCH) et ministère de la Défense (DoD). Expérience d’approvisionnement plus rapide et plus cohérente. Informations de surveillance et de résolution des problèmes en quasi-temps réel.Prise en charge de plusieurs types d’appareils (HoloLens, Salle de réunion Teams). De nombreuses options de personnalisation pour l’expérience d’approvisionnement.
Modes pris en chargePiloté par l’utilisateur;Piloté par l’utilisateur; Préprovisionné. Déploiement automatique. Appareils existants.
Types de jointure pris en chargeRejoindre Microsoft Entra.Rejoindre Microsoft Entra.
Jointure hybride Microsoft Entra.
Inscription de l’appareil requise ?Non.Oui.
Que doivent configurer les administrateurs ?Stratégie de préparation des appareils Windows Autopilot. Groupe de sécurité de l’appareil avec le client d’approvisionnement Intune en tant que propriétaire.Profil de déploiement Windows Autopilot. Page d’état d’inscription (ESP).
Quelles configurations peuvent être fournies lors de l’approvisionnement ?Basé sur l’appareil uniquement pendant l’expérience out-of-box (OOBE).Jusqu’à 10 applications essentielles (métier), Win32, Microsoft Store, Microsoft 365). Jusqu’à 10 scripts PowerShell essentiels.Basé sur l’appareil pendant l’ESP de l’appareil. Basé sur l’utilisateur pendant l’ESP utilisateur. N’importe quel nombre d’applications.
Résolution des problèmes de création de rapports &Rapport de déploiement de la préparation de l’appareil Windows Autopilot : Affiche tous les déploiements de préparation des appareils Windows Autopilot. Davantage de données disponibles. Quasiment en temps réel.Rapport de déploiement Windows Autopilot : Affiche uniquement les appareils inscrits sur Windows Autopilot. Pas en temps réel.
Prend en charge les applications métier et Win32 dans le même déploiement ?Oui.Non.
Versions prises en charge de WindowsWindows 11, version 23H2 avec KB5035942 ou version ultérieure. Windows 11, version 22H2 avec KB5035942 ou version ultérieure.Toutes les versions actuellement prises en charge du canal de disponibilité générale De Windows 11.Toutes les versions actuellement prises en charge du canal de disponibilité générale Windows 10.

Mais cette nouvelle méthode pourrait correspondre à certains scénarios comme le suggère Microsoft :

Conditions requisesWindows Autopilot
préparation de l’appareil (Autopilot v2)		Windows Autopilot
(Autopilot v1)
Government Community Cloud High (GCCH) et
Environnements du ministère de la Défense (DoD)		✅❌
Scénario piloté par l’utilisateur✅✅
Scénario pré-provisionné❌✅
Scénario de déploiement automatique❌✅
Scénario d’appareils existants❌✅
Prise en charge de la réinitialisation d’Autopilot❌✅
Jonction Microsoft Entra✅✅
Jonction Microsoft Entra hybride❌✅
Réinitialisation de Windows Autopilot❌✅
Windows 11✅✅
Windows 10❌✅
Déployer des applications Win32 et métier
dans le même déploiement		✅❌
Configuration et expérience de déploiement plus simples✅❌
Personnalisation étendue du déploiement
et expérience OOBE		❌✅
Aucune exigence de pré-phaser les appareils✅❌
Installer plus de 10 applications pendant OOBE❌✅
Exécuter plus de 10 scripts PowerShell pendant OOBE❌✅
Surveillance en quasi-temps réel✅❌
Empêcher l’utilisateur d’accéder au Bureau jusqu’à ce que
les configurations basées sur l’utilisateur sont appliquées		❌✅
Prise en charge d’HoloLens❌✅
Prise en charge des salles de réunion Teams❌✅
Interface de configuration du microprogramme d’appareil
(DFCI) Prise en charge de la gestion		❌✅
Autopilot dans la cogestion❌✅

Pourquoi changer ce qui marche déjà ?

Comme le rappel l’excellent billet écrit sur le site de Synapsys, Microsoft a souhaité faire évoluer son service Autopilot créé en 2017 afin de pouvoir supporter un plus grand nombre d’appareils. Cela va permettre de gérer le provisionnement des Cloud PC Windows 365 ou pour des clients dont le tenant est sur une instance Gov du Cloud Microsoft :

Windows Autopilot Device Preparation vise à simplifier encore plus le déploiement des périphériques, en optimisant le temps global de préparation de celui-ci et en améliorant notamment la résolution des problématiques qui peuvent survenir pendant le déploiement ainsi que le reporting. 

Synapsys-groupe

Et bien sûr, plus besoin du hash 😎 :

La grosse nouveauté comparée à Windows Autopilot est qu’il n’est plus nécessaire d’importer le hash matériel pour pouvoir bénéficier du service. Autre nouveauté, le profil de déploiement sera à déployer sur un profil utilisateur et non machine. 

Synapsys-groupe

Ai-je besoin de licences spécifiques pour Autopilot v2 ?

Comme il est rappelé dans la documentation Microsoft, Autopilot v2 a besoin des mêmes licences que pour Autopilot v1. Voici une liste non exhaustive de licences ou combinaison de licences possibles :

  • Licence Microsoft 365 Business Premium
  • Licence Microsoft 365 F1 ou F3
  • Licence Microsoft 365 Academic A1, A3 ou A5
  • Licence Microsoft 365 Entreprise E3 ou E5
  • Licence Enterprise Mobility + Security E3 ou E5
  • Licence Intune pour l’éducation
  • Licence ID Microsoft Entra P1 ou P2 + Licence Microsoft Intune

Afin de se faire une meilleure idée sur Autopilot v2, je vous propose un petit exercice à réaliser sur une souscription Azure.

Dans cet exercice, nous allons effectuer les étapes suivantes :

Microsoft a même mis à disposition un très bon tutoriel pour Autopilot v2 juste ici :

Etape 0  –  Rappel des prérequis :

Afin de tester la fonctionnalité d’intégration proposée via Autopilot v2, nous allons avoir besoin de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une ou des licences contenant Intune et Azure AD Premium P1
  • Une Image OS de Windows 11, version 22H2 ou 23H2 générée après avril 2024 ou avec le KB5035942

Etape I – Configurer l’inscription automatique Windows à Intune :

Commençons par la configuration sur Entra ID.

Pour que la préparation des appareils Windows Autopilot (Autopilot v2) fonctionne, les appareils doivent être en mesure de s’inscrire automatiquement dans Intune. L’inscription automatique des appareils dans Intune peut être configurée automatiquement dans le portail Azure

Microsoft Learn

La méthode d’inscription à Intune avec Autopilot v2 ne diffère pas de la première : il est nécessaire de configurer une inscription automatique à Intune depuis le portail Entra ID.

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis cliquez sur cela :

Définissez le périmètre de l’inscription automatique MDM à Intune, puis cliquez sur Sauvegarder :

Restons sur le portail d’Entra ID afin d’autoriser les utilisateurs à joindre des machines à Intune.

Etape II – Autoriser les utilisateurs à joindre des appareils :

Pour rappel, il existe plusieurs types de jointures possibles à Entra ID, dont voici un lien vers un précédent article. Avec Autopilot v2, les utilisateurs ont toujours besoin d’être autorisé à joindre des postes à Entra ID.

Pour que la préparation des appareils Windows Autopilot fonctionne, les utilisateurs doivent être autorisés à joindre des appareils à l’ID Microsoft Entra.

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis activez cette option :

Continuons avec la création d’un premier groupe Entra ID dédié aux postes Intune.

Etape III – Créer un groupe d’appareils Entra ID :

La préparation des appareils Windows Autopilot utilise un groupe d’appareils dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Le groupe d’appareils spécifié dans la stratégie de préparation des appareils Windows Autopilot est le groupe d’appareils dans lequel les appareils sont ajoutés automatiquement pendant le déploiement de la préparation de l’appareil Windows Autopilot

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis créer un groupe dédié aux appareils automatiquement inscrits par Autopilot v2 :

Ajoutez le propriétaire Intune Provisioning Client ou avec son principal de service dont l’ID est le suivant : f1346770-5b25-470b-88bd-d5744ab7952c :

N’ajoutez aucun membre manuellement, puis cliquez sur Créer :

Continuons avec la création d’un second groupe Entra ID dédié aux utilisateurs Intune.

Etape IV – Créer un groupe d’utilisateurs Entra ID :

La préparation de l’appareil Windows Autopilot utilise un groupe d’utilisateurs dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Les utilisateurs membres du groupe d’utilisateurs spécifié dans la stratégie de préparation de l’appareil Windows Autopilot sont les utilisateurs qui reçoivent le déploiement de la préparation de l’appareil Windows Autopilot.

Microsoft Learn

Pour cela, restez sur le même menu qui précédemment d’Entra ID, puis créer un second groupe cette fois dédié aux utilisateurs concernés par le processus Autopilot v2 :

Ajoutez des membres manuellement ou dynamiquement en correspondance avec vos utilisateurs Autopilot v2, puis cliquez sur Créer :

Continuons avec la configuration de postes sous Intune.

Etape V – Affectation de la configuration Intune :

Pendant l’expérience OOBE (out-of-box experience) avant que l’utilisateur final ne soit connecté pour la première fois, la préparation de l’appareil Windows Autopilot permet de déployer jusqu’à :

  • 10 applications managées
  • 10 scripts PowerShell

Pour que les applications s’installent et que les scripts PowerShell fonctionnent correctement, ils doivent être affectés au groupe d’appareils créé pour la préparation des appareils Windows Autopilot.

Microsoft Learn

J’ai souhaité dans mon cas créer différents scénarios d’installation d’applications :

  • Applications intégrées au processus Autopilot v2 :
    • Microsoft Company Portal (Windows Store)
    • Global Secure Access (EXE)
  • Applications obligatoires pour les postes Intune :
    • Google Chrome (MSI)
    • Microsoft 365 Apps (Microsoft 365 Apps)
  • Applications disponibles pour les utilisateurs Intune :
    • Adobe Acrobat Reader DC (Windows Store)
    • Mozilla Firefox (Windows Store)
    • Notepad X (Windows Store)

Pour cela, rendez-vous dans le menu suivant d’Intune, puis rajoutez vos applications concernées :

J’ai également rajouté un script PowerShell, mais que je ne souhaite pas intégrer dans le processus Autopilot v2 car les applications installées ou les scripts PowerShell qui s’exécuteront systématiquement dans un contexte système.

Il ne nous reste maintenant qu’à créer la stratégie de préparation des appareils Windows Autopilot.

Etape VI – Création de la stratégie de préparation des appareils Windows Autopilot :

La stratégie Autopilot spécifie la façon dont l’appareil est configuré pendant l’installation de Windows et ce qui est affiché pendant l’expérience OOBE (out-of-box experience).

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Intune, puis cliquez sur le menu suivant :

Cliquez sur Créer :

Cliquez sur Suivant :

Nommez votre profil, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux postes Intune via Autopilot v2, puis cliquez sur Suivant :

Définissez les paramètres de configuration Autopilot v2 :

Personnalisez l’expérience OOBE :

Ajoutez les applications intégrées dans le processus Autopilot v2 :

Ajoutez si besoin les scripts intégrés dans le processus Autopilot v2, puis cliquez sur Suivant :

Modifiez les tags au besoin, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Cliquez sur Sauvegarder :

La configuration Autopilot v2 est maintenant terminée, il ne nous reste qu’à créer une machine virtuelle Hyper-V sur Azure pour ensuite créer des machines sous Windows 11.

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

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

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

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

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

Rajoutez un second disque pour stocker la machine virtuelle Windows 11, créée plus tard dans notre machine virtuelle hôte (Hyper-V) :

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

Cliquez ensuite sur Suivant :

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

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

Quelques minutes plus tard, cliquez ici pour voir votre machine virtuelle Hyper-V :

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

Nous allons utiliser Bastion pour nous connecter de façon sécurisée à notre VM hôte (Hyper-V).

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

Peu après, constatez le déploiement réussi d’Azure Bastion via la notification Azure suivante :

Renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

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

Exécutez la commande suivante pour installer les 2 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 :

Lancez la commande suivante pour lancer un redémarrage de votre VM Hyper-V :

Shutdown -R

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

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

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

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

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

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

Depuis la console Server Manager, ouvrez Hyper-V Manager :

Ouvrez le menu suivant :

Contrôlez la présence de votre switch virtuel créé précédemment :

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

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

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

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle Windows 11.

Etape VIII – Création de la machine virtuelle Windows 11 :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows 11 afin d’y installer l’OS.

Toujours sur la machine virtuelle Hyper-V, ouvrez le navigateur internet Microsoft Edge.

Rendez-vous sur la page suivante pour télécharger l’ISO de Windows 11, puis effectuez les actions suivantes :

Choisissez la langue désirée, puis cliquez sur Confirmer :

Cliquez sur la version 64 bits pour lancer le téléchargement :

Attendez quelques minutes pour que le téléchargement de l’ISO se termine :

Depuis votre VM Hyper-V, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows 11 :

Cliquez sur Suivant :

Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :

Pensez à bien sélectionner Génération 2 :

Comme indiqué, cette option ne sera plus modifiable par la suite.

Modifiez la taille de la mémoire vive allouée à la VM Windows 11, puis cliquez sur Suivant :

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

Cliquez sur Suivant :

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

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 11 :

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

Dans la section Sécurité, cochez la case suivante pour activer TPM :

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

Double-cliquez sur votre machine virtuelle Windows 11 :

Cliquez-ici pour lancer le démarrage de la VM Windows 11 :

Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :

Attendez que le chargement se termine :

La machine virtuelle est maintenant prête à recevoir l’OS Windows 11. Suivez toutes les étapes de l’installation pour le configurer et l’installer.

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

Lancez l’installation de Windows 11 :

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

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

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

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

Attendez maintenant que l’installation de Windows 11 commence :

Lancez le redémarrage de la machine virtuelle Windows 11 :

Tout est bon, il ne nous reste plus qu’à voir si nouvelle méthode d’Autopilot v2 prend bien la suite de la configuration une fois l’utilisateur 365 authentifié.

Etape IX – Test Autopilot v2 :

Attendez quelques minutes que le redémarrage se termine :

Une fois l’interface Windows 11 affichée, sélectionnez le pays adapté, puis cliquez sur Oui :

Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :

Ajoutez si besoin un second clavier :

Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour sont disponibles :

Le traitement peut être plus ou moins long :

Un redémarrage est même possible :

Afin que le processus Autopilot v2 fonctionne, configurez votre Windows 11 avec un des utilisateurs appartenant au groupe créé pour les utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Windows 11 se connecte alors au compte 365 pour en comprendre la configuration Autopilot v2 :

Le processus de préparation des appareils Windows Autopilot démarre alors :

Une fois le traitement terminé, cliquez sur Accepter :

Si besoin, déverrouillez la session Windows pour continuer :

Attendez la fin de configuration Windows :

Vous voilà enfin sur le bureau Windows 11 !

Attendez quelques minutes afin de voir le Company Portal s’installer automatiquement :

Le client Global Secure Access, est lui aussi installé automatiquement, ouvrant une fenêtre authentification avec possibilité SSO :

Environ 20 minutes plus tard, d’autres applications comme ceux liés à la suite Office, s’installent également de façon automatique :

Prenons en exemple l’installation manuelle de Mozilla Firefox :

L’installation manuelle via le Company Portal ne prend que quelques secondes :

Et l’application Firefox s’ajoute bien dans menu Démarrer de Windows :

Le script configuré en dehors de la Préparation de l’appareil Windows Autopilot (Autopilot v2) s’exécute bien dans le contexte utilisateur :

Enfin côté portail Intune, Microsoft propose également un nouveau rapport afin de surveiller l’état des déploiements Autopilot v2 :

Conclusion

J’espère que cet article vous aura permis de percevoir les avantages et l’intérêt possible de cette nouvelle méthode Autopilot v2. Bien entendu, et comme le rappelle Microsoft, ce nouveau type de déploiement ne pourra pas encore prendre en compte tous les scénarios ou toutes les configurations.

Windows 365 Cross-region Disaster Recovery (CRDR) !

Comme beaucoup de services Azure en GA, Windows 365 possède lui aussi une SLA. Celle-ci est annoncée à 99.9 %. Pour un utilisateur travaillant dans son Cloud PC, il est essentiel que ce dernier soit hautement disponible pour accomplir ses tâches. Mais si un panne intervient dans un centre de données Microsoft, existe-t-il une option de reprise d’activité après sinistre pour son Cloud PC Windows 365 ? La réponse est … oui !

Avant de s’intéresser à ce nouveau service disponible via une licence add-on, faisons rapidement le tour de ce que propose Microsoft en termes de services pour Windows 365.

Quels sont les engagements Microsoft en termes de SLA ?

Voici un lien officiel Microsoft contenant les SLAs par services. Vous pouvez y télécharger le document Word dans la langue de votre choix :

Dans ce document figure une section dédiée à la SLA du service Windows 365. On y retrouve les engagements Microsoft et les indemnités financières en cas d’indisponibilité :

Quelles sont les mesures de maintien de service dans une licence Windows 365 ?

Sur la page consacrée au Cloud PC de Microsoft, on y retrouve les informations de disponibilités suivantes :

  • 99,9 % des sessions utilisateur Windows 365 Cloud PC hautement disponibles, telles que définies dans le contrat SLA Windows 365.
  • Stockage sur disque avec résilience des objets de données de onze 9.
  • Récupération d’urgence automatisée « dans la zone » pour le calcul.
  • Un objectif de point de récupération de ~0.
Microsoft Learn

Cela nous indique que Microsoft a différents mécanismes possibles dans la même zone pour prévenir des défaillances matérielles :

  • Défaillance CPU/Mémoire
  • Défaillance du réseau
  • Défaillance des disques
  • Défaillance électrique

Il ne semble pas y avoir de surcoût pour profiter de ce premier niveau de protection, et le niveau de RPO est proche de zéro :

La récupération d’urgence Windows 365 automatisée est basée sur une copie à jour du disque du système d’exploitation, avec un RPO de ~0. Par conséquent, le processus de récupération démarre automatiquement, car il n’est pas nécessaire d’accepter la perte de données associée à une récupération dans le passé.

Microsoft Learn

Quid de la SLA dans la gestion des Cloud PC (Intune + Portail) ?

Toujours dans ce même article, Microsoft nous annonce d’autres chiffres sur la gestion Intune des Cloud PC, mais également dans l’accès aux utilisateurs :

Le service de gestion des PC cloud possède une architecture régionalement redondante, conçue pour être hautement disponible, avec une durée de bon fonctionnement cible de 99,99 %. En cas de panne du service de gestion, le service a les objectifs suivants :

  • RTO de < 6 heures.
  • RPO de <30 minutes pour les modifications apportées au service de gestion.
Microsoft Learn

Qu’est que le Cross-region Restore ?

Le service appelé Cross-region Restore est connu de longue date pour la restauration des machines virtuelles Azure au travers du service Recovery Service Vault, quand celui-ci a la fonctionnalité CRR d’activée :

La restauration inter-région peut être utilisée pour restaurer des machines virtuelles Azure dans la région secondaire, qui est une région jumelée à Azure.

Vous pouvez restaurer toutes les machines virtuelles Azure pour le point de récupération sélectionné si la sauvegarde est effectuée dans la région secondaire.

Pendant la sauvegarde, les captures instantanées ne sont pas répliquées dans la région secondaire. Seules les données stockées dans le coffre sont répliquées. Ainsi, les restaurations de la région secondaire sont des restaurations de niveau coffre uniquement. L’heure de restauration de la région secondaire sera presque identique à celle du niveau coffre pour la région principale.

Microsoft Learn

Qu’est que le Cross-region Disaster Recovery (CRDR) pour Windows 365 ?

En ce 1er juillet 2024, Microsoft a annoncé la disponibilité générale de son service Cross-region Disaster Recovery pour Windows 365. Déjà disponible pour un grand nombre de services Azure, cette offre payante permet de disposer d’une sauvegarde de secours sur une seconde région Azure distante :

La récupération d’urgence inter-région de Windows 365 est un service facultatif pour Windows 365 Entreprise qui protège les PC et les données cloud contre les pannes régionales.

Lorsqu’il est activé, il crée des copies temporaires distantes géographiquement des PC cloud accessibles dans la région de sauvegarde sélectionnée. Ces copies permettent d’augmenter la disponibilité et de préserver la productivité.

Microsoft Learn

CRR vs DR vs CRDR ?

Le Cross Region Restore (CRR) et le Disaster Recovery (DR) sont toutes deux des stratégies utilisées pour assurer la continuité des activités et la protection des données, mais elles servent à des fins différentes et sont utilisées dans des scénarios différents :

  • Cross Region Restore (CRR) permet de restaurer des données sauvegardées dans une région secondaire.
  • Disaster Recovery (DR) implique un ensemble de politiques et de procédures pour permettre la récupération synchrone ou la continuation des infrastructures technologiques vitales et des systèmes suite à un désastre.

Le Cross-region Disaster Recovery (CRDR) s’inscrit finalement dans un mélange de ces 2 concepts :

  • Restauration des données sauvegardées dans une région secondaire.
  • Procédure pour permettre la continuation des infrastructures dans une région secondaire.

Quid des RPOs et RTOs ?

Comme le Cross-region Disaster Recovery de Windows 365 fonctionne avec des sauvegardes périodiques et non une synchronisation constante des données, le RPO s’en retrouve impacté :

En cas de panne, le service a les objectifs cibles suivants pour la récupération d’urgence inter-région :

  • RTO de < 4 heures pour les tenants avec moins de 50 000 PC cloud dans une région.
  • RPO de <4 heures.
Microsoft Learn

Note : le délai RPO du CRR dépendra également de la fréquence de sauvegarde configurée dans les paramètres de l’utilisateur des Cloud PCs :

Maintenant que ces concepts ont été annoncés, et afin d’y avoir plus clair, je vous propose un petit exercice sur le Cross-region Disaster Recovery (CRDR) pour Windows 365 :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une licence Microsoft 365
  • Une licence Windows 365 Entreprise
  • Une licence add-on Windows 365 Cross Region Disaster Recovery

Commencez par configurer le service Cross Region Disaster Recovery via le portail Intune.

Etape I – Configuration du CRDR

Rendez-vous sur la page du portail Intune, puis naviguez dans le menu suivant afin d’y retrouver la liste de vos postes Windows 365 :

Rendez-vous dans le menu suivant pour configurer le CRDR :

Cliquez sur la règle de paramètres utilisateurs de votre choix :

Cliquez sur Éditer :

Activez par cette option la fonctionnalité CRDR :

Choisissez le lien réseau correspondant à votre infrastructure, mais également la Géographie et la région Azure où seront créés les Cloud PCs quand le CRDR sera déclenché, puis cliquez sur Suivant :

Cliquez ici pour mettre à jour votre règle utilisateur :

La notification Intune suivante apparaît alors :

Vérifiez que le paramétrage CRDR est bien changé sur votre règle utilisateur :

Toujours sur le portail Intune, rendez-vous dans le rapport suivant afin de voir l’impact sur vos Cloud PCs déjà en place :

Cliquez sur la section suivante afin de comprendre pourquoi une alerte est présente :

Cliquez sur un des Cloud PCs pour comprendre le motif de l’alerte :

Un problème de licence est bien à l’origine de notre alerte :

Comme la majorité des licences, cet add-on a lui-aussi besoin d’être acheté en nombre et assigné aux utilisateurs concernés.

Ouvrez un nouvel onglet vers le portail Entra, puis cliquez sur la licence add-on Windows 365 Cross Region Disaster Recovery :

Assignez cet add-on a un de vos utilisateurs disposant déjà d’une licence Windows 365 :

Attendez quelques minutes, puis retournez sur le rapport afin de constater la disparition de l’alerte sur l’utilisateur en question :

La configuration du CRDR semble terminée, il ne nous reste qu’à tester le service sur notre utilisateur de test pour comprendre en détail la procédure de ce service.

Etape II – Activation du Cross-region Disaster Recovery :

Ouvrez une session sur votre Windows 365, puis rendez-vous sur la page Internet suivante afin de localiser approximativement votre Cloud PC.

Dans mon cas, le résultat nous montre une IP rattachée à la région de Zurich en Suisse. Cette information est cohérente puis que ce Cloud PC est créé dans la région Azure Suisse Nord :

Retournez sur la console Intune, puis activez le service CRDR pour ce Cloud PC via la fonction Bulk :

Renseignez tous les champs, puis cliquez sur Suivant :

Choisissez le Cloud PC dont l’utilisateur possède la licence Windows 365 Cross Region Disaster Recovery, puis cliquez sur Suivant :

Lancez l’activation du CRDR en cliquant sur Créer :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater l’erreur du lancement du CRDR :

Je pense que cela s’explique par l’absence de points de restauration dans la seconde région Azure, et/ou du fait de la configuration très récente.

J’ai donc décidé d’attendre 24-48 heures avant de recommencer la même opération d’activation du CRDR :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater le lancement du CRDR :

Quelques minutes plus tard, la session Windows ouverte sur le Cloud PC concerné se ferme d’elle-même, pour cause d’arrêt de la machine virtuelle :

Retentez d’ouvrir une session Windows 365 via le client Microsoft Remote Desktop :

Le message d’erreur suivant indique que la machine virtuelle du Cloud PC n’est plus accessible :

Actualiser la page du Cloud PC afin d’y constater un changement du statut CRDR :

Quelques minutes plus tard, le statut CRDR est passé en complété :

Retournez sur le rapport Intune appelé Statut de reprise après sinistre des PC Cloud dans toute la région afin d’y constater 2 nouvelles informations :

  • Le démarrage du service CRDR
  • L’expiration de l’instance CRDR dans 7 jours

Sur le client Microsoft Remote Desktop, lancez un rafraîchissement sur le Cloud PC :

Constatez l’apparition d’un second espace de travail contenant un poste appelé Temporary Cloud PC :

Ouvrez une session de bureau à distance sur ce Temporary Cloud PC :

Rendez-vous sur la page Internet suivante afin de localiser approximativement votre Cloud PC temporaire.

Dans mon cas, ce nouveau résultat nous montre une IP rattachée à la France. Cette information est cohérente, puisque le CRDR est configuré sur la région Azure France Central :

La notification Windows suivante nous informe également le caractère temporaire de ce second Cloud PC :

Il ne nous reste plus qu’à désactiver le Cross-region Disaster Recovery afin de voir le retour dans la région Azure d’origine.

Etape III – Désactivation du Cross-region Disaster Recovery :

Comme pour l’activation du CRDR, la désactivation de ce dernier se déclenche via la fonction Bulk :

Cliquez-ici pour ajouter le Cloud PC temporaire concerné par le CRDR :

Choisissez le Cloud PC temporaire créé sur France Central :

Cliquez sur Suivant :

Lancez la désactivation du CRDR en cliquant sur Créer :

La notification Intune suivante apparaît :

Attendez quelques minutes, puis retourner sur la page du Cloud PC afin d’y constater le lancement du failback du CRDR :

Suite à cette opération, une notification Windows nous informe que le Cloud PC temporaire devrait être décommissionné sous peu :

Une seconde notification Windows se fait plus pressante sur le besoin de déconnexion du Cloud PC temporaire :

Quelques minutes plus tard, le statut du failback du CRDR est passé en complété :

Retournez sur le rapport Intune appelé Statut de reprise après sinistre des PC Cloud dans toute la région afin d’y constater 2 nouvelles informations :

  • L’arrêt du service CRDR
  • La suppression de l’expiration du Cloud PC temporaire

Quelques minutes plus tard, la session Windows ouverte sur le Cloud PC temporaire est automatiquement fermée à cause de l’arrêt de la machine virtuelle :

Sur le client Microsoft Remote Desktop, lancez un rafraîchissement sur le Cloud PC temporaire :

Constatez dans le second espace de travail la disparition du poste appelé Temporary Cloud PC :

Ouvrez une session de bureau à distance sur le Cloud PC de base :

Ouvrez à nouveau page Internet suivante.

Dans mon cas, le résultat nous remontre une IP rattachée à la région de Zurich en Suisse. Cette information est cohérente puis que ce Cloud PC de base avait été créé dans la région Azure Suisse Nord :

Conclusion

Contrairement à de nombreuses solutions traditionnelles de récupération après sinistre, Windows 365 Cross-region Disaster Recovery a été conçu pour être configuré et utilisé avec une expérience minimale, voire aucune, en matière de récupération après sinistre. La configuration peut être terminée en quelques minutes.

Windows 365 Cross-region Disaster Recovery est fourni en tant que licence complémentaire aux SKU Windows 365 Entreprise. Aux États-Unis, le prix de l’add-on Windows 365 Cross-region Disaster Recovery est de 5 $ par utilisateur et par mois.

Clonez votre Windows 365

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

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

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

Voici ce que Microsoft en dit en quelques mots :

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

Microsoft Learn

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

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une licence Windows 365

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

Etape I – Environnement Windows 365 de départ :

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

Assignez à cet utilisateur une licence Windows 365 :

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

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

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

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

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

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

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

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

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

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

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

Choisissez parmi les options suivantes :

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

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

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

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

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

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

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

Vérifiez la bonne apparition de celle-ci :

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

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

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

Acceptez en cliquant sur Oui :

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

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

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

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

Lancez l’installation de Google Chrome :

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

Etape II – Sauvegarde du poste Windows 365 :

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

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

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

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

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

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

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

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

Lancez l’assignation RBAC par le bouton suivant :

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

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

Confirmez votre choix en cliquant sur Oui :

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

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

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

Le status du partage est consultable ici :

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

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

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

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

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

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

Cliquez-ici pour créer le disque OS :

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

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

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

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

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

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

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

Cliquez sur Suivant :

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

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

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

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

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

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

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

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

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

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

Constatez la bonne ouverture de votre session Windows :

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

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

Etape IV – Modification de la VM :

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

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

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

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

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

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

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

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

Sysprep /generalize /oobe /mode:vm /shutdown

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

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

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

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

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

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

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

Etape V – Nouvel environnement Windows 365 :

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

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

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

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

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

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

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

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

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

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

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

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

Vérifiez la bonne apparition de celle-ci :

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

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

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

Acceptez en cliquant sur Oui :

Constatez la bonne ouverture de votre session Windows :

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

😎

Troubleshooting – Quelques erreurs possibles :

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

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

Conclusion :

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

Windows Server 2025 🪟

Depuis seulement quelques jours, La nouvelle release de Windows Server s’appelle maintenant Windows Server 2025 ! Seulement disponible via le programme Windows Server Insider, la version Build v26040 de Windows Server 2025 promet de nouvelles fonctionnalités comme le Hotpatching pour tous ou encore Active Directory et SMB en version Next Gen, et sûrement encore plein d’autres à découvrir.

Cette annonce de Windows Server 2025 a été faite sur le site TechCommunity juste ici.

De précédentes annonces concernant Windows Server avaient été annoncées durant le dernier Ignite juste là :

Je ne vais pas rentrer tout de suite dans les détails de Windows Server 2025, que je ne connais pas encore car je ne l’ai pas testé. Mais je trouvais intéressant de partager avec vous une méthode de déploiement facile et rapide du dernier OS de Microsoft sur Azure.

En effet, et comme vous pouvez vous en doutez, ce dernier n’est pas encore directement accessible via le portail Azure lors de la création d’une machine virtuelle.

D’où mon petit exercice très rapide sur le sujet :

Commençons par un bref rappel des prérequis.

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

La suite se passera par l’inscription au programme Windows Insider.

Etape I – Programme Windows Insider :

Afin de récupérer l’image de la dernière version disponible de Windows Server 2025, il est donc nécessaire de s’inscrire au programme Windows Insider (de Windows Server).

La documentation officielle de Microsoft l’explique bien et est accessible via ce lien :

Vous pouvez vous inscrire directement Programme Windows Insider via cette page, en utilisant un compte Microsoft Entra ou même un compte personnel Microsoft :

Lisez les informations du programme, puis acceptez ses termes si vous êtes d’accord :

Cliquez-ici pour rejoindre la page dédiée à Windows Server :

Choisissez la version suivante de Windows Server afin de pouvoir l’installer sous Azure :

Sélectionnez la seule langue disponible actuellement, puis cliquez sur Confirmer :

Cliquez-ici pour commencer le téléchargement du fichier au format VHDX :

Attendez quelques minutes la fin du téléchargement sur votre poste :

Une fois téléchargé, le fichier VHDX doit être converti en VHD pour être exploité sous Azure.

Etape II – Préparation du fichier image VHD :

En effet Azure ne support que le format VHD. Nous allons donc devoir effectuer une conversion de format. Cela est possible facilement en PowerShell.

Note : Pour utiliser la commande Convert-VHD, les outils Hyper-V sont nécessaires.

Ouvrez PowerShell, puis lancez la commande suivante pour convertir le fichier téléchargé au format VHDX en fichier au format VHD :

Convert-VHD –Path c:\2025\Windows_InsiderPreview_ServerDatacenter_Azure_Edition_en-us_VHDX_26040.vhdx –DestinationPath c:\2025\Windows_InsiderPreview_ServerDatacenter_Azure_Edition_en-us_VHDX_26040.vhd -VHDType Fixed

Attendez environ 5 minutes que le traitement de conversion se termine :

Une fois le fichier image converti au format VHD, ouvrez le portail Azure, puis recherchez le Service de stockage :

Créez un nouveau compte de stockage Azure en cliquant ici :

Nommez votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, démarrez la création de la ressource :

Environ 1 minute plus tard, cliquez-ici pour vous connecter au nouveau compte de stockage :

Créez un nouveau contenaire blob :

Nommez-le puis lancez sa création :

Dans ce contenaire blob, cliquez sur Téléverser :

Sélectionnez votre fichier VHD, choisissez le format Page Blob, puis cliquez sur Téléverser :

La notification Azure suivante doit apparaitre :

Suivez l’évolution de l’envoi vers Azure en bas à droite de l’écran :

Attendez environ 15 minutes que l’envoi vers Azure se termine :

Une fois l’envoi vers Azure terminé, cliquez sur votre blob pour en copier l’URL :

Votre source est enfin prête. Nous allons maintenant créer une galerie d’images de VM en faisant appel à notre fichier blob.

Etape III – Création de la galerie d’images :

Pour cela, commencez par rechercher le service Azure suivant :

Créez une nouvelle galerie d’images VM en cliquant ici :

Nommez votre galerie d’images VM, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour démarrer la création de la ressource :

Environ 1 minute plus tard, la galerie d’images VM est créée, puis cliquez ici :

Cliquez-ici pour créer une nouvelle définition d’image VM :

Renseignez tous les champs nécessaires, puis lancez la validation Azure :

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

Environ 2 minutes plus tard, cliquez-ici pour ajouter une nouvelle version :

Cliquez-ici pour ajouter une nouvelle version à votre définition d’images VM :

Renseignez les champs et reprenez pour le disque OS l’URL du blob copiée précédemment :

Lancez la validation Azure :

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

Environ 10 minutes plus tard, cliquez-ici pour retourner sur votre version :

Notre environnement est enfin prêt, nous allons maintenant créer notre première machine virtuelle sous Windows Server 2025.

Etape IV – Création de la machine virtuelle :

Cliquez-ici pour créer une nouvelle machine virtuelle à partir de cette image :

Renseignez tous les champs de base :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

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

Retirez l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour lancer la création de la ressource :

Environ 5 minutes plus tard, cliquez-ici pour consulter la machine virtuelle créée :

Dans la foulée, déployez le service Azure Bastion afin de pouvoir ouvrir une connexion RDP :

Attendez 5 minutes la création du service Azure Bastion :

Etape V – Test et connexion :

Une fois le service Azure Bastion déployé, ouvrez une session RDP par ce dernier :

Définissez la politique d’envoi de données à Microsoft :

Depuis Server Manager, vérifiez la bonne version de votre Windows Server :

Depuis Paramètres, vérifiez la bonne version de votre Windows Server :

De retour sur Azure, profitez-en pour installer Windows Admin Center :

Attendez environ 1 minute que l’extension Windows Admin Center soit installée :

Vérifiez sa bonne installation par cet écran :

Ajoutez votre utilisateur Entra ID le rôle RBAC suivant :

Ajoutez une IP publique et une règle entrante NSG pour pouvoir vous connecter à Windows Admin Center depuis le portail Azure :

Ouvrez une connexion à Windows Admin Center :

Vérifiez la bonne disponibilité des informations via Windows Admin Center :

Redémarrez par le portail Azure votre VM si Windows Admin Center reste trop longtemps sur cette page :

Conclusion

Microsoft continue de faire avancer Windows Server dans sa gamme de produit OS, et promet à coup sûr de belles choses à venir 😎. Quand j’aurais pris le temps de faire mes tests dessus🤣, comptez sur moi pour d’autres articles à suivre !

Microsoft 365 Backup

Une des grandes annonces du dernier Ignite portait sur l’introduction d’une solution native de sauvegarde 365, appelée Microsoft 365 Backup. Attendue depuis de nombreuses années et faisant la part belle aux solutions tierces, voyons ce que ce nouveau venu propose puisque la préversion publique est ouverte depuis maintenant une semaine.

Oui, Microsoft 365 Backup est en préversion depuis une semaine et son déploiement se fait progressivement sur l’ensemble des tenants du Cloud Public de Microsoft. Cette approche est d’ailleurs similaire à celle utilisée lors du déploiement de Microsoft 365 Archive, dont je vous invite à lire l’article ici. Aucune date de GA n’a encore été annoncée si ce n’est pour 2024.

Quelles sont les termes et conditions de Microsoft 365 Backup ?

Le lien officiel Microsoft est disponible juste ici. On peut résumer les points suivants :

  • Fonctionnalités en préversion
  • Microsoft 365 Backup permet de sauvegarder des objets des services suivants :
    • des comptes OneDrive
    • des sites SharePoint
    • des boîtes mails Exchange Online
  • Nécessite une souscription Azure
  • Tarif à la consommation (PAYG) actuel de 0,15 $/Go/Mois

Microsoft a déjà à disposition une première FAQ.

Quelles sont les limites de la préversion de Microsoft 365 Backup ?

Le lien officiel Microsoft est disponible juste là. On peut résumer les points suivants :

  • Performances potentiellement dégradées
  • Une seule police de sauvegarde par service :
    • OneDrive
    • SharePoint
    • Exchange Online
  • Limitations renforcées pour éviter l’engorgement des ressources Microsoft

Combien coûte Microsoft 365 Backup ?

Une sauvegarde IT est rarement gratuite, elle peut même vite représenter des coûts très importants. Pour Microsoft 365 Backup, le seul prix actuel connu est celui de la préversion, à savoir $0.15/Go de données sauvegardées.

Le volume total de données sauvegardées est la somme des boîtes Outlook protégées, des sites SharePoint protégés et des comptes OneDrive protégés.

Pour vous aider à estimer vos coûts, Microsoft a mis un disposition un Calculateur dédié à Microsoft 365 Backup sous format Excel. Vous pouvez alimenter cette feuille Excel en lisant cette notice et en vous basant sur les usages de votre tenant :

Il est à noter que la volume total dépendra également de la rétention de données anciennes sauvegardées. Autrement dit, une grosse boite mail supprimée continuera d’impacter les sauvegardes et donc les coûts sur plusieurs mois.

Existe-t-il des limitations à la sauvegarde / restauration ?

Actuellement, chacun des 3 services dispose des limites suivantes :

  • SharePoint :
    • Fréquences des sauvegardes (< 14 jours) : toutes les 15 minutes
    • Fréquences des sauvegardes (> 14 jours) : toutes les semaines
    • Durée de rétention : 1 année
    • Tâches de restauration actives (max) : 25
    • Sites en cours de restauration dans le cadre de tâches de restauration actives (max) : 1000
    • Nombre total de sites restaurés (actifs et achevés) aujourd’hui (max) : 10000
  • Exchange :
    • Fréquences des sauvegardes : toutes les 10 minutes
    • Durée de rétention : 1 année
    • Tâches de restauration actives (max) : 25
    • Boîtes aux lettres d’utilisateurs restaurées dans le cadre de tâches de restauration actives (max) : 1000
    • Nombre total de boîtes aux lettres restaurées (actives et terminées) aujourd’hui (max) : 10000
  • OneDrive :
    • Fréquences des sauvegardes (< 14 jours) : toutes les 15 minutes
    • Fréquences des sauvegardes (> 14 jours) : toutes les semaines
    • Durée de rétention : 1 année
    • Tâches de restauration actives (max) : 25
    • Comptes en cours de restauration dans les tâches de restauration actives (max) : 1000
    • Nombre total de comptes restaurés (actifs et terminés) (max) : 10000

Pourrons-nous suivre les coûts de Microsoft 365 Backup ?

Mon hypothèse est que les coûts seront visibles de la même manière que les autres ressources Azure, via le Cost Management :

Comme toujours je vous propose de réaliser un petit exercice sur le sujet :

Commençons par un bref rappel des prérequis.

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

Dans mon cas, j’ai utilisé un tenant Microsoft 365 disposant de licences Microsoft 365 E5 issues de la plate-forme CDX. J’y ai ensuite rajouté une souscription Azure MSDN.

Etape I – Préparation de l’environnement Azure :

Avant de pouvoir tester cette fonctionnalité, il est nécessaire de créer un groupe de ressources sur votre souscription Azure pour y stocker les sauvegardes 365.

Pour cela, rendez-vous dans le portail Azure, créez un nouveau groupe de ressources dans la région Azure de votre choix, puis lancez la validation :

Une fois la validation Azure réussie, lancez la création, puis attendez environ 1 minute :

Et c’est tout, rien de plus n’est nécessaire du côté d’Azure ! La suite va se passer du côté de Microsoft 365.

Etape II – Activation de la fonction de sauvegarde :

Afin de configurer la fonction de sauvegarde de Microsoft 365, rendez-vous sur la console d’administration de 365 par ce lien, puis cliquez sur le menu suivant :

Recherchez la rubrique suivante, puis cliquez dessus :

Commencez par cliquez ici pour configurer Syntex, alias SharePoint Premium :

Sélectionnez la souscription Azure de votre choix :

Reprenez le groupe de ressources Azure créé précédemment, puis choisissez la localisation des sauvegardes :

Cochez la case des conditions d’utilisation et de facturation, puis cliquez sur Sauvegardez :

Attendez environ 1 minute que Microsoft finalise la configuration de votre tenant :

La notification suivante apparaît alors sur ce même onglet :

Cliquez ensuite sur ce lien pour visualiser la liste des services disponibles :

Vérifiez que la fonction de sauvegarde est bien présente, puis cliquez dessus :

Activez la fonction de sauvegarde comme ceci :

Confirmez votre choix après avoir lu au besoin les termes et conditions du service :

La mise en route est maintenant terminée, il ne nous reste plus qu’à configurer les polices de sauvegarde en cliquant ici :

Commençons par le service Exchange.

Etape III – Police de sauvegarde Exchange :

Retrouvez toutes les polices de sauvegarde 365 depuis cette page disponible sur la console d’administration :

Cliquez-ici pour configurer la police de sauvegarde d’Exchange :

Cliquez sur Suivant :

Intégrés les comptes Outlook à protéger, puis cliquez sur Suivant :

Prenez en compte la politique de sauvegarde non modifiable, puis cliquez ici pour créer la police :

Attendez quelques secondes pour finaliser la création de la police :

La police est maintenant créée, attendez quelques minutes la mise en application de celle-ci sur votre tenant :

Quelques minutes plus tard, le statut est passé sur actif, cliquez-ici pour voir les options :

Il est possible de mettre en pause la police, cliquez-ici pour rajouter un compte Exchange :

Constatez le nouveau traitement une fois un autre compte exchange rajouté :

Continuons avec la police de sauvegarde SharePoint.

Etape IV – Police de sauvegarde SharePoint :

Cliquez-ici pour configurer la police de sauvegarde SharePoint :

Cliquez sur Suivant :

Intégrés les sites SharePoint à protéger, puis cliquez sur Suivant :

Prenez en compte la politique de sauvegarde non modifiable, puis cliquez ici pour créer la police :

Attendez quelques secondes pour finaliser la création de la police :

La police est maintenant créée, cliquez-ici pour revenir sur la page précédente :

Attendez quelques minutes la mise en application de celle-ci sur votre tenant :

Terminons par la police de sauvegarde OneDrive.

Etape V – Police de sauvegarde OneDrive :

Cliquez-ici pour configurer la police de sauvegarde OneDrive :

Cliquez sur Suivant :

Intégrés les comptes OneDrive à protéger, puis cliquez sur Suivant :

Prenez en compte la politique de sauvegarde non modifiable, puis cliquez ici pour créer la police :

Attendez quelques secondes pour finaliser la création de la police :

La police est maintenant créée, cliquez-ici pour revenir sur la page précédente :

La police est maintenant créée, attendez quelques minutes la mise en application de celle-ci sur votre tenant :

Commençons les tests de restauration.

Etape VI – Restauration de mails Outlook :

Commençons par supprimer quelques mails depuis Outlook stockés dans la boite de réception :

Supprimez ces mêmes mails Outlook depuis la corbeille :

Supprimez enfin ces mêmes mails Outlook depuis la seconde corbeille :

Attendez au minimum 10 minutes

Retournez sur la page Microsoft 365 Backup du portail d’administration 365, puis cliquez-ici pour entamer la restauration :

Conservez le choix du service à restaurer, puis cliquez sur Suivant :

Choisissez les objets à restaurer parmi la liste disponible, puis cliquez sur Suivant :

Définissez le fuseau horaire et la sauvegarde la plus proche, puis cliquez sur Suivant :

Affinez votre sauvegarde en cliquant ici :

Choisissez un point de restauration antérieur à l’évènement, puis cliquez sur Sauvegarder :

Cliquez sur Suivant :

Choisissez la méthode de restauration, puis cliquez sur Suivant :

Cliquez-ici pour démarrer le travail de restauration :

La tâche de restauration est prise en compte, cliquez-ici pour revenir sur la page précédente :

Il ne reste plus qu’à patienter :

Quelques minutes plus tard, le statut de la restauration a changé :

Le dossier est bien visible côté utilisateur et ce dernier contient bien les mails précédemment supprimés :

Continuons avec la restauration SharePoint.

Etape VII – Restauration de sites SharePoint :

Retournez sur la page Microsoft 365 Backup du portail d’administration 365, puis cliquez-ici pour entamer la restauration :

Conservez le choix du service à restaurer, puis cliquez sur Suivant :

Choisissez les objets à restaurer parmi la liste disponible, puis cliquez sur Suivant :

Définissez le fuseau horaire et la sauvegarde la plus proche, puis cliquez sur Suivant :

Affinez si besoin votre sauvegarde en cliquant ici :

Choisissez la méthode de restauration, puis cliquez sur Suivant :

Cliquez-ici pour démarrer le travail de restauration :

La tâche de restauration est prise en compte, cliquez-ici pour revenir sur la page précédente :

Il ne reste plus qu’à patienter :

Quelques minutes plus tard, le statut de la restauration a changé :

Un tour dans la console d’administration SharePoint nous affiche le nouveau site restauré :

Le site SharePoint est bien accessible depuis son URL en mode lecture seule :

Dans cette méthode, il ne restera qu’aux utilisateurs de récupérer le contenu voulu.

Terminons avec la restauration OneDrive.

Etape VIII – Restauration de comptes OneDrive :

Retournez sur la page Microsoft 365 Backup du portail d’administration 365, puis cliquez-ici pour entamer la restauration :

Conservez le choix du service à restaurer, puis cliquez sur Suivant :

Choisissez les objets à restaurer parmi la liste disponible, puis cliquez sur Suivant :

Définissez le fuseau horaire et la sauvegarde la plus proche, puis cliquez sur Suivant :

Affinez si besoin votre sauvegarde en cliquant ici :

Choisissez la méthode de restauration, puis cliquez sur Suivant :

Cliquez-ici pour démarrer le travail de restauration :

La tâche de restauration est prise en compte, cliquez-ici pour revenir sur la page précédente :

Il ne reste plus qu’à patienter :

Quelques minutes plus tard, le statut de la restauration a changé :

Un clic sur cette ligne ne semble pas encore afficher l’URL du site OneDrive recréé :

Je suis passé par le script PowerShell suivant pour obtenir l’URL du site restauré :

$TenantUrl = Read-Host "Enter the SharePoint admin center URL"
$LogFile = [Environment]::GetFolderPath("Desktop") + "\OneDriveSites.log"
Connect-SPOService -Url $TenantUrl
Get-SPOSite -IncludePersonalSite $true -Limit all -Filter "Url -like '-my.sharepoint.com/personal/'" | Select -ExpandProperty Url | Out-File $LogFile -Force
Write-Host "Done! File saved as $($LogFile)."

L’URL du nouveau site était donc écrite comme ceci :

https://XXXX.sharepoint.com/personal/YYYYYYYR0

Le nouveau site OneDrive était bien accessible et présentant le même contenu :

Cette seconde commande PowerShell permet de supprimer le site restauré :

Remove-SPOSite -Identity "https://XXXXX-my.sharepoint.com/personal/YYYYYYYR0" -NoWait

Conclusion

Cette nouvelle approche simplifiée de la sauvegarde de données 365 devraient faciliter la vie à pas mal de monde, que ce soient les utilisateurs ou les équipes IT. Même si les options sont encore assez limitées dans cette préversion, nul doute que d’autres vont être proposées afin d’être aussi compétitif que les leaders du marché 😎

Microsoft 365 Archive 💾

Oubliez Syntex, appelez-le maintenant SharePoint Premium ! Plein de nouvelles fonctionnalités ont été annoncées durant cette année folle, et se finalement sont concrétisées durant le Microsoft Ignite de 2023. Office 365 n’est d’ailleurs pas en reste avec Copilot, Archivage ou encore Sauvegarde.

Dans cette article, je vous propose de parler de l’archivage de site SharePoint Online. Fonctionnalité sans aucun doute très attendue depuis un certain temps !

Mais avant de tester l’archivage sur un tenant de test, je vous propose de parcourir quelques notions importantes.

Quelles sont les limites d’espace de SharePoint Online ?

L’espace disponible dédié aux sites SharePoint Online est facilement consultable depuis la console d’administration du même nom :

Le volume total va dépendre du nombre de licences 365 présentes sur le tenant. Une page d’information Microsoft est disponible juste ici.

Que doit-on faire si l’espace de SharePoint Online est entièrement consommé ?

Une fois l’espace SharePoint Online entièrement consommé jusqu’à l’os, trois options s’offraient alors à vous :

Une licence d’espace comme celle ci-dessus apporte seulement 1 Go de donnée SharePoint Online supplémentaire, pour un mois ou une année, selon la période d’engagement souscrite.

Le prix public de celle-ci est environ 0.20 €, ce qui n’est pas donné quand on parle très souvent de To de données.

Qu’est-ce que SharePoint Premium ?

Le terme de SharePoint Premium a été officialisé durant le Microsoft Ignite 2023 :

Aujourd’hui, nous sommes ravis de présenter le nouveau SharePoint Premium, notre plateforme avancée de gestion de contenu et d’expériences et notre prochaine évolution pour Syntex. SharePoint Premium apporte l’IA, l’automatisation et une sécurité accrue à vos expériences de contenu, au traitement et à la gouvernance.

Avec SharePoint Premium, nous ferons la transition entre les services déjà publiés dans le cadre de Syntex, y compris SharePoint Advanced Management, pour rejoindre la famille croissante des services SharePoint, ainsi que de toutes nouvelles expériences de contenu.

Microsoft Tech Community

Qu’est-ce que Microsoft 365 Archive ?

SharePoint Online est devenu un outil indispensable dans la collaboration entre employés. Comme toute donnée, l’archivage de données anciennes est souvent nécessaire pour plusieurs raisons (légale, fiscale, IT, …)

C’est ici qu’intervient Microsoft 365 Archive :

Microsoft 365 Archive offre un stockage économique pour les sites SharePoint inactifs.

Votre organization peut avoir besoin de conserver des données inactives ou vieillissantes pendant de longues périodes au cas où vous devrez les récupérer ultérieurement.

Microsoft 365 Archive vous permet de conserver ces données inactives en les déplaçant dans un niveau de stockage froid (archive) dans SharePoint. Toutes les données archivées avec Microsoft 365 Archive auront les mêmes normes de recherche, de sécurité et de conformité appliquées automatiquement à un coût beaucoup plus réduit.

Microsoft Learn

Un site SharePoint Online archivé reste-t-il accessible aux utilisateurs ?

Non, les sites archivés ne sont pas accessibles aux utilisateurs et aux administrateurs durant cet état. Il est nécessaire de retirer l’état d’archivage sur le site concerné pour le rendre à nouveau consultable.

Combien coûte l’archivage SharePoint Online ?

Selon la documentation Microsoft, Syntex (SharePoint Premium) est facturé à la consommation (PAYG). Cette consommation sera liée à la souscription Azure renseignée lors de la configuration.

La grille tarifaire de Microsoft 365 Archive est actuellement disponible sous la forme suivante :

  • Microsoft 365 Archive ne sera facturé qu’à partir du moment où l’espace total des sites archivés et non archivés dépasse la limite de quota de stockage SharePoint online incluse ou allouée sous licence.
  • Si Microsoft 365 Archive est facturé, le prix sera de 0,05 $/Go/mois.
  • Si un site SharePoint Online est réhydraté après sept jours d’archivage, le prix sera de 0,60 $/Go réhydraté.

Pourrons-nous suivre les coûts de Microsoft 365 Archive ?

Mon hypothèse est que le coût seront visibles de la même manière que les autres ressources Azure, via le Cost Management :

Comme toujours je vous propose de réaliser un petit exercice sur le sujet :

Commençons par un bref rappel des prérequis.

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

Dans mon cas, j’ai utilisé un tenant Microsoft 365 disposant de licences Microsoft 365 E5 issues de la plate-forme CDX. J’y ai ensuite rajouté une souscription Azure MSDN.

Etape I – Préparation de l’environnement Azure :

Avant de pouvoir tester cette fonctionnalité, toujours en préversion, il est nécessaire de créer un groupe de ressources sur votre souscription Azure pour y stocker les sites SharePoint archivés.

Pour cela, rendez-vous dans le portail Azure, créez un nouveau groupe de ressources dans la région Azure de votre choix, puis lancez la validation :

Une fois la validation Azure réussie, lancez la création, puis attendez environ 1 minute :

Et c’est tout, rien de plus n’est nécessaire du côté d’Azure ! La suite va se passer du côté de Microsoft 365.

Etape II – Activation de la fonction d’archivage :

Avant de configurer la fonction d’archivage des sites SharePoint, rendez-vous dans la console d’administration pour constater l’absence de menu relatif à l’archivage :

Retournez sur la console d’administration de 365 par ce lien, puis cliquez sur le menu suivant :

Recherchez la rubrique suivante, puis cliquez dessus :

Commencez par cliquez ici pour configurer Syntex, alias SharePoint Premium :

Sélectionnez la souscription Azure de votre choix :

Reprenez le groupe de ressources Azure créé précédemment, puis choisissez la localisation des archives SharePoint Online :

Cochez la case des conditions d’utilisation et de facturation, puis cliquez sur Sauvegardez :

Attendez environ 1 minute que Microsoft finalise la configuration de votre tenant :

La notification suivante apparaît alors sur ce même onglet :

Cliquez ensuite sur ce lien pour visualiser la liste des services disponibles :

Vérifiez que la fonction d’Archivage est bien présente. Celle-ci est encore en préversion chez Microsoft à l’heure où ces lignes sont écrites :

Activez la fonction d’archivage comme ceci :

Confirmez votre choix après avoir lu au besoin les termes et conditions du service :

Le service d’archivage est bien actif, il est toujours possible de désactiver cette fonctionnalité par le bouton présent en bas de l’onglet :

La configuration côté Microsoft 365 est maintenant terminée, il ne nous reste plus qu’à tester la fonction d’archivage sur un site SharePoint Online.

Etape III – Test de la fonction d’archivage :

Retournez dans la console d’administration SharePoint Online afin de constater l’apparition d’un nouveau sous-menu consacré aux sites archivés :

Microsoft vous affiche l’espace disponible restant sur votre environnement SharePoint Online. Celui-ci dépend des licences 365 présentes sur votre tenant :

Dans la liste des sites actifs, choisissez l’un d’entre eux, puis cliquez sur la fonction Archiver :

Microsoft vous informe de l’espace actuellement alloué au site, cliquez à nouveau sur Archiver :

Microsoft vous informe des éléments qui seront archivés et d’autres qui le ne seront pas. Cliquez ici pour confirmer votre choix :

Peu de temps après, la console SharePoint Online vous informe du succès de l’archivage du site.

Toujours sur la console SharePoint Online, rendez-vous dans la liste des sites archivés :

Cliquez sur le site SharePoint Online archivé, puis cliquez sur son URL pour l’ouvrir dans un nouvel onglet :

Constatez l’apparition du message suivant au lieu de l’affichage habituel de votre site SharePoint Online :

Malgré la petite taille de mon site en exemple, notez l’absence d’actualisation du compteur d’espace SharePoint Online :

Attendez plusieurs heures avant de voir le changement s’y refléter.

Sur le portail Azure, une nouvelle ressource appelée Syntex est présente en tant qu’élément caché :

Néanmoins, aucune information relative à notre site archivé n’y figure.

De retour sur la console SharePoint Online, il est possible de réactiver le site précédemment archivé par la fonction suivante :

Microsoft nous informe de l’absence de coût lié à notre situation récente d’archivage, cliquez sur Réactivez :

Attendez environ 1 minute que Microsoft réhydrate le site précédemment archivé :

Actualisez la page principale de votre site SharePoint Online afin d’y constater la bonne réapparition du site :

Conclusion :

On peut dire que cette fonctionnalité d’archivage SharePoint Online était attendue depuis très très longtemps ! Sa simplicité de mise en place est un véritable atout, ainsi que le prix du stockage Azure en comparaison du prix stockage live de SharePoint.

Il ne restera plus qu’à définir la politique interne pour les sites dont l’accès direct n’est plus nécessaire. A titre préventif, je recommanderai les points de sécurité suivants :

  • Création d’une souscription Azure uniquement dédiée à l’archivage des sites SharePoint.
  • Mise en place de droits RBAC restreints sur la souscription Azure.
  • Ajout de verrous de suppression sur le groupe de ressources ou la souscription Azure :

Bon archivage 😎

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