Lors des premiers déploiements de Windows 365 Link, un problème revient systématiquement, y compris dans des tenants Intune pourtant bien maîtrisé : l’échec de l’enrôlement Intune pendant l’OOBE. Ce blocage n’est généralement pas lié à Windows 365, ni à une erreur utilisateur, ni à un problème réseau. Dans la majorité des cas, il est provoqué par une politique de restriction d’enrôlement Intune parfaitement légitime, mais inadaptée au comportement spécifique de Windows 365 Link.
Un premier article a déjà été écrit sur Windows 365 Link afin de répondre aux questions suivantes :
Dans ce second article, je vous propose de passer en revue les trois méthodes possible pour intégrer votre Windows 365 Link à votre tenant tout en évitant les restrictions mise en place sur Intune. Nous prendrons le temps de comparer leurs avantages, leurs limites et les scénarios dans lesquels elles font réellement sens.
Pourquoi Windows 365 Link pose problème avec les restrictions d’enrôlement ?
Lors du tout premier démarrage, Windows 365 Link démarre en Out of Box Experience, l’utilisateur s’authentifie avec son compte Microsoft Entra ID, le poste est alors joint à Microsoft Entra, puis l’enrôlement MDM automatique Intune est déclenché.
Jusque-là, rien d’inhabituel… du moins en apparence :
Mais c’est précisément au moment où Intune évalue les restrictions d’enrôlement que les choses se compliquent. Windows 365 Link :
est vu comme Unknown
n’est pas encore identifié comme corporate
n’est donc pas encore classifié
Ce n’est qu’après la jonction Entra ID complète que le Windows 365 Link bascule en poste d’entreprise :
La conséquence directe de ce comportement est simple : l’enrôlement peut se retrouver bloqué si une restriction d’enrôlement Intune bloquant les postes personnelles est mise en place :
Cette restriction d’enrôlement bloque de façon logique, les postes personnels, inconnus, et donc bloque aussi Windows 365 Link, même s’il s’agit d’un poste Microsoft, managé et destiné à Windows 365 :
Pour y remédier, Microsoft documente trois approches officielles. Elles sont toutes valides, mais ne répondent pas aux mêmes contraintes opérationnelles. Et je souhaitais en rajouter une de plus :
C’est l’approche la plus stricte et aussi la plus propre d’un point de vue sécurité :
Sécurité maximale
Aucun contournement des restrictions existantes
Comportement parfaitement déterministe
Les Corporate Device Identifiers permettent de dire à Intune que si un poste correspond à ces caractéristiques, il doit le considérer comme corporate dès le début de l’enrôlement.
Ainsi le device n’est jamais vu comme Unknown et les politiques bloquantes ne s’appliquent pas. Mais le seul souci reste la gestion et la manipulation de numéros de série des Windows 365 Link.
Pour cela, commencez par créer un fichier au format CSV contenant les champs suivants :
Manufacturer,Model,SerialNumber
Cela peut donner le fichier suivant :
Rendez-vous dans le menu d’Intune suivant :
Choisissez le type suivant, puis charger le fichier CSV précédemment créé :
Cliquez sur Ajouter :
Constatez l’apparition de votre poste dans les Corporate Device Identifiers :
Retournez sur votre Windows 365 Link afin de terminer la phase d’enrôlement :
Sur la console Intune, constatez le changement de statut de votre Windows 365 Link :
Cette fois, la phase d’enrôlement a pu aller jusqu’au bout, l’utilisateur peut maintenant se connecter à son Cloud PC :
Passons maintenant à une approche plus souple, mais tout aussi maîtrisable.
Méthode II – Autoriser Windows 365 Link via un filtre Intune :
Au lieu d’identifier chaque Windows 365 Link individuellement via des numéros de série, il est possible de définir une restriction d’enrôlement particulière à Windows 365 Link, avec une priorité plus haute, et ciblée uniquement sur Windows 365 Link via un filtre Intune.
Cette restriction d’enrôlement autorise l’enrôlement des Windows 365 Link, sans remettre en cause les restrictions pour les autres Windows.
Depuis le portail Intune, créez un filtre d’assignation pour les Windows 365 Link via le menu suivant :
Spécifie la règle de filtrage selon la propriété suivante afin de ne prendre en compte que les appareils Windows 365 Link :
Retournez ensuite dans la liste des restrictions d’enrôlement Windows afin d’en ajouter une nouvelle :
Nommez cette restriction, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Assignez cette restriction à tous les utilisateurs, puis cliquez ici pour ajouter un filtre :
Reprenez le filtre créé spécialement pour les Windows 365 Link :
Cliquez sur Suivant :
Cliquez sur Créer :
Attendez quelques secondes la fin de la nouvelle restriction d’enrôlement :
La règle doit être au-dessus de toute restriction d’enrôlement bloquante, pour cela, effectuez un glisser-déposer afin de changer la priorité de la restriction d’enrôlement dédiée au Windows 365 Link :
Avec cette deuxième méthode, la phase d’enrôlement a pu aller jusqu’au bout, l’utilisateur peut maintenant se connecter à son Cloud PC :
Passons maintenant à la troisième méthode.
Méthode III – Device Enrollment Manager (DEM) :
En utilisant un compte disposant du rôle DEM, il est également possible de contourner ces restrictions dans certains scénarios :
Un gestionnaire d’inscription d’appareil (DEM) est un utilisateur non administrateur qui peut inscrire des appareils dans Intune.
Les gestionnaires d’inscriptions des appareils sont utiles lorsque vous devez inscrire et préparer de nombreux appareils pour la distribution. Un compte DEM peut inscrire et gérer jusqu’à 1 000 appareils, tandis qu’un compte non administrateur standard ne peut en inscrire que 15.
Un DEM peut donc enrôler des devices même s’ils sont bloqués par des restrictions et aussi dépasser les limites de devices par utilisateur.
Configurez un ou plusieurs DEM sur le compte suivant :
Avec cette troisième méthode, la phase d’enrôlement a pu aller jusqu’au bout, le DEM a pu enrôler le Windows 365 Link et maintenant tous les utilisateurs peuvent se connecter à leur Cloud PC :
À noter que le DEM se retrouve en tant qu’utilisateur principal, et qu’il peut être remplacé :
Méthode IV – Windows Autopilot devices :
Lorsqu’on parle d’enrôlement Intune et de Windows 365 Link, une question revient très rapidement : Peut-on utiliser Windows Autopilot avec Windows 365 Link ?
Contrairement à un PC Windows classique, Windows 365 Link ne prend tout simplement pas en charge Windows Autopilot, quelle que soit la variante utilisée :
Autopilot : Windows 365 Link ne prend pas en charge autopilot ou la préparation des appareils Autopilot, notamment :
Inscription Autopilot
Configurations d’intégration
Actions d’appareil spécifiques à Autopilot, telles que la réinitialisation Autopilot.
Étant curieux, j’ai quand même voulu tester Autopilot pour le Windows 365 Link :
Mais le résultat a été l’effet attendu, puisque je n’ai pas été contraint lors de l’enrôlement du Windows 365 Link sur un autre tenant différent de celui configuré pour Autopilot :
Autrement dit, aucun scénario Autopilot n’est supporté, même partiellement, pour Windows 365 Link. Cette limitation n’est pas un oubli ou une restriction arbitraire : elle est directement liée à la nature même du Windows 365 Link :
Pas un Windows client classique
Aucune application locale
OS dédié extrêmement verrouillé
Politique stricte de contrôle d’exécution (intégrité du code)
Conclusion
Les restrictions d’enrôlement Intune sont l’un des premiers pièges rencontrés lors des déploiements de Windows 365 Link. Ce n’est ni un bug, ni un comportement anormal, mais la conséquence directe :
du cycle d’enrôlement Intune,
et du positionnement très spécifique de Windows 365 Link.
Une fois ce cadre bien compris, la solution devient finalement assez simple :
choisir la méthode d’enrôlement adaptée (Corporate Identifiers, filtre dédié ou DEM),
ne pas chercher à appliquer des logiques PC classiques (Autopilot, apps, scripts),
et traiter Windows 365 Link comme ce qu’il est réellement : un point d’accès sécurisé, minimaliste et contrôlé vers Windows 365.
C’est à cette condition que l’enrôlement devient fiable, reproductible, et cohérent avec une stratégie Cloud-first autour de Windows 365.
Depuis plusieurs mois, je souhaitais pouvoir Windows 365 Link dans des conditions réelles d’utilisation. Cette opportunité m’a enfin permis de prendre le temps d’analyser la solution de manière concrète, au-delà des annonces marketing et des fiches techniques. L’objectif de cet article est de décortiquer Windows 365 Link sous différents angles : technique, licences, intégration à l’écosystème Microsoft, mais aussi usage quotidien.
Au fil des tests, j’ai cherché à comprendre dans quels scénarios ce type d’appareil apporte une réelle valeur, et dans quels cas d’usage il montre ses limites.
Cet article se veut à la fois factuel et basé sur un retour d’expérience, afin d’apporter une vision pragmatique de Windows 365 Link et de son positionnement dans une stratégie de poste de travail cloud.
Pour vous guider plus facilement dans cet article très long, voici des liens rapides :
Commençons par le tout début. Il était une fois… Windows 365 Link.
Qu’est-ce que Windows 365 Link ?
En quelques mots, Windows 365 Link est un thin client qui permet de se connecter directement à un Cloud PC Windows 365, vous offrant ainsi un moyen sécurisé et simple d’accéder à votre environnement cloud.
Windows 365 Link est le premier appareil matériel pc cloud qui permet aux utilisateurs de se connecter directement à leur machine virtuelle Cloud PC. Il s’agit d’une solution de pile complète et spécialement conçue par Microsoft.
Lorsque les utilisateurs se connectent à leur Windows 365 Link, ils sont connectés à leur machine virtuelle PC Windows 365 Cloud via le service Windows 365.
Nerdio illustre, à l’aide d’un schéma simple, la manière dont Windows 365 Link s’intègre à l’écosystème cloud de Microsoft
Quelles sont ses caractéristiques techniques ?
Windows 365 Link mesure 120 × 120 × 30 mm pour un poids de 418 grammes, et est compatible VESA 100 et verrous Kensington. De plus, il dispose des connectivités suivantes :
Sans fil :
Wi-Fi 6E
Bluetooth 5.3
Face avant :
USB-A (USB 3.2)
Prise audio jack
Face arrière :
USB-C (USB 3.2)
DisplayPort (1.4a, jusqu’à 4k 60 Hz)
HDMI (2.0b, jusqu’à 4k60)
Ethernet (1.0 Gbit/s)
Alimentation électrique (65 watts)
Unified Extensible Firmware Interface (UEFI) pour la réinitialisation
Côté matériel et logiciel, on retrouve les éléments suivants :
Windows 365 Link est conçu pour offrir un accès direct, sécurisé et dédié à un PC Cloud Windows 365, sans exécuter de système Windows local complet. L’objectif n’est pas de remplacer un PC traditionnel, mais de proposer un point d’accès matériel minimaliste, fortement intégré aux services Microsoft Entra ID, Intune et Windows 365.
En quoi est-il différent d’un PC pour accéder à Windows 365 ?
Contrairement à un PC Windows traditionnel, Windows 365 Link ne stocke pas de données utilisateur localement et ne permet pas d’exécuter d’applications hors du PC Cloud. Toute l’expérience utilisateur est déportée dans le Cloud PC, ce qui contribue à réduire la surface d’attaque locale et simplifie considérablement l’administration du poste.
Windows 365 Link peut-il remplacer un thin client tiers ?
Windows 365 Link se rapproche fonctionnellement d’un thin client, mais avec une intégration native et exclusive à Windows 365.
Il ne vise pas la polyvalence fonctionnelle (VDI multiples, accès Linux ou AVD générique), mais une expérience optimisée et contrôlée pour Windows 365 uniquement. Cela en fait un choix pertinent dans des environnements standardisés, mais plus restrictif que certaines solutions tierces.
Attention, ce point a déjà été mentionné à plusieurs reprises, mais mérite d’être rappelé : Windows 365 Link ne prend pas en charge Azure Virtual Desktop ni Microsoft Dev Box.
Dans quels scénarios est-il le plus pertinent ?
Windows 365 Link est particulièrement adapté aux environnements à postes partagés, aux scénarios Frontline, aux centres de contact, aux environnements industriels ou aux sites distants où la simplicité de déploiement, la sécurité et la rapidité de remplacement du matériel sont prioritaires.
Voici quelques exemples de cas d’usage :
Postes partagés
Permettre aux collaborateurs en mode hybride de retrouver instantanément leur environnement de travail
Accès rapide et sécurisé à leur Cloud PC Windows 365, sans dépendance au poste physique
Idéal pour les environnements à forte rotation d’utilisateurs ou à postes non attribués
Centres d’appels
Démarrage en quelques secondes vers un Cloud PC Windows 365
Expérience utilisateur fluide et réactive, adaptée aux usages intensifs (voix, CRM, applications métiers)
Aucune donnée stockée localement sur le terminal, réduisant les risques de fuite d’informations
Authentification sans mot de passe via Microsoft Entra ID
Espaces spécialisés
Accès sécurisé aux outils et aux données dans des environnements contrôlés
Utilisation dans des lieux spécifiques tels que :
laboratoires
zones logistiques ou arrière-boutiques
centres de formation
accueils et réceptions
Frontline et métiers spécifiques
Mise à disposition d’un poste de travail Cloud sécurisé pour :
travailleurs de première ligne en milieu industriel
agents d’accueil
personnels en environnement scientifique ou de recherche
Réduction des contraintes matérielles locales et simplification du support
Métiers à forte sensibilité des données
Accès distant sécurisé pour des profils tels que :
analystes financiers
consultants
chargés de clientèle bancaire
agents de support client
téléconseillers / télévendeurs
Centralisation des données dans le Cloud PC, limitant les risques de fuite ou de perte
Dans quels cas n’est-il pas recommandé ?
Windows 365 Link est peu adapté aux utilisateurs nomades, aux scénarios nécessitant un fonctionnement hors ligne, ou aux usages impliquant des applications locales spécifiques ou des périphériques avancés non pris en charge. Il n’est pas non plus destiné à remplacer un poste de travail puissant pour des usages lourds locaux.
De ce fait, la comparaison entre Windows 365 Link + Cloud PC et un ordinateur portable moyen de gamme peut soulever des questions économiques :
Critère
Laptop moyen de gamme
Windows 365 Link + Windows 365
Coût matériel initial
~800 € (laptop)
365 € (Windows 365 Link)
Durée de vie
3–4 ans
4–5 ans (device statique)
Coût licence Windows 365
0 €
60 €/mois → 2 160 € sur 3 ans
Déploiement initial
Imaging, drivers, apps
Provisioning automatique
Support & maintenance (3 ans)
30 h × 60 €/h = 1 800 €
30 h × 30 €/h = 900 €
Données locales
Oui
Non
Exposition en cas de perte/vol
Élevée
Très faible (données Cloud)
Continuité de service
Dépend du matériel
Reconnexion immédiate
Coût total estimé sur 3 ans
~2 600 €
~3 425 €
Lecture du ROI
Référence
Surcoût ~825 € / poste sur 3 ans
Windows 365 n’est donc pas nécessairement moins coûteux par défaut, le ROI devient positif si :
Postes partagés / Frontline / hot desk
Réduction forte du support de proximité
Exigences sécurité élevées
Besoin de remplacement immédiat du poste
Sinon, sur poste dédié standard, l’ordinateur portable reste économiquement plus avantageux.
Permet-il de réduire les coûts IT et le provisioning ?
Dans les usages recommandés listés plus haut, Windows 365 Link peut contribuer à une réduction des coûts liés au support, au renouvellement matériel et à la gestion des images système. En revanche, il renforce la dépendance au modèle de licences Windows 365, qui doit être évalué globalement dans la stratégie poste de travail.
Windows 365 Link simplifie le provisioning, le remplacement des appareils et l’exploitation quotidienne grâce à l’enrôlement automatique Entra ID et Intune. L’administration est centralisée, avec moins d’interventions locales, ce qui facilite la standardisation et la gouvernance du poste de travail.
Quels sont ses bénéfices de sécurité ?
L’absence de données persistantes locales, l’authentification systématique via Microsoft Entra ID et l’intégration native avec les stratégies d’accès conditionnel renforcent la posture de sécurité globale. En cas de perte ou de vol du matériel, aucune donnée utilisateur n’est exposée localement.
En centralisant l’exécution et les données dans le Cloud PC, Windows 365 Link limite les impacts d’incidents matériels, de compromission locale ou de mauvaise configuration utilisateur. La gestion centralisée via Intune permet également d’appliquer des politiques de sécurité homogènes et cohérentes.
Quels sont les licences nécessaires pour l’utiliser ?
Voici les exigences connues pour pouvoir utiliser Windows 365 Link :
Exigences de licence Windows 365
Exigences Microsoft Entra ID
Exigences Microsoft Intune
Prenons le temps de comprendre en détail toutes ces exigences.
Exigences de licence Windows 365 :
Windows 365 Link n’introduit aucune nouveauté du côté des licences. On reste strictement dans le périmètre Windows 365.
Sans licence Windows 365 valide assignée à l’utilisateur, votre Windows 365 Link n’est pas utilisable : la connexion à un autre PC est tout simplement impossible, même à un environnement Azure Virtual Desktop.
À noter que Windows 365 Link accepte tous les types de licences Windows 365 :
Windows 365 Entreprise
Windows 365 Business
Windows 365 Frontline
Exigences Microsoft Entra ID :
Avec Windows 365 Link, un point apparaît rapidement comme non négociable : Windows 365 Link doit être Microsoft Entra joined ou Entra hybrid joined.
L’utilisateur qui effectue cette jonction doit bien évidemment avoir les droits pour joindre des appareils au tenant :
Lors de la jonction à Entra ID, le device s’enrôle automatiquement dans Intune. Et là, point important : l’utilisateur qui joint le device doit disposer d’une licence Microsoft Entra ID Premium, sinon l’enrôlement automatique échoue.
L’enrôlement automatique dans Intune dépend du paramétrage suivant :
Exigences Microsoft Intune :
L’enrôlement Intune des Windows 365 Link se fait pendant l’OOBE, sans action manuelle supplémentaire grâce aux mécanismes d’Entra.
Là encore, l’utilisateur qui joint le Windows 365 Link doit :
Disposer d’une licence Microsoft Intune
Avoir le droit d’enrôlement
Ne pas être bloqué par des restrictions d’enrôlement Intune :
Concrètement, voici ce que la donne lors du premier démarrage du Windows 365 Link :
L’utilisateur démarre et s’authentifie pour la toute première fois :
Le Windows 365 Link s’enrôle automatiquement dans Entra :
Puis l’enrôlement automatique MDM prend le relais pour l’ajouter dans Intune :
Avant d’arriver à cela avec votre Windows 365 Link, prenons le temps de passer en revue toutes les étapes.
Où peut-on l’acheter ?
Sa disponibilité dépend des pays et des vagues de lancement définies par Microsoft. L’appareil est proposé via des partenaires et revendeurs agréés Microsoft, comme TD SYNNEX selon les régions concernées.
À ce jour, la disponibilité semble s’élargir progressivement avec les vagues successives de déploiement, parfois désignées comme Wave 1 ou Wave 2. Windows 365 Link est actuellement disponible pour les pays suivants :
États-Unis
Australie
Canada
Danemark
France
Allemagne
Inde
Japon
Pays-Bas
Nouvelle-Zélande
Suède
Suisse
Royaume-Uni
Dans les prochains mois, Il devrait l’être par la suite aussi disponible dans :
Belgique
Finlande
Irlande
Italie
Pologne
Singapour
Espagne
Pour connaître les options d’achat exactes, il est recommandé de se rapprocher d’un partenaire Microsoft local ou de consulter les annonces officielles de Microsoft pour votre zone géographique.
Maintenant que les principaux aspects fonctionnels, techniques et de licences autour de Windows 365 Link ont été abordés, il est temps de passer à la partie plus concrète.
La section suivante détaille pas à pas les différentes étapes de configuration et de prise en main de Windows 365 Link, depuis la préparation de l’environnement jusqu’aux premiers tests en conditions réelles :
Dans mon environnement de test, j’ai déjà configuré plusieurs polices de provisionnement afin de créer mes Cloud PCs qui vont me servir durant mes tests :
Les Cloud PCs étant correctement déployés, une exigence particulière concerne toutefois le SSO avec Entra. Pour être plus clair, je vais maintenant repasser en détail sur toutes les étapes pour correctement configurer le SSO.
Etape I – Configuration du Single Sign-On :
Windows 365 Link repose entièrement sur le mécanisme Single Sign-On via Microsoft Entra ID. Autrement dit : si le SSO n’est pas activé sur le Cloud PC, la connexion de votre utilisateur risque d’échouer :
Pour activer le SSO, il sera nécessaire de vérifier, et de modifier si nécessaire, la police de provisionnement de vos Cloud PC, puis de recréer au besoin de nouveaux Cloud PCs si ces derniers ont été créés avant cette modification :
Voici l’option SSO dans la police de provisionnement des Cloud PCs qui doit être cochée :
L’étape suivante consiste à supprimer la demande de consentement SSO côté Microsoft Entra ID, dont la configuration repose sur des principaux de service :
Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise la console PowerShell d’Azure Cloud Shell, accessible depuis le portail Azure :
J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte aux permissions appropriées :
Je modifie la propriété isRemoteDesktopProtocolEnabledtruesur True, puis je vérifie que la propriété isRemoteDesktopProtocolEnabledest correctement définie :
Depuis le portail Intune, je crée ensuite un groupe contenant les Cloud PCs :
J’utilise une requête dynamique pour ajouter automatiquement mes prochains Cloud PCs au groupe :
Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login :
Tout est maintenant en place pour tester la première authentification sur votre Windows 365 Link.
Etape II – Test de la première connexion Windows 365 Link :
La vidéo suivante correspond à la première connexion avec succès de mon utilisateur de test à son Windows 365 Link :
J’ai réalisé ensuite une seconde vidéo montrant plusieurs scénarios de connexion et de bascule d’utilisateurs avec Windows 365 Link :
Le premier test illustre la connexion d’un utilisateur unique à différents Cloud PC Windows 365 qui lui sont attribués. L’objectif est d’observer le temps de connexion, la fluidité du changement de Cloud PC, ainsi que l’efficacité globale du processus d’authentification.
Le second test se concentre sur un scénario de type pool partagé, comparable à un usage Windows 365 Frontline, où plusieurs utilisateurs se connectent successivement au sein d’un même pool de Cloud PC. Ce scénario permet d’analyser le comportement de l’authentification, la gestion des sessions et la rapidité de bascule entre utilisateurs.
Ces démonstrations offrent un retour concret sur les performances et l’expérience utilisateur, avant d’aborder les aspects de configuration et d’administration via Intune.
Travis nous a d’ailleurs fait une excellente vidéo sur ce sujet disponible juste ici :
Une fois ces premiers tests de connexion réalisés, on peut imaginer d’autres tâches ou configurations que l’on peut faire autour de son Windows 365 Link.
Mais avant cela, je vous conseille de commencer par créer un filtre d’assignation Intune pour cibler uniquement les Windows 365 Link dans vos futures polices de configuration.
Etape III – Création d’un filtre d’assignation Intune :
Depuis le portail Intune, je commence par créer un filtre d’assignation, qui me sera très utile pour configurer les Windows 365 Link par la suite :
Je nomme ce filtre avec comme plateforme Windows 10 et +, puis je clique sur Suivant :
Je spécifie la règle de filtrage selon la propriété suivante afin de ne prendre en compte que les appareils Windows 365 Link, puis je clique sur Prévisualiser :
Si des Windows 365 Link sont déjà présents, je devrais voir ces derniers apparaître :
Enfin je confirme la création du filtre :
Mon filtre est maintenant en place, je vais pouvoir commencer à effectuer quelques réglages, comme la détection automatique du fuseau horaire.
Etape IV – Configuration automatique du fuseau horaire :
Au démarrage de votre Windows 365 Link, l’heure qui s’affiche n’est peut-être pas la bonne :
Les appareils Windows 365 Link peuvent rencontrer des problèmes de fuseau horaire si la détection automatique n’est pas autorisée. Il est possible de forcer l’utilisation du fuseau horaire local en autorisant l’accès à la localisation via Microsoft Intune.
Pour cela, connectez-vous au portail Intune, puis dirigez-vous vers le menu suivant :
Sélectionnez le type de profil suivant :
Renseignez les informations suivantes, puis cliquez sur Suivant :
Nom : Windows 365 Link – Time Zone Detection
Description : Autorise l’accès à la localisation afin de permettre la détection automatique du fuseau horaire sur les appareils Windows 365 Link.
Recherchez Access location, puis sélectionnez la catégorie Privacy, configurez comme ceci, puis cliquez sur Suivant :
Ajoutez les Scope tags nécessaires selon votre organisation, puis cliquez sur Suivant :
Dans Assignments, ciblez les appareils Windows 365 Link selon la méthode suivante, puis cliquez sur Suivant :
Par exemple, en utilisant All devices
En appliquant un Include filter basé sur un filtre de type Windows 365 Link
Vérifiez la configuration, puis cliquez ici pour déployer la stratégie :
Quelques minutes plus tard, l’accès à la localisation est autorisé, Windows 365 Link peut détecter automatiquement le fuseau horaire local, et affiche l’heure correcte selon la localisation de l’utilisateur :
Etape V – Modification du délai d’extinction de l’écran :
Par défaut, les appareils Windows 365 Link éteignent l’écran après environ cinq minutes d’inactivité. Ce comportement est assimilé à un verrouillage local : lorsque l’utilisateur réactive l’appareil, l’écran de connexion s’affiche.
Comme pour l’heure, la configuration se fait via une police de configuration Intune. Dans mon cas je configure l’extinction de l’écran après 9 minutes d’inactivité :
Travis nous a encore fait une excellente seconde vidéo sur ce sujet :
Etape VI – Modification des délais de déconnexion des sessions :
Comme Microsoft le recommande, est-il possible de raccourcir (mais pas de rallonger ?) les temps définis par défaut dans le cas de sessions Windows 365 inactives ou déconnectées :
Par défaut, Windows 365 PC Frontline conservent la session utilisateur active jusqu’à ce que :
En mode dédié : Le PC cloud est inactif pendant 30 minutes.
En mode partagé : Le PC cloud est inactif pendant 15 minutes.
Deux minutes avant la limite de temps d’inactivité, l’utilisateur reçoit une notification avec une boîte de dialogue.
Cette stratégie force la fermeture (log off) des sessions Windows 365 afin d’éviter :
Les sessions laissées ouvertes sans activité
Les sessions bloquées après une coupure réseau
La consommation inutile de capacité (critique en Frontline partagé)
Elle remplace alors entièrement le comportement par défaut des services Windows 365 expliqués plus haut, à la condition que les temps indiqués ne soient pas supérieurs :
Par contre, à la différence des configurations précédemment appliquées sur les Windows 365 Link, j’ai appliqué cette nouvelle police sur filtre comprenant uniquement les Cloud PCs Frontline comme ceci :
Le tableau ci-dessous résume les différents événements observés et les mécanismes impliqués dans ma configuration :
Étape
Heure
Événement
Mécanisme responsable
Login utilisateur
08h47
Connexion au Cloud PC Frontline
Session RDS active
Idle atteint
08h52
Message “You will be signed out in 2 minutes”
Idle session RDS (5 min)
Log off
08h54
Déconnexion automatique (sign out)
End session when time limits are reached
Écran noir
09h03
Extinction automatique de l’écran
Policy Display Windows 365 Link (9 min)
Etape VII – Connexion automatique sur un Cloud PC :
Windows 365 Link permet également d’activer des mécanismes de connexion automatique et d’authentification sans mot de passe (passwordless), afin de simplifier encore davantage l’accès au Cloud PC pour l’utilisateur final.
Dans ce scénario, l’utilisateur n’a pas besoin de saisir manuellement son identifiant, ce qui rend l’expérience de connexion particulièrement fluide :
Pour cela, je suis passé par la création d’une police de configuration personnalisé avec les paramètres OMA-URI suivants :
Nom : Activer les clés de sécurité FIDO pour la connexion à Windows
OMA-URI : ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
Type de données : Integer
Valeur : 1
Il est également possible de configurer Windows 365 Link pour qu’il se connecte automatiquement à un Cloud PC Windows 365 spécifique :
Cette option est particulièrement adaptée aux environnements à poste dédié ou aux usages standardisés. On y retrouve les fonctionnalités habituelles, comme la restauration ou la réinitialisation de la connexion.
Enfin, un bouton Annuler permet d’annuler la connexion automatique à ce Cloud PC. Cette action redirige l’utilisateur vers l’écran de sélection afin de lui permettre de choisir un autre Cloud PC Windows 365 auquel se connecter :
Ces options permettent d’adapter finement l’expérience de connexion selon que l’on se trouve dans un scénario à poste dédié ou à usage partagé.
Etape VIII – Restauration de mode usine :
Si nécessaire, Microsoft propose une restauration en mode usine des Windows 365 Link depuis le portail Intune. Comme beaucoup de postes gérés en MDM sous Intune, cette fonction très utile permet de réinitialiser complètement l’appareil à distance, en supprimant toute configuration et toute association utilisateur, afin de le reprovisionner proprement.
Voici d’ailleurs une vidéo qui montre le processus en entier, d’environ 30 minutes (accéléré), sur un Windows 365 Link :
Etape IX – Test de Microsoft Teams :
J’ai réalisé un test Microsoft Teams avec Windows 365 Link et j’ai été très satisfait de l’expérience globale, tant sur la qualité du rendu que sur la fluidité du partage d’écran et des flux audio/vidéo.
Un tour dans les paramètres de Teams confirme que le mode Media Optimized (SlimCore) est bien actif avec Windows 365 Link :
Pour plus de détails sur SlimCore et son fonctionnement côté AVD / Windows 365, voir cet article dédié sur mon blog.
Ce test rapide illustre le rendu réel de Microsoft Teams en conditions d’usage, du partage d’écran et des flux caméra, en mettant en évidence que le traitement (CPU) est effectué localement sur le Windows 365 Link et non sur le Cloud PC :
Et voici encore une autre vidéo faite cette fois avec une vidéo YouTube :
Après ces différents tests et configurations, il est possible de tirer plusieurs enseignements concrets sur l’usage de Windows 365 Link.
Conclusion
En conclusion, et après plusieurs jours d’utilisation et de tests dans des scénarios réels, Windows 365 Link s’est montré convaincant à l’usage quotidien.
Les performances observées, la simplicité d’accès au Cloud PC et la stabilité globale de l’expérience m’ont laissé une impression très positive au quotidien. Dans certains cas, j’ai pu avoir des doutes quant à la pertinence de l’appareil, notamment pour des scénarios où ses limites fonctionnelles peuvent apparaître.
Néanmoins, pour les cas d’usage évoqués plus haut (postes partagés, environnements Frontline, centres de contact ou contextes à forte exigence de sécurité), Windows 365 Link apporte une réelle valeur.
C’est un produit cohérent, bien positionné dans la stratégie Cloud-first de Microsoft, et je suis personnellement très satisfait d’avoir pu le tester dans des conditions concrètes et représentatives.
Alors, Windows 365 Link est-il un produit de niche ou le début d’une nouvelle norme ?
Windows 365 Link s’inscrit dans la stratégie Cloud-first de Microsoft et cible des usages bien définis. Il ne remplace pas tous les postes de travail, mais propose une alternative cohérente dans les environnements où la simplicité, la sécurité et la centralisation priment sur la flexibilité locale.
Enfin, retrouvez-moi et Arnaud et Arnaud dans un futur AzuReX prévu le 29 janvier prochain à 13 heures, dont l’inscription se passe juste ici 😎
Microsoft continue d’intégrer des capacités d’intelligence artificielle directement au cœur de Windows. Jusqu’à présent, ces évolutions étaient principalement associées aux Copilot+ PCs, reposant sur un NPU. Avec les AI-enabled Cloud PCs annoncés lors de l’Ignite 2025, Microsoft explore une autre approche : proposer certaines expériences IA de Windows directement dans Windows 365.
Cet article présente un pas à pas de mise en œuvre, ainsi qu’un premier retour sur les fonctionnalités actuellement disponibles dans le cadre du Frontier Preview Program.
Mais comme à chaque fois, commençons par quelques questions-réponses.
Qu’est-ce qu’un AI-enabled Cloud PC ?
Un AI-enabled Cloud PC est un Cloud PC Windows 365 configuré pour activer des fonctionnalités IA avancées de Windows, sans dépendre des capacités matérielles locales du poste utilisateur :
Nous facilitons la recherche de vos documents, photos et paramètres dans Windows 11 en introduisant l’indexation sémantique en plus de l’indexation traditionnelle. Vous n’avez plus besoin de vous souvenir des noms de fichiers, des mots exacts contenus dans les fichiers ou des noms de paramètres.
Par exemple, vous pouvez utiliser vos propres mots pour trouver des images en tapant « pont au coucher du soleil », des documents en décrivant leur contenu, comme « budget voyage en Europe », ou des paramètres, comme « modifier mon thème ».
Il ne s’agit pas d’un NPU virtuel exposé au système, mais d’une expérience Windows enrichie par des services IA exécutés dans le cloud, puis diffusée via le streaming Windows 365.
Copilot+ PC vs AI-enabled Cloud PC :
L’approche de l’IA dans Windows repose sur le même principe, mais comme le Cloud PC est virtuel et se trouve dans le Cloud, son IA l’est également :
Copilot+ PC : poste physique avec NPU local (capacité IA “on-device”).
AI-enabled Cloud PC : poste Windows 365 exécuté dans le cloud, avec expérience IA intégrée côté Cloud PC.
Dans l’état actuel de la Frontier Preview, deux fonctionnalités sont disponibles :
Improved Windows Search
Click to Do
Qu’est-ce qu’Improved Windows Search ?
Improved Windows Search est une évolution du moteur de recherche Windows qui s’appuie sur des capacités d’IA pour interpréter l’intention de recherche, et non plus uniquement les métadonnées des fichiers (nom, emplacement). Concrètement, cela permet :
d’effectuer des recherches descriptives (par exemple sur le contenu d’un document ou d’une image),
d’obtenir des résultats plus pertinents dans la barre de recherche Windows et dans l’Explorateur de fichiers,
d’unifier la recherche entre fichiers locaux et contenus OneDrive, y compris pour des fichiers non encore téléchargés.
La précision des résultats dépend du contenu, de l’indexation et du contexte d’usage :
Qu’est-ce que Click to Do ?
Click to Do est une fonctionnalité qui permet d’exécuter des actions contextuelles à partir de ce qui est affiché à l’écran (texte ou images). Une fois activée :
l’utilisateur peut sélectionner un élément à l’écran (via Windows + clic ou Windows + Q),
Windows propose des actions adaptées au contenu détecté (par exemple copier du texte depuis une image, envoyer le contenu vers Microsoft 365 Copilot, ou lancer des actions associées).
Tout le monde peut-il déjà en profiter ?
Tout d’abord, le nombre et le type d’actions disponibles varient selon le contenu sélectionné et l’état actuel de la Frontier Preview. Ensuite, pour le moment, le Cloud PC doit respecter un certain nombre de contraintes :
Windows 365 en SKU Enterprise
256 Go de stockage disque
8 vCPU / 32 Go de RAM
Image Windows 11 récente (24H2 ou ultérieure)
Rejoindre le canal Beta du Windows Insider Program
Être déployé dans une des régions Azure suivantes :
West US 2
West US 3
East US
East US 2
Central India
Central US
South East Asia
Australia East
UK South
West Europe
North Europe
Ces exigences ne sont pas anodines : elles garantissent que le Cloud PC dispose de ressources suffisantes pour exécuter les services IA dans de bonnes conditions.
Voici la procédure Microsoft que nous allons suivre dans cet article. D’autres articles, comme celui-ci, sont aussi très bon :
Pour réaliser cet exercice, il vous faudra disposer de :
Un tenant Microsoft
Une licence Windows 365 Entreprise avec au minimum 8vCPU/32GB/256GB
Avant d’aller plus loin, commençons par vérifier que notre environnement répond bien aux prérequis de la fonctionnalité pour Windows 365.
Pour cela, rendez-vous dans le portail Intune, puis l’écran affichant vos différents Cloud PC :
Vérifiez le SKU de votre Cloud PC :
Vérifiez que l’image Windows 11 utilisée pour le provisionnement est au minimum en version 24H2 :
Vérifiez également que le Cloud PC est déployé dans une région Azure supportée :
Si cela n’est pas le cas, il vous est possible de déplacer très facilement votre Cloud PC via la procédure expliquée ici.
Enfin, si tous ces points sont validés, commençons par rejoindre le programme Windows Insider.
Etape I – Activation du Programme Windows Insider :
Démarrez une session sur votre Cloud PC, ouvrez les paramétrages Windows, puis cliquez ici pour rejoindre le programme Windows Insider :
Juste avant de pouvoir rejoindre le programme Windows Insider, cliquez sur cette alerte afin d’activer la remontée de données de diagnostic :
Activez l’option, puis retournez sur la page principale des paramètres Windows :
Puis, cliquez sur Commencer afin de l’activer sur votre Cloud PC :
Utilisez le compte de votre utilisateur de test pour joindre le programme :
Réutilisez le compte de votre utilisateur de test proposé dans la liste :
Choisissez le canal Beta, puis cliquez sur Continuer :
Cliquez sur Continuer pour accepter les conditions du programme liées aux données privées :
Redémarrez ensuite votre Cloud PC :
Une fois le Cloud PC redémarré, retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour :
Attendez l’installation complète de toutes les mises à jour, puis redémarrez au besoin. Une fois toutes les installations terminées, vérifiez la version Windows de votre Cloud PC :
À noter qu’il est également possible d’utiliser Intune pour basculer sur le canal Beta :
Le Cloud PC est maintenant à jour. La prochaine étape consiste à activer la fonctionnalité IA via Intune.
Etape II – Activation des fonctionnalités IA via Intune :
A noter que Microsoft propose une autre façon de passer par une stratégie Intune, via une stratégie locale, expliquée juste ici.
Dans le portail Intune, allez dans Windows 365, puis créez un nouveau groupe destiné à votre utilisateur de test pour cette nouvelle fonctionnalité IA :
Toujours sur Intune, allez dans Windows 365, puis créez une nouvelle stratégie Cloud PC configurations (preview) :
Nommez celle-ci, puis cliquez sur Suivant :
Activez la fonction IA, puis cliquez sur Suivant :
Filtrez au besoin via des Tags, puis cliquez sur Suivant :
Ajoutez votre groupe d’utilisateurs de test (Il est important de noter que cette activation est user-based. Elle ne s’appliquera qu’aux Cloud PCs respectant l’ensemble des prérequis techniques) :
Cliquez sur Créer pour terminer le processus :
Constatez la création de cette nouvelle stratégie dans l’onglet des paramétrages configurés pour vos Cloud PCs :
Déclenchez une synchronisation sur votre Cloud PC depuis la console Intune :
Un rapport affichant la fonctionnalité IA sur les les Cloud PC est disponible juste ici :
Après environ une heure, la fonctionnalité IA commence à se mettre en place sur le Cloud PC :
Le statut du démarre par le celui-ci :
C’est à ce moment précis qu’il faudra faire preuve d’un peu de patience afin de constater le changement côté utilisateur. Il sera même nécessaire de redémarrer le poste :
Une fois l’IA en place sur le Cloud PC, possiblement plusieurs heures après, le statut change de cette façon :
Il y est même expliqué pourquoi certains Cloud PC ne sont pas éligibles à l’IA :
Cette information est également disponible sur la fiche du Cloud PC :
Vous y êtes enfin ! Il ne vous reste plus qu’à vous reconnecter pour tester les changements :
Pour cela, j’ai ouvert côte à côte deux sessions Cloud PCs afin que vous puissiez voir les améliorations, une fois la fonctionnalité IA activée.
Etape III – Tests d’Improved Windows Search :
La première fonctionnalité visible est Improved Windows Search. Elle modifie en profondeur la manière dont Windows interprète les requêtes de recherche IA.
Plutôt que de se limiter aux noms de fichiers ou aux métadonnées, la recherche s’appuie davantage sur le contenu réel des documents, y compris ceux stockés dans OneDrive. Il devient possible de retrouver des fichiers à partir de descriptions plus naturelles, même si le nom du fichier est peu explicite.
Dans des environnements riches en documents, la différence avec la recherche traditionnelle est rapidement perceptible.
Voici un premier changement visuel des différents nouveaux champs de recherche IA dans Windows 11 :
Dans OneDrive, la nouvelle recherche IA montre bien des fichiers contenant AVD dans le nom, mais également des images contenant ce même terme :
Toujours dans OneDrive, la nouvelle recherche IA montre bien des fichiers contenant SYNNEX dans le nom, mais également des photos contenant ce même terme :
Cette nouvelle fonction de recherche IA marche plutôt bien je dois dire :
Même des objets y sont facilement identifiés dans les photos remontées dans la nouvelle recherche IA :
Passons maintenant à Click to Do.
Etape IV – Tests de Click to Do :
Click to Do propose une approche différente. L’objectif est de réduire le nombre d’étapes nécessaires pour interagir sur du contenu visible à l’écran. Une fois l’application lancée :
l’utilisateur peut sélectionner du texte ou une image,
des actions contextuelles sont proposées,
certaines actions peuvent s’intégrer avec Microsoft 365 Copilot.
Dans l’état actuel de la préversion, Click to Do doit être lancé au moins une fois après chaque redémarrage du Cloud PC pour être pleinement opérationnel :
Pour cela, retrouvez-le dans le menu de votre Cloud PC mis à jour :
Une fois lancé, il est possible de parcourir des sites web contenant des images de texte, d’appuyer sur la touche Windows + clic de souris dès que l’on souhaite interagir avec l’IA.
Cela vous donnera des options pour effectuer des actions sur ce que l’IA voit, comme copier du texte dans une image par exemple :
Le texte copié depuis l’image est assez bien repris grâce à l’IA :
Il est également possible de reprendre une image présente sur une page web, et de lui retirer automatiquement le fond grâce à l’IA :
Il est même possible de reprendre du texte pour préparer un prompt Copilot sous Word :
D’autres fonctions sont visibles, mais ne sont pas encore opérationnelles pour les Cloud PCs, comme celle-ci :
Pour le moment, rien ne bascule dans Microsoft 365 Copilot, cela est d’ailleurs confirmé sur la documentation Microsoft :
Les Windows 365 AI-enabled Cloud PCs illustrent une orientation claire : faire du cloud le vecteur principal de diffusion des innovations IA de Windows. Plutôt que de conditionner ces fonctionnalités à un matériel spécifique, Microsoft choisit de les intégrer directement dans l’expérience Cloud PC, sous contrôle IT.
Plusieurs éléments doivent encore être gardés à l’esprit :
Les fonctionnalités sont encore en Frontier Preview
Le périmètre IA reste volontairement limité
La disponibilité dépend fortement de la région Azure et du sizing
Certains comportements peuvent évoluer sans préavis
À ce stade, il s’agit encore d’une approche exploratoire. Néanmoins, les fondations techniques et opérationnelles laissent entrevoir un potentiel intéressant pour les environnements Windows 365 à moyen terme, comme les Windows 365 for Agents :
Depuis la mi-2025, Microsoft renforce progressivement les paramètres de sécurité par défaut dans ses environnements Windows 365 et Azure Virtual Desktop (AVD). L’un des changements les plus visibles pour les administrateurs et utilisateurs concerne la redirection du presse-papiers (clipboard), désormais désactivée par défaut dans les nouvelles configurations.
Cette évolution, alignée avec la Microsoft Secure Future Initiative (SFI), vise à limiter les risques d’exfiltration de données et à uniformiser la posture de sécurité entre Windows 365 et AVD. Mais concrètement, comment ce changement s’applique-t-il ? Quels paramètres contrôlent réellement le comportement du presse-papiers ? Et comment vérifier la configuration effective entre les deux couches (Propriétés RDP et stratégies GPO/Intune) ?
Dans mon précédent article, publié fin 2024, je présentais les options de durcissement du presse-papiers AVD via Intune et les propriétés RDP. Depuis mi-2025, Microsoft est passé d’une approche configurable à une approche imposée par défaut : les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désormais désactivées nativement dans Windows 365 et AVD. Ce qui était un bon réflexe de sécurité devient aujourd’hui la norme.
Une excellente référence pour cette mise à jour est l’article de Dieter Kempeneers, Configure Advanced Clipboard AND Drive Redirection for AVD and Windows 365, dans lequel il détaille non seulement la désactivation par défaut des redirections (presse-papiers, lecteurs, imprimantes) sur les nouveaux hôtes AVD et les Cloud PC Windows 365, mais aussi la façon d’en réactiver certains comportements de façon granulaire.
Dans ce nouvel article, je décortique la logique de redirection RDP, les nouvelles valeurs par défaut introduites par Microsoft, et surtout, les implications pratiques pour vos déploiements et modèles AVD / Windows 365.
Depuis quand Microsoft a changé la règle du presse-papier pour Windows 365 ?
Microsoft a introduit de nouveaux paramètres de sécurité par défaut pour Windows 365 Cloud PCs le 18 juin 2025 :
Windows 365 renforce la sécurité des PC cloud en désactivant par défaut les redirections du presse-papiers, des lecteurs, des périphériques USB et des imprimantes pour tous les PC cloud nouvellement provisionnés et reprovisionnés. Cette modification minimise le risque d’exfiltration de données et d’injection de logiciels malveillants, ce qui offre une expérience plus sécurisée et s’aligne sur le principe de l’initiative Microsoft Secure Future Initiative (SFI) visant à activer et à appliquer par défaut les protections de sécurité.
Un message sous forme de bandeau est bien visible lors de la création d’une police de provisionnement Windows 365 :
D’ailleurs, la police de configuration de sécurité appelée Windows 365 Security Baseline et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc, de facto, le transfert de fichiers :
Est-ce que cette restriction concerne aussi Azure Virtual Desktop ?
Oui, les nouveaux pools d’hôtes Azure Virtual Desktop sont aussi concernés par ce renforcement :
Cette modification des paramètres par défaut de redirection sera bientôt effective. Afin d’aider les administrateurs informatiques à s’y préparer, une bannière pouvant être ignorée s’affichera sur la page d’accueil « Créer un pool d’hôtes » du portail Azure. Cette bannière informera les administrateurs des nouveaux paramètres par défaut pour les nouveaux pools d’hôtes et fournira des liens vers la documentation expliquant comment les remplacer en modifiant les propriétés RDP du pool d’hôtes une fois celui-ci créé.
Remarque : pour les pools d’hôtes existants, aucune modification ne sera apportée à la configuration de redirection en votre nom. Cependant, nous vous recommandons de renforcer la sécurité des paramètres en désactivant les redirections qui ne sont pas nécessaires. Pour effectuer ces modifications, consultez la section relative à la redirection des appareils dans la documentation sur les propriétés RDP.
Voici la nouvelle option de configuration RDP mise par défaut, et visible dans les propriétés du pool d’hôtes AVD :
D’ailleurs, la police de configuration de sécurité appelée Security Baseline for Windows 10 and later et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc de facto le transfert de fichiers :
Qu’est-ce que cela change pour mes futures créations AVD et Windows 365 ?
Pour AVD : pour tout nouveau pool d’hôtes créé après la date de changement, les redirections de presse-papier, lecteurs, USB et imprimantes seront désactivées par défaut.
Pour Windows 365 : idem pour tous les Cloud PCs nouvellement provisionnés ou reprovisionnés : les mêmes redirections sont désactivées par défaut.
Impact : vos modèles, templates ou polices qui s’appuyaient sur ces redirections devront être revus. Si vous aviez des scénarios utilisateur où l’on transférait facilement du contenu local vers le poste cloud, il faudra anticiper ce nouveau comportement.
Comment identifier la configuration actuelle des postes ?
Le comportement dépend de deux couches complémentaires. Le serveur RDP n’impose pas unilatéralement la redirection : il la négocie avec le client en fonction de ces deux niveaux :
Le client (.rdp / Propriétés RDP AVD) détermine ce qui est demandé ou refusé pour la session. Exemple : redirectclipboard:i:0 dans les propriétés RDP d’un host pool.
Le serveur (Policies / GPO / Intune) définit ce qui est autorisé ou interdit de manière globale sur la machine. Exemple : fDisableClipboard dans le registre des stratégies.
Première couche : configuration client / RDP Properties :
Ces valeurs correspondent à la configuration du service RDP. Elles sont mises à jour lorsque tu modifies les RDP Properties d’un host pool dans AVD, par exemple :
Ces valeurs représentent la couche de gouvernance :
Elles sont prioritaires sur les paramètres locaux et sont appliquées au démarrage du service TermService.
Elles déterminent ce qui est autorisé ou interdit globalement sur la machine, indépendamment des paramètres envoyés par le .rdp.
La configuration peut se faire très facilement depuis une police de configuration Intune :
Interaction entre les deux couches :
Le comportement effectif correspond toujours à la configuration la plus restrictive :
Policy (serveur)
RDP Property (client/session)
Résultat final
Autorise
Interdit (redirectclipboard:i:0)
❌ Redirection désactivée
Interdit
Autorise (redirectclipboard:i:1)
❌ Redirection désactivée
Autorise
Autorise
✅ Redirection active
Résultats de tests : comportement réel du presse-papiers RDP
Pour mieux comprendre ces nouveaux paramètres de redirection du presse-papiers, j’ai réalisé une série de tests sur plusieurs configurations RDP (AVD et Windows 365).
Le but était de vérifier quels types de données (texte, image, HTML, binaire, etc.) pouvaient être copiés dans chaque sens selon les paramètres du serveur et du client.
Les couches de configuration RDP :
Les deux couches peuvent définir différentes valeurs, mais elles ne s’écrasent pas : le moteur RDP évalue d’abord la police, puis les propriétés RDP :
Couche
Rôle
1. ConfigurationRDP
Paramètres appliqués au niveau du service RDP local. C’est ce qu’utilise la session à l’exécution. Modifié par les propriétés RDP d’un host pool AVD.
2. Policy configuration (GPO / Intune)
Paramètres de gouvernance. Écrits par une stratégie (GPO/MDM) et prioritaires sur la configuration locale.
Niveaux de granularité (SCClipLevel / CSClipLevel) :
Les valeurs SCClipLevel et CSClipLevel permettent aussi d’affiner très précisément la redirection dans chaque sens :
SC (Server → Client) : copier du cloud vers le poste local.
CS (Client → Server) : copier du poste local vers le cloud.
Niveau
Formats autorisés
Exemple
0
Aucune redirection
Blocage total
1
Texte brut uniquement
Copier/coller texte simple
2
Texte brut + images
Exemple : capture d’écran
3
Texte brut + images + RTF
Texte formaté (Word, Outlook)
4
+ HTML
Copier/coller depuis un navigateur
Comment cela se voit pour Windows 365 ?
Voici un récapitulatif des différents tests effectués, en modifiant les propriétés pour AVD ou Windows 365 :
Et voici le détail de ces tests avec les configurations Intune appliquées pour impacter le registre Windows :
Test A – Clipboard redirection isn’t available : Le presse-papiers est complètement désactivé côté session RDP. Aucun copier/coller ne fonctionne dans aucun sens :
Test B – Clipboard redirection is available : Le presse-papiers est activé côté session RDP. Le copier/coller fonctionne dans les deux sens :
Test C – Do not allow Clipboard redirection Disabled (fDisableClip=0). Le comportement dépend donc de la configuration du fichier .rdp, qui est activé. Le copier/coller fonctionne dans les deux sens :
Test D – Do not allow Clipboard redirection Enabled (fDisableClip=1). Blocage complet du copier/coller, même si le .rdp autorise la redirection :
Test E – Do not allow Clipboard redirection Disabled (fDisableClip=0), comme la configuration du fichier .rdp, qui est activé. Disable clipboard transfers from session host to client (SCClipLevel=0) et inversement (CSClipLevel=0). Aucun copier-coller descendant ou montant n’est possible :
Test F – Allow plain text : Autorise uniquement le texte brut (SCClipLevel=1 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement, et pas d’images ni de formats enrichis :
Test G – Allow plain text and image : Autorise texte brut + images (SCClipLevel=2 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :
Test H – Ajoute le support du Rich Text (SCClipLevel=3 / CSClipLevel=0 / fDisableClip=0). Le copier/coller de texte et d’images fonctionne, mais pas HTML ni formats binaires. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :
Test I – Allow plain text, images, Rich Text Format and HTML. Ajoute HTML (SCClipLevel=4 / CSClipLevel=0 / fDisableClip=0). Formats binaires toujours bloqués.Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :
Test J – Allow plain text, images, Rich Text Format, HTML and Binary. Autorise tous les formats, y compris binaires (CSClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du host vers client :
Test K – Allow plain text (inverse direction). Même logique que F mais appliquée au client → host (SCClipLevel=0 / CSClipLevel=1 / fDisableClip=0). Seul le texte brut passe du poste local vers le cloud :
Test L – Allow plain text and images (inverse direction). Autorise texte et images du client vers la session (SCClipLevel=0 / CSClipLevel=2 / fDisableClip=0) :
Test M – Allow plain text, images and Rich Text Format (inverse direction). Ajoute RTF côté client → host (SCClipLevel=0 / CSClipLevel=3 / fDisableClip=0). HTML et binaire toujours bloqués :
Test N – Allow plain text, images, Rich Text Format and HTML (inverse direction). Permet HTML du client vers la session (SCClipLevel=0 / CSClipLevel=4 / fDisableClip=0) :
Test O – Allow plain text, images, Rich Text Format, HTML and Binary (inverse direction). Autorise tous les formats, y compris binaires (SCClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du client vers le host :
Conclusion
La désactivation par défaut des redirections RDP dans Windows 365 et AVD s’inscrit dans une tendance claire : un durcissement progressif des environnements cloud Windows pour tendre vers le secure by default.
Pour les architectes et administrateurs, cela signifie qu’il faut désormais anticiper ce comportement dans les modèles de provisionnement, les recommandations Intune et les templates de pools AVD.
Le presse-papiers, souvent considéré comme un simple confort utilisateur, devient un point de contrôle important dans la stratégie de sécurité : il faut choisir entre flexibilité et maîtrise du flux de données entre les environnements locaux et cloud.
En maîtrisant les deux couches de configuration (Propriétés RDP et polices GPO/MDM) et les niveaux SCClipLevel / CSClipLevel, vous pouvez adapter finement le niveau de redirection autorisé, du simple texte brut jusqu’à la copie complète de formats binaires.
En résumé : ce changement n’est pas une contrainte, mais une opportunité d’élever le niveau de sécurité sans perdre la visibilité sur le fonctionnement interne du protocole RDP.
Windows 365 continue d’évoluer et de s’adapter aux nouveaux usages. Après les éditions Business et Enterprise, Microsoft propose depuis quelque temps déjà Windows 365 Frontline, une déclinaison pensée pour les équipes en rotation ou à temps partiel. Bref, pour tous ceux qui n’ont pas besoin d’un Cloud PC huit heures par jour.
Dans cet article, je vous propose de faire le tour complet de Windows 365 Frontline, avec la création des stratégies dans Intune, le provisioning des Cloud PCs, les comportements de session, et les petits détails qu’on ne découvre qu’en le déployant soi-même.
Avant d’aller plus loin, je vous propose la lecture de plusieurs articles sur ce blog, qui parlent de Windows 365 depuis sa GA en 2021 :
Windows 365 Frontline a été présenté pour la première fois en avril 2023 et est devenu disponible en version publique quelques mois plus tard, à l’été 2023.
Windows 365 Frontline est une déclinaison de Windows 365 pensée pour les travailleurs “de première ligne”. Il s’agit de cibler ceux qui n’utilisent pas un poste de travail huit heures par jour, tous les jours, mais travaillant sur leur poste de manière ponctuelle ou en rotation. C’est donc parfait pour les équipes en postes tournant, les centres de support, les services clients, ou les équipes sur le terrain.
Windows 365 Frontline est une version de Windows 365 qui permet aux organisations de réduire les coûts en leur permettant de provisionner un PC cloud qui peut être utilisé par plusieurs utilisateurs avec une seule licence.
L’objectif principal est et reste de réduire le coût des licences Windows 365 tout en gardant la simplicité et la sécurité du Cloud PC.
Quelles sont les limitations de Windows 365 Frontline ?
Windows 365 Frontline apporte une vraie flexibilité, mais il faut connaître ses limites techniques et opérationnelles pour bien l’intégrer dans un environnement d’entreprise :
Un seul utilisateur peut être actif par Cloud PC à la fois : Même si la licence couvre plusieurs utilisateurs, ils ne peuvent pas se connecter simultanément.
Pas de mise en veille prolongée : lorsqu’un utilisateur se déconnecte, la session est suspendue mais reste comptabilisée tant que la VM est “réservée”.
Temps de démarrage à prévoir : la mise en service d’un Cloud PC Frontline peut prendre quelques minutes selon la politique de démarrage configurée.
Windows 365 Frontline Dedicated vs Shared ?
Microsoft propose aujourd’hui deux modes pour Frontline : Dedicated et Shared :
Le mode Dedicated reste le choix recommandé pour des postes attribués en rotation (3 utilisateurs maximum).
Prenons trois collaborateurs travaillant sur des shifts différents (matin, après-midi, nuit) — avec une seule licence Windows 365 Frontline, chacun dispose de son propre Cloud PC pendant son créneau de travail.
On réduit les coûts de licence tout en maintenant une expérience utilisateur complète et sécurisée pour chaque employé.
Le modèle devient particulièrement avantageux à grande échelle : pour 300 employés en rotation, il ne faudrait que 100 licences actives, soit une économie substantielle tout en maintenant une expérience et une sécurité identiques à Windows 365 Entreprise :
Le mode Shared vise les scénarios éphémères où la persistance n’est pas nécessaire (kiosques, formation). Ce mode a été introduit par Microsoft fin 2024. Ce mode est donc conçu pour des tâches courtes et ponctuelles (ex. : formation, inventaire, accès temporaire pour prestataires).
En quelques mots, le Frontline Partagé se distingue du Frontline Dédié sur :
Les Cloud PCs partagés sont réinitialisés après chaque session utilisateur : le profil et les données sont supprimés.
1 licence = 1 Cloud PC partagé : la licence est liée à la machine virtuelle, pas à un utilisateur spécifique.
Les déconnexions automatiques après inactivité libèrent la session, permettant à d’autres utilisateurs d’accéder rapidement au poste.
Idéal pour les scénarios nécessitant un accès rapide et sécurisé à des applications ou outils sans conservation de données persistantes.
Au final, quelles sont les différentes licences Windows 365 ?
Voici un comparatif des différentes licences Windows 365 disponibles :
Feature
Dedicated (Enterprise / Business)
Frontline Dedicated (Standard)
Frontline Shared Mode (Preview)
Cloud PC Usage
1 Cloud PC par utilisateur
3 Cloud PCs partagés entre 3 utilisateurs
Plusieurs Cloud PCs partagés entre de nombreux utilisateurs (1 à la fois)
User Profile
Persistant – sauvegardé entre les sessions
Persistant – chaque utilisateur a son propre bureau
Non persistant – profil supprimé après déconnexion
Concurrent Users
Un utilisateur par Cloud PC
1 utilisateur par Cloud PC à la fois (jusqu’à 3 par licence, en rotation)
Un seul utilisateur à la fois par PC partagé
Session Type
Expérience Windows complète
Expérience Windows complète
Sessions pooled et réinitialisables
Best For
Employés à temps plein utilisant un Cloud PC quotidiennement
Quels sont les prix pour ces licences Windows 365 ?
Les licences Windows 365 Frontline affichent un prix facial plus élevé que les éditions Enterprise ou Business, mais elles sont conçues pour être partagées entre plusieurs utilisateurs.
Autrement dit, il faut raisonner en coût par utilisateur actif plutôt qu’en coût par licence : une approche indispensable pour déterminer la solution la plus avantageuse financièrement selon ton modèle d’usage (rotation, shifts, postes partagés, etc.).
Voici donc un tableau comparatif indicatif (en USD) pour une machine de 4 vCPU / 16 Go RAM, selon les quatre « méthodologies » (Business / Enterprise / Frontline Dedicated / Frontline Shared) de licensing possibles pour Windows 365 :
Méthode / SKU
Prix en €, paiement mensuel engagement annuel
Windows 365 Enterprise
≈ 63 Euros
Windows 365 Business
≈ 63 Euros, avec Windows Hybrid Benefit
Windows 365 Frontline Dedicated
≈ 94.53 € (licence 3 utilisateurs)
Windows 365 Frontline Shared
≈ 94.53 € par poste partagé
Maintenant, il ne nous reste plus qu’à tester tout cela 😎
Pour réaliser cette démonstration sur les licences Windows 365 Frontline, il vous faudra disposer de :
Un tenant Microsoft
Une ou plusieurs licences Windows 365 Frontline
Dans le portail Microsoft 365 Admin Center, on remarque tout de suite que ces licences ne peuvent pas être attribuées directement à des utilisateurs ou à des appareils :
Toujours depuis le portail Admin Center, il n’est pas possible d’associer la licence Frontline à un utilisateur :
Commençons par tester les Cloud PCs Frontline dédiés à des utilisateurs spécifiques.
Test I – Test de Windows 365 Frontline Dédié :
J’ai commencé par créer un groupe sur le portail Entra ID pour mes utilisateurs de test :
Sur le portail Intune, dans la section Polices de provisionnement de Windows 365, je crée une nouvelle police :
Je nomme ma stratégie, je sélectionne le type Frontline et le mode Dedicated :
Je choisis la jointure Entra ID et j’active le Single Sign-On (SSO) :
Je sélectionne une image Windows 11 pour mes Cloud PCs :
Je clique sur Suivant :
Je clique sur Suivant :
Je clique ici pour attribuer une configuration de Cloud PCs :
Je choisis la taille des Cloud PCs, ainsi que leur nombre :
Je clique sur Suivant :
Je clique sur Créer pour valider ma nouvelle police de provisionnement :
Je constate la création de la police de provisionnement de mes PC Frontline :
De retour dans la liste des Cloud PCs, je remarque l’apparition de nouveaux Cloud PCs avec le statut Pending :
En cliquant sur la mention Pending, j’observe un message indiquant plusieurs raisons possibles expliquant ce statut :
Quelques minutes plus tard, le statut Pending passe à Provisioning pour ces Cloud PCs :
Environ un quart d’heure plus tard, les PC apparaissent en statut Provisioned :
Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :
Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC, normal :
Je retourne sur la police de provisionnement et j’augmente le nombre d’instances Windows 365 à 2 pour cette police Frontline :
Je parviens cette fois à connecter trois utilisateurs en simultané, bien que la configuration n’autorise initialement que deux sessions :
Dans les rapports Intune, on constate que la plateforme signale une surcapacité, mais qu’elle a tout de même permis la connexion grâce à la marge de tolérance (buffering) intégrée :
Voici d’ailleurs quelques règles du concurrency buffer pour Windows 365 Frontline :
Le concurrency buffer permet de dépasser temporairement la limite maximale de connexions simultanées permises par les licences Frontline dans des cas de transition comme le changement de shift
Le concurrency buffer ne s’applique pas aux Cloud PCs GPU-enabled ni au mode Frontline Shared.
Il peut être utilisé jusqu’à 4 fois par jour, pour un maximum d’1 heure à chaque activation. L’heure commence dès le dépassement de la limite de licences.
Si le buffer est utilisé de façon excessive (par exemple plus d’une heure à quatre reprises dans 24 heures), un blocage temporaire est activé pendant 48 heures, empêchant toute utilisation du buffer.
Si le tenant subit plus de deux blocages temporaires sur une période de 7 jours, le buffer peut être bloqué de façon permanente. Dans ce cas, il faut ouvrir un ticket auprès du support Intune pour restaurer l’accès.
Pendant le blocage (temporaire ou permanent), les utilisateurs peuvent toujours se connecter, mais uniquement jusqu’à la limite standard de licences (le buffer n’est plus accessible).
Continuons par par tester les Cloud PCs Frontline partagés à des utilisateurs.
Test II – Test de Windows 365 Frontline Partagé :
J’ai créé un second groupe dans le portail Entra ID pour mes utilisateurs de test :
Sur le portail Intune, dans la section Stratégies Windows 365, et je crée une seconde police de provisionnement :
Je nomme ma stratégie, je sélectionne le type Frontline, le mode Shared, je choisis la jointure Entra ID et j’active le SSO :
Je sélectionne une image Windows 11 pour mes Cloud PCs :
Je clique sur Suivant :
Je clique sur Suivant :
Je choisie la taille des Cloud PCs, ainsi que leur nombre :
Je clique sur Créer pour valider ma nouvelle police de provisionnement :
De retour dans la liste des Cloud PCs, je remarque l’apparition du nouveau Cloud PC avec le statut Provisioning :
Environ un quart d’heure plus tard, le Cloud PC apparaît en statut Provisionné :
Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :
Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC :
Sur mon premier utilisateur, je personnalise le bureau et le fond d’écran, je crée un dossier sur le disque C avec un fichier, j’ajoute des éléments sur le bureau et je modifie la barre du menu Démarrer :
Je déconnecte le premier utilisateur et me connecte avec le second ; je constate alors la présence des fichiers locaux sur le disque C :
J’attends environ une heure, puis je me reconnecte avec le premier utilisateur ; je constate la restauration des éléments issus de OneDrive ainsi que des fichiers locaux, mais l’absence du fond d’écran et des raccourcis de la barre des tâches, non pris en charge par OneDrive :
Je lance un reprovisionnement immédiat de ma machine partagée :
Je constate le démarrage du nouveau processus :
Le provisionnement progresse et la nouvelle machine partagée apparaît dans l’environnement :
Quelques minutes plus tard, la nouvelle machine partagée est provisionnée :
Je me reconnecte avec mes deux utilisateurs, en commençant par le premier, et je constate la disparition des fichiers précédemment présents sur le disque C mais la conservation des données sauvegardées sur OneDrive :
Conclusion
Windows 365 Frontline apporte une vraie flexibilité dans la gestion des postes Cloud, surtout pour les environnements en rotation ou à effectif variable.
Le mode Dedicated reste parfait pour les équipes qui se relaient sur un même poste tout en conservant leur propre environnement, tandis que le mode Shared s’adresse davantage aux scénarios temporaires ou sans persistance.
Ce qu’il faut retenir, c’est que Frontline ne vise pas à remplacer les éditions Business ou Enterprise, mais bien à optimiser les coûts et les licences quand tout le monde n’a pas besoin d’un Cloud PC permanent.
Et comme souvent avec Microsoft 365 et Intune, le meilleur moyen de comprendre… c’est de tester soi-même ! 😉
Microsoft continue de faire évoluer Windows 365 pour répondre aux besoins des organisations qui travaillent avec des partenaires externes, freelances ou prestataires. La dernière nouveauté, actuellement en préversion publique, permet de provisionner un Cloud PC pour une identité externe (invité B2B dans votre tenant Microsoft Entra ID).
Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un poste Windows 365 sécurisé.
Qui peut bénéficier de cette nouveauté ?
Nous venons de sortir il y a peu de la préversion privée, et nous sommes donc maintenant en préversion publique, avant une mise à disposition générale (GA) dans plusieurs mois je suppose. Tout utilisateur externe invité dans votre tenant Microsoft Entra ID peut donc en profiter.
Comme rappelé plus haut, les scénarios typiques sont : prestataires, auditeurs, partenaires de développement…
Le flux d’approvisionnement change-t-il pour ces utilisateurs invités ?
Non. Vous utilisez les mêmes polices de provisionnement Windows 365 et le même processus de licence que pour les Cloud PC internes.
Depuis quelles plate-formes le compte invité fonctionne ?
A ce jour où ces lignes sont écrites, la documentation Microsoft mentionne deux moyens possibles :
Cloud PC sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
Cloud PC joint à Entra ID
Police de provisionnement Windows 365 avec Single Sign-On activé
Quelles sont les principales limitations actuellement dans cette préversion ?
Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler le Cloud PC).
Pas de support pour Windows 365 Government ni pour les invités cross-cloud (Azure Gov, 21Vianet).
Pas d’authentification Kerberos/NTLM vers les ressources on-premises.
Quelques limites sur la Token Protection pour identités externes.
Quelle licence Windows 365 faut-il pour ces utilisateurs invités ?
Comme dit plus haut, il faut bien provisionner une licence dans votre tenant sur le compte invité.
Les licences détenues par un collaborateur externe dans son propre tenant ne confèrent aucun droit pour utiliser un Cloud PC dans votre tenant :
Si vous utilisez Windows 365 avec des identités externes (actuellement en préversion), il peut y avoir des considérations spéciales à prendre en compte pour la façon dont vous accordez des licences à d’autres produits et services de Microsoft pour ces identités externes.
Les licences attribuées à un collaborateur externe dans son propre locataire d’origine ne confèrent généralement pas de droits à Windows 365 ou à d’autres produits au sein de votre locataire. Par conséquent, nous vous recommandons généralement d’acheter le même type de licence que vous achetez pour les utilisateurs internes et de l’attribuer à l’identité du collaborateur externe dans votre locataire.
Par exemple, si vous attribuez des licences Microsoft 365 Apps en même temps que vos PC Windows 365 cloud et que vos collaborateurs externes ont besoin des mêmes droits, achetez une licence Microsoft 365 Apps et attribuez-la au collaborateur externe de votre locataire.
Vous devez donc acheter et attribuer les mêmes licences que pour vos utilisateurs internes (ex. Windows 365 Enterprise/Frontline, Microsoft 365 Apps si nécessaire).
Maintenant, il ne nous reste plus qu’à tester tout cela 😎
Cliquez sur Nouvel utilisateur, puis choisissez Inviter un utilisateur externe :
Renseignez l’adresse e-mail du compte Microsoft Entra de l’invité puis cliquez ici :
Attendez quelques secondes, puis constatez la réception de l’e-mail d’invitation dans la boîte du compte invité, et enfin cliquez sur lien présent dans ce dernier :
Cliquez sur Accepter pour rejoindre le tenant qui vous a invité :
Constatez l’absence du début du provisionnement du Cloud PC :
Vérifiez le groupe d’utilisateurs associé à votre politique de provisionnement Windows 365, puis et ajoutez-lui le nouvel utilisateur invité :
Constatez le début du provisionnement du Cloud PC :
Quelques temps plus tard, constatez le succès du provisionnement pour cet utilisateur invité :
Le provisionnement du Cloud PC est maintenant terminé. Nous allons maintenant pouvoir tester la connexion à ce poste avec notre utilisateur invité.
Etape III – Test de connexion invité depuis le navigateur internet :
Commençons nos tests par le navigateur internet. Pour cela, rendez-vous sur l’URL ci-dessous, puis authentifiez avec le compte invité de votre utilisateur :
https://windows.cloud.microsoft/
Une fois authentifié, constatez l’absence du nouveau Cloud PC provisionné sur votre tenant pour votre compte invité :
Ouvrez une nouvelle page internet en vous connectant, toujours avec le compte invité, sur une autre URL, contenant le domaine de votre tenant :
Vérifiez que l’URL reste bien sur le domaine de votre tenant, et que le Cloud PC invité apparaît :
Cliquez sur Connecter :
Cliquez à nouveau sur Se connecter :
Cliquez sur Oui :
Constatez la bonne ouverture de session de votre compte invité :
Ouvrez Windows Terminal :
Lancez la commande suivante afin d’afficher l’état de l’enregistrement du Cloud PC dans Entra ID :
dsregcmd /status
AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID (prérequis principal pour les Cloud PC invités).
EnterpriseJoined : NO
DomainJoined : NO : Normal pour un Cloud PC moderne en mode Entra join (non hybride).
TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
SSO / Primary Refresh Token :
AzureAdPrt : YES
DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :
Ouvrez Microsoft Edge, puis constatez l’absence de récupération automatique du jeton (token) de connexion pour le SSO :
Ouvrez Microsoft OneDrive, puis constatez, là aussi, l’absence de récupération automatique du token de session pour le SSO :
Malgré l’absence de SSO, la connexion depuis le navigateur internet se passe bien. Continuons les tests avec l’application Windows App.
Etape IV – Test de connexion invité depuis Windows App :
Avant de continuer, ouvrez les Paramètres de l’application Windows App, puis vérifiez la version installée :
Ouvrez PowerShell en tant qu’administrateur, puis lancez la commande ci-dessous pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :
Souci I – Impossible de se connecter malgré une version 24H2 :
Si, malgré le respect des prérequis, il est possible que vous rencontriez le blocage suivant au moment de vous connecter :
Ou ce message d’erreur là :
Cela vient peut-être de l’absence du correctif KB5065789 sur votre Cloud PC, pourtant en version 24H2.
Pour remédier à cette mise à jour manquante, retournez sur le portail Entra ID pour ajouter un utilisateur de votre tenant aux administrateurs locaux des machines jointes à Entra ID :
Ensuite, retournez sur le portail Azure pour récupérer l’adresse IP locale du Cloud PC invité :
Depuis un autre Cloud PC auquel vous avez déjà accès, connectez-vous à cette IP locale avec un des comptes administrateurs :
Attendez que l’ouverture de session se fasse :
Lancez la commande PowerShell suivante pour vérifier les correctifs installés :
Si besoin, allez dans Windows Update puis lancez la recherche de mises à jour :
Redémarrez si nécessaire :
Rouvrez la session avec l’administrateur local, puis relancez Windows Update si besoin :
Redémarrez à nouveau, si nécessaire :
Vérifiez avec la commande PowerShell que le correctif KB5065789 (24H2) est maintenant bien présent :
Retournez sur la page web de Windows 365 ouverte avec le compte invité :
Constatez cette fois la bonne ouverture de session sur votre compte invité :
Souci II – Impossible de choisir une entreprise via Windows App :
Si, dans Windows App, le choix d’une authentification alternative n’apparaît pas, et que l’application ne vous propose qu’une adresse e-mail à renseigner :
C’est qu’il vous manque une clef de registre Windows pour faire apparaître ce choix alternatif.
Pour cela, sur votre PC local, ouvrez PowerShell en tant qu’administrateur puis lancez la commande indiquée pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :
Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier, afin de voir le choix apparaître maintenant :
Souci III – Impossible de se connecter via Windows App – Erreur 7q6ch :
J’ai rencontré ce souci lors de l’authentification dans l’application Windows App, sur 2 postes uniquement. Les autres n’ont posé aucune difficulté.
Malgré une authentification réussie pour mon compte invité, le message d’erreur suivant apparaissait :
Suivi de ce seconde message :
Malgré plusieurs réinstallations de l’application Windows App, je n’ai pas encore trouvé la cause de ce souci. Je suis toujours en contact avec les équipes de Microsoft pour en comprendre la cause.
Conclusion
L’arrivée des Cloud PC Windows 365 pour identités externes simplifie enfin l’accès des prestataires et partenaires, sans créer de comptes temporaires.
La fonctionnalité reste en préversion publique avec plusieurs limites (SSO partiel, stratégies Intune incomplètes, pas de support Government/cross-cloud), mais Microsoft annonce déjà des évolutions à venir.
C’est donc le bon moment pour tester, identifier les impacts et se préparer à son adoption lorsque ces restrictions seront levées.
Attendez-vous au prochain article sur Azure Virtual Desktop 😎🤘😉
Windows 10 verra son support étendu s’achever le 14 octobre 2025, poussant beaucoup à envisager Windows 11. Comment vérifier la compatibilité de votre poste et quelles sont les solutions officielles ou détournées pour migrer même si votre matériel ne remplit pas tous les critères ? C’est ce que nous allons voir ensemble dans cet article consacré à la migration d’un poste, pleinement fonctionnel, mais qui ne satisfait pas toutes les conditions.
Il est parfois frustrant de constater l’« air du tout jetable » qui règne dans le monde de l’informatique : des machines parfaitement fonctionnelles se retrouvent considérées comme obsolètes dès qu’un détail matériel (TPM, Secure Boot ou CPU non listé) n’est pas validé.
Pourtant, nombre de ces postes ont encore de belles années devant eux et peuvent très bien faire le boulot sous Windows 11, si l’on savait simplement contourner ce petit verrou.
C’est d’ailleurs grâce à un message de Marjorie SIEGLER sur LinkedIn que j’ai découvert la méthode la plus simple pour faire sauter ce contrôle et donner une seconde vie à ces PC « délaissés ». Un grand merci à elle pour ce partage éclairé !
Quand Microsoft arrêtera-t-il le support de Windows 10 ?
Le support grand public (« Mainstream Support ») de Windows 10 a pris fin le 13 octobre 2020. Microsoft assure toutefois un support étendu (« Extended Support ») jusqu’au 14 octobre 2025, date à laquelle toutes les mises à jour de sécurité et correctifs pour Windows 10 cesseront d’être publiés.
Qu’est-ce que Windows 11 ?
Windows 11 est la version suivante de Windows après Windows 10. Publié officiellement par Microsoft en octobre 2021, il apporte un certain nombre de changements tant au niveau de l’interface utilisateur que des fonctionnalités sous-jacentes par rapport à Windows 10.
Quels sont les prérequis pour passer de Windows 10 à Windows 11 ?
Voici les conditions minimales à respecter pour passer de Windows 10 à Windows 11. Ces prérequis sont inchangés depuis leur publication initiale et doivent tous être satisfaits simultanément pour que l’upgrade in-place soit autorisée :
Catégorie
Prérequis minimaux
Processeur (CPU)
Processeur 64 bits cadencé à ≥ 1 GHz avec au moins 2 cœurs, figurant dans la liste officielle des CPU compatibles Windows 11 et prenant en charge les instructions SSE 4.1/4.2, AVX.
Mémoire vive (RAM)
4 Go ou plus.
Stockage
Disque (physique ou partition) d’au moins 64 Go d’espace disponible pour l’installation.
Firmware système
Démarrage en mode UEFI avec Secure Boot activé.
TPM (Trusted Platform Module)
Module TPM version 2.0 activé.
Carte graphique
Compatible DirectX 12 ou version ultérieure avec pilote WDDM 2.0.
Écran
Écran HD (720p) de plus de 9″ en diagonale, 8 bits par canal de couleur.
Connexion Internet et compte
Pour Windows 11 Home, un compte Microsoft et une connexion Internet sont nécessaires pour la configuration initiale.
Peut-on vérifier la compatibilité de son poste pour passer à Windows 11 ?
Microsoft propose une application gratuite, PC Health Check, qui analyse automatiquement votre machine et vous indique si elle remplit les conditions minimales pour Windows 11 :
Quid des extended security updates (ESU) pour Windows 10 ?
Les Extended Security Updates (ESU) pour Windows 10 sont un programme payant permettant aux utilisateurs de continuer à recevoir uniquement les correctifs de sécurité (critique et important) après la date de fin de support officielle de Windows 10 (14 octobre 2025).
Le support standard de Windows 10 s’achève le 14 octobre 2025. Les ESU Windows 10 débutent alors, et s’étendent jusqu’au 14 octobre 2028 (trois années au total).
Pour les acheter, vous pourrez passer via le Volume Licensing (Microsoft 365, Microsoft 365 FPP, etc.) ou auprès d’un partenaire Microsoft avec un contrat EA unqiuement (pour l’instant).
Pour information, vous aurez la possibilité d’enrôlement gratuit pour les ESU quand les machines Windows 10 sont hébergées sur :
Azure Virtual Desktop
Azure VM
Windows 365
Voici d’ailleurs un tableau Microsoft montrant les autres ESU actuellement en vigueur :
Peut-on malgré tout migrer sur Windows 11 sans valider tous les prérequis ?
Il n’existe pas de voie « officielle » pour forcer l’installation de Windows 11 sur un matériel qui ne respecte pas tous les prérequis. Microsoft bloque volontairement l’upgrade in-place (et parfois même la clean install) dès qu’un des critères essentiels (TPM 2.0, Secure Boot, CPU compatible, etc.) n’est pas rempli.
Cependant, plusieurs utilisateurs avancés ont découvert des contournements (workarounds) pour installer Windows 11 sur du matériel non pris en charge. Voici les principales méthodes, ainsi que leurs risques et limitations.
Méthode 1 : modification du registre avant l’upgrade in-place :
Méthode 2 : clean install depuis un ISO modifié (offline) :
Méthode 3 : utilisation d’un script tiers (par exemple Flyby11) :
Méthode 4 : utilisation d’un argument d’installation :
Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre afin de tester la méthode 4 sur un environnement de test :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice de mise à jour d’un poste Windows 10 non compatible vers Windows 11, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
N’ayant pas d’anciens postes physiques à disposition (à part celui de mon fils 🤣), j’ai choisi de le simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.
Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.
Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
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ésent dans la famille Dsv3, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées, puis 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 hôte (Hyper-V) :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
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, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :
Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Créez un nouveau volume NTFS :
L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.
Etape II – Création de la machine virtuelle Windows 10 :
Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :
Attendez la fin du téléchargement pour continuer :
Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :
Cliquez-ici pour créer votre machine virtuelle invitée :
Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :
Choisissez Génération 1 :
Modifiez la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 10 :
Une fois la machine virtuelle Windows 10 créée, modifiez sa configuration comme ceci :
Double-cliquez sur votre machine virtuelle, puis cliquez-ici pour lancer le démarrage de la VM :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows :
Une fois Windows 10 correctement installé, installez PC Health Check afin de constater l’impossibilité en l’état actuel de basculer sur Windows 11 :
Nous allons maintenant pouvoir tester la méthode alternative pour installer malgré tout Windows 11 sur cette machine virtuelle
Etape III – Mise à jour vers Windows 11
Avant de mettre à jour vers Windows 11, commencez par ouvrir Windows Update afin de mettre à jour tous les patchs existants :
Une fois tous les patchs installés, vérifiez à nouveau Windows Update :
Téléchargez cette fois l’image ISO de Windows 11 :
Une fois téléchargée, extrayez le contenu de l’ISO dans un dossier :
Puis créez un fichier texte avec le contenu suivant :
setup.exe /product server
Sauvegardez ce fichier texte avec une terminaison BAT :
Ouvrez en mode administrateur l’exécuteur de commande Windows, puis lancez l’application setup.bat :
Autorisez l’action en cliquant sur Oui :
Attendez plusieurs minutes que l’installation se prépare :
Cliquez sur Suivant :
Attendez la vérification de mises à jour Windows :
Attendez encore quelques minutes :
Acceptez les termes et conditions de Microsoft Windows :
Cliquez-ici pour conserver les informations en place sur votre poste :
Attendez quelques minutes :
Attendez la seconde vérification des mises à jour Windows :
Cliquez-ici pour démarrer l’installation de Windows 11 :
Attendez plusieurs minutes que l’installation se termine :
Attendez encore plusieurs redémarrages de votre poste :
Authentifiez-vous avec votre compte sur Windows 11 :
Retournez dans les paramètres Windows afin de vérifier le bon changement de version de votre OS :
Retournez à nouveau dans Windows Update pour vérifier, puis lancez les nouvelles mises à jour disponibles :
Conclusion
En définitive, si vous êtes dans la situation où votre poste Windows 10 parfaitement fonctionnel ne remplit pas tous les critères officiels de Windows 11, sachez qu’il existe plusieurs moyens de contourner ces contrôles et d’offrir une seconde vie à votre machine.
Gardez toutefois à l’esprit que ces contournements ne sont pas supportés officiellement par Microsoft : vous prenez le risque de ne plus recevoir certaines mises à jour futures, voire de rencontrer des limitations sur les fonctionnalités de sécurité (Windows Hello, BitLocker, etc.)
En revanche, si votre objectif est de repousser l’obsolescence de machines qui tournent encore très bien, l’une de ces méthodes peut vous permettre de migrer vers Windows 11 sans changer de matériel immédiatement.
Depuis 2024, Microsoft propose une solution de sauvegarde directement intégrée à Microsoft 365. Cette solution apporte une couche de sécurité pour les informations stockées sur SharePoint, OneDrive et Exchange. Un article est d’ailleurs disponible ici. Mais que propose Veeam comme solution de sauvegarde SaaS pour protéger à son tour les données 365 ?
Comme bien d’autres éditeurs spécialisés dans la sauvegarde, Veeam propose justement un produit SaaS pour répondre à ce besoin : Veeam Data Cloud for Microsoft 365.
Qu’est-ce que Veeam Data Cloud SaaS Backup ?
Veeam Data Cloud for Microsoft 365 (VDC) est une solution BaaS (Backup as a Service) conçue pour protéger et restaurer de manière sécurisée les données hébergées dans le cloud Microsoft et dans certaines autres applications SaaS.
Accès aux services Veeam Data Cloud depuis un navigateur web ;
Le coût du stockage des sauvegardes est inclus dans l’abonnement, avec stockage illimité ;
Choix de la région Azure préférée pour héberger les sauvegardes ;
Veeam ajuste automatiquement les ressources cloud sans frais supplémentaires ;
Aucun frais additionnel pour les opérations de restauration ;
Après annulation ou résiliation de l’abonnement, les sauvegardes restent disponibles pendant 30 jours supplémentaires ;
Le support technique de l’ensemble du service est 100 % assuré par Veeam.
Dois-je déployer des ressources dans Azure ?
Non, car Veeam Data Cloud for Microsoft 365 est une solution 100 % SaaS. Elle inclut le logiciel, l’infrastructure de sauvegarde et le stockage. Tout est directement géré par Veeam.
Contrairement à la solution Veeam Backup for Microsoft 365 disponible sur Azure Marketplace, avec VDC vous n’avez rien à provisionner :
vous vous connectez simplement via une interface web pour créer vos tâches de sauvegarde, définir vos politiques de rétention et lancer vos restaurations, sans vous soucier du provisionnement ni de la maintenance de l’infrastructure sous-jacente.
Quels sont les différents plans possibles ?
Veeam Data Cloud for Microsoft 365 propose trois formules : Express, Flex et Premium. Toutes les fonctionnalités sont détaillées ici :
Express s’appuie exclusivement sur le Microsoft 365 Backup Storage pour offrir des sauvegardes ultrarapides et des restaurations en masse, sans limitation de débit ;
Flex utilise un compte Azure Storage dédié, géré par Veeam, avec choix de la région et granularité de restauration (fichiers, versions, recherches avancées…) ;
Premium combine la vitesse et l’échelle d’Express avec le contrôle, la flexibilité et la granularité de Flex, le tout dans une même interface.
En résumé :
Express = vitesse (M365 Backup Storage) ;
Flex = autonomie et granularité (Azure Storage géré par Veeam) ;
Premium = les deux mondes réunis.
Voici un tableau comparatif de prix de ces trois plans en engagement mensuel :
Et voici un tableau comparatif de prix de ces trois plans en engagement annuel :
Comment est-on facturé par Veeam ?
La facturation de Veeam Data Cloud for Microsoft 365 se fait à l’usage et dépend du type de charge de travail protégé.
Vous pouvez souscrire via Azure Marketplace, des revendeurs ou des Veeam Cloud & Service Providers. Selon le canal et le contrat, vous pouvez opter pour un paiement anticipé (abonnement annuel ou multi-annuel) ou un paiement en arriéré, basé sur la consommation mensuelle.
Comment et où la donnée est sauvegardée ?
Dans Veeam Data Cloud SaaS Backup, vos sauvegardes et les options disponibles dépendent du plan choisi :
Express : pas de choix d’emplacement ; plusieurs copies redondantes dans la limite de sécurité Microsoft.
Flex : sélection de la région de stockage Azure souhaitée ; copies redondantes et sauvegarde distincte dans une autre région Azure.
Premium : sélection de la région de stockage Azure souhaitée ; respect strict de la règle 3-2-1 avec plusieurs options de sauvegarde et de restauration.
Comment tester Veeam Data Cloud SaaS Backup ?
Voici les différentes étapes que nous allons suivre afin de tester la solution Veeam Data Cloud SaaS Backup sur un environnement Microsoft 365 de test :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de réaliser nos tests sur Veeam Data Cloud SaaS Backup, nous allons avoir besoin de :
Un tenant Microsoft actif
Une souscription Azure valide
Commençons par déployer la solution depuis Azure Marketplace.
Etape I – Déploiement de VDC :
Depuis le portail Azure, recherchez Veeam Data Cloud for Microsoft 365 :
Déployez la solution SaaS dans la souscription, le groupe de ressources et la région Azure de votre choix :
Choisissez votre plan, puis lancez la validation Azure :
Une fois la validation réussie, créez la solution :
Attendez quelques minutes le temps de la configuration de Veeam Data Cloud SaaS Backup :
La notification Azure apparaît alors :
Une fois la configuration de Veeam Data Cloud SaaS Backup terminée, la notification Azure se met à jour :
Retournez dans le groupe de ressources Azure utilisé par votre solution SaaS, puis cliquez dessus :
Un détail de la souscription achetée s’affiche alors :
Cliquez sur le bouton de finalisation de la configuration :
Définissez votre région :
Vérifiez le plan souscrit :
Renseignez les informations de votre entreprise, puis cliquez sur Soumettre :
Une fois la souscription VDC activée, cliquez sur ici pour basculer sur la console de gestion :
Liez l’authentification avec votre Azure AD (Entra ID) en acceptant les autorisations :
Cliquez sur Acceptez :
Acceptez les conditions d’utilisations de VDC :
Définissez les notifications souhaitées par VDC, puis cliquez sur Suivant :
Pour vos données, choisissez :
la région Azure de votre choix,
la durée de rétention des données,
Puis copiez le code donnée afin d’effectuer une délégation d’authentification :
Dans ce nouvel onglet, collez le code précédemment copié, puis cliquez sur Suivant :
Authentifiez-vous avec un compte administrateur global de votre tenant :
Cliquez sur Acceptez :
Une fois l’authentification réussie, vous pouvez fermer cet onglet :
Les deux applications Veeam précédemment acceptées sont alors visibles :
Continuez la configuration de VDC en cliquant sur Connecter :
Définissez le modèle d’adaptation de nombre de licences VDC, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez-ici pour créer votre propre police de sauvegarde VDC :
Confirmez votre choix en cliquant sur Non :
Notre environnement VDC est maintenant en place et opérationnel. Comme nous avons décidé de créer notre propre police de sauvegarde, nous avons besoin d’en créer une pour définir quelles données 365 doivent être sauvegardées.
Etape II – Configuration de la police de sauvegarde :
Depuis ce menu, cliquez-ici pour créer une nouvelle police de sauvegarde VDC :
Nommez votre police de sauvegarde, puis cliquez sur Suivant :
Définissez les objets à sauvegarder (Exchange, OneDrive, SharePoint, Teams…), puis cliquez sur Créer :
La politique apparaît dans la liste :
Consultez le menu Facturation pour voir les licences consommées :
Retournez sur votre police VDC, puis démarrez celle-ci :
Attendez la fin de traitement de celle-ci :
Attendez le changement de statut, ainsi que l’apparition des menus dédiés à la sauvegarde dans la section de gauche :
Cliquez sur votre police afin de constater les différents points de sauvegarde :
Retournez dans le menu du tableau de bord afin de voir les informations mises en avant par VDC :
En bas de ce tableau de bord figurent les types de données sauvegardées ainsi qu’un journal d’activités des utilisateurs :
Retournez dans le menu de facturation afin de voir les licences nouvellement consommées :
Affichez le détail des licences consommées par utilisateur :
Il est même possible d’effectuer une liaison de type webhook dans Teams :
Les opérations de restauration entraînent alors l’apparition d’un message dans Teams :
Notre police de sauvegarde est maintenant en place et données ont déjà été sauvegardées. Testons maintenant la partie restauration des données sur différents services de Microsoft 365.
Etape III – Tests de restauration :
Commencez par effectuer un test de restauration en supprimant un ou plusieurs messages dans votre messagerie Outlook :
Sur la console VDC, retournez sur le type de données Outlook, puis laissez-vous guider dans la restauration :
Prévisualisez au besoin le ou les e-mails à restaurer :
Cliquez sur Restaurer pour démarrer le processus :
La notification suivante de VDC apparaît alors :
L’activité de restauration est conservée et visible ici :
Retournez dans votre messagerie Outlook afin de constater le retour des e-mails restaurés :
Effectuez un test de restauration en supprimant un ou plusieurs fichiers dans votre compte OneDrive :
Sur la console VDC, retournez sur le type de données OneDrive, puis laissez-vous guider dans la restauration comme pour Outlook :
Retournez sur votre compte OneDrive afin de constater le retour des fichiers restaurés :
Effectuez un test de restauration en supprimant un ou plusieurs fichiers dans l’une de vos équipes Teams :
Sur la console VDC, retournez sur le type de données Teams, puis laissez-vous guider dans la restauration comme pour Outlook :
Retournez sur votre équipe Teams afin de constater le retour des fichiers restaurés :
Il en sera de même pour la restauration de fichiers ou de données SharePoint :
Enfin, il existe également une fonction de recherche globale, très pratique pour retrouver la données à restaurer :
La sauvegarde de certaines données 365 nécessite une configuration supplémentaire. Par exemple, il est également possible d’activer en plus la sauvegarde des messages des chats Teams.
Etape IV – Sauvegarde des chats Teams :
Pour cela, rendez-vous dans l’application VDC automatiquement créée et visible dans votre portail Entra ID, puis copiez l’ID de votre application :
Retournez dans la console VDC afin d’activer la sauvegarde des chats Teams :
Depuis le portail Azure, ouvrez le Cloud Shell :
Saisissez la commande suivante afin de créer un accès Graph payant en replaçant les valeurs en gras :
az graph-services account create --resource-group VOTRE_RG --resource-name myGraphAppBilling --subscription VOTRE_SUB --location global --app-id VOTRE_APP_ID
Confirmez l’action avec Y :
Obtenez le résultat de commande suivant :
La ressource Graph est alors visible sur dans votre groupe de ressources :
Retournez sur la console VDC afin de modifier votre police de sauvegarde afin d’y inclure les chats :
Après une nouvelle sauvegarde des données, consultez les messages de chat Teams sauvegardés par VDC :
Conclusion :
Veeam Data Cloud for Microsoft 365 offre une solution de sauvegarde complète et clé en main pour protéger vos environnements Microsoft 365 sans devoir gérer ni provisionner d’infrastructure.
Son déploiement via le portail Azure est rapide et intuitif, et la console web Veeam centralise la création des politiques de sauvegarde, le suivi des activités et l’exécution des restaurations, qu’il s’agisse de mails Outlook, de fichiers OneDrive, …
Grâce à ses trois formules (Express, Flex et Premium), vous pouvez adapter la sauvegarde à vos besoins de rapidité, de contrôle et de granularité, tout en bénéficiant d’un stockage inclus et d’une facturation à l’usage.
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.
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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.
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 :
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.
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.
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.
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.
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.
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.
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.
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 IPlocationindique 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.
