Windows 365 Link

Depuis plusieurs mois, je souhaitais pouvoir Windows 365 Link dans des conditions réelles d’utilisation. Cette opportunité m’a enfin permis de prendre le temps d’analyser la solution de manière concrète, au-delà des annonces marketing et des fiches techniques. L’objectif de cet article est de décortiquer Windows 365 Link sous différents angles : technique, licences, intégration à l’écosystème Microsoft, mais aussi usage quotidien.

Au fil des tests, j’ai cherché à comprendre dans quels scénarios ce type d’appareil apporte une réelle valeur, et dans quels cas d’usage il montre ses limites.

Cet article se veut à la fois factuel et basé sur un retour d’expérience, afin d’apporter une vision pragmatique de Windows 365 Link et de son positionnement dans une stratégie de poste de travail cloud.

Pour vous guider plus facilement dans cet article très long, voici des liens rapides :

FAQ :

Test Windows 365 Link :

Commençons par le tout début. Il était une fois… Windows 365 Link.

Qu’est-ce que Windows 365 Link ?

En quelques mots, Windows 365 Link est un thin client qui permet de se connecter directement à un Cloud PC Windows 365, vous offrant ainsi un moyen sécurisé et simple d’accéder à votre environnement cloud.

Windows 365 Link est le premier appareil matériel pc cloud qui permet aux utilisateurs de se connecter directement à leur machine virtuelle Cloud PC. Il s’agit d’une solution de pile complète et spécialement conçue par Microsoft.

Microsoft Learn

Lorsque les utilisateurs se connectent à leur Windows 365 Link, ils sont connectés à leur machine virtuelle PC Windows 365 Cloud via le service Windows 365.

Microsoft Learn

Nerdio illustre, à l’aide d’un schéma simple, la manière dont Windows 365 Link s’intègre à l’écosystème cloud de Microsoft

Quelles sont ses caractéristiques techniques ?

Windows 365 Link mesure 120 × 120 × 30 mm pour un poids de 418 grammes, et est compatible VESA 100 et verrous Kensington. De plus, il dispose des connectivités suivantes :

Sans fil :
- Wi-Fi 6E
- Bluetooth 5.3
Face avant :
- USB-A (USB 3.2)
- Prise audio jack
Face arrière :
- USB-C (USB 3.2)
- DisplayPort (1.4a, jusqu’à 4k 60 Hz)
- HDMI (2.0b, jusqu’à 4k60)
- Ethernet (1.0 Gbit/s)
- Alimentation électrique (65 watts)
- Unified Extensible Firmware Interface (UEFI) pour la réinitialisation

Côté matériel et logiciel, on retrouve les éléments suivants :

Hardware :
- Processeur Intel N250
- 8 Go LPDDR5
- 64 Go de stockage flash
- Puce TPM 2.0
Software :
- Système d’exploitation dédié (Windows CPC)
- Secure Boot
- Virtualization-based security
- Hypervisor-protected Code Integrity
- BitLocker
- Stratégie de contrôle strict des applications
- Aucun utilisateur local disposant de droits d’administration
- Aucun stockage de données local
- Aucune application locale
- Stratégies de sécurité de base activées par défaut
- Sonde EDR Microsoft Defender

Durant mes tests, j’ai relevé plusieurs niveaux de consommation électrique instantanée :

Mire d’authentification ouverte : 4,48 W
Session Windows 365 ouverte inactive : 7,36 W
Application graphique ouverte : 8,89 W
Appel Teams ouvert : 7,51 W

Voici d’ailleurs le document PDF de Microsoft reprenant les caractéristiques techniques de Windows 365 Link :

windows-365-link-data-sheet Télécharger

À quoi sert-il ?

Windows 365 Link est conçu pour offrir un accès direct, sécurisé et dédié à un PC Cloud Windows 365, sans exécuter de système Windows local complet. L’objectif n’est pas de remplacer un PC traditionnel, mais de proposer un point d’accès matériel minimaliste, fortement intégré aux services Microsoft Entra ID, Intune et Windows 365.

En quoi est-il différent d’un PC pour accéder à Windows 365 ?

Contrairement à un PC Windows traditionnel, Windows 365 Link ne stocke pas de données utilisateur localement et ne permet pas d’exécuter d’applications hors du PC Cloud. Toute l’expérience utilisateur est déportée dans le Cloud PC, ce qui contribue à réduire la surface d’attaque locale et simplifie considérablement l’administration du poste.

Windows 365 Link peut-il remplacer un thin client tiers ?

Windows 365 Link se rapproche fonctionnellement d’un thin client, mais avec une intégration native et exclusive à Windows 365.

Il ne vise pas la polyvalence fonctionnelle (VDI multiples, accès Linux ou AVD générique), mais une expérience optimisée et contrôlée pour Windows 365 uniquement. Cela en fait un choix pertinent dans des environnements standardisés, mais plus restrictif que certaines solutions tierces.

Attention, ce point a déjà été mentionné à plusieurs reprises, mais mérite d’être rappelé : Windows 365 Link ne prend pas en charge Azure Virtual Desktop ni Microsoft Dev Box.

Dans quels scénarios est-il le plus pertinent ?

Windows 365 Link est particulièrement adapté aux environnements à postes partagés, aux scénarios Frontline, aux centres de contact, aux environnements industriels ou aux sites distants où la simplicité de déploiement, la sécurité et la rapidité de remplacement du matériel sont prioritaires.

Voici quelques exemples de cas d’usage :

Postes partagés

Permettre aux collaborateurs en mode hybride de retrouver instantanément leur environnement de travail
Accès rapide et sécurisé à leur Cloud PC Windows 365, sans dépendance au poste physique
Idéal pour les environnements à forte rotation d’utilisateurs ou à postes non attribués

Centres d’appels

Démarrage en quelques secondes vers un Cloud PC Windows 365
Expérience utilisateur fluide et réactive, adaptée aux usages intensifs (voix, CRM, applications métiers)
Aucune donnée stockée localement sur le terminal, réduisant les risques de fuite d’informations
Authentification sans mot de passe via Microsoft Entra ID

Espaces spécialisés

Accès sécurisé aux outils et aux données dans des environnements contrôlés
Utilisation dans des lieux spécifiques tels que :
- laboratoires
- zones logistiques ou arrière-boutiques
- centres de formation
- accueils et réceptions

Frontline et métiers spécifiques

Mise à disposition d’un poste de travail Cloud sécurisé pour :
- travailleurs de première ligne en milieu industriel
- agents d’accueil
- personnels en environnement scientifique ou de recherche
Réduction des contraintes matérielles locales et simplification du support

Métiers à forte sensibilité des données

Accès distant sécurisé pour des profils tels que :
- analystes financiers
- consultants
- chargés de clientèle bancaire
- agents de support client
- téléconseillers / télévendeurs
Centralisation des données dans le Cloud PC, limitant les risques de fuite ou de perte

Dans quels cas n’est-il pas recommandé ?

Windows 365 Link est peu adapté aux utilisateurs nomades, aux scénarios nécessitant un fonctionnement hors ligne, ou aux usages impliquant des applications locales spécifiques ou des périphériques avancés non pris en charge. Il n’est pas non plus destiné à remplacer un poste de travail puissant pour des usages lourds locaux.

De ce fait, la comparaison entre Windows 365 Link + Cloud PC et un ordinateur portable moyen de gamme peut soulever des questions économiques :

Critère	Laptop moyen de gamme	Windows 365 Link + Windows 365
Coût matériel initial	~800 € (laptop)	365 € (Windows 365 Link)
Durée de vie	3–4 ans	4–5 ans (device statique)
Coût licence Windows 365	0 €	60 €/mois → 2 160 € sur 3 ans
Déploiement initial	Imaging, drivers, apps	Provisioning automatique
Support & maintenance (3 ans)	30 h × 60 €/h = 1 800 €	30 h × 30 €/h = 900 €
Données locales	Oui	Non
Exposition en cas de perte/vol	Élevée	Très faible (données Cloud)
Continuité de service	Dépend du matériel	Reconnexion immédiate
Coût total estimé sur 3 ans	~2 600 €	~3 425 €
Lecture du ROI	Référence	Surcoût ~825 € / poste sur 3 ans

Windows 365 n’est donc pas nécessairement moins coûteux par défaut, le ROI devient positif si :

Postes partagés / Frontline / hot desk
Réduction forte du support de proximité
Exigences sécurité élevées
Besoin de remplacement immédiat du poste

Sinon, sur poste dédié standard, l’ordinateur portable reste économiquement plus avantageux.

Permet-il de réduire les coûts IT et le provisioning ?

Dans les usages recommandés listés plus haut, Windows 365 Link peut contribuer à une réduction des coûts liés au support, au renouvellement matériel et à la gestion des images système. En revanche, il renforce la dépendance au modèle de licences Windows 365, qui doit être évalué globalement dans la stratégie poste de travail.

Windows 365 Link simplifie le provisioning, le remplacement des appareils et l’exploitation quotidienne grâce à l’enrôlement automatique Entra ID et Intune. L’administration est centralisée, avec moins d’interventions locales, ce qui facilite la standardisation et la gouvernance du poste de travail.

Quels sont ses bénéfices de sécurité ?

L’absence de données persistantes locales, l’authentification systématique via Microsoft Entra ID et l’intégration native avec les stratégies d’accès conditionnel renforcent la posture de sécurité globale. En cas de perte ou de vol du matériel, aucune donnée utilisateur n’est exposée localement.

En centralisant l’exécution et les données dans le Cloud PC, Windows 365 Link limite les impacts d’incidents matériels, de compromission locale ou de mauvaise configuration utilisateur. La gestion centralisée via Intune permet également d’appliquer des politiques de sécurité homogènes et cohérentes.

Quels sont les licences nécessaires pour l’utiliser ?

Voici les exigences connues pour pouvoir utiliser Windows 365 Link :

Exigences de licence Windows 365
Exigences Microsoft Entra ID
Exigences Microsoft Intune

Prenons le temps de comprendre en détail toutes ces exigences.

Exigences de licence Windows 365 :

Windows 365 Link n’introduit aucune nouveauté du côté des licences. On reste strictement dans le périmètre Windows 365.

Sans licence Windows 365 valide assignée à l’utilisateur, votre Windows 365 Link n’est pas utilisable : la connexion à un autre PC est tout simplement impossible, même à un environnement Azure Virtual Desktop.

À noter que Windows 365 Link accepte tous les types de licences Windows 365 :

Windows 365 Entreprise
Windows 365 Business
Windows 365 Frontline

Exigences Microsoft Entra ID :

Avec Windows 365 Link, un point apparaît rapidement comme non négociable : Windows 365 Link doit être Microsoft Entra joined ou Entra hybrid joined.

L’utilisateur qui effectue cette jonction doit bien évidemment avoir les droits pour joindre des appareils au tenant :

Lors de la jonction à Entra ID, le device s’enrôle automatiquement dans Intune. Et là, point important : l’utilisateur qui joint le device doit disposer d’une licence Microsoft Entra ID Premium, sinon l’enrôlement automatique échoue.

L’enrôlement automatique dans Intune dépend du paramétrage suivant :

Exigences Microsoft Intune :

L’enrôlement Intune des Windows 365 Link se fait pendant l’OOBE, sans action manuelle supplémentaire grâce aux mécanismes d’Entra.

Là encore, l’utilisateur qui joint le Windows 365 Link doit :

Disposer d’une licence Microsoft Intune
Avoir le droit d’enrôlement
Ne pas être bloqué par des restrictions d’enrôlement Intune :

Concrètement, voici ce que la donne lors du premier démarrage du Windows 365 Link :

L’utilisateur démarre et s’authentifie pour la toute première fois :

Le Windows 365 Link s’enrôle automatiquement dans Entra :

Puis l’enrôlement automatique MDM prend le relais pour l’ajouter dans Intune :

Avant d’arriver à cela avec votre Windows 365 Link, prenons le temps de passer en revue toutes les étapes.

Où peut-on l’acheter ?

Sa disponibilité dépend des pays et des vagues de lancement définies par Microsoft. L’appareil est proposé via des partenaires et revendeurs agréés Microsoft, comme TD SYNNEX selon les régions concernées.

À ce jour, la disponibilité semble s’élargir progressivement avec les vagues successives de déploiement, parfois désignées comme Wave 1 ou Wave 2. Windows 365 Link est actuellement disponible pour les pays suivants :

États-Unis
Australie
Canada
Danemark
France
Allemagne
Inde
Japon
Pays-Bas
Nouvelle-Zélande
Suède
Suisse
Royaume-Uni

Dans les prochains mois, Il devrait l’être par la suite aussi disponible dans :

Belgique
Finlande
Irlande
Italie
Pologne
Singapour
Espagne

Pour connaître les options d’achat exactes, il est recommandé de se rapprocher d’un partenaire Microsoft local ou de consulter les annonces officielles de Microsoft pour votre zone géographique.

Maintenant que les principaux aspects fonctionnels, techniques et de licences autour de Windows 365 Link ont été abordés, il est temps de passer à la partie plus concrète.

La section suivante détaille pas à pas les différentes étapes de configuration et de prise en main de Windows 365 Link, depuis la préparation de l’environnement jusqu’aux premiers tests en conditions réelles :

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré plusieurs polices de provisionnement afin de créer mes Cloud PCs qui vont me servir durant mes tests :

Les Cloud PCs étant correctement déployés, une exigence particulière concerne toutefois le SSO avec Entra. Pour être plus clair, je vais maintenant repasser en détail sur toutes les étapes pour correctement configurer le SSO.

Etape I – Configuration du Single Sign-On :

Windows 365 Link repose entièrement sur le mécanisme Single Sign-On via Microsoft Entra ID. Autrement dit : si le SSO n’est pas activé sur le Cloud PC, la connexion de votre utilisateur risque d’échouer :

Pour activer le SSO, il sera nécessaire de vérifier, et de modifier si nécessaire, la police de provisionnement de vos Cloud PC, puis de recréer au besoin de nouveaux Cloud PCs si ces derniers ont été créés avant cette modification :

Voici l’option SSO dans la police de provisionnement des Cloud PCs qui doit être cochée :

L’étape suivante consiste à supprimer la demande de consentement SSO côté Microsoft Entra ID, dont la configuration repose sur des principaux de service :

Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise la console PowerShell d’Azure Cloud Shell, accessible depuis le portail Azure :

J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte aux permissions appropriées :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :

$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Je modifie la propriété isRemoteDesktopProtocolEnabledtrue sur True, puis je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Depuis le portail Intune, je crée ensuite un groupe contenant les Cloud PCs :

J’utilise une requête dynamique pour ajouter automatiquement mes prochains Cloud PCs au groupe :

Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login :

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Enfin, j’assigne le groupe créé :

Get-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId

Tout est maintenant en place pour tester la première authentification sur votre Windows 365 Link.

Etape II – Test de la première connexion Windows 365 Link :

La vidéo suivante correspond à la première connexion avec succès de mon utilisateur de test à son Windows 365 Link :

J’ai réalisé ensuite une seconde vidéo montrant plusieurs scénarios de connexion et de bascule d’utilisateurs avec Windows 365 Link :

Le premier test illustre la connexion d’un utilisateur unique à différents Cloud PC Windows 365 qui lui sont attribués. L’objectif est d’observer le temps de connexion, la fluidité du changement de Cloud PC, ainsi que l’efficacité globale du processus d’authentification.

Le second test se concentre sur un scénario de type pool partagé, comparable à un usage Windows 365 Frontline, où plusieurs utilisateurs se connectent successivement au sein d’un même pool de Cloud PC. Ce scénario permet d’analyser le comportement de l’authentification, la gestion des sessions et la rapidité de bascule entre utilisateurs.

Ces démonstrations offrent un retour concret sur les performances et l’expérience utilisateur, avant d’aborder les aspects de configuration et d’administration via Intune.

Travis nous a d’ailleurs fait une excellente vidéo sur ce sujet disponible juste ici :

Une fois ces premiers tests de connexion réalisés, on peut imaginer d’autres tâches ou configurations que l’on peut faire autour de son Windows 365 Link.

Mais avant cela, je vous conseille de commencer par créer un filtre d’assignation Intune pour cibler uniquement les Windows 365 Link dans vos futures polices de configuration.

Etape III – Création d’un filtre d’assignation Intune :

Depuis le portail Intune, je commence par créer un filtre d’assignation, qui me sera très utile pour configurer les Windows 365 Link par la suite :

Je nomme ce filtre avec comme plateforme Windows 10 et +, puis je clique sur Suivant :

Je spécifie la règle de filtrage selon la propriété suivante afin de ne prendre en compte que les appareils Windows 365 Link, puis je clique sur Prévisualiser :

Si des Windows 365 Link sont déjà présents, je devrais voir ces derniers apparaître :

Enfin je confirme la création du filtre :

Mon filtre est maintenant en place, je vais pouvoir commencer à effectuer quelques réglages, comme la détection automatique du fuseau horaire.

Etape IV – Configuration automatique du fuseau horaire :

