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.

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 🤘🙏

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