💪Bastion Premium 💪

Comme tous les services Cloud, Azure Bastion continue d’évoluer et s’améliorer via l’ajout de nouvelles fonctionnalités très pratiques. Au travers de cet article, nous prendrons le temps de refaire un tour du service et de ses changements dans sa gamme et ses fonctionnalités, comme l’enregistrement automatique ou l’accès 100% privé.

Cet article n’est pas le premier à parler d’Azure Bastion sur ce blog, voici un lien vers celui écrit en 2023. Depuis cette date, le produit a subi quelques changements que nous aborderons ici.

Qu’est-ce qu’Azure Bastion ?

Côté Microsoft, le but de ce service de jump n’est pas changé :

Azure Bastion est un service PaaS entièrement managé que vous approvisionnez pour vous connecter en toute sécurité aux machines virtuelles via une adresse IP privée. Il fournit une connectivité RDP/SSH sécurisée et fluide à vos machines virtuelles, directement au travers du protocole TLS depuis le Portail Azure ou via un SSH natif ou un client RDP déjà installé sur votre ordinateur local. Quand vous vous connectez via Azure Bastion, vos machines virtuelles n’ont pas besoin d’adresse IP publique, d’agent ou de logiciel client spécial.

Microsoft Learn

Azure Bastion est donc toujours un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient sous Windows ou Linux.

Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :

Bastion fournit une connectivité RDP et SSH sécurisée à toutes les machines virtuelles du réseau virtuel pour lequel il est approvisionné. Azure Bastion protège vos machines virtuelles contre l’exposition des ports RDP/SSH au monde extérieur, tout en fournissant un accès sécurisé à l’aide de RDP/SSH.

Microsoft Learn

J’ai également reposté la vidéo dédiée à Azure Bastion en français juste ici :

Quel est le principal point fort d’Azure Bastion ?

Un seul mot me vient tout de suite en tête : SECURITE.

Comme tout service de jump, Azure Bastion devient de facto la ressource exposée de votre infrastructure Cloud. Dans les faits, ce dernier intègre des fonctions de pare-feu et des mesures périmétriques de sécurité.

De plus, l’accès au service depuis le portail Azure apporte la couche de pré-authentification d’Azure AD. Celui-ci profite alors de toutes ses mesures de sécurité, comme l’Accès conditionnel, la gestion des droits RBAC, etc …

L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.

Enfin, Azure Bastion mettra tout le monde d’accord grâce au retrait des adresses IP publiques sur vos VMs Azure, car la connexion RDP/SSH entre Bastion et votre machine virtuelle se fera via le réseau virtuel privé Azure, donc grâce et uniquement par son adresse IP privée.

Pour y voir plus clair, Microsoft met à disposition un tableau de ses principaux avantages :

Avantage	Description
RDP et SSH par le biais du portail Azure	Vous pouvez accéder directement à la session RDP et SSH directement dans le portail Azure via une expérience fluide en un seul clic.
Session à distance sur TLS et traversée de pare-feu pour RDP/SSH	Azure Bastion utilise un client web basé sur HTML5 qui est automatiquement diffusé sur votre appareil local. Votre session RDP/SSH utilise TLS sur le port 443. Le trafic peut ainsi traverser les pare-feu de façon plus sécurisée. Bastion prend en charge TLS 1.2. Les versions antérieures de TLS ne sont pas prises en charge.
Aucune adresse IP publique n’est nécessaire sur la machine virtuelle Azure.	Azure Bastion ouvre la connexion RDP/SSH à votre machine virtuelle Azure en utilisant l’adresse IP privée sur votre machine virtuelle. Vous n’avez pas besoin d’une adresse IP publique sur votre machine virtuelle.
Aucune contrainte liée à la gestion des groupes de sécurité réseau (NSG)	Vous n’avez pas besoin d’appliquer des groupes de sécurité réseau sur le sous-réseau Azure Bastion. Comme Azure Bastion se connecte à vos machines virtuelles par le biais d’une adresse IP privée, vous pouvez configurer vos groupes de sécurité réseau pour autoriser RDP/SSH depuis Azure Bastion uniquement. Vous n’avez plus à gérer les groupes de sécurité réseau chaque fois que vous devez vous connecter de manière sécurisée à vos machines virtuelles. Pour plus d’informations sur les groupes de sécurité réseau, consultez Groupes de sécurité réseau.
Vous n’avez pas besoin de gérer un hôte Bastion distinct sur une machine virtuelle	Azure Bastion est un service PaaS de plateforme entièrement géré d’Azure, renforcé en interne pour vous fournir une connectivité RDP/SSH sécurisée.
Protection contre l’analyse des ports	Vos machines virtuelles sont protégées contre l’analyse des ports par des utilisateurs malveillants, car vous n’avez pas besoin de les exposer à Internet.
Renforcement de la sécurité à un seul endroit	Azure Bastion résidant au périmètre de votre réseau virtuel, vous n’avez pas à vous soucier du durcissement de la sécurité de chacune des machines virtuelles de votre réseau virtuel.
Protection contre les exploits zéro-day	La plateforme Azure protège contre les exploits du jour zéro en assurant une sécurité durcie permanente et à jour pour Azure Bastion.

Mais combien coûte Azure Bastion ?

C’est à partir d’ici que les choses ont changé depuis mon dernier article. Il existe maintenant 4 SKUs disponibles pour Azure Bastion :

Développeur
Basic
Standard
Premium

Côté tarif, Microsoft met à disposition une table des tarif d’Azure Bastion sur cette page :

Pour bien se rendre compte des écarts de prix, cela donne les tarifs mensuels suivants :

Comme indiqué au-dessus, Azure Bastion en version Développeur est gratuit, mais votre accès unique repose alors sur une instance partagée d’Azure Bastion :

Pour les autres SKUs, Microsoft le dit et je vous le confirme : Azure Bastion est facturé dès que ce dernier est déployé peu importe son utilisation :

Azure Bastion est facturée toutes les heures à partir du moment où la ressource est déployée jusqu’à sa suppression, quelle que soit l’utilisation des données sortantes. La tarification horaire est basée sur la référence SKU sélectionnée, le nombre d’unités d’échelle configurées et les taux de transfert de données.

Tarification Microsoft

Quel SKU choisir pour Azure Bastion ?

Les fonctionnalités détermineront le SKU le plus adapté à votre besoin :

Fonctionnalité	Référence SKU Développeur	Référence De base	Référence Standard	SKU Premium
Se connecter pour cibler les machines virtuelles dans les mêmes réseaux virtuels	Oui	Oui	Oui	Oui
Se connecter pour cibler les machines virtuelles dans les réseaux virtuels appairés	Non	Oui	Oui	Oui
Prise en charge de connexions simultanées	Non	Oui	Oui	Oui
Accéder aux clés privées des machines virtuelles Linux dans Azure Key Vault (AKV)	Non	Oui	Oui	Oui
Se connecter à une machine virtuelle Linux avec SSH	Oui	Oui	Oui	Oui
Se connecter à une machine virtuelle Windows avec RDP	Oui	Oui	Oui	Oui
Se connecter à une machine virtuelle Linux avec RDP	No	Non	Oui	Oui
Se connecter à une machine virtuelle Windows avec SSH	No	Non	Oui	Oui
Spécifier le port d’entrée personnalisé	No	Non	Oui	Oui
Se connecter à des machines virtuelles à l’aide de Azure CLI	No	Non	Oui	Oui
Mise à l’échelle de l’hôte	No	Non	Oui	Oui
Charger ou télécharger des fichiers	No	Non	Oui	Oui
Authentification Kerberos	Non	Oui	Oui	Oui
Lien partageable	No	Non	Oui	Oui
Se connecter aux machines virtuelles via une adresse IP	No	Non	Oui	Oui

Note : Gardez en tête que pour vous pouvez monter en gamme le SKU de votre Azure Bastion, mais descendre vous sera impossible.

Comment mettre en place Azure Bastion ?

Rien de plus simple, quelques clics suffisent pour déployer Azure Bastion.

Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités des 4 SKUs d’Azure Bastion. Bref, ne perdons pas de temps :

Etape 0 – Rappel des prérequis :

Pour réaliser ce nouvel exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Mon environnement Azure de départ contient déjà 3 machines virtuelles :

Ces 3 machines virtuelles sont réparties sur 2 réseaux virtuels déployés dans 2 régions Azure :

Un appairage entre ces 2 réseaux virtuels est déjà en place :

Pour information, un déploiement rapide d’Azure Bastion est possible depuis une machine virtuelle :

Une autre méthode de déploiement rapide d’Azure Bastion est également disponible depuis un réseau virtuel :

Dans notre cas, nous allons personnaliser le déploiement d’Azure Bastion afin de pouvoir sélectionner le SKU Développeur.

Etape I – Déploiement d’Azure Bastion Développeur :

Comme indiqué en introduction, ce SKU gratuit fonctionne via une ressource Azure Bastion partagée et sécurisée :

L’intérêt principal d’utiliser ce SKU d’Azure Bastion est évidemment son prix, si aucune de ses limitations n’est bloquante pour vous :

Connexion impossible sur les réseaux virtuels appairée
Connexions simultanées impossibles
Authentification Kerberos impossible

Si cela vous convient, recherchez le service Bastion dans la barre de recherche du portail Azure :

Cliquez-ici pour créer votre Azure Bastion :

Renseignez les champs suivants :

Sélectionnez le SKU Développeur :

Constatez la liste réduite des régions Azure disponibles pour ce SKU :

Choisissez votre réseau virtuel déjà en place, puis cliquez sur Suivant :

Constatez que toutes les fonctionnalités annexes sont indisponibles avec ce SKU, puis lancez la validation Azure :

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

Attendez environ 1 minute pour que le service soit accessible sur votre environnement :

Sur une machine virtuelle présente sur le même réseau virtuel qu’Azure Bastion, connectez-vous à celle-ci :

La session de bureau à distance Windows s’ouvre bien via le protocole RDP :

Constatez l’URL spécifique de cette session Bastion pointant sur une ressource CDN :

Tentez d’utiliser votre Azure Bastion Développeur sur une autre machine virtuelle présente sur un réseau virtuel appairé au premier, sans succès :

*L’instance d’Azure Bastion **Développeur** déjà en place n’est pas reconnue.*

Sur ce SKU, il est malgré tout possible de restreindre les sources des sessions Bastion :

