Aujourd’hui, on se retrouve pour tester ensemble une clef FIDO2 sur un environnement Microsoft Cloud. Fini les galères des mots de passe, place à une sécurité renforcée et simplifiée. Dans cet article, je vous partage mon expérience, étape par étape, de la configuration sur un tenant Microsoft à la vérification des connexions via USB et NFC. Venez découvrir comment, avec une approche à la fois technique et accessible, on peut repenser la manière de sécuriser nos identités en ligne.
Qu’est-ce que FIDO ?
FIDO, qui signifie Fast IDentity Online, désigne un ensemble de normes d’authentification qui utilisent la cryptographie à clé publique pour se passer des mots de passe traditionnels.
Concrètement, l’objectif de FIDO est de renforcer la sécurité en ligne en utilisant des méthodes d’authentification plus fiables et ergonomiques, comme les dispositifs matériels (clés de sécurité) ou l’authentification biométrique (empreintes digitales, reconnaissance faciale).
Pour moi, c’est une approche qui simplifie l’expérience utilisateur car, tout en augmentant considérablement la sécurité, ces passkeys sont interopérables, ce qui signifie qu’une seule passkey peut être utilisée sur plusieurs sites ou comptes.
D’ailleurs, j’avais déjà parlé de l’intégration d’une authentification FIDO2 pour le service Azure Virtual Desktop juste ici :
Qu’est-ce que l’Alliance FIDO ?
Créée en 2012, FIDO Alliance est une association d’entreprises du secteur technologique ayant pour objectif de changer la manière dont nous nous authentifions en ligne. L’idée de ce consortium est de se passer des mots de passe, souvent vulnérables, en favorisant des méthodes d’authentification plus sûres et plus simples à utiliser :
Pour résumer, FIDO Alliance réunit de nombreux acteurs du secteur (comme Google, Microsoft, mais pas que) pour développer des standards ouverts, tels que FIDO U2F et FIDO2, qui permettent par exemple d’utiliser des dispositifs matériels (clefs de sécurité) ou des méthodes biométriques pour s’authentifier.
FIDO vs U2F vs FIDO2 ?
Le protocole FIDO original, alias FIDO 1.0, était la première itération de la norme d’authentification FIDO. Publié en 2014, il visait à remplacer les mots de passe traditionnels par des données biométriques et des jetons matériels. Elle comportait à la fois FIDO UAF (Universal Authentication Framework) et FIDO U2F (Universal Second Factor).
En 2016, le World Wide Web Consortium (W3C) et la FIDO Alliance ont commencé à collaborer pour normaliser l’authentification FIDO. Cela a conduit au lancement de FIDO2 en 2018, qui offre une approche plus complète et standardisée de l’authentification sans mot de passe. De nombreux navigateurs célèbres, dont Firefox et Chrome, ont mis en œuvre la norme, ce qui a contribué à son adoption.
FIDO2 a deux composantes principales : WebAuthn et CTAP (Client to Authenticator Protocol). Ensemble, WebAuthn et CTAP offrent une expérience de connexion cryptographiquement sécurisée, pratique et interopérable.
En résumé, les principales différences entre FIDO 1.0 et FIDO2 sont la normalisation, la portée, l’interopérabilité et l’adoption. FIDO2 est un protocole plus complet et normalisé qui est pris en charge par tous les principaux navigateurs et systèmes d’exploitation, y compris Android, IOS, MacOS et Windows.
FIDO2.1 est une petite évolution de la spécification FIDO2 qui vise à combler certaines limites et à renforcer à la fois la sécurité et l’expérience utilisateur. Concrètement, FIDO2.1 apporte notamment :
Une gestion améliorée des PIN et des mécanismes d’authentification locales, avec des règles plus strictes pour éviter les codes trop faibles.
Des processus d’enrôlement et de récupération des identifiants optimisés, pour faciliter la réinitialisation ou le transfert sécurisé des clés.
Une meilleure interopérabilité entre les différents types d’authentificateur (qu’ils soient matériels ou intégrés à un appareil), ce qui simplifie leur déploiement dans des environnements hétérogènes.
En résumé, il ne s’agit pas d’un changement radical, mais plutôt d’un raffinement qui permet d’offrir une sécurité renforcée tout en rendant l’usage du système encore plus fluide et adaptable.
Quelles sont les méthodes de connexion d’une clef FIDO2 ?
USB-A et USB-C :
Pour les PC, on branche la clé directement dans un port USB-A ou USB-C.
Pour les smartphones, il est souvent possible de les utiliser via un câble OTG ou directement sur un port USB-C, selon le modèle.
NFC :
De nombreuses clés intègrent une puce NFC, ce qui permet une connexion sans contact avec des smartphones compatibles (par exemple, iPhone à partir d’iOS 13.3 et de nombreux appareils Android).
À noter toutefois que sur Android, les clés protégées par PIN ne supportent pas la connexion NFC.
La prise en charge des clés de passage de FIDO2.1 (à savoir les clés résidentes protégées par un code PIN) a été introduite dans le cadre de Google Play Services v23 et uniquement par le biais de la méthode de transport USB. Cela signifie donc que :
Android ne prend en charge les identifiants FIDO protégés par un code PIN que si Google Play Services est présent. Android ne prend pas en charge les informations d’identification FIDO protégées par un code PIN via NFC.
Quels sont les risques encourus si je perds ma clef FIDO2 ?
La perte de votre clé FIDO2 peut poser des problèmes d’accès à vos comptes, mais les risques de compromission sont fortement limités. En effet, ces clés reposent sur la cryptographie asymétrique : même si quelqu’un mettait la main sur votre clé, il ne pourrait pas extraire la clé privée qui reste protégée.
De plus, la plupart des dispositifs FIDO2 nécessitent un code PIN ou une authentification biométrique pour être utilisés, ce qui ajoute une couche de sécurité supplémentaire.
Néanmoins, il est important de prévoir une solution de secours. Par exemple, en enregistrant plusieurs clés ou en activant d’autres méthodes de récupération, vous pourrez rapidement révoquer une clé perdue et en associer une nouvelle, sans compromettre l’accès à vos comptes.
Dois-je acheter une licence payante d’Entra ID pour utiliser une clef FIDO2 ?
Non, il n’est pas nécessaire d’acheter une licence Entra ID spécifique pour utiliser une clé FIDO2 en authentification sans mot de passe.
Cette fonctionnalité est incluse dans toutes les éditions d’Entra ID, y compris la version gratuite, même si certaines fonctionnalités avancées (comme l’accès conditionnel) nécessitent des licences Entra ID Premium.
Qui sont Token2 ?
La société Token2 a vu le jour en 2014. Il s’agit d’une entreprise suisse spécialisée dans la cybersécurité, et plus précisément dans l’authentification multifactorielle.
Le siège de Token2 se situe à Versoix, dans la République et le Canton de Genève, en Suisse.
Pour faire simple, ils conçoivent et développent des solutions matérielles et logicielles qui rendent l’authentification en ligne à la fois plus sûre et plus pratique.
D’ailleurs, Token2 est aussi un membre certifié de l’alliance FIDO :
Token2, fier membre de l’Alliance FIDO, a obtenu son certificat FIDO initial en 2019 et fournit une variété de clés de sécurité FIDO depuis plus de 5 ans.
En plus des clés FIDO2 ordinaires, Token2 est ravie de présenter sa très attendue série PIN+, une ligne révolutionnaire de clés de sécurité FIDO2 qui a récemment reçu la certification de l’Alliance FIDO.
Ces clés de sécurité de pointe introduisent des règles avancées de complexité du code PIN qui redéfinissent les standards de sécurité.
Pour aller toujours plus loin dans la sécurité de leurs produits, Token2 a également fait l’objet d’un audit indépendant (réalisé par Compass) en 2024 sur le firmware open source (disponible sur GitHub) de leurs clés Token2 PIN+ (voir leur outil de test de PIN), confirmant leur robustesse et leur transparence.
Enfin, j’en profite pour dire un grand merci à Manon, Emin et Naila pour me permettre de tester vos produits !
Ce qui m’a séduit d’emblée sur cette clef FIDO2.1 R3, c’est la présence du triple combo USB-A, USB-C et NFC, ainsi que le support des normes FIDO et FIDO2.1( avec le support d’OpenPGP et d’OTP) :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser nos tests sur une clef FIDO2.1, il vous faudra disposer de :
Un tenant Microsoft
J’ai choisi dans la première partie de l’article de tester la mise en place d’une clef FIDO2 sur un tenant ne disposant d’aucune licence Entra ID Premium.
Pour vérifier si votre tenant dispose de licences ou non Entra ID Premium, je vous propose de commencer par vérifier cette information
Etape I – Configuration du tenant :
Allez dans la page suivante d’Entra afin de constater la présence, ou non, de licences Entra Premium sur votre tenant :
Ensuite, basculez l’onglet des propriétés afin de déterminer la méthode de sécurité appliquée sur votre tenant :
Enfin, vérifiez l’activation, ou non, de différentes méthodes d’authentification sur cette page :
Notre environnement est donc dans sa configuration la plus basique. Avant de modifier celle-ci, je vous propose de constater les méthodes de sécurité déjà disponibles sur notre utilisateur.
Etape II – Ajout de la méthode d’authentification FIDO2 :
Pour cela, rendez-vous sur la page suivante de votre utilisateur, puis cliquez sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Constatez la liste des méthodes d’authentification déjà accessibles à votre utilisateur :
Retournez sur la page des méthodes d’authentification Entra ID via cette page, puis cliquez-ici :
Activez la méthode FIDO2 :
Configurez au besoin les options de cette méthode, puis cliquez sur Sauvegarder :
Vérifiez le changement de statut pour cette méthode d’authentification :
Attendez environ 5 à 10 minutes avant de continuer la configuration de votre utilisateur.
Etape III – Ajout de la première clef FIDO2 :
Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez à nouveau sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Constatez l’apparition de nouvelles méthodes dans la liste de celles disponibles pour votre utilisateur :
Sélectionnez la méthode appelée Clef de sécurité :
Avant cela, Microsoft souhaite vérifier votre identité par une autre méthode MFA déjà en place, cliquez donc sur Suivant :
Réussissez le challenge MFA avec Microsoft Authenticator :
Une fois réussi, recommencez le processus d’ajout, puis cliquez-ici :
Cliquez sur Suivant :
Microsoft communique alors avec votre OS Windows afin de vérifier et d’enrôler la clef FIDO2 :
Attendez encore quelques secondes :
Confirmez les informations de compte, puis cliquez sur OK :
Cliquez sur OK :
Saisissez le code PIN déjà configuré sur votre clef FIDO2, puis cliquez sur OK :
Touchez physiquement la zone prévue à cet effet pour terminer :
Windows confirme le bon enrôlement de la clef FIDO2 chez Microsoft, cliquez sur OK :
Nommez votre clef FIDO2 afin de l’identifier par la suite plus facilement, puis cliquez sur Suivant :
Cliquez sur Terminer :
Constatez l’apparition de celle-ci dans les informations de sécurité de votre utilisateur :
Il est très fortement conseillé d’enrôler toujours 2 clefs afin d’utiliser la seconde en cas de secours.
Testons maintenant comment l’expérience utilisateur est impactée par l’ajout de cette méthode d’authentification FIDO2.
Etape IV – Test de connexion FIDO2 sur PC :
Sur votre poste, ouvrez un navigateur internet en session privée :
Au lieu de saisir le mot de passe de votre utilisateur, cliquez comme ceci :
Attendez quelques secondes :
Renseignez le code PIN de votre clef FIDO2 :
Touchez la zone prévue à cet effet pour confirmer l’authentification :
Cliquez sur Oui :
Et vous voilà correctement authentifié sur le portail de Microsoft Office 365 :
Nous avons vu l’impact de l’authentification d’une clef FIDO2 pour un compte Cloud de Microsoft. Intéressons-nous maintenant à la nouvelle clef FIDO2 proposée par Token2 et ses différentes possibilités d’authentification.
Etape V – Ajout de la clef FIDO2 Token2 T2F2-Dual:
avant d’utiliser cette nouvelle clef FIDO2 pour un compte, il est nécessaire de lui configurer un code PIN.
Pour cela, rendez-vous dans le menu suivant des paramètres Windows :
Cliquez sur le bouton Gérer :
Touchez la zone prévue à cet effet de votre nouvelle clef FIDO2 :
Cliquez-ici pour configurer le code PIN :
Testez un code PIN simple à 4 caractères afin de constater le refus de la nouvelle clef FIDO2 d’accepter cette valeur trop courte :
Testez un code PIN reprenant une simple suite de chiffres à 6 caractères afin de constater un second refus pour accepter cette valeur trop simple :
Renseignez cette fois 6 caractères aléatoires afin de constater l’acceptation de la valeur complexe :
Si nécessaire, il vous est toujours possible de changer ce code PIN en cliquant ici :
Il vous sera demandé de renseigner l’ancien code PIN avant de pouvoir en configurer un nouveau dans le but de conserver les identités déjà configurées :
Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Sélectionnez à nouveau Clef de sécurité, puis repassez sur toutes les étapes afin que votre nouvelle clef FIDO2 apparaisse dans la liste de ses méthodes d’authentification :
Notre nouvelle clef FIDO2 est maintenant en place pour notre utilisateur.
Comme sa méthode d’authentification via le port USB est la même que pour la première clef, testons directement la possibilité de connexion via NFC depuis un smartphone.
Etape VI – Test de connexion NFC sur smartphone :
Si votre smartphone vous permet une connexion via NFC : ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :
Saisissez le compte de votre utilisateur, puis cliquez sur Suivant :
Sans même saisir son mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :
Le message suivant vous invite à rapprocher ou à connecter votre clef FIDO2 à votre smartphone :
Dans le cadre du NFC, approchez votre clef de sécurité FIDO2 en haut de votre smartphone comme ceci :
Retirez la clef, puis saisissez le code PIN de votre clef FIDO2 :
Le message suivant vous invite à rapprocher à nouveau votre clef FIDO2 à votre smartphone :
Rapprochez une seconde fois votre clef FIDO2 afin de confirmer l’authentification de votre compte, puis cliquez sur Oui :
Constatez la bonne connexion de votre utilisateur aux services de Microsoft :
Comme annoncé plus haut, certains smartphones de la marque Android ne permettent pas la connexion NFC à votre compte dans le cadre d’une clef FIDO2 protégée par un code PIN.
Etape VII – Test de connexion USB-C sur smartphone :
Si votre smartphone ne vous permet pas la connexion via NFC : ouvrez un navigateur internet en session privée, rendez-vous sur la page officielle de Microsoft office, saisissez le nom de compte, puis cliquez sur Suivant :
Sans même saisir de mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :
Cliquez sur le bouton ci-dessous :
Le message suivant vous invite à connecter votre clef FIDO2 à votre smartphone :
Connectez votre clef de sécurité FIDO2 via USB-C, puis saisissez le code PIN de celle-ci :
Touchez physiquement la zone prévue à cet effet pour terminer :
Cliquez sur Oui :
Constatez la bonne connexion de votre utilisateur aux services de Microsoft :
Etape VIII – Ajout d’un accès conditionnel FIDO2 :
Depuis votre portail Entra ID, rendez-vous dans le paramétrage des Accès conditionnels afin de constater le besoin de licence Entra ID Premium pour activer cette fonction :
Achetez une licence Entra ID Premium ou basculez sur un tenant en disposant déjà :
Vérifiez que la sécurité par défaut de votre tenant est désactivée au profit de l’accès conditionnel :
Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :
Configurez celle-ci :
Puis créez votre nouvelle Police d’accès conditionnel :
Saisissez un nom à votre police, sélectionnez votre utilisateur de test, ajoutez l’application Azure, puis cliquez ici :
Autorisez l’accès sous réserve de satisfaire votre méthode d’authentification renforcée :
Ajoutez si besoin une fréquence d’authentification, puis créez votre police d’accès conditionnel :
Attendez quelques minutes, ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :
Saisissez le nom et le mot de passe de votre compte de test, puis cliquez comme ceci :
Vous voilà correctement authentifié sur le portail de Microsoft Office 365 :
Toujours en navigation privée, ouvrez un nouvel onglet pour vous rendre sur le portail Azure, puis constatez le besoin d’un complément d’authentification FIDO2 :
Saisissez le code PIN de votre clef FIDO2 :
Touchez votre clé FIDO2 sur la zone prévue à cet effet :
Vous voilà correctement authentifié sur le portail Azure :
Avant de conclure cet article, je trouvais intéressant de parler de certains outils très pratiques et mis à disposition par Token2 sur leur site.
Celui-ci vous permet de tester en direct l’enregistrement et l’authentification via des clés FIDO2 et passkeys. Concrètement, il offre une expérience pratique pour :
Enregistrement (Registration) : Vous pouvez inscrire votre clé de sécurité (physique ou intégrée, c’est-à-dire un authentificateur de plateforme) en utilisant l’API WebAuthn. Lorsque la clé clignote, il suffit de toucher le bouton, scanner l’empreinte ou utiliser le NFC (pour les appareils compatibles) pour finaliser l’inscription.
Authentification (Login) : Une fois la clé enregistrée, l’outil simule un processus de connexion sécurisé. Vous pouvez tester différentes configurations de demande de PIN (toujours, si un PIN est défini, ou jamais) pour voir comment cela influence le comportement de l’authentification.
L’outil fido2-manage est un utilitaire de gestion pour les clés de sécurité conformes à la norme FIDO2.1. Concrètement, il permet de :
Lister les dispositifs connectés : Afficher la liste des clés FIDO2.1 détectées.
Afficher des informations détaillées : Consulter les données techniques de la clé (modèle, AAGUID, certificats d’attestation, etc.).
Gérer les passkeys : Visualiser et supprimer les clés résidentes (passkeys) stockées sur l’appareil.
Configurer ou modifier le PIN : Définir, changer ou forcer une modification du code PIN de la clé.
Réinitialiser la clé : Effectuer une réinitialisation aux paramètres d’usine (en notant que cette opération est possible uniquement dans un court laps de temps après la connexion).
Conclusion
En fin de compte, cette aventure avec la clef FIDO2, notamment la PIN+ Dual Release3, m’a prouvé que la sécurité peut être à la fois robuste et intuitive. Que ce soit pour se connecter via USB ou NFC, l’expérience utilisateur reste fluide et rassurante.
Tester ces solutions, c’est un peu comme prendre un virage vers l’avenir de l’authentification : simple, efficace et sans prise de tête.
Merci d’avoir suivi ce test avec moi, et à très bientôt pour de nouvelles explorations tech !
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.
L’actualité concernant l’intelligence artificielle défile à un rythme effréné. Avec cette avalanche de nouveaux outils, de techniques et de possibles usages, combinant à la fois de réelles avancées, mais aussi parfois des discours marketing très prometteurs, chacun se doit de faire sa propre analyse, et de trier dans ces nouveautés les mises applications possibles dans au quotidien.
Qu’est-ce que les vecteurs dans le domaine de l’IA ?
Dans le domaine de l’IA, un vecteur est généralement utilisé pour représenter des données numériques. Un vecteur est une liste ordonnée de nombres. Par exemple, dans un espace à trois dimensions, un vecteur pourrait être représenté comme [3, 4, 5], où chaque nombre représente une dimension spécifique.
Dans l’IA, les vecteurs, c’est-à-dire des représentations numériques (ou embeddings) de données permettent donc de transformer du texte, des images ou d’autres données en une série de nombres qui représentent leurs caractéristiques essentielles. Ces représentations numériques facilitent la comparaison et la mesure de la similarité entre différents éléments.
L’embedding est une méthode de transformations de données provenant d’images, de textes, de sons, de données utilisateur, ou de tout autre type d’information, en vecteurs numériques. Cela revient à traduire le langage humain en une langue que les machines peuvent interpréter, capturant ainsi les nuances sémantiques ou contextuelles des éléments traités.
Grâce à une IA, la façon de rechercher des informations pertinentes repose sur la comparaison des vecteurs pour identifier les documents ou les images similaires. En d’autres termes, les vecteurs aident à comprendre et à exploiter la signification des données pour améliorer la précision des résultats de recherche.
Où sont stockés les vecteurs ?
Traditionnellement, les vecteurs étaient stockés dans des bases de données dédiées, comme Pinecone ou Milvus, conçues spécifiquement pour gérer des données vectorielles et optimiser les recherches par similarité.
Cependant, avec l’évolution des technologies, certains SGBD relationnels, comme Azure SQL Database, intègrent désormais un support natif pour les vecteurs. Cela permet de stocker et d’interroger directement des vecteurs au sein d’une base de données SQL classique, simplifiant ainsi l’architecture des applications et réduisant la nécessité d’avoir un système séparé.
Depuis quand Azure SQL Database peut stocker les vecteurs ?
Le type vector est un nouveau type de données natif dans Azure SQL Database spécifiquement conçu pour stocker des vecteurs. Plutôt que d’utiliser un format générique comme du JSON ou du varbinary, ce type offre un format dédié, compact et optimisé pour les opérations mathématiques, telles que le calcul de distances (cosinus, euclidienne, etc.).
Il permet ainsi d’effectuer directement dans la base de données des recherches par similarité, sans recourir à des systèmes externes spécialisés dans le stockage vectoriel.
Comment fonctionne la recherche de distance entre 2 vecteurs ?
En utilisant des fonctions intégrées telles que VECTOR_DISTANCE, cela calcule une distance (cosinus, euclidienne, etc.) entre le vecteur de la requête et chaque vecteur stocké, permettant d’ordonner les résultats par similarité (la distance la plus faible indiquant la correspondance la plus proche).
Est-ce disponible sur SQL Server 2022 ?
Non, la fonctionnalité native de support des vecteurs n’est pas disponible dans SQL Server 2022. Actuellement, cette capacité est proposée dans Azure SQL Database. Microsoft prévoit d’intégrer des fonctionnalités similaires dans les futures versions, notamment SQL Server 2025.
Pour la première fois, Microsoft apporte un support vectoriel natif à SQL Server. SQL Server 2025 sera une base de données vectorielle prête pour l’entreprise, capable de générer et de stocker en mode natif des incrustations vectorielles. Cette prise en charge native des vecteurs permettra aux clients de SQL Server d’exécuter des modèles d’IA génératifs en utilisant leurs propres données. Ils peuvent choisir le modèle d’IA requis grâce à la gestion extensible des modèles permise par Azure Arc.
Peut-on tester les vecteurs sur une base de données Azure SQL ?
Comme toujours, Alex Wolf, via son excellente chaîne YouTube The Code Wolf, nous montre la prise en charge des vecteurs IA au sein même des bases de données SQL :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Afin de faire nos tests sur le base de données Azure SQL pour < comprendre le fonctionnement des vecteurs, nous allons avoir besoin de :
Un tenant Microsoft active
Une souscription Azure valide
Commençons par créer la base de données SQL depuis le portail Azure.
Etape I – Création de la base de données Azure SQL :
Depuis le portail Azure, commencez par rechercher le service de bases de données SQL :
Renseignez les informations de base, comme la souscription Azure et le groupe de ressources :
Cliquez-ici pour également créer un serveur SQL hébergeant notre base de données :
Renseignez un nom unique pour votre serveur SQL, indiquez un compte administrateur à ce dernier, puis cliquez sur OK :
Conservez l’option de base pour la puissance votre serveur SQL, la réplication sur LRS, puis cliquez sur Suivant :
Conservez l’accès public pour nos tests, ajoutez-y votre adresse IP publique, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 5 minutes, puis cliquez-ici pour accéder aux ressources créées :
Copiez les éléments de connexion à cette base de données présents l’onglet ci-dessous, puis conservez cette valeur par la suite dans un éditeur de texte :
Utilisez un outil de gestion de base de données, comme SQL Server Management Studio (SSMS), ou Azure Data Studio, disponible lui sur cette page :
Acceptez les conditions d’utilisations, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Cliquez sur Terminer :
Ouvrez Azure Data Studio, puis cliquez-ici pour créer une nouvelle connexion :
Collez les informations de connexion de votre base SQL précédemment copiées, renseignez le mot de passe de votre administrateur, puis cliquez sur Connecter :
Saisissez la commande SQL suivante afin de créer la table liée au stockage des données et de leurs vecteurs :
CREATE TABLE dbo.demo
(
id INT PRIMARY KEY,
filename VARCHAR(50),
vectors VECTOR(1024) NOT NULL
)
Exécutez la commande, puis obtenez la confirmation suivante :
Notre base de données, encore vide en enregistrements et en vecteurs est maintenant prête.
Nous allons maintenant créer un le service d’intelligence artificielle sur Azure afin de créer calculer les vecteurs de nos futures données.
Etape II – Création du service d’IA Computer Vision :
Toujours sur le portail Azure, recherchez le service d’IA suivant :
Cliquez-ici pour créer un nouveau service :
Renseignez toutes les informations, en privilégiant un déploiement dans les régions East US ou West Europe, conservez le modèle de prix F0 (suffisant pour nos tests), puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Une fois le déploiement terminé, cliquez-ici :
Copiez les 2 informations suivantes dans votre bloc-notes afin de vous y connecter plus tard à via API :
Afin d’envoyer différentes requêtes via API à notre service d’IA, utilisez un service dédié, comme par exemple Postman, disponible ici (créez un compte gratuit si nécessaire) :
Notre environnement manuel est maintenant prêt pour être testé.
La prochaine étape consiste à générer manuellement des vecteurs via notre service d’IA afin de les stocker dans votre base de données SQL.
Etape III – Chargement des vecteurs d’images dans la DB SQL :
Une fois connecté sur votre console Postman, cliquez-ici pour utiliser le service :
Notre premier objectif est de convertir les données d’une image en vecteur. Pour cela, choisissez la méthode de type POST, puis saisissez l’URL composée de la façon suivante :
Point de terminaison de votre service Computer Vision
Service API de vectorisation d’images proposé par Computer Vision
Exécutez la commande suivante, puis constatez le succès de celle-ci :
Contrôlez le résultat du chargement dans la base de données SQL via la requête suivante :
SELECT * FROM dbo.demo
Notre base de données Azure SQL a bien stocké les vecteurs calculés par le service d’intelligence artificielle. La prochaine étape consiste à calculer la distance entre les vecteurs des images et les vecteur d’un mot-clef.
Etape IV – Calcul de distance entre les images et le mot-clef :
Retournez sur le service d’appel API Postman, puis créez un nouvel onglet de requête :
Choisissez à nouveau une méthode de type POST, puis l’URL composée de la façon suivante :
Point de terminaison de votre service Computer Vision
Service API de vectorisation de texte proposé par Computer Vision
Rendez-vous dans l’onglet Headers afin de rajouter à nouveau en valeur la clef de votre service Computer Vision sous la clef Ocp-Apim-Subscription-Key :
Rendez-vous dans l’onglet Body afin de rajouter en RAW le mot-clef :
{
"text":"café"
}
Cliquez ensuite sur Envoyer, changez le format de sortie des vecteurs calculés en RAW, puis copiez tous les vecteurs présents entre les 2 crochets :
Retournez sur Azure Data Studio, puis commencez par coller la requête SQL suivante afin de créer une variable qui stockera les vecteurs de notre mot-clef :
DECLARE @searchVector VECTOR(1024) = '[]'
Entre les 2 crochets de la déclaration de variable, collez les vecteurs du mot-clef précédemment copiés :
Ajoutez en dessous la requête SQL basée sur la fonction VECTOR_DISTANCE :
SELECT TOP(10) id, filename, VECTOR_DISTANCE('cosine', @searchVector, vectors)
AS Distance from demo ORDER BY Distance
Puis exécutez l’ensemble afin de constater le résultat de distance entre le mot-clef et les 3 images :
Ces différents tests nous démontrent la possibilité de stockage des vecteurs et la recherche de résultats basés sur la distance entre ces derniers, le tout dans une base de données SQL.
Toutes ces étapes de génération de vecteurs et de recherche sur les distances sont facilement intégrables dans une application, comme celle justement proposée par Alex Wolf.
Etape V – Automatisation de l’importation des vecteur :
Retournez sur Azure Data Studio afin de créer une seconde table dédiée à notre application :
CREATE TABLE dbo.images
(
id INT PRIMARY KEY,
name VARCHAR(50),
vectors VECTOR(1024) NOT NULL
)
Rendez-vous sur la page GitHub suivante afin de télécharger l’application au format ZIP :
Décompressez l’archivage dans le dossier local de votre choix :
Ouvrez l’application Visual Studio Code, puis ouvrez le dossier correspondant à votre application :
Ouvrez le fichier Program.cs pour y renseigner votre le point de terminaison, ainsi que la clef de votre service Computer vision, puis Sauvegardez :
Ouvrez le fichier AzureBectorDatabaseService.cs pour y renseigner les informations de connexion de votre base SQL précédemment copiées avec le bon mot de passe, puis Sauvegardez :
Démarrez l’application via la commande .NET suivante :
dotnet run
Quelques secondes plus tard, l’application est démarrée, l’URL et le port exposé s’affichent :
Collez cette URL dans un navigateur internet pour ouvrir l’application, puis cliquez sur le bouton ci-dessous pour charger une ou des images au format JPG :
Sélectionnez-le ou les fichiers images de votre choix, puis cliquez sur Ouvrir :
Cliquez-ici pour téléversé le ou les fichiers :
Constatez l’apparition de la vignette de vos images téléversées :
Effectuez la même opération avec d’autres images plus ou moins variées :
Retournez sur Azure Data Studio, puis lancez la requête SQL suivante pour voir le chargement de des données et des vecteurs dans la seconde table créée :
SELECT * FROM dbo.images
Notre application contient maintenant des fichiers images, avec leurs vecteurs dans notre base de données SQL grâce à notre service d’IA Computer Vision.
Il nous reste maintenant qu’à rechercher via un mot-clef, transposé lui-aussi en vecteurs via l’IA, à des images dont les vecteurs lui seraient proches.
Etape VI – Automatisation du calcul de distance vectorielle :
Retournez sur la page web de votre application, saisissez un mot-clef dans la zone prévue à cet effet, puis cliquez sur Rechercher afin de constater la pertinence des résultats :
Refaites d’autres tests en jouant également avec les 3 niveaux du seuil de confiance :
Les résultats retournés varient selon le niveau du seuil de confiance :
La faible quantité d’images chargées et le niveau de confiance réglé sur moyen donne des résultats trop larges :
Cette approximation peut se corriger avec un niveau de confiance élevé :
Conclusion
En conclusion, l’intégration native du type de données vector dans Azure SQL Database marque une avancée majeure pour les développeurs souhaitant exploiter l’intelligence artificielle directement au sein de leur SGBD.
Cette fonctionnalité permet de stocker et d’interroger des vecteurs de manière optimisée, simplifiant ainsi l’architecture des applications en éliminant le besoin d’une base de données vectorielle externe.
En adoptant ces outils, les équipes peuvent désormais transformer et analyser leurs données de façon plus intuitive et sécurisée, tout en tirant parti de l’écosystème SQL existant. C’est un pas décisif vers une intégration plus fluide de l’IA et la modernisation d’environnements traditionnels.
Début février, Microsoft vient d’annoncer une nouvelle fonctionnalité en préversion pour migrer une machine virtuelle, de première génération vers la seconde. Cette bascule de génération est l’occasion de renforcer la sécurité (via Secure Boot et vTPM), d’améliorer les performances (temps de démarrage plus rapides) et d’offrir un support de disques de plus grande capacité. Tout cela, sans avoir besoin de reconstruire la machine virtuelle et en quelques clics.
Depuis quand la génération 2 est disponible sur Azure ?
Microsoft a annoncé la prise en charge des machines virtuelles de génération 2 depuis 2019, avec une généralisation progressive de leur déploiement par la suite.
Il y a quelques jours, Microsoft a annoncé la prévisualisation publique des machines virtuelles de génération 2 sur Azure. Les machines virtuelles de génération 2 prennent en charge un certain nombre de nouvelles technologies telles que l’augmentation de la mémoire, les Intel Software Guard Extensions (SGX) et la mémoire persistante virtuelle (vPMEM), qui ne sont pas prises en charge par les machines virtuelles de génération 1. Mais nous y reviendrons plus tard.
Les machines virtuelles Gen1 restaient toujours utiles pour la migration d’environnements legacy, ou lorsque la compatibilité avec d’anciennes images était nécessaire.
En revanche, les VM Gen 2, avec leur firmware UEFI, offrent la possibilité d’exécuter des fonctionnalités modernes comme la virtualisation imbriquée.
Qu’est-ce que le Trusted Launch ?
Azure propose le lancement fiable pour améliorer de manière fluide la sécurité des machines virtuelles (VM) de génération 2. Le lancement fiable protège contre les techniques d’attaque avancées et persistantes. Le lancement fiable se compose de plusieurs technologies d’infrastructure coordonnées qui peuvent être activées indépendamment. Chaque technologie offre une couche de défense supplémentaire contre les menaces sophistiquées.
Concrètement, Trusted Launch combine plusieurs technologies :
Secure Boot : Assure que seuls des composants logiciels signés et vérifiés sont autorisés à se charger pendant le démarrage.
vTPM (TPM virtuel) : Fournit une zone sécurisée pour stocker des clés cryptographiques et d’autres informations sensibles.
Measured Boot : Enregistre et vérifie les mesures du processus de démarrage pour détecter toute modification non autorisée.
Qu’est-ce que le Secure Boot ?
Le Secure Boot est donc une fonctionnalité de sécurité intégrée au niveau du firmware qui garantit que, lors du démarrage du système, seuls des composants logiciels authentifiés et signés numériquement (bootloader, pilotes, etc.) sont chargés.
Cela permet de prévenir l’exécution de code malveillant dès le démarrage, protégeant ainsi le système contre des attaques telles que les bootkits. En vérifiant l’intégrité et l’authenticité des éléments critiques, Secure Boot contribue à renforcer la sécurité globale de la machine.
Quelles sont les différences entre les 2 générations ?
Ce tableau permet ainsi de choisir la génération en fonction des besoins spécifiques en termes de sécurité, performance et compatibilité :
Fonctionnalité
Machines virtuelles Gen 1
Machines virtuelles Gen 2
Exemple / Explication
1. Type de firmware
BIOS
UEFI
Gen 2 utilise l’UEFI, permettant par exemple l’activation du Secure Boot.
2. Support des systèmes d’exploitation
32 bits et 64 bits
Exclusivement 64 bits
Pour un déploiement Windows Server 2019, seule la Gen 2 est compatible en 64 bits.
3. Interface de disque de démarrage
Utilise un contrôleur IDE
Utilise un contrôleur SCSI
Le démarrage sur SCSI en Gen 2 offre de meilleures performances I/O.
4. Secure Boot
Non disponible
Disponible
La sécurité est renforcée grâce au Secure Boot dans les VM Gen 2.
5. Virtualisation imbriquée
Support limité
Support amélioré
Permet d’exécuter Hyper-V dans la VM Gen 2 pour des environnements de test.
6. Temps de démarrage
Démarrage plus classique
Démarrage généralement plus rapide
Une VM Gen 2 peut démarrer plus vite grâce à l’architecture UEFI optimisée.
7. Taille maximale du disque système
Limité selon les anciens standards
Support de disques système de plus grande taille
Idéal pour des OS nécessitant un volume de boot plus important.
8. Virtualisation basée sur la sécurité
Non supportée
Supportée
Permet d’utiliser des fonctionnalités telles que Windows Defender Credential Guard.
9. Gestion de la mémoire
Standard
Optimisée pour des performances supérieures
Amélioration dans la gestion de la mémoire et la réactivité du système dans la Gen 2.
10. Support des périphériques modernes
Compatible avec du matériel plus ancien
Conçu pour exploiter les dernières technologies matérielles
Par exemple, intégration possible d’un TPM virtuel pour renforcer la sécurité.
11. Déploiement et gestion
Basé sur des modèles plus anciens
Optimisé pour une gestion moderne via Azure Resource Manager
Facilite l’intégration avec les nouvelles options de déploiement automatisé dans Azure.
12. Compatibilité des images
Compatible avec un large éventail d’images anciennes
Restreint aux images récentes optimisées pour UEFI
Gen 1 permet d’utiliser des images plus anciennes, alors que Gen 2 cible les OS modernes.
En résumé, le choix entre Gen1 et Gen2 se fera principalement en fonction des exigences de compatibilité et de sécurité :
Gen1 convient aux scénarios où l’héritage et la compatibilité avec des images plus anciennes priment.
Gen2 est privilégiée pour bénéficier d’une meilleure sécurité et de performances optimisées, notamment grâce aux fonctionnalités comme Secure Boot et le vTPM.
Puis-je utiliser des Gen1/Gen2 avec toutes les familles de machines virtuelles Azure ?
Non. Et pour vous aider, Microsoft vous met à disposition cette liste, disponible via ce lien.
Toutes les images OS sont-elles compatible avec Gen2 ?
Non. Les machines virtuelles Gen2 prennent en charge que certaines images OS :
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012
Windows 11 Professionnel, Windows 11 Entreprise
Windows 10 Professionnel, Windows 10 Entreprise
SUSE Linux Enterprise Server 15 SP3, SP2
SUSE Linux Enterprise Server 12 SP4
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS
Puis-je basculer une VM de Gen1 à Gen2, et inversement ?
Anciennement, il n’était pas possible de facilement convertir directement une VM existante de Gen1 vers Gen2, en raison des différences fondamentales au niveau du firmware et de la configuration des disques. Pour migrer vers une Gen2, il fallait alors bien souvent recréer la machine virtuelle dans la génération cible.
Qu’est-ce que MBR2GPT ?
MBR2GPT est un outil en ligne de commande de Microsoft qui permet de convertir un disque partitionné en MBR vers le format GPT sans perte de données, facilitant ainsi la transition d’un mode BIOS hérité vers un démarrage UEFI.
Depuis peu, Microsoft vient d’ajouter une fonctionnalité, encore en préversion, pour basculer de Gen1 à Gen2 en quelques clics, dont la source est disponible juste ici.
Enfin, voici d’ailleurs une vidéo de Microsoft parlant en détail de l’outil MBR2GPT :
Comme indiqué dans cette vidéo, l’outil MBR2GPT va travailler sur la conversation des partitions de l’OS :
Le processus sur Azure se fait en seulement quelques clics, et je vous propose de tester tout cela 😎💪
Pour réaliser ce test de conversation de génération (encore en préversion), il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Commençons par créer une machine virtuelle de première génération.
Etape I – Création de la machine virtuelle Gen1 :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle compatible à la fois Gen1 et Gen2 :
Renseignez les informations de l’administrateur local, 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 :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion pour continuer.
L’étape suivante consiste à lancer l’utilitaire intégré MBR2GPT afin de valider et de transformer la partition du disque OS au format GPT, et aussi d’ajouter la partition système EFI requise pour la mise à niveau en Gen2.
Etape II – Transformation du disque OS depuis MBR vers GPT :
Une fois Azure Bastion correctement déployé, saisissez les identifiants renseignés lors de la création de votre machine virtuelle :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
Confirmez le statut du mode BIOS en Legacy :
Les propriétés du disque OS nous confirme l’utilisation du style de partition MBR (Master Boot Record) :
Depuis le menu Démarrer de votre machine virtuelle, puis cliquez sur Exécutez pour ouvrir le programme cmd :
Lancez la commande MBR2GPT suivante pour exécuter la validation MBR vers GPT :
MBR2GPT /validate /allowFullOS
Assurez-vous que la validation de l’agencement du disque se termine avec succès. Ne continuez pas si la validation du disque échoue :
Lancez la commande MBR2GPT suivante pour exécuter la conversion MBR vers GPT :
MBR2GPT /convert /allowFullOS
Obtenez le résultat suivant :
Cliquez-ici pour fermer votre session Windows :
Une fois la session Windows fermée, cliquez-ici pour fermer l’onglet ouvert pour Azure Bastion :
Depuis le portail Azure, arrêtez votre machine virtuelle :
Confirmez votre choix en cliquant sur Oui :
Quelques minutes plus tard, confirmez que la machine virtuelle est en état Arrêté (désallouée).
Encore en préversion, l’activation des mesures de sécurité sur la machine virtuelle n’est pas possible depuis le portail Azure. Il faut donc utiliser Azure Cloud Shell.
Etape III – Activation du vTPM et du Secure Boot :
Mais avant d’activer le vTPM et le Secure Boot sur notre machine virtuelle Azure, il est nécessaire d’activer la fonctionnalité Gen1ToTLMigrationPreview, encore en préversion, sur notre souscription Azure.
Pour cela, cliquez sur le bouton suivant pour ouvrir la fenêtre d’Azure Cloud Shell :
Une fois Azure Cloud Shell d’ouvert en mode PowerShell, saisissez la commande suivante afin de voir si celle-ci est déjà activée :
Validez la mise à jour du profil de sécurité le dans la configuration de la VM :
# Following command output should be `TrustedLaunch
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.SecurityType
# Following command output should return `SecureBoot` and `vTPM` settings
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.Uefisettings
Le changement de génération de notre machine virtuelle est également visible sur le portail Azure :
De même que le profil de sécurité ainsi que les options activées (une fois que vous avez activé le Trusted launch, les machines virtuelles ne peuvent plus être ramenées au type de sécurité Standard) :
Ces options sont encore modifiables depuis l’écran ci-dessous (Microsoft recommande d’activer le Secure Boot si vous n’utilisez pas de pilotes personnalisés non signés) :
Redémarrez votre machine virtuelle :
Reconnectez-vous à celle-ci via le service Azure Bastion :
Constatez la bonne ouverture de session Windows :
Confirmez le statut du mode BIOS en UEFI, de même que l’activation du Secure Boot :
Relancer la validation de l’agencement du disque sur un disque déjà configuré en GPT provoquera une erreur logique :
Les propriétés du disque OS nous confirme l’utilisation du style de partition GUID (GPT), qui est un schéma de partitionnement moderne qui utilise des identifiants uniques (GUID) pour chaque partition :
Etape IV – Activation de services annexes :
Une fois la bascule en Gen2 effectuée, il n’est plus possible d’activer la sauvegarde via Azure Backup avec une police de type standard :
D’ailleurs, l’activation de la sauvegarde après le changement de Gen1 à Gen2 n’a posé aucun souci :
Il en a été de même pour l’activation de réplication pour une machine migrée de Gen1 à Gen2 :
Dans le cadre d’un test de failover, la nouvelle machine virtuelle, créée temporairement, est bien elle aussi en génération 2 :
La connexion via Azure Bastion sur cette machine virtuelle temporaire est bien fonctionnelle :
Conclusion
En conclusion, cette procédure toute simple et réalisée en quelques clics avec MBR2GPT nous démontre que migrer vos machines virtuelles de Gen1 à Gen2 représente bien plus qu’un simple changement de firmware :
Grâce à une sécurité renforcée avec Secure Boot et vTPM, des performances accrues et une prise en charge des disques de plus grande taille.
Adopter Gen2, c’est ainsi investir dans une plateforme plus robuste, performante et alignée avec les exigences actuelles de la sécurité informatique.
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.
Comme beaucoup d’entre vous, je suis régulièrement amené à discuter migration pour Microsoft 365. Et même que, de temps à autre, il s’agit de migrations de données depuis un tenant Microsoft vers un autre. Ayant justement l’opportunité de tester ShareGate Migrate grâce au programme Microsoft MVP, je souhaitais vous en faire partager via un article en mode découverte sur plusieurs de ses fonctionnalités.
Qu’est-ce que ShareGate ?
ShareGate est un outil de gestion et de migration pour SharePoint et Microsoft 365 (y compris OneDrive for Business et Teams). Il est principalement utilisé pour :
Migrer des sites, bibliothèques, documents et permissions entre différentes versions de SharePoint (On-Premise vers Online, entre tenants, etc…)
Gérer et administrer SharePoint en facilitant l’audit, l’organisation et la gouvernance des contenus et permissions.
Simplifier la gestion des espaces collaboratifs (Teams, SharePoint, OneDrive) en automatisant certaines tâches d’administration et en assurant la conformité des espaces.
ChatGPT
Vers où ShareGate peut migrer les données ?
Comme le montre l’image ci-dessous, ShareGate est capable de traiter de nombreux scénarios de migration de données :
Dans cet article, nous réaliserons des tests de fonctionnalité dans le cadre d’une migration de données depuis un tenant 365 vers un autre.
Combien coûte ShareGate ?
ShareGate propose plusieurs plans tarifaires adaptés aux besoins des entreprises en matière de migration et de gestion de Microsoft 365 :
Migrate Essentials : 1 activation de machine pour des migrations essentielles, à partir de 5 995 $ par an.
Migrate Pro : 5 activations de machine pour des migrations accélérées, incluant des formations pour les utilisateurs finaux et la migration des boîtes aux lettres, à partir de 9 995 $ par an.
Migrate Enterprise : 25 activations de machine pour des projets de migration à grande échelle, avec les mêmes avantages que le plan Pro, à partir de 17 995 $ par an.
Une version d’essai de 15 jours est même disponible sur leur site internet :
ShareGate a également mis à disposition beaucoup de contenus pour vous aider dans vos différents projets de migration :
Est-ce qu’il existe des limitations / restrictions à la migration ?
Oui, malgré sa puissance, ShareGate Migration a certaines limitations à prendre en compte lors de la migration de sites SharePoint, OneDrive, et Microsoft Teams. Voici les principales :
– Vitesse maximale de migration : 1,5 Go/heure par boîte. – Types de boîtes pris en charge : utilisateur et partagé. – Boîtes aux lettres d’archive, chiffrées, invitées ou externes non prises en charge. – Permissions des dossiers, dossiers partagés/publics/archivés non préservés. – Politiques de rétention des e-mails non conservées. – Composants Loop, pièces jointes de référence, en-têtes de messages non pris en charge. – Événements de calendrier uniques passés non migrés. – Listes de contacts, catégories de contacts, statuts favoris non copiés. – Règles de flux de messagerie non prises en charge. – Paramètres de boîte aux lettres, comme le fuseau horaire, partiellement pris en charge.
– Les équipes avec confidentialité « Organisation » deviennent « Publique » à la destination. – Seul le modèle d’équipe standard est pris en charge. – Image de l’équipe, paramètres spécifiques, balises personnalisées non migrés. – Demandes en attente pour les équipes privées non migrées. – Canaux supprimés, webhooks entrants/sortants, applications personnalisées non migrés. – Équipes et canaux archivés migrés comme non archivés. – Images copiées/collées non visibles à la destination. – OneNote par défaut recréé lors du renommage de l’équipe à la destination.
– Noms contenant des codes Alt non pris en charge. – Noms d’équipe avec une barre oblique (/) créent des dossiers imbriqués. – Certains caractères spéciaux dans les noms de fichiers remplacés par un underscore (_).
SharePoint
– Les personnalisations, telles que les solutions tierces et les fonctionnalités personnalisées, peuvent ne pas être entièrement prises en charge. – Les éléments liés à l’apparence, comme les mises en page de page et les pages maîtres, ne sont pas migrés. – Les sites en lecture seule ne peuvent pas être migrés correctement et doivent être déverrouillés avant la migration.
Planner
– Le fond d’écran, les paramètres de notification et les plans favoris des utilisateurs ne sont pas préservés. – Les e-mails d’affectation de tâches et de commentaires sont envoyés par défaut et ne peuvent pas être désactivés. – Les auteurs des tâches, des commentaires et les horodatages ne sont préservés que dans les commentaires. – Les restrictions de Planner s’appliquent, par exemple : maximum de 200 plans par équipe et environ 2 400 tâches par plan.
Dans cet article, je vous propose donc de tester la migration d’un tenant à un autre via l’application ShareGate Migration :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de tester la migration de tenant à tenant, il vous faudra disposer de :
Une licence ShareGate
Un premier tenant de test, appelé tenant de départ et contenant des données 365
Un second tenant de test, appelé tenant de destination et ne contenant pas ou peu de données 365
Commençons par configurer l’application ShareGate Migration sur un poste local.
Etape I – Configuration de ShareGate :
Afin de profiter des services de ShareGate pour migrer des données, nous allons devoir créer un compte chez eux et installer l’application ShareGate Migrate sur le poste local.
Pour enregistrer le produit, connectez-vous sur la page d’authentification de ShareGate, et si vous ne disposez pas encore de compte, cliquez sur ce bouton pour en créer un :
Une fois votre compte validé et connecté, votre tableau de bord de ShareGate se présente de la façon suivante :
Les souscriptions ShareGate sont visibles sur cette page :
Plusieurs ressources de formation sont également disponibles via ce lien :
Comme précédemment, de nombreuses documentations y sont disponibles :
Cliquez-ici pour télécharger le client local ShareGate Migrate :
Une fois l’installeur téléchargé sur votre poste, ouvrez-le, puis cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Cliquez sur Terminer :
Ouvrez l’application ShareGate Migrate :
Authentifiez-vous avec le compte disposant de la licence ShareGate :
L’application locale s’ouvre alors avec différents menus :
L’activation de notre licence sur notre poste local est bien affichée sur la console web de ShareGate :
Notre poste local est maintenant configuré. Nous allons pouvoir nous focaliser sur les 2 tenants Microsoft 365 : départ et destination.
Etape II – Préparation des 2 tenants :
Dans mon exemple de migration, 2 tenants Microsoft 365 sont créés pour les tests de migration :
Un environnement Microsoft 365 avec des utilisateurs ayant des données fictives
Un environnement Microsoft 365 vide d’utilisateurs
Un environnement Microsoft 365 avec des équipes Teams ayant des données fictives
Un environnement Microsoft 365 vide d’équipes Teams
Un environnement Microsoft 365 avec des sites SharePoint ayant des données fictives
Un environnement Microsoft 365 vide de sites SharePoint
ShareGate ne s’occupe pas de copier les utilisateurs présents dans le tenant de départ vers le tenant de destination.
Pour cela, exportez la liste des utilisateurs depuis le portail Entra :
Cliquez-ici pour déclencher le téléchargement du fichier au format CSV :
Le fichier CSV généré contient les informations sur les identités Cloud de vos utilisateurs de test :
Sur le tenant de destination, cliquez-ici pour préparer l’importation des utilisateurs :
Cliquez-ici pour télécharger le fichier d’exemple pour l’importation des utilisateurs :
Remplissez le fichier en prenant les informations présentes dans le fichier d’extraction provenant de votre tenant de départ :
Chargez ce nouveau fichier CSV, puis cliquez-ici pour démarrer la création des utilisateurs :
Attendez quelques secondes la fin de l’importation :
Sur le tenant de destination, rafraîchissez la page plusieurs fois si besoin afin de voir apparaître les utilisateurs avec leur nouvel identifiant provisoire :
Si besoin, faites la même opération de création avec les groupes de sécurité que vous souhaitez reprendre dans le tenant de destination.
Notre tenant de destination est déjà prêt pour copier les e-mails contenus dans les boîtes aux lettres du tenant de départ.
Etape III – Copie de données Exchange :
Avant de démarrer la copie via ShareGate Migrate, assignez des licences aux utilisateurs dans le tenant de destination afin de lancer la création des boîtes aux lettres Outlook :
Depuis la console Exchange du tenant de destination, recréez également les boîte aux lettres partagées devant être migrées :
Ajoutez-y les autorisations de délégations aux utilisateurs concernés :
Si nécessaire, activez les boîtes aux lettres archives aux personnes concernées sur le tenant de destination :
Retournez sur l’application ShareGate Migration, puis cliquez sur le menu suivant :
Ajoutez-y une première connexion vers le tenant de départ via le menu suivant :
Cliquez-ici pour vous authentifier :
Renseignez les identifiants d’un administrateur global du tenant de départ :
ShareGate déploie alors une application sur le tenant de départ, et vous demande d’accepter les droits de celle-ci :
Attendez quelques secondes la finalisation de la configuration de l’application sur votre tenant de départ :
Vous pouvez consultez cette première application et ses droits via la page suivante d’Entra :
Sélectionnez alors les boîte aux lettres devant être migrées vers le tenant de destination, puis cliquez-ici :
Ajoutez-y une seconde connexion vers le tenant de destination :
Cliquez-ici pour vous authentifier :
Renseignez les identifiants d’un administrateur global du tenant de destination :
ShareGate déploie également une application sur le tenant de destination, et vous demande d’accepter les droits de celle-ci :
Attendez quelques secondes la finalisation de la configuration de l’application sur votre tenant de destination :
Vous pouvez consultez cette seconde application et ses droits via la page suivante d’Entra :
Choisissez les éléments à copier, puis continuez :
ShareGate Migrate effectue d’abord une correspondance automatique entre les boîtes aux lettres des 2 tenant.
Dans mon cas, n’ayant pas assigné de licence Microsoft 365 à Brian, aucune boîte aux lettres ne lui avait été générée sur le tenant de destination :
Modifiez à votre guise les correspondances entre les boîtes aux lettres des 2 tenants, puis continuez :
ShareGate Migrate effectue ensuite une seconde correspondance automatique entre destinataires internes des 2 tenant :
Dans mon cas, le tenant de départ contenait des adresses e-mails rattachées à des comptes de ressource :
Recréez si nécessaire ces dernières dans le tenant de destination :
Relancez la correspondance automatique :
Confirmez votre choix :
ShareGate retrouve alors toutes les adresses des destinataires internes, puis continuez :
Vérifiez toutes les informations avant la migration, puis démarrez la copie :
Attendez quelques minutes, constatez la fin de l’opération de copie, puis cliquez pour exporter le rapport :
Ouvrez le premier fichier Excel afin de retrouver un récapitulatif de chaque boîte aux lettres avec les informations suivantes :
Succès
Avertissements
Erreurs
D’autres fichiers Excel sont également générés par boîte aux lettres. Dans mon cas, la majorité des erreurs était dues aux calendriers :
Constatez la bonne copie des messages en ouvrant un utilisateur de test sur les tenants de départ et de destination :
Vérifiez le dossier des messages envoyés :
Vérifiez le calendrier, puis constatez la recopie des réunions Teams avec la recréation d’un nouveau lien propre au tenant de destination :
Vérifiez un autre dossier créé par l’utilisateur :
Vérifiez la présence des contacts :
Vérifiez la présence des règles de gestion des messages :
Vérifiez la présence de messages sur une boîte aux lettres partagée :
Retournez sur ShareGate Migration afin de provoquer une nouvelle copie d’une ou plusieurs boîtes aux lettres :
Constatez à chaque traitement de copie la génération d’une tâche depuis le menu suivant :
Notre premier essai concernant la copie de boites aux lettres d’un tenant 365 à autre s’est avéré concluant.
D’autres actions concernant la bascule du nom de domaine personnalisé, le changement des noms d’utilisateurs, les modifications d’enregistrements DNS etc… sont encore à prévoir.
Continuons avec la copie des données des équipes Teams.
Etape IV – Copie de données Teams :
Retournez sur l’application ShareGate Migration, puis cliquez sur le menu suivant :
Ajoutez-y une première connexion vers le tenant de départ via le menu suivant :
Renseignez les identifiants d’un administrateur global du tenant de départ :
Sélectionnez alors les équipes Teams/canaux devant être migrés vers le tenant de destination, puis cliquez-ici :
Ajoutez-y une seconde connexion vers le tenant de destination :
Renseignez les identifiants d’un administrateur global du tenant de destination :
Cliquez-ici pour consulter les options possibles lors de cette copie :
Définissez les options de copie souhaitées, puis cliquez sur Sauvegarder :
Cliquez-ici pour détailler les canaux recréés dans le tenant de destination :
Cliquez-ici pour programmer la copie ultérieurement afin d’anticiper les périodes creuses en termes d’usages et de performances :
Définissez la date et l’heure précise de votre copie, puis cliquez sur Programmer :
Retrouvez cette tâche non démarrée dans l’écran suivant :
Une fois tâche terminée, retrouvez cette dernière dans l’historique des tâches :
La tâche vous informe de la durée de la copie ainsi que du détail des éléments copiés par équipes Teams :
Chaque objets d’équipe Teams est visible et dispose d’un statut de copie :
Succès
Avertissements
Erreurs
En cas d’erreur, des informations sont disponibles sur celle-ci ainsi que sur la marche à suivre :
Comme attendu, SharePoint Migrate ne copie pas les messages Teams :
Constatez la bonne copie des équipes Teams et de leurs canaux en ouvrant un utilisateur de test sur les tenants de départ et de destination :
Vérifiez la présence de messages republiés sur les canaux Teams :
Un onglet spécifique fait son apparition dans le tenant de destination :
Celui-ci affiche les posts Teams dans une présentation plus facile à visualiser :
Constatez la reprise de plans liés à des équipes Teams :
Constatez la reprise de documents hébergés sur le site SharePoint de l’équipe Teams :
Depuis la console Teams du tenant de destination, constatez la présence des équipes Teams :
Depuis la console SharePoint du tenant de destination, constatez la présence de sites SharePoint liés aux équipes Teams :
Retournez sur ShareGate Migrate, puis cliquez sur cette fonction de gestion des équipes Teams :
Cliquez-ici pour vous authentifier :
Renseignez les identifiants d’un administrateur global du tenant de départ :
ShareGate déploie alors une autre application sur le tenant de destination, et vous demande d’accepter les droits de celle-ci :
Cela ouvre une console gérée par ShareGate en relation avec votre tenant Teams de destination afin de vous faciliter certaines opérations :
Retournez sur ShareGate Migrate, puis cliquez sur la fonction de copie incrémentale :
Sélectionnez alors les équipes Teams/canaux devant être copiés de façon incrémentale, puis démarrer la copie :
Attendez quelques minutes la fin de la copie incrémentale :
La tâche vous informe de la durée ainsi que du détail des éléments copiés en incrémental :
Continuons avec la copie de données Planner.
Etape V – Copie de données Planner :
Retournez sur l’application ShareGate Migration, puis cliquez sur le menu suivant :
Sélectionnez le tenant de départ ainsi que les équipes/plans à copier :
Sélectionnez le tenant de destination :
Sélectionnez le groupe de destination, puis démarrez la copie :
Attendez quelques minutes, constatez la fin de l’opération de copie, puis cliquez pour exporter le détail :
Constatez la copie de tous les plans en ouvrant un utilisateur de test sur les tenants de départ et de destination :
Vérifiez la présence de tâches sur les plans copiés :
Continuons nos tests avec la copie de sites SharePoint.
Etape VI – Copie de données SharePoint :
Lorsque vous utilisez ShareGate Migration, l’assignation automatique en tant qu’administrateur de collection de sites est essentielle, même si vous êtes Global Admin dans Microsoft 365. En effet, les droits d’administrateur global ne garantissent pas l’accès automatique à toutes les collections de sites SharePoint ou OneDrive.
Cette option permet à ShareGate d’obtenir les permissions nécessaires pour accéder aux contenus, effectuer des migrations complètes et manipuler les métadonnées sans intervention manuelle, simplifiant ainsi les opérations et réduisant les risques d’erreur.
Pour cela, rendez-vous dans les paramétrages de l’application :
Dans le menu Sécurité, cochez l’option suivante :
Retournez dans le menu Copie, puis cliquez sur le menu suivant :
Ajoutez-y une première connexion vers le tenant de départ, puis cliquez sur Connecter :
Dérouler l’arborescence des collections de sites SharePoint :
Choisissez une collection de sites ou tous les sites SharePoint, puis cliquez sur Suivant :
Ajoutez-y une seconde connexion vers le tenant de destination, puis cliquez sur Connecter :
Choisissez une collection de sites ou tous les sites SharePoint, puis cliquez sur Suivant :
Sélectionnez un ou tous les sites à copier, puis cliquez sur le bouton Options :
Définissez les options de copie souhaitées, puis cliquez sur Sauvegarder :
Lancez un pré-check afin que ShareGate Migration regarde les informations à copier avant de lancer le traitement :
Constatez la génération de la tâche de pré-check visible depuis le menu suivant :
Attendez quelques minutes, puis, une fois le pré-check terminé, cliquez pour consulter le rapport :
Retournez sur l’action pour démarrer la copie vers le tenant de destination :
Patientez quelques minutes le temps du traitement de copie :
Une fois le traitement terminé, cliquez sur cette fonction de gestion des groupes 365 :
Là encore, cela ouvre une console gérée par ShareGate en relation avec votre tenant de destination afin de vous faciliter certaines opérations :
Depuis la console SharePoint ouverte sur les 2 tenants, constatez la présence des sites SharePoint :
Ouvrez le site racine de votre SharePoint :
Ouvrez un site annexe de votre SharePoint :
Terminons avec la migration des comptes OneDrive personnels.
Etape VII – Copie de données OneDrive :
Deux remarques importantes :
Le contenu d’une seule bibliothèque OneDrive ne peut être copié à la fois en utilisant l’interface utilisateur de ShareGate Migrate.
Afin de générer des comptes OneDrive pour tous les utilisateurs, créez un premier fichier CSV contenant tous les comptes OneDrive de destination comme ceci :
Ouvrez PowerShell avec le module ShareGate par le menu suivant :
Lancez le script ci-dessous en y renseignant les informations suivantes :
Login Global admin du tenant de destination
Mot de passe Global admin du tenant de destination
Adresse admin du site SharePoint du tenant de destination
Fichier CSV reprenant les compte OneDrive à générer
Afin de voir la création des différents comptes OneDrive, rendez-vous dans le menu suivant de SharePoint Migration :
Attendez la création de tous les espaces OneDrive avant de continuer :
Afin de récupérer les URLs des sites OneDrive du tenant de départ, lancez la génération d’un premier rapport personnalisé :
Cliquez comme ceci :
Choisissez le tenant de départ, puis cliquez sur Suivant :
Lancez la génération du rapport :
Sélectionnez tous les comptes OneDrive, puis cliquez sur Editer :
Ajoutez l’administrateur global de votre tenant de départ, puis cliquez sur Appliquer :
Cliquez sur Continuer :
Cliquez sur Retour :
Cliquez sur Retour :
Cliquez sur Exporter :
Sauvegardez l’export au format XLSX :
Cliquez sur Fermer :
Effectuez à nouveau TOUTES ces opérations pour le tenant de destination :
Créez un second fichier au format CSV, reprenant les URLs des comptes OneDrive avec :
en premières colonne ceux du tenant de départ
en seconde colonne ceux du tenant de destination
Ouvrez une fenêtre PowerShell, puis lancez le script suivant en y renseignant les informations suivantes :
Login Global admin du tenant de départ
Mot de passe Global admin du tenant de départ
Login Global admin du tenant de destination
Mot de passe Global admin du tenant de destination
Second fichier CSV reprenant les comptes OneDrive à copier / coller
Import-Module Sharegate
# Define the CSV file path
$csvFile = "C:\Azure\CopyContent.csv"
# Import the CSV file
$table = Import-Csv $csvFile -Delimiter ","
# Define source and destination credentials
$srcUsername = "admin@M365x72297931.onmicrosoft.com"
$srcPassword = ConvertTo-SecureString 'mymotdepasse' -AsPlainText -Force
$dstUsername = "sharegate1@jloudev3.onmicrosoft.com"
$dstPassword = ConvertTo-SecureString 'mymotdepasse' -AsPlainText -Force
# Set variables for site and list operations
Set-Variable srcSite, dstSite, srcList, dstList
# Loop through each row in the CSV
foreach ($row in $table) {
# Clear previous values of variables
Clear-Variable srcSite
Clear-Variable dstSite
Clear-Variable srcList
Clear-Variable dstList
# Connect to source and destination sites
$srcSite = Connect-Site -Url $row.SourceSite -Username $srcUsername -Password $srcPassword
$dstSite = Connect-Site -Url $row.DestinationSite -Username $dstUsername -Password $dstPassword
# Get source and destination lists
$srcList = Get-List -Site $srcSite -Name "Documents"
$dstList = Get-List -Site $dstSite -Name "Documents"
# Copy content from source list to destination list
Copy-Content -SourceList $srcList -DestinationList $dstList
# Remove site collection administrator permissions
Remove-SiteCollectionAdministrator -Site $srcSite
Remove-SiteCollectionAdministrator -Site $dstSite
}
Attendez quelques minutes la fin du traitement de copie des données OneDrive pour tous les comptes :
Constatez la bonne copie des données OneDrive en ouvrant un utilisateur de test sur les tenants de départ et de destination :
Conclusion
En somme, l’exploration de ShareGate Migrate nous a permis de constater que cet outil se positionne comme une solution complète et efficace pour orchestrer des migrations complexes entre tenants Microsoft 365.
Du transfert des boîtes aux lettres à la copie des équipes Teams, en passant par la migration des sites SharePoint, Planner et OneDrive, ShareGate offre une approche centralisée qui simplifie chaque étape du processus.
Bien que certaines limitations subsistent – notamment en ce qui concerne la migration de certains éléments spécifiques dans Exchange ou Teams – ShareGate se démarque par sa capacité à rendre le processus de migration transparent et maîtrisable.
Ce que nous avons découvert, c’est l’importance d’une préparation rigoureuse : la mise en place des prérequis, la vérification des permissions et la création des comptes adéquats constituent autant de facteurs déterminants pour le succès de la migration.
D’abord, un grand merci à Merill Fernando pour ses newsletters toujours intéressantes sur Entra, dont voici le lien. Beaucoup d’articles écrits sur ce blog proviennent de différentes sources en anglais, et dont les travaux et réflexions méritent des tests et une retranscription en français. J’ai toujours du plaisir à essayer de comprendre certains types d’attaque visant le Cloud. Je voulais donc partager avec vous un exemple basé sur du phishing et dont la mise en place est d’une grande simplicité
Attention, ce contenu a une vocation strictement éducative. Les techniques et démonstrations présentées ici sont destinées à sensibiliser aux enjeux de la sécurité informatique et à permettre de mieux comprendre les mécanismes d’attaque afin de mieux s’en protéger.
Il ne s’agit en aucun cas d’un incitatif à la réalisation d’actions malveillantes. Nous vous encourageons vivement à rester dans un cadre légal et à utiliser ces informations uniquement pour renforcer la sécurité de vos systèmes. Je décline toute responsabilité quant à l’utilisation abusive de ces connaissances.
Un précédent article décrivant un autre scénario d’attaque, via le Device Code Flow, est disponible juste ici. Plusieurs sources m’ont aidé à écrire ce nouvel article :
zolder.io ont créé une application fonctionnant sur un Cloudflare Worker qui agit comme un proxy malveillant imitant la page de connexion Microsoft. Cette application intercepte les identifiants de connexion et d’autres informations sensibles, facilitant ainsi l’accès non autorisé aux comptes Microsoft, tout en contournant les mesures de sécurité comme l’authentification multi-facteurs classiques.
Nicola Suter, MVP Microsoft, a lui aussi écrit un article inspiré par Zolder.io en démontrant qu’il est possible de créer un kit de phishing AiTM fonctionnant sur Azure. Les fonctions sur Azure peuvent imiter une page de connexion Entra ID, capter les identifiants et automatiser la reprise de session, tout en contournant des mécanismes de détection classiques.
AiTM, kesako ?
Une attaque AITM exploite un proxy intermédiaire pour intercepter les informations d’authentification pendant qu’un utilisateur se connecte à un service légitime, ce qui permet à l’attaquant de détourner la session et de contourner certaines sécurités mises en place par l’authentification multi-facteurs :
Il s’agit d’une nouvelle technique de phishing encore plus efficace. Cette méthode utilise des sites Web usurpés qui déploient un serveur proxy entre un utilisateur cible et le site Web que l’utilisateur souhaite visiter.
Contrairement au phishing classique, elles ne se contentent pas de tromper l’utilisateur pour lui soutirer ses identifiants. Voici en quoi elles consistent :
Interception en temps réel : L’attaquant crée une page de connexion factice qui sert d’intermédiaire (un proxy) entre la victime et le véritable site légitime. Ainsi, l’utilisateur se connecte en pensant accéder au service habituel, tandis que l’attaquant intercepte les identifiants, cookies et autres données sensibles en temps réel.
Bypass des mesures de sécurité : Puisque l’authentification se fait sur la vraie page (via le proxy), même si l’utilisateur passe une authentification multifacteur (MFA), les tokens et sessions générés peuvent être capturés par l’attaquant, qui peut ensuite les réutiliser pour prendre le contrôle du compte.
Utilisation d’outils serverless : Des plateformes comme Cloudflare Workers ou Azure Functions permettent de déployer rapidement ce type d’attaque sans gérer d’infrastructures traditionnelles, rendant ainsi l’attaque plus facile à mettre en œuvre et plus discrète.
L’attaquant peut voler et intercepter le mot de passe de la victime, détourner les sessions de connexion et le cookie de session (un cookie permet d’authentifier un utilisateur chaque fois qu’il visite un site) et ignorer le processus d’authentification, car le phishing AiTM n’est pas lié à une vulnérabilité dans l’authentification.
Oui, il est possible de réduire le risque contre les attaques AITM en mettant en œuvre une combinaison de mesures préventives et de détection. Voici quelques axes de défense :
Authentification renforcée :
MFA résistant au phishing : Adopter des méthodes d’authentification fortes et moins vulnérables au phishing (comme FIDO2, Windows Hello ou l’utilisation de certificats) permet de réduire les risques, car ces solutions reposent sur des mécanismes difficiles à intercepter via un proxy.
Politiques d’accès conditionnel : Restreindre l’accès aux services sensibles uniquement depuis des dispositifs conformes (registered devices) ou depuis des réseaux de confiance peut empêcher l’exploitation des sessions capturées.
Surveillance et détection :
Analyse comportementale : Mettre en place des outils de détection qui surveillent les anomalies dans les logs de connexion (par exemple, des connexions depuis des adresses IP inhabituelles ou issues des plages d’IP cloud reconnues) permet d’identifier rapidement une activité suspecte.
Canary tokens et autres mécanismes de vigilance : Bien qu’ils puissent parfois être contournés, ces outils permettent de détecter des modifications inattendues sur la page de connexion ou d’autres indices d’une attaque.
Sensibilisation des utilisateurs :
Former les utilisateurs à reconnaître les signes d’une tentative de phishing (URL étranges, absence de certificats de sécurité attendus, etc.) est une barrière importante contre ces attaques.
Encourager la vérification de l’authenticité des sites et des notifications de sécurité peut réduire le risque de compromission.
Gestion des sessions et réponses rapides :
En cas de compromission, disposer de procédures de réinitialisation rapides (révocation des sessions, changements de mots de passe, etc.) permet de limiter les dommages.
L’implémentation de solutions de sécurité capables d’alerter en temps réel sur des activités anormales (via par exemple Microsoft Entra ID Protection ou d’autres outils SIEM) renforce la réaction face à une attaque.
Dans cet article, je vous propose donc de tester 3 déploiements d’une application frauduleuse :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de mettre en place notre application frauduleuse de démonstration, nous allons avoir besoin de :
Une licence Microsoft Teams
Une souscription Azure valide pour le déploiement sur Azure (Etape IV)
Commençons par configurer Teams afin que nous puissions recevoir les notifications et les messages lorsque notre utilisateur de test s’est authentifié au travers de notre application frauduleuse.
Etape I – Configuration Teams :
Ouvrez votre console client de Teams afin de créer un nouveau canal dans l’équipe de votre choix :
Une fois le canal Teams créé, cliquez sur le bouton ci-dessous pour ajouter un connecteur externe :
Cliquez-ici pour ajouter le connecteur Webhook entrant en utilisant la barre de recherche :
Cliquez sur Ajouter :
Une fois le connecteur ajouté, cliquez sur Créer :
Copiez l’URI du connecteur Webhook dans un éditeur de texte :
Commençons par tester la méthode de déploiement proposée par zolder.io via Cloudflare.
Etape II – Méthode Cloudflare :
Cloudflare propose justement un plan gratuit qui permet d’utiliser les Cloudflare Workers, une plateforme serverless pour exécuter du code JavaScript.
Pour cela, connectez-vous sur la page suivante, puis créez un compte Cloudflare :
Si nécessaire, vérifiez votre compte Cloudflare grâce à l’e-mail reçu sur l’adresse renseignée :
Une fois sur votre tableau de bord Cloudflare, rendez-vous dans le menu suivant afin de créer un Worker :
Conservez ses propriétés de base, puis cliquez sur Déployer :
Une fois le Worker déployé, modifiez le code par le bouton ci-dessous :
Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez sur le fichier suivant :
Copiez le code du fichier worker.js :
Collez ce dernier dans un éditeur de texte :
Collez l’URI du connecteur Webhook Teams sur la ligne suivante :
Collez l’ensemble pour remplacer le code déjà présent sur votre worker Cloudflare, puis cliquez sur Déployer :
Attendez quelques secondes la mention de la sauvegarde en bas de page :
Cliquez sur ce lien afin d’ouvrir un nouvel onglet sur votre application frauduleuse :
Attendez quelques minutes et/ou rafraîchissez la page web plusieurs fois au besoin afin d’obtenir le résultat suivant :
Renseignez le nom de compte de votre utilisateur de test, puis cliquez sur Suivant :
Renseignez le mot de passe de votre utilisateur de test, puis cliquez sur Suivant :
Cliquez sur Oui :
Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :
Retournez sur le canal Teams créé précédemment afin de constater l’apparition d’un premier message provenant du connecteur Webhook, et contenant le login et mot de passe de l’utilisateur de test :
Un second message Teams apparaît également dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Demandez à n’importe quelle IA générative de parser ce texte en JSON avec le prompt suivant :
Convertis cette chaîne de cookies en un snippet JavaScript qui utilise JSON.parse pour créer un tableau d’objets cookies, puis qui les applique avec document.cookie en leur assignant une date d’expiration fixe, comme dans cet exemple :
JSON.parse('[{"name":"ESTSAUTHPERSISTENT","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"ESTSAUTH","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"SignInStateCookie","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true}]').forEach(c => document.cookie = c.name + "=" + c.value + "; expires=Wed, 05 Aug 2040 23:00:00 UTC; path=/");
Copiez / collez le résultat obtenu par l’IA dans un éditeur de texte :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Moins d’une heure après la publication de notre application frauduleuse chez Cloudflare, un nouvel e-mail nous informe de la détection de notre application et la fermeture de celle-ci :
La console Cloudflare de notre application frauduleuse devient alors inexploitable :
Enfin, il en est de même côté client pour l’URL générée pour notre application frauduleuse :
Continuons les tests en effectuant un déploiement en local de l’application frauduleuse.
Etape III – Méthode locale :
Rendez-vous sur la page suivante pour télécharger Node.js :
Lancez l’installation de Node.js, puis cliquez sur Suivant :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois Node.js correctement installé, cliquez sur Terminer :
Rendez-vous sur la page suivante pour télécharger les outils d’exécution locale d’Azure Functions :
Lancez l’installation, puis cliquez sur Suivant :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois les outils Azure Functions correctement installés, cliquez sur Terminer :
Rendez-vous sur la page suivante pour télécharger Visual Studio Code :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois Visual Studio Code correctement installé, cliquez sur Terminer :
Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez-ici pour télécharger l’archive au format ZIP :
Décompressez l’archive ZIP dans un dossier local de votre choix :
Ouvrez Visual Studio Code, puis cliquez sur le bouton ci-dessous :
Choisissez le dossier précédemment créé en local :
Confirmez votre confiance en ce dernier :
Ouvrez par le menu suivant la console Terminal intégrée à Visual Studio Code :
Saisissez la commande suivante afin d’ajouter le webhook de votre canal Teams :
func settings add TEAMS_WEBHOOK_URI "https://"
Constatez l’apparition de votre configuration webhook Teams dans le fichier suivant :
Lancez la commande suivante pour installer le package @azure/functions dans votre projet Node.js et l’ajouter comme dépendance dans le fichier package.json.
npm install @azure/functions --save
Lancez la commande suivante pour démarrer l’application frauduleuse en local tout en affichant des informations détaillées de log pour le diagnostic.
func start --verbose
Choisissez node :
Attendez quelques secondes afin de constater le bon démarrages des 4 fonctions de l’application frauduleuse :
Copiez l’URL suivante :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Cliquez sur Oui :
Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :
Retournez sur le canal Teams créé précédemment afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Terminons nos tests par un déploiement de notre application frauduleuse sur Azure.
Etape IV – Méthode Azure :
Ouvrez un onglet vers ce répertoire GitHub, puis cliquez-ici pour déployer votre application frauduleuse sur Azure :
Renseignez tous les champs ci-dessous dont également l’URI de votre webhook Teams, puis lancez la validation Azure:
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 10 minutes la fin de la création des ressources Azure, puis cliquez-ici :
Cliquez sur la fonction Azure créée lors du déploiement :
Copiez l’URL de votre application frauduleuse, puis vérifiez la bonne activation des différentes fonctionnalités :
Ajoutez au besoin un domaine personnalisé afin de rendre l’URL de votre site moins suspicieux :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Retournez sur le canal Teams précédemment créé afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Testons maintenant si l’ajout d’une MFA renforce la protection de notre compte de test.
Etape V – Ajout de Microsoft Authenticator :
Configurez une méthode MFA de type Microsoft Authenticator sur votre utilisateur de test :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA à votre utilisateur de test :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Réussissez le challenge MFA demandé par Microsoft via la notification reçue sur votre compte Microsoft Authenticator :
Retournez sur le canal Teams précédemment créé afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies précédemment copié, appuyez sur la touche Entrée, puis fermer la fenêtre du mode Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application, sans souci particulier concernant l’instauration de la MFA :
Etape VI – Restriction des adresses IPs :
Configurez une police d’accès conditionnel avec une restriction sur votre adresse IP publique sur votre utilisateur de test afin d’empêcher toute autre lieu de s’y connecter :
L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès malgré sa bonne localisation :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Etape VII – Ajout d’une méthode MFA résistante au phishing :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA résistante au phishing à votre utilisateur de test :
L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Etape VIII – Restriction des postes locaux :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une machine locale jointe à Entra ID pour votre utilisateur de test :
Malgré que la machine soit jointe à Entra ID et conforme, l’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Conclusion
Qu’il s’agisse d’un déploiement via Cloudflare, d’un environnement local ou d’un déploiement sur Azure, cela illustre la facilité avec laquelle ces attaques peuvent être exécutées.
Pourtant, elles soulignent également l’importance cruciale d’une authentification renforcée (avec des solutions telles que FIDO2 ou autres) et de politiques d’accès conditionnel strictes.
La surveillance continue, la gestion proactive des sessions et la sensibilisation des utilisateurs complètent ce dispositif de défense pour mieux protéger les environnements Cloud. Ces mesures, lorsqu’elles sont correctement implémentées, offrent une barrière robuste contre l’exploitation des failles de sécurité et renforcent significativement la protection des systèmes face aux menaces modernes.
Pour information, environ 12 heures après mon déploiement, la fonction Azure était toujours opérationnelle mais l’URL personnalisée avait bien été détectée et bloquée :
Dans la série des démonstrations très intéressantes sur l’intelligence artificielle, j’appelle le RAG local ! Comme toujours, Alex de la chaîne YouTube The Code Wolf nous montre comment en quelques clics il est possible d’installer et tester une IA sur votre poste local, tout en y ajoutant des données spécifiques (RAG) afin d’en améliorer les réponses.
Mais qu’est-ce que le RAG ?
Le Retrieval Augmented Generation (RAG) est une approche novatrice qui combine le meilleur de deux mondes en IA : la recherche d’informations (retrieval, qui ne génère pas de réponse originale) et la génération de contenu (qui ne s’appuie que sur les données de son entraînement). Traditionnellement, les LLM génèrent du contenu en s’appuyant uniquement sur les informations apprises durant leur phase d’entraînement. Le RAG, en revanche, permet au modèle de « consulter » une base de données ou un corpus de documents externes en temps réel pour enrichir sa génération de texte. Cette capacité de recherche améliore significativement la précision, la pertinence et la richesse du contenu généré.
La qualité de la base de données est un élément crucial pour le fonctionnement du RAG. Une base de données riche, variée et actualisée permet au modèle d’acquérir une connaissance approfondie et de générer des réponses plus précises et pertinentes.
La recherche d’informations joue également un rôle important en permettant au RAG de trouver les éléments les plus pertinents dans la base de données et de les utiliser pour inspirer ses réponses.
Voici un exemple des étapes pour mieux comprendre les interactions :
Étape
Description
1. Question
L’utilisateur demande : « Quelle est la vitesse de la lumière dans le vide ? »
2. Embedding de texte
La question est convertie en vecteur (séquence numérique) pour capturer sa signification.
3. Corpus et base de données vectorielle
Les documents sont découpés en passages courts et convertis en vecteurs, stockés dans une base de données vectorielle.
4. Recherche
Le module de recherche compare les vecteurs de la question aux vecteurs des documents pour trouver les plus similaires.
5. Réponse
Le LLM utilise la question et les extraits récupérés pour générer une réponse pertinente : « La vitesse de la lumière dans le vide est de 299 792 458 mètres par seconde »
Mais comment tester le RAG en local ?
Voici un exemple des ressources nécessaires pour y parvenir :
Composant
Description
Bibliothèques et outils
– SentenceTransformers pour les embeddings de texte. – Un modèle de langage comme ollama. – qdrant, Faiss ou Annoy pour la base de données vectorielle.
Données
– Corpus de documents à utiliser pour la recherche. – Données prétraitées et converties en vecteurs.
Environnement de développement
– Python ou .NET – Docker
Serveur RAG
– Framework comme R2R (Ready-to-Run) pour déployer le pipeline RAG. – API pour interagir avec le pipeline.
Faut-il un GPU pour faire du RAG ?
L’utilisation d’un GPU pour mettre en place le RAG n’est pas strictement nécessaire, mais elle peut grandement améliorer les performances, surtout pour les tâches de génération de texte et de traitement de grandes quantités de données. Voici quelques points à considérer :
Sans GPU :
Possible : Tu peux utiliser un CPU pour les tâches de RAG, mais cela peut être plus lent, surtout pour les modèles de langage volumineux.
Limité : Les performances peuvent être limitées, ce qui peut affecter la rapidité et l’efficacité du système.
Avec GPU :
Accélération : Un GPU peut accélérer les calculs nécessaires pour les embeddings de texte et la génération de réponses.
Efficacité : Améliore la capacité à traiter des requêtes en temps réel et à gérer des corpus de données plus importants.
En résumé, bien que l’on puisse mettre en place un système RAG sans GPU, l’utilisation de ce dernier est recommandée pour des performances optimales, surtout si l’on travaille avec des modèles de langage avancés et des bases de données volumineuse.
Voici donc la vidéo de The Code Wolf qui va nous servir de base à notre démonstration :
Son programme, lui-même basé sur les données de ce GitHub, met en place un chatbot intelligent utilisant des données de Zelda, grâce à la technique RAG.
Dans cet article, je vous propose de tester son application via deux machines virtuelles Azure :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de mettre en place une application RAG en local, nous allons avoir besoin de :
Un poste local ayant un GPU puissant pouvant effectuer de la virtualisation
ou
Un tenant Microsoft active
Une souscription Azure valide
Ayant des crédits Azure, je vous propose dans ma démonstration de partir sur la seconde solution. Un petit souci vient malheureusement heurter mon raisonnement : les SKUs de machine virtuelle Azure pouvant faire de la virtualisation n’ont pas de GPU puissant.
Je vais donc créer 2 machines virtuelles Azure :
Machine virtuelle CPU pour Docker + tests RAG CPU
Machine virtuelle GPU pour tests RAG GPU
Commençons par créer la première machine virtuelle CPU.
Etape I – Préparation de la machine virtuelle CPU :
Depuis le portail Azure, commencez par rechercher le service des réseaux virtuels :
Cliquez-ici pour créer votre réseau virtuel :
Nommez ce dernier, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre réseau virtuel :
Environ 30 secondes plus tard, la ressource Azure est créée, cliquez-ici :
Cliquez-ici pour déployer le service Azure Bastion :
N’attendez-pas la fin du déploiement d’Azure Bastion, recherchez le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle CPU :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présente dans la famille Dasv6 :
Renseignez un compte d’administrateur local, puis cliquez sur Suivant :
Rajoutez ou non un second disque de données, puis cliquez 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 CPU :
Renseignez les identifiants renseignés lors de la création de votre VM :
Acceptez les conditions Microsoft :
Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, fermez l’installation :
Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, redémarrez la machine virtuelle :
Quelques secondes plus tard, relancez une connexion via Azure Bastion :
Rendez-vous sur la page suivante afin de télécharger Ollama :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :
http://localhost:11434/
Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :
ollama pull phi3:mini
Ollama télécharge alors la version mini de Phi3 d’environ 2 Go :
Lancez la seconde commande suivante :
ollama pull nomic-embed-text
Ollama télécharge alors un modèle ouvert d’environ 270 Mo :
Vérifiez la liste des modèles en place avec la commande suivante :
ollama list
Rendez-vous sur la page suivante afin de télécharger Docker en version Desktop :
Conservez ces 2 cases cochées, puis cliquez sur OK pour lancer l’installation :
Attendez quelques minutes que l’installation se termine :
Cliquez-ici pour redémarrer à nouveau la machine virtuelle CPU :
Quelques secondes plus tard, relancez une connexion via Azure Bastion :
Attendez si nécessaire la fin de l’installation de composants additionnels :
Depuis le menu Démarrer de la session Windows, ouvrez l’application Docker :
Acceptez les conditions d’utilisation de Docker :
Cliquez sur le bouton Finaliser :
Cliquez-ici :
Cliquez-ici :
Attendez le démarrage du service de virtualisation Docker :
Une fois le service correctement démarré, vous ne devriez voir pour le moment aucun conteneurs :
Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :
docker run -p 6333:6333 -p 6334:6334 -d --name qdrant qdrant/qdrant
Cette commande Docker permet de Qdrant, qui est une base de données vectorielle sous forme de conteneur.
Cela te permet d’utiliser Qdrant pour stocker et rechercher des vecteurs dans ton pipeline RAG :
Autorisez Docker à pouvoir passer au travers de Windows Firewall :
Retournez sur la console de Docker afin de constater le bon démarrage du conteneur :
Notre environnement de test est en place, nous allons maintenant pouvoir récupérer l’application et les données RAG.
Etape II – Chargement de la base de données vectorielle :
Ce premier programme effectue plusieurs tâches pour créer une base de données vectorielle avec Qdrant et générer des embeddings de texte à l’aide d’Ollama.
Voici un résumé des étapes :
Création des clients :
Crée un client Qdrant pour interagir avec la base de données vectorielle.
Crée un client Ollama pour générer des embeddings de texte.
Chargement des données :
Charge des enregistrements de différents fichiers JSON (lieux, boss, personnages, donjons, jeux) et les désérialise en objets ZeldaRecord.
Vectorisation des données chargées :
Pour chaque enregistrement, génère un embedding en utilisant le client Ollama.
Crée une liste de structures de points (PointStruct) contenant les embeddings et les informations associées (nom et description).
Insertion des données dans Qdrant :
Crée une collection dans Qdrant pour stocker les enregistrements vectorisés.
Insère les enregistrements dans la base de données Qdrant.
Lancez l’extraction des fichiers dans un dossier local de votre choix :
Ouvrez Visual Studio Code installé précédemment, puis ouvrez le dossier créé :
Confirmez la confiance dans le dossier comme ceci :
Ouvrez le terminal de Visual Studio Code via le menu suivant :
Positionnez-vous dans le dossier populateDb, puis lancez la commande suivante :
dotnet run
Le chargement des données dans la base de données vectorielle commence :
Ouvrez le gestionnaire des tâches Windows afin constater l’utilisation du CPU pour ce traitement :
Quelques minutes plus tard, en fonction de la performance de votre machine virtuelle, le traitement se termine via le message de succès suivants :
Ouvrez la page web suivante afin de constater dans la console qdrant la création de la collection RAG, puis cliquez-ici :
http://localhost:6333/dashboard
Choisissez sur un point présent dans la liste de la collection, puis cliquez ici pour y voir plus détail :
Constatez la représentation graphique de la base de données :
Cliquez sur un des points en relation avec le premier consulté :
Cliquez à nouveau sur un des points en relation avec le second consulté :
Copiez les vecteurs d’un des points consultés :
Ouvrez Notepad pour y coller les valeurs de vecteur afin de voir comment ces derniers sont formulés :
Nos données RAG sont maintenant chargées. Nous allons maintenant pouvoir tester les prompts depuis la seconde partie de l’application.
Etape III – Lancement de prompts IA RAG :
Ce programme va nous permettre de poser des questions sur des sujets liés à Zelda et d’obtenir des réponses pertinentes en utilisant des données spécifiques grâce à la recherche vectorielle et à la génération de texte.
Avant de lancez le programme, vérifiez, et modifiez au besoin la version exacte de celle téléchargée pour phi3, puis sauvegardez vos modifications :
Positionnez-vous dans le dossier RagApp, puis lancez la commande suivante :
dotnet run
Posez une question sans rapport avec l’univers de Zelda dans un premier temps :
Posez ensuite une question en rapport avec l’univers de Zelda :
Constatez les lenteurs de réponse de l’intelligence artificielle et l’utilisation intensive du CPU :
Confirmez la durée d’utilisation du CPU en fonction de la longueur des réponses de l’IA :
Confirmez l’utilisation exclusive du CPU par la commande suivante :
ollama ps
Bien que l’utilisation d’un CPU soit possible pour certaines tâches d’IA, l’absence de GPU peut entraîner des performances réduites, des limitations dans l’utilisation de modèles avancés, une consommation accrue de ressources et des défis en termes de scalabilité.
Nous allons donc continuer les tests avec la mise en place d’une seconde machine virtuelle GPU dans Azure.
Etape IV – Préparation de la machine virtuelle GPU :
Avant de créer la machine virtuelle GPU depuis Azure, créez la règle de firewall Windows suivante sur la première machine virtuelle afin de rendre accessible qdrant :
Recherchez à nouveau le service des machines virtuelles :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présente dans la famille N :
Renseignez un compte d’administrateur local, puis cliquez 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 GPU :
Renseignez les identifiants renseignés lors de la création de votre VM :
Acceptez les conditions Microsoft :
Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :
Une fois téléchargée, lancez l’installation :
Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, redémarrez la machine virtuelle :
Quelques secondes plus tard, relancez une connexion via Azure Bastion :
Sur cette page, téléchargez le pilote NVIDIA GRID :
Confirmez le dossier de décompression au niveau local :
Attendez environ 30 secondes que la décompression se termine :
Après une rapide vérification système, cliquez sur Accepter et Continuer :
Cliquez sur Suivant :
Une fois l’installation terminée avec succès, cliquez sur Fermer :
Ouvrez le Gestionnaire des tâches Windows afin de constater l’apparition d’une section GPU :
Rendez-vous sur la page suivante afin de télécharger Ollama :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :
http://localhost:11434/
Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :
ollama pull phi3:mini
Ollama télécharge alors la version mini de Phi3 d’environ 2 Go :
Lancez la seconde commande suivante :
ollama pull nomic-embed-text
Ollama télécharge alors un modèle ouvert d’environ 270 Mo :
Vérifiez la liste des modèles en place avec la commande suivante :
ollama list
Vérifiez le bon accès à qdrant situé lui sur la machine virtuelle CPU :
Lancez l’extraction des fichiers dans un dossier local de votre choix :
Etape V – Chargement de la base de données vectorielle :
Ouvrez Visual Studio Code, ouvrez le dossier créé, puis indiquez l’IP locale de la machine virtuelle CPU :
Modifiez également 2 fois le nom de la nouvelle collection créée sur la machine virtuelle GPU, puis Sauvegardez :
Positionnez-vous dans le dossier populateDb, puis lancez la commande suivante :
dotnet run
Ouvrez le Gestionnaire des tâches Windows afin constater l’utilisation plus efficace du GPU pour ce traitement de chargement :
Ouvrez la page web suivante afin de constater dans qdrant la création de la seconde collection RAG, puis cliquez-ici :
http://10.0.0.4:6333/dashboard
Etape VI – Lancement de prompts IA RAG :
Avant de lancez le second programme, vérifiez, et modifiez au besoin l’adresse IP, la version de phi3, la collection utilisée, puis Sauvegardez vos modifications :
Positionnez-vous dans le dossier RagApp, lancez la commande suivante, puis posez une question en rapport avec l’univers de Zelda :
dotnet run
Constatez la pleine puissance GPU pour le traitement :
Constatez la rapidité du texte généré par l’IA :
Confirmez l’utilisation du GPU par la commande suivante :
ollama ps
Conclusion
En conclusion, la mise en place d’une IA RAG (Retrieval-Augmented Generation) sur votre propre PC est un processus réalisable, même sans GPU.
Cependant, l’utilisation d’un GPU est fortement recommandée pour améliorer les performances, surtout pour les tâches de génération de texte et de traitement de grandes quantités de données.
Maintenant, il ne reste plus qu’à tester et affiner votre application et vos données pour obtenir des résultats RAG parfait😎
Microsoft innove pour Windows Serveur 2025 et propose de payer la licence via un abonnement paiement à l’utilisation (PAYG) grâce à Azure Arc ! Avec cette option, vous déployez une VM et payez uniquement pour l’utilisation. Cette fonctionnalité est facturée directement sur votre abonnement Azure. Vous pouvez désactiver le paiement à l’utilisation à tout moment. Enfin, le tarif semble assez intéressant 😎
Une vidéo de John existe déjà sur le sujet 🙏💪 :
Dans cet article, je vous propose de tester et surtout de voir combien cela coûte💰:
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice de licence PAYG sur Windows Serveur 2025, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Afin de tester cette fonctionnalité de licensing utilisant Azure Arc, nous allons avoir besoin de lier nos VMs de test à une souscription Azure présente sur notre tenant Microsoft.
Pour cela, je vous propose donc de simuler plusieurs VMs sous Windows Serveur 2025 grâce à un environnement Hyper-V créé sous Azure.
Dans Azure, il est en effet possible 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 :
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 :
Renseignez les informations de l’administrateur local, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la machine virtuelle invitée (Windows Serveur 2025),créée plus tard dans notre machine virtuelle Hyper-V, puis cliquez sur Suivant :
Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle Hyper-V :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :
Peu après, constatez le déploiement réussi d’Azure Bastion via la notification Azure suivante :
Renseignez les identifiants renseignés lors de la création de votre VM Hyper-V :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM Hyper-V :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume au format NTFS :
Une fois connecté sur votre machine virtuelle Hyper-V, ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
Depuis la console Server Manager, ouvrez Hyper-V Manager :
Ouvrez le menu suivant :
Contrôlez la présence de votre switch virtuel créé précédemment :
L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle sous Windows Serveur 2025.
Etape II – Création de la machine virtuelle :
Pour cela, il est nécessaire de récupérer une image au format ISO de Windows Serveur 2025, puis de lancer l’installation.
Toujours sur la machine virtuelle Hyper-V, ouvrez le navigateur internet Microsoft Edge.
Dans mon cas, je suis passé par Visual Studio pour télécharger l’image au format ISO de Windows Serveur 2025 :
Attendez quelques minutes pour que le téléchargement se termine :
Une fois le fichier téléchargé, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows Serveur 2025 :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :
Pensez à bien choisir Génération 2 :
Modifier 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 de Windows Serveur 2025 téléchargé précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :
Une fois la machine virtuelle créée, cochez la case suivante pour activer TPM, puis augmenter le nombre de processeurs :
Double-cliquez sur votre machine virtuelle invitée, puis cliquez-ici pour lancer son démarrage :
La machine virtuelle est maintenant prête à recevoir Windows Serveur 2025. Suivez toutes les étapes de l’installation pour le configurer.
Etape III – Installation de Windows Serveur 2025 :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Définissez la langue de votre clavier, puis cliquez sur Suivant :
Lancez l’installation de Windows Serveur 2025 :
Cliquez-ici afin de ne pas renseigner de clef de licence Windows Serveur 2025 pour utiliser par la suite une licence en PAYG :
Choisissez une version Desktop, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Lancez l’installation de Windows Serveur 2025 :
Attendez maintenant quelques minutes la fin de l’installation de Windows Serveur 2025 :
Attendez que le redémarrage se poursuivre :
Définissez un mot de passe à votre compte local, puis cliquez sur Suivant :
Déverrouillez la session Windows :
Renseignez à nouveau le mot de passe de votre compte administrateur pour ouvrir la session :
Adaptez la configuration des remontées télémétriques, puis cliquez sur Accepter :
Windows Serveur 2025 est maintenant installé sur notre machine virtuelle. Il nous faut maintenant configurer Azure Arc afin que la liaison avec Azure puisse mettre en place la licence PAYG.
Etape IV – Configuration d’Azure Arc :
Une fois la session Windows ouverte, ouvrez les paramètres systèmes depuis le menu Démarrer :
Constatez l’absence de licence Windows Serveur 2025 active, puis cliquez dessus :
L’erreur suivante concernant l’activation apparaît alors :
Ouvrez le programme de configuration d’Azure Arc déjà préinstallé :
Cliquez sur Suivant :
Attendez quelques instants afin que l’installation se finalise :
Une fois Azure ARC installé, cliquez sur Configurer :
Cliquez sur Suivant :
Cliquez-ici afin de générer un code d’activation à usage unique :
Copiez le code généré :
Rendez-vous sur la page web indiquée, puis collez le code précédemment copié :
Authentifiez-vous avec un compte Azure disposant des droits nécessaires :
Cliquez sur Suivant :
Sélectionnez Pay-as-you-go, puis cliquez sur Suivant :
Sur le dernier écran de la procédure de configuration, sélectionnez Terminer :
Constatez la bonne connexion à Azure Arc via l’icône de notification suivant :
La liaison via Azure Arc est maintenant opérationnelle, mais la licence Windows Serveur 2025 n’est pas encore appliquée sur votre machine virtuelle. Nous allons devoir terminer la configuration de celle-ci depuis le portail Azure.
Etape V – Gestion de la licence PAYG :
Retournez sur la page système d’activation de Windows afin de constater la présence d’un autre message d’erreur :
Retournez sur le portail Azure, puis cliquez sur la nouvelle ressource Azure représentant notre machine virtuelle et créée après la fin de la configuration d’Azure Arc :
Dans le menu Licences du volet gauche, cochez la case Pay-as-you-go with Azure, puis sélectionnez Confirmer :
Attendez quelques minutes afin de constater la bonne activation de celle-ci :
Cette information est également visible depuis la page principale de la ressource Arc :
Rouvrez la page système d’activation de Windows afin de constater la bonne activation de la licence Windows :
Afin de comprendre un peu mieux les mécanismes de licences PAYG via Azure Arc, j’ai créé au total 4 machines virtuelles sur mon serveur Hyper-V :
Machine virtuelle Windows Serveur Standard 4 cœurs,
Machine virtuelle Windows Serveur Standard 4 cœurs éteinte par la suite,
Machine virtuelle Windows Serveur Datacentre 4 puis 8 cœurs par la suite,
Machine virtuelle Windows Serveur Standard 12 cœurs.
J’y ai également configuré Azure Arc, et activé les licences Windows Serveur 2025 via ma souscription Azure :
Mon environnement de test est maintenant en place, il ne nous reste qu’à attendre plusieurs jours afin de comprendre les coûts facturés par Microsoft via ma souscription Azure.
Etape VI – Analyse des coûts de licence :
Afin de comprendre les coûts de facturation pour les différentes machines virtuelles fonctionnant sous Windows Serveur 2025 PAYG, je vous propose d’utiliser le Gestionnaire des coûts Azure :
Utilisez les différents filtres disponibles pour identifier les coûts qui vous intéressent :
Commençons par analyser les 7 premiers jours suivant la configuration de mon environnement de test :
Comme le montre le gestionnaire des coûts ci-dessus, ainsi que la documentation Microsoft ci-dessous, aucun frais de licence n’est facturé durant les 7 premiers jours :
En outre, vous pouvez utiliser le paiement à l’utilisation gratuitement pour les sept premiers jours après l’avoir activé en tant qu’essai.
Pour plus de clarté, j’ai également transposé ces premiers résultats dans un tableau Excel :
J’ai continué avec les 3 jours suivants, cette fois facturés par Microsoft :
Comme le montre le gestionnaire des coûts ci-dessus, ainsi que la documentation Microsoft ci-dessous, des frais journaliers en fonction du nombre de cœurs de chaque VM sont facturés :
Pour plus de clarté, j’ai également transposé ces résultats dans un tableau Excel :
Deux informations sont intéressantes dans ce tableau :
La tarification par cœur Microsoft semble identique pour des machines sous licence Standard ou Datacentre.
Il semble que le prix $33.58 indiqué par Microsoft dans la documentation ne corresponde pas à un prix unitaire relevé par cœur, mais pour 2 cœurs :
J’ai ensuite effectué par la suite 2 modifications sur 2 de mes machines virtuelles de test :
Arrêt d’une machine virtuelle
Augmentation du nombre de cœurs
Pour plus de clarté, j’ai également transposé ces résultats dans un tableau Excel :
L’arrêt de la machine virtuelle le 24 décembre montre bien une baisse des coûts de licence pour les jours suivants.
Le passage de 4 à 8 cœurs indique bien un doublement des coûts de licences pour les jours suivants.
Voici enfin le même tableau Excel dans sa totalité
Conclusion
En résumé, cette nouvelle approche pour licencier des serveurs en dehors du cloud est facile à mettre en œuvre et semble très intéressante financièrement. Les tests ont montré qu’un arrêt de machine virtuelle réduit les coûts de licence, tandis que l’augmentation du nombre de cœurs entraîne une augmentation proportionnelle des coûts.
Ces observations soulignent l’importance de gérer judicieusement les ressources et les configurations de vos machines virtuelles pour toujours optimiser au mieux les coûts de licence.
Enfin, pour la gestion des licences Azure, il est fortement recommandé de considérer Azure Hybrid Benefit pour la majorité des machines virtuelles sous Windows pour maximiser les économies.
La restriction du presse-papier Windows entre le poste local et une session Azure Virtual Desktop est déjà possible depuis la configuration du protocole RDP. Mais la personnalisation des restrictions peut être poussée encore d’un cran. Avec Intune, vous pouvez exiger que le fameux copier-coller ne fonctionne que dans un sens spécifique, ou même uniquement que pour certains types de donnée !
Comme annoncé en introduction, vous pouvez déjà configurer beaucoup de paramètres RDP pour Azure Virtual Desktop. La configuration du protocole RDP est directement disponible depuis la configuration de votre pool d’hôtes de session Azure Virtual Desktop.
Le protocole RDP (Remote Desktop Protocol) possède plusieurs propriétés que vous pouvez définir pour personnaliser le comportement d’une session à distance, par exemple pour la redirection d’appareil, les paramètres d’affichage, le comportement de session, etc.
Quelles sont les propriétés RDP prises en charges par AVD ?
Toutes les propriétés existantes au protocole RDP ne sont pas intégrées à Azure Virtual Desktop. Voici la liste de ceux compatibles avec AVD, et sont aussi disponibles sur la page officielle de Microsoft :
Propriété RDP
Description
encode redirected video capture
Active ou désactive l’encodage de la vidéo redirigée.
targetisaadjoined
Autorise les connexions aux hôtes de session joints à Microsoft Entra à l’aide d’un nom d’utilisateur et d’un mot de passe. Cette propriété s’applique uniquement aux clients non-Windows et aux appareils Windows locaux qui ne sont pas joints à Microsoft Entra. Elle est remplacée par la propriété enablerdsaadauth.
camerastoredirect
Configure les caméras à rediriger. Ce paramètre utilise une liste délimitée par des points-virgules des interfaces KSCATEGORYVIDEOCAMERA des caméras activées pour la redirection.
redirected video capture encoding quality
Contrôle la qualité de la vidéo encodée.
maximizetocurrentdisplays
Détermine l’affichage d’une session à distance utilisée pour l’écran plein écran lors de l’optimisation. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
drivestoredirect
Détermine les lecteurs fixes, amovibles et réseau sur l’appareil local qui seront redirigés et disponibles dans une session à distance.
devicestoredirect
Détermine les périphériques qui utilisent le protocole MTP (Media Transfer Protocol) ou le protocole PTP (Picture Transfer Protocol), comme une caméra numérique, sont redirigés d’un appareil Windows local vers une session à distance.
usbdevicestoredirect
Détermine les périphériques USB pris en charge sur l’ordinateur client qui sont redirigés à l’aide d’une redirection opaque de bas niveau vers une session distante.
bandwidthautodetect
Détermine s’il faut ou non utiliser la détection automatique de la bande passante réseau.
redirected clipboard
Détermine s’il faut rediriger le Presse-papiers.
smart sizing
Détermine si l’appareil local met à l’échelle le contenu de la session distante pour qu’il corresponde à la taille de la fenêtre.
autoreconnection enabled
Détermine si l’appareil local tente automatiquement de se reconnecter à l’ordinateur distant si la connexion est supprimée, par exemple en cas d’interruption de la connectivité réseau.
redirectlocation
Détermine si l’emplacement de l’appareil local est redirigé vers une session distante.
audiomode
Détermine si l’ordinateur local ou distant lit l’audio.
compression
Détermine si la compression en bloc est activée lors de la transmission de données à l’appareil local.
videoplaybackmode
Détermine si la connexion utilisera le streaming multimédia efficace par RDP pour la lecture vidéo.
networkautodetect
Détermine si la détection automatique des types de réseau est activée.
dynamic resolution
Détermine si la résolution d’une session distante est automatiquement mise à jour lorsque la fenêtre locale est redimensionnée.
use multimon
Détermine si la session distante utilise un ou plusieurs affichages à partir de l’appareil local.
enablerdsaadauth
Détermine si le client utilisera l’ID Microsoft Entra pour s’authentifier auprès du PC distant. Lorsqu’il est utilisé avec Azure Virtual Desktop, cela offre une expérience d’authentification unique. Cette propriété remplace la propriété targetisaadjoined.
enablecredsspsupport
Détermine si le client utilisera le fournisseur de support de sécurité des informations d’identification (CredSSP) pour l’authentification s’il est disponible.
redirectsmartcards
Détermine si les appareils de carte à puce sur l’appareil local sont redirigés et disponibles dans une session à distance.
keyboardhook
Détermine si les combinaisons de touches Windows (Windows, OngletAlt+) sont appliquées à une session à distance.
redirectprinters
Détermine si les imprimantes disponibles sur l’appareil local sont redirigées vers une session à distance.
redirectcomports
Détermine si les ports série ou COM sur l’appareil local sont redirigés vers une session distante.
redirectwebauthn
Détermine si les requêtes WebAuthn d’une session distante sont redirigées vers l’appareil local, ce qui permet d’utiliser des authentificateurs locaux (tels que des clés de sécurité et de Windows Hello Entreprise).
screen mode id
Détermine si une fenêtre de session distante s’affiche en plein écran lorsque vous lancez la connexion.
singlemoninwindowedmode
Détermine si une session distante à affichage multiple bascule automatiquement vers un affichage unique lors de la sortie de l’écran plein écran. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
audiocapturemode
Indique si la redirection d’entrée audio est activée.
desktopheight
Spécifie la hauteur de résolution (en pixels) d’une session distante.
desktopwidth
Spécifie la largeur de résolution (en pixels) d’une session distante.
desktopscalefactor
Spécifie le facteur d’échelle de la session distante pour rendre le contenu plus grand.
kdcproxyname
Spécifie le nom de domaine complet d’un proxy KDC.
selectedmonitors
Spécifie les affichages locaux à utiliser dans une session distante. Les affichages sélectionnés doivent être contigus. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows, l’application Bureau à distance pour Windows et l’application de connexion Bureau à distance de boîte de réception sur Windows.
desktop size id
Spécifie les dimensions d’un bureau de session à distance à partir d’un ensemble d’options prédéfinies. Ce paramètre est remplacé si les paramètres desktopheight et desktopwidth sont spécifiés.
alternate shell
Spécifie un programme à démarrer automatiquement dans une session distante en tant que shell au lieu de l’Explorateur.
Où les modifier ?
Certaines propriétés RDP sont en effet modifiables depuis ces écrans du pool d’hôtes :
Informations de connexion :
Comportement de la session :
Redirection de périphérique :
Comme vous pouvez le voir dans la copie d’écran ci-dessous, la configuration détermine si le presse-papiers de l’ordinateur client sera redirigé et disponible ou non dans la session distante, et vice versa :
Le presse-papiers de l’ordinateur local est disponible dans la session à distance (par défaut)
Le presse-papiers de l’ordinateur local n’est pas disponible dans la session à distance
Non configuré
Paramètres d’affichage
Avancé
Peut-on configurer le comportement de redirection du Presse-papiers plus finement ?
Oui, cela est possible grâce à l’une des 3 méthodes suivantes :
Via Microsoft Intune
Via une stratégie de groupe
Via une ou des clefs de registre dans la golden image
Travis vous explique en détail la fonctionnalité via les clefs de registre Windows :
Dans cet article, je vous propose de tester la méthode via Intune :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Peu de prérequis sont nécessaires pour réaliser ce test AVD sur les restrictions du presse-papier Windows :
Un tenant Microsoft
Une souscription Azure valide
Dans ce test, nous allons déployer un environnement Azure Virtual Desktop composé de 5 machines virtuelles individuelles. Ces 5 machines nous permettront de comparer les différentes configurations Intune afin de voir les changement dans le presse-papier :
Aucune restriction
Restriction complète
Restriction depuis le poste local
Restriction depuis AVD
Restriction sur le format de donné
Etape I – Préparation Azure Virtual Desktop :
Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :
Nommez celui-ci, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1minute :
Une fois le réseau virtuel déployé, continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :
Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop
Choisissez un pool d’hôtes de type personnel, puis cliquez sur Suivant :
Définissez le nombre de machines virtuelles créées ainsi que la région Azure, puis choisissez l’image OS :
Choisissez les caractéristiques techniques de vos machines virtuelles AVD, puis spécifiez le réseau virtuel adéquat :
Effectuez une joindre à Entra ID en incluant Intune ainsi que les informations d’identification du compte administrateur local, puis cliquez sur Suivant :
Définissez un nouvel espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :
Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer l’assignation des utilisateurs :
Assignez les 5 utilisateurs de test à votre groupe d’application AVD :
Assignez ces mêmes 5 utilisateurs de test AVD aux 5 machines virtuelles créés :
N’oubliez pas la configuration RDP suivante, puis Sauvegarder :
Notre environnement Azure Virtual Desktop est maintenant en place. La suite de la configuration des restriction passera par le portail Intune.
Etape II – Configuration Intune :
Rendez-vous sur le portail Intune afin de créer 4 groupes Entra ID qui serviront à tester tous les scénarios de restriction du presse-papier :
Pour chacun de ces groupes, ajoutez dans chacun d’eux une machine virtuelles AVD de test :
Consultez la liste des machines virtuelles inscrites sur Intune pour vérification :
Commencez par créer une première police de configuration Intune, par exemple la restriction maximale :
Choisissez les options suivantes, puis cliquez sur Créer :
Nommez votre profil de configuration Intune, puis cliquez sur Suivant :
Recherchez dans le catalogue les options suivantes afin de les activer, ce qui aura pour effet de bloquer dans les 2 sens le presse-papier pour tous les types de transfert, puis cliquez sur Suivant :
Cliquez sur Suivant :
Ajouter un des 4 groupes de machines virtuelles créé précédemment, puis cliquez sur Suivant :
Vérifiez les paramètres une dernière fois, puis cliquez sur Créer :
Créer les 3 autres polices en faisant varier les réglages liés au presse-papier :
Retournez sur le menu suivant afin de pousser les configurations sur les machines virtuelles AVD dès que possible :
Renseignez les champs suivants, puis cliquez sur Suivant :
Ajoutez les machines virtuelles AVD, puis cliquez sur Suivant :
Lancez la synchronisation Intune en cliquant sur Créer :
Attendez quelques minutes afin de constater l’application avec succès des différentes polices de configuration sur les machines virtuelles AVD :
Attendez quelques minutes, puis retournez sur le portail Azure afin de redémarrer les machines virtuelles AVD pour que les modifications soient prises en compte :
Constatez l’indisponibilité des machines virtuelles AVD pendant la phase de redémarrage :
Constatez la disponibilité des machines virtuelles AVD quelques minutes plus tard :
Notre environnement avec les 5 machines virtuelles AVD est prêt pour les différents tests. Dans mon cas, je vais utiliser l’application Remote Desktop afin d’exécuter en parallèle les 5 sessions de bureau à distance :
J’ai donc ouvert 5 sessions AVD pour mes 5 utilisateurs de test :
Commençons par un premier test sans aucune restriction sur le presse-papier.
Etape III – Test Presse-papier sans restriction :
Cette première machine virtuelle n’est pas présente dans groupe Entra ID et n’a donc aucune police de configuration associée :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
Aucune configuration n’est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne
Continuons avec un second test avec une restriction complète du presse-papier.
Etape IV – Test Presse-papier avec restriction complète :
Cette seconde machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
2 configurations sont présentes dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Continuons avec un troisième test avec une restriction sur le presse-papier depuis le poste local.
Etape V – Test Presse-papier avec restriction depuis le poste local :
Cette troisième machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
1 configuration est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne
Continuons avec un quatrième test avec une restriction sur le presse-papier depuis AVD.
Etape VI – Test Presse-papier avec restriction depuis AVD :
Cette quatrième machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
1 configuration est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Continuons avec un dernier test avec une restriction sur le format de donnée sur le presse-papier.
Etape VII – Test Presse-papier avec restriction sur le format de donné :
Cette dernière machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
2 configurations sont présentes dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Le copier-coller d’un texte depuis AVD vers le poste local fonctionne
Le copier-coller d’une image depuis AVD vers le poste local fonctionne
Conclusion
La mise en place de restrictions sur le presse-papier via Intune renforcera la sécurité et son importance cruciale dans les environnements virtuels. En limitant le transfert de fichiers et certaines données sensibles, nous pouvons renforcer significativement la protection des informations.
Enfin, Intune permet de simplifier la gestion des politiques de sécurité Azure Virtual Desktop et Windows 365 via ses nombreuses règles disponibles sur étagère.
