Vous avez peut-être déjà entendu parler de Display Protection, vous vous doutez que ça doit bloquer les captures d’écran sur AVD ou Windows 365, mais vous n’avez jamais mis les mains dedans ? Rassurez-vous, la préversion publique vient juste de sortir et cet article est fait pour vous. On part d’un host pool Azure Virtual Desktop tout ce qu’il y a de plus classique, où le Snipping Tool capture allègrement la session, et on va dérouler, capture après capture, jusqu’à un flux d’affichage chiffré que le poste local n’arrive tout simplement plus à copier.
Un mot tout de suite sur le statut : la fonctionnalité est passée maintenant en preview publique. Et pour vous guider plus facilement dans cet article, voici des liens rapides :
- 1. Display Protection, c’est quoi au juste ?
- 2. Ne pas confondre : quatre features qui se ressemblent
- 3. Les trois niveaux de protection
- 4. Les pré-requis
- 5. Étape 0 : la baseline de mon lab AVD
- 6. Étape 1 : la propriété RDP sur le host pool
- 7. Étape 2 : préparer le poste client
- 8. Étape 3 : le moment de vérité
- 9. L’impact réel sur l’environnement
- 10. Bonus Windows 365 : le même réglage dans Intune
- 11. Les codes d’erreur et comment les lire
- 12. Monitoring : l’événement DisplayProtectionState
1. Display Protection, c’est quoi au juste ?
Display Protection est le volet Output Protection de la famille Input and Output Protection 😂. Le principe tient en une phrase : le flux d’affichage est chiffré avant même de quitter le Cloud PC ou la session host, et il n’est déchiffré que dans un chemin de rendu de confiance sur le poste local.
Quand le GPU de l’endpoint sait faire, et Microsoft précise que les GPU intégrés comme discrets sont supportés, le déchiffrement se fait directement dedans. Sinon, on retombe sur un rendu logiciel protégé. Dans les deux cas, un outil de capture qui tourne sur le poste local ne voit plus le contenu de la session : il n’a pas de quoi décoder ce qu’il intercepte.
« …protect display output […] against unauthorized screen capture and recording »
Source : Display Protection for Windows 365 and Azure Virtual Desktop, Microsoft Learn
Trois caractéristiques structurantes à retenir de la documentation. D’abord, seuls les clients Windows App qui atteignent le niveau de protection exigé peuvent ouvrir une session protégée : c’est une exigence de confiance sur l’endpoint, pas un simple réglage cosmétique. Ensuite, le niveau de protection est configurable, avec une option d’exigence HDCP pour les écrans connectés. Enfin, la protection s’applique uniquement à la session distante affichée et ne change rien au comportement du Cloud PC lui-même.
Pour rappel, jusqu’ici, la seule réponse à la question « comment j’empêche un utilisateur de screenshoter sa session ? » était Screen Capture Protection, qui demande poliment à l’OS local de ne pas capturer. Display Protection change la nature du problème : le poste local n’a pas la clé.
2. Ne pas confondre : quatre features qui se ressemblent
C’est le point où tout le monde se mélange les pinceaux, y compris en avant-vente. Quatre fonctionnalités Microsoft parlent de protection de l’écran ou de la frappe, et elles ne font pas du tout la même chose.
| Fonctionnalité | Ce qu’elle protège | Comment | Clients supportés |
|---|---|---|---|
| Display Protection (preview) | L’affichage, contre la capture et l’enregistrement depuis le poste local | Chiffrement du flux d’affichage, déchiffrement dans le GPU ou en rendu logiciel protégé | Windows App sur Windows 11 physique uniquement |
| Screen Capture Protection | La capture d’écran, via les API de l’OS local | Stratégie Intune (settings catalog) ou GPO appliquée à la VM ou au Cloud PC | Windows, macOS, et iOS/iPadOS, Android, web via MAM Intune |
| Watermarking | Rien techniquement, ça dissuade la photo au smartphone | Filigrane à code QR traçable dans la session | Multi-plateformes |
| Input Protection (preview) | Les frappes clavier, contre les keyloggers | Driver noyau et MSI Windows Cloud IO Protect installé sur l’endpoint | Windows 11 physique avec TPM 2.0 |
La nuance qui compte : Microsoft écrit noir sur blanc, à propos de Screen Capture Protection, que la fonctionnalité « doesn’t provide Digital Rights Management (DRM)-level protection ». Display Protection joue dans une autre catégorie, celle du chemin d’affichage protégé de bout en bout. Les deux ne s’excluent pas, elles se complètent dans une logique de défense en profondeur.
3. Les trois niveaux de protection
Azure Virtual Desktop et Windows 365 exposent exactement les mêmes niveaux. C’est le cœur de la décision d’architecture, donc autant les avoir en tête avant de toucher au portail.
| Niveau | Valeur RDP | Comportement |
|---|---|---|
| Not configured | 0 | Pas de protection d’affichage sur le Cloud PC ou la session host. |
| Hardware or software enforcement | 1 | La machine tente d’établir un canal d’affichage protégé matériel. Si la protection matérielle n’est pas disponible, elle bascule sur la protection logicielle. |
| Hardware enforcement required | 2 | Le canal protégé matériel est obligatoire. Si l’endpoint ne peut pas le fournir, la connexion est bloquée et l’utilisateur voit une erreur. |
Dans ce pas-à-pas je reste sur le niveau 1, celui qui ne casse personne : si le GPU du poste ne suit pas, on dégrade vers le logiciel au lieu de refuser la connexion. Le niveau 2 mérite son propre article, avec un parc d’endpoints qualifié en amont, parce qu’il transforme chaque poste non conforme en ticket au support.
4. Les pré-requis
| Élément | Exigence |
|---|---|
| Client | Windows App version 2.0.1236.0 ou plus récente, à mettre à jour depuis le Microsoft Store. |
| Poste local | Un appareil Windows 11 physique. Les machines virtuelles ne sont pas supportées comme endpoint. |
| Machine distante | Cloud PC Windows 365 ou session host Azure Virtual Desktop sur une version d’OS client Windows supportée, ou Windows Server. |
| Affichage | Un écran piloté par le GPU du poste, en sortie HDMI, DisplayPort ou USB-C DisplayPort Alt Mode. Résolution jusqu’à 4K (3840 x 2160). |
| Non supporté | Endpoints virtualisés, macOS, iOS, Android, navigateurs web, et appareils Windows 365 Link. |
Ce tableau, lisez-le deux fois. La moitié des échecs de test viennent de là, en particulier la ligne « poste local » : si vous testez depuis une VM de démo, ça ne marchera jamais, quel que soit le nombre de fois où vous cliquerez sur Reconnect.
5. Étape 0 : la baseline de mon lab AVD
Avant de toucher quoi que ce soit, on documente l’état initial. C’est ce qui rendra la démonstration crédible auprès d’un RSSI, et ça évite de se demander plus tard si le comportement observé vient de la nouvelle configuration ou d’autre chose.
- Depuis le poste Windows 11 physique, ouvrez Windows App et connectez-vous au host pool de test :
- Dans la session distante, affichez quelque chose de reconnaissable : un document, une page, peu importe, tant que c’est identifiable sur une capture :
- Sur le poste local, pas dans la session, déclenchez l’outil Capture d’écran de Windows et capturez la fenêtre de la session. Collez le résultat et constatez : tout est lisible. C’est la situation de départ :
Notez au passage la version exacte de Windows App et la configuration graphique du poste. Ces deux informations vous serviront si un comportement bizarre apparaît plus loin :
6. Étape 1 : la propriété RDP sur le host pool
Côté Azure Virtual Desktop, la configuration passe par une propriété RDP ajoutée sur le host pool. Pas de GPO, pas de clé de registre, pas d’extension à déployer sur les session hosts.
- Dans le portail Azure, ouvrez le host pool cible.
- Allez dans RDP properties, puis l’onglet Advanced.
- Ajoutez la propriété suivante, puis enregistrez.
enableWindowsCloudIODisplayProtection:i:1La valeur finale correspond au niveau choisi : 0 pour not configured, 1 pour hardware or software enforcement, 2 pour hardware enforcement required. Cette propriété active la vérification côté serveur que Display Protection est bien appliqué sur l’endpoint.
Attendez la sauvegarde du changement de la propriété avant de continuer :
7. Étape 2 : préparer le poste client
La configuration est poussée vers l’endpoint à travers les propriétés de connexion RDP, puis mise en cache sur l’appareil. C’est ce cache qui explique la quasi-totalité des faux négatifs lors des tests.
- Vérifiez la version de Windows App sur le poste et mettez-la à jour depuis le Microsoft Store si elle est inférieure à 2.0.1236.0 :
- Dans Windows App, sélectionnez Refresh pour récupérer immédiatement la configuration à jour :
- Fermez la session existante, ne vous contentez pas d’une reconnexion sur une session déjà ouverte.
8. Étape 3 : le moment de vérité
Le moment de vérité. On ouvre une nouvelle session et on refait exactement le même geste qu’à l’étape 0.
- Depuis le poste Windows 11 physique, ouvrez une nouvelle session sur le session host où Display Protection est activé :
- Vérifiez que la connexion aboutit sans message d’erreur. C’est déjà une information : cela veut dire que l’endpoint satisfait le niveau demandé.
- Pendant que la session est active, relancez l’outil de capture sur le poste local et capturez la fenêtre de session.
Et là, magie : le contenu capturé est bloqué ou apparaît vide. Le rectangle est là, l’image ne l’est pas :
Attention, l’accès à Azure Virtual Desktop via le portail Web ne supporte pas cette fonctionalité :
9. L’impact réel sur l’environnement
Une fonctionnalité de sécurité qui ne coûte rien, ça n’existe pas. Voilà ce qui change et ce qui ne change pas.
Ce qui ne change pas : le comportement de la machine distante. La protection porte sur la session affichée, pas sur le Cloud PC ou la session host. Les applications, les stratégies et les outils qui tournent à l’intérieur ne voient pas la différence.
Ce qui change, en revanche, mérite une checklist avant tout déploiement large :
- Performance : quand la protection matérielle n’est pas disponible, la session bascule en protection logicielle, ce qui peut allonger le temps d’établissement de la session. Pour la meilleure expérience, il faut des endpoints avec un GPU compatible.
- Résolution : le plafond est 4K (3840 x 2160). Au-delà, la session protégée n’est pas supportée. Les postes à triple écran haute définition sont à qualifier sérieusement.
- Docks et adaptateurs : les écrans branchés via DisplayLink ou un adaptateur graphique USB ne sont pas supportés, parce qu’ils ne fournissent pas le chemin d’affichage protégé et n’ont généralement pas de support HDCP. La session protégée peut être bloquée (erreur 0x110) ou le contenu protégé peut ne pas s’afficher.
- Câblage : le VGA n’a pas de HDCP, les vieilles stations d’accueil et les moniteurs non HDCP non plus. Il faut viser une sortie HDMI, DisplayPort ou USB-C DisplayPort Alt Mode pilotée par le GPU du poste.
- Parc client : macOS, iOS, Android, les navigateurs web et les appareils Windows 365 Link sont hors périmètre. Si une population utilise ces clients, elle ne pourra pas ouvrir de session protégée.
- Redirections : le presse-papier reste un chemin d’exfiltration, comme démontré à l’étape 3. Si le sujet est vraiment la confidentialité, la désactivation des redirections fait partie du même chantier.
Le piège classique dans un parc d’entreprise : la flotte de portables est branchée sur des docks universels USB en open space. C’est exactement la population qui va tomber sur l’erreur HDCP, et ce n’est pas une question de licence ou de stratégie, c’est du câble.
10. Bonus Windows 365 : le même réglage dans Intune
Sur Windows 365, on ne passe pas par une propriété RDP saisie à la main mais par le centre d’administration Intune.
- Commencez par créer un groupe de machines Windows 365 :
- Connectez-vous au centre d’administration Microsoft Intune, allez dans Devices, puis Manage Windows 365 Cloud PCs, Cloud PC Settings, puis Remote Connection Experience :
- Sous IO Protection, sélectionnez le niveau voulu pour Display Protection :
Les niveaux sont strictement les mêmes que sur AVD, et le mécanisme de propagation aussi : la configuration part vers l’endpoint dans les propriétés de connexion, elle est mise en cache, et le Refresh de Windows App reste le raccourci pour ne pas attendre :
Ouvrez une session Windows 365 sur votre utilisateur de test :
Tout comme AVD, le mécanisme fonctionne très bien depuis un client compatible :
Et comme sur AVD toujours, rien ne passe depuis le navigateur internet :
11. Les codes d’erreur et comment les lire
Quand la protection ne peut pas être établie, la connexion peut être bloquée et un message apparaît sur le poste. Voici la grille de lecture.
| Code | Code étendu | Signification | Causes fréquentes |
|---|---|---|---|
| 0x204 | 0x11f5 | Client incompatible | Connexion depuis iOS, macOS ou Android. Windows App antérieur à 2.0.1236. Configuration récemment activée ou modifiée et pas encore reçue par l’endpoint. |
| 0x204 | 0x11f6 | Stratégie non respectée | L’endpoint retombe sur la protection logicielle, absence de support GPU ou mauvaise configuration GPU, alors que la machine distante exige l’enforcement matériel. |
| 0x110 | aucun | Exigences HDCP non satisfaites | Vieilles stations d’accueil, adaptateurs USB et docks DisplayLink sans HDCP, câbles VGA, moniteurs non HDCP. |
Le réflexe sur un 0x204 avec le code étendu 0x11f5 juste après avoir activé la fonctionnalité : sélectionner Refresh dans Windows App pour tirer la dernière configuration, ou attendre la propagation (jusqu’à 8 heures), puis retenter :
Voici l’erreur rencontrée lors d’une tentative de connexion depuis un poste compatible, mais dont l’ouverture de session est faite depuis Edge, non compatible à ce jour :
À noter que j’ai également rencontré cette erreur lors de la connexion à une session AVD depuis un poste Windows 365 qui ne le supportait pas. On aurait aimé un message d’erreur plus clair :
Si le code ne correspond à aucun de ceux listés par Microsoft, la marche à suivre est de contacter le support avec l’activity ID, l’horodatage de l’échec et les étapes de reproduction.
12. Monitoring : l’événement DisplayProtectionState
Tester sur un poste, c’est bien. Savoir ce qui se passe sur l’ensemble du tenant, c’est mieux, surtout si vous préparez un déploiement progressif.
Et autant vous le dire tout de suite, parce que c’est la première question qu’on se pose : il n’y a rien à vérifier dans l’OS. Ni sur le session host, ni sur le poste local. Pas de clé de registre d’état, pas de journal d’événements, pas de cmdlet. La négociation se fait à l’établissement de la connexion entre Windows App et la machine distante, et c’est le service qui en garde la trace. Le seul point de contrôle documenté est côté tenant.
- Dans le centre d’administration Microsoft Intune, allez dans Reports, puis Cloud PC monitoring (preview).
- Ouvrez l’onglet Connection health.
- Utilisez le sélecteur de plage de temps et les filtres pour cibler les connexions à investiguer.
- Sélectionnez View data pour déplier le volet, puis ouvrez la table Events.
- Ajoutez la colonne du nom d’événement si elle n’est pas affichée, ou cherchez l’événement par son nom.
Deux événements existent, un par composant : KeyboardInputProtectionState pour l’input protection et DisplayProtectionState pour le display protection. Ils servent à confirmer si la protection a été négociée pour une connexion donnée, et à investiguer celles où elle ne s’est pas appliquée.
Conclusion
Voilà, en quatre étapes, de l’étape 0 à l’étape 3, vous êtes passé d’une session AVD que n’importe quel outil de capture pouvait aspirer à une session dont le flux d’affichage est chiffré jusqu’au GPU du poste.
Concrètement, ça donne quoi ? Une ligne de propriété RDP, une mise à jour de Windows App, et un argument de sécurité qui se démontre en deux captures d’écran devant un RSSI. Pas de nouvelle infrastructure, pas d’agent à déployer sur les session hosts.
Les cinq pièges à retenir :
- Le poste doit être un Windows 11 physique avec Windows App 2.0.1236.0 ou plus récent.
- La configuration est mise en cache sur l’endpoint et peut mettre jusqu’à 8 heures à se propager. Le bouton Refresh est votre ami.
- Les docks DisplayLink, les adaptateurs graphiques USB, le VGA et les moniteurs non HDCP sont des générateurs d’erreur 0x110.
- Sans GPU compatible, on bascule en protection logicielle, avec un temps d’établissement de session potentiellement plus long, et un plafond à 4K dans tous les cas.
- Le presse-papier reste ouvert. Sans désactivation des redirections, l’information sort de la session protégée par un simple copier-coller.
Foncez tester en lab, et prenez le temps de qualifier votre parc d’écrans et de docks avant de rêver au niveau 2. C’est cette qualification, plus que la configuration elle-même, qui décidera du succès du déploiement.
Sources
- Display Protection for Windows 365 and Azure Virtual Desktop (Microsoft Learn)
- Input and Output Protection for Windows 365 and Azure Virtual Desktop (Microsoft Learn)
- Windows Cloud Input Protection (Microsoft Learn)
- Enable screen capture protection in Azure Virtual Desktop and Windows 365 (Microsoft Learn)