Bien que son prix soit gratuit, Azure Bastion en version Développeur limite certains besoins. Pour la suite, nous allons donc le migrer vers une gamme supérieure.

Etape II – Déploiement d’Azure Bastion Basic :

A partir de ce niveau de SKU, l’instance Azure Bastion n’est plus partagée mais dédiée à votre infrastructure. Cette intégration s’accompagne d’un sous-réseau dédié aux instances Azure Bastion :

Comparé à Bastion en version Développeur, l’intérêt d’utiliser ce SKU d’Azure Bastion repose sur les arguments suivants :

Connexion au réseaux virtuels appairés
Connexions simultanées
Authentification Kerberos
Intégration du coffre Azure Key Vault pour les clefs Linux

Retournez sur l’instance d’Azure Bastion Développeur déjà en place, puis mettez à jour son SKU en cliquant comme ceci :

A ce moment-là, il vous est demandé de mettre en place une adresse IP publique à votre service Bastion, mais aussi de créer un sous-réseau dédié à ce dernier :

Cliquez-ici pour ajouter un nouveau sous-réseau :

Choisissez dans la liste Azure Bastion, modifiez au besoin l’adressage puis cliquez sur Ajouter :

Une fois le sous-réseau ajouté, cliquez sur la croix en haut à droite :

Une seule option est alors dégrisée avec ce SKU, cochez-là si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service soit mis à jour sur votre environnement :

Une fois votre Azure Bastion mis à jour, retournez sur une machine virtuelle Windows d’un réseau virtuel appairé, puis lancez une connexion via Bastion comme ceci :

Un nouvel onglet dans votre navigateur ouvre bien une session RDP de votre machine virtuelle :

Refaite le même test sur une machine virtuelle Linux :

Un nouvel onglet dans votre navigateur ouvre bien une session SSH de votre machine virtuelle :

Constatez le changement dans la nature de l’URL pointant cette fois sur un DNS dédié :

Des informations sur les sessions Bastion actuellement en cours sont également disponibles :

Des métriques sur les ressources de votre Azure Bastion sont également visibles :

Enfin, il est également possible de constater les 2 composants Azure déployée sur ce sous-réseau dédié :

Continuons de mettre à jour notre instance Azure Bastion vers un SKU plus avancé.

Etape III – Déploiement d’Azure Bastion Standard :

Comparé à Azure Bastion de base, l’intérêt ce SKU d’Azure Bastion repose sur les arguments suivants :

Connexions via adresse IP
Connexions Linux en RDP
Connexions Windows en SSH
Personnalisation du port d’entrée possible
Augmentation du nombre d’instances
Génération de lien partageable

De nouvelles options sont dégrisées avec ce SKU, cochez-les si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service soit mis à jour sur votre environnement :

Une fois votre Azure Bastion mis à jour, un nouveau menu dédié aux liens partagés fait son apparition dans les paramètres votre Azure Bastion.

Cliquez-ici pour créer votre premier lien partagé :

Choisissez la machine virtuelle cible, puis cliquer sur Appliquer :

Le nouveau lien partagé s’ajoute aux liens déjà générés, copiez votre lien dans le presse-papier :

Ouvrez un navigateur privé, puis collez votre lien partageable dans la barre d’adresse, renseignez les identifiants de l’administrateur, puis cliquez-ici pour ouvrir la session :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance Windows :

Après avoir fermé la session Windows ouverte grâce au lien partagé, pensez à supprimer le lien généré :

Retournez sur la configuration d’Azure Bastion afin de faire varier le nombre d’instances, puis cliquez sur Appliquer :

Chaque instance peut prendre en charge 20 connexions RDP simultanées et 40 connexions SSH simultanées pour les charges de travail moyenne.

Si une instance supplémentaire est déployée, un coût additionnel est ajouté :

Azure Bastion propose de choisir le protocole et le port d’entrée pour les machines virtuelles :

Continuons de mettre à jour notre instance Azure Bastion vers un SKU plus avancé.

Etape IV – Déploiement d’Azure Bastion Premium :

Comparé à Azure Bastion Standard, l’intérêt d’utiliser ce nouveau SKU d’Azure Bastion repose sur les arguments suivants :

Enregistrement de session
Déploiement privé uniquement

Toutes les options sont alors dégrisées avec ce SKU, cochez-les si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service Bastion soit mis à jour sur votre environnement.

Enregistrement de session

Une fois mis à jour, copiez le nom DNS privé de votre service :

Afin de tester l’enregistrement de session d’Azure Bastion, il est nécessaire de créer un compte de stockage :

Une fois le compte de stockage créé, renseignez l’origine en reprenant le protocole https:// suivi du nom DNS privé de votre Azure Bastion.

Cela donne dans mon cas :

https://bst-9c038b3d-e74c-4838-9613-7a38c0f1fda3.bastion.azure.com

Cliquez ici pour créer un conteneur objet blob dédié :

Dans ce nouveau conteneur, créez une clef SAS avec les propriétés suivantes :

Copiez l’URL de votre nouvelle clef SAS :

Retournez sur votre service Azure Bastion afin de rajouter ce stockage :

Collez votre clef SAS, puis cliquez sur le bouton suivant :

Vérifiez l’absence de message d’erreur ou d’avertissement :

Testez l’enregistrement d’une session SSH en ouvrant une nouvelle connexion via Azure Bastion :

Après avoir terminé des manipulations dans votre session SSH, constatez l’apparition d’un blob sur le conteneur créé :

Constatez également l’apparition d’un enregistrement directement visualisable en cliquant ici :

L’enregistrement s’ouvre dans un nouvel onglet avec une barre de lecture :

Testez un second enregistrement pour une session RDP :

Azure Bastion Privé

Note : La mise en place d’une connexion 100% privée pour Azure Bastion déjà en place n’est pas possible après coup :

Il est donc nécessaire de commencer par supprimer votre Bastion déjà en place :

Une fois votre Bastion supprimé, vous pouvez également supprimer son adresse IP publique :

Le déploiement d’Azure Bastion en version privée se décide via la case à cocher suivante :

Une fois déployé, testez une connexion via cet Azure Bastion privé depuis un poste hors d’atteinte du réseau virtuel cible :

Constatez l’échec de cette tentative :

Afin de tester la connexion privée, j’ai créé un second Azure Bastion Standard sur un autre réseau virtuel appairé :

Puis j’ai activé la fonctionnalité lien partageable sur mon Bastion privé :

J’ai ensuite copié le lien partageable généré :

J’ai testé ce lien partageable privé, sans succès, sur mon poste local :

J’ai retesté avec succès ce même lien partageable privé depuis une session ouverte sur mon second Azure Bastion, dont le réseau virtuel est bien appairé à celui contenant mon Bastion privé :

Via cette méthode, j’ai pu me connecter sans souci à ma machine virtuelle de façon 100% privée :

Conclusion

Sécurité et simplicité sont les adjectifs qui définissent très bien Azure Bastion. Azure Bastion permet d’accéder en toute sécurité aux machines virtuelles via RDP/SSH sans nécessiter d’adresse IP publique, ce qui réduit considérablement les risques d’exposition aux menaces comme l’analyse de ports et les exploits zéro-day.

De plus, il centralise le renforcement de la sécurité en une seule couche, éliminant ainsi la nécessité de sécuriser individuellement chaque machine virtuelle. La flexibilité offerte par les différentes architectures et références SKU permet de s’adapter à divers besoins opérationnels tout en garantissant une connectivité fluide et sécurisée, même dans des configurations réseau complexes comme l’appairage de réseaux virtuels.

Améliorations Teams VDI

Microsoft vient d’annoncer il y a peu la disponibilité générale (GA) d’une nouvelle optimisation pour les communications Teams sur les environnements VDI (Azure Virtual Desktop, Windows 365) baptisée SlimCore. Nous allons voir dans cet article de quoi il en retourne, et comment la mettre en place.

Prenons un peu de temps pour resituer ce changement majeur pour la VDI.

Qu’est-ce que SlimCore ?

SlimCore est un moteur multimédia développé par Microsoft pour remplacer WebRTC (Web Real-Time Communication) dans certaines applications comme Microsoft Teams. Il gère l’audio, la vidéo et le partage d’écran dans le nouveau client Teams pour ordinateur, offrant de meilleures performances, qualité et fiabilité par rapport à WebRTC.

Les principaux avantages de SlimCore sont :

Parité des fonctionnalités et performances : SlimCore permet à Teams sur l’infrastructure de bureau virtuel (VDI) d’avoir des fonctionnalités et des performances similaires à celles du client Teams natif, ce qui facilite l’ajout rapide de nouvelles fonctionnalités et la réduction des écarts présents avec WebRTC.
Amélioration de la qualité des appels : SlimCore optimise les performances audio et vidéo, réduisant les problèmes tels que les interruptions d’appels et la latence.
Mises à jour automatiques : SlimCore est mis à jour automatiquement, garantissant que le moteur multimédia reste compatible avec les dernières fonctionnalités de Teams, sans nécessiter d’intervention manuelle ou de mises à jour d’infrastructure.

SlimCore vs WebRTC ?

SlimCore est plus performant et optimisé pour Microsoft Teams, en particulier dans des environnements VDI, avec des mises à jour transparente et une intégration plus poussée dans l’écosystème Microsoft, tandis WebRTC est une solution plus flexible et ouverte, utilisée dans de nombreuses plateformes, mais avec des performances parfois limitées dans des environnements plus complexes comme le VDI :

Caractéristique	SlimCore	WebRTC
Origine et usage	Moteur multimédia propriétaire développé par Microsoft pour Teams. Utilisé dans le client natif et les environnements VDI.	Standard ouvert largement utilisé pour les communications audio, vidéo et partage de données en temps réel via les navigateurs et applications.
Performances et qualité	Optimisé pour une qualité d’appel et de vidéo élevée, même en environnements VDI (réduction de la latence, des déconnexions, meilleure stabilité).	Performance variable selon les configurations réseau et navigateur. Moins optimisé pour les environnements complexes comme VDI.
Support des fonctionnalités	Permet à Microsoft de déployer plus rapidement des nouvelles fonctionnalités dans Teams, sans limitation des standards externes.	Les fonctionnalités sont limitées par le standard et peuvent évoluer plus lentement.
Mises à jour et compatibilité	Mises à jour automatiques et transparentes par Microsoft, sans intervention de l’utilisateur ou de l’administrateur.	Dépend des mises à jour des navigateurs et autres implémentations, ce qui peut entraîner des incompatibilités ou des retards.
Flexibilité et adoption	Spécifiquement intégré dans l’écosystème Microsoft, moins flexible en dehors de cet environnement.	Très flexible et largement adopté par de nombreuses plateformes, adapté à une grande variété d’applications.
Optimisation pour VDI	Conçu pour garantir une parité de performances entre le client natif Teams et Teams sur VDI.	Moins optimisé pour les environnements VDI, avec des écarts de performance par rapport aux clients natifs.
Déploiement des nouvelles fonctionnalités	Fonctionnalités déployées plus rapidement via SlimCore directement dans Teams.	Limité par les capacités de WebRTC, les fonctionnalités avancées peuvent prendre plus de temps à arriver.

Est-ce en rapport avec le nouveau Microsoft Teams ?

Cette évolution est en effet dans la suite de la refonte du client Teams de 2023, dont la GA date d’octobre de cette année-là. Voici quelques-unes des principales caractéristiques et avancées :

Performance améliorée : L’application est désormais deux fois plus rapide tout en consommant jusqu’à 50 % de ressources en moins.
Interface utilisateur simplifiée : Une interface plus soignée et réactive, facilitant la navigation et l’efficacité.
Notifications améliorées : Les notifications sont désormais entièrement gérées dans Teams, avec des paramètres plus personnalisables.
Comptes multiples : Vous pouvez facilement vous connecter à plusieurs comptes professionnels, scolaires et personnels sans avoir à vous déconnecter et vous reconnecter. Cela simplifie grandement la gestion des différents rôles et responsabilités.

Quels sont les quatre grands piliers de Teams VDI ?

C’est ici qu’intervient le remplacement de WebRTC, une technologie open-source utilisée pour le streaming audio et vidéo dans de nombreuses plateformes de collaboration, au profit de SlimCore, interne à Microsoft.

Microsoft en parle des avantages de ce changement juste ici :

Nouvelles fonctionnalités : SlimCore, un nouveau moteur multimédia, remplace WebRTC dans Teams. Cela permet à Teams sur ordinateur et sur VDI (bureau virtuel) d’avoir les mêmes fonctionnalités. Même si toutes les nouveautés ne sont pas disponibles immédiatement sur VDI, nous ne sommes plus limités par WebRTC, ce qui permet d’ajouter les nouvelles options plus rapidement.
Amélioration des performances : Les performances de Teams sur Windows sont maintenant disponibles pour VDI. Cela permet de rejoindre les réunions plus vite, de réduire les coupures d’appels et d’améliorer le succès lors des partages d’écran et des réunions, avec l’utilisation des codecs les plus récents.
Mises à jour automatiques : Microsoft met à jour SlimCore automatiquement sur l’ordinateur de l’utilisateur. Cela se fait sans interruption et sans redémarrage lorsque Teams sur VDI est mis à jour. Ce système permet d’éviter que des versions récentes de Teams interagissent avec des composants anciens, garantissant une meilleure qualité.
Support simplifié : Les administrateurs n’ont besoin de contacter que Microsoft pour tout problème avec Teams sur VDI, car nous gérons l’ensemble de la solution. Nous avons analysé les délais de résolution passés pour réduire la gravité et la fréquence des incidents, et nous investissons aussi dans des solutions de dépannage et d’auto-assistance avec des guides détaillés.

Quelles sont les fonctionnalités présentes dans cette optimisation ?

Microsoft propose une liste des nouvelles fonctionnalités liées à ce changement juste ici :

Fonctionnalité	Disponible
1080p	Oui
Accélération matérielle sur le point de terminaison	Oui
Vue Galerie 3×3 et 7×7	Oui
Qualité de service	Oui
Suppression du bruit	Oui
CACHÉ	Oui
Mode présentateur	Oui
Teams Premium	Oui (En attente : filigrane, mairies, décorer mon arrière-plan)
Effet d’arrière-plan chargé par l’utilisateur	Bientôt disponible
Zoom +/-	Bientôt disponible

Quelles sont les versions Apps ou OS supportant déjà SlimCore ?

Pour que la bascule vers SlimCore se fasse, nous avons besoin au minimum de :

Requis	Version minimale
Nouveau client Teams	24193.1805.3040.8975 (pour AVD/Windows 365) 24165.1410.2974.6689 (pour les VDA à session unique Citrix) 24243.1309.3132.617 (pour les VDA multisession Citrix)
AVD/Windows 365	Application Windows : 1.3.252 Client Bureau à distance : 1.2.5405.0
Citrix	VDA : application Citrix Workspace 2203 LTSR CU3 ou 2305 CR : 2203 LTSR, 2402 LTSR ou 2302 CR
Poste local	Windows 10 1809 (condition minimale de SlimCore) Les objets de stratégie de groupe ne doivent pas bloquer les installations MSIX (voir Étape 3 : Préproduction et inscription de SlimCore MSIX sur le point de terminaison)

L’architecture s’en retrouve principalement modifiée côté client via l’ajout d’un nouveau plugin appelé MsTeamsPlugin.dll :

Comment cela se traduit-il au niveau de son installation ?

Microsoft nous explique les choses assez simplement :

Une fois qu’un plugin est « arrivé » chez le client, Teams envoie des instructions sur la version spécifique du moteur média dont il a besoin et le plugin fait le reste : il contacte le CDN public de Microsoft, télécharge un paquet MSIX et l’installe/enregistre automatiquement sur l’appareil de l’utilisateur. Pas de redémarrage ni de privilèges d’administrateur !

Microsoft Tech Community

Par défaut, MsTeamsPlugin télécharge et installe automatiquement la version appropriée du moteur multimédia SlimCore sans intervention de l’utilisateur ou d’un administrateur.

Voici ce que l’on retrouve au niveau local :

Get-AppXPackage *SlimCore*

Important : Microsoft stocke jusqu’à 12 versions de SlimCore VDI à des fins de compatibilité, et dans le cas où l’utilisateur accède à différents environnements VDI (par exemple, persistant, où les nouvelles mises à jour automatiques Teams se mettent à jour automatiquement et non persistants, où les nouvelles mises à jour automatiques Teams sont désactivées).

Enfin, la nouvelle solution pour VDI stocke des données spécifiques à l’utilisateur (journaux, les configurations et les modèles IA ou ML, …) sur le poste local au démarrage de Teams sur la session VDI :

Et quid d’une mise à jour Teams côté client ou VDI ?

Grâce à ce changement d’approche, Microsoft a là aussi prévu le coup :

Chaque fois que vous mettez à niveau Teams sur le serveur, une nouvelle version du moteur de médias est déployée sur le client. Plus aucune mise à jour n’est nécessaire sur votre pile VDI (serveur ou client). Les plugins sont compatibles en amont et en aval avec les versions de SlimCore, et les plugins nettoieront également les versions de SlimCore inutilisées ou obsolètes.

Microsoft Tech Community

Doit-on prévoir des modifications au niveau des réseaux ?

Certains changement sont à prévoir selon votre cas. Microsoft met à disposition un second schéma afin de comprendre ces nouveaux changements :

Comme le signale Microsoft, assurez-vous que l’appareil de l’utilisateur dispose d’une connectivité réseau (UDP et TCP) aux ID de point de terminaison 11, 12, 47 et 127 décrits dans URL et plages d’adresses IP Microsoft 365.

ID	Catégorie	ER	Adresses	Ports	Remarques
11	Optimiser les besoins	Oui	13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/38	UDP : 3478, 3479, 3480, 3481	Processeurs multimédias et relais de transport 3478 (STUN), 3479 (audio), 3480 (vidéo), 3481 (partage d’écran)
12	Autoriser obligatoire	Oui	`.lync.com`, `.teams.microsoft.com`, `teams.microsoft.com` 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 52.238.119.141/32, 52.244.160.207/32, 2603:1027 ::/48, 2603:1037 ::/48, 2603:1047 ::/48, 2603:1057 ::/48, 2603:1063 ::/38, 2620:1ec :6 ::/48, 2620:1ec :40 ::/42	TCP : 443, 80
47	Valeur par défaut requise	Non	*.office.net	TCP : 443, 80	Utilisé pour les téléchargements SlimCore et les effets d’arrière-plan
127	Valeur par défaut requise	Non	*.skype.com	TCP : 443, 80

Comment vérifie-t-on si SlimCore est bien utilisé ?

Si toutes les exigences sont en place, SlimCore devrait être automatiquement utilisé dans Microsoft Team lors d’une session VDI. Un contrôle rapide est possible dans le client VDI.

Ouvrez votre client Teams sur votre session VDI, puis cliquez sur le bouton des paramètres :

Puis cliquez sur la fonctionnalité A Propos :

Conclusion

La mise en place de cette nouvelle optimisation Teams dédiée aux environnements VDI montre une priorisation chez Microsoft de ses produits VDI phares que son Azure Virtual Desktop et Windows 365.

La nouvelle optimisation basée sur SlimCore offre de meilleures performances, une configuration d’appel plus rapide, un partage d’écran plus fiable, moins de temps d’arrêt et des résolutions de cas plus rapides.

Offrant de meilleures performances et de nouvelles fonctionnalités telles que la vidéo en 1080p et les mises à jour automatiques, SlimCore a pour objectif est de réduire les problèmes techniques, d’améliorer la qualité des réunions et de simplifier la gestion pour les administrateurs IT.

Soyez Passwordless grâce à Microsoft Authenticator

Très souvent, la sécurité d’un périmètre ou d’un environnement focalise une attention particulière aux processus d’authentification ainsi qu’aux moyens mis à disposition aux utilisateurs pour y parvenir. Quelles méthodes, quelles conditions, quels protocoles mettre en place ? La MFA est un principe de base maintenant acquis pour tous et set présent dans une majorité de systèmes, mais le mot de passe reste alors encore de la partie.

Qu’est-ce que le Passwordless ?

Le concept de Passwordless (sans mot de passe) désigne une méthode d’authentification qui permet aux utilisateurs de se connecter à des systèmes ou des services sans avoir à utiliser un mot de passe traditionnel.

Autrement dit, le concept de Passwordless regroupe plusieurs méthodes d’authentification différentes, comme :

Passkey via Microsoft Authenticator
Push via Microsoft Authenticator
FIDO2
Windows Hello
SmartCard

Pourquoi vouloir se débarrasser du mot de passe ?

L’objectif principal du Passwordless est de réduire les risques de compromission liés aux mots de passe traditionnels, comme les attaques par hameçonnage (phishing), les vols de mot de passe, ou encore les mauvaises pratiques liées à la gestion des mots de passe (mots de passe faibles ou réutilisés).