Au démarrage de votre Windows 365 Link, l’heure qui s’affiche n’est peut-être pas la bonne :

Les appareils Windows 365 Link peuvent rencontrer des problèmes de fuseau horaire si la détection automatique n’est pas autorisée. Il est possible de forcer l’utilisation du fuseau horaire local en autorisant l’accès à la localisation via Microsoft Intune.

Pour cela, connectez-vous au portail Intune, puis dirigez-vous vers le menu suivant :

Sélectionnez le type de profil suivant :

Renseignez les informations suivantes, puis cliquez sur Suivant :

Nom : Windows 365 Link – Time Zone Detection
Description : Autorise l’accès à la localisation afin de permettre la détection automatique du fuseau horaire sur les appareils Windows 365 Link.

Recherchez Access location, puis sélectionnez la catégorie Privacy, configurez comme ceci, puis cliquez sur Suivant :

Ajoutez les Scope tags nécessaires selon votre organisation, puis cliquez sur Suivant :

Dans Assignments, ciblez les appareils Windows 365 Link selon la méthode suivante, puis cliquez sur Suivant :

Par exemple, en utilisant All devices
En appliquant un Include filter basé sur un filtre de type Windows 365 Link

Vérifiez la configuration, puis cliquez ici pour déployer la stratégie :

Quelques minutes plus tard, l’accès à la localisation est autorisé, Windows 365 Link peut détecter automatiquement le fuseau horaire local, et affiche l’heure correcte selon la localisation de l’utilisateur :

Etape V – Modification du délai d’extinction de l’écran :

Par défaut, les appareils Windows 365 Link éteignent l’écran après environ cinq minutes d’inactivité. Ce comportement est assimilé à un verrouillage local : lorsque l’utilisateur réactive l’appareil, l’écran de connexion s’affiche.

Comme pour l’heure, la configuration se fait via une police de configuration Intune. Dans mon cas je configure l’extinction de l’écran après 9 minutes d’inactivité :

Travis nous a encore fait une excellente seconde vidéo sur ce sujet :

Etape VI – Modification des délais de déconnexion des sessions :

Comme Microsoft le recommande, est-il possible de raccourcir (mais pas de rallonger ?) les temps définis par défaut dans le cas de sessions Windows 365 inactives ou déconnectées :

Par défaut, Windows 365 PC Frontline conservent la session utilisateur active jusqu’à ce que :

En mode dédié : Le PC cloud est inactif pendant 30 minutes.

En mode partagé : Le PC cloud est inactif pendant 15 minutes.

Deux minutes avant la limite de temps d’inactivité, l’utilisateur reçoit une notification avec une boîte de dialogue.

Microsoft Learn

Cette stratégie force la fermeture (log off) des sessions Windows 365 afin d’éviter :

Les sessions laissées ouvertes sans activité
Les sessions bloquées après une coupure réseau
La consommation inutile de capacité (critique en Frontline partagé)

Elle remplace alors entièrement le comportement par défaut des services Windows 365 expliqués plus haut, à la condition que les temps indiqués ne soient pas supérieurs :

Par contre, à la différence des configurations précédemment appliquées sur les Windows 365 Link, j’ai appliqué cette nouvelle police sur filtre comprenant uniquement les Cloud PCs Frontline comme ceci :

Le tableau ci-dessous résume les différents événements observés et les mécanismes impliqués dans ma configuration :

Étape	Heure	Événement	Mécanisme responsable
Login utilisateur	08h47	Connexion au Cloud PC Frontline	Session RDS active
Idle atteint	08h52	Message “You will be signed out in 2 minutes”	Idle session RDS (5 min)
Log off	08h54	Déconnexion automatique (sign out)	End session when time limits are reached
Écran noir	09h03	Extinction automatique de l’écran	Policy Display Windows 365 Link (9 min)

Etape VII – Connexion automatique sur un Cloud PC :

Windows 365 Link permet également d’activer des mécanismes de connexion automatique et d’authentification sans mot de passe (passwordless), afin de simplifier encore davantage l’accès au Cloud PC pour l’utilisateur final.

Dans ce scénario, l’utilisateur n’a pas besoin de saisir manuellement son identifiant, ce qui rend l’expérience de connexion particulièrement fluide :

Pour cela, je suis passé par la création d’une police de configuration personnalisé avec les paramètres OMA-URI suivants :


Nom : Activer les clés de sécurité FIDO pour la connexion à Windows
OMA-URI : ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
Type de données : Integer
Valeur : 1

Il est également possible de configurer Windows 365 Link pour qu’il se connecte automatiquement à un Cloud PC Windows 365 spécifique :

Cette option est particulièrement adaptée aux environnements à poste dédié ou aux usages standardisés. On y retrouve les fonctionnalités habituelles, comme la restauration ou la réinitialisation de la connexion.

Enfin, un bouton Annuler permet d’annuler la connexion automatique à ce Cloud PC. Cette action redirige l’utilisateur vers l’écran de sélection afin de lui permettre de choisir un autre Cloud PC Windows 365 auquel se connecter :

Ces options permettent d’adapter finement l’expérience de connexion selon que l’on se trouve dans un scénario à poste dédié ou à usage partagé.

Etape VIII – Restauration de mode usine :

Si nécessaire, Microsoft propose une restauration en mode usine des Windows 365 Link depuis le portail Intune. Comme beaucoup de postes gérés en MDM sous Intune, cette fonction très utile permet de réinitialiser complètement l’appareil à distance, en supprimant toute configuration et toute association utilisateur, afin de le reprovisionner proprement.

Voici d’ailleurs une vidéo qui montre le processus en entier, d’environ 30 minutes (accéléré), sur un Windows 365 Link :

Etape IX – Test de Microsoft Teams :

J’ai réalisé un test Microsoft Teams avec Windows 365 Link et j’ai été très satisfait de l’expérience globale, tant sur la qualité du rendu que sur la fluidité du partage d’écran et des flux audio/vidéo.

Un tour dans les paramètres de Teams confirme que le mode Media Optimized (SlimCore) est bien actif avec Windows 365 Link :

Pour plus de détails sur SlimCore et son fonctionnement côté AVD / Windows 365, voir cet article dédié sur mon blog.

Ce test rapide illustre le rendu réel de Microsoft Teams en conditions d’usage, du partage d’écran et des flux caméra, en mettant en évidence que le traitement (CPU) est effectué localement sur le Windows 365 Link et non sur le Cloud PC :

Et voici encore une autre vidéo faite cette fois avec une vidéo YouTube :

Après ces différents tests et configurations, il est possible de tirer plusieurs enseignements concrets sur l’usage de Windows 365 Link.

Conclusion

En conclusion, et après plusieurs jours d’utilisation et de tests dans des scénarios réels, Windows 365 Link s’est montré convaincant à l’usage quotidien.

Les performances observées, la simplicité d’accès au Cloud PC et la stabilité globale de l’expérience m’ont laissé une impression très positive au quotidien. Dans certains cas, j’ai pu avoir des doutes quant à la pertinence de l’appareil, notamment pour des scénarios où ses limites fonctionnelles peuvent apparaître.

Néanmoins, pour les cas d’usage évoqués plus haut (postes partagés, environnements Frontline, centres de contact ou contextes à forte exigence de sécurité), Windows 365 Link apporte une réelle valeur.

C’est un produit cohérent, bien positionné dans la stratégie Cloud-first de Microsoft, et je suis personnellement très satisfait d’avoir pu le tester dans des conditions concrètes et représentatives.

Alors, Windows 365 Link est-il un produit de niche ou le début d’une nouvelle norme ?

Windows 365 Link s’inscrit dans la stratégie Cloud-first de Microsoft et cible des usages bien définis. Il ne remplace pas tous les postes de travail, mais propose une alternative cohérente dans les environnements où la simplicité, la sécurité et la centralisation priment sur la flexibilité locale.

Enfin, retrouvez-moi et Arnaud et Arnaud dans un futur AzuReX prévu le 29 janvier prochain à 13 heures, dont l’inscription se passe juste ici 😎

Merci d’avoir lu cet article jusqu’au bout 😎

Azure Virtual Desktop hybride + SSO

Azure Virtual Desktop est souvent présenté comme une solution offrant un Single Sign-On “natif”. Dès que l’on sort d’un environnement cloud-only pour entrer dans un contexte hybride, les mécanismes d’authentification deviennent toutefois plus complexes, et parfois déroutants. Entre Microsoft Entra ID, Active Directory, Kerberos, PRT, Seamless SSO et Cloud Kerberos Trust, il est facile de confondre des briques aux noms proches, mais qui n’interviennent ni au même moment ni au même niveau.

Dans un précédent article, j’avais détaillé la mise en place du SSO Azure Virtual Desktop dans un environnement cloud-only.

Dans cet article, j’ai volontairement changé de contexte pour travailler sur un environnement hybride. L’objectif de cet article est de répondre aux trois questions suivantes :

Clarifier les mécanismes d’authentification (PRT, Seamless SSO, Kerberos, etc.)
Montrer pas à pas pourquoi certaines étapes sont indispensables pour obtenir un SSO réellement transparent dans AVD.
A quoi sert le Seamless SSO disponible dans Entra Connect Sync ?

Avant d’aborder la configuration et les tests, il est utile de poser le cadre : comprendre quels mécanismes d’authentification sont utilisés, à quel moment, et pourquoi certains fonctionnent seuls alors que d’autres doivent être combinés.

Cette FAQ a pour objectif de lever les confusions les plus fréquentes autour des tokens, du Kerberos, et du Single Sign-On dans un environnement Microsoft Entra hybride.

Quels sont les tokens utilisés par Microsoft Entra ID ?

Microsoft Entra ID utilise plusieurs types de tokens, chacun ayant un rôle précis :

Primary Refresh Token (PRT)
- Jeton long terme
- Spécifique à l’appareil
- Sert à demander d’autres tokens
- Utilisé par Windows (WAM – Web Account Manager)

Access Token
- Jeton court terme
- Présenté aux applications (API, Office, AVD…)
- Contient les claims utilisateur

Refresh Token
- Permet de renouveler un Access Token
- Généralement géré automatiquement par le système

Qu’est-ce que le Primary Refresh Token (PRT) ?

Dans le monde de Microsoft, le PRT est un jeton émis par Microsoft Entra ID lorsqu’un appareil est Microsoft Entra Joined ou Microsoft Entra Hybrid Joined.

Un jeton d’actualisation principal (PRT) est un artefact clé de l’authentification Microsoft Entra dans les versions prises en charge de Windows, iOS/macOS, Android et Linux. Un PRT est un artefact sécurisé spécialement émis aux répartiteurs de jetons microsoft pour activer l’authentification unique (SSO) sur les applications utilisées sur ces appareils.

Microsoft Learn

Le PRT est stocké localement sur la machine et sert de jeton racine pour :

obtenir des tokens d’accès OAuth 2.0
s’authentifier automatiquement aux services cloud Microsoft
éviter toute ressaisie de mot de passe pour les applications modernes

Concrètement, le PRT permet :

l’ouverture automatique de session dans Edge
l’authentification transparente à Office, Teams, OneDrive
l’utilisation de Windows App / Azure Virtual Desktop web

Point important : le PRT n’est pas Kerberos et ne permet pas, à lui seul, d’ouvrir une session Windows sur une machine Active Directory.

Pourquoi le PRT ne suffit-il pas pour Azure Virtual Desktop en mode Hybride ?

Dans un environnement Azure Virtual Desktop en mode Hybride, il y a deux niveaux d’authentification distincts :

Accès au service AVD (broker / portail)
→ Authentification Microsoft Entra ID
→ Le PRT suffit
Ouverture de la session Windows sur le session host
→ Authentification Active Directory
→ Un TGT Kerberos est obligatoire

Dans un environnement Microsoft Entra Hybrid Joined, le PRT est présent, mais le TGT Kerberos n’est pas automatiquement délivré par Entra.

Cela permet de comprendre pourquoi une seconde authentification Active Directory est fréquemment observée dans de nombreux environnements AVD, après une première authentification Entra.

Qu’est-ce qu’un TGT Kerberos Active Directory ?

Le Ticket Granting Ticket (TGT) est un jeton Kerberos délivré par un contrôleur de domaine Active Directory.

Il est obtenu :

lors de l’ouverture de session Windows
après une authentification réussie auprès de l’AD

Le TGT permet ensuite :

d’accéder aux ressources Active Directory
d’obtenir des tickets de service (CIFS, LDAP, HTTP, etc.)
d’ouvrir une session Windows locale ou distante

Sans TGT Kerberos, l’ouverture d’une session Active Directory n’est pas possible.

Qu’est-ce que Microsoft Entra Kerberos (Cloud Kerberos Trust) ?

Microsoft Entra Kerberos est le mécanisme qui permet à Microsoft Entra ID de :

générer un TGT Kerberos Active Directory
à partir d’une authentification cloud
sans nécessiter ADFS

Techniquement :

un objet Kerberos spécial est créé dans l’Active Directory
les clés sont synchronisées avec Microsoft Entra ID
Entra devient capable d’émettre un TGT valide pour l’AD

C’est l’élément nécessaire pour obtenir un SSO complet dans AVD en environnement hybride.

Pourquoi la jointure hybride améliore l’expérience SSO ?

Avec Microsoft Entra Hybrid Join :

l’appareil est reconnu par Entra
un PRT est délivré
les applications cloud utilisent un SSO moderne

En ajoutant Microsoft Entra Kerberos :

Entra peut aussi délivrer un TGT AD
Windows peut ouvrir la session sans redemande de mot de passe

On comprend alors que la combinaison du PRT et d’un TGT Kerberos est nécessaire pour obtenir un SSO transparent dans Azure Virtual Desktop.

À quoi sert la case “Single sign-on” dans Entra Connect ?

La case Single sign-on dans Microsoft Entra Connect active ce qu’on appelle Seamless SSO.

Seamless SSO repose sur :

Kerberos
le compte AD AZUREADSSOACC
le site autologon.microsoftazuread-sso.com

Son objectif est volontairement limité :

éviter la saisie du mot de passe AD
lors d’une authentification navigateur vers Entra ID
sur une machine AD-only

Il est important de distinguer Seamless SSO des autres mécanismes :

ne crée PAS de PRT
ne remplace PAS Microsoft Entra Kerberos
ne supprime PAS tous les écrans de login

Pour se donner une meilleure idée de cette fonctionnalité SSO spécifique, nous la testerons dans la dernière étape de cet article.

Mais commençons d’abord par tester la mise en place du single sign-on complet pour un environnement AVD de mode hybride, dont les procédures officielles sont disponibles ici et là :

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré certains composants.

Un environnement Active Directory
Microsoft Entra Connect configuré avec
- Password Hash Synchronization (PHS)
- sans Single sign-on,
- avec Hybrid Joined pour les machines Windows 10/11
- Synchronisation de l’OU des utilisateurs AVD
- Synchronisation de l’OU des machines hôtes AVD

Un environnement Azure Virtual Desktop avec deux machines virtuelles jointes à AD :

Notre environnement AVD en mode hybride est en place, commençons par un premier test.

Etape I – Test sans configuration SSO :

Avant d’aller plus loin, j’effectue déjà un premier test de connexion d’un utilisateur AVD depuis le portail web :

Une authentification AD est demandée lors de l’ouverture de la session Windows, c’est un comportement normal à ce stade car rien n’est configuré :

La commande dsregcmd /status sert à afficher l’état d’enregistrement de l’appareil auprès d’Entra ID et, concernant le PRT (Primary Refresh Token), elle fournit des informations de diagnostic sur sa présence et son état :

AzureAdPrt : YES / NO : Indique si un PRT est présent sur la machine pour l’utilisateur
AzureAdPrtUpdateTime : Date/heure du dernier rafraîchissement du PRT
AzureAdPrtExpiryTime : Date/heure d’expiration du PRT
AzureAdPrtAuthority : Autorité qui a émis le token (généralement login.microsoftonline.com).

Concernant la partie des tickets, voici ce que l’on peut aussi en déduire :

OnPremTgt : NO : cela indique si la session utilisateur courante ne possède pas Ticket Granting Ticket Kerberos émis par un contrôleur de domaine AD.
CloudTgt : YES : indique la présence d’un TGT Kerberos cloud, émis par Entra ID.

Comme on peut le constater, le PRT émis via Entra fonctionne bien pour les services Cloud, mais l’ouverture de session et l’accès à certaines ressources gérées par l’AD pourraient être restreints dans la situation actuelle.

Commençons étape par étape les changements pour arriver à une configuration complète.

Etape II – Configuration SSO du pool d’hotes AVD :

Sur le portail Azure, comme l’indique la documentation Microsoft, j’effectue la configuration SSO du host pool Azure Virtual Desktop afin d’activer “Microsoft Entra authentication for single sign-on” :

J’effectue un nouveau test avec mon utilisateur :

À ce stade, une authentification AD est encore demandée lors de l’ouverture de la session Windows :

Etape III – Création d’un objet serveur Kerberos :

Sur le serveur AD, comme l’indique la documentation Microsoft, je commence par installer le module AzureADHybridAuthenticationManagement :

# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Pour créer l’objet Kerberos Server nécessaire au Cloud Kerberos Trust, j’ai choisi l’exemple 4 de la documentation Microsoft :

Cet exemple exploite l’authentification moderne basée sur le User Principal Name (UPN) sans exiger de mot de passe AD explicite.
Il s’intègre parfaitement dans un environnement hybride sécurisé avec MFA et politiques d’accès conditionnel
Il évite les écueils des méthodes utilisant NTLM ou des identifiants AD en clair.

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Je lance donc le script à la suite du précédent, en prenant soin de remplacer l’UPN par un administrateur général ou hybride :

Je vérifie le serveur Microsoft Entra Kerberos nouvellement créé à l’aide de la commande suivante :

# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Enfin je constate la présence krbtgt_AzureAD utilisé par les DC pour signer les TGT Kerberos. Il s’agit d’une séparation cryptographique claire avec krbtgt dans le cadre de Kerberos émis depuis Entra :

J’effectue un nouveau test avec mon utilisateur :

Une fois le Cloud Kerberos Trust et l’authentification RDP Microsoft Entra activés, la seconde authentification Active Directory disparaît et est remplacée par un simple message de consentement Allow Remote Desktop connection :

Entra veut un consentement explicite de l’utilisateur. Ce message ne correspond pas à une authentification supplémentaire, mais à une demande de confiance entre l’utilisateur et le session host :

Si l’utilisateur clique sur Oui, ce consentement sera conservé 30 jours et ne pourra pas mémoriser plus de 15 hôtes.

L’Étape suivante consiste donc à supprimer définitivement le popup en déclarant les session hosts comme appareils de confiance dans Microsoft Entra ID.

Etape IV – Activation de l’authentification Microsoft Entra pour RDP :

Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise Azure Cloud Shell depuis le portail Azure :

J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte au permissions appropriées :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :

$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Je modifie la propriété isRemoteDesktopProtocolEnabledtrue sur True :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Afin de masquer la boîte de dialogue en configurant la liste des hôtes AVD approuvés, je créé un groupe dans Entra ID contenant les hôtes de sessions :

J’utilise une requête dynamique pour ajouter automatiquement mes prochains hôtes dans le groupe :

Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login.

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Enfin, je vérifie la bonne assignation du groupe :

J’effectue un nouveau test avec mon utilisateur :

Cette fois l’authentification passe sans encombre. Un TGT Kerberos AD DS (on-premises) est maintenant présent dans la session.

Cela permet d’observer que :

La machine est Hybrid Entra ID Joined
Le PRT est valide
Le Kerberos cloud fonctionne
Le Kerberos AD DS fonctionne
Les deux mondes coexistent simultanément dans la même session

Cette sortie correspond à un état hybride cohérent, où les mécanismes cloud et on-premises coexistent.

Pour finir, je vous propose de tester l’impact du Seamless SSO présent et configurable dans Entra Connect Sync.

Etape V – Activation du SSO d’Entra Connect Sync :

Pour cela, je décide de rajouter une troisième machine AVD :

Celle-ci est bien présente dans l’Active Directory :

Mais elle n’est pas présente dans Entra ID :

Pour ne pas perturber mes tests, je décide donc de bloquer la connexion aux deux autres VMs AVD :

J’effectue un test avec mon utilisateur :

Comme aucune configuration hybride n’est en place pour cette machine AVD, il n’y a pas de ticket TGT Kerberos émis par Entra ID, donc la seconde authentification AD est logique :

Une fois dans la session Windows, dsregcmd nous affiche les informations suivantes :

La machine est jointe uniquement à Active Directory on-premises
Elle n’est pas jointe à Entra ID
Elle n’est pas Hybrid Join
Aucun PRT
Aucun SSO cloud
Aucune authentification Entra ID
Une tentative d’Entra ID Join / Hybrid Join a eu lieu
- Elle a échoué côté Entra ID
- La machine AVD n’existe pas ou n’est pas reconnu dans le tenant

L’ouverture de la page d’authentification d’Office 365 dans Microsoft Edge me montre d’ailleurs aucune connexion SSO :

Je décide donc d’activer la fonctionnalité SSO dans Entra Connect Sync :

Une fois la configuration terminée, je constate la création de AZUREADSSOACC en tant que compte ordinateur créé dans Active Directory :

Ce dernier est créé automatiquement lors de l’activation de Seamless Single Sign-On (Seamless SSO) avec Entra ID. Le compte est utilisé par Entra ID pour :

établir une relation de confiance Kerberos avec l’AD on-prem
permettre le SSO sans saisie de mot de passe depuis des postes domain-joined vers Entra ID

J’effectue donc un nouveau test avec mon utilisateur :

Dans ce contexte, il est logique que l’authentification AD soit toujours demandée :

Une fois la session Windows ouverte, comme Seamless SSO fonctionne via l’adresse autologon.microsoftazuread-sso.com, je décide de la rajouter en tant qu’URL de l’Intranet local.

Pour cela, j’ouvre inetcpl.cpl :

Je clique sur Site dans Intranet local :

Je clique sur Avancée :

Je rajoute l’URL suivante :

https://autologon.microsoftazuread-sso.com

Toujours dans Intranet Local, je coche Connexion automatique avec le nom d’utilisateur et le mot de passe actuels :

Quelques minutes plus tard, j’ouvre Microsoft Edge et je constate l’authentification automatique de mon compte Cloud correspondant :

La présence du ticket HTTP/autologon.microsoftazuread-sso.com dans le cache Kerberos confirme que le mécanisme Seamless SSO est bien actif. Ce ticket, émis par le contrôleur de domaine à destination de Microsoft Entra ID, permet une authentification navigateur sans saisie de mot de passe.

klist

Il est important de noter que ce mécanisme n’est pas celui utilisé pour l’ouverture de session Windows dans Azure Virtual Desktop, qui repose sur un TGT Kerberos distinct délivré via Microsoft Entra Kerberos (krbtgt_AzureAD).

Conclusion

À travers ces différents tests et configurations, on constate que le Single Sign-On dans Azure Virtual Desktop hybride ne repose pas sur un mécanisme unique, mais sur une combinaison cohérente de plusieurs briques d’authentification.

Le PRT permet une authentification fluide aux services cloud, mais il ne suffit pas à lui seul pour ouvrir une session Windows dans un contexte Active Directory. C’est bien l’association du Hybrid Join, du Cloud Kerberos Trust et de l’authentification Microsoft Entra pour RDP qui permet d’aligner les mondes cloud et on-premises, et d’obtenir une expérience utilisateur réellement transparente dans AVD.

Comprendre ces mécanismes permet non seulement d’éviter des configurations incomplètes, mais aussi d’expliquer pourquoi certains scénarios fonctionnent “presque”, tout en continuant à demander une authentification supplémentaire.

Chalet Azure Romandie

Un an déjà… Quand on a lancé le Chalet Azure Romandie, on n’avait pas de roadmap parfaite, pas de machine bien huilée, juste une intuition : pour nous, il manquait en Suisse romande un lieu (physique et virtuel) pour parler écosystème Microsoft en français, entre passionnés, pros, étudiants, curieux. En cette fin 2025, après une année rythmée par les meetups, les échanges, les retours ultra positifs et quelques belles sueurs froides organisationnelles, j’avais envie de poser tout ça par écrit.

Ce billet, c’est un peu le journal de bord de cette première année, présenté un peu comme une FAQ : pourquoi ce chalet, comment ça a commencé, ce qu’on a appris… et où on veut aller en 2026.

Comment est née l’idée du Chalet Azure Romandie ?

À l’origine, on est trois : Seyfallah, Éric et moi. On se croise depuis un moment déjà autour de projets IT et d’autres communautés comme le Silicon Chalet, très active, très vivante, qui fait déjà beaucoup pour l’IT en Suisse romande.

On y participe sous plusieurs casquettes : parfois speakers, parfois organisateurs, parfois juste personnes dans le public avec un paquet de questions.

En enchaînant les événements, on s’est rendu compte d’une chose : il manquait un espace focalisé sur les technos Microsoft, avec une identité propre, un rythme, une ambiance à part, mais toujours dans l’esprit communauté et partage. L’idée du “Chalet Azure Romandie” est née de là :

garder l’ADN “chalet” (convivialité, proximité, réseau),
mais créer un nouveau groupe dédié au cloud Microsoft, à ses usages, ses architectes, ses développeurs, ses admins, ses décideurs.

Quand est-ce que ça a vraiment démarré ?

Si je devais mettre une date sur le début “officiel”, je dirais : la fin de la rentrée 2024. À ce moment-là, Microsoft prépare Ignite en novembre 2024, organisé à Chicago. De notre côté, Seyfallah et moi avons prévu d’y participer sur place.

C’est là que la discussion se cristallise : et si on profitait d’Ignite comme point de départ du Chalet Azure Romandie avec une idée toute simple :

“On est sur place, on a accès aux annonces, aux sessions, aux experts… Et si on ramenait tout ça en français, en direct, pour la Romandie ?”

On décide donc de lancer le premier “événement” du Chalet Azure Romandie sous forme de 2 lives à distance, démarrés via la page Meetup du Silicon Chalet.

Pourquoi le premier événement était un Ignite en “remote” depuis Chicago ?

Le plan initial était assez ambitieux (et naïf 😄) :

faire des lives depuis le salon,
animer des tables rondes,
permettre à la communauté romande de poser des questions en direct,
et tout ça dans un créneau de fin de journée pour les amis en Suisse et, plus largement, en francophonie.

Sur le papier, tout semblait gérable. En pratique, le jour J, on s’est retrouvés dans un salon avec près de 20 000 personnes, du bruit, des mouvements partout, une bande passante capricieuse… bref : impossible de tenir le format live comme prévu.

On a donc dû improviser :

on s’est éclatés en petits groupes,
on a enregistré des sessions à l’écart de la foule,
on a structuré des séquences d’échange plus calmes.

Mais le résultat en valait la peine :

deux sessions bien remplies,
environ une cinquantaine de personnes par session,
et surtout : la preuve que dès le départ, il y avait une vraie envie de contenu Microsoft en français.

Comment s’est organisée la première vraie année, en 2025 ?

En 2025, on a quitté le “mode online” pour entrer dans une vraie dynamique de meetups présentiels et réguliers. Concrètement, ça voulait dire :

trouver des salles,
trouver des sponsors,
trouver des speakers,
et répéter l’exercice 7 à 8 fois sur la première année.

On a organisé des événements à travers plusieurs villes de Suisse romande :

Genève,
Plan-les-Ouates,
Gland,
…

Côté sponsors, on a eu la chance d’être soutenus par :

Kyos,
Swissquote,
TD SYNNEX,
Ilem SA,
Squad,
Spaces,
Wavestone,
et un peu plus tard Microsoft directement sur certaines sessions.

Côté thématiques, on a couvert grâce à des speakers de qualité entre autres :

IA et Sécurité Microsoft,
Azure Landing Zones,
Dynamics 365,
AI Agents,
Azure Policy,
Fabric et l’intégration de Copilot,
et aussi des Hands-on pour mettre vraiment les mains dans le cambouis.

À quoi ressemble une soirée type au Chalet Azure Romandie ?

Rapidement, un format “signature” s’est dessiné. En général, on a :

1 à 2 talks maximum,
une présentation du sponsor,
un quiz lié au contenu des talks (parfois sérieux, parfois volontairement décalé),
des goodies pour les gagnants,
et surtout : un gros temps de networking.

Et ce dernier point est clé : on essaie de garder environ 50 % du temps de la soirée pour le réseau, les discussions, les pizzas, les bières et les échanges.

Pourquoi ? Parce que c’est là que :

les étudiants croisent les pros,
les personnes en recherche d’emploi discutent avec des gens qui recrutent ou qui connaissent des opportunités,
les admins, les architectes, les consultants partagent leurs galères, leurs bonnes pratiques, leurs idées.

À un moment, la magie opère : on n’a presque plus rien à faire. Les gens se parlent entre eux, échangent des cartes, des profils LinkedIn, des anecdotes de prod. Et c’est exactement ce qu’on voulait !

Comment avez-vous varié les formats et les speakers ?

On a essayé de ne jamais tomber dans la routine. Côté formats, on a alterné entre :

talks courts,
talks plus longs,
sessions très interactives,
labs individuels,
labs en équipe,
tables rondes.

Côté speakers, on a fait attention à plusieurs points :

inviter des personnes francophones,
mélanger speakers expérimentés et nouveaux venus,
mettre en avant les femmes dans l’IT.

Et en 2026, on veut pousser cet aspect encore plus loin : plus de diversité, plus de profils différents, plus de premières scènes.

Qu’avez-vous appris côté organisation (et galères) ?

Une année comme 2025, c’est une véritable école de l’organisation d’événements. Parmi les grandes leçons :

Anticiper beaucoup plus qu’on ne le pense : salles, matériel, restauration, communication, etc.
Structurer : qui fait quoi, quand, avec qui.
Et surtout… gérer le sujet qui fâche : les no-shows.

Les no-shows, c’est vraiment l’ennemi des meetups gratuits :

des personnes s’inscrivent,
ne viennent pas,
mais restent inscrites.

Résultat :

ça consomme de l’énergie côté orga,
ça démotive parfois les sponsors qui paient pour des places, de la nourriture, des boissons,
ça peut frustrer des personnes en liste d’attente qui, elles, seraient venues.

En 2026, on veut durcir un peu le jeu sur ce point : sans perdre l’esprit communautaire, rappeler que s’inscrire à un événement, c’est un engagement, surtout quand des sponsors financent et que des speakers parfois font plusieurs centaines de kilomètres pour venir.

Comment Microsoft est entré dans l’aventure ?

2025 a marqué un tournant : Microsoft Suisse a commencé à s’intéresser de près au Chalet Azure Romandie. Ce n’était pas “juste” un label, mais un vrai soutien humain et logistique :
des personnes comme Fabien, Dominique ou Philippe (et d’autres) ont joué un rôle important, soit en venant très tôt, soit en nous rejoignant en cours de route.

Concrètement, ça s’est traduit par :

des workshops avancés (IA, Fabric, Copilot, Power Platform…),
la présence d’experts Microsoft dans les sessions,
un dialogue plus constant entre la communauté et l’éditeur.

Pour nous, ça a été un vrai signal de confiance :

“Une petite communauté par la taille peut être grande par l’intérêt et l’engagement qu’elle génère autour des produits.”

Et Ignite 2025 dans tout ça ?

En 2025, Ignite se tenait à San Francisco. Cette fois-ci, on n’est pas repartis sur le même modèle que Chicago. On a opté pour quelque chose de plus posé :

une table ronde de débrief en fin d’année,
du partage d’expérience,
la présence d’experts,
et un événement de clôture qui a fait office de bilan 2025 et de tremplin pour 2026.

Pourquoi créer une page Meetup dédiée au Chalet Azure Romandie ?

Jusqu’à fin 2025, beaucoup de choses passaient encore par le Silicon Chalet. Pour clarifier l’identité, on a décidé de lancer une page Meetup propre au Chalet Azure Romandie avec pour objectifs :

rendre le groupe plus visible pour celles et ceux qui cherchent du contenu Microsoft,
faciliter la gestion des événements et des inscriptions,
et rejoindre officiellement le réseau des Azure Tech Groups dans le monde :

Aujourd’hui, le Chalet Azure Romandie fait donc partie de cette constellation de communautés Azure, chacune avec son identité locale mais un même objectif : partager, apprendre, connecter.

Et maintenant ? 2026, une année sous le signe de l’ouverture !

On a fêté les un an du Chalet Azure Romandie. L’énergie est là, la dynamique est très forte, et surtout : on ne manque ni d’idées, ni d’envie.

Pour 2026, nos principales intentions sont :

continuer à proposer un contenu varié (technique, décisionnel, retours d’expérience),
garder ce mix de formats (talks, labs, workshops, tables rondes),
renforcer la place des femmes dans les speakers,
consolider et élargir notre réseau de sponsors et de lieux,
et valider notre Call for Speakers pour toute l’année 2026.

D’ailleurs, l’appel à speakers pour 2026 est déjà lancé et les premiers créneaux se remplissent vite. Il y a encore de la place, et on veut :

des experts reconnus, ou des profils plus juniors qui veulent se lancer,
des sujets très techniques, ou pas,
tant que ça apporte quelque chose à la communauté Microsoft en Romandie.

Un mot pour finir ?

On est fiers du chemin parcouru en un an. On est très reconnaissants envers :

les sponsors qui nous ont fait confiance,
les speakers qui ont pris du temps pour préparer des sessions de qualité,
les participants qui sont venus, ont posé des questions, ont partagé,
les équipes de Microsoft qui ont rejoint l’initiative,
et bien sûr, le Silicon Chalet, qui reste un de nos points d’ancrage historiques.

On est aussi contents, très simplement, du travail que nous avons accompli tous les trois, et de l’énergie qu’on y a mise. Pour la suite, on a envie d’une chose :

que tu nous rejoignes, en tant que participant, speaker, sponsor, ou simple curieux.

Le Chalet Azure Romandie, c’est une aventure communautaire. On espère te voir avec nous en 2026 et au-delà.

Azure Disk Encryption / Encryption at Host / SSE

Le chiffrement des disques Azure existe depuis longtemps, mais il reste souvent mal compris : SSE, Encryption at Host, ADE… tout ne fonctionne pas au même niveau, et tout n’a pas le même impact. Je vous propose ici un tour d’horizon concret : explications, tests de performance et retour d’expérience sur la migration depuis Azure Disk Encryption.

Avant d’aller plus loin dans notre sujet, gardez toujours en tête que le processus de chiffrement concerne plusieurs états possibles de la donnée :

Dans cet article, nous aurons pour objectif de parler de la protection des données « au repos » sur les disques, afin qu’elles restent inexploitables en cas d’accès non autorisé, extraction de disque virtuel ou compromission de stockage.

Vue d’ensemble des options de chiffrement des disques de VM :

À ce jour, il existe plusieurs mécanismes de chiffrement disponibles pour vos disques de vos machines virtuelles Azure. Voici un premier récapitulatif des différents mécanismes de chiffrement disponibles sur Azure :

Azure Disk Storage Server-Side Encryption (SSE) : ce premier niveau de chiffrement est toujours activé pour les données au repos. Il chiffre automatiquement les données stockées sur les disques gérés Azure (disques OS et disques de données, à l’exception des disques temporaires et des caches disque).

Il est même possible de travailler avec d’autres clés que celles gérées par Microsoft :

Confidential disk encryption : ce mécanisme lie les clés de chiffrement des disques au TPM de la machine virtuelle et rend le contenu protégé du disque accessible uniquement à la machine virtuelle et ne permet pas que l’hyperviseur puisse déchiffrer les données.

Encryption at host : option au niveau de la machine virtuelle qui améliore le chiffrement côté serveur Azure Disk Storage afin de garantir que tous les disques temporaires et les caches disque sont chiffrés au repos et transférés chiffrés vers les clusters de stockage.

Azure Disk Encryption (ADE) : ce mécanisme chiffre le système d’exploitation et les disques de données des machines virtuelles Azure (VM) à l’intérieur de vos VM à l’aide de la fonctionnalité DM-Crypt de Linux ou de la fonctionnalité BitLocker de Windows. Azure Key Vault permet de contrôler et gérer les clés et les secrets de chiffrement de disque.

Quand ADE est activé, chaque disque de la machine virtuelle affiche alors cette information :

Une extension ADE est sur la machine virtuelle :

Est-ce que Azure Disk Encryption est déprécié ?

Azure Disk Encryption présente actuellement plusieurs limites importantes :

Le chiffrement réalisé directement dans l’OS peut entraîner une consommation CPU supplémentaire dans la VM.
ADE n’est pas compatible avec l’ensemble des types de disques ni toutes les distributions Linux.
Son intégration étroite avec l’OS et l’agent Azure le rend plus sensible et plus complexe à maintenir.

Partant de ce constat, je suppose que Microsoft a fait son choix et que ADE sera officiellement retiré le 15 septembre 2028, et propose même une stratégie de migration vers Encryption at host :

Azure Disk Encryption pour les machines virtuelles et les Virtual Machine Scale Sets sera mis hors service le 15 septembre 2028. Les nouveaux clients doivent utiliser le chiffrement sur l’hôte pour toutes les nouvelles machines virtuelles.

Les clients existants doivent planifier la migration des machines virtuelles ADE actuelles vers le chiffrement sur l’hôte avant la date de mise hors service pour éviter toute interruption de service.

Microsoft Learn

Qu’est-ce que Encryption at host ?

Encryption at Host est un mécanisme de chiffrement fourni par la plateforme Microsoft Azure permettant de chiffrer les disques de machines virtuelles au niveau de l’hôte (l’hyperviseur), avant que les données ne soient écrites sur le stockage.

Plutôt que de chiffrer les disques directement dans la machine virtuelle via BitLocker ou DM-Crypt, ce mode déplace le chiffrement sur l’hyperviseur Azure lui-même.

Cela permet de chiffrer l’ensemble des composants associés à la VM (disques OS, disques de données, disques temporaires et cache) tout en évitant la charge CPU dans la VM :

Quelles sont les restrictions liées à cette migration ?

Microsoft rappelle ici les différents points et limitations à prendre lorsque vous souhaitez migrer d’Azure Disk Encryption à Encryption at host, Voici quelques-unes d’entre elles :

Temps d’arrêt requis : le processus de migration nécessite un temps d’arrêt de machine virtuelle pour les opérations de disque et la recréation des machines virtuelles.
Aucune migration sur place : vous ne pouvez pas convertir directement des disques chiffrés par ADE en chiffrement sur l’hôte. La migration nécessite la création de disques et de machines virtuelles.
Machines virtuelles jointes à un domaine : si vos machines virtuelles font partie d’un domaine Active Directory, d’autres étapes sont requises :
- La machine virtuelle d’origine doit être supprimée du domaine avant la suppression
- Après avoir créé la machine virtuelle, elle doit être jointe au domaine
- Pour les machines virtuelles Linux, la jonction de domaine peut être effectuée à l’aide d’extensions Azure AD

Commençons par un rappel des prérequis.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les différentes méthodes de chiffrements, il faut disposer de :

Un tenant Microsoft
Une souscription Azure valide

La suite se passera par la création d’une machine virtuelle depuis le portail Azure.

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

Je commence par créer une machine virtuelle Windows Server 2025 avec 32 cœurs, afin d’éviter toute limitation liée aux performances de la VM pendant les tests :

Une fois la VM créée, j’ajoute un disque de données supplémentaire en plus du disque système. À ce stade, les deux disques utilisent le chiffrement au repos par défaut de type SSE, appliqué automatiquement par la plateforme :

Sur l’écran de configuration des disques, des Paramètres supplémentaires sont disponibles :

Je constate que le chiffrement au niveau de l’hôte n’est pas activé à ce stade. La VM utilise uniquement le chiffrement SSE, sans mécanisme supplémentaire de type ADE ou Encryption at Host :

Je me connecte à la machine virtuelle via Azure Bastion :

Je vérifie que le service BDESVC associé à BitLocker n’est pas actif et qu’aucun chiffrement au niveau du système d’exploitation n’a été configuré :

Get-Service BDESVC
manage-bde -status

Cela confirme que seul le chiffrement SSE au niveau du stockage est en place, et qu’aucune couche de chiffrement, au niveau de la machine virtuelle ou de l’hyperviseur est activée :

Afin d’étoffer mon analyse, il est intéressant de comparer les performances (IOPS, Débits et CPU) entre plusieurs types de chiffrement de stockage. Pour cela j’utiliserai l’outil de mesure Diskspd et les métriques disponibles sur le portail Azure.

Etape II – Installation de l’outil de mesure Diskspd :

L’installation de Diskspd se fait directement sur la machine virtuelle à tester :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Commençons maintenant les tests avec différentes méthodes de chiffrement, en commençant d’ailleurs avec uniquement SSE.

Etape III – Tests de performance avec le chiffrement au repos SSE :

Pour réaliser des tests avec Diskspd, et pour obtenir un maximum d’IOPS / débit, je lance les deux commandes PowerShell suivante :

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > IOPS-PremiumSSDv2-0encryption.txt

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > Throughput-PremiumSSDv2-0encryption.txt

J’ouvre Task Manager afin d’observer en temps réel l’activité du disque :

Je surveille l’utilisation CPU de la VM depuis le portail Azure :

Une fois les deux tests terminés, les fichiers sont générés dans le dossier courant :

le premier fichier TXT généré est pour consigner les IOPS :

Le second fichier TXT est généré pour consigner les débits :

Continuons les tests de performances avec Encryption at host d’activé.

Etape IV – Tests de performance avec Encryption at host :

Pour activer Encryption at host, il est d’abord nécessaire d’éteindre la machine virtuelle :

Sur l’écran de configuration des disques, je clique ici, j’active Encryption at host, puis je sauvegarde :

Une fois la modification appliquée, je redémarre la machine virtuelle :

L’activation de la fonctionnalité Encryption at host est aussi visible juste ici :

Je me reconnecte à la VM via Azure Bastion, puis je relance une seconde salve de tests avec Diskspd :

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > IOPS-PremiumSSDv2-encryptionathost.txt

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > Throughput-PremiumSSDv2-encryptionathost.txt

J’ouvre Task Manager afin d’observer en temps réel l’activité du disque :

Je surveille l’utilisation CPU de la VM depuis le portail Azure :

Une fois les deux tests terminés, les fichiers sont générés dans le dossier courant :

le premier fichier TXT généré est pour consigner les résultats IOPS :

Le second fichier TXT est généré pour consigner les résultats débits :

Continuons les tests de performances avec cette fois Azure Disk Encryption activé.

Etape V – Tests de performance avec Azure Disk Encryption :

Pour configurer Azure Disk Encryption, il est nécessaire de commencer par créer un Azure KeyVault :

Sur l’écran de configuration des disques, j’effectue les actions suivantes :

J’éteins la machine virtuelle,
Je désactive Encryption at host,
Je redémarre la machine virtuelle,
J’active Azure Disk Encryption avec mon Azure Key Vault (4096),
Je sauvegarde la configuration

Azure lance alors le déploiement automatique d’ADE :

Une extension s’installe alors sur la machine virtuelle :

Je me reconnecte, puis je vérifie que le service BDESVC associé à BitLocker démarre :

Get-Service BDESVC
manage-bde -status

Je constate le démarrage du chiffrement pour les deux disques de ma machine virtuelle :

Quelques minutes plus tard, le chiffrement est terminé :

Je constate l’apparition de la mention ADE sur le disque OS :

Je m’y reconnecte via Azure Bastion, puis relance une troisième salve de tests avec Diskspd :

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > IOPS-PremiumSSDv2-ADEencryption.txt

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > Throughput-PremiumSSDv2-ADEencryption.txt

J’ouvre Task Manager afin d’observer en temps réel l’activité du disque :

Je surveille l’utilisation CPU de la VM depuis le portail Azure :

Une fois les deux tests terminés, les fichiers sont générés dans le dossier courant :

le premier fichier TXT généré est pour consigner les résultats IOPS :

Le second fichier TXT est généré pour consigner les résultats débits :

Etape VI – Comparaison des performances de chiffrement :

Les mesures montrent que les performances des disques restent globalement équivalentes entre les trois modes, mais que l’usage CPU varie nettement, notamment lorsque le chiffrement est exécuté dans le système d’exploitation comme avec Azure Disk Encryption :

Mode de chiffrement	CPU moyen (%)
SSE (Storage Service Encryption)	1.5 %
Encryption at Host	1.0 %
ADE (Azure Disk Encryption)	2.8 %

SSE et Encryption at Host ont un impact CPU faible et comparable.

ADE présente une charge CPU sensiblement supérieure, liée au chiffrement effectué par BitLocker dans la VM, ce qui correspond à l’architecture même de ce mode.

La surcharge induite par ADE reste faible, mais l’hétérogénéité des latences confirme qu’il reste plus sensible que les modes opérés directement par la plateforme.

Etape VII – Migration d’ADE vers Encryption at host :

La migration depuis ADE vers Encryption at host sur une machine virtuelle n’est pas possible pour des raisons techniques. Voici ce qui se produit lorsqu’on tente d’activer Encryption at Host sur une VM, qui était auparavant configurée avec Azure Disk Encryption :

Microsoft liste donc ici les différentes étapes nécessaires pour réaliser cette migration. Nous allons commencer par désactiver Azure Disk Encryption.

Sur l’écran de configuration des disques, je désactive Azure Disk Encryption, puis je sauvegarde :

Une tâche Azure se déclenche, j’attends quelques minutes que celle-ci se termine :

Je me reconnecte à la machine via Azure Bastion, puis je vérifie que le service BDESVC est toujours activé et qu’une phase de déchiffrement vient de démarrer :

Get-Service BDESVC
manage-bde -status

Quelques minutes plus tard, le déchiffrement est entièrement terminé :

Malgré cela, l’extension ADE est toujours présente sur ma machine virtuelle :

Je la désinstalle depuis le portail Azure :

Quelques minutes plus tard, la notification Azure suivante apparaît :

Lancez la commande PowerShell suivante depuis Azure Cloud Shell pour chacun des disques afin de créer des disques qui ne portent pas sur les métadonnées de chiffrement ADE :

Attention : Ce script ne fonctionne pas sur les disques Premium SSDv2 et Ultra.

# Get source disk information
$sourceDisk = Get-AzDisk -ResourceGroupName "MyResourceGroup" -DiskName "MySourceDisk"

# Create a new empty target disk
# For Windows OS disks
$diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512) -OsType Windows -HyperVGeneration "V2"

# For Linux OS disks (if not ADE-encrypted)
# $diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload #   -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512) -OsType Linux #   -HyperVGeneration "V2"

# For data disks (no OS type needed)
# $diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload #   -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512)

$targetDisk = New-AzDisk -ResourceGroupName "MyResourceGroup" -DiskName "MyTargetDisk" -Disk $diskConfig

# Generate SAS URIs and copy the data
# Get SAS URIs for both disks
$sourceSAS = Grant-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $sourceDisk.Name -Access Read -DurationInSecond 7200
$targetSAS = Grant-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $targetDisk.Name -Access Write -DurationInSecond 7200

# Copy the disk data using AzCopy
azcopy copy $sourceSAS.AccessSAS $targetSAS.AccessSAS --blob-type PageBlob

# Revoke SAS access when complete
Revoke-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $sourceDisk.Name
Revoke-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $targetDisk.Name

Pour mon disque data configuré en premium SSDv2, je crée un snapshot manuellement :

Depuis le nouveau disque OS créé via le script plus haut, je relance la création d’une nouvelle machine virtuelle :

Je configure cette nouvelle machine virtuelle, en y intégrant le disque de data issu du snapshot, puis je lance sa création :

Une fois la machine virtuelle créée, j’éteins celle-ci, puis j’active Encryption at host dans les paramétrages des disques :

Je redémarre la machine virtuelle, puis je constate dans l’affichage du diagnostic le bon démarrage de celle-ci :

Conclusion

Au final, SSE et Encryption at Host couvrent aujourd’hui l’essentiel des besoins, avec un impact quasi nul sur la VM et une gestion simplifiée. SSE reste la base, toujours activée, tandis qu’Encryption at Host ajoute une couche complète de protection sans coût CPU notable.

ADE fonctionne encore, mais son intégration à l’OS et sa charge CPU supplémentaire en font une solution plus lourde à exploiter. Avec les résultats obtenus et sa dépréciation annoncée, il devient clairement le mécanisme à éviter pour les nouvelles machines virtuelles.

SSE : excellente base, impact minimal, tout est géré par la plateforme.

Encryption at Host : même niveau de performance que SSE, avec la garantie que toutes les couches (OS, data, cache, disque temporaire) sont chiffrées directement par l’hyperviseur.

ADE : Performances disque similaires, mais CPU plus élevé, dû au chiffrement dans la VM. Cela confirme pourquoi ce mode est progressivement remplacé par les autres mécanismes gérés par la plateforme.

Pour la majorité des workloads, Encryption at Host apparaît désormais comme l’option la plus propre, la plus simple et la plus pérenne.

Testez Microsoft Foundry

Bienvenue dans ce lab pratique consacré à Microsoft Foundry, la plateforme unifiée qui permet d’explorer, tester et déployer des expériences d’intelligence artificielle au sein de l’écosystème Azure. Cet article retrace pas à pas les différentes étapes du lab afin de permettre à chacun de revivre l’expérience ou de la reproduire en autonomie.

Lors du Chalet Azure Romandie du 27 novembre 2025, les participants ont pu découvrir concrètement comment manipuler des modèles avancés comme gpt-4o et Sora, créer leurs propres agents, générer des vidéos IA, ajouter des filtres de sécurité, traduire des documents, ou encore produire un avatar animé.

Voici donc les 5 défis que vous pouvez également essayer :

Etape 0 – Connexion à Microsoft Foundry :

Pour réaliser cet exercice sur Microsoft 365 Archive, il vous faudra disposer d’une souscription Azure valide.

Ouvrez un navigateur web, puis saisissez l’URL du portail Azure AI Foundry (nouvellement Microsoft Foundry) :

Authentifiez-vous avec un e-mail professionnel ou personnel :

Une fois authentifiée, conservez l’ancienne présentation du portail de Microsoft Foundry, appelée encore Azure AI Foundry, afin de suivre les consignes ci-dessous plus facilement :

Commençons le premier défi par le déploiement d’un agent.

Défi I – Création d’un Agent Smith :

Nous allons déployer un agent qui s’appuiera sur le modèle gpt-4o et répondra aux différentes questions du défi.

Pour cela, cliquez-ici pour créer votre agent :

Mais comme aucun projet IA n’est encore présent, nous allons commencer par la création de celui-ici. Pour cela, renseignez les informations pour la création de votre nouveau projet IA, puis lancez sa création :

Dans le champ Projet, saisissez projet-agent
Développez options avancées
Choisissez la souscription Azure disponible
Donnez un nom unique à votre ressource Azure AI Foundry
Nommez rg-chalet-romandie le nom de votre groupe de ressource
Vérifiez que la région Azure East US 2 est bien sélectionnée

Attendez environ 2 à 3 minutes pour la fin de la création des ressources Azure :

Une fois le déploiement terminé, cliquez sur le menu Playgrounds afin de commencer par le déploiement d’un premier modèle IA, recherchez dans la liste le modèle gpt-4o, puis cliquez sur le bouton Confirmer :

Conservez les options de base de votre modèle, puis cliquez sur le bouton Déployer :

Une fois le modèle IA déployé, retournez dans le menu Playgrounds afin de lancer le prompt suivant sur le nouvel agent, automatiquement créé et lié à votre modèle :

Générer une blague sur les informaticiens

L’erreur suivante peut apparaître. Elle indique que les ressources IA ne sont pas encore entièrement accessibles :

Après plusieurs minutes et plusieurs essais, vous devriez obtenir une réponse dans le chat de la part de votre agent IA :

Votre défi est réussi, vous pouvez le faire valider, puis passez au défit suivant.

Défi II – Génération d’une vidéo IA :

Imaginez pouvoir créer des scènes vidéo réalistes, des animations et des effets spéciaux, à partir d’instructions textuelles simples et précises. Foundry vous permet de réaliser cette prouesse à l’aide du modèle Sora d’OpenAI.

La génération de vidéos dans ce cas est un processus asynchrone. Vous créez une demande de travail avec vos spécifications d’invite (ou prompt en anglais) de texte et de format vidéo, et le modèle traite la demande en arrière-plan.

Une fois terminé, récupérez la vidéo générée via une URL de téléchargement.

Cliquez sur le menu à gauche Playgrounds, puis le menu suivant afin de tester la génération de vidéos par l’IA :

Cliquez ici pour déployer un nouveau modèle IA destiné à la génération de la vidéo :

Choisissez le modèle Sora dans la liste, puis cliquez sur Confirmer :

Conservez les options de base, puis cliquez sur le bouton Déployer :

Une fois le modèle Sora déployé, retournez dans le menu Playgrounds afin de lancer le prompt de génération de la vidéo :

Sélectionnez la résolution 720p, une durée de 10 secondes, saisissez votre prompt qui générera une vidéo époustouflante, puis cliquez sur le bouton Générer.

Attendez quelques instants avant de pouvoir constater le résultat :

Après quelques instants, visionnez le résultat généré par Sora :

Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.

Défi III – Filtrage IA de contenu :

Microsoft Foundry embarque en standard les composants Azure AI Content Safety pour filtrer les contenus répréhensibles générés ou traités (détection de langage toxique, données personnelles partagées, etc…).

Nous allons créer un filtre et une liste de blocage basés sur le mot AWS. Nous allons dans un premier temps créer une liste de blocage :

Saisissez un nom représentant la liste, blocklistaws, puis cliquez sur le bouton suivant pour créer celle-ci :

Ajoutez un nouveau terme :

Saisissez le terme AWS, puis ajoutez-le :

Nous allons maintenant créer notre propre filtre de contenu et l’associer à notre liste de blocage. Pour cela, cliquez sur le bouton ci-dessous pour créer un filtre de contenu :

Saisissez un nom représentant le filtre, filtrereomandie, puis cliquez sur le bouton Suivant :

Dans l’étape Filtre d’entrée, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :

Dans l’étape Filtre de sortie, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :

Sélectionnez le modèle qui recevra ce filtre de contenu personnalisé, dans notre cas gpt-4o :

Confirmez le remplacement du filtrage de contenu de page par le nouveau :

Lancez la création du filtrage IA :

Retournez dans Playgrounds, puis cliquez sur Chat playground :

Collez le prompt suivant dans le chat :

Comment utiliser AWS ?

Un retour négatif de la part d’Azure IA Foundry, et invoquant blocklistaws, devrait apparaître. Continuez avec le prompt suivant :

Comment me faire très mal au bras ?

Un retour négatif de la part d’Azure IA Foundry, et invoquant Self-harm, devrait apparaître.

Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.

Défi IV – Traduction IA de documents :

La traduction automatique est l’un des domaines historiques de l’IA de Microsoft. L’entreprise propose un service de traduction basé sur des réseaux de neurones, connu sous le nom d’Azure AI Translator, capable de traduire instantanément du texte ou des documents entiers d’une langue à une autre.

Cliquez sur le menu suivant afin de générer une traduction de texte :

Cliquez sur Text translation :

Collez le texte suivant, choisissez le français comme langue de destination, puis lancez la traduction :

好⼀朵美丽的茉莉花
好⼀朵美丽的茉莉花
芬芳美丽满枝桠
又⾹又⽩⼈⼈夸
让我来将你摘下
送给别⼈家
茉莉花呀茉莉花

Constatez le résultat traduit :

Passons maintenant au dernier défi IA.

Défi V – Avatar IA :

Azure Speech permet en résumé de tester et prototyper rapidement des fonctionnalités de reconnaissance vocale, conversion texte-vers-voix, traduction audio, etc., sans avoir à tout coder ou déployer de façon complète.

Cliquez sur le menu suivant afin de générer un avatar :

Choisissez le menu Text to speech avatar, puis cliquez sur Lisa parmi la liste des avatars disponibles :

Définissez la langue française, la voix de Vivienne, collez le texte ci-dessous, puis lancez la génération de la vidéo :

Romandie un jour, Romandie toujours.

Attendez quelques secondes la fin de la génération de la vidéo :

Une fois la vidéo générée, lancez-là pour en vérifier le contenu :

Une fois tous les défis terminés :

Conclusion

Ce parcours à travers Microsoft Foundry met en lumière la richesse des outils IA disponibles aujourd’hui : agents personnalisés, génération multimédia, filtrage de contenu, traduction, ou encore avatars vocaux.

Chaque défi illustre la maturité croissante de l’écosystème et la facilité avec laquelle il devient possible d’expérimenter, prototyper et imaginer de nouvelles solutions basées sur l’IA.

Que ce lab inspire de futurs projets et continue d’alimenter la dynamique d’innovation au sein de la communauté !

FSLogix pour Entra ID !

Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.

Lors du premier jour de Microsoft Ignite 2025 à San Francisco, Microsoft a dévoilé la préversion publique d’une fonctionnalité demandée depuis longtemps : la prise en charge des profils FSLogix stockés sur un compte Azure Files directement joint à Entra ID. Une étape majeure dans la modernisation de l’environnement AVD.

Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.

Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.

Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :

Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.

Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :

Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.

Microsoft Techcommunity

Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :

Qu’est-ce qu’une identité cloud-only ?

Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.

Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?

Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».

Que change concrètement pour un architecte cloud ou un administrateur ?

Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.

Plusieurs vidéos sont également disponible pour vous aider à la tâche :

Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :

Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.

L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :

Etape 0 – Rappel des prérequis :

Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :

Un abonnement Azure valide
Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.

Etape I – Préparation de l’environnement :

Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :

Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :

Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :

Activation de l’identité Microsoft Entra directement sur le compte de stockage :

Activation du support Microsoft Entra Kerberos pour gérer l’authentification :

Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :

Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :

Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :

Attribution du consentement administrateur global pour autoriser l’application

Validation de l’autorisation accordée à l’application d’entreprise :

Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :

Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :

Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :

Activation du Single Sign-On directement dans les propriétés RDP :

Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :


reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f

Confirmation que la clé de registre est bien apparue :

Exécution du second script PowerShell via Run Command pour activer le chargement des clés d’identités pour la gestion FSLogix :

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

Vérification de la création de la clé de registre attendue dans Windows :

Application de la configuration complète FSLogix via les différentes clés de registre :

reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryInterval /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ProfileType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachIntervalSeconds /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\cloudonlysa.file.core.windows.net\profiles" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d "VHDX" /f

Vérification de la création des clés de registre attendues pour FSLogix :

Alternative via Intune pour gérer ces mêmes paramètres sans script :

Redémarrage des machines virtuelles du host pool pour appliquer la configuration :

Etape II – Test de connexion AVD :

Attente du retour en ligne des machines dans l’environnement AVD :

Activation du mode de drainage sur la seconde machine pour préparer les tests :

Connexion avec l’utilisateur de test pour valider le fonctionnement :

Observation du démarrage du service FSLogix App Services à l’ouverture de session :

Création du dossier de profil FSLogix directement dans le file share :

Présence du fichier VHDx correspondant au profil utilisateur :

Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :

Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :

Inversion du mode de drainage sur les deux machines AVD :

Reconnexion avec l’utilisateur de test pour valider la bascule du profil :

Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :

Vérification que la permission générée pour l’utilisateur de test est bien présente :

Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.

Etape III – Configurations des permissions NTFS Access Control Lists :

Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :

Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :

Comme l’indique la documentation Microsoft ci-dessous, tout ne semble pas encore au point :

Travis Roberts rencontre d’ailleurs le même souci que moi :

Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :

Le bouton Manage access est alors visible juste ici :

Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :

L’affichage des permissions NTFS Access Control Lists configurées par défaut :

Les permissions pour FSLogix doivent alors être reconfigurées comme telles :

Cela donne ceci sur le partage de fichier FSLogix :

Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.

Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.

Etape IV – Tests de performances :

J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID
Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput

Pour réaliser les mesures, nous utiliserons l’outil Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
- IOPS
- Débit
Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID :

Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :

Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :

Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-PSSDv2.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-PSSDv2.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

-d900 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b8K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
-c50G : taille du fichier 50 GB
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-AvecEntra.txt : fichier de sortie des résultats

Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :

Scenario	IOPS	Bandwidth MB/s
Avec Entra ID	12,446.88	299.95
Sans Entra ID	15,032.54	341.17
Premium SSD v2	20,378.31	1,167.25

Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.

La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.

Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.

Conclusion

Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.

Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.

Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft Entra.

Configurez le presse-papier dans AVD/W365

Depuis la mi-2025, Microsoft renforce progressivement les paramètres de sécurité par défaut dans ses environnements Windows 365 et Azure Virtual Desktop (AVD). L’un des changements les plus visibles pour les administrateurs et utilisateurs concerne la redirection du presse-papiers (clipboard), désormais désactivée par défaut dans les nouvelles configurations.

Cette évolution, alignée avec la Microsoft Secure Future Initiative (SFI), vise à limiter les risques d’exfiltration de données et à uniformiser la posture de sécurité entre Windows 365 et AVD.
Mais concrètement, comment ce changement s’applique-t-il ? Quels paramètres contrôlent réellement le comportement du presse-papiers ? Et comment vérifier la configuration effective entre les deux couches (Propriétés RDP et stratégies GPO/Intune) ?

Dans mon précédent article, publié fin 2024, je présentais les options de durcissement du presse-papiers AVD via Intune et les propriétés RDP. Depuis mi-2025, Microsoft est passé d’une approche configurable à une approche imposée par défaut : les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désormais désactivées nativement dans Windows 365 et AVD. Ce qui était un bon réflexe de sécurité devient aujourd’hui la norme.

Une excellente référence pour cette mise à jour est l’article de Dieter Kempeneers, Configure Advanced Clipboard AND Drive Redirection for AVD and Windows 365, dans lequel il détaille non seulement la désactivation par défaut des redirections (presse-papiers, lecteurs, imprimantes) sur les nouveaux hôtes AVD et les Cloud PC Windows 365, mais aussi la façon d’en réactiver certains comportements de façon granulaire.

Dans ce nouvel article, je décortique la logique de redirection RDP, les nouvelles valeurs par défaut introduites par Microsoft, et surtout, les implications pratiques pour vos déploiements et modèles AVD / Windows 365.

Depuis quand Microsoft a changé la règle du presse-papier pour Windows 365 ?

Microsoft a introduit de nouveaux paramètres de sécurité par défaut pour Windows 365 Cloud PCs le 18 juin 2025 :

Windows 365 renforce la sécurité des PC cloud en désactivant par défaut les redirections du presse-papiers, des lecteurs, des périphériques USB et des imprimantes pour tous les PC cloud nouvellement provisionnés et reprovisionnés. Cette modification minimise le risque d’exfiltration de données et d’injection de logiciels malveillants, ce qui offre une expérience plus sécurisée et s’aligne sur le principe de l’initiative Microsoft Secure Future Initiative (SFI) visant à activer et à appliquer par défaut les protections de sécurité.

Microsoft

Un message sous forme de bandeau est bien visible lors de la création d’une police de provisionnement Windows 365 :

D’ailleurs, la police de configuration de sécurité appelée Windows 365 Security Baseline et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc, de facto, le transfert de fichiers :

Est-ce que cette restriction concerne aussi Azure Virtual Desktop ?

Oui, les nouveaux pools d’hôtes Azure Virtual Desktop sont aussi concernés par ce renforcement :

Cette modification des paramètres par défaut de redirection sera bientôt effective. Afin d’aider les administrateurs informatiques à s’y préparer, une bannière pouvant être ignorée s’affichera sur la page d’accueil « Créer un pool d’hôtes » du portail Azure. Cette bannière informera les administrateurs des nouveaux paramètres par défaut pour les nouveaux pools d’hôtes et fournira des liens vers la documentation expliquant comment les remplacer en modifiant les propriétés RDP du pool d’hôtes une fois celui-ci créé.

Microsoft

Remarque : pour les pools d’hôtes existants, aucune modification ne sera apportée à la configuration de redirection en votre nom. Cependant, nous vous recommandons de renforcer la sécurité des paramètres en désactivant les redirections qui ne sont pas nécessaires. Pour effectuer ces modifications, consultez la section relative à la redirection des appareils dans la documentation sur les propriétés RDP.

Microsoft

Voici la nouvelle option de configuration RDP mise par défaut, et visible dans les propriétés du pool d’hôtes AVD :

D’ailleurs, la police de configuration de sécurité appelée Security Baseline for Windows 10 and later et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc de facto le transfert de fichiers :

Qu’est-ce que cela change pour mes futures créations AVD et Windows 365 ?

Pour AVD : pour tout nouveau pool d’hôtes créé après la date de changement, les redirections de presse-papier, lecteurs, USB et imprimantes seront désactivées par défaut.
Pour Windows 365 : idem pour tous les Cloud PCs nouvellement provisionnés ou reprovisionnés : les mêmes redirections sont désactivées par défaut.

Impact : vos modèles, templates ou polices qui s’appuyaient sur ces redirections devront être revus. Si vous aviez des scénarios utilisateur où l’on transférait facilement du contenu local vers le poste cloud, il faudra anticiper ce nouveau comportement.

Comment identifier la configuration actuelle des postes ?

Le comportement dépend de deux couches complémentaires. Le serveur RDP n’impose pas unilatéralement la redirection : il la négocie avec le client en fonction de ces deux niveaux :

Le client (.rdp / Propriétés RDP AVD) détermine ce qui est demandé ou refusé pour la session. Exemple : redirectclipboard:i:0 dans les propriétés RDP d’un host pool.
Le serveur (Policies / GPO / Intune) définit ce qui est autorisé ou interdit de manière globale sur la machine. Exemple : fDisableClipboard dans le registre des stratégies.

Première couche : configuration client / RDP Properties :

Ces valeurs correspondent à la configuration du service RDP. Elles sont mises à jour lorsque tu modifies les RDP Properties d’un host pool dans AVD, par exemple :

Set-AzWvdHostPool -Name "pool1" -CustomRdpProperty "redirectclipboard:i:0"

Lorsqu’une session RDP s’ouvre :

Le Remote Desktop Agent (ou rdpinit.exe) initialise la session avec les paramètres .rdp transmis par le broker AVD.
Ces paramètres ne sont pas écrits dans le registre immédiatement.

Seconde couche : configuration serveur / Polices :

Pour consulter les paramètres imposés par une stratégie locale, GPO ou Intune :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Ces valeurs représentent la couche de gouvernance :

Elles sont prioritaires sur les paramètres locaux et sont appliquées au démarrage du service TermService.
Elles déterminent ce qui est autorisé ou interdit globalement sur la machine, indépendamment des paramètres envoyés par le .rdp.

La configuration peut se faire très facilement depuis une police de configuration Intune :

Interaction entre les deux couches :

Le comportement effectif correspond toujours à la configuration la plus restrictive :

Policy (serveur)	RDP Property (client/session)	Résultat final
Autorise	Interdit (redirectclipboard:i:0)	❌ Redirection désactivée
Interdit	Autorise (redirectclipboard:i:1)	❌ Redirection désactivée
Autorise	Autorise	✅ Redirection active

Résultats de tests : comportement réel du presse-papiers RDP

Pour mieux comprendre ces nouveaux paramètres de redirection du presse-papiers, j’ai réalisé une série de tests sur plusieurs configurations RDP (AVD et Windows 365).

Le but était de vérifier quels types de données (texte, image, HTML, binaire, etc.) pouvaient être copiés dans chaque sens selon les paramètres du serveur et du client.

Les couches de configuration RDP :

Les deux couches peuvent définir différentes valeurs, mais elles ne s’écrasent pas : le moteur RDP évalue d’abord la police, puis les propriétés RDP :

Couche	Rôle
1. Configuration RDP	Paramètres appliqués au niveau du service RDP local. C’est ce qu’utilise la session à l’exécution. Modifié par les propriétés RDP d’un host pool AVD.
2. Policy configuration (GPO / Intune)	Paramètres de gouvernance. Écrits par une stratégie (GPO/MDM) et prioritaires sur la configuration locale.

Niveaux de granularité (SCClipLevel / CSClipLevel) :

Les valeurs SCClipLevel et CSClipLevel permettent aussi d’affiner très précisément la redirection dans chaque sens :

SC (Server → Client) : copier du cloud vers le poste local.
CS (Client → Server) : copier du poste local vers le cloud.

Niveau	Formats autorisés	Exemple
`0`	Aucune redirection	Blocage total
`1`	Texte brut uniquement	Copier/coller texte simple
`2`	Texte brut + images	Exemple : capture d’écran
`3`	Texte brut + images + RTF	Texte formaté (Word, Outlook)
`4`	+ HTML	Copier/coller depuis un navigateur

Comment cela se voit pour Windows 365 ?

Voici un récapitulatif des différents tests effectués, en modifiant les propriétés pour AVD ou Windows 365 :

Et voici le détail de ces tests avec les configurations Intune appliquées pour impacter le registre Windows :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Test A – Clipboard redirection isn’t available : Le presse-papiers est complètement désactivé côté session RDP. Aucun copier/coller ne fonctionne dans aucun sens :

Test B – Clipboard redirection is available : Le presse-papiers est activé côté session RDP. Le copier/coller fonctionne dans les deux sens :

Test C – Do not allow Clipboard redirection Disabled (fDisableClip=0). Le comportement dépend donc de la configuration du fichier .rdp, qui est activé. Le copier/coller fonctionne dans les deux sens :

Test D – Do not allow Clipboard redirection Enabled (fDisableClip=1). Blocage complet du copier/coller, même si le .rdp autorise la redirection :

Test E – Do not allow Clipboard redirection Disabled (fDisableClip=0), comme la configuration du fichier .rdp, qui est activé. Disable clipboard transfers from session host to client (SCClipLevel=0) et inversement (CSClipLevel=0). Aucun copier-coller descendant ou montant n’est possible :

Test F – Allow plain text : Autorise uniquement le texte brut (SCClipLevel=1 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement, et pas d’images ni de formats enrichis :

Test G – Allow plain text and image : Autorise texte brut + images (SCClipLevel=2 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test H – Ajoute le support du Rich Text (SCClipLevel=3 / CSClipLevel=0 / fDisableClip=0). Le copier/coller de texte et d’images fonctionne, mais pas HTML ni formats binaires. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test I – Allow plain text, images, Rich Text Format and HTML. Ajoute HTML (SCClipLevel=4 / CSClipLevel=0 / fDisableClip=0). Formats binaires toujours bloqués. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test J – Allow plain text, images, Rich Text Format, HTML and Binary. Autorise tous les formats, y compris binaires (CSClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du host vers client :

Test K – Allow plain text (inverse direction). Même logique que F mais appliquée au client → host (SCClipLevel=0 / CSClipLevel=1 / fDisableClip=0). Seul le texte brut passe du poste local vers le cloud :

Test L – Allow plain text and images (inverse direction). Autorise texte et images du client vers la session (SCClipLevel=0 / CSClipLevel=2 / fDisableClip=0) :

Test M – Allow plain text, images and Rich Text Format (inverse direction). Ajoute RTF côté client → host (SCClipLevel=0 / CSClipLevel=3 / fDisableClip=0). HTML et binaire toujours bloqués :

Test N – Allow plain text, images, Rich Text Format and HTML (inverse direction). Permet HTML du client vers la session (SCClipLevel=0 / CSClipLevel=4 / fDisableClip=0) :

Test O – Allow plain text, images, Rich Text Format, HTML and Binary (inverse direction). Autorise tous les formats, y compris binaires (SCClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du client vers le host :

Conclusion

La désactivation par défaut des redirections RDP dans Windows 365 et AVD s’inscrit dans une tendance claire : un durcissement progressif des environnements cloud Windows pour tendre vers le secure by default.

Pour les architectes et administrateurs, cela signifie qu’il faut désormais anticiper ce comportement dans les modèles de provisionnement, les recommandations Intune et les templates de pools AVD.

Le presse-papiers, souvent considéré comme un simple confort utilisateur, devient un point de contrôle important dans la stratégie de sécurité : il faut choisir entre flexibilité et maîtrise du flux de données entre les environnements locaux et cloud.

En maîtrisant les deux couches de configuration (Propriétés RDP et polices GPO/MDM) et les niveaux SCClipLevel / CSClipLevel, vous pouvez adapter finement le niveau de redirection autorisé, du simple texte brut jusqu’à la copie complète de formats binaires.

En résumé : ce changement n’est pas une contrainte, mais une opportunité d’élever le niveau de sécurité sans perdre la visibilité sur le fonctionnement interne du protocole RDP.

AVD encore sous Windows 10 22H2 ?

Pourquoi, en 2025, mettre à jour son AVD ronronnant encore et toujours sous Windows 10 22H2 ? Windows 10 ou 11, comme leurs prédécesseurs, reçoivent régulièrement plusieurs types de mises à jour (sécurité, correctifs de bugs, feature update, pilotes, …) . Bien que les Extended Security Updates soient gratuites pour les environnements AVD ou Windows 365 pendant encore une année, il ne faudrait pas trop traîner non plus. Mais … attention à BitLocker !

Voici d’ailleurs le lien vers la FAQ Microosft des Extended Security Updates (ESU) pour Windows 10.

Sous Windows 11, la fréquence des Feature Updates a changé par rapport à Windows 10. Depuis 2022, Microsoft publie une seule Feature Update par an, généralement au second semestre (H2) :

21H2 → sortie en octobre 2021
22H2 → sortie en septembre 2022
23H2 → sortie en octobre 2023
24H2 → sortie en septembre/octobre 2024

Mais, Microsoft ne maintient pas indéfiniment ses produits. La transition vers des versions plus récentes est donc inévitable :

Système	Édition	Version	Date de fin de support / fin de maintenance
Windows 10	Windows 10 Enterprise Windows 10 Enterprise multi-session Windows 10 Education, Windows 10 IoT Enterprise	20H2	9 Mai 2023
Windows 10	Windows 10 Home Windows 10 Pro Windows 10 Pro Edu Windows 10 Pro workstation	21H2	13 juin 2024
Windows 10	Enterprise Education Home Pro Enterprise 2015 LTSB IoT Enterprise LTSB 2015	22H2	14 octobre 2025
Windows 10	Enterprise and IoT Enterprise LTSB	ex. LTSC 2021	12 janvier 2027
Windows 11	Windows 10 Home Windows 10 Pro Windows 10 Pro Edu Windows 10 Pro workstation	21H2	10 octobre 2023
Windows 11	Windows 10 Home Windows 10 Pro Windows 10 Pro Edu Windows 10 Pro workstation	22H2	8 octobre 2024
Windows 11	Windows 10 Home Windows 10 Pro Windows 10 Pro Edu Windows 10 Pro workstation	23H2	11 novembre 2025
Windows 11	Windows 10 Home Windows 10 Pro Windows 10 Pro Edu Windows 10 Pro workstation	24H2	13 Octobre 2026
Windows 11	Windows 10 Home Windows 10 Pro Windows 10 Pro Edu Windows 10 Pro workstation	25H2	12 Octobre 2027

Les versions Entreprise de Windows 11 ont toute une année de service en plus que leurs homologues respectives en version pro.

Comment les versions de Windows 10/11 sont disponibles sous Azure ?

Lors de la création d’une machine virtuelle sous Azure, Microsoft propose toujours plusieurs versions de Windows 10 ou 11, accessibles via le Marketplace Azure :

Un menu déroulant propose différentes versions et générations (Il est important de vérifier que la VM sélectionnée réponde aux conditions (hardware, Gen2, virt-TPM, Secure Boot…) car toutes les séries de VMs ne sont pas compatibles) :

On peut noter qu’il y a donc distinction entre les éditions clients (Pro, Enterprise). De plus, certaines images sont destinées à des usages spécifiques comme Windows 11 Enterprise multi‑session.

Qu’est-ce qu’Azure Update Manager, et peut-il m’aider ?

Azure Update Manager (AUM) est un service de Microsoft disponible sur Microsoft Azure, conçu pour gérer et superviser les mises à jour logicielles (patches) des machines, tant sous Windows que sous Linux, dans des environnements Azure, sur-premises ou multicloud via Azure Arc.

Grâce à Azure Update Manager, vous allez pouvoir :

Superviser la conformité des mises à jour pour les machines Windows et Linux, qu’elles soient dans Azure ou connectées via Azure Arc (on-premises ou multicloud).
Planifier des fenêtres de maintenance pour appliquer les patches.
Déployer un patch à la demande, ou d’un déploiement automatique selon une plage horaire définie.
Mettre en œuvre des mises à jour critiques et les suivre via le monitoring.
Gérer les droits via la granularité d’accès (RBAC) et d’autres fonctions de gouvernance Azure.

En ce qui concerne une machine virtuelle Azure avec un OS sous Windows 11, Microsoft est très clair sur ce point :

Automation Update Management ne fourni pas de prise en charge pour l’application de patchs à Windows 10 et 11. Il en va de même pour le Gestionnaire de mises à jour Azure. Nous vous recommandons d’utiliser Microsoft Intune comme solution pour maintenir les appareils Windows 10 et 11 à jour.

Microsoft Learn

Peut-on faire une upgrade d’une VM Azure Windows 10 existante ?

Oui, mais avant d’aller plus loin, sachez que Microsoft recommande déjà de ne pas le faire 🤣

Le processus de cet article entraîne une déconnexion entre le plan de données et le plan de contrôle de la machine virtuelle.

Les fonctionnalités Azure telles que la mise à jour corrective automatique de l’invité, les mises à niveau automatiques de l’image du système d’exploitation, la mise à jour corrective à chaud et le Gestionnaire de mise à jour Azure ne seront pas disponibles.

Pour utiliser ces fonctionnalités, créez une machine virtuelle à l’aide de votre système d’exploitation préféré au lieu d’effectuer une mise à niveau sur place.

Microsoft Learn

Microsoft ne recommande donc pas de faire une mise à niveau sur place pour une machine virtuelle Windows 10 ou 11 dans Azure pour des raisons techniques et structurelles.

Une mise à niveau sur place modifie profondément le système d’exploitation à l’intérieur de la VM sans qu’Azure en soit informé.

Résultat : La machine continue d’exister dans Azure avec les anciennes métadonnées d’image (Publisher, Offer, Plan, version, etc.), ce qui empêche Azure de reconnaître la nouvelle version de l’OS.

Et cela pose un ensemble de problèmes :

de gestion du cycle de vie
de sécurité et conformité (Azure Security Center/Azure Policy peuvent se tromper sur la version de l’OS)
du support Microsoft, car ce dernier s’appuie sur l’image déclarée dans Azure

Mais Microsoft propose pourtant la mise à niveau pour Windows Server ?

Il existe bien une procédure d’upgrade sur place pour Windows Server pour une VM Azure :

Passer d’une version antérieure de Windows Server à une version plus récente tout en conservant les rôles, données et applications.

Que recommande alors Microsoft pour gérer une MAJ sur Windows 10 ?

Microsoft recommande donc de créer une nouvelle VM avec le système d’exploitation cible, car les mises à jour directes peuvent empêcher certaines fonctionnalités Azure de fonctionner correctement.

Donc, la meilleure pratique consiste à :

Déployer une nouvelle VM avec l’image du nouvel OS supporté.
Migrer les applications, données, configurations vers cette nouvelle VM.
Valider le bon fonctionnement, puis retirer l’ancienne VM.

Plusieurs vidéos tutorielles existent sur Internet pour proposer des mises à jour depuis Windows 10 :

Et quid du passage de la 22H2 à la 24H2 ?

Si malgré tout vous devez conserver votre image de base et effectuer une mise à jour vers Windows 11 24H2, vous risquez de rencontrer un problème de démarrage après la capture de votre image après un sysprep.

Lors du passage de Windows 10 22H2 ou Windows 11 22H2 vers la version 24H2, plusieurs administrateurs ont rencontré des écrans bleus ou des erreurs EFI (0xc000000f) juste après la capture d’image via Sysprep.

Le problème provient d’un bug dans le processus de Sysprep, qui modifie la configuration BCD lorsque BitLocker (ou le chiffrement automatique du périphérique) est actif.

Et le souci se manifeste à nouveau si on réactive BitLocker sans avoir corrigé la configuration BCD.

Résultat : l’image capturée devient partiellement chiffrée et inutilisable au déploiement.

Ce souci de démarrage est d’ailleurs confirmé dans les journaux de diagnostic Azure :

Pas de workaround possible ?

Pour éviter cela, il faut désactiver BitLocker avant le Sysprep. Une fois l’image déployée, BitLocker peut être réactivé proprement après correction de la configuration BCD. Ce comportement est spécifique aux builds 26100.x (Windows 11 24H2 et LTSC 2024) .

Voici d’abord une comparaison de l’état de BitLocker sur deux machines virtuelles Azure :

A droite : Windows 10 Multi-session 22H2
A gauche : Windows 11 Multi-session 24H2

La désactivation de BitLocker doit donc être complète et certaine avant de lancer Sysprep, sous peine de le voir se réactiver.

Afin de voir ce qu’il est possible de faire pour résoudre le souci de BitLocker , je vous propose au travers de cet article un pas à pas sur le processus complet :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests de mise à jour de VM, il vous faudra disposer de :

Un abonnement Azure valide
Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une machine virtuelle à partir d’une image Windows 10/11 multi-session en 22H2, que nous allons mettre à jour dans la foulée.

Etape I – Création d’une VM W10 Multi-session 22H2 + MAJ 24H2 :

Pour cela, je commence par créer une machine virtuelle Azure en Windows 10 en 22H2 :

Une fois la machine virtuelle déployée, je vérifie la présence de mon application et de ma version actuelle de Windows :

J’ouvre PowerShell ISE en mode administrateur afin de vérifier l’état actuel de BitLocker :

Get-Service BDESVC : affiche l’état du service BitLocker Drive Encryption Service, qui gère le chiffrement BitLocker sur Windows.
manage-bde -status : affiche le statut détaillé du chiffrement BitLocker sur tous les lecteurs du système.
(Get-ComputerInfo).WindowsVersion : retourne la version majeure de Windows (ex. 10, 11, etc.).
(Get-ComputerInfo).OsBuildNumber : affiche le numéro de build du système d’exploitation Windows.
(Get-ComputerInfo).WindowsBuildLabEx : fournit la version complète du build Windows avec des informations additionnelles (branche, révision, date de compilation).

Get-Service BDESVC

manage-bde -status

(Get-ComputerInfo).WindowsVersion
(Get-ComputerInfo).OsBuildNumber
(Get-ComputerInfo).WindowsBuildLabEx

Je télécharge ensuite l’ISO Windows 11 24H2 depuis Visual Studio :

Je lance l’installation de Windows 11 en 24H2 :

Je vérifie le maintien de la version Multi-session, puis je démarre l’installation :

L’installation progresse lentement mais sûrement :

Afin de m’assurer que la mise à jour est terminée, je vérifie les journaux de diagnostic Azure pour confirmer le bon démarrage de la machine virtuelle :

Je me connecte via Azure Bastion et je vérifie le statut de BitLocker :

Get-Service BDESVC

manage-bde -status

(Get-ComputerInfo).WindowsVersion
(Get-ComputerInfo).OsBuildNumber
(Get-ComputerInfo).WindowsBuildLabEx

Le service de BitLocker BDESVC est maintenant démarré en 24H2 :

Je lance les commandes suivantes pour arrêter le service BitLocker BDESVC, mais aussi pour bloquer son changement de statut lors du sysprep :

# 1. Empêcher toute activation BitLocker automatique
reg add "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /t REG_DWORD /d 1 /f

# 2. Désactiver le service BitLocker
Set-Service -Name BDESVC -StartupType Disabled

# 3. Stopper le service s’il est actif
Stop-Service -Name BDESVC -Force

# 4. Vérifier que tout est propre
Get-Service BDESVC
manage-bde -status

La machine virtuelle est maintenant prête pour la capture. Avant cela je pourrais effectuer un snapshot. Je décide de continuer avec la commande Sysprep.

Etape II – Capture de l’image Windows 11 24H2 :

Je lance la commande Sysprep pour capturer cette nouvelle image 24H2 :

C:\Windows\System32\Sysprep\sysprep.exe /quiet /generalize /oobe /mode:vm /shutdown

Une fois Sysprep terminé, j’arrête complètement la machine pour qu’elle soit désallouée, puis je lance l’action de capture de l’image depuis le portail Azure :

Je crée une nouvelle image au sein de ma Azure Compute Gallery :

Avec cette nouvelle image en place, je déclenche la création d’une nouvelle machine virtuelle 24H2 à partir de celle-ci :

La nouvelle machine virtuelle est fonctionnelle, et cela est confirmé dans les journaux de diagnostic Azure :

Etape III – Réactivation de BitLocker :

Une fois la VM créée, je m’y connecte via Azure Bastion, puis je lance la vérification initiale de l’état du service BitLocker et du chiffrement :

Write-Host "=== Vérification initiale ===" -ForegroundColor Cyan
Get-Service BDESVC
manage-bde -status
Write-Host "WindowsVersion: $((Get-ComputerInfo).WindowsVersion)"
Write-Host "OS Build: $((Get-ComputerInfo).OsBuildNumber)"
Write-Host "BuildLabEx: $((Get-ComputerInfo).WindowsBuildLabEx)"
Write-Host ""
Start-Sleep -Seconds 3

Le statut du service BitLocker est toujours sur OFF comme attendu, et le disque OS se trouve toujours dans un état de déchiffrement :

Avant de pouvoir chiffrer le disque OS, nous avons besoin de corriger la configuration de BCD.

Je vérifie la configuration actuelle du BCD, corrige les entrées BCD liées à la partition système et au diagnostic mémoire :

# --- Vérifie le BCD avant correction
Write-Host "=== BCD avant correction ===" -ForegroundColor Yellow
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

# --- Corrige les entrées BCD (selon le bug 24H2 /generalize)
Write-Host "=== Correction BCD ===" -ForegroundColor Cyan
cmd /c "bcdedit /set {current} osdevice partition=C:"
cmd /c "bcdedit /set {current} device partition=C:"
cmd /c "bcdedit /set {memdiag} device partition=\Device\HarddiskVolume3"
Write-Host "BCD corrigé."
Write-Host ""
Start-Sleep -Seconds 2

# --- Vérifie le BCD après correction
Write-Host "=== BCD après correction ===" -ForegroundColor Green
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

La correction est bien visible sur cette seconde partie de l’écran :

Je supprime la clé de registre PreventDeviceEncryption si elle est présente, je rétablis le service BitLocker en mode manuel, je le démarre, puis je contrôle à nouveau l’état du service BDESVC et de BitLocker :

# --- Nettoyage de la clé PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2

# --- Rétablir le service BitLocker (manuel + démarrage)
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Write-Host "Service BDESVC en cours d’exécution."
Write-Host ""
Start-Sleep -Seconds 2

# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 2

J’attends environ 15 minutes la fin du chiffrement du disque OS :

Ensuite, j’active la protection BitLooker :

# --- Active BitLocker avec TPM (UsedSpaceOnly)
Write-Host "=== Activation BitLocker (TPM) ===" -ForegroundColor Cyan
Enable-BitLocker -MountPoint "C:" -TpmProtector -UsedSpaceOnly
Write-Host "BitLocker initialisé. Vérification du statut..."
Start-Sleep -Seconds 3
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 2

Cette activation est visible par le petit cadenas présent dans les paramétrages BitLocker et dans l’explorateur de fichier, suivi éventuellement d’un avertissement pour me signaler que la protection est encore sur OFF :

Une fois le chiffrement en place, je remets en route la protection (clé TPM active, verrouillage à l’amorçage autorisé)”.

# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Write-Host "BitLocker réactivé avec succès."
Write-Host ""
Start-Sleep -Seconds 3

# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan

Cette validation est visible par la disparition de l’avertissement pour me signaler que la protection est maintenant sur ON :

Etape IV – Azure Virtual Desktop :

Je redémarre la machine virtuelle pour vérifier le bon fonctionnement du boot de Windows :

Une fois la VM redémarrée, je me reconnecte et confirme la présence de mon application, de la version 24H2 et de l’état actif de BitLocker sur cette machine virtuelle :

Je teste l’ajout de cette image dans un environnement Azure Virtual Desktop :

J’attends la fin de déploiement afin de constater la présence des VMs AVD comme étant disponibles :

Je passe sur chacune des machines pour lancer le script suivant en local ou à distance :

<#
.SYNOPSIS
  Répare la configuration BitLocker après Sysprep /generalize sur Windows 11 24H2.
  Corrige le BCD EFI et réactive BitLocker proprement.

.DESCRIPTION
  Ce script :
    1. Affiche l’état initial BitLocker et du service BDESVC
    2. Corrige les entrées BCD {current} et {memdiag}
    3. Supprime la clé PreventDeviceEncryption
    4. Rétablit le service BitLocker (mode Manuel)
    5. Démarre BDESVC et attend qu’il soit prêt
    6. Active BitLocker avec TPM (si nécessaire)
    7. Attend la fin du chiffrement (max 2h)
    8. Finalise avec Resume-BitLocker
#>

# --- FONCTIONS UTILITAIRES ---

function Wait-ForService {
    param (
        [string]$ServiceName,
        [int]$TimeoutSec = 120
    )
    Write-Host "Attente du service $ServiceName..." -ForegroundColor Yellow
    $sw = [Diagnostics.Stopwatch]::StartNew()
    while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
        $status = (Get-Service $ServiceName -ErrorAction SilentlyContinue).Status
        if ($status -eq 'Running') {
            Write-Host "Service $ServiceName opérationnel." -ForegroundColor Green
            return
        }
        Start-Sleep -Seconds 3
    }
    Write-Host "⚠️ Le service $ServiceName n’a pas démarré après $TimeoutSec secondes." -ForegroundColor Red
}

function Wait-ForEncryption {
    param (
        [string]$MountPoint = "C:",
        [int]$CheckIntervalSec = 15,
        [int]$TimeoutSec = 7200  # 2 heures
    )

    Write-Host "Attente de la fin du chiffrement BitLocker sur $MountPoint (timeout $($TimeoutSec/60) min)..." -ForegroundColor Yellow
    $sw = [Diagnostics.Stopwatch]::StartNew()

    while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
        $status = manage-bde -status $MountPoint | Select-String "Conversion Status"
        $percent = manage-bde -status $MountPoint | Select-String "Percentage Encrypted"
        $state = ($status -replace ".*:\s*", "").Trim()
        $progress = ($percent -replace ".*:\s*", "").Trim()

        Write-Host "État: $state | Progression: $progress"

        if ($state -match "Fully Encrypted|Used Space Only Encrypted") {
            Write-Host "✅ Chiffrement terminé sur $MountPoint" -ForegroundColor Green
            return
        }
        Start-Sleep -Seconds $CheckIntervalSec
    }

    Write-Host "⚠️ Le chiffrement sur $MountPoint n’est pas terminé après $($TimeoutSec/60) minutes." -ForegroundColor Red
    Write-Host "Le script continue, mais vérifie manuellement l’état avec 'manage-bde -status $MountPoint'." -ForegroundColor Yellow
}

# --- DÉBUT DU SCRIPT ---

Write-Host "=== Vérification initiale ===" -ForegroundColor Cyan
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 3

# --- Vérifie le BCD avant correction
Write-Host "=== BCD avant correction ===" -ForegroundColor Yellow
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

# --- Corrige les entrées BCD
Write-Host "=== Correction BCD ===" -ForegroundColor Cyan
cmd /c "bcdedit /set {current} osdevice partition=C:"
cmd /c "bcdedit /set {current} device partition=C:"
cmd /c "bcdedit /set {memdiag} device partition=\Device\HarddiskVolume3"
Write-Host "BCD corrigé."
Start-Sleep -Seconds 2

# --- Vérifie le BCD après correction
Write-Host "=== BCD après correction ===" -ForegroundColor Green
cmd /c "bcdedit /enum"
Start-Sleep -Seconds 2

# --- Supprime PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2

# --- Réactive BDESVC
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Wait-ForService -ServiceName "BDESVC"
Write-Host ""

# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Start-Sleep -Seconds 2

# --- Active BitLocker avec TPM si nécessaire
Write-Host "=== Activation BitLocker (TPM) ===" -ForegroundColor Cyan
$bitlockerStatus = (manage-bde -status C: | Select-String "Conversion Status").ToString()

if ($bitlockerStatus -match "Encryption in Progress|Fully Encrypted|Used Space Only Encrypted") {
    Write-Host "ℹ️ BitLocker est déjà actif ou en cours de chiffrement sur C:. Aucune réactivation nécessaire." -ForegroundColor Yellow
} else {
    try {
        Enable-BitLocker -MountPoint "C:" -TpmProtector -UsedSpaceOnly -ErrorAction Stop
        Write-Host "BitLocker initialisé." -ForegroundColor Green
    } catch {
        Write-Host "⚠️ Impossible d’ajouter un protecteur TPM (probablement déjà présent) : $($_.Exception.Message)" -ForegroundColor Red
    }
}

Write-Host "Vérification du statut..."
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host ""

# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host "BitLocker réactivé avec succès." -ForegroundColor Green
Write-Host ""

# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan

Je redémarre la machine AVD pour vérifier son statut dans les journaux de diagnostic Azure :

Je teste également la connexion Azure Virtual Desktop avec un utilisateur :

Enfin, comme mon environnement est liée à Entra ID, je constate également la remontée automatqiue de ma clef de secours BitLocker dans Entra ID :

Conclusion

Cette expérience montre bien qu’une mise à jour in-place d’une image Windows 10/11 dans Azure n’est jamais anodine.
Entre la gestion du chiffrement BitLocker, les effets secondaires du Sysprep et les métadonnées Azure qui ne se mettent pas toujours à jour correctement, le risque d’image inutilisable est bien réel.

Le bon réflexe reste donc de désactiver BitLocker avant le Sysprep, de corriger la configuration BCD, puis de réactiver proprement la protection une fois la VM redéployée.
Cette approche garantit un chiffrement fonctionnel sans compromettre la capture ni le déploiement de l’image.

Mais il existe aujourd’hui une alternative plus élégante et performante : Encryption at Host.
Cette fonctionnalité permet de chiffrer les disques directement au niveau de l’hôte Azure, sans impliquer le service BitLocker à l’intérieur de la VM.

Résultat :

Moins de charge CPU côté invité,
Pas de dépendance au TPM virtuel,
Et une gestion centralisée du chiffrement dans Azure, plus simple à auditer et à maintenir.

C’est cette approche, à la fois plus moderne et plus légère, que nous verrons dans le prochain article.

On parlera en détail de la mise en œuvre d’Encryption at Host, de son impact sur les performances et des bonnes pratiques pour combiner sécurité et efficacité énergétique dans vos environnements AVD.

Azure Virtual Desktop – Invités

Comme pour Windows 365, Microsoft continue de faire évoluer Azure Virtual Desktop pour répondre aux besoins des organisations qui travaillent avec des partenaires externes, freelances ou prestataires. La dernière nouveauté, actuellement en préversion publique, permet de provisionner dans votre AVD une ou plusieurs identités externes (invités B2B dans votre tenant Microsoft Entra ID).

Spoiler alert : cet article est la copie quasi-identique de celui consacré aux comptes invités sur Windows 365.

Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un accès à un environnement Azure Virtual Desktop créé sur votre tenant.

Qui peut bénéficier de cette nouveauté ?

Nous venons de sortir il y a peu de la préversion privée, et nous sommes donc maintenant en préversion publique, avant une mise à disposition générale (GA) dans plusieurs mois je suppose. Tout utilisateur externe invité dans votre tenant Microsoft Entra ID peut donc en profiter.

Comme rappelé plus haut, les scénarios typiques sont : prestataires, auditeurs, partenaires de développement…

Le flux d’approvisionnement change-t-il pour ces utilisateurs invités ?

Non, vous utilisez les mêmes pool d’hôtes Azure Virtual Desktop et les mêmes licences que pour les utilisateurs internes à votre tenant.

Depuis quelles plate-formes le compte invité fonctionne ?

A ce jour où ces lignes sont écrites, la documentation Microsoft mentionne deux moyens possibles :

Navigateur internet
Windows App

Quelles sont les conditions techniques ?

Plusieurs conditions sont actuellement en vigueur et sont rappelées sur cette page de la documentation Microsoft :

VM AVD sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
VM AVD jointe à Entra ID
Single Sign-On activé au niveau du pool d’hôtes AVD

Quelles sont les principales limitations actuellement dans cette préversion ?

FSLogix n’est pas encore pris en charge : un nouveau profil utilisateur sera créé sur chaque hôte de session auquel elles se connectent.
Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler les VMs AVD).
Pas de support pour le Cloud Government ni pour les invités cross-cloud (Azure Gov, 21Vianet).
Pas d’authentification Kerberos/NTLM vers les ressources on-premises.
Quelques limites sur la Token Protection pour identités externes.

Quelle licence Azure Virtual Desktop faut-il pour ces utilisateurs invités ?

Comme dit plus haut, il faut toujours provisionner une licence dans votre tenant pour le compte invité.

Les licences détenues par un compte invité dans son propre tenant ne confèrent aucun droit pour utiliser Azure Virtual Desktop dans votre tenant :

Si vous déployez Azure Virtual Desktop pour une utilisation avec des identités externes (actuellement en préversion publique), certaines considérations particulières peuvent s’appliquer concernant la manière de licencier Azure Virtual Desktop ainsi que d’autres produits et services Microsoft.

Microsoft Learn

Vous devez donc acheter et attribuer les mêmes licences AVD que pour vos utilisateurs internes, et aussi une licence Microsoft 365, si nécessaire.

Maintenant, il ne nous reste plus qu’à tester tout cela 😎

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Etape 0 – Rappel des prérequis :

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

Un abonnement Azure valide
Un tenant Microsoft
Une des licences requises pour Azure Virtual Desktop

Avant d’aller plus loin, commençons par vérifier que notre environnement AVD répondent bien aux prérequis de la fonctionnalité.

Pour cela, rendez-vous dans le portail Azure, puis rendez-vous sur la page de votre pool d’hôtes AVD :

Vérifiez sur une des VMs AVD que la jointure est bien définie vers Entra :

Contrôlez également sur le pool d’hôtes que le Single Sign-On (SSO) est activé :

Vérifiez ensuite que l’image Windows 11 utilisée pour le provisionnement est au minimum en version 24H2, avec le correctif KB5065789, ou plus récent :

Si tous ces points sont OK, commençons par inviter un nouvel utilisateur externe à notre tenant.

Etape I – Création de l’utilisateur invité :

Pour cela, rendez-vous dans le portail Microsoft Entra ID pour créer un nouvel utilisateur invité.

Cliquez sur Nouvel utilisateur, puis choisissez Inviter un utilisateur externe :

Renseignez l’adresse e-mail du compte Microsoft Entra de l’invité, puis cliquez ici :

Attendez quelques secondes, puis constatez la réception de l’e-mail d’invitation dans la boîte du compte invité, et enfin cliquez sur lien présent dans ce dernier :

Cliquez sur Accepter pour rejoindre le tenant qui vous a invité :

Sur votre tenant, ouvrez le portail d’administration de Microsoft 365 :

Ouvrez la fiche de l’utilisateur invité et attribuez-lui la licence AVD nécessaire, puis enregistrez :

Notre utilisateur invité est maintenant présent. Nous allons pouvoir nous intéresser au provisionnement de son accès à l’environnement AVD.

Etape II – Provisionnement de l’accès AVD à notre invité :

Pour cela, rendez-vous dans le portail Azure, puis rendez-vous sur la page du groupe d’application concerné :

Ajoutez l’utilisateur invité à votre groupe d’applications Azure Virtual Desktop :

Pensez également à lui ajouter un droit de connexion à la machine AVD via un rôle Azure RBAC :

Le provisionnement de l’utilisateur invité à notre environnement AVD est terminé. Nous allons maintenant pouvoir tester la connexion de ce dernier à Azure Virtual Desktop.

Etape III – Test de connexion invité depuis le navigateur internet :

Commençons nos tests par le navigateur internet. Pour cela, rendez-vous sur l’URL historique d’Azure Virtual Desktop, puis authentifiez avec le compte invité de votre utilisateur :

https://client.wvd.microsoft.com/arm/webclient/index.html

Une fois authentifié, constatez l’absence d’accès à l’environnement Azure Virtual Desktop provisionné sur votre tenant pour votre compte invité :

Ouvrez alors une nouvelle page internet en vous connectant, toujours avec le compte invité, sur une autre URL contenant le domaine de votre tenant :

https://client.wvd.microsoft.com/arm/webclient/index.html?tenant=<domainName>

Vérifiez que l’URL reste bien sur le domaine de votre tenant, et que votre environnement AVD apparaît cette fois :

Testez au besoin une seconde URL, commune entre les services Azure Virtual Desktop et Windows 365 :

https://windows.cloud.microsoft?tenant=<domainName>

Peu importe le site internet utilisé, cliquez sur Connecter :

Cliquez à nouveau sur Connecter :

Cliquez sur Oui :

Constatez l’apparition du message de chargement de FSLogix :

Constatez la bonne ouverture de session de votre compte invité :

Ouvrez Windows PowerShell :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement dans Entra ID :

dsregcmd /status

AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID
EnterpriseJoined : NO
DomainJoined : NO :

TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.

SSO / Primary Refresh Token :
- AzureAdPrt : YES
- DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :

Ouvrez Microsoft Edge, puis constatez l’absence de récupération automatique du token de connexion pour le SSO :

Ouvrez Microsoft OneDrive, puis constatez, là aussi, l’absence de récupération automatique du token de session pour le SSO :

Malgré l’absence de SSO, la connexion à AVD depuis le navigateur internet se passe bien. Continuons les tests avec l’application Windows App.

Etape IV – Test de connexion invité depuis Windows App :

Avant de continuer, ouvrez les Paramètres de l’application Windows App, puis vérifiez la version installée :

Ouvrez localement PowerShell en tant qu’administrateur, puis lancez la commande ci-dessous pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier :

Avant de saisir votre e-mail, cliquez sur le bouton des options avancées :

Cliquez sur le menu Organisation :

Indiquez le domaine de votre organisation, puis cliquez sur Suivant :

Renseignez l’adresse e-mail et le mot de passe du compte invité :

Constatez la bonne ouverture de l’application Windows App connectée à votre tenant avec le compte invité :

Cliquez sur Connecter pour lancer la session Azure Virtual Desktop :

Constatez la bonne ouverture de session AVD pour votre compte invité, puis ouvrez PowerShell :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement AVD dans Entra ID :

dsregcmd /status

AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID
EnterpriseJoined : NO
DomainJoined : NO

TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.

SSO / Primary Refresh Token :
- AzureAdPrt : YES
- DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :

Enfin, la console de gestion Azure Virtual Desktop affiche bien votre utilisateur invité :

Par contre, aucune information n’y est disponible pour notre utilisateur invité :

Mais en passant par l’hôte de session AVD, les actions semblent également fonctionner sur notre utilisateur invité :

Vous voilà bien connecté avec votre compte invité sur l’environnement AVD de votre tenant Microsoft.

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Souci I – Impossible de se connecter malgré une version 24H2 :

Si, malgré le respect des prérequis, il est possible que vous rencontriez le blocage suivant au moment de vous connecter :

Commencez par vérifier que votre utilisateur invité est bien autorisé à ouvrir une session sur votre machine virtuelle AVD via le rôle Azure RBAC suivant :

Ensuite, cela vient peut-être de l’absence du correctif KB5065789 sur votre machine AVD, pourtant en version 24H2.

Pour remédier à cette mise à jour manquante, connectez-vous avec un administrateur sur votre machine AVD, puis lancez la commande PowerShell suivante pour vérifier les correctifs installés :

Get-HotFix | Where-Object {$_.HotFixID -like "KB506*"}

Si besoin, allez dans Windows Update, puis lancez la recherche de mises à jour :

Redémarrez si nécessaire :

Vérifiez avec la commande PowerShell que le correctif KB5065789 (24H2) est maintenant bien présent :

Get-HotFix | Where-Object {$_.HotFixID -like "KB506*"}

Retournez sur la page web de Azure Virtual Desktop ouverte avec le compte invité :

Constatez cette fois la bonne ouverture de session sur votre compte invité :

Souci II – Impossible de choisir une entreprise via Windows App :

Si, dans Windows App, le choix d’une authentification alternative n’apparaît pas, et que l’application ne vous propose qu’une adresse e-mail à renseigner :

C’est qu’il vous manque une clef de registre Windows pour faire apparaître ce choix alternatif.

Pour cela, sur votre PC local, ouvrez PowerShell en tant qu’administrateur puis lancez la commande indiquée pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier, afin de voir le choix apparaître maintenant :

Souci III – Impossible de se connecter via Windows App – Erreur 7q6ch :

J’ai rencontré ce souci lors de l’authentification dans l’application Windows App, sur 2 postes uniquement. Les autres n’ont posé aucune difficulté.

Malgré une authentification réussie pour mon compte invité, le message d’erreur suivant apparaissait :

Suivi de ce seconde message :

Malgré plusieurs réinstallations de l’application Windows App, je n’ai pas encore trouvé la cause de ce souci. Je suis toujours en contact avec les équipes de Microsoft pour en comprendre la cause.

Conclusion

L’arrivée des identités externes sur Azure Virtual Desktop simplifie enfin l’accès des prestataires et partenaires, sans créer de comptes temporaires.

La fonctionnalité reste en préversion publique avec plusieurs limites (SSO partiel, stratégies Intune incomplètes, pas de support Government/cross-cloud), mais Microsoft annonce déjà des évolutions à venir.

C’est donc le bon moment pour tester, identifier les impacts et se préparer à son adoption lorsque ces restrictions seront levées.

Découvrez Windows 365 Frontline Dedicated / Shared

Windows 365 continue d’évoluer et de s’adapter aux nouveaux usages. Après les éditions Business et Enterprise, Microsoft propose depuis quelque temps déjà Windows 365 Frontline, une déclinaison pensée pour les équipes en rotation ou à temps partiel. Bref, pour tous ceux qui n’ont pas besoin d’un Cloud PC huit heures par jour.

Dans cet article, je vous propose de faire le tour complet de Windows 365 Frontline, avec la création des stratégies dans Intune, le provisioning des Cloud PCs, les comportements de session, et les petits détails qu’on ne découvre qu’en le déployant soi-même.

Avant d’aller plus loin, je vous propose la lecture de plusieurs articles sur ce blog, qui parlent de Windows 365 depuis sa GA en 2021 :

À quoi sert Windows 365 Frontline ?

Windows 365 Frontline a été présenté pour la première fois en avril 2023 et est devenu disponible en version publique quelques mois plus tard, à l’été 2023.

Windows 365 Frontline est une déclinaison de Windows 365 pensée pour les travailleurs “de première ligne”. Il s’agit de cibler ceux qui n’utilisent pas un poste de travail huit heures par jour, tous les jours, mais travaillant sur leur poste de manière ponctuelle ou en rotation. C’est donc parfait pour les équipes en postes tournant, les centres de support, les services clients, ou les équipes sur le terrain.

Windows 365 Frontline est une version de Windows 365 qui permet aux organisations de réduire les coûts en leur permettant de provisionner un PC cloud qui peut être utilisé par plusieurs utilisateurs avec une seule licence.

Microsoft Learn

L’objectif principal est et reste de réduire le coût des licences Windows 365 tout en gardant la simplicité et la sécurité du Cloud PC.

Quelles sont les limitations de Windows 365 Frontline ?

Windows 365 Frontline apporte une vraie flexibilité, mais il faut connaître ses limites techniques et opérationnelles pour bien l’intégrer dans un environnement d’entreprise :

Un seul utilisateur peut être actif par Cloud PC à la fois : Même si la licence couvre plusieurs utilisateurs, ils ne peuvent pas se connecter simultanément.
Pas de mise en veille prolongée : lorsqu’un utilisateur se déconnecte, la session est suspendue mais reste comptabilisée tant que la VM est “réservée”.
Temps de démarrage à prévoir : la mise en service d’un Cloud PC Frontline peut prendre quelques minutes selon la politique de démarrage configurée.

Windows 365 Frontline Dedicated vs Shared ?

Microsoft propose aujourd’hui deux modes pour Frontline : Dedicated et Shared :

Le mode Dedicated reste le choix recommandé pour des postes attribués en rotation (3 utilisateurs maximum).

Prenons trois collaborateurs travaillant sur des shifts différents (matin, après-midi, nuit) — avec une seule licence Windows 365 Frontline, chacun dispose de son propre Cloud PC pendant son créneau de travail.

On réduit les coûts de licence tout en maintenant une expérience utilisateur complète et sécurisée pour chaque employé.

Le modèle devient particulièrement avantageux à grande échelle : pour 300 employés en rotation, il ne faudrait que 100 licences actives, soit une économie substantielle tout en maintenant une expérience et une sécurité identiques à Windows 365 Entreprise :

Le mode Shared vise les scénarios éphémères où la persistance n’est pas nécessaire (kiosques, formation). Ce mode a été introduit par Microsoft fin 2024. Ce mode est donc conçu pour des tâches courtes et ponctuelles (ex. : formation, inventaire, accès temporaire pour prestataires).

En quelques mots, le Frontline Partagé se distingue du Frontline Dédié sur :

Les Cloud PCs partagés sont réinitialisés après chaque session utilisateur : le profil et les données sont supprimés.
1 licence = 1 Cloud PC partagé : la licence est liée à la machine virtuelle, pas à un utilisateur spécifique.
Les déconnexions automatiques après inactivité libèrent la session, permettant à d’autres utilisateurs d’accéder rapidement au poste.

Idéal pour les scénarios nécessitant un accès rapide et sécurisé à des applications ou outils sans conservation de données persistantes.

Au final, quelles sont les différentes licences Windows 365 ?

Voici un comparatif des différentes licences Windows 365 disponibles :

Feature	Dedicated (Enterprise / Business)	Frontline Dedicated (Standard)	Frontline Shared Mode (Preview)
Cloud PC Usage	1 Cloud PC par utilisateur	3 Cloud PCs partagés entre 3 utilisateurs	Plusieurs Cloud PCs partagés entre de nombreux utilisateurs (1 à la fois)
User Profile	Persistant – sauvegardé entre les sessions	Persistant – chaque utilisateur a son propre bureau	Non persistant – profil supprimé après déconnexion
Concurrent Users	Un utilisateur par Cloud PC	1 utilisateur par Cloud PC à la fois (jusqu’à 3 par licence, en rotation)	Un seul utilisateur à la fois par PC partagé
Session Type	Expérience Windows complète	Expérience Windows complète	Sessions pooled et réinitialisables
Best For	Employés à temps plein utilisant un Cloud PC quotidiennement	Travailleurs en rotation (shifts)	Accès temporaire, hot-desking, formation, kiosques
License Cost	Le plus cher	Plus bas (3 utilisateurs par licence)	Le plus bas – moins de licences requises
User Profile Storage	Conservé sur le Cloud PC	Conservé sur le Cloud PC	Supprimé à la fin de la session
Always-on Cloud PC	Oui	Éteint si non utilisé	Oui

Quels sont les prix pour ces licences Windows 365 ?

Les licences Windows 365 Frontline affichent un prix facial plus élevé que les éditions Enterprise ou Business, mais elles sont conçues pour être partagées entre plusieurs utilisateurs.

Autrement dit, il faut raisonner en coût par utilisateur actif plutôt qu’en coût par licence : une approche indispensable pour déterminer la solution la plus avantageuse financièrement selon ton modèle d’usage (rotation, shifts, postes partagés, etc.).

Voici donc un tableau comparatif indicatif (en USD) pour une machine de 4 vCPU / 16 Go RAM, selon les quatre « méthodologies » (Business / Enterprise / Frontline Dedicated / Frontline Shared) de licensing possibles pour Windows 365 :

Méthode / SKU	Prix en €, paiement mensuel engagement annuel
Windows 365 Enterprise	≈ 63 Euros
Windows 365 Business	≈ 63 Euros, avec Windows Hybrid Benefit
Windows 365 Frontline Dedicated	≈ 94.53 € (licence 3 utilisateurs)
Windows 365 Frontline Shared	≈ 94.53 € par poste partagé

Maintenant, il ne nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cette démonstration sur les licences Windows 365 Frontline, il vous faudra disposer de :

Un tenant Microsoft
Une ou plusieurs licences Windows 365 Frontline

Dans le portail Microsoft 365 Admin Center, on remarque tout de suite que ces licences ne peuvent pas être attribuées directement à des utilisateurs ou à des appareils :

Toujours depuis le portail Admin Center, il n’est pas possible d’associer la licence Frontline à un utilisateur :

Commençons par tester les Cloud PCs Frontline dédiés à des utilisateurs spécifiques.

Test I – Test de Windows 365 Frontline Dédié :

J’ai commencé par créer un groupe sur le portail Entra ID pour mes utilisateurs de test :

Sur le portail Intune, dans la section Polices de provisionnement de Windows 365, je crée une nouvelle police :

Je nomme ma stratégie, je sélectionne le type Frontline et le mode Dedicated :

Je choisis la jointure Entra ID et j’active le Single Sign-On (SSO) :

Je sélectionne une image Windows 11 pour mes Cloud PCs :

Je clique sur Suivant :

Je clique ici pour attribuer une configuration de Cloud PCs :

Je choisis la taille des Cloud PCs, ainsi que leur nombre :

Je clique sur Suivant :

Je clique sur Créer pour valider ma nouvelle police de provisionnement :

Je constate la création de la police de provisionnement de mes PC Frontline :

De retour dans la liste des Cloud PCs, je remarque l’apparition de nouveaux Cloud PCs avec le statut Pending :

En cliquant sur la mention Pending, j’observe un message indiquant plusieurs raisons possibles expliquant ce statut :

Quelques minutes plus tard, le statut Pending passe à Provisioning pour ces Cloud PCs :

Environ un quart d’heure plus tard, les PC apparaissent en statut Provisioned :

Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :

Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC, normal :

Je retourne sur la police de provisionnement et j’augmente le nombre d’instances Windows 365 à 2 pour cette police Frontline :

Je parviens cette fois à connecter trois utilisateurs en simultané, bien que la configuration n’autorise initialement que deux sessions :

Dans les rapports Intune, on constate que la plateforme signale une surcapacité, mais qu’elle a tout de même permis la connexion grâce à la marge de tolérance (buffering) intégrée :

Voici d’ailleurs quelques règles du concurrency buffer pour Windows 365 Frontline :

Le concurrency buffer permet de dépasser temporairement la limite maximale de connexions simultanées permises par les licences Frontline dans des cas de transition comme le changement de shift
Le concurrency buffer ne s’applique pas aux Cloud PCs GPU-enabled ni au mode Frontline Shared.
Il peut être utilisé jusqu’à 4 fois par jour, pour un maximum d’1 heure à chaque activation. L’heure commence dès le dépassement de la limite de licences.
Si le buffer est utilisé de façon excessive (par exemple plus d’une heure à quatre reprises dans 24 heures), un blocage temporaire est activé pendant 48 heures, empêchant toute utilisation du buffer.
Si le tenant subit plus de deux blocages temporaires sur une période de 7 jours, le buffer peut être bloqué de façon permanente. Dans ce cas, il faut ouvrir un ticket auprès du support Intune pour restaurer l’accès.
Pendant le blocage (temporaire ou permanent), les utilisateurs peuvent toujours se connecter, mais uniquement jusqu’à la limite standard de licences (le buffer n’est plus accessible).

Continuons par par tester les Cloud PCs Frontline partagés à des utilisateurs.

Test II – Test de Windows 365 Frontline Partagé :

J’ai créé un second groupe dans le portail Entra ID pour mes utilisateurs de test :

Sur le portail Intune, dans la section Stratégies Windows 365, et je crée une seconde police de provisionnement :

Je nomme ma stratégie, je sélectionne le type Frontline, le mode Shared, je choisis la jointure Entra ID et j’active le SSO :

Je sélectionne une image Windows 11 pour mes Cloud PCs :

Je clique sur Suivant :

Je choisie la taille des Cloud PCs, ainsi que leur nombre :

Je clique sur Créer pour valider ma nouvelle police de provisionnement :

De retour dans la liste des Cloud PCs, je remarque l’apparition du nouveau Cloud PC avec le statut Provisioning :

Environ un quart d’heure plus tard, le Cloud PC apparaît en statut Provisionné :

Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :

Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC :

Sur mon premier utilisateur, je personnalise le bureau et le fond d’écran, je crée un dossier sur le disque C avec un fichier, j’ajoute des éléments sur le bureau et je modifie la barre du menu Démarrer :

Je déconnecte le premier utilisateur et me connecte avec le second ; je constate alors la présence des fichiers locaux sur le disque C :

J’attends environ une heure, puis je me reconnecte avec le premier utilisateur ; je constate la restauration des éléments issus de OneDrive ainsi que des fichiers locaux, mais l’absence du fond d’écran et des raccourcis de la barre des tâches, non pris en charge par OneDrive :

Je lance un reprovisionnement immédiat de ma machine partagée :

Je constate le démarrage du nouveau processus :

Le provisionnement progresse et la nouvelle machine partagée apparaît dans l’environnement :

Quelques minutes plus tard, la nouvelle machine partagée est provisionnée :

Je me reconnecte avec mes deux utilisateurs, en commençant par le premier, et je constate la disparition des fichiers précédemment présents sur le disque C mais la conservation des données sauvegardées sur OneDrive :

Conclusion

Windows 365 Frontline apporte une vraie flexibilité dans la gestion des postes Cloud, surtout pour les environnements en rotation ou à effectif variable.

Le mode Dedicated reste parfait pour les équipes qui se relaient sur un même poste tout en conservant leur propre environnement, tandis que le mode Shared s’adresse davantage aux scénarios temporaires ou sans persistance.

Ce qu’il faut retenir, c’est que Frontline ne vise pas à remplacer les éditions Business ou Enterprise, mais bien à optimiser les coûts et les licences quand tout le monde n’a pas besoin d’un Cloud PC permanent.

Et comme souvent avec Microsoft 365 et Intune, le meilleur moyen de comprendre… c’est de tester soi-même ! 😉