Passwordless vs MFA ?

Passwordless et MFA (Multi-Factor Authentication) sont 2 méthodes d’authentification sécurisée, mais elles diffèrent dans leur approche et leur mise en œuvre.

Des fonctionnalités telles que l’authentification multifacteur (MFA) sont un excellent moyen de sécuriser votre organisation, mais les utilisateurs sont souvent frustrés par la couche de sécurité supplémentaire en plus de devoir mémoriser leurs mots de passe.

Les méthodes d’authentification sans mot de passe sont plus pratiques, car le mot de passe est supprimé et remplacé par quelque chose que vous avez ou quelque chose que vous êtes ou connaissez.

Microsoft Learn

Voici une comparaison entre ces 2 concepts :

Caractéristique	Passwordless	MFA (Multi-Factor Authentication)
Utilisation des mots de passe	Aucune utilisation de mot de passe	Utilise souvent un mot de passe + autre facteur
Sécurité	Très sécurisé (aucun mot de passe à compromettre)	Très sécurisé (nécessite plusieurs facteurs)
Expérience utilisateur	Fluide et simplifiée	Peut être plus complexe (plusieurs étapes)
Technologie utilisée	Biométrie, clés de sécurité, lien magique, etc.	Combinaison de mot de passe + SMS, email, biométrie
Exemples d’utilisation	Connexion par empreinte digitale, lien magique	Connexion par mot de passe + code SMS ou app Authenticator

Dans cet article, je vous propose de mettre en place et de tester l’authentification Passwordless via l’application Microsoft Authenticator sur smartphone pour une identité 365 :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la méthode Passwordless de Microsoft, il vous faudra disposer de :

Un tenant Microsoft
Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator

Important : à l’issue de cette démonstration, gardez en tête que votre smartphone sera enregistré (mais non managé) dans chaque tenant Microsoft où il sera utilisé pour se connecter en Passwordless.

Commençons par activer le service Passwordless sur le tenant 365.

Etape I – Configuration du tenant :

Pour cela, rendez-vous dans la section suivante de votre portail Entra, puis cliquez sur Microsoft Authenticator :

Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator :

Définissez le périmètre des utilisateurs concernés en laissant le mode d’authentification à Any ou Passwordless :

Basculez sur le second onglet afin d’activer ou non Microsoft Authenticator OTP :

L’option suivante exigeant de retaper le numéro affiché n’est pas modifiable :

Choisissez au besoin ou non d’afficher l’application demandant l’authentification Passwordless :

Choisissez au besoin ou non d’afficher la localisation du demandeur de l’authentification Passwordless :

Choisissez au besoin ou non d’afficher Microsoft Authenticator sur les applications de type Compagnon :

Enfin, cliquez sur Sauvegarder :

Afin de comprendre le fonctionnement du processus depuis l’enrôlement de départ de Microsoft Authenticator, il est préférable de créer un utilisateur de test.

Etape II – Configuration du l’utilisateur :

Toujours sur votre portail Entra, cliquez ici pour créer un nouvel utilisateur sur votre tenant Microsoft :

Renseignez-lui un UPN, un nom d’affichage, ainsi qu’un mot de passe temporaire, puis lancez la validation Entra :

Une fois la validation Entra réussie, lancez la création de votre utilisateur des test :

Une fois l’utilisateur créé, ouvrez le navigateur internet de votre choix en mode privé :

Rendez-vous sur la page office.com, puis cliquez ici pour vous authentifier :

Saisissez le nom de compte de votre utilisateur de test ainsi que son mot de passe provisoire :

Définissez un nouveau mot de passe :

Cliquez sur Oui :

Notre environnement 365 et notre utilisateur sont maintenant créé.

Passons maintenant à l’étape suivante qui consiste à associer Microsoft Authenticator à notre compte de test.

Etape III – Configuration MFA :

En haut à droite, cliquez ici pour afficher les propriétés de votre compte 365 :

Dans l’onglet dédié aux informations de sécurité, ajoutez une nouvelle méthode d’authentification :

Choisissez la méthode suivante pour configurer Microsoft Authenticator :

Installez au besoin l’application Microsoft Authenticator depuis un store d’applications, puis cliquez sur Suivant :

Cliquez sur Suivant :

Choisissez le type Compte professionnel ou scolaire :

Cliquez ici pour utiliser l’appareil photo afin de scanner le QR code :

Scanner le QR code présenté par Microsoft :

Une fois scanné, cliquez sur Suivant :

Une notification est alors envoyée à votre smartphone :

Saisissez le nombre précédemment affiché, puis cliquez sur Oui :

Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :

La méthode Microsoft Authenticator est maintenant correctement configurée sur votre compte de test, cliquez alors sur Suivant :

La méthode Microsoft Authenticator apparaît alors sur votre compte en tant que méthode dite MFA :

L’utilisateur de test est maintenant correctement configuré avec un mot de passe traditionnel et une méthode de sécurité de type MFA.

Etape IV – Configuration Passwordless :

Afin d’activer la méthode Passwordless, nous allons transformer le compte de test enregistré sur l’application Microsoft Authenticator.

Pour cela, ouvrez l’application Microsoft Authenticator, sélectionnez votre compte de test, puis cliquez ici pour activer la fonctionnalité Passwordless :

Microsoft vous informe que l’appareil sera inscrit dans le tenant ID correspondant, cliquez sur Continuer

Sur l’application Microsoft Authenticator, renseignez le mot de passe de votre compte de test :

Un nombre apparaît alors sur la fenêtre, ainsi qu’une notification Microsoft Authenticator, vous demandant de ressaisir ce dernier :

Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :

Cliquez ici pour confirmer l’enregistrement de votre smartphone sur le tenant ID concerné :

Microsoft Authenticator vous confirme le succès des opérations et de l’activation de la fonctionnalité Passwordless, cliquez alors sur Terminer :

Retournez sur le portail Entra afin de constater l’apparition de votre smartphone en tant que périphérique enregistré :

De retour sur les éléments de sécurité de votre utilisateur de test, la méthode Microsoft Authenticator s’est transformée de MFA à Passwordless :

Tout notre environnement de test est maintenant configuré. Il ne nous reste qu’à tester que la méthode Passwordless fonctionne correctement à la place du mot de passe.

Etape V – Test du Passwordless :

Rouvrez à nouveau un navigateur internet en mode privée :

Rendez-vous à nouveau sur la page office.com, puis cliquez ici pour vous authentifier :

Saisissez le nom de compte de votre utilisateur de test, puis, au lieu de renseigner son mot de passe, cliquez sur le choix suivant :

Microsoft envoie alors une notification sur le smartphone configuré comme Passwordless :

Ouvrez la notification Microsoft Authenticator, puis ressaisissez le nombre précédemment indiqué par Microsoft :

De retour sur votre navigateur, confirmez votre souhait de rester authentifié en cliquant sur Oui :

La page d’accueil d’Office 365 s’ouvre bien, l’utilisateur s’est correctement authentifié sans mot de passe :

Côté traçabilité, il est possible de retrouver des logs des authentifications Passwordless dans plusieurs écrans de Microsoft :

Côté utilisateur, via sa gestion de compte :

Côté Administrateur, via la vue des logs d’un utilisateur sur Entra ID :

Ou via une requête KQL après l’activation Log Analytics sur Entra ID :

SigninLogs
| where AuthenticationDetails has "passwordless"
| project TimeGenerated, UserPrincipalName, AuthenticationDetails , ResultDescription
| order by TimeGenerated desc

Conclusion

En conclusion, l’adoption du Passwordless avec Microsoft Authenticator constitue une avancée significative dans la sécurisation des environnements numériques tout en améliorant l’expérience utilisateur.

En éliminant la nécessité de mémoriser et de gérer des mots de passe, cette méthode réduit les risques liés aux compromissions, telles que les attaques de phishing ou le vol de mots de passe.

De plus, elle simplifie les processus d’authentification, rendant l’accès aux services plus fluide. Pour les entreprises, c’est une opportunité d’offrir un meilleur équilibre entre sécurité et facilité d’utilisation, tout en renforçant la confiance des utilisateurs dans la protection de leurs données.

Bref, aucune méthode n’est jamais parfaite 😎 :

Azure WAN

Les stratégies de connexion entre des réseaux Cloud et/ou sur site sont déjà possibles grâce aux appairages, aux passerelles VPN et encore bien d’autres. Mais force est de constater qu’Azure WAN simplifie la mise en œuvre d’une architecture multi-réseaux. Et bien figurez-vous que j’ai justement pu enfin trouver le temps pour le tester cet Azure WAN ! 😎

Avant vous parler du test que j’ai réalisé sur ce service, commençons d’abord par quelques notions sur Azure WAN.

Qu’est-ce qu’Azure WAN ?

Azure WAN facilite la connexion des sites distants, des succursales ou des utilisateurs via un réseau centralisé. Cela permet d’intégrer plusieurs réseaux locaux (LAN) sur un WAN global, améliorant ainsi la connectivité et la gestion.

Azure WAN est un concentré de services réseaux déjà disponibles sur le Cloud Microsoft. Il propose de mettre en place et de gérer de façon simple et rapide différents types de liaison dans le Cloud et/ou sur site.

Mais seulement cette simplicité n’est pas un synonyme d’économie : Azure WAN propose dès les premiers liens des puissances assez grandes. Et qui dit performances, dit coûts.

Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.

Microsoft Learn

Voici quelques-unes des fonctionnalités principales :

Connectivité de branche (via l’automatisation de la connectivité à partir d’appareils partenaires Virtual WAN, comme SD-WAN ou CPE VPN).

Connectivité VPN de site à site.

Connectivité VPN d’un utilisateur distant (point à site).

Connectivité privée (ExpressRoute).

Connectivité multicloud (connectivité transitive pour les réseaux virtuels).

Interconnectivité ExpressRoute des VPN.

Routage, Pare-feu Azure et chiffrement pour la connectivité privée.

Microsoft Learn

Grâce à son interface unique et centralisée, les administrateurs réseau peuvent configurer et surveiller facilement l’ensemble du réseau WAN, incluant les connexions des utilisateurs, les VPN, et les passerelles virtuelles. Cela simplifie donc l’administration des réseaux complexes.

Dans quel cas considérer Azure WAN ?

Le service est idéal pour les environnements hybrides ou multicloud, en offrant une connectivité fluide entre les réseaux sur site et divers fournisseurs de cloud.

Azure WAN est avant tout une boîte à outils où les liaisons entre ressources Azure et/ou sur sites sont vraiment très simples à mettre en œuvre.

Quels SKUs sont disponibles pour Azure WAN ?

Azure WAN permet de réduire les coûts en diminuant la nécessité d’équipements réseau sur site. L’approche as-a-service signifie que les entreprises paient uniquement pour ce qu’elles utilisent, réduisant ainsi les coûts d’infrastructure.

A ce jour, 2 SKUs sont déjà disponibles pour Azure WAN. Microsoft nous expose via le tableau ci-dessous les différences :

Type de Virtual WAN	Type de Hub	Configurations disponibles
De base	De base	VPN de site à site uniquement
standard	standard	ExpressRoute VPN utilisateur (point à site) VPN (site à site) Transit de hub à hub et de réseau virtuel à réseau virtuel via le hub virtuel Pare-feu Azure NVA est un WAN virtuel

Autrement dit, l’Azure WAN de base, bien que gratuit (base + traffic), apportera seulement les connexions VPN site à site et aux réseaux virtuels Azure, mais certaines liaisons sont manquantes comme :

Connexion entre les hubs
Connectivité ExpressRoute
Connectivité VPN utilisateur/point à site
Connectivité de réseau virtuel à réseau virtuel Azure
Azure Firewall

Enfin, Il est malgré tout possible de migrer depuis le SKU Basic vers Standard, mais pas l’inverse :

Quels sont les autres coûts liés au services Azure WAN ?

La tarification du service Azure WAN est très fragmenté. La facturation dépendra des différents trafics réseaux, et donc se divisera potentiellement en une myriade de petits frais.

Dans l’image ci-dessous, pas loin de 13 différents types de transfert sont facturés par Microsoft :

Pour y voir plus clair sur le trafic réseaux d’Azure WAN, Microsoft propose différents scénarios concrets disponibles juste là.

Tarification de la liaison :

Microsoft communique également via leur site web le détail tarifaire complet des liaisons réseaux possibles :

Tarification de la données en transit :

Microsoft nous rappelle ici les différents prix au Go de données transférées entre des réseaux sur Azure et/ou sur site :

Afin de comprendre comment déployer Azure WAN, j’ai décidé de recréer une petite infrastructure réseau, répartie sur plusieurs régions Azure :

Par manque de temps et de connaissances, je n’ai pas testé Firewall et la fonctionnalité BGP sur mon test d’Azure WAN.

Mon test d’Azure WAN :

Mon environnement WAN de test est constitué des éléments Azure suivants :

1 Azure WAN avec 2 Azure Hub :

4 réseaux virtuels Azure contenant chacun une machine virtuelle :

2 VPN Gateway Site à Site :

2 VPN Gateway Point à Site avec une configuration P2S VPN globale WAN :

J’ai recréé sur Azure différentes ressources pour simuler deux environnements sur site :

2 réseaux en connexion site à site avec 2 passerelles VPN :

2 réseaux en connexion point à site avec des PCs équipés du client Azure VPN :

Afin d’effectuer mes tests de connectivités entre tous ces réseaux, j’ai également déployé les machines virtuelles suivantes :

Afin d’avoir une vue d’ensemble de l’infrastructure WAN, Microsoft propose une cartographie fidèle avec toutes les liaisons internes et externes :

Toute la configuration WAN côté infrastructure Azure peut s’effectuer directement depuis la page du portail Azure dédiée à mon Azure WAN.

Configuration WAN :

Pour arriver à ce résultat, une fois le WAN déployé, j’ai créé ici les 2 hubs suivants :

J’ai activé les liaisons suivantes via la configuration de mon WAN :

Configuration des 2 hubs :

Pour chacun des 2 hubs, j’ai activé les passerelles VPN Site à Site et Point à Site (30 minutes d’attente par liaison) :

Connexions aux 4 réseaux virtuels Azure :

Depuis la page d’Azure WAN, j’ai connecté les 4 réseaux virtuels internes à mon infrastructure Azure à mes 2 hubs :

J’ai utilisé la route par Default pour chacune des liaisons :

Connexions aux réseaux locaux Site à site :

Depuis la page Azure WAN, j’ai créé 2 sites physiques respectivement connectés à mes 2 hubs :

Pour chacun des 2 sites, j’ai indiqué leur plan d’adressage respectif :

Une fois les 2 liaisons VPN Site à Site déployées et connectées, ces dernières sont alors bien respectivement visibles sur les 2 hubs :

Une fois toutes les connexions internes et externes en place, les différentes routes sont bien visibles sur chacun de mes 2 hubs :

Connexions Points à site :

Toujours sur la page Azure WAN, j’ai mis en place une configuration unique concernant le type de tunnel et la méthode d’authentification Entra ID :

Afin d’assurer une authentification via Entra ID, j’ai mis en place un tunnel Point à Site de type OpenVPN :

Comme mon précédent article parlant déjà du VPN Point à Site, j’ai configuré les informations suivantes en relation avec mon tenant Microsoft :

J’ai installé Azure VPN sur mes 2 PCs situés en mobilité :

La configuration VPN établie par mon WAN repose sur un FQDN unique. Cela permet d’établir la connexion Point à Site vers le hub le plus proche de façon transparente et automatique :

Poste 1 :

Poste 2 :

Une fois la connexion VPN cliente établie, les informations sont visibles sur le hub :

Mon environnement WAN est maintenant en place, il ne me reste plus qu’à tester les accès et la transitivité de l’infrastructure toute entière.

Tests des accès :

Pour cela, j’ai installé le service Azure Bastion sur le réseau virtuel contenant un PC en mobilité :

J’ai démarré la connexion Point à Site via Azure VPN en utilisant le SSO de l’OS :

J’ai pu ouvrir avec succès des connexions RDP vers toutes les machines virtuelles de mon WAN :

Second PC en mobilité ayant une connexion Point à Site ouverte sur l’autre hub
Serveur ayant une connexion Site à Site ouverte sur le même hub
Serveur ayant une connexion Site à Site ouverte sur l’autre hub
Serveurs ayant un appairage de réseau virtuel sur le même hub
Serveurs ayant un appairage de réseau virtuel sur l’autre hub

Le routage vers toutes les machines s’est donc effectuée sans aucun autre composant additionnel qu’Azure WAN lui-même 💪

Surveillance des liaisons :

Une fois le WAN en place, la surveillance des liaisons est indispensable afin d’y remédier au plus vite car ces dernières sont souvent critiques pour un ou plusieurs services de l’entreprise.

Pour cela des métriques sont disponibles via le menu Insights de mon Azure WAN :

De plus, Azure WAN peut s’appuyer sur le service Connection Monitor disponible sous Network Watcher afin d’établir des tests de connectivité et des règles d’alerte.

J’ai configuré Connection Monitor afin d’effectuer des tests ICMP vers Azure, mais aussi vers mes 2 sites physiques :

A peine les tests créés, Connection Monitor affiche les résultats :

Différentes informations sont disponibles sur ces tests :

Afin de simuler une panne, j’ai simplement éteint une machine virtuelle Azure sur site :

A peinte la machine virtuelle éteinte, Connection Monitor indique déjà des échecs dans les tests concernés :

Le détail du test en défaut nous affiche également le routage et même le lieu exact du blocage de la liaison :

Azure Monitor affiche également les 2 alerte déclenchée :

Grâce au groupe d’action configuré sur la règle de l’alerte créée par Connection Monitor, une notification par e-mail me parvient immédiatement :

Afin de retrouver une situation opérationnelle, je rallume la machine virtuelle sur site précédemment éteinte :

Quelques minutes plus tard, les alertes générées sont automatiquement résolues :

De retour sur Connection Monitor, tous les tests repassent alors en vert :

Conclusion

En résumé, Azure WAN offre une solution robuste, sécurisée et évolutive pour connecter et gérer les réseaux distribués à travers le monde. Il simplifie la gestion des infrastructures réseau tout en garantissant des performances et une sécurité optimales, ce qui en fait une option précieuse pour les entreprises cherchant à moderniser leurs infrastructures réseau.

Migrez un ancien OS Windows sur le Cloud Azure

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

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

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

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

Microsoft Learn

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

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

Qu’est-ce que Disk2vhd ?

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

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

Microsoft Learn

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

Microsoft Learn

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

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

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

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

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

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

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

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

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

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

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

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

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

Cliquez ensuite sur Suivant :

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

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

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

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

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

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

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

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

Rôle DHCP
Rôle Hyper-V

Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

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

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

Shutdown -R

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

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

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

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

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

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

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

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

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

Cliquez sur Suivant :

Cliquez sur Terminer :

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

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

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

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

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

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

Cliquez sur Suivant :

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

Choisissez Génération 1 :

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 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 invitée créée, modifiez sa configuration comme ceci :

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

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

Double-cliquez sur votre machine virtuelle invitée :

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

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

Lancez l’installation de Windows :

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

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

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

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

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

Attendez maintenant que l’installation de Windows commence :

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

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

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

Avant cela, quelques modifications sont nécessaires.

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

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

Windows Server 2012, 2016, Windows 10 -> Disk2vhd v2.02
Windows Server 2008 R2, Windows 7 -> Disk2vhd v1.6

Partagez ce dossier sur le réseau :

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

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

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

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

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

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

Eteignez également votre machine virtuelle invitée :

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

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

Etape IV – Préparation du fichier VHD :

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

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

Cliquez sur Suivant :

Modifier les informations suivantes, puis cliquez sur Suivant :

Choisissez Génération 1 :

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

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

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

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

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

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

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

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

Confirmez le risque sécuritaire en cliquant sur Oui :

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

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

sfc.exe /scannow

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

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

netsh.exe winhttp reset proxy

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

diskpart.exe
san policy=onlineall
exit

Configurez l’heure UTC pour Windows :

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

Modifiez le profil d’alimentation en performances hautes :

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

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

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

Réinitialisez par défaut certains services Windows :

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

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

Activez le service bureau à distance RDP :

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

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

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

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

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

Pour Windows Server 2012, 2016 et pour Windows 10 :

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

Pour Windows Server 2008 R2 et pour Windows 7 :

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

Définissez la valeur keep-alive :

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

Définissez les options de reconnexion :

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

Limitez le nombre de connexions simultanées :

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

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

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

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

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

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

Activez l’option suivante :

Convertissez la connexion actuelle en réseau privé :

Activer le service à distance PowerShell :

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

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

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

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

chkdsk.exe /f

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

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

Attendez la fin de traitement :

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

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

cmd

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

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

exit

Réouvrez Windows PowerShell ISE en mode administrateur :

Activez la collecte des journaux d’erreur :

# Set up the guest OS to collect a kernel dump on an OS crash event
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Type DWord -Force -Value 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name DumpFile -Type ExpandString -Force -Value "%SystemRoot%\MEMORY.DMP"
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name NMICrashDump -Type DWord -Force -Value 1

# Set up the guest OS to collect user mode dumps on a service crash event
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
if ((Test-Path -Path $key) -eq $false) {(New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting' -Name LocalDumps)}
New-ItemProperty -Path $key -Name DumpFolder -Type ExpandString -Force -Value 'C:\CrashDumps'
New-ItemProperty -Path $key -Name CrashCount -Type DWord -Force -Value 10
New-ItemProperty -Path $key -Name DumpType -Type DWord -Force -Value 2
Set-Service -Name WerSvc -StartupType Manual

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

winmgmt.exe /verifyrepository

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

netstat.exe -anob | findstr 3389

Vérifiez les mises à jour Windows :

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

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

Eteignez votre machine virtuelle invitée :

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

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

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

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

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

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

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

Suivi du calcul de Hash :

Pour finir par le transfert vers Azure :

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

Cliquez ici pour créer la machine virtuelle :

Renseignez les informations de base :

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

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

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

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

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

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

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

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

Constatez la bonne ouverture de session Windows :

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

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

Cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

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

Cliquez sur Terminer :

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

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

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

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

Confirmez votre action en cliquant sur Oui :

Effectuez un test de démarrage de votre machine virtuelle :

Vérifiez le succès des 2 opérations via les notifications Azure :

Cliquez-ici pour rouvrir la session Windows ouverte précédemment via Azure Bastion :

Effectuez les mêmes opérations pour les autres anciens OS à tester :

Conclusion

Par cette démonstration, un portage rapide et en urgence de certaines anciennes versions Windows, client ou serveur, est parfaitement possible. Quelques manipulations de préparation sont nécessaires, mais ces dernières sont fonctionnelles pour les OS suivants :

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

Entra Verified ID + Face Check

La vérification faciale est une solution qui existe chez plusieurs éditeurs et qui compare des visages tout en respectant la vie privée. Elle aide les entreprises à vérifier l’identité des personnes de manière sécurisée et efficace. Par exemple, une banque peut l’utiliser pour s’assurer que la personne ouvrant un compte est bien celle qu’elle prétend déclarer. Mais peut-on combiner cette fonctionnalisé avec Entra Verified ID ?

La réponse est oui :

La correspondance faciale est alimentée par Azure AI services. En partageant uniquement les résultats de correspondance et non les données d’identité sensibles, Vérification faciale protège la confidentialité des utilisateurs tout en permettant aux organisations de s’assurer que la personne est bien qui elle prétend être.

Microsoft Learn

Combinée à Entra Verified ID, Face check permettra alors une expérience plus rapide dans le partage d’une identité :

La documentation Microsoft explique d’ailleurs très bien le concept et l’intégration dans une application, mais également une FAQ disponible juste ici.

Vérification faciale vs Face ID ?

Face ID est une offre d’option de sécurité biométrique basée sur la vision pour les produits Apple pour déverrouiller un appareil en vue d’accéder à une application mobile. Vérification faciale est une fonctionnalité de Vérification d’identité Microsoft Entra qui utilise également la technologie IA basée sur la vision, mais compare l’utilisateur au justificatif Vérification d’identité présenté… Les deux mécanismes requièrent que l’utilisateur soit face à une caméra dans le processus, mais fonctionne de différentes manières.

Microsoft Learn

Mais qu’advient-il des données liées aux images ?

Les données ne sont ni stockées ni conservées par aucun des services Microsoft Authenticator, Vérification d’identité ou Azure AI. En outre, les images ne sont pas non plus partagées avec l’application de vérificateur. L’application de vérificateur obtient uniquement le score de confiance en retour.

Dans un système basé sur l’IA, le score de confiance est la réponse de pourcentage de probabilité pour une requête au système. Pour ce scénario, le score de confiance est la probabilité que la photo du justificatif de l’utilisateur Vérification d’identité corresponde à la capture de l’utilisateur sur l’appareil mobile.

Microsoft Learn

Comme toujours, je vous propose de suivre ensemble ce pas à pas dans le but de tester ce tutoriel Microsoft :

Etape 0 – Rappel des prérequis :

Afin de tester la fonctionnalité Face Check disponible sur les identités vérifiées via Entra ID nous allons avoir besoin de :

Un tenant Microsoft active
Une souscription Azure active

Commençons par configurer notre tenant afin de pouvoir générer des identités vérifiées personnalisées.

Etape I – Configuration du tenant :

Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route des identités vérifiées.

Deux options de mise en place s’offrent alors à vous :

Pour cette démonstration de Face Check, choisissez la configuration rapide :

Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :

La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :

Une fois la configuration automatique terminée, la notification suivante apparaît :

Afin de configurer Face Check, nous avons besoin de créer un groupe de ressources Azure. Rendez-vous sur le portail Azure, puis cliquez ici :

Cliquez ici pour créer un nouveau groupe de ressources Azure :

Renseignez les informations de base pour ce groupe de ressources, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du groupe de ressources :

Retournez sur le portail d’Entra ID afin d’activer l’addon Face Check :

Prenez le temps de lire les conditions tarifaires de Face Check, dont le prix sera appliqué à partir du 12 août 2024 :

Renseignez vos informations Azure concernant le groupe de ressources créé précédemment, puis cliquez sur Valider :

Une fois la validation Azure réussie, cliquez sur Activer :

La notification Entra suivante apparaît alors :

La configuration du service Verified ID destiné à Face Check est maintenant terminée. Nous allons avoir maintenant besoin de créer un utilisateur de test.

Etape II – Création d’un utilisateur de test :

Toujours sur le portail Entra, créez un nouvel utilisateur Entra ID :

Renseignez les informations de base de cet utilisateur, puis cliquez sur Suivant :

Renseignez également une adresse de messagerie :

Renseignez également un pays de localisation, puis lancez la validation Entra :

Lancez la création de votre utilisateur de test :

La notification Entra suivante apparaît alors :

Une fois l’utilisateur de test créé, ajoutez une photo de vous sur le profil de ce dernier :

Ouvrez le navigateur de votre choix en mode privé :

Ouvrez la page Mon compte de Microsoft, puis authentifiez-vous avec votre utilisateur de test :

A votre première connexion, personnalisez son mot de passe :

Cliquez ici afin d’obtenir une identité vérifiée :

Microsoft génère alors un QR code pour générer et stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :

Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :

Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :

Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière, dont votre photo :

Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :

Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :

La prochaine étape sera de créer une application de test pour vérifier le bon fonctionnement de Face Check pour notre nouvel utilisateur.

Si vous ne souhaitez pas déployer d’application sur Azure, vous pouvez également utiliser celle mise à disposition par Microsoft.

Etape III – Création d’une application de test :

Sur la portail Entra, copiez votre DID afin de la configurer plus tard dans l’application :

Rendez-vous sur la page GitHub suivante, puis déployez l’application sur votre tenant par ce lien :

Renseignez les 2 champs suivants, puis lancez la validation Azure :

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

Attendez environ 5 minutes la fin du déploiement Azure, qui devrait peut-être présenter l’erreur non bloquante suivante, puis cliquez ici pour continuer :

Vérifiez que l’application déployée dispose bien de sa propre identité :

Copiez le script ci-dessous dans un éditeur de texte en prenant soin de renseigner les deux informations suivantes propres à votre déploiement :

Votre tenant ID
Le nom de votre application de test déployé

$TenantID="<YOUR TENANTID>"
$YourAppName="<NAME OF YOUR AZURE WEBAPP>"

#Do not change this values below
#
$ApiAppId = "3db474b9-6a0c-4840-96ac-1fceb342124f"
$PermissionName = "VerifiableCredential.Create.PresentRequest"
 
# Install the module
Install-Module AzureAD

Connect-AzureAD -TenantId $TenantID

$MSI = (Get-AzureADServicePrincipal -Filter "displayName eq '$YourAppName'")

Start-Sleep -Seconds 10

$ApiServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$ApiAppId'"
$AppRole = $ApiServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}
New-AzureAdServiceAppRoleAssignment -ObjectId $MSI.ObjectId -PrincipalId $MSI.ObjectId ` -ResourceId $ApiServicePrincipal.ObjectId -Id $AppRole.Id

Toujours sur le portail Azure, ouvrez par ce bouton Azure Cloud Shell :

Exécutez le script précédemment modifié, puis attendez le résultat suivant :

Retournez sur le portail Entra, puis recherchez votre application de test :

Vérifiez la présence de la permission suivante nécessaire à la gestion des identités vérifiées :

Tout est maintenant en place, il nous reste qu’à tester notre application.

Etape IV – Test application via Face Check :

Retournez sur le portail Azure afin de copier l’URL web de votre application de test :

Ouvrez un nouvel onglet vers cette URL de test, puis cliquez ici :

Votre application génère alors un QR code à scanner :

Depuis votre smartphone, ouvrez Microsoft Authenticator afin de scanner le QR code :

Confirmez votre action de partage de votre identité vérifiée avec votre application de test en cliquant sur Suivant :

Cliquez sur Suivant pour démarrer la vérification avec votre visage :

Suivez les indications de l’application afin de valider l’opération Face Check :

Le message suivant vous confirme le succès de la vérification Face Check :

Cliquez à nouveau sur Partager pour confirmer l’action :

Votre application web vous confirme bien le succès du partage et le score retourné par la fonction Face Check :

Une nouvelle activité Woordgrove Helpdesk s’ajoute sur votre identité vérifiée :

Quelques informations supplémentaires sur ce partage sont disponibles :

Conclusion

L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :

Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.

Autopilot v2 💪💻🚨

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

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

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

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

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

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

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

Pourquoi changer ce qui marche déjà ?

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

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

Synapsys-groupe

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

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

Synapsys-groupe

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

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

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

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

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

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

Etape 0 – Rappel des prérequis :

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

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

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

Commençons par la configuration sur Entra ID.

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

Microsoft Learn

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

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

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

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

Etape II – Autoriser les utilisateurs à joindre des appareils :

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

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

Microsoft Learn

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

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

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

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

Microsoft Learn

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

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

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

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

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

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

Microsoft Learn

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

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

Continuons avec la configuration de postes sous Intune.

Etape V – Affectation de la configuration Intune :

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

10 applications managées

10 scripts PowerShell

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

Microsoft Learn

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

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

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

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

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

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

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

Microsoft Learn

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

Cliquez sur Créer :

Cliquez sur Suivant :

Nommez votre profil, puis cliquez sur Suivant :

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

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

Personnalisez l’expérience OOBE :

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

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

Modifiez les tags au besoin, puis cliquez sur Suivant :

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

Cliquez sur Sauvegarder :

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

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

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

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

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

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

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

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

Cliquez ensuite sur Suivant :

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

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

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

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

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

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

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

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

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

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

Rôle DHCP
Rôle Hyper-V

Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

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

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

Shutdown -R

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

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

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

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

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

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

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

Ouvrez le menu suivant :

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

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

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

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

Cliquez sur Suivant :

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

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

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

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

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

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

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

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

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

Cliquez sur Suivant :

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

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

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

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

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

Cliquez sur Suivant :

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

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

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

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

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

Double-cliquez sur votre machine virtuelle Windows 11 :

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

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

Attendez que le chargement se termine :

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

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

Lancez l’installation de Windows 11 :

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

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

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

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

Attendez maintenant que l’installation de Windows 11 commence :

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

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

Etape IX – Test Autopilot v2 :

Attendez quelques minutes que le redémarrage se termine :

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

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

Ajoutez si besoin un second clavier :

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

Le traitement peut être plus ou moins long :

Un redémarrage est même possible :

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

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

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

Une fois le traitement terminé, cliquez sur Accepter :

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

Attendez la fin de configuration Windows :

Vous voilà enfin sur le bureau Windows 11 !

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

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

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

Prenons en exemple l’installation manuelle de Mozilla Firefox :

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

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

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

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

Conclusion

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

Entra Verified ID

Dans un monde où nos vies numériques et physiques sont inextricablement liées, la sécurité des identités est primordiale. Les violations de données et l’usurpation d’identité sont des menaces croissantes.

Pour contrer cela, Microsoft s’intègre dans l’idée d’une solution innovante d’identité décentralisée qui donne aux utilisateurs le contrôle de leurs informations, éliminant la dépendance aux autorités centralisées et aux intermédiaires. Voici d’ailleurs ici quelques notions présentées par Microsoft.

Et voilà les différents points abordés dans cet article :

Pourquoi imaginer des identités décentralisées ?

Notre identité numérique est utilisée partout, souvent sans notre consentement éclairé. Actuellement, nos données sont contrôlées par des tiers, ce qui présente des risques de sécurité. Une identité décentralisée permet aux utilisateurs de contrôler et sécuriser leurs informations personnelles :

Microsoft travaille-t-il seul dans son coin ?

La réponse est bien évidemment non 🙏

Microsoft collabore activement avec les membres de la DIF (Decentralized Identity Foundation), du W3C Credentials Community Group et de la communauté plus étendue en lien avec l’identité. Nous avons travaillé avec ces groupes pour identifier et développer des normes critiques, et les normes suivantes ont été implémentées dans nos services.

Identificateurs décentralisés W3C

Justificatifs vérifiables W3C

DIF Sidetree

DIF Well Known DID Configuration

DIF DID-SIOP

DIF Presentation Exchange

Microsoft Learn

Qu’est-ce que sont les identificateurs décentralisés (DID) ?

Les DID sont des identifiants uniques créés et contrôlés par les utilisateurs, résistants à la censure et immuables. Ils permettent de prouver des informations sans dépendre de systèmes centralisés :

Qu’est-ce qu’un justificatif vérifiable ?

Les justificatifs vérifiables sont des attestations numériques signées par des entités de confiance. Ils fonctionnent comme des preuves de diplômes, permis ou autres certifications, mais sous une forme numérique sécurisée.

L’application France Identité en est d’ailleurs un bonne exemple puis qu’elle permet le stockage des nouvelles cartes d’identité française ou le permis de conduire :

Comment fonctionne l’identité décentralisée ?

Nous avons besoin d’une nouvelle forme d’identité. Nous avons besoin d’une identité capable de réunir des technologies et des normes pour fournir des attributs d’identité clés tels que l’indépendance et la résistance à la censure. Ces fonctionnalités sont difficiles à obtenir à l’aide des systèmes existants.

Pour y parvenir, il nous faut nous appuyer sur une base technique composée de sept innovations clés. Les identificateurs détenus par l’utilisateur constituent l’une de ces innovations clés, un agent utilisateur pour gérer les clés associées à ces identificateurs et les magasins de données chiffrés et contrôlés par l’utilisateur.

1. Identificateurs décentralisés (DID) W3C. ID créés, détenus et contrôlés par les utilisateurs indépendamment de toute organisation ou de tout gouvernement. Les DID sont des identificateurs globaux uniques liés à des métadonnées DPKI (Decentralized Public Key Infrastructure) composés de documents JSON contenant des éléments de clé publique, des descripteurs d’authentification et des points de terminaison de service.

2. Système d’approbation. Pour pouvoir résoudre les documents DID, les DID sont généralement enregistrés sur un réseau sous-jacent d’un type qui représente un système d’approbation. Microsoft prend actuellement en charge le système d’approbation DID :Web. DID:Web est un modèle basé sur des autorisations qui autorise l’approbation à l’aide de la réputation existante d’un domaine web. DID:Web est dans l’état de pris en charge Disponibilité générale.

3. Agent utilisateur/Portefeuille DID : application Microsoft Authenticator. Permet aux personnes réelles d’utiliser des identités décentralisées et des justificatifs vérifiables. Authenticator crée des DID, facilite les demandes d’émission et de présentation de justificatifs vérifiables, et gère la sauvegarde de la valeur initiale de la requête dans un fichier portefeuille chiffré.

4. Outil de résolution Microsoft. API qui recherche et résout les DID à l’aide de la méthode did:web et retourne le DDO (DID Document Object). Le DDO comprend les métadonnées DPKI associées au DID telles que les clés publiques et les points de terminaison de service.

5. Service Vérification d’identité Microsoft Entra. Service d’émission et de vérification dans Azure et API REST pour Justificatifs vérifiables W3C signés avec la méthode did:web. Ils permettent aux propriétaires d’identité de générer, présenter et vérifier les revendications. Ils constituent la base de confiance entre les utilisateurs des systèmes.

Microsoft Learn

Comment puis-je facilement tester les identités vérifiées ?

Par cet exercice d’identité vérifiée proposé par Microsoft, le processus devrait vous paraître plus concret. Voici l’explication du contexte de cet démonstration

Woodgrove est une société privée.
Proseware, une société qui offre des remises aux employés de Woodgrove.
Alice, une employée de Woodgrove souhaite obtenir une remise tarifaire sur les produits Proseware

Voici les différentes étapes de cet exercice :

Etape 1 : Obtention d’une identité vérifiée en relation avec une identité physique
Etape 2 : Utilisation de l’identité vérifié pour accéder aux ressources d’entreprise
Etape 3 : Utilisation de l’identité vérifié pour accéder aux ressources tierces

Si vous ne souhaitez pas faire cet exercice par vous-même, j’ai retrouvé une vidéo retraçant les différentes étapes :

Le seul prérequis nécessaire pour réaliser cet exercice est de disposer de Microsoft Authenticator sur son smartphone.

Pour réaliser cet exercice, rendez-vous sur cette page, renseignez des informations fictives, puis cliquez sur Suivant :

Cliquez-ici pour obtenir une identité vérifiée :

Cliquez-ici pour prendre une photographie fictive :

Cliquez-ici pour téléverser une copie d’une identité gouvernementale fictive :

Cliquez sur Suivant :

Attendez quelques secondes, puis cliquez sur OK :

Votre identité fictive a bien généré une identité vérifiée que nous allons maintenant récupérer :

Pour cela, ouvrez Microsoft Authenticator sur votre smartphone afin de scanner le QR code généré pour cette identité vérifiée :

La page web s’actualise et vous demande de reproduire le code PIN sur votre Smartphone :

Cliquez sur Suivant :

Cliquez sur Ajouter :

La page web s’actualise pour vous confirmer le succès de la récupération de l’identité vérifiée sur votre application Microsoft Authenticator, et vous invite ensuite à retourner sur la page principale :

L’étape 2 est automatiquement validée par le fait de disposer cette identité vérifiée sur votre application Microsoft Authenticator :

L’identité vérifiée s’intègre dans la liste des identités vérifiées sauvegardées, cliquez sur celle-ci :

Constatez les informations Entra ID stockées dans cette identité vérifiée :

Un autre onglet affiche l’historique des actions associées à cette identité vérifiée :

Toujours sur le portail web, cliquez-ici pour utiliser cette identité vérifiée pour vous authentifier sur portail employé de votre entreprise :

Scanner le QR code suivant afin d’autoriser le partage de votre identité vérifiée avec votre entreprise Woodgrove :

Utilisez la fonction suivante pour scanner le QR code généré :

Le site web est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :

Choisissez l’identité vérifiée à partager avec l’entreprise Woodgrove, puis confirmez le partage en cliquant ici :

Le site web de votre entreprise Woodgrove s’actualise et vous invite maintenant à continuer pour accéder au portail employé :

Une nouvelle activité liée à Woodgrove s’ajoute sur votre identité vérifiée :

Retournez sur le portail employé de votre entreprise Woodgrove afin de tester la validité de votre identité vérifiée par ce lien :

Un nouvel onglet s’ouvre à destination d’un site de vente fictif appelé Proseware :

Afin de profiter de rabais intéressant, une identification entreprise est nécessaire chez Proseware. Pour cela, cliquez sur le bouton suivant pour accéder aux prix remisés :

Cliquez sur le choix suivant afin d’utiliser votre nouvelle identité vérifiée :

Comme votre identité vérifiée est stockée sur votre application Microsoft Authenticator, un QR code est généré par Proseware afin de partager des informations d’identification :

Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivant pour scanner le QR code généré par Proseware :

Le site web de Proseware est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :

Choisissez l’identité vérifiée à partager avec Proseware, puis confirmez le partage en cliquant ici :

Le site web de Proseware s’actualise et affiche maintenant des tarifs remisés selon votre identité vérifiée :

Une nouvelle activité Proseware s’ajoute sur votre identité vérifiée :

Quelques informations supplémentaires sur ce partage sont disponibles :

Peut-on mettre en place les identités vérifiées sur Entra ID ?

Oui, il est possible de mettre en place les identités vérifiées sur Microsoft Entra ID. Voici quelques étapes clés pour commencer :

Configurer votre locataire Microsoft Entra : Vous devez d’abord configurer votre locataire pour la vérification d’identité.
Créer des informations d’identification vérifiables : Utilisez le portail Microsoft Entra pour créer et émettre des informations d’identification personnalisées.
Utiliser des outils et des exemples de code : Microsoft fournit des exemples de code et des guides pour vous aider à émettre et vérifier des informations d’identification vérifiables.

Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route d’Entra Verified ID.

Deux options de mise en place s’offrent alors à vous :

Pour notre démonstration, choisissez la configuration rapide :

Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :

La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :

Une fois la configuration automatique terminée, la notification suivante apparaît :

Retournez sur cette même page afin de constater l’apparition de nouveaux menus, ainsi que l’apparition d’un rendu graphique de l’identité vérifiée générée sur votre tenant :

Cliquez-ici afin de contrôler qui sur votre tenant peut obtenir une identité vérifiée :

Par défaut, tous les utilisateurs de votre tenant peuvent obtenir une identité vérifié. Cette option reste modifiable via ces 2 champs :

Retournez sur la page précédente afin d’obtenir une identité vérifiée sur votre compte Entra actuel :

Ce lien ouvre un nouvel onglet vers la page Mon Compte :

Cliquez-ici pour obtenir votre identité vérifiée :

Un QR code est alors généré et valable pendant 5 minutes :

Sur votre smartphone, ouvrez l’application Microsoft Authenticator, puis rendez-vous dans le menu suivant afin de scanner le QR Code :

L’identité vérifiée associée au QR code est reconnue, Microsoft Authenticator vous propose de l’ajouter à votre portefeuille d’identités vérifiées :

Cette dernière s’intègre alors dans la liste des identités vérifiées déjà sauvegardées :

Cliquez dessus afin de constater les informations Entra ID stockées dans cette identité vérifiée :

Ces informations ont été rendues accessibles par le biais de la configuration de l’identité vérifiée de votre tenant :

Toujours sur l’application Microsoft Authenticator, un autre onglet affiche l’historique des actions associées à cette identité vérifiée :

Retournez sur le portail Entra ID afin de tester la validité de votre identité vérifiée par ce lien :

Un nouvel onglet s’ouvre à destination d’un site de vente fictif appelé Proseware :

Afin de profiter de rabais intéressant, une identification est nécessaire chez Proseware. Pour cela, cliquez sur le bouton suivant pour accéder aux prix remisés :

Cliquez sur le choix suivant afin d’utiliser votre nouvelle identité vérifiée :

Comme votre identité vérifiée est stockée sur votre application Microsoft Authenticator, un QR code est généré par Proseware afin de partager des informations d’identification :

Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivant pour scanner le QR code généré par Proseware :

Le site web de Proseware est maintenant en attente de l’acceptation du partage d’informations de votre identité vérifiée :

Confirmez le partage en cliquant ici :

Le site web de Proseware s’actualise et affiche maintenant des tarifs remisés selon votre identité vérifiée :

Une nouvelle activité Proseware s’ajoute sur votre identité vérifiée :

Quelques informations supplémentaires sur ce partage sont disponibles :

Enfin, une fonction de révocation est même disponible via la page de configuration d’Entra ID :

Et il semble également possible de retirer le service déjà configuré d’identités vérifiées sur un tenant :

Conclusion

L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :

Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.

Windows 365 Cross-region Disaster Recovery (CRDR) !

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

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

Quels sont les engagements Microsoft en termes de SLA ?

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

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

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

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

99,9 % des sessions utilisateur Windows 365 Cloud PC hautement disponibles, telles que définies dans le contrat SLA Windows 365.

Stockage sur disque avec résilience des objets de données de onze 9.

Récupération d’urgence automatisée « dans la zone » pour le calcul.

Un objectif de point de récupération de ~0.

Micr o soft Learn

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

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

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

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

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

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

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

RTO de < 6 heures.

RPO de <30 minutes pour les modifications apportées au service de gestion.

Microsoft Learn

Qu’est que le Cross-region Restore ?

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

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

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

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

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

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

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

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

CRR vs DR vs CRDR ?

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

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

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

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

Quid des RPOs et RTOs ?

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

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

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

RPO de <4 heures.

Microsoft Learn

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

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

Etape 0 – Rappel des prérequis :

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

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

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

Etape I – Configuration du CRDR

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

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

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

Cliquez sur Éditer :

Activez par cette option la fonctionnalité CRDR :

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

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

La notification Intune suivante apparaît alors :

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

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

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

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

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

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

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

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

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

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

Etape II – Activation du Cross-region Disaster Recovery :

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

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

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

Renseignez tous les champs, puis cliquez sur Suivant :

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

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

La notification Intune suivante apparaît :

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

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

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

La notification Intune suivante apparaît :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cliquez sur Suivant :

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

La notification Intune suivante apparaît :

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

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

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

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

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

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

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

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

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

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

Ouvrez à nouveau page Internet suivante.

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

Conclusion

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

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

Modifiez la langue de votre VM

Grâces à la Marketplace Azure, il est très facile de trouver son bonheur quand on recherche une image particulière, déjà mise à jour et surtout adaptée au contexte du Cloud. Seulement, certaines personnalisations ultérieures sont souvent nécessaires, comme par exemple : la langue affichée. Certains vous diront que fois basique, mais c’est souvent essentiel pour de nombreux utilisateurs non anglophones.

Ayant récemment travaillé sur un environnement Azure Virtual Desktop aux exigences de langues spécifiques, je souhaitais trouver un moyen simple de changer la langue OS d’une machine virtuelle image template fonctionnant sous Windows 11.

Microsoft préconise cette approche pour AVD :

À compter de Windows 11, les comptes d’utilisateur non-administrateurs peuvent désormais ajouter la langue d’affichage et les fonctionnalités de langue correspondantes. Cette fonctionnalité signifie que vous n’aurez pas besoin de préinstaller des modules linguistiques pour les utilisateurs d’un pool d’hôtes personnel.

Pour les pools d’hôtes mis en pool, nous vous recommandons quand même d’ajouter les langues que vous prévoyez d’ajouter à une image personnalisée. Vous pouvez utiliser les instructions de cet article pour les versions à session unique et à plusieurs sessions de Windows 11 Entreprise.
Microsoft Learn

La méthode proposé par Microsoft pour les environnements Azure Virtual Desktop multisessions semble très convaincante et fera l’objet d’un prochain article sur ce blog.

En parallèle de cette méthode, je souhaitais vous en proposer une autre plus ancienne, mais toujours fonctionnelle, pour une VM Azure Virtual Desktop ou non.

Plein de choses sont d’ailleurs déjà possibles via des GPOs, mais je souhaitais configurer la langue directement dans mon image VM template.

Voici donc les quelques chapitres dans mon article :

Etape 0 – Rappel des prérequis :

Pour réaliser mon test, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Commençons par créer une machine virtuelle sous Windows 11.

Etape I – Création d’une machine virtuelle :

Comme vous pouvez le voir dans la copie d’écran ci-dessous, il n’est pas possible de choisir précisément la langue ou le pack de langues de notre OS :

Comme attendu, l’écran de démarrage est par défaut en anglais :

L’interface utilisateur l’est également :

Allons voir dans Language et région :

Seule la langue Anglais (USA) est disponible pour notre utilisateur administrateur :

Seul le pack Anglais (USA) semble installé :

Cela se confirme par la commande suivante :

Get-InstalledLanguage

Toutes les features et le clavier correspondant semblent déjà installés pour ce pack de langue :

Le pays est là encore défini sur USA, peu importe le région Azure utilisée :

De façon logique, le formatage Anglais (USA) y est également appliqué :

Continuons avec l’administration des paramètres de la langue :

Un clic pour consulter les 3 types de paramétrage :

Que ce soit pour l’utilisateur actuel, l’écran d’accueil ou pour un nouvel utilisateur, tout est configuré en Anglais (USA) :

Maintenant, notre but est donc de modifier la configuration en Anglais vers une configuration Français (Suisse). Pour cela, je me suis inspiré de l’article suivant écrit par Alexandre Verkinderen pour y parvenir.

Etape II – Modification de la langue via script :

Commençons par ouvrir une fenêtre PowerShell ISE :

Vérifions une seconde fois le ou les packs de langue installés par la commande suivante :

Get-InstalledLanguage

Exécuter le script PowerShell suivant en prenant soin de modifier certaines variables :

$regionalsettingsURL (ne pas modifier) : méhode automatisée ancienne, mais toujours valable et basée sur un fichier XML de configuration source
$RegionalSettings (ne pas modifier) : fichier XML de configuration de destination
$Language : modifier au besoin le language (liste)
$GeoId : Zone géographique (liste)
$TimeZone : Fuseau horaire par défaut (liste)

# Script to define regional settings on Azure Virtual Machines deployed from the market place
# Author: Created by Alexandre Verkinderen, modified by Jean-Loup Orgitello
# Blogpost: https://mscloud.be/configure-regional-settings-and-windows-locales-on-azure-virtual-machines/
#
########################################

#variables
$regionalsettingsURL = "https://raw.githubusercontent.com/jlou07/CHLang/main/CHRegion.xml"
$RegionalSettings = "C:\Region.xml"
$Language = "fr-CH"
$GeoId = "223"
$TimeZone = "W. Europe Standard Time"

#LanguagePack Suisse
Install-Language $Language

#downdload regional settings file
$webclient = New-Object System.Net.WebClient
$webclient.DownloadFile($regionalsettingsURL,$RegionalSettings)

#LanguagePack USA
unInstall-Language "en-US"
Start-sleep -Seconds 120

# Set languages/culture. Not needed perse.
Set-WinSystemLocale $Language
Set-WinUserLanguageList -LanguageList $Language -Force
Set-Culture -CultureInfo $Language
Set-WinHomeLocation -GeoId $GeoId 
Set-TimeZone -id $TimeZone

# Set Locale, language etc. 
& $env:SystemRoot\System32\control.exe "intl.cpl,,/f:`"$RegionalSettings`""

# restart virtual machine to apply regional settings to current user. 
Start-sleep -Seconds 40
Restart-Computer