Vous les avez peut-être testées en préversion, comme moi : l’orchestration des hôtes de session, la mise à l’échelle dynamique et les disques OS éphémères sur Azure Virtual Desktop. Bonne nouvelle, depuis juin 2026 ces trois briques de gestion avancée des host pools sont annoncées en disponibilité générale. L’occasion de faire le point, de regrouper mes trois anciens tutos de préversion, et surtout de pointer ce qui a changé depuis, car un seul détail peut casser vos anciens déploiements.
Ces fonctionnalités, je les avais chacune détaillées dans un tutoriel pas-à-pas quand elles étaient en préversion. Plutôt que de vous renvoyer vers trois articles vieillissants, je les réunis ici en une synthèse à jour de la GA, avec des liens vers chaque tuto d’origine si vous voulez remettre les mains dans le portail.
1. De la préversion à la GA : ce qui change vraiment
Avant d’entrer dans le détail, un rappel utile sur la notion de fond. Sur Azure Virtual Desktop, un pool d’hôtes partagé se gère de deux façons :
La gestion standard, où vous créez, mettez à jour et scalez vos hôtes avec vos propres outils, et la gestion par configuration d’hôte de session, celle que Microsoft qualifie d’automatisée. C’est cette seconde approche, et les capacités qui gravitent autour, qui passe en GA :
Point de vigilance à connaître dès maintenant : le choix de l’approche se fait à la création du pool d’hôtes et ne peut plus être modifié ensuite :
Un pool créé sans configuration d’hôte de session ne pourra jamais en recevoir une par la suite. Cette approche ne concerne par ailleurs que les pools d’hôtes mutualisés :
À surveiller : à l’heure où j’écris ces lignes, certaines pages de référence Microsoft, comme celle de la mise à jour de l’hôte de session ou celle de l’identité managée, portent encore la mention préversion. Le changelog officiel, lui, annonce bien la disponibilité générale et distingue clairement les nouveautés qui restent en preview. Le plus probable est un simple décalage de documentation, doublé d’un déploiement progressif. À vérifier dans votre tenant avant tout passage en production.
2. L’orchestration des hôtes de session
C’est la brique centrale. La configuration d’hôte de session, ou session host configuration, décrit une bonne fois pour toutes ce que doivent être vos hôtes : image, taille de VM, type de disque, type de sécurité, jonction de domaine, réseau, identité, tags.
Tous les hôtes du pool s’alignent sur cette configuration unique :
Pour faire évoluer votre parc, vous ne touchez plus chaque VM une par une, vous modifiez la configuration :
Puis vous déclenchez une mise à jour de l’hôte de session :
La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de machine virtuelle sous-jacente, l’image du système d’exploitation et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session. La mise à jour de l’hôte de session libère ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour.
Concrètement, la mise à jour ne bricole pas vos VM en place, elle les remplace. Le service cible d’abord un seul hôte, dit initial, pour valider que le processus fonctionne de bout en bout, puis il traite le reste par lots dont vous fixez la taille :
Chaque hôte concerné passe en mode drain, vos utilisateurs connectés reçoivent une notification et un délai avant déconnexion, l’ancienne VM est retirée du pool, une nouvelle est créée depuis la configuration à jour, jointe au domaine puis remise en service :
L’ancienne VM est enfin supprimée. La progression n’avance que lorsqu’un hôte est réellement terminé, ce qui explique qu’elle reste à 0 % pendant le traitement du tout premier.
Bon à savoir : l’état d’alimentation existant est respecté, vous pouvez donc lancer une mise à jour sur un pool dont tous les hôtes sont OFF pour limiter les coûts. Le pas-à-pas complet, du domaine managé jusqu’au déclenchement de la mise à jour, reste disponible dans mon tuto dédié : Orchestrez votre AVD.
3. La mise à l’échelle dynamique : créer et supprimer, pas seulement allumer et éteindre
Le plan de mise à l’échelle existait déjà pour optimiser les coûts d’un pool.
Ce qui arrive en GA, c’est sa méthode dynamique. La différence tient en une phrase :
En gestion de l’énergie, le plan se contente d’allumer et d’éteindre des VM existantes :
En mode dynamique, il crée et supprime réellement les machines virtuelles selon l’usage et la planification, en s’appuyant sur la mise à jour de l’hôte de session pour les recréer dans leur dernière version :
Les phases du plan, elles, ne changent pas : montée en charge, période de pointe, descente en charge et hors-période.
Vous y réglez les seuils de capacité, l’algorithme d’équilibrage, le nombre minimum et maximum de VM, et la déconnexion forcée éventuelle en descente de charge. L’intérêt du dynamique : quand la charge tombe, vous ne payez plus des VM éteintes qui traînent, elles disparaissent, puis se recréent à la demande :
Les mécanismes de fond, eux, restent les mêmes d’une méthode à l’autre.
La mise à l’échelle démarre/crée progressivement des machines virtuelles quand une certaine limite d’utilisateurs est atteinte :
Elle éteint/supprime les machines virtuelles tant qu’elles ne sont pas exploitées :
Elle peut forcer la déconnexion des utilisateurs, uniquement si vous l’avez activé en descente de charge :
Quelques garde-fous à garder en tête : la méthode dynamique vise les pools mutualisés (pas les environnements personnels), s’appuie sur un pool déjà configuré avec la mise à jour de l’hôte de session, et connaît des restrictions selon le type de jonction et l’hébergement.
Le principe : le disque système vit sur le stockage local de l’hôte, pas sur du stockage distant managé :
Résultat, des lectures et écritures à plus faible latence, un provisionnement et une réinitialisation plus rapides :
Et un coût inclus dans celui de la taille de VM :
La contrepartie est assumée, ces disques ne conservent rien au-delà du cycle de vie de la machine :
Le changement de la GA est là. En préversion, l’interface de création d’AVD ne permettait pas de choisir un disque éphémère, ce qui obligeait à un contournement, créer les VM à la main puis les rattacher au pool :
Microsoft annonce désormais les disques éphémères disponibles et optimisés pour Azure Virtual Desktop, et la configuration d’hôte de session inclut les informations du disque OS. La prise en charge devient donc officielle et intégrée, au lieu d’un montage manuel.
Pour bien saisir les différents disques éphémères sur Azure, l’excellente vidéo de John Savill reste la meilleure entrée en matière :
Les contraintes restent les mêmes, et il faut les connaître : pas de sauvegarde de la VM, pas de désallocation, et un redimensionnement qui fait perdre toute la donnée. Pour un pool AVD bâti sur une golden image et qui ne stocke pas de données utilisateur, ce ne sont pas des bloqueurs, plutôt des propriétés à assumer.
5. Le vrai piège : l’identité managée devient incontournable
Si vous relisez mes anciens tutos, vous verrez que je faisais reposer les droits sur l’application de service Azure Virtual Desktop, avec des rôles RBAC assignés à la main sur le Key Vault et un rôle personnalisé pour la lecture de la configuration. Cette mécanique n’est plus la bonne. Microsoft a basculé vers l’identité managée, et ce n’est pas une simple recommandation :
Attention : l’identité managée est devenue nécessaire pour les pools qui utilisent une configuration d’hôte de session. Le calendrier annoncé par Microsoft est sans ambiguïté : depuis le 19 septembre 2025, un nouveau pool de ce type doit être créé avec une identité managée ; depuis le 15 octobre 2025, un pool existant ne peut plus mettre à jour sa configuration sans en ajouter une ; et depuis le 15 novembre 2025, il ne peut plus créer d’hôtes sans elle. Si vous suivez encore la méthode service principal de mes anciens articles, vous allez vous heurter à un mur.
La bonne nouvelle, c’est que l’identité managée simplifie le tableau. Elle supprime le besoin d’assigner des permissions à l’application de service Azure Virtual Desktop, attribue automatiquement les droits en fonction des paramètres de la configuration d’hôte de session, et apporte un contrôle plus fin par pool :
Elle débloque aussi deux cas concrets : l’accès à un Key Vault dont l’accès public est désactivé, réservé aux services Microsoft de confiance, et l’usage d’une image hébergée dans un autre abonnement du même tenant. La marche à suivre est décrite sur la page de configuration de l’identité managée.
Concrètement, ça donne quoi ?
Voilà, en une synthèse, trois briques de préversion réunies et remises à niveau pour la disponibilité générale : la configuration d’hôte de session pour standardiser et mettre à jour votre parc, la mise à l’échelle dynamique pour créer et supprimer les VM au fil de la charge, et les disques éphémères désormais intégrés proprement.
Les pièges à retenir :
L’identité managée n’est plus optionnelle, oubliez la méthode service principal de mes anciens tutos.
L’approche de gestion se choisit à la création du pool et ne se change plus après.
Les disques éphémères ne persistent rien, parfait pour une golden image, à proscrire pour de la donnée utilisateur.
Certaines pages de doc portent encore le label préversion, vérifiez l’état réel dans votre tenant avant la prod.
Si vous avez lu mon article de juillet 2025 sur les VPN Azure et la deadline du 30/09, vous vous souvenez du test avec une VPN Gateway Basic SKU avec une IP publique dynamique. Le verdict était brutal : suppression de la connexion, suppression de la gateway, impossibilité de migrer l’IP dynamique, création d’une nouvelle IP Standard, recréation complète de la gateway, changement d’adresse IP à la clé. Un calvaire. Bonne nouvelle : Microsoft a depuis simplifié la procédure pour les VPN Gateways Basic SKU. En 2026, c’est un clic dans le portail, sans coupure réseau, sans changement d’IP, en moins de cinq minutes.
Pour rappel, jusqu’ici les VPN Gateways Basic SKU pouvaient être créées avec une IP publique Basic SKU. Azure a migré ces IPs en interne vers des IPs Standard SKU depuis. Il reste une dernière action à faire côté client : supprimer la référence à l’ancienne ressource IP Basic dans la configuration de la gateway. C’est ce qu’on va faire ensemble, capture après capture.
Attention : cet article concerne uniquement la VPN Gateway Basic SKU (le SKU développement/lab, sans SLA). Si vous avez une gateway VpnGw1 à VpnGw5 ou un SKU legacy (Standard, High Performance), le processus est différent : utilisez l’outil de migration dédié dans la Configuration de la gateway. Ce n’est pas ce dont on parle ici.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Avant de toucher quoi que ce soit, vérifiez que vous êtes bien dans le cas de figure de cet article. Le piège classique : confondre « VPN Gateway Basic SKU » et « IP publique Basic SKU ». Ce sont deux ressources distinctes. Ici, on parle bien du SKU de la gateway elle-même.
Situation
Action
VPN Gateway Basic SKU avec une référence à une IP publique Basic SKU
✅ Vous êtes concerné par cet article
VPN Gateway Basic SKU sans référence IP Basic (déjà nettoyée)
✅ Rien à faire, vous êtes bon
VPN Gateway VpnGw1 à VpnGw5 (non-AZ ou AZ)
❌ Pas cet article : utiliser l’outil « Migrate to Standard IP » dans Configuration
VPN Gateway SKU legacy (Standard, High Performance)
❌ Pas cet article : suivre le guide de migration dédié Microsoft
Pour rappel, la VPN Gateway Basic SKU est un SKU développeur, sans SLA. Elle ne retire pas, contrairement à ce que beaucoup pensaient (moi y compris, au moment de mon article 2025). Microsoft a confirmé qu’elle reste disponible : c’est uniquement la référence à l’IP Basic qui doit être nettoyée.
2. Étape 0 : identifier la présence de la référence IP Basic
Deux façons de vérifier si votre gateway est concernée : depuis la CLI Azure ou directement depuis le portail.
Via Azure CLI : récupérez d’abord l’ID de l’IP publique associée à votre gateway.
az network vnet-gateway show \
--name <nom-de-votre-gateway> \
--resource-group <votre-resource-group> \
--query "ipConfigurations[].publicIpAddress.id" \
--output tsv
Copiez l’ID retourné, puis vérifiez le SKU de cette IP :
az network public-ip show \
--ids <id-copié-ci-dessus> \
--query "sku.name" \
--output tsv
Si la commande retourne Basic, vous êtes concerné. Si elle retourne Standard, votre gateway est déjà propre :
Via le portail Azure : naviguez vers votre ressource Virtual network gateway. Dans le menu de gauche, sous Settings, cliquez sur Configuration. Si votre gateway est concernée, vous verrez une section Validation avec un bouton Delete Basic Public IP Reference. C’est la confirmation visuelle que vous devez agir.
Si vous ne voyez pas cette section, soit votre gateway n’a plus de référence IP Basic (déjà nettoyée), soit vous n’êtes pas sur un gateway Basic SKU.
3. Étape 1 : vérifier la validation dans le portail
Toujours sur la page Configuration, regardez la section Validation. Chaque ressource listée doit afficher le statut Succeeded avant de pouvoir continuer.
Attention : si une ou plusieurs ressources affichent un statut autre que Succeeded, ne continuez pas. Résolvez d’abord les erreurs signalées avant de déclencher la suppression.
4. Étape 2 : supprimer la référence IP Basic
Toutes les ressources sont en Succeeded ? Le moment de vérité. Cliquez sur le bouton Delete Basic Public IP Reference.
Concrètement, ça donne quoi ? Cette action retire l’association entre la ressource IP publique Basic SKU et la gateway. Ce n’est pas une migration. Azure avait déjà basculé l’IP en interne vers une ressource Standard SKU non visible dans votre subscription : vous ne faites que supprimer le pointeur côté client.
This action removes the association between your Basic SKU public IP address resource and the Basic SKU VPN gateway. It’s not a migration operation. The public IP address itself is already moved internally by Azure to a Standard SKU public IP address resource used by the VPN gateway.
Mon retour terrain : dans mon article de 2025, le Test III montrait qu’il fallait supprimer la connexion VPN, supprimer la gateway, recréer une IP Standard, et tout reconstruire. L’IP changeait au passage. C’était le comportement de l’époque pour une IP dynamique. La procédure 2026 est radicalement différente pour la Basic SKU Gateway : un bouton, zéro downtime, l’IP reste la même. Microsoft a bien bossé sur ce point.
5. Étape 3 : vérifier le résultat
Une fois l’opération terminée, retournez sur la page de la gateway. Et là, surprise possible : l’adresse IP peut apparaître comme null dans le portail, ou le nom de l’ancienne ressource IP Basic est encore affiché sans lien cliquable.
Attention : ce comportement est un bug cosmétique connu et documenté par Microsoft. La gateway fonctionne parfaitement, l’IP n’a pas changé, et vos connexions S2S/P2S continuent de tourner. Ne paniquez pas.
Pour vérifier l’IP réelle utilisée par la gateway, deux options. Depuis le portail, cliquez sur JSON View en haut à droite de la page Overview de la gateway : les propriétés réelles de la ressource y sont correctement renseignées, avec l’adresse IP effective.
Ou depuis la CLI, via la propriété tunnelIpAddresses :
az network vnet-gateway show \
--name <nom-de-votre-gateway> \
--resource-group <votre-resource-group> \
--query "bgpSettings.bgpPeeringAddresses[0].tunnelIpAddresses[0]" \
--output tsv
6. Étape 4 : supprimer l’ancienne ressource IP Basic
La suppression de la référence ne supprime pas la ressource IP publique Basic SKU de votre subscription. Elle reste dans votre resource group, et Azure continue de vous la facturer tant que vous ne la supprimez pas manuellement.
Depuis le portail, naviguez vers votre resource group, repérez la ressource de type Public IP address avec le SKU Basic, et supprimez-la. Ou en CLI :
az network public-ip delete \
--name <nom-de-votre-ip-basic> \
--resource-group <votre-resource-group>
Une fois supprimée, la facturation de cette ressource s’arrête. La gateway continue d’utiliser une IP Standard SKU gérée en interne par Azure, non visible et non facturée séparément dans votre subscription.
7. Pièges à éviter
Piège n°1 : tenter d’upgrader l’ancienne ressource IP Basic manuellement. Après avoir supprimé la référence, vous pourriez être tenté d’upgrader la ressource IP Basic restante vers un Standard SKU via le portail ou PowerShell. Ne le faites pas. Microsoft a documenté que cette tentative provoque un état de provisionnement Failed sur la ressource. La bonne action est la suppression pure et simple, pas l’upgrade.
Piège n°2 : paniquer devant l’affichage null dans le portail. Comme vu à l’étape 3, le portail peut afficher l’IP comme null ou encore le nom de l’ancienne ressource Basic sans lien. C’est purement cosmétique. Fiez-vous à la vue JSON ou à la CLI pour vérifier l’état réel, et testez vos tunnels VPN : ils fonctionnent.
Piège n°3 : ne rien faire avant le 30 juin 2026. Si vous ne supprimez pas la référence avant la deadline, votre gateway continuera de fonctionner, mais dans une configuration non supportée, sans garantie de SLA. Microsoft ne viendra pas corriger ça pour vous. La VPN Gateway Basic SKU est déjà un SKU sans SLA en temps normal : sans cette action, elle perd toute couverture de support.
8. Questions fréquentes
Microsoft a publié une FAQ détaillée sur cette procédure. Voici les points que je trouve les plus utiles à avoir en tête.
Cette opération change-t-elle le SKU ou migre-t-elle ma gateway ?
Non. C’est le point qui perturbe le plus : on parle de « migration IP » partout, mais cette opération ne migre rien et ne change pas le SKU de la gateway. Elle supprime uniquement la référence côté client.
This operation doesn’t change the VPN Gateway SKU and doesn’t migrate the gateway. It only removes the reference to the Basic SKU public IP address resource from the gateway configuration.
La valeur de l’IP ne change pas. En revanche, après l’opération, la ressource IP publique Basic SKU côté client n’est plus liée à la gateway. L’IP est désormais portée par une ressource Standard SKU interne, non visible dans votre subscription.
The IP address value itself doesn’t change and continues to be used by the VPN gateway. However, after removing the reference: the customer-visible Basic SKU public IP address resource is no longer linked to the gateway. The IP address is now associated with an internal Standard SKU public IP address resource that isn’t visible in your subscription.
Pourquoi ne puis-je pas accéder à la nouvelle ressource IP Standard créée par Azure ?
Parce qu’elle est intentionnellement invisible. C’est une ressource interne Azure-managed, hors du périmètre de votre subscription. Vous ne pouvez pas la gérer, la voir, ni la facturer.
The Standard SKU public IP address that’s used by the VPN gateway after this process is an internal Azure-managed resource. It isn’t customer-visible or customer-manageable.
L’opération elle-même n’entraîne aucun nouveau frais. Mais l’ancienne ressource IP Basic reste dans votre subscription et continue d’être facturée jusqu’à sa suppression manuelle. La nouvelle IP Standard interne, elle, n’est pas facturée séparément.
Dis-associating the Basic public IP reference from your VPN gateway doesn’t introduce any new charges and doesn’t result in additional billing. Once you delete it, billing for that Basic public IP resource stops. Your VPN gateway continues to use an internally managed Standard SKU public IP address provided by Azure. This internal Standard SKU public IP address isn’t customer-visible and isn’t billed separately.
Que se passe-t-il si je ne fais rien avant le 30 juin 2026 ?
Votre gateway continue de tourner, mais dans une configuration officiellement non supportée. Pas de SLA, pas d’intervention Microsoft. Et contrairement à ce qu’on pourrait espérer, Microsoft ne fera rien à votre place.
If you don’t take action, your VPN gateway will continue running in an unsupported state. The VPN Gateway Basic SKU doesn’t include SLA guarantees and isn’t intended for production use. Microsoft won’t automatically modify or clean up resources in your subscription. Your gateway might continue to function, but reliability, availability, and support aren’t guaranteed.
Voilà, en quatre étapes : vérification CLI ou portail, validation de la section Configuration, clic sur Delete Basic Public IP Reference, suppression de l’ancienne ressource IP Basic. Dix minutes grand maximum, zéro coupure réseau, l’IP ne change pas.
Par rapport à la situation de 2025 décrite dans mon article sur la deadline du 30/09, Microsoft a vraiment simplifié la procédure pour le cas VPN Gateway Basic SKU. En 2025, le seul chemin pour une IP dynamique était la destruction et la recréation complète, avec changement d’IP à la clé. En 2026, c’est un bouton dans le portail.
Les trois pièges à retenir :
Ne pas tenter d’upgrader l’ancienne ressource IP Basic après dissociation, sous peine de la mettre en état Failed.
L’affichage null dans le portail est cosmétique : vérifier via la vue JSON ou la CLI.
Deadline le 30 juin 2026. Microsoft ne fait rien pour vous si vous ne bougez pas.
Foncez tester en lab si vous n’êtes pas encore passé à l’acte, et planifiez la prod dans la foulée. C’est le genre d’opération qui se fait en dix minutes et qui évite une mauvaise surprise après le 30 juin.
Et pendant que vous êtes dans le portail Azure, profitez-en pour jeter un œil au Service Retirement Workbook, accessible depuis Azure Advisor > Workbooks > Service Retirement. Ce classeur liste toutes vos ressources impactées par des retraits Azure en cours, avec les dates d’échéance et les actions recommandées. Je l’avais déjà présenté dans mon article de 2025 et il reste, aujourd’hui encore, le meilleur moyen de ne rien rater dans votre tenant.
Que peut bien dire le titre de cet article ? Vous avez peut être déjà entendu parler des Context-based Redirections à droite à gauche, vous savez vaguement ce dont ça parle, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On va dérouler, écran après écran, jusqu’à voir une redirection (presse-papiers, lecteurs, imprimante, USB…) s’activer pour une machine conforme et se couper net pour une machine non conforme.
Pour rappel, jusqu’ici une politique de redirection sur AVD ou Windows 365 était binaire : si vous bloquiez le presse-papiers (ou les lecteurs, l’USB, l’imprimante), c’était bloqué pour tout le monde, sur tous les appareils : le portable corporate conforme comme le téléphone perso en BYOD. La seule parade, c’était de maintenir deux host pools séparés.
Avec les Context-based Redirections, on peut enfin faire varier la redirection au niveau de chaque connexion, selon la conformité de l’appareil, le réseau, ou le rôle de l’utilisateur. Un seul host pool, deux comportements. C’est du Zero Trust appliqué à la redirection.
Attention : au moment où j’écris ces lignes, la fonctionnalité est en Public Preview. À tester en lab, pas en prod. Et elle n’est supportée que via les clients Windows App (Windows, web, Android, iOS, macOS), le bon vieux mstsc ne participe pas au mécanisme.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Concrètement, ça donne quoi ? C’est une capacité qui applique des politiques d’accès granulaires aux redirections client, en s’appuyant sur un contexte d’authentification Microsoft Entra. L’idée : la redirection n’est autorisée que si la session atteint le niveau de confiance exigé.
La redirection contextuelle permet aux organisations de contrôler le comportement de redirection en fonction des conditions d’utilisateur et de session.
À l’aide du contexte d’authentification, les administrateurs peuvent définir quand des fonctionnalités client spécifiques doivent être autorisées ou restreintes en fonction de facteurs tels que le rôle d’utilisateur, la conformité de l’appareil ou l’emplacement réseau.
Cela permet de s’assurer que les données sensibles sont accessibles uniquement lorsque la session répond au niveau de confiance requis.
Le point que je veux marteler tout de suite, parce que je vais beaucoup parler du presse-papiers dans la démonstration : la fonctionnalité ne se limite pas au copier-coller. Microsoft documente quatre redirections pilotables par contexte d’authentification :
Clipboard : le presse-papiers (copier-coller texte, image, fichier… dans un sens ou dans l’autre).
Drive : les lecteurs locaux (fixes, amovibles, réseau) remontés dans la session distante.
Printer : la redirection d’imprimante.
USB : la redirection des périphériques USB.
Attention, il est possible que ces options ne soit pas encore visibles sur votre tenant. Cela n’est qu’une question de jours.
Dans cet article, je teste le clipboard et les lecteurs, tout simplement parce que ce sont les deux redirections que j’avais déjà sous la main, restreintes via mes anciennes polices (j’y reviens juste en dessous). Mais le principe, l’enchaînement des trois couches, la logique d’évaluation à la connexion : tout est rigoureusement identique pour l’imprimante et l’USB. Si vous savez piloter le presse-papiers par contexte, vous savez piloter les quatre. Vous remplacez juste la redirection ciblée dans la dernière couche.
Pour info : la policy Remote Connection Experience expose chacune de ces redirections avec le même menu déroulant. Pour chaque ligne, vous choisissez « activé », « non configuré » ou « contexte d’authentification ». C’est ce dernier choix qui déclenche tout le mécanisme, et il se présente exactement de la même façon que vous soyez sur Clipboard, Drive, Printer ou USB.
2. Pourquoi maintenant ? Le durcissement par défaut depuis mi-2025
Petit détour utile pour comprendre pourquoi cette fonctionnalité tombe à pic. Depuis mi-2025, Microsoft a basculé d’une logique « tout ouvert, à vous de durcir » vers du secure by default : sur les nouvelles images Windows 365 et les nouveaux host pools AVD, les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désactivées nativement. C’est aligné avec la Microsoft Secure Future Initiative (SFI).
J’ai déjà décortiqué ces deux sujets dans le détail, et je vous renvoie à mes articles précédents si vous voulez creuser le sujet :
Configurez le presse-papier dans AVD/W365 : le durcissement par défaut depuis le 18 juin 2025, la logique des deux couches (propriétés RDP côté client + polices GPO/Intune côté serveur), et le détail des niveaux SCClipLevel / CSClipLevel.
AVD : Restriction du Presse-papier : comment restreindre finement le copier-coller via Intune et les propriétés RDP, sens par sens et type de donnée par type de donnée.
Là où le bât blessait : cette restriction par défaut, bien qu’affinée, restait globale :
Au niveau des configurations RDP d’Azure Virtual Desktop :
Au niveau des polices de configuration Intune :
Une fois le presse-papiers (ou les autres) bloqué ou débloqué, il l’était pour toutes les connexions, sans distinction de l’appareil ou du réseau :
C’est exactement le mur que les Context-based Redirections font tomber : on garde la posture « fermé par défaut », mais on rouvre dynamiquement pour les connexions de confiance.
D’où l’enchaînement logique de cet article : on part d’un environnement où la redirection est restreinte, et on la rend conditionnelle :
3. Comment ça marche : l’architecture en 3 couches
C’est LE point à comprendre avant de cliquer partout. Le mécanisme repose sur trois couches qui s’enchaînent :
Le contexte d’authentification : un simple « jeton » d’exigence que l’on définit dans Entra et que l’on « publie ».
La policy d’accès conditionnel (CA) : elle cible ce contexte et impose une exigence (appareil conforme, réseau de confiance, MFA…). C’est elle qui décide si le claim c1 est émis ou non dans le token de session.
La policy Remote Connection Experience (RCE) côté Windows 365 (ou la propriété RDP du host pool côté AVD), qui lie une redirection donnée (clipboard, drive, printer ou USB) au contexte.
La logique de bout en bout, à la connexion :
La redirection est liée à c1 → elle est OFF par défaut, et ne s’allume que si le claim c1 est présent dans le token de session.
Le claim c1 n’est présent que si le step-up d’authentification pour c1 réussit.
Ce step-up réussit si aucune CA ne le bloque, ou si une CA qui le cible est satisfaite.
Mon retour terrain : la CA ne sert qu’à poser des exigences sur l’émission du claim c1. S’il n’y a aucune CA qui cible c1, rien ne bloque → le claim passe → vous avez vos redirections (selon ce que la RCE autorise). Dès qu’une CA cible c1, il faut la satisfaire ; si vous êtes bloqué par elle, le claim n’est jamais émis → redirection coupée. C’est aussi simple que ça, mais ça m’a pris un paquet de tests pour le formuler clairement.
4. Pré-requis
Brique
Ce qu’il vous faut
Poste de travail virtuel
Windows 365 Enterprise (Cloud PC) ou Azure Virtual Desktop
Identité & accès conditionnel
Microsoft Entra ID P1 (minimum) pour le Conditional Access
Gestion des stratégies
Microsoft Intune (config + RCE policy + conformité)
Client de connexion
Windows App (Windows / web / Android / iOS / macOS). Pas mstsc.
Image / agent
Cloud PC sur image récente prenant en charge la preview
Pré-requis à valider selon votre déploiement (W365 ou AVD).
5. Étape 0 : Débrayer les restrictions par défaut
Le piège classique, et il est sournois : sur les images récentes de Cloud PC (et les nouveaux pools d’hôtes AVD), les redirections client sont désactivées par défaut :
C’est précisément le durcissement dont je parlais à la section 2. Si vous laissez ça en l’état, vous allez croire que votre conf context-based « bloque bien »… alors qu’en réalité c’est juste le défaut restrictif qui parle. Et surtout : la policy la plus restrictive l’emporte. Tant qu’une stratégie restreint la redirection « en dur », le mécanisme context-based ne pourra jamais l’autoriser.
Si vous utilisez une image de galerie récente pour tester votre PC cloud ou si vous avez des stratégies existantes dans votre environnement qui affectent les redirections, modifiez-les avant le test, car la stratégie la plus restrictive l’emporte.
Par conséquent, vous devez définir les redirections que vous souhaitez tester pour qu’elles soient « non configurées » ou « activées » pour que la redirection basée sur le contexte fonctionne correctement.
La parade : créer (ou réutiliser) une policy Settings catalog dans Intune qui remet les redirections que l’on veut tester sur Disabled au sens « Do not allow… = Disabled » :
Autrement dit, on désactive la désactivation, donc on autorise. 😅
Dans mon lab, je m’appuie justement sur le groupe et les polices que j’avais montés pour mes articles précédents sur le presse-papiers : c’est mon point de départ « fermé », que je vais rouvrir conditionnellement.
Plateforme : Windows 10 and later ; type de profil : Settings catalog → Create.
Basics : donnez un nom parlant et une description.
Configuration settings → + Add settings.
Pour le presse-papiers, les lecteurs et l’USB : recherchez Device and Resource Redirection, sélectionnez la catégorie, puis cochez les réglages à piloter :
Pour l’imprimante : recherchez Printer Redirection (catégorie distincte) et cochez les réglages voulus :
Basculez chaque réglage « Do not allow… » sur Disabled. On ne veut aucune interdiction « en dur » sur les redirections qu’on va confier au contexte
Scope tags (facultatif) → Next
Assignments : ciblez le groupe qui doit recevoir la policy → Next
Review + create → Create
Une fois la configuration poussée sur le poste, cela nous donne la configuration de registre suivante :
Pour info : sous le capot, ces réglages pilotent les valeurs de registre RDP côté session (par ex. fDisableClip pour le presse-papiers, fDisableCdm pour les lecteurs). « Débrayé à 0 » = redirection autorisée. Si vous voulez le détail de ces clés, des deux couches client/serveur et des niveaux SCClipLevel / CSClipLevel, tout est dans mon article Configurez le presse-papier dans AVD/W365.
6. Étape 1 : Créer le contexte d’authentification (c1)
Première vraie brique du mécanisme. Le contexte d’authentification, c’est ce « jeton d’exigence » qu’on va ensuite cibler depuis la CA et lier depuis la RCE. Pas à pas :
Cochez impérativement Publish to apps, puis choisissez une valeur dans le menu ID (ici c1)
Sauvegardez
Attention : si Publish to apps n’est pas coché, vous pourrez bien référencer c1 dans la RCE policy, mais il ne sera jamais sollicité à la connexion. Résultat : la CA reste en « Not Applied » et rien ne se déclenche. C’est l’oubli n°1.
C’est ici que se joue la « condition de confiance ». Le squelette est toujours le même : la CA cible le contexte d’authentification c1 (dans Target resources, pas dans les conditions !), et c’est le Grant (ou l’exclusion) qui décide. Je vous donne trois cas de figure que j’ai testés.
Cas n°1 : Exiger un appareil conforme compliant
Le scénario BYOD par excellence : redirection autorisée depuis une machine gérée et conforme, coupée depuis une machine perso non gérée.
Conditional Access → Policies → New Policy :
Donnez un nom, puis des utilisateurs : All users sous Include (ou votre groupe de test) :
Target resources → menu Select what this policy applies to → Authentication context → cochez c1 :
Grant → Grant access → cochez Require device to be marked as compliant → Select.
Enable policy = On → Create.
Cas n°2 : Restreindre par adresse IP (Named location)
Ici on veut : redirection autorisée uniquement depuis un réseau de confiance (votre plage IP publique), coupée ailleurs.
Le point clé à intégrer : une location, c’est une CONDITION, pas un grant. On ne peut pas dire « autorise si IP de confiance ». La bonne logique est inversée : « Bloque c1 partout, SAUF depuis l’IP de confiance ».
D’abord, créez la Named location :
Conditional Access → Named locations → + New location (IP ranges)
Nommez-la et saisissez votre plage IP publique en CIDR (ex. 203.0.113.42/32)
Cochez Mark as trusted location si proposé → Create
Ensuite, la CA :
Users : All users (ou groupe de test)
Target resources → Authentication context → c1
Conditions → Locations : Include = Any location ; Exclude = Loc-Confiance
Grant → Block access → Select
Enable policy = On → Create
Attention : le Conditional Access voit l’IP publique de sortie du client. Derrière un NAT ou un proxy d’entreprise, c’est l’IP du NAT qu’il faut déclarer, pas celle du poste. Et si votre IP est dynamique (box FAI), le test peut « sauter » quand elle change. Élargissez la plage plutôt qu’un /32 figé.
Cas n°3 : Combiner conformité & adresse IP
Pourquoi pas les deux ? Pour exiger à la fois un appareil conforme et un réseau de confiance, deux approches :
Une seule CA : ciblez c1, Grant = Require device to be marked as compliant, ET ajoutez la condition Locations (Include = la location de confiance) pour ne l’évaluer que sur ce réseau. Hors réseau de confiance, prévoyez une seconde CA de blocage.
Deux CA qui ciblent c1 : une exige le compliant, l’autre bloque hors réseau de confiance. Comme toutes les CA ciblant c1 doivent passer, le claim n’est émis que si appareil conforme et sur réseau de confiance.
Mon retour terrain : quand plusieurs CA ciblent c1, elles se cumulent (« most restrictive wins » côté claim). Pour un test propre d’un seul cas, mettez les autres CA ciblant c1 sur Off le temps de l’essai, sinon vous ne saurez plus laquelle bloque.
8. Étape 3 : La police Remote Connection Experience (et la variante AVD)
C’est la couche qui lie une redirection au contexte c1. Côté Windows 365, ça passe par une policy Remote Connection Experience (preview). C’est aussi ici que vous décidez quelle(s) redirection(s) parmi les quatre (Clipboard, Drive, Printer, USB) vous confiez au contexte :
Intune → Devices → Manage Windows 365 Cloud PCs → Cloud PC Settings
Create → Remote Connection Experience (preview) :
Basics : nom et description de la police :
Dans Configuration settings → Device redirections, repérez la redirection à piloter (Clipboard, Drive, Printer ou USB) et choisissez Authentication context: Context-based redirection :
Dans le champ Entra Authentication context qui apparaît, sélectionnez c1.
Laissez les redirections non voulues sur Not configured.
Scope tags (facultatif) → Next :
Assignments → Add groups → sélectionnez un groupe de DEVICES (les Cloud PC), surtout pas un groupe d’utilisateurs → Next :
Review + create → Create :
Veillez à affecter cette stratégie d’expérience de connexion à distance Windows 365 à des groupes d’appareils (PC cloud), et non à des groupes d’utilisateurs.
La redirection basée sur le contexte étant appliquée au niveau de l’appareil, l’attribution de la stratégie aux utilisateurs n’applique pas le comportement de redirection attendu.
Pas de RCE policy : la liaison se fait dans les propriétés RDP du host pool. Dans l’onglet Device redirection, au lieu d’un toggle activé/désactivé, vous choisissez « Dynamically configure using authentication context » et sélectionnez le contexte. La logique d’évaluation à la connexion est la même qu’en Windows 365.
9. Pièges & retour terrain
Le piège qui m’a rendu fou : la persistance du token Windows App : Windows App garde un token de session en cache. Tant que ce token vit, le résultat du step-up c1 (présent ou absent) est figé dedans. Vous pouvez changer la CA et la RCE mille fois, la session en cours ne réévalue rien. Il faut un token frais : vraie déconnexion/reconnexion. Ne perdez pas trois heures comme moi à modifier des policies : reconnectez-vous avec une session neuve.
Client non supporté : avec mstsc / Bureau à distance legacy, c1 n’est jamais demandé. Passez par Windows App.
Assignation RCE sur des users : la RCE/context-based s’applique au device. Assignée à un groupe d’utilisateurs, elle ne fait rien. Groupe de devices (Cloud PC) obligatoire.
« Publish to apps » oublié sur le contexte d’authentification → c1 jamais sollicité → CA « Not Applied ».
Restrictions par défaut non débrayées → « most restrictive wins » → la redirection reste coupée quoi que vous fassiez.
Direction du clipboard : le binding porte sur une direction précise (ex. « clipboard local disponible dans la session distante » = copie sur votre PC → colle DANS le Cloud PC). Testez bien la direction que vous avez liée à c1.
Propagation lente : comptez quelques minutes côté CA, et au premier déploiement la RCE peut nécessiter un redémarrage du Cloud PC avant d’être prise en compte.
10. Conclusion
Voilà, comment en 4 étapes, on est passé d’un Cloud PC tout neuf à une redirection dynamique qui s’adapte à la confiance de la connexion. Concrètement, ça donne quoi ? Un seul host pool / une seule conf, et la redirection (presse-papiers, lecteurs, mais aussi imprimante et USB sur exactement le même modèle) qui s’ouvre pour les machines conformes (ou sur le bon réseau) et qui se ferme pour le reste.
Le rêve du BYOD sans compromis. J’ai testé le clipboard et les lecteurs, mais gardez bien en tête que les quatre redirections se pilotent à l’identique : c’est la même mécanique de bout en bout.
Foncez tester en lab, c’est clairement l’une des évolutions sécurité les plus utiles de l’année sur AVD / Windows 365. Einfin pour aller plus loin : quelques lectures qui complètent bien le sujet, et que je vous recommande :
Vous avez vu passer l’annonce Microsoft parlant d’une file share comme une ressource Azure de premier niveau et vous vous dites : mais attendez, les partages de fichiers existent depuis des années dans Azure, où est la nouveauté ? Cet article est fait pour vous. On va partir du modèle historique : le compte de stockage pour dérouler ce que change vraiment le nouveau provider Microsoft.FileShares, passé en GA en 2026, et surtout vous aider à trancher : vous migrez, ou pas encore ?
Azure Files introduit une nouvelle expérience de gestion des services de partage de fichiers, désormais généralement disponible, dans laquelle les partages sont déployés en tant que ressources Azure indépendantes et de niveau supérieur via le Microsoft.
Chaque partage de fichiers a des performances dédiées, la sécurité, la mise en réseau et la facturation, ce qui permet une meilleure isolation, des performances prévisibles et un suivi précis des coûts.
L’expérience améliore également considérablement la mise à l’échelle et l’efficacité, prenant en charge jusqu’à 10 000 partages par abonnement par région, un provisionnement plus rapide et une automatisation native cloud via des modèles ARM, des Bicep et des flux de travail CI/CD.
Il est actuellement disponible pour les partages NFS 4.1.
C’est la première confusion qu’il faut lever, parce qu’on l’entend partout : « des partages de fichiers, Azure en propose depuis longtemps ». Vrai… et faux. Jusqu’ici, le partage de fichiers n’a jamais été une ressource Azure à part entière. C’était toujours un objet enfant, créé à l’intérieur d’un compte de stockage. La ressource Azure, celle que vous voyiez dans votre groupe de ressources, c’était le compte de stockage et pas le partage :
Cette nuance n’est pas de la sémantique : c’est elle qui explique 90 % des frictions qu’on va voir. Tant que le partage était un sous-objet, il héritait de tout ce qui appartenait au compte. Le nouveau modèle casse précisément cet héritage.
2. Avant : tout partait du compte de stockage
Pour rappel, jusqu’ici le schéma était le suivant : vous créiez un compte de stockage, vous choisissiez un SKU (général avec blobs/queues/tables, ou un SKU dédié file storage), puis vos partages SMB ou NFS sous ce compte. Tout partait de là, et c’est là que les ennuis commençaient.
Les limites sont partagées. IOPS, capacité provisionnée, débit : c’est le compte qui porte les plafonds, et tous les partages se les répartissent. Un partage gourmand peut pénaliser les autres.
Le control plane aussi est mutualisé. Créer, modifier, supprimer des partages, gérer les snapshots : ces opérations tapent dans des quotas au niveau du compte. À plusieurs administrateurs sur le même compte, ça devient un point de contention :
Le réseau est hérité. C’est le compte de stockage qui porte la configuration réseau. Vos private endpoints, vos règles, vous les héritez du compte, donc pas de granularité par partage :
La facturation est au niveau du compte. Bon courage pour faire du showback / chargeback propre par partage : il faut décortiquer une facture agrégée :
La clé de compte est toute-puissante. La fameuse account key donne accès à tout ce qui vit dans le compte de stockage. Côté sécurité, c’est un secret à très large rayon d’action :
Le piège classique : au moment de créer un compte de stockage, le nombre d’options (SKU, type, redondance, protocoles…) est tel qu’on ne sait plus exactement ce qu’on configure. Beaucoup de comptes finissent surdimensionnés ou mal typés « au cas où ».
3. Après : Microsoft.FileShares, ressource de premier niveau
Concrètement, ça donne quoi ? Microsoft introduit un nouveau provider de ressources, Microsoft.FileShares, et avec lui un nouveau type de ressource top-level : le partage de fichiers lui-même. Pas d’enfant, pas de parent compte de stockage. Vous créez directement un file share dans un groupe de ressources et un abonnement, vous lui donnez un nom, et c’est tout.
Nous annonçons la mise à disposition générale d’une nouvelle expérience de gestion des services pour les partages de fichiers SSD Premium (NFS), qui permet de créer, sécuriser, faire évoluer et facturer chaque partage de fichiers de manière indépendante, sans être lié à un compte de stockage.
Gestion familière et intuitive des partages de fichiers : l’expérience utilisateur s’aligne sur les modèles des NAS et des serveurs de fichiers sur site, ce qui améliore la convivialité par rapport au modèle classique.
Infrastructure-as-Code : définissez la nomenclature, la capacité, les IOPS, la mise en réseau, les balises et la sécurité dans des modèles Bicep ou ARM pour une automatisation simplifiée avec vos outils DevOps préférés.
Évoluez en fonction de la charge de travail : prise en charge de jusqu’à 10 000 partages de fichiers par abonnement et par région, avec une expérience de provisionnement des partages de fichiers 2,5 fois plus rapide.
Sécurité et réseau au niveau des partages : restrictions réseau, instantanés et chiffrement limités au partage individuel, ce qui permet de faire correspondre les limites d’isolation aux limites de la charge de travail.
Visibilité des coûts par partage : les compteurs de facturation s’affichent sous la ressource de partage de fichiers, ce qui permet aux équipes d’effectuer des refacturations précises, de suivre les coûts par charge de travail et d’améliorer la refacturation sans avoir recours à des solutions de contournement.
Au jour du GA, le périmètre est volontairement resserré :
Tier SSD uniquement
Protocole NFS 4.1 uniquement
Facturation alignée sur le modèle provisioned v2 SSD
Côté résilience, vous choisissez LRS ou ZRS
Capacité, IOPS et débit se provisionnent indépendamment
Azure file share using Microsoft.FileShares is now generally available… shares are deployed as independent, top-level Azure resources through the Microsoft.FileShares resource provider, removing the dependency on storage accounts.
Assez de théorie, passons aux mains dans le cambouis. Le mieux pour comprendre ce qui change, c’est de dérouler la création d’un partage dans le portail. Vous allez voir : il n’y a plus jamais le mot « compte de stockage » dans le parcours.
Étape 0 : Le nouveau point d’entrée « File shares »
Depuis l’accueil du portail, vous cherchez directement File shares. C’est un hub à part entière, qui liste vos partages comme des ressources autonomes :
Étape 1 : Les bases : abonnement, groupe de ressources, nom
On clique sur Create. Et là, surprise par rapport au monde d’avant : on vous demande un abonnement, un groupe de ressources et un nom de partage. Point. Exactement comme pour n’importe quelle ressource Azure de premier niveau :
Étape 2 : Tier, protocole et résilience
Au GA, le choix est volontairement cadré : tier SSD et protocole NFS 4.1 imposés. La seule décision de résilience se fait ici, au niveau du partage : LRS (redondance locale) ou ZRS (redondance inter-zones) selon la région Azure choisie :
Étape 3 : Le cœur du sujet : capacité, IOPS et débit séparés
C’est l’écran le plus important. Vous provisionnez la capacité, les IOPS et le débit de façon indépendante. Plus de « budget commun » réparti entre tous les partages du compte : ce que vous réglez ici, ce sont les limites de ce partage, et de lui seul :
Les maximums d’IOPS et de débit s’ajustent selon la capacité choisie (la plage va de 32 Gio à 256 Tio).
Le Calculateur de prix Azure vous permet de travailler ces valeurs, tout en mesurant l’impact sur le prix :
Étape 4 : L’onglet Advanced : root squash, chiffrement et nom de montage
C’est l’onglet qu’on a tendance à survoler, et c’est dommage, parce qu’il porte trois réglages qui changent la vie côté NFS :
Protocol → Root squash. C’est le mapping de l’identité root côté client NFS. Vous choisissez entre no root squash, root squash et all squash selon le niveau de confiance que vous accordez aux clients qui montent le partage.
Security → Require encryption in transit. Vous imposez le chiffrement du flux entre le client et le partage. À garder activé sauf raison impérieuse.
Other → Mount name. Vous donnez au partage un nom de montage différent du nom de la ressource Azure. Pratique pour garder des chemins de montage propres côté clients NFS sans vous imposer la convention de nommage Azure.
Mon retour terrain : le Mount name est le petit réglage que je règle systématiquement. Découpler le chemin de montage du nom de la ressource Azure vous évite de trimballer une convention de nommage cloud jusque dans vos fstab et vos scripts. Vos clients NFS gardent des chemins courts et lisibles.
Étape 5 : Le réseau, au niveau du partage
Autre changement de fond : la configuration réseau se fait ici, pas sur un compte parent. Vous décidez pour ce partage s’il est exposé en public endpoint ou enfermé derrière des private endpoints. Chaque partage a donc sa propre posture réseau :
Étape 6 : Review + create, le moment de vérité
On valide, on crée. Et là, magie : le partage apparaît dans le groupe de ressources comme une ressource Microsoft.FileShares à part entière, avec ses propres tags, son propre coût, son propre control plane :
Aucune clé de compte à aller récupérer quelque part, parce qu’il n’y en a tout simplement pas :
Du côté des performances et de la taille, tout est toujours rectifiable :
Et c’est là que le bât blesse. Du côté de la sauvegarde, un menu Snapshots est bien présent, mais il ne permet que des déclenchements manuels :
Plus inquiétant : le service de sauvegarde Azure Recovery Services vault ne le voit même pas :
Même chose pour les Backup vaults, qui ne sauvegardent pas ce type de stockage :
Et même le service Resiliency ne le détecte pas :
Attention ! la sauvegarde, c’est LE gros angle mort du GA : côté protection des données, on est à l’os. Le menu Snapshots existe, mais en déclenchement manuel uniquement : pas de planification, pas de rétention automatique.
Pire, la ressource est invisible pour Azure Backup, ni le coffre Recovery Services, ni les Backup vaults ne la voient et elle n’apparaît même pas dans Resiliency. Autrement dit : aucune sauvegarde managée au GA. Si votre donnée a la moindre valeur, prévoyez votre propre stratégie (snapshots scriptés + copie hors-partage) en attendant que Microsoft branche la protection native.
Étape 7 : On monte le partage : la lame Connect
Mais avant d’aller plus loin dans la connexion, l’intégration réseau est obligatoire :
Mon réseau est à présent configuré sur celui de ma machine Linux via un Service Endpoint :
Reste à le monter côté client. La lame Connect du partage vous donne directement la commande de montage NFS, avec le bon endpoint et les bonnes options pré-remplis : vous n’avez qu’à la copier sur votre client Linux :
Téléchargez le paquet Microsoft correspondant à votre version d’Ubuntu, afin d’ajouter le dépôt officiel Microsoft (nécessaire pour installer ensuite des outils comme aznfs) :
La commande sudo apt-get update met à jour la liste des paquets disponibles, puis sudo apt-get install aznfs installe le client Azure NFS (aznfs) depuis le dépôt Microsoft :
sudo apt-get update
sudo apt-get install aznfs
Créez le dossier /mount/jloshare qui servira de point de montage pour le partage NFS :
sudo mkdir -p /mount/jloshare
Montez le partage Azure Files en NFS sur votre point /mount/jloshare en utilisant le client optimisé aznfs, avec des options de performance et de compatibilité NFS 4.1 :
sudo mount -t aznfs fs-vlsw3zm2p5tvmn54j.z22.file.storage.azure.net:/fs-vlsw3zm2p5tvmn54j/jloshare /mount/jloshare -o vers=4,minorversion=1,sec=sys,nconnect=4
Affichez les systèmes de fichiers montés et filtrez pour vérifier que votre partage jloshare est bien monté :
df -h | grep jloshare
Depuis le portail Azure, la modification du volume du file share apparait immédiatement sur le partage :
5. Ce que vous gagnez concrètement
Le bénéfice tient en un mot : isolation. Tout ce qui était mutualisé au niveau du compte redescend au niveau du partage.
Performance dédiée : chaque partage a ses propres limites de capacité, d’IOPS et de débit. Plus de voisin bruyant qui mange votre budget perf.
Control plane par partage : les opérations (création, modification, suppression, snapshots) consomment un quota propre à chaque partage, sur un modèle de « seau » qui se recharge en continu. Les plafonds sont tellement hauts qu’en pratique, les blocages control-plane qu’on connaissait deviennent très improbables.
Réseau par partage : public endpoint, private endpoints : vous les configurez au niveau du partage, pas d’un compte parent qui impose ses règles à tout le monde.
Plus de clé de compte : il n’y a tout simplement pas d’account key toute-puissante. Le partage est sa propre ressource, avec sa propre surface de sécurité.
Facturation et tags granulaires : le coût est porté par le partage (capacité + IOPS + débit), avec ses propres tags. Le showback / chargeback devient enfin trivial.
Mon retour terrain : le gros gain au quotidien, ce n’est pas la perf brute, c’est la traçabilité des coûts et la fin de la clé de compte. Sur des environnements multi-équipes ou multi-projets, pouvoir taguer et facturer partage par partage change la vie des FinOps.
6. Les limites au jour du GA
Soyons honnêtes : « GA » ne veut pas dire « complet ». Le modèle est jeune, et plusieurs fonctionnalités qu’on tient pour acquises côté classique ne sont pas encore là. À l’heure où j’écris, il manque notamment :
La sauvegarde managée. C’est le point noir : au GA, vous n’avez que des snapshots manuels. Pas d’Azure Backup sur ce type de ressource, ni coffre Recovery Services, ni Backup vault ne le prennent en charge et il n’apparaît pas non plus dans Resiliency (voir la démo §4). La protection de la donnée est entièrement à votre charge.
SMB. C’est NFS 4.1 uniquement. Si vos workloads sont Windows/SMB (AVD + FSLogix, partages bureautiques…), ce modèle ne vous concerne pas encore.
CMK (clés gérées par le client), soft delete / corbeille, autres protocoles. Tout ça est annoncé comme « à venir », mais pas disponible au GA.
Attention ! FSLogix / AVD, ce modèle n’est pas pour vous aujourd’hui : au GA, c’est NFS 4.1 uniquement, et SMB n’est pas disponible. Or FSLogix exige du SMB (profils VHD/VHDX montés en SMB). Mécaniquement, vous ne pouvez pas poser vos profils FSLogix sur un partage Microsoft.FileShares pour l’instant. Pour de l’AVD, restez sur le compte de stockage classique en Azure Files SMB (provisioned v2 SSD). SMB est annoncé « à venir » sur ce nouveau modèle : le jour où il arrive, l’isolation par partage et la fin de l’account key deviendront très intéressantes pour de l’AVD multi-équipes, mais on n’y est pas.
7. Alors, je l’utilise ou pas ?
La règle est simple : si vos besoins rentrent dans le périmètre actuel, c’est le futur, foncez. Sinon, le classique fait toujours le job. Voici comment je le résume.
Voilà : cette « nouvelle ressource file share », ce n’est pas un énième renommage, c’est un vrai changement d’architecture. Le partage cesse d’être un sous-objet du compte de stockage pour devenir une ressource Azure de plein droit, avec sa perf, son réseau, sa sécurité et sa facture à lui. À la clé : une isolation propre, la fin de la clé de compte toute-puissante, un coût traçable partage par partage et une vraie compatibilité infrastructure-as-code.
Les trois pièges à retenir avant de vous lancer :
La sauvegarde, c’est le gros trou du GA : Snapshots manuels uniquement, et aucune prise en charge par Azure Backup (Recovery Services vault, Backup vault) ni par Resiliency. La protection de la donnée est à votre charge, n’y mettez rien de critique sans stratégie maison.
NFS 4.1 / SSD uniquement : pas de SMB (donc pas de FSLogix / AVD), pas de HDD.
Facturation provisioned v2 : dimensionnez correctement capacité, IOPS et débit, vous payez le provisionné.
Si vous êtes sur du NFS, foncez tester en lab : c’est clairement la direction que prend Azure Files. Pour le reste, le classique a encore de beaux jours devant lui, le temps que la sauvegarde managée, SMB et les autres briques manquantes débarquent.
Dernier point, et il pèse lourd dès qu’on dimensionne du provisionné : la capacité réservée, vous la payez. Autant ne pas voir trop large « au cas où » et faire grossir le partage automatiquement quand le besoin arrive.
Vous avez déployé Nerdio Manager for Enterprise (peut-être en suivant mon article précédent), vous avez coché en passant « FSLogix Profiles Storage Configuration » dans le wizard, mais vous n’avez jamais vraiment creusé ce que Nerdio fabrique derrière ? Cette suite logique est pour vous. On va dérouler, étape par étape, ce que Nerdio fait à votre place sur FSLogix et surtout ce que vous auriez à faire à la main sans lui. Parce que FSLogix, c’est probablement la brique d’AVD qui génère le plus de tickets support, et ça vaut la peine de comprendre pourquoi Nerdio fait baisser ce volume.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Avant d’entrer dans Nerdio, faisons l’inventaire de ce qu’il faut faire pour avoir un FSLogix qui tourne proprement sur un host pool AVD Entra-only. La liste, que vous pouvez retrouver dans cet article, se décompose dans cet ordre :
Provisionner un storage account
Activer l’authentification Entra Kerberos
Grant admin consent
Exclure cette app des policies Conditional Access MFA
Créer le file share
Distribuer les rôles RBAC
Régler les ACL NTFS
Pousser les clés registry FSLogix
Maintenir tout ça dans le temps
Mon retour terrain : à la main, comptez une bonne demi-journée pour un déploiement propre, plus le temps de débuggage des permissions NTFS qui vient quasi systématiquement. L’étape 7 (ACL NTFS) est celle qui génère le plus de tickets support sur tout AVD. Une fausse manip d’héritage et vous y passez la journée d’anniversaire de votre fils.
Maintenant, voyons ce que Nerdio peut faire pour vous.
2. Le wizard Create Azure Files Share
Avant toute chose, je vous conseille de créer le groupe de ressources sur le portail Azure, puis de lier ce dernier dans votre console Nerdio :
Dans Nerdio, direction Settings → FSLogix Profiles → Add Azure Files Share. Vous avez le choix entre pointer un storage account existant ou laisser Nerdio créer le share complet, du SA jusqu’aux ACL NTFS. Et oui, ça inclut le scénario Entra ID joined, c’est ce qu’on va dérouler ensemble :
Le wizard se passe en seulement 5 étapes :
Étape 1 : Storage Account
Nom du SA, resource group, région, SKU (Standard ou Premium Files), réplication. Rien d’extraordinaire, mais tout se passe dans une seule fenêtre Nerdio plutôt que de naviguer dans quatre blades Azure différentes.
Étape 2 : Active Directory ou Entra ID
L’étape clé. Vous activez le toggle Join AD or Entra ID, puis vous choisissez Entra ID dans la liste déroulante. Et là, Nerdio vous met deux warnings honnêtes que vous devez lire avant de cliquer Next :
Attention : Nerdio vous prévient sur deux points avant de valider :
⚠️ Be sure to grant admin consent after storage account is joined to Entra ID.
⚠️ Entra ID Conditional Access MFA is not supported with Entra ID joined Azure Files storage accounts. The new Entra ID application must be excluded from CA MFA policies.
Ce sont les deux seules manips qu’il vous restera à faire à la fin. Nerdio s’occupe du reste : création de l’app registration, configuration Entra Kerberos sur le storage, le tout en une seule passe.
Étape 3 : Share & Permissions
Vous donnez un nom au share, sa capacité (entre 100 GB et 100 TB), et vous attribuez les rôles RBAC SMB Share Contributor aux groupes Entra ID concernés. Mais surtout, et c’est là le gros gain, vous avez un dropdown NTFS Permission Preset avec une option FSLogix.
Ce preset, c’est exactement la combinaison Authenticated Users / CREATOR OWNER / Administrators de la section 1, avec les bons héritages.
Bonus sécurité : la case Limit access to specific host pools vous permet de restreindre ce share à un ou plusieurs host pools précis. Pratique si vous avez plusieurs environnements (prod, dev, RH, finance…) et que vous voulez éviter qu’un host pool puisse écrire dans le profil d’un autre.
Étape 4 : Temporary VM Settings
Pour appliquer les ACL NTFS et finaliser le join, Nerdio doit mount le share quelque part. Il monte donc une VM temporaire dans votre vNet le temps de la config, puis la supprime automatiquement.
Vous renseignez ici la taille de VM (le défaut B2s suffit), le subnet et éventuellement l’image. C’est cette VM qui va faire le icacls du preset FSLogix sur le share, donc gardez bien le subnet AVD ou un subnet qui peut joindre le storage.
Étape 5 : Tags
Classique. Submit.
Le déploiement commence alors, et toutes les étapes sont indiquées dans le log :
Sur le portail Azure, on retrouve la machine virtuelle temporaire créée pour l’occasion :
Une fois le traitement terminé, toutes les étapes sont bien détaillées dans le log :
Le statut du compte de stockage est également visible dans le portail Azure :
Et la configuration de la gestion identitaire Entra Kerberos est faite :
Dans Entra, l’app registration est bien créée :
Les ACL de base sont bien appliquées (un durcissement des héritages NTFS reste possible si votre politique de sécurité l’exige) :
À l’issue de l’opération, la machine virtuelle temporaire se détruit automatiquement :
À la fin du traitement, trois actions restent à votre charge :
Allez dans Entra ID → Enterprise Applications, ouvrez la nouvelle app qui porte le nom de votre storage account, et cliquez sur Grant admin consent for [tenant].
Ajoutez également la prise en charge des groupes dans le manifeste de l’app :
Si vous avez des Conditional Access policies MFA, ajoutez cette app dans la liste d’exclusion :
C’est tout. Comparez avec la liste de la section 1 : on est passé de 9 étapes à 3 manips de 30 secondes.
3. Les FSLogix Profiles : templates réutilisables
Voilà la deuxième brique qui change la vie : les FSLogix Profiles au sens Nerdio du terme, à ne pas confondre avec les profils utilisateurs FSLogix !
Dans Settings → FSLogix, vous créez un profil, c’est-à-dire un template de configuration FSLogix, que vous pourrez ensuite appliquer à n’importe quel host pool.
Concrètement :
Nom du profil : par exemple « Standard AVD Users » ou « Power Users with bigger profiles ».
Excluded users group : un groupe Entra ID dont les membres ne seront PAS soumis à FSLogix. Best practice : y mettre vos admins. Comme ça, si FSLogix casse, vos admins peuvent toujours se logger en profil local et venir réparer.
Profile path : un dropdown qui vous propose tous les shares que vous avez créés à l’étape précédente. Vous n’avez plus à retaper le path UNC à la main.
Office Container (ODFC) : checkbox pour activer le container Office séparé. Honnêtement, dans la grande majorité des cas AVD vous n’en avez pas besoin (j’y reviens en section 5).
Cloud Cache : à laisser de côté sauf scénario multi-région avec DR actif-actif.
Toujours sur l’écran de configuration FSLogix, vous tombez sur la vraie matrice des réglages FSLogix. Et là, Nerdio fait deux choses qui valent la mention.
Les eye icons. Chaque setting a une petite icône œil que vous pouvez survoler pour avoir la description complète de la clé registry correspondante. Plus besoin d’aller chercher dans la doc Microsoft à chaque fois. C’est bête mais c’est ce qui transforme FSLogix d’un truc obscur en quelque chose de réellement administrable.
Les valeurs par défaut « Not configured ». Tant que vous ne touchez pas, Nerdio ne pousse rien sur cette clé : la valeur par défaut FSLogix est utilisée. Vous ne tunez que ce que vous voulez vraiment changer, ce qui rend votre conf lisible.
Les best practices que je pousse personnellement (et qui sont presque toutes pré-suggérées par Nerdio) :
Réglage
Valeur
Pourquoi
DeleteLocalProfileWhenVHDShouldApply
Enabled
Sur un environnement neuf, ça évite l’accumulation de profils locaux qui se baladent à côté des VHDX. À ne PAS activer si vous migrez depuis une infra existante avec des profils locaux à préserver.
FlipFlopProfileDirectoryName
Enabled
Met le username AVANT le SID dans le nom du folder. Indispensable pour s’y retrouver quand vous cherchez le profil d’un user dans le share.
VolumeType
VHDX
Disque dynamique, grandit au fil du temps. Sur Standard Files, c’est ce qui vous évite de réserver 30 Go par user dès le premier login.
IsDynamic
Enabled
Idem, le VHDX commence à quelques Mo et grandit en fonction de l’usage réel.
LockedRetryCount / LockedRetryInterval
Défauts, à augmenter si réseau capricieux
Si le VHD est temporairement locké (réseau qui tousse, session précédente qui ne s’est pas fermée proprement), FSLogix réessaye au lieu de filer un profil temp.
PreventLoginWithFailure
Enabled
Si FSLogix n’arrive pas à monter le profil, l’utilisateur est BLOQUÉ au login plutôt que de se retrouver sur un profil temporaire. Préférable : un user qui appelle le support > un user qui bosse 4 h sur un profil qui sera jeté au logoff.
PreventLoginWithTempProfile
Enabled
Même logique, ceinture et bretelles.
ProfileType
0
Mount sur un seul host à la fois. Le multi-mount (type 3) est une plaie à débugger, à n’activer que si vous avez vraiment besoin.
SizeInMBs
30000 (30 GB)
Plafond raisonnable. Tracez les profils qui s’en approchent dans le monitoring (section 7).
Compression au logoff
Enabled
À chaque logoff, FSLogix compacte le VHDX. Vous économisez pas mal de stockage à long terme.
Et pour les puristes : le mode Advanced vous laisse taper directement les clés FSLogix par nom et valeur si vous voulez configurer quelque chose qui n’est pas exposé dans l’UI. Nerdio ne vous enferme pas :
Une fois le profil créé, vous cliquez sur les trois points → Set as default :
À partir de là, chaque nouveau host pool que vous créez héritera de cette config FSLogix automatiquement. Et bien sûr, vous pouvez override par host pool si vous avez besoin d’une config différente quelque part.
C’est ça le vrai gain par rapport à une approche GPO : ce que vous configurez une fois s’applique partout, sans recréer une GPO ni modifier votre image golden.
4. La config qui descend toute seule sur les session hosts
À la création (ou à la mise à jour) d’un host pool, Nerdio injecte la conf FSLogix via ses Scripted Actions au boot des session hosts :
Comme c’est magnifique, et tellement simple :
Les machines virtuelles sont bien visibles dans le pool d’hôtes :
Concrètement :
Pas besoin de GPO
Ça marche sur des hosts Entra-only ou joints à un domaine AD
Ça s’applique aussi bien sur les hosts existants que sur les nouveaux (auto-scale, re-image)
Si vous allez voir le registre d’un session host après le déploiement :
La version de FSLogix correspond à celle demandée :
Vous retrouverez bien tout sous HKLM\SOFTWARE\FSLogix\Profiles, mais cette fois sans que vous ayez touché à un seul reg add ni à une GPO :
Et bien sûr, le profil VHDX se crée au premier démarrage de l’utilisateur :
Mon retour terrain : si vous changez la config dans le FSLogix Profile Nerdio, vous pouvez redéployer la conf sur tous les hosts d’un host pool en un clic, sans rebuilder l’image. Nerdio relance simplement le Scripted Action sur chaque host. C’est l’inverse du modèle « je rebuild mon image dorée à chaque tuning FSLogix » qu’on voyait avec les GPO.
Exclusions registry. Toujours dans le FSLogix Profile, vous avez un onglet Profile Exclusions où vous gérez la liste des dossiers et fichiers que FSLogix doit ignorer (typiquement les caches Teams, les logs, les téléchargements). C’est l’équivalent de la clé HKLM\SOFTWARE\FSLogix\Profiles\Exclude List, mais éditable depuis une UI au lieu d’un import de fichier .reg.
Redirections.xml. Pareil, Nerdio gère l’upload et la synchronisation du redirections.xml sur le share. Vous le modifiez dans Nerdio, il est poussé automatiquement au prochain mount des profils.
Office Container (ODFC). Comme dit en section 3, dans la majorité des cas AVD vous n’en avez pas besoin. La doc Microsoft elle-même recommande de NE PAS mélanger Profile Container et ODFC sauf cas particulier (par exemple OneDrive en mode Files On-Demand avec beaucoup de fichiers). Si vous l’activez, comptez doubler la complexité de troubleshooting.
Cloud Cache. Outil puissant pour faire du multi-storage avec basculement automatique, mais à réserver aux scénarios DR actif-actif ou multi-région avec une vraie contrainte de continuité de service. Sur un host pool en région unique, Cloud Cache n’apporte rien que le Profile Container standard ne fasse déjà.
6. Multi-storage et scoping par host pool
Pour les déploiements qui grossissent, deux features valent le coup d’être mentionnées.
Plusieurs locations FSLogix. Vous pouvez déclarer plusieurs shares dans Nerdio (même un Azure NetApp Files si vous en avez un) et les pointer depuis différents FSLogix Profiles. Pratique pour séparer prod et dev, ou pour des shares dédiés par département.
Scoping par host pool. Souvenez-vous de la case Limit access to specific host pools à l’étape Share & Permissions (section 2). Couplée aux FSLogix Profiles par host pool, ça vous permet d’avoir une isolation stricte : un host pool « Finance » ne peut pas écrire dans le share « RH », et inversement. Tout ça géré dans la même UI, sans pondre des RBAC complexes à la main.
7. Monitoring et cleanup des profils orphelins
Plusieurs features moins glamour, mais qui paient leur licence Nerdio sur le long terme.
Monitoring des tailles de profil : Nerdio remonte pour chaque session active la taille du VHDX du user. Vous voyez tout de suite les profils qui gonflent (typiquement les boîtes OST Outlook, les caches Teams mal nettoyés). Vous pouvez tirer des alertes là-dessus.
Auto-Scale du file share : Manage Auto-Scale for FSLogix permet d’automatiser le dimensionnement des ressources et la gestion des profils utilisateurs afin d’assurer performance et optimisation des coûts sans intervention manuelle, de la même façon que mon article sur la méthode scriptée dans Azure :
Cleanup des profils orphelins : Nerdio propose une Scripted Action prête à l’emploi qui scanne votre share FSLogix, compare la liste des folders aux users existants dans Entra ID, et supprime les VHDX des users qui n’existent plus (départs, comptes supprimés). Vous la planifiez en récurrent (une fois par mois par exemple) et vous oubliez.
À la main : il faut écrire le script PowerShell, le planifier (Automation Account, Function App, ou serveur dédié), le maintenir quand l’API Graph change. Avec Nerdio : checkbox + planification.
8. Verdict
Si vous gérez un seul host pool sur une infra stable, FSLogix à la main reste tenable et vous payez l’effort une fois, vous oubliez. Mais dès que vous avez :
Plusieurs host pools avec des configs FSLogix différentes,
Des changements de conf réguliers (ajout d’exclusions, redirections, tuning),
Du multi-département avec isolation des profils,
… Nerdio paye sa licence rien que sur la partie FSLogix. La création du share avec preset NTFS, le push de la conf au boot, le monitoring et le cleanup, c’est plusieurs jours de travail PowerShell que vous n’avez plus à faire ni à maintenir.
Voilà, en 8 sections vous avez fait le tour de ce que Nerdio fait pour vous sur FSLogix. Concrètement, ça donne quoi ? Vos tickets support « profil temporaire » devraient chuter de manière significative. Ce qui, dans la vie d’un admin AVD, n’a pas de prix.
Foncez tester en lab : le wizard Create Azure Files Share en mode Entra-joined, c’est cinq minutes à dérouler, et vous verrez tout de suite la différence avec le manuel. Prochain article de la série : on attaquera l’auto-scaling avec Nerdio, l’autre grande raison de payer cette licence (et la moins évidente à découvrir tout seul).
Un dimanche soir, votre stockage FSLogix sature, et personne ne le voit. Lundi matin, vos 200 utilisateurs AVD n’arrivent plus à se connecter car leur profil ne se charge plus. Que faire en ce moment d’urgence ? Vous découvrez en urgence que provisionner un share Azure avec « 8 To au cas où » , ça vous coûte un bras et demi. Ce mauvais rêve vous parle ou vous empêche de dormir ? Cet article est fait pour vous.
On va très rapidement remonter l’histoire d’Azure Files, comprendre pourquoi Provisioned v2 (GA depuis 2025) change la donne pour les workloads FSLogix, et surtout déployer ensemble, depuis Azure Cloud Shell, en moins de 5 minutes, une solution open-source qui fait grossir automatiquement le quota quand l’usage approche la saturation, avec des notifications mail à la clé.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Mais pour rappel, jusqu’ici Azure Files se déclinait essentiellement en deux familles :
Standard (HDD) en pay-as-you-go : pas cher, performances modestes, facturation peu prédictible (capacité utilisée + transactions).
Premium (SSD) en provisioned : les IOPS et le throughput étaient dérivés mécaniquement de la capacité provisionnée. Vous vouliez 50 000 IOPS ? Vous provisionniez des To de capacité, que vous les remplissiez ou non.
Ce dernier point a été le casse-tête FSLogix pendant des années. Sur un share AVD, vous n’avez pas spécialement besoin de 5 To de capacité, mais vous avez besoin de pouvoir encaisser une sign-in storm à 8 h le matin.
Sur du Premium V1, pour atteindre les IOPS nécessaires, vous étiez obligé de surprovisionner la capacité. Vous payiez alors de l’espace que vous n’utilisiez pas, contrairement au HDD pay-as-you-go.
Et si vous étiez tenté par le HDD pay-as-you-go pour dormir tranquille : à la place d’un long discours, voici une image qui a dû faire mal à de nombreux administrateurs d’AVD :
Sur cete copie du Cost Management, les opérations d’écriture représentent 99% du coût total !
Mon retour terrain : sur la quasi-totalité des projets AVD que j’ai vus, le calcul de sizing FSLogix se faisait « en IOPS » et la capacité était une conséquence. Résultat : des shares à 2-4 To remplis à 30 %, payés plein pot.
2. L’arrivée de Provisioned v2
Provisioned v2 est GA depuis 2025, dans toutes les régions publiques Azure et toutes les régions Azure US Government. La grande nouveauté : on provisionne trois axes indépendants.
Le modèle v2 provisionné pour Azure Files associe la prévisibilité du coût total de possession à la flexibilité, vous permettant ainsi de créer un partage de fichiers qui répond précisément à vos exigences en matière de stockage et de performances.
Lorsque vous créez un partage de fichiers v2 approvisionné, vous spécifiez la quantité de stockage, d’IOPS et de débit dont votre partage de fichiers a besoin.
Cooldown 24 h sur la descente : on peut augmenter le quota n’importe quand, mais on ne peut le diminuer qu’après 24 h sans changement.
Burst IOPS credit-based : sur SSD, le burst max est MIN(MAX(3 × ProvisionedIOPS, 10 000), 102 400). Pratique pour absorber les pics ponctuels sans surprovisionner.
Bursting v2 approvisionné :
IOPS provisionnées
Limite d’IOPS en rafale SSD
Crédits de rafale SSD
Limite de l’IOPS en mode bursting de disque de l’HDD
Côté FSLogix, la doc Microsoft Learn pose deux chiffres très concrets, par utilisateur :
Profil de charge
IOPS par utilisateur
Steady state (utilisation normale en cours de journée)
10
Sign-in / Sign-out (ouverture ou fermeture de session)
50
L’exemple de ce tableau est celui d’un utilisateur unique, mais il peut être utilisé pour estimer les besoins relatifs au nombre total d’utilisateurs dans votre environnement. Par exemple, vous avez besoin d’environ 1 000 IOPS pour 100 utilisateurs et environ 5 000 IOPS lors de la connexion et de la déconnexion.
Projetons ça sur quelques tailles d’environnement classiques :
Users
IOPS steady (×10)
IOPS pic sign-in (×50)
50
500
2 500
200
2 000
10 000
500
5 000
25 000
1 000
10 000
50 000
Côté capacité, Microsoft ne fixe pas de chiffre dur officiel par utilisateur, ça dépend des applis, d’Outlook (qui crée souvent les plus gros .OST), de OneDrive Known Folder Move, etc.
Sur la majorité des environnements AVD que j’ai croisés, on tourne entre 5 et 30 GiB par profil, avec une grosse variance. C’est exactement le genre de variable difficile à prévoir à l’avance, et c’est pour ça que l’auto-grow prend tout son sens.
Attention : les 10 / 50 IOPS sont des moyennes Microsoft. Sur une population à fort usage Office + Teams + OneDrive sync, on monte assez vite. Mesurez sur votre prod plutôt que de partir tête baissée sur la table.
4. Le piège du « pay-per-provisioned »
C’est le point qui change avec le Provisioned v2, qu’il soit SSD ou HDD. Microsoft le dit noir sur blanc :
Vous payez en fonction de ce que vous approvisionnez, quel que soit le montant que vous utilisez réellement.
Concrètement : vous provisionnez 8 To « au cas où » → vous payez 8 To, qu’ils soient remplis à 5 % ou à 95 %. Plus du tout le modèle Standard pay-as-you-go d’antan où vous ne payiez que le stockage consommé.
Deux stratégies s’offrent à vous :
Surprovisionner dès le départ pour ne jamais être surpris → vous payez de la capacité dormante pendant des mois.
Provisionner serré (avec un peu de marge) puis grossir à la demande, dès que l’usage s’approche d’un seuil → vous payez ce dont vous avez besoin au moment où vous en avez besoin.
L’option 2 demande de l’automatisation. C’est exactement ce que fait la solution qui suit.
main.bicep : déploie un Automation Account avec Managed Identity, les modules PowerShell 7.2 (Az.Accounts + Az.Storage), un runbook vide, une schedule, et toute la stack Azure Communication Services pour les emails.
Grow-FslogixShare.ps1 : le runbook qui lit la capacité utilisée du share, compare au seuil, agrandit le quota, et envoie un email récapitulatif.
deploy-cloudshell.sh : script interactif qui vous pose les questions et orchestre tout depuis Azure Cloud Shell.
Le runbook est grow-only par design : il ne diminue jamais le quota et c’est volontaire : un utilisateur qui charge un gros profil un jour et le supprime le lendemain ne doit pas déclencher une décroissance.
Et de toute façon, Azure impose 24 h de cooldown avant toute baisse, donc autant ne pas s’embêter.
Pré-requis
Subscription
Vous devez être Contributor sur un Resource Group de la sub.
Storage account
Kind FileStorage avec SKU PremiumV2_* ou StandardV2_* déjà existant, avec un file share déjà créé.
Email de notif
N’importe quelle adresse (interne, externe, gmail, …). Optionnelle : si vous la laissez vide, les notifs sont désactivées et la stack ACS n’est pas déployée.
Outils
Azure Cloud Shell (Bash).
Mon retour terrain : j’ai fait le choix d’Azure Communication Services pour les emails, plutôt que Microsoft Graph. Avantage énorme : un simple rôle Contributor scopé sur la ressource ACS suffit. Pas de consentement admin tenant, pas de Mail.Send au niveau du tenant, pas de mailbox à provisionner. La solution est déployable par n’importe quel admin Azure qui a un Resource Group à sa main.
6. Déploiement pas-à-pas depuis Cloud Shell
Étape 0 — Ouvrir Cloud Shell et récupérer les fichiers
Mais juste avant, j’ai déployé un Azure File Share de 50 Go sur mon environnement de test :
Les jobs manuels ou automatiques sont visibles ici :
Si vous voulez juste tester l’envoi d’email sans toucher au quota, le runbook supporte un switch -WhatIf qui simule la décision sans appliquer.
Au besoin, vous pouvez modifier la configuration planifiée en en créant une nouvelle ici :
Quand l’usage du share franchit le seuil (par défaut 80 %), comme ici :
Le runbook calcule le nouveau quota (ceil(quota_actuel × 1.25), capé à MaxQuotaGiB), appelle Update-AzRmStorageShare :
La taille du partage de fichier augmente bien de 25 % :
Et enfin il envoie un email récap :
Mais, si le share atteint le cap dur (MaxQuotaGiB), le runbook arrête de le faire grossir :
Et il envoie aussi un email d’alerte en importance haute :
Attention : le premier email envoyé depuis le domaine ACS managé (DoNotReply@<guid>.azurecomm.net) peut tomber en spam. Whitelistez *.azurecomm.net côté destinataire, ou mieux branchez un custom domain vérifié dans le portail ACS (10 minutes d’enregistrements DNS).
Et comme attendu, le service veille en continu :
8. Estimation de coûts (ordres de grandeur)
Les prix Azure Files V2 varient selon la région et la redondance, et Microsoft les ajuste régulièrement.
Les chiffres qui suivent sont des ordres de grandeur pour un déploiement de 256 Go en Europe de l’Ouest, sur un workload FSLogix sur les quatre types de stockage :
À vérifier sur le calculateur Azure avant de chiffrer un projet. Attention au prix hors transaction du HDD PAYG.
Voici d’ailleurs plusieurs hypothèses de sizing FSLogix :
~ 15 GiB par profil utilisateur (mid-range, typique AVD avec Office + OneDrive sync léger)
IOPS pic sign-in : 50 IOPS / user (recommandation Microsoft)
Throughput : ce que recommande Azure par défaut pour la capacité provisionnée
Users
Capacité visée
IOPS visés (pic)
Stratégie « provisioned sec » à la main
Stratégie « auto-grow »
50
~ 750 GiB
2 500
Surprovisionner à 1 TiB pour avoir de la marge
Démarrer à 256 GiB, grossir au fil de l’eau jusqu’à ~ 800 GiB
200
~ 3 TiB
10 000
Provisionner d’office 4 TiB
Démarrer à 1 TiB, monter par paliers de +25 %
500
~ 7,5 TiB
25 000
Provisionner d’office 8 TiB
Démarrer à 2 TiB, monter au besoin
1 000
~ 15 TiB
50 000
Provisionner d’office 16 TiB
Démarrer à 4 TiB, monter au besoin
Sur les ratios de remplissage que je vois en prod (souvent 40-60 % sur les premiers 6 mois), la stratégie auto-grow économise typiquement 30 à 50 % sur la ligne « capacité provisionnée » du share, le temps que la base utilisateurs se stabilise. L’IOPS reste à provisionner pour le pic, ou à profiter des bursts :
Coût ajouté par la solution elle-même :
Automation Account : les 500 premières minutes de runtime par mois sont incluses. Un check toutes les 30 minutes consomme quelques secondes par run, soit largement sous le seuil gratuit.
Azure Communication Services Email : facturation à l’email envoyé. Sur le volume d’un déploiement comme le nôtre (typiquement quelques dizaines d’emails par mois), c’est négligeable.
Bref : le coût de l’orchestration est ridicule face à ce que la stratégie permet d’économiser sur la capacité du share.
9. Pièges & vigilance
Attention : les modules PowerShell sont importés en asynchrone. Pendant les 10-15 minutes qui suivent le déploiement, un job qui se déclenche peut échouer avec « Could not find module Az.Accounts ». C’est normal, ça se résout tout seul. Évitez juste de tester immédiatement après le déploiement.
Attention : le Managed Domain ACS a besoin d’une à deux minutes pour être complètement provisionné après le déploiement. Le tout premier envoi d’email peut échouer ; il suffit de relancer.
Attention : le sender par défaut est DoNotReply@<guid>.azurecomm.net. Pour un envoi propre depuis alerts@mondomaine.com, il faut ajouter un custom domain vérifié dans le portail ACS (quelques enregistrements DNS, 10 minutes) puis mettre à jour AcsSenderAddress sur le jobSchedule.
Mon retour terrain : le runbook est grow-only, ne descend jamais le quota. Et tant mieux : Azure impose 24 h de cooldown avant toute baisse, et refuse toute baisse sous l’usage courant. Si vous voulez vraiment réduire, faites-le à la main après avoir mesuré sur un mois entier.
Conclusion
Voilà, en quelques minutes de Cloud Shell, vous avez :
Un Automation Account avec identité managée
Un runbook qui surveille votre share FSLogix v2 et adapte le quota automatiquement.
Une stack Azure Communication Services dédiée qui envoie les emails
Concrètement, ça donne quoi ? Vous ne surprovisionnez plus à l’aveugle. Vous démarrez serré, et la capacité suit l’usage réel, avec un email récap à chaque changement, et un garde-fou final si jamais ça part en vrille.
Foncez tester, le repo est en MIT, vous pouvez le forker, l’adapter à vos seuils, brancher Logic Apps ou un Teams Webhook à la place de l’email si c’est votre flow. github.com/jlou07/azure-files-autogrow.
Encore hésitant à passer votre stockage FSLogix en v2 ? Regardez cette vidéo :
Et si vous voulez creuser le calcul de sizing FSLogix plus en détail, dites-le moi en commentaire, il y a matière à un article dédié sur la mesure d’IOPS réelle vs la table Microsoft.
Vous avez entendu parler de Nerdio à droite à gauche, vous savez vaguement que ça « simplifie AVD », mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On part d’une souscription Azure quasi vide et on va dérouler, capture après capture, tout ce qu’il faut faire pour aboutir à un utilisateur qui clique sur Windows App et qui ouvre un bureau AVD propre, avec son profil FSLogix qui suit.
À chaque étape je montre en parallèle ce qui apparaît côté portail Azure, parce que c’est très bien Nerdio, mais il faut comprendre ce qu’il fabrique réellement dans votre subscription. Avant de plonger dans le tuto, deux vidéos pour planter le décor :
La première fait le tour rapide des deux produits Nerdio :
Nerdio Manager for Entreprise
Nerdio Manager for MSP
La seconde montre un déploiement en moins de 5 minutes :
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Avant de cliquer sur quoi que ce soit dans le Marketplace Azure, vous devez avoir plusieurs briques en place. Si elles ne sont pas là, vous allez avoir des erreurs classiques du genre « no subnet available » ou « FSLogix path unreachable » pendant la configuration de Nerdio. Autant les poser proprement avant.
Premier prérequis : un Virtual Network. Le vNet doit être joignable depuis votre Active Directory (ou être Entra ID joined comme chez moi), et c’est là-dedans que les session hosts vont atterrir :
Dans mon lab j’ai créé un vnet avec deux subnets dédiés : un pour AVD et un pour Windows 365.
Deuxième prérequis : un NAT gateway, associé à vos subnets AVD et Windows 365. La NAT gateway est la solution la plus simple, bien qu’il en existe d’autres (voir mon article) :
Pour rappel, depuis 2025 Microsoft a rappelé que le default outbound access d’Azure allait disparaître. Si vos VMs AVD ont besoin de sortir sur Internet (et elles en ont besoin : Windows Update, M365, agents), il vous faut une IP de sortie explicite.
Troisième prérequis : un compte de stockage pour FSLogix :
Attention : sur un environnement Entra ID joined, l’authentification au file share FSLogix passe par Entra Kerberos. Pensez à activer cette option côté storage account et à attribuer les rôles RBAC Storage File Data SMB Share Contributor aux utilisateurs AVD. Sinon, vous aurez l’écran « Please wait for the FSLogix Apps Services » pendant 30 secondes puis un profil temporaire : le piège classique.
2. Déployer Nerdio Manager for Enterprise depuis le Marketplace
Direction le Marketplace Azure, on tape nerdio et on tombe sur plusieurs offres. Celle qui nous intéresse dans cet article est Nerdio Manager for Enterprise (à ne pas confondre avec Nerdio Manager for MSP qui est pour les prestataires multi-tenants) :
Sur la fiche produit, on voit que le pricing est en « BYOL via Microsoft Enterprise Contract », vous payez Nerdio sur votre facture Azure (Marketplace), pas via une licence séparée.
On clique sur Create :
L’écran Create NME Plan est un assistant Azure classique :
Premier onglet, Basics : on choisit la subscription, on crée un nouveau Resource Group dédié, et on sélectionne la région :
J’ai pris France Central parce que je veux que les composants Nerdio (App Service, SQL, Key Vault) soient au même endroit que mes session hosts.
Attention : le compte avec lequel vous lancez le déploiement doit être Global Administrator sur Entra ID ETOwner sur la subscription. C’est rappelé dans l’écran Basics. Si vous êtes juste Contributor, ça va planter au consent.
Onglet Resource Names : on définit un préfixe et on laisse les noms par défaut. À ce stade vous voyez déjà la liste de ce qui va être déployé :
App Service Plan, App Service, Log Analytics, Application Insights, deux Automation Accounts, SQL server + SQL database, Key Vault, Storage Account, et un deuxième Log Analytics pour le monitoring.
Onglet Private Endpoints : en prod vous activerez les private endpoints pour blinder la sécurité (l’App Service et le SQL deviennent inaccessibles depuis Internet). Pour notre lab dev/test on laisse décoché :
Onglet Tags : standard, vous appliquez vos tags habituels :
Et enfin Review + create. Vous validez les conditions Marketplace, vous vérifiez l’adresse mail (qui sera utilisée par Nerdio pour vous joindre support / facturation), et vous cliquez Create.
Le déploiement prend entre 5 et 15 minutes selon la région et la charge Azure du moment :
Chez moi : 8 minutes pile. Une fois le « Your deployment is complete » affiché, on passe à la suite.
Dans l’onglet Outputs, vous récupérez l’URL de votre App Service Nerdio :
Mettez-la en favori tout de suite, c’est votre console de management.
3. Initialiser le Nerdio Manager
On ouvre l’URL de l’App Service.
Premier accueil : Nerdio vous demande de lancer un script PowerShell qui va finir la plomberie (permissions, secrets, certificat dans Key Vault, app registration Entra ID) :
C’est une étape obligatoire : on ne peut pas s’en passer.
Cliquez sur Copy pour récupérer la commande PowerShell, puis ouvrez le Cloud Shell directement depuis l’icône en haut du portail Azure :
Vous collez la commande, vous appuyez sur Entrée et vous laissez tourner :
À la fin vous devez voir un Deployment completed successfully :
Pendant l’exécution, Entra ID vous demande de donner le consent admin pour l’app Nerdio. Cochez « Consent on behalf of your organization » et cliquez Accepter :
Si vous voulez vérifier, allez sur la page Enterprise Application nerdio-nmw-app dans Entra ID, onglet Permissions. Vous devez voir une liste impressionnante de permissions Microsoft Graph :
(lecture/écriture sur utilisateurs, groupes, devices Intune, Cloud PCs, scripts, app policies, etc.) plus une permission Azure Resource Manager (user_impersonation).
C’est cette app registration qui va piloter votre tenant à la place de Nerdio.
4. Premier login et registration
Une fois le script PowerShell terminé, on retourne sur l’URL Nerdio et on rafraîchit la page. Cette fois on a l’écran d’accueil avec votre tenant Entra ID et votre subscription pré-remplis. On clique sur Register Nerdio Manager.
Petit formulaire de registration côté Nerdio (Company, Name, Email, Phone) :
C’est ce qui leur permet de tracer votre install pour le support et les MAJ.
On clique sur Next :
Vous obtenez un Install ID unique. C’est lui qui va lier votre app Nerdio au backend de licensing.
Étape Services : Nerdio vous demande quels services vous voulez manager. Dans mon lab j’ai tout coché : Azure Virtual Desktop, Windows 365 (Cloud PCs) et Intune (Physical endpoints) :
Vous pouvez désactiver ce que vous n’utilisez pas, mais comme c’est gratuit en termes de licensing (vous payez Nerdio au user actif, pas au service), autant tout activer.
Étape Configuration : Nerdio vous demande trois choses, dans cet ordre : un vNet, un Directory (Entra ID, AD DS, ou Entra Domain Services), et un emplacement FSLogix. On clique sur le bouton Configure à côté de Features and scope pour commencer par paramétrer Intune :
Sur la fenêtre Configure Intune, vous choisissez ce que Nerdio a le droit de faire sur Intune : Manage / Read-only / N/A pour chaque feature (devices, group membership, scripts, conditional access, app policies, etc.) :
Pour un lab on met tout en Manage.
Ensuite on revient et on configure le VNet, puis on le link au subnet AVD :
Et/ou Windows365, selon ce qu’on veut faire en premier.
Puis Directory : C’est ce profil qui dira aux session hosts de se joindre automatiquement et de s’enrôler dans Intune au boot :
Enfin FSLogix Profiles Storage Configuration. On pointe le path UNC du share, et on coche absolument « Configure session hosts registry for Entra ID joined storage » :
c’est le réglage qui force FSLogix à utiliser Entra Kerberos pour s’authentifier au share. Sans ça : profil temporaire, garanti.
Attention : pour le FSLogix sur stockage Entra ID joined, en plus de cocher la case dans Nerdio, il faut que le storage account ait été configuré avec Identity-based access côté Azure (rappel du prérequis 1) et que vos utilisateurs AVD aient le rôle RBAC Storage File Data SMB Share Contributor. C’est l’erreur n°1 sur les déploiements Entra-only.
Une fois les trois choses configurées, vous voyez l’écran de Configuration avec les trois boutons remplis (vNet sélectionné, Directory Entra ID, FSLogix location renseigné), on clique sur Done.
La console Nerdio charge alors la configuration pendant plusieurs minutes :
6. Le Grant Admin Consent final
Nerdio détecte qu’il a besoin de permissions supplémentaires pour fonctionner sur l’étendue que vous venez de définir (vNet, FSLogix, Intune).
Une popup Grant Consent apparaît, avec un warning : « The list of required permissions can take some time to fully populate. You may need to grant permissions multiple times. »
Cliquez sur le lien pour ouvrir la fenêtre de consent Entra ID.
Vous validez la longue liste de permissions et vous cliquez Accept. Vous obtenez alors l’écran « Admin Consent granted » :
Côté portail Azure, vous pouvez vérifier sur l’Enterprise App nerdio-nmw-app que les permissions Microsoft Graph sont maintenant à 29 (au lieu de 25 avant) :
Quatre permissions supplémentaires viennent d’être accordées (typiquement liées à la gestion des policies, des groupes, etc.).
De retour dans Nerdio, on coche « I have granted admin consent » et on clique OK.
Mon retour terrain : il m’est arrivé de devoir passer le consent deux fois sur cet écran. La première fois Nerdio détecte des permissions manquantes après quelques secondes et redemande. Ne paniquez pas, c’est normal, le warning vous prévient.
7. Tour des ressources Azure créées par Nerdio
Voilà, vous arrivez sur le dashboard Workspaces de Nerdio. Il est vide pour le moment, on va y revenir :
Concrètement, à ce stade vous avez un environnement Nerdio fonctionnel, sans encore d’AVD configuré.
Maintenant, allez voir côté portail Azure, vous devriez voir les services Azure suivants :
App Service / App Service Plan + Application Insights
2 Automation Account
Data Collection Endpoint + Data Collection Rule+ 2 Log Analytics Workspaces
Key Vault
Runbook
Smart detector alert rule
SQL database + SQL server
Storage Account
Soit 16 ressources Azure (avec Action group et Failure Anomalies en bonus).
Et dans l’IAM de votre vNet, vous voyez maintenant l’app registration nerdio-nmw-app avec trois rôles : Reader et Backup Reader hérités au niveau subscription, et Network Contributor sur le vNet lui-même :
. C’est ce qui permet à Nerdio de créer des NICs et de gérer les session hosts dans votre subnet.
8. Downgrade dev/test pour faire baisser la facture
16 ressources Azure pour faire tourner une simple app web de management, ça pique un peu, surtout quand on découvre que Nerdio déploie par défaut :
App Service Plan en B3 (~150 €/mois)
SQL Database en S1 (~22 €/mois).
Total déploiement par défaut : autour de 248 $/mois rien que pour la console Nerdio elle-même, sans compter vos session hosts.
Concrètement, vous allez sur la SQL Database, onglet Compute + storage, et vous basculez en Basic (For less demanding workloads) à 5 DTUs et 2 GB de data, coût estimé : 6,11 $/mois :
On en profite pour passer le backup en Locally-redundant (LRS) puisqu’on est en dev/test.
Puis sur l’App Service Plan, vous faites un Scale up et vous descendez de B3 vers B1 (Basic). Coût estimé : ~8,40 €/mois.
Attention : ce downgrade est officiellement supporté uniquement pour dev/test et POC. En production, gardez le B3 + S1 sinon vous allez avoir des perfs dégradées sur l’auto-scaling, les scripted actions et les opérations bulk. La KB Nerdio est claire là-dessus.
9. Créer un Workspace
On revient dans Nerdio.
Première chose à faire : aller dans Settings > Environment > Linked Resource Groups et vérifier qu’on a bien linké le RG dans lequel on veut déployer les session hosts :
Chez moi, je veux que mes session hosts atterrissent dans un RG dédié nerdio-rg, donc je le link via Link new resource group.
Maintenant, direction Workspaces. C’est encore vide, on clique sur New Workspace.
Pour rappel, un Workspace AVD c’est juste un conteneur logique qui va regrouper vos host pools. Côté Microsoft, c’est l’objet Microsoft.DesktopVirtualization/workspaces :
Je le mets en West Europe (parce que c’est la région supportée par AVD la plus proche de France Central, AVD n’est pas dispo partout).
Côté Azure, vous voyez maintenant apparaître la ressource de type Workspace. Nerdio a bien créé l’objet AVD pour vous :
10. Créer un Host Pool
Sur la ligne du workspace, on clique sur les trois points et on choisit Host pools :
On clique New Host Pool :
La fenêtre Add Host Pool est dense, voici mes choix pour le lab :
Host pool type : Static (pas d’auto-scale dynamique pour ce test)
Initial host count : 2 pour valider le load balancing
Name (VM prefix) : nerdio-vm
Network : nerdio-vnet (AVD)
Desktop image : Windows 11 25H2 AVD + Microsoft 365 Apps (image Marketplace gallery)
VM size : D8s_v6 (8 cores, 32 GB RAM)
OS disk : 128 GB E10 Standard SSD
Nerdio prévient que la tâche est longue (entre 20 et 40 minutes pour 2 hosts), on clique OK et c’est parti. Vous pouvez suivre l’avancement dans l’onglet Tasks.
Côté Azure pendant que ça tourne, on voit déjà apparaître deux nouvelles ressources : Host pool et Application group, c’est l’objet qui va recevoir les assignations utilisateurs :
Dans l’onglet Tasks de Nerdio, on voit le déroulé : un Create host pool, puis Add hosts en parallèle pour les 2 VMs (qui prennent ~12 à 15 minutes chacune) :
Côté Azure on voit les 2 VMs apparaître avec leurs NICs respectifs, attachés au subnet AVD :
Une fois toutes les Tasks COMPLETED, on est bon :
Dans la vue Session Hosts, les deux VMs sont là, marquées Entra Joined, avec leur IP dans le subnet :
Côté Azure, sur le host pool, vous voyez le dashboard Overview : Total machines 2, Can connect 2, Can’t connect 0. Tout est vert :
11. Configurer le Host Pool (RDP, SSO Entra ID, time limits)
Le host pool tourne, mais il faut le configurer un peu avant de laisser les utilisateurs se connecter : périphériques redirigés, single sign-on Entra ID, time limits. Sur la ligne du host pool, trois points > Settings.
Onglet RDP Settings : c’est ici qu’on définit ce qui est redirigé entre le client et la session AVD. J’active Redirect microphone, Redirect speaker, Redirect cameras, Redirect clipboard, Redirect printers :
Je laisse désactivé Redirect all local drives (la sécurité préfère).
Toujours dans RDP Settings, en passant en Custom RDP configuration, je cherche la propriété enablerdsaadauth et je la mets à 1. C’est la propriété qui autorise le single sign-on Entra ID côté RDP ;:
Sans elle, vos utilisateurs vont devoir retaper leur mot de passe à chaque connexion, même avec SSO configuré côté Azure.
Onglet Session Time Limits : j’active la fonctionnalité, je mets Disconnect IDLE sessions after à 1 jour et Log off DISCONNECTED sessions after à 1 heure :
Comme ça les sessions zombies sont nettoyées automatiquement et les licences M365 ne tournent pas dans le vide.
Côté Azure, sur le host pool dans le portail, onglet RDP Properties, vous pouvez vérifier que Microsoft Entra single sign-on est bien sur « Connections will use Microsoft Entra authentication to provide single sign-on » :
C’est le miroir Azure du réglage Nerdio.
Attention : pour que le SSO Entra ID fonctionne complètement, il faut trois choses alignées : (1) enablerdsaadauth=1 dans les RDP properties, (2) le SSO activé sur le host pool côté Azure, (3) les utilisateurs en MFA conforme aux exigences Conditional Access. C’est documenté ici : Configure single sign-on with Microsoft Entra authentication.
12. Assigner les utilisateurs
Sur la ligne du host pool, trois points > Users and groups.
Lors de l’ajout des utilisateurs, Nerdio nous propose de le faire automatiquement :
C’est le rôle qui permet à l’utilisateur de s’authentifier en RDP sur la VM Entra-joined. Sans ça : erreur d’authentification à la connexion.
Côté Azure, sur l’Application Group, onglet Assignments, vous voyez vos utilisateurs apparaître :
C’est l’objet AVD qui décide qui voit le host pool dans Windows App.
Et dans l’IAM, en filtrant sur un utilisateur (avdtest4 par exemple), vous voyez bien le rôle Virtual Machine User Login qui a été attribué automatiquement par Nerdio :
Mon retour terrain : beaucoup de gens oublient ce rôle et passent 30 minutes à se demander pourquoi leur utilisateur voit le host pool dans Windows App mais ne peut pas se connecter (erreur « Your account is configured to prevent you from using this device »). C’est ici que ça se règle, et Nerdio vous le propose automatiquement : c’est exactement la valeur ajoutée du produit.
13. Tester la connexion utilisateur
Le moment de vérité.
On se connecte avec un compte de test sur Windows App (ou windows.cloud.microsoft). Dans la vue Devices, on voit notre workspace et le host pool :
Clic sur la tuile :
Premier signe qui rassure : l’écran « Please wait for the FSLogix Apps Services ». Ça veut dire que FSLogix est en train de monter le profil VHDX depuis le file share Entra Kerberos :
Si vous voyez cet écran, c’est que tout votre prérequis FSLogix doit marcher.
Et voilà : bureau Windows 11 25H2, session AVD multi-session, prête à l’emploi :
14. Vérifier le résultat côté Nerdio et FSLogix
On retourne sur le file share dans le portail Azure.
Et là, magie : un répertoire vient d’être créé par FSLogix, contenant le VHDX du profil utilisateur :
C’est la preuve que le profil persiste, déconnectez l’utilisateur, reconnectez-le sur l’autre VM du host pool, il retrouvera ses paramètres.
Et côté Nerdio, sur la vue User Sessions, on voit la session active. Vous pouvez log off, disconnect ou send message à l’utilisateur depuis là :
Conclusion
Voilà, en une douzaine d’étapes vous êtes passé d’un vNet vide à un environnement AVD multi-session Entra-joined avec FSLogix profiles, SSO Entra ID, et vos utilisateurs assignés, le tout piloté depuis une console unique.
Concrètement, ça donne quoi ?
Là où Microsoft vous fait jongler entre 5 blades du portail (Workspaces, Host pools, Application groups, RDP properties, IAM), Nerdio centralise tout dans une seule UI cohérente. Il vous propose automatiquement les bons réglages, comme le rôle Virtual Machine User Login qu’on aurait pu oublier.
Les 3 pièges à retenir si vous reproduisez en lab :
Le Grant Consent peut nécessiter deux passages, soyez patient.
Pour FSLogix sur un storage Entra ID joined, n’oubliez pas la case « Configure session hosts registry for Entra ID joined storage » et les rôles RBAC sur le file share.
Pour le SSO Entra ID, les trois conditions doivent être réunies : enablerdsaadauth=1 + SSO côté host pool + utilisateurs MFA-compliant.
Et n’oubliez pas le downgrade dev/test (SQL Basic + App Service B1) si vous laissez tourner l’environnement à long terme : ~190 $/mois économisés rien que sur les composants Nerdio.
Foncez tester en lab, c’est gratuit pendant 30 jours en trial Nerdio !
Et si vous galérez sur une étape, dites-le-moi en commentaire, je referai un article plus poussé sur la partie scaling et auto-scale, qui est vraiment là où Nerdio fait la différence.
Pendant longtemps, faire de l’AVD ailleurs que dans Azure, c’était soit du AVD on Azure Local, soit… rien. Pour ceux qui n’avaient pas encore investi dans le HCI mais qui avaient déjà du Hyper-V, du VMware ou du Nutanix qui tournait depuis dix ans en datacenter, l’équation était la même : reverse-proxy + RDS + bricolage maison. Microsoft vient enfin d’ouvrir la porte avec Azure Virtual Desktop Hybrid, en Public Preview depuis le 4 mai 2026.
Today, we’re excited to announce Azure Virtual Desktop for hybrid environments, a new capability for bringing the power of cloud-native desktop virtualization to existing on-premises infrastructure. With this update, on-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.
Et la philosophie de fonctionnement est élégante : Azure Arc enrôle vos VMs on-prem, une extension AVD les transforme en session hosts, et le service AVD continue de vivre dans le cloud comme d’habitude. Bref, pas de nouvelle stack à apprendre, juste une nouvelle case à cocher.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Comme annoncé en introduction, Microsoft a publié le 4 mai 2026 la préversion publique d’Azure Virtual Desktop Hybrid. Le principe est simple : on prend une VM Windows qui tourne déjà chez vous (sur Hyper-V, VMware, Nutanix ou même un serveur physique), on l’enrôle dans Azure Arc, on lui pose une extension AVD, et hop, elle devient un session host AVD à part entière. L’utilisateur se connecte via la Windows App, exactement comme s’il attaquait un host pool 100 % Azure.
With Azure Virtual Desktop Hybrid, customers can run Azure Virtual Desktop session hosts on-premises using their existing hardware and preferred hypervisor connected through Microsoft Azure Arc. The Azure Virtual Desktop service remains in Azure, while session hosts can be deployed anywhere on-premises Azure Arc-enabled servers are supported. Users can access their desktops through the familiar Windows App.
This matters because it gives customers a phased, lower-risk path to cloud adoption:
Modernize legacy VDI environments at their own pace, preserving investments in datacenters, hardware, and operational tools.
Adopt cloud-managed desktops incrementally, with a clear path to migrate session hosts to Azure when the time is right.
Keep existing partner integrationsfor virtual machine management and provisioning.
Pour rappel, jusqu’ici, faire tourner AVD ailleurs que dans Azure imposait soit AVD on Azure Local (anciennement Azure Stack HCI). Cela exigeait d’investir dans une stack HCI Microsoft – soit de partir sur du bon vieux RDS on-prem, en sacrifiant tout l’écosystème AVD (FSLogix moderne, app groups, Insights, Windows App).
Avec AVD Hybrid, ce dilemme s’efface : la documentation Microsoft Learn confirme que les VMs on-prem se comportent comme de vrais session hosts AVD pilotés depuis le portail Azure.
C’est un vrai changement de philosophie : historiquement, AVD c’était « tu déplaces ta VDI dans Azure, et après on en reparle ». Aujourd’hui, c’est « tu gardes ton hyperviseur, on apporte juste le control plane AVD chez toi ».
Ça ouvre AVD à toute une population qui en avait été tenue à l’écart pour des raisons de souveraineté, de coûts d’egress ou tout simplement parce qu’ils avaient déjà payé leur datacenter.
Est-ce la même chose qu’AVD sur Azure Local ?
C’est le même esprit, mais pas la même mécanique. AVD on Azure Local exige une infrastructure HCI Microsoft certifiée, avec ses nœuds, ses switches, son cluster, son réseau SDN. AVD Hybrid, lui, ne demande qu’une chose : une VM Windows qui peut joindre Azure Arc. Le reste, c’est votre hyperviseur qui le gère, peu importe lequel.
Pas besoin de cluster spécifique – une simple VM Windows suffit
Le control plane AVD reste dans Azure (le service est rendu par Microsoft, comme pour AVD classique)
Les session hosts vivent chez vous, et c’est Azure Arc qui sert de pont
Si vous avez déjà déployé des serveurs Azure Arc-Enabled (par exemple pour bénéficier d’Azure Policy, Defender for Cloud ou Update Manager sur du on-prem), vous êtes déjà à 80 % du chemin. Il ne reste plus qu’à poser l’extension AVD et à brancher le session host sur un host pool.
Quels hyperviseurs sont supportés ?
La réponse de Microsoft est volontairement large : tout endroit où Azure Arc peut s’installer. Concrètement, c’est confirmé pour :
Microsoft Hyper-V (Windows Server, Hyper-V Server)
VMware vSphere (ESXi 7.x / 8.x)
Nutanix AHV
Serveurs Windows physiques (oui, vous pouvez transformer un poste rack en session host)
On-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.
Côté partenaires de lancement, Microsoft a explicitement nommé Nerdio, ControlUp, LoginVSI et Nutanix comme étant déjà alignés avec la Preview. Si vous utilisez Nerdio Manager for Enterprise, la fonctionnalité est intégrée dès aujourd’hui.
Quels OS et quelles licences sont éligibles ?
C’est le tableau qu’il faut imprimer et coller à côté de l’écran. Voici la matrice officielle issue de la documentation Microsoft Learn :
OS
Déploiement supporté
Licences éligibles
Windows Server 2016 / 2019 / 2022 / 2025
VMs et serveurs physiques
RDS CAL avec Software Assurance, ou RDS User Licenses en souscription
Windows 11 / Windows 10 Enterprise mono-session
VMs uniquement (pas de PC physique)
M365 E3/E5/A3/A5/F3, M365 Business Premium, Windows Enterprise E3/E5, Windows Education A3/A5, Windows VDA per user
Windows 11 / 10 Enterprise multi-session
Non supporté hors Azure
n/a
Le piège classique pour ceux qui font de l’AVD depuis longtemps : Windows 11 Enterprise multi-session n’est PAS supporté en hybride. Cette SKU reste exclusive à Azure. Si vous voulez du multi-utilisateur sur du on-prem, il faudra repasser sur du Windows Server avec le rôle Remote Desktop Session Host. C’est cohérent avec la philosophie multi-session, qui est historiquement liée à un avantage Azure-only.
Concernant la fameuse licence « Windows Cloud Hybrid » annoncée pour la GA : elle n’est PAS exigée pendant la Public Preview. Vous pouvez tester avec vos licences existantes. À la GA, Microsoft annoncera les conditions tarifaires définitives.
Entra Join ou jointure de domaine ?
Tous les modes sont supportés, et c’est une très bonne nouvelle. Mes propres tests le confirment :
Microsoft Entra Join pur : la VM s’enregistre directement dans le tenant. Idéal pour les machines Windows 11 mono-session, surtout dans une logique zéro-trust. Pas besoin de contrôleur de domaine joignable depuis la VM.
Active Directory (jointure de domaine traditionnelle) : fonctionne parfaitement, surtout pour des Windows Server qui ont besoin de Kerberos pour attaquer des serveurs de fichiers SMB on-prem ou des bases SQL avec authentification intégrée.
Active Directory + Microsoft Entra Connect (jointure de domaine traditionnelle, synchronisée vers Entra) :
Mon retour terrain :
Pour Windows 11 mono-session, l'Entra Join pur est plus rapide à mettre en place et évite tout le pataquès du DC à rendre joignable depuis le réseau de l'hyperviseur.
Pour Windows Server, j'ai gardé le domain-join classique, parce que dans les vrais projets, le serveur de fichiers SMB est très souvent encore en AD on-prem et qu'on veut éviter de mixer les modèles. Les deux cas marchent du premier coup, je le détaillerai plus loin dans les cas pratiques.
Quels sont les prérequis à respecter ?
Avant de se lancer, il faut cocher quelques cases. Voici le récap :
Windows Server 2016+ ou Windows 11/10 Enterprise mono-session
Hyperviseur
Hyper-V, VMware, Nutanix AHV, ou serveur physique
Host pool
Validation host pool obligatoire pendant la Preview
Le piège classique : oublier le resource provider Microsoft.HybridConnectivity, qui est nécessaire pour la connectivité SSH/RDP via Arc. Si vous l’oubliez, l’enrôlement Arc passe, mais certaines opérations downstream peuvent silencieusement échouer. Croyez-en quelqu’un qui a passé une bonne demi-heure à se demander pourquoi 🙃.
Qu’est-ce qu’un « validation host pool » ?
Un validation host pool est un host pool AVD marqué comme environnement de validation (case à cocher dans le portail). Microsoft le réserve aux features en preview, et c’est actuellement le seul mode supporté pour AVD Hybrid pendant la Public Preview. La documentation est explicite :
Azure Virtual Desktop Hybrid is currently in Public Preview and is only supported with validation host pools. If you deploy a production host pool then you will need to redeploy once Windows Cloud Hybrid is Generally Available.
Ne mettez pas en prod votre validation host pool. Servez-vous-en pour piloter, valider votre architecture, former l’équipe, mais prévoyez le redéploiement quand la GA sortira.
Quelles fonctions ne sont PAS supportées en Preview ?
Power management dans le portail Azure (start/stop/deallocate sur les VMs)
Auto-Scale
Start VM on Connect
Session Host Configuration
C’est logique : ces fonctions reposent toutes sur le control plane Azure pour piloter les VMs (les démarrer, les arrêter, les redimensionner). Or, en hybride, c’est votre hyperviseur qui contrôle l’alimentation et le lifecycle des VMs. Microsoft ne peut pas démarrer une VM Hyper-V chez vous… à moins de passer par des extensions Arc dédiées, ce qui n’est pas encore en place.
Attention : l’absence d’Auto-Scale signifie que vous devez prévoir vous-même la scalabilité (provisioning manuel ou via votre orchestrateur d’hyperviseur). Pour des populations de plusieurs centaines d’utilisateurs, ce sera vite un bloqueur si vous comptiez sur AVD pour faire ça à votre place.
Combien ça coûte pendant la Preview ?
Pendant la Public Preview, vous payez :
Vos licences Windows / RDS CAL / M365 (rien de neuf, ce sont les mêmes qu’avant)
L’enrôlement Azure Arc (gratuit pour les serveurs Arc-Enabled de base, payant pour certaines features Defender / Update Manager / Policy avancées)
Le service AVD lui-même (pas de coût supplémentaire spécifique au mode hybride à ce stade)
À la GA, une licence Windows Cloud Hybrid sera très probablement requise pour les session hosts hybrides. Microsoft n’a pas encore communiqué les tarifs définitifs, mais le pattern habituel sur les « extensions cloud d’AVD » laisse penser à un modèle per user / month aligné sur les RDS User License Souscriptions.
Étape 0 : rappel des prérequis
Avant tout test, assurez-vous que :
Vous avez une souscription Azure active
Votre VM on-prem (Hyper-V, VMware, Nutanix…) est installée, à jour, et joignable en TCP 443 sortant vers Internet
Votre identité (Entra Join ou jointure AD) est déjà configurée avant l’enrôlement Arc
Que vous disposiez du rôle Azure Connected Machine Onboarding pour créer et gérer les ressources Azure Arc :
Que vous disposiez du rôle Contributeur à la virtualisation des postes de travail pour la gestion des pools d’hôtes Azure Virtual Desktop.
Étape 1 : enregistrer les resource providers
Sur la souscription cible, ouvrez Subscriptions > [votre sub] > Resource providers, puis vérifiez ou enregistrez si nécessaire :
Dans l’onglet Basics, cochez « Validation environment: Yes »
Cette case est INDISPENSABLE pendant la Preview.
Attention : ne confondez pas validateavd (l’onglet sur la doc Microsoft, qui parle bien d’AVD) avec validatearc. Ce sont deux choses différentes : validateavd est ce qu’on cherche ici. La validation côté Arc (vérifier les resource providers, les rôles RBAC) se fait en parallèle.
Si vous ne disposez pas encore d’un pool d’hôtes AVD, veuillez le créer dans l’étape 3.
Étape 3 : créer le validation host pool, le workspace et l’application group
Si le pool d’hôtes AVD n’est pas encore créé dans votre environnement Azure, commencez par la base via l’assistant de création du host pool AVD :
Basics : nom (par exemple HP-AVDHybrid-Lab), région du metadata (dans mon cas Europe), type Pooled ou Personal selon votre besoin, et validation environment: Yes.
Virtual machines : choisir « No, I’ll add VMs later ». Les VMs seront ajoutées via l’enrôlement Arc + extension AVD, pas par le wizard Azure.
Workspace : créez-en un nouveau (par exemple WS-AVDHybrid-Lab) ou attachez-en un existant.
Tags et Review + create : validez.
Si cela n’est pas déjà le cas non plus, créez ensuite un application group (Desktop ou RemoteApp) et liez-le au workspace. C’est ce qui sera publié à l’utilisateur :
Étape 4 : onboarder la VM on-prem dans Azure Arc
Sur la VM on-prem, on va installer l’agent Azure Connected Machine, qui est le pont entre votre datacenter et Azure :
Dans le portail Azure, allez dans Azure Arc > Machines > Add.
Choisissez « Add a single server » (pour le lab) ou « Add multiple servers » (pour générer une clé partagée).
Renseignez la souscription, le group de ressources, la région.
Téléchargez le script d’onboarding PowerShell généré automatiquement.
Exécutez-le en administrateur sur la VM on-prem.
Le script télécharge l’agent (AzureConnectedMachineAgent.msi), l’installe, puis lance azcmagent connect avec les paramètres de votre tenant.
Au bout de 2 à 5 minutes, la VM apparaît dans Azure Arc > Machines avec un statut Connected.
Attention : la VM doit être déjà jointe à votre identité cible (Entra Join OU jointure de domaine) avant l’enrôlement Arc. Si vous changez de modèle d’identité après coup, il faut désinstaller l’agent Arc et tout recommencer. Ne sautez pas cette étape.
Étape 5 : installer l’extension AVD Azure Arc et enregistrer le session host
C’est ici que les deux mondes se rejoignent, et c’est l’étape qui m’a le plus surpris. Contrairement à ce qu’on pourrait croire, l’enregistrement du session host hybride ne se fait pas via le bouton « + Add » du host pool dans le portail.
Il faut exécuter manuellement un script PowerShell, qui va poser l’extension Microsoft.AzureVirtualDesktop.CloudDeviceExtension sur le compte Arc de la machine. C’est cette extension et non l’agent AVD classique qui réalise l’enregistrement.
Attention : si vous oubliez le Set-AzContext et que votre compte est rattaché à plusieurs souscriptions, le New-AzConnectedMachineExtension ira chercher la VM Arc dans la mauvaise souscription et vous tombera sur une erreur « machine not found » très peu parlante. Toujours vérifier avec Get-AzContext avant d’enchaîner.
Générez une clé d’enregistrement du pool d’hôtes AVD via ce script PowerShell :
$token = la registration key générée a une durée de vie limitée (max 27 jours), donc générez-la juste avant de jouer le script
ResourceGroupName et MachineName = ceux de la ressource Arc dans Azure (pas le hostname Windows brut, mais le nom sous lequel la VM apparaît dans Azure Arc > Machines)
Location = la région Azure du resource group de la machine Arc (francecentral, westeurope, etc.), pas la « localisation physique » de votre datacenter
isCloudDevice = $false est essentiel : c’est ce flag qui dit à l’extension qu’on est en mode hybride, et pas sur une VM Azure native
La registration key passe en protectedSettings, elle n’apparaîtra donc pas en clair dans la définition de l’extension
L’extension met 3 à 5 minutes à se déployer :
En coulisses, elle installe les composants AVD nécessaires (équivalent de l’agent et du bootloader sur les VMs Azure natives) et enregistre la machine auprès du host pool grâce au token.
Au bout de quelques minutes, la VM apparaît dans la liste Session hosts du host pool, avec un statut Available. Du point de vue d’AVD, c’est une VM « comme les autres » et c’est tout l’intérêt de la mécanique d’Azure Arc.
Comme pour les machines AVD hébergées dans Azure, des contrôles réguliers sont appliquées afin de vérifier leur disponibilité :
Un échec dans les contrôles AVD rendra la machine indisponible pour recevoir de nouvelles sessions utilisateurs :
Étape 6 : assigner les utilisateurs AVD
Dernière ligne droite :
Ouvrez votre application group (Desktop ou RemoteApp).
Allez dans Assignments et ajoutez les utilisateurs ou groupes Microsoft Entra qui doivent pouvoir se connecter.
Étape 7 : test de connexion AVD
Côté utilisateur : ouvrez la Windows App (web ou client lourd) et connectez-vous avec le compte Entra ID assigné.
Le desktop publié par votre validation host pool hybride apparaît. Cliquez, c’est parti.
Et voilà : vous êtes connecté à un Windows qui tourne chez vous, mais piloté par AVD dans le cloud. Première fois que je l’ai vu marcher, ça m’a clairement fait sourire 😅
Cas n°1 : Hyper-V + Windows Server domain-joined
Premier cas testé dans mon lab : une VM Windows Server 2022 qui tourne sur un nœud Hyper-V standalone, jointe à mon AD on-prem (lui-même synchronisé vers Entra ID via Microsoft Entra Connect).
OS : Windows Server 2022 Standard
Hyperviseur : Hyper-V (Windows Server 2022)
Identité : jointure de domaine AD on-prem + sync Entra Connect
Licence : Windows Server + RDS CAL
Déroulé : enrôlement Arc nickel en 3 minutes, extension AVD posée en 5 minutes, session host visible Available dans le host pool. Connexion via la Windows App avec un user du domaine sync vers Entra : OK, RDP qui négocie en 2 secondes, le bureau s’affiche. Aucun ajustement particulier nécessaire. C’est le scénario le plus « facile » car on retrouve une cinématique classique RDS, juste branchée sur AVD.
Mon retour : c’est le scénario à privilégier pour migrer un parc RDS existant. Vous gardez votre AD, vos GPO, vos profils, votre serveur de fichiers SMB, et vous échangez juste votre broker / gateway / web access RDS contre AVD. Le gain est majeur : vous récupérez la Windows App, FSLogix moderne, l’intégration Entra ID, les Insights, sans toucher à votre infra serveur.
Cas n°2 : Hyper-V + Windows 11 mono-session Entra-joined
Deuxième cas, plus moderne et plus zéro-trust : une VM Windows 11 Enterprise mono-session qui tourne aussi sur Hyper-V, mais cette fois sans aucune jointure AD, uniquement Microsoft Entra Join.
OS : Windows 11 Enterprise 24H2 (mono-session)
Hyperviseur : Hyper-V
Identité : Microsoft Entra Join pur (pas d’AD)
Licence : Microsoft 365 Business Premium
Déroulé : avant tout, j’ai pris soin de faire l’Entra Join AVANT l’enrôlement Arc (via Settings > Accounts > Access work or school). Une fois la VM jointe au tenant, l’agent Arc s’installe normalement, l’extension AVD se pose, et le session host apparaît dans le host pool. Connexion via la Windows App avec un user Entra : OK, single sign-on transparent grâce à Entra Join.
Mon retour : c’est le scénario qui me plaît le plus pour des nouveaux projets. Pas de DC à exposer au réseau de l’hyperviseur, pas de Kerberos, pas de GPO – juste Entra ID, les policies Intune, et c’est tout. Pour des cabinets, des équipes projet, des labs, ou tout ce qui n’a pas besoin de Kerberos vers du legacy, c’est la voie royale. Pour rappel : Windows 11 multi-session reste interdit en hybride, donc pour cette population, c’est mono-session ou rien.
Cas n°3 : VMware vSphere + Windows Server
Troisième cas, et celui qui intéressera beaucoup d’entreprises encore très VMware-centric : une VM Windows Server 2025 sur VMware vSphere 8, jointe au domaine.
OS : Windows Server 2025 Standard
Hyperviseur : VMware vSphere 8 (ESXi 8.0 U2)
Identité : jointure de domaine AD on-prem
Licence : Windows Server + RDS CAL
Déroulé : identique au cas n°1, à 100 %. C’est exactement ça qui est bluffant. Du point de vue d’Azure Arc et d’AVD, qu’il y ait du Hyper-V ou du vSphere en dessous ne change strictement rien. Tant que l’agent Connected Machine s’installe et que la VM peut sortir en TCP 443, c’est jeu. J’ai posé l’agent Arc, lancé l’extension AVD, le session host est apparu en Available, et un utilisateur du domaine s’est connecté via la Windows App sans broncher.
Mon retour : c’est le cas le plus politique. Pour beaucoup de DSI, « passer chez Microsoft » voulait jusqu’ici dire « abandonner VMware ». AVD Hybrid permet exactement l’inverse : garder vSphere, ne pas refaire toute son infra, et bénéficier quand même du control plane AVD moderne. Pour les organisations qui ont investi dans vSphere récemment (et il y en a beaucoup, surtout après les bouleversements de licensing VMware), c’est un message fort de Microsoft : pas besoin de tout casser pour profiter d’AVD.
Le résumé visuel de mes trois cas :
Cas
Hyperviseur
OS
Identité
Résultat
1
Hyper-V
Windows Server 2022
AD domain-join
OK – idéal pour reprise RDS
2
Hyper-V
Windows 11 mono-session
Entra Join pur
OK – idéal pour green-field zéro-trust
3
VMware vSphere 8
Windows Server 2025
AD domain-join
OK – idéal pour parcs vSphere existants
Et la conclusion qui me semble importante : les trois cas suivent rigoureusement la même procédure. La doc Microsoft est tenue à la lettre, les scripts d’onboarding fonctionnent à l’identique, l’extension AVD se pose pareil. Aucune divergence d’OS ou d’hyperviseur n’a nécessité de bricolage particulier. C’est rare et c’est notable.
Les limitations et pièges à connaître
Parce qu’on est en Public Preview, il y a quelques verrues à garder en tête :
Limitation
Impact
Validation host pool obligatoire
Tout passage en prod nécessitera un redéploiement à la GA
Windows 11 multi-session non supporté hors Azure
Multi-utilisateur obligatoire = Windows Server
Auto-Scale absent
Provisioning manuel ou via votre orchestrateur d’hyperviseur
Start VM on Connect absent
Les session hosts doivent être déjà allumés côté hyperviseur
Power management Azure portal absent
Le start/stop se fait dans votre console d’hyperviseur, pas Azure
Session Host Configuration absent
Pas de « build automatique » du session host depuis le portail
Identité à fixer AVANT Arc
Changer d’identité après onboarding = désinstaller / réinstaller
Pas de date de GA annoncée
À tester en pilote, pas à passer en prod critique
Et comme toujours avec les previews Microsoft, la feature peut encore évoluer avant la GA (interface, intégrations supplémentaires, prise en charge du multi-session, modèle de licence Windows Cloud Hybrid). À surveiller de près.
Conclusion
C’est clairement l’une des évolutions que beaucoup de monde attendait, et pas juste les fans de la marque AVD (comme moi 😅). AVD Hybrid règle un vrai point bloquant : pour faire du AVD ailleurs que dans Azure, il fallait jusqu’ici passer par Azure Local et son hardware certifié, ce qui excluait de fait toutes les entreprises encore en VMware ou Nutanix. Avec cette préversion, Microsoft signe un geste d’ouverture rare : votre hyperviseur, peu importe lequel, peut héberger des session hosts AVD pilotés par Azure Arc.
Ce qui me plaît particulièrement : la cohérence de la procédure entre les trois cas que j’ai testés (Hyper-V Server domain-joined, Hyper-V Windows 11 Entra-joined, VMware vSphere domain-joined), la simplicité du branchement via Azure Arc (les admins qui pratiquent déjà Arc sur du Defender for Cloud ou de l’Update Manager seront en territoire connu), et le fait qu’on retrouve l’écosystème AVD complet (Windows App, Entra ID, FSLogix, Insights) plutôt qu’une version dégradée.
Ce qui mérite vigilance : le statut Public Preview qui impose des validation host pools, l’absence d’Auto-Scale qui peut bloquer pour les gros parcs, l’interdiction du multi-session hors Azure qui force à repenser certains designs, et le flou sur la licence Windows Cloud Hybrid qui arrivera à la GA. Je l’intègre dès maintenant dans mes projets PoC, mais avec un pilote propre avant toute généralisation.
En tout cas, si vous avez du Hyper-V, du VMware ou du Nutanix qui tourne en datacenter, foncez tester : Azure portal > Azure Virtual Desktop > Host pools > Create, cochez Validation environment: Yes, puis enrôlez vos VMs via Azure Arc et posez l’extension AVD.
La documentation officielle est claire et la procédure marche du premier coup. Et dites-moi dans les commentaires ce que vous en pensez, surtout si vous avez essayé sur un hyperviseur que je n’ai pas couvert (Proxmox ? KVM ? Hyper-V Azure Local ?), je suis curieux de vos retours !
Dans les environnements de bureaux à distance modernes (Azure Virtual Desktop, Windows 365, Citrix …) l’expérience utilisateur dépend énormément du protocole d’affichage distant, du réseau, des ressources , … Quand tout fonctionne bien, personne ne s’en préoccupe. Mais dès qu’un utilisateur dit : « mon Cloud PC lag », « la vidéo est saccadée », « j’ai un délai quand je tape au clavier » … on entre immédiatement dans une zone grise. Bon courage pour comprendre la cause !
Un problème d’affichage distant peut venir de nombreux endroits : réseau, client, serveur, GPU, codec vidéo, politiques de compression et j’en passe.
C’est exactement pour cela que j’aime beaucoup un outil que j’utilise régulièrement lors de phases de troubleshooting : Remote Display Analyzer (RDA).
Cet outil permet de voir et tester en direct ce que fait réellement le protocole d’affichage distant :
Avant d’aller plus loin, je voulais remercier l’équipe RDA de m’avoir donné une licence pour réaliser mes tests.
Et pour vous guider plus facilement dans cet article très long, voici des liens rapides :
Remote Display Analyzer (RDA) est un petit et très léger outil conçu pour analyser les protocoles d’affichage utilisés dans les environnements de virtualisation de poste de travail.
Il ne supporte pas que des environnements Microsoft, mais bon nombre de solutions présentes sur le marché, notamment :
Microsoft RDP
Azure Virtual Desktop
Windows 365
Citrix HDX
Omnissa / VMware Horizon Blast
Nutanix Frame
Combien coûte RDA ?
Remote Display Analyzer est décliné en plusieurs éditions afin de répondre à des besoins différents. En plus de l’édition Community, il existe une édition Personal ainsi qu’une édition Company, qui offrent des fonctionnalités avancées adaptées à des usages plus professionnels ou à grande échelle :
Il existe une version gratuite de RDA : l’édition Community permet d’accéder aux statistiques temps réel du protocole d’affichage, ce qui est largement suffisant pour de nombreux scénarios de diagnostic et de troubleshooting :
Voici un lien de téléchargement de la version gratuite de RDA. Enfin les deux autres versions payantes sont plus complètes, et remontent plus données :
Comment fonctionne RDA ?
Comme annoncé plus haut, Remote Display Analyzer ne nécessite aucune installation préalable. L’outil se présente sous la forme d’un simple exécutable qui peut être lancé directement à l’intérieur d’une session distante, sans configuration particulière.
Voici un lien vers ses fonctionnalités. Dès que RDA est lancé, il détecte automatiquement :
le protocole utilisé
le mode d’affichage actif
l’encodeur vidéo
Dans le cas d’Azure Virtual Desktop, Remote Display Analyzer permet également de vérifier si la session utilise RDP Shortpath.
RDP Shortpath est un mode de transport UDP qui permet d’améliorer les performances et de réduire la latence dans les sessions AVD.
Lorsque Shortpath est actif, le trafic RDP ne passe plus uniquement par le service de gateway Azure, mais peut établir un chemin direct entre le client et la machine virtuelle.
Remote Display Analyzer permet de vérifier immédiatement si la session utilise le transport TCP classique ou le mode UDP (RDP Shortpath) :
C’est extrêmement utile lors de phases de troubleshooting pour vérifier si la configuration réseau permet bien l’utilisation de Shortpath.
Il affiche également différentes métriques en temps réel, comme par exemple :
bande passante utilisée
latence réseau
nombre de frames
frames perdues
GPU
Il vous informe sur les statistiques portant sur les paquets envoyés et les contraintes potentielles sur ces derniers, mais également sur les FPS envoyés :
Enfin, il vous donne des informations utiles sur le GPU :
Dans les environnements Azure Virtual Desktop ou Windows 365 utilisant des machines virtuelles avec GPU (par exemple NV-series ou NVads), l’encodage vidéo peut être offloadé vers le GPU. Lorsque cette accélération est active :
la charge CPU diminue
l’encodage vidéo devient plus rapide
l’expérience utilisateur est plus fluide
Remote Display Analyzer permet de vérifier si l’encodeur vidéo GPU est réellement utilisé et d’observer en temps réel la latence de l’encodeur ainsi que le nombre de frames générées.
Cela permet notamment de vérifier que les politiques GPU sont correctement appliquées sur les session hosts AVD.
Comment interpréter les métriques de RDA ?
Certaines métriques sont particulièrement utiles pour comprendre l’expérience utilisateur.
FPS :
Un environnement fluide tourne généralement entre 25 FPS et 60 FPS
En dessous de 20 FPS, les utilisateurs commencent souvent à percevoir des saccades.
Latence round-trip :
< 40 ms → excellent
40-80 ms → correct
100 ms → visible
Video Encoder Latency
Une latence encodeur trop élevée peut indiquer : CPU saturé, GPU absent, codec mal configuré
Qu’est-ce que les « Skipped Frames » ?
Dans les protocoles d’affichage distants, toutes les images générées par l’application ne sont pas forcément envoyées au client.
Lorsque certaines ressources deviennent limitées, le protocole peut décider d’ignorer certaines images afin de maintenir une expérience utilisateur acceptable.
Remote Display Analyzer permet d’identifier trois types de frames ignorées :
Skipped frames – client
Cela signifie que le client ne peut pas décoder ou afficher les images assez rapidement. Les causes les plus fréquentes sont :
client peu puissant
GPU absent
décodage vidéo logiciel
écran haute résolution
Skipped frames – network
Dans ce cas, c’est le réseau qui devient le facteur limitant. Le protocole décide alors de réduire le flux graphique. Cela peut être causé par :
bande passante insuffisante
latence élevée
pertes de paquets
congestion réseau
Skipped frames – server
Ici le problème vient du serveur lui-même. Cela peut être dû à :
CPU saturé
GPU saturé
trop de sessions par host
encodage vidéo trop lourd
Quelques exemples de problèmes que RDA permet d’analyser :
Un premier cas fréquent concerne la latence élevée dans les sessions distantes. Les utilisateurs peuvent ressentir un délai entre l’action réalisée sur le clavier ou la souris et la réaction affichée à l’écran. Dans ce type de situation, Remote Display Analyzer permet de visualiser la latence réseau, le nombre de frames envoyées et les éventuelles frames perdues afin d’identifier si le problème vient du réseau, du serveur ou du client.
Dans l’exemple ci-dessous, RDA analyse une session Windows 11 dans Azure Virtual Desktop :
Comme la vidéo le montre, il peut être très instructif de simuler différents niveaux de latence réseau afin d’observer comment la session se comporte dans des conditions WAN plus difficiles. Remote Display Analyzer permet alors de suivre en temps réel l’impact de la latence sur la fluidité et la réactivité.
Un autre problème courant concerne les vidéos ou les animations qui deviennent saccadées. Les utilisateurs peuvent par exemple remarquer que Microsoft Teams, YouTube ou certaines applications graphiques ne sont pas fluides. Dans ce cas, l’outil permet d’analyser le nombre d’images par seconde, le codec vidéo utilisé ainsi que la bande passante réellement consommée par la session :
On rencontre également souvent des problèmes d’image floue ou de compression trop forte. Dans ces situations, le texte peut sembler légèrement dégradé ou certaines images peuvent apparaître très compressées. Remote Display Analyzer permet alors de tester différents niveaux de compression et différentes qualités d’image afin de trouver le bon compromis entre qualité visuelle et consommation réseau.
Enfin, certains environnements rencontrent des problèmes de charge CPU trop élevée sur les serveurs. Cela peut se produire lorsque l’encodage vidéo est effectué par le CPU plutôt que par le GPU. Dans ce type de scénario, RDA permet de vérifier si l’encodage GPU est réellement utilisé ou si le CPU est responsable du traitement graphique :
Peut-on modifier certains réglages graphiques avec RDA ?
Ce qui rend l’outil vraiment intéressant est une autre capacité. Remote Display Analyzer permet de modifier certains paramètres d’affichage en live pour les environnements Citrix. Cela permet de faire des tests très rapides pour comprendre l’impact réel d’une configuration. Par exemple :
codec vidéo
profondeur de couleur
compression
qualité d’image
frames par seconde
Comme le rappelle l’éditeur dans leur FAQ, RDA nécessite les droits administrateur pour pouvoir effectuer ces modifications.
Conclusion
Remote Display Analyzer est un outil extrêmement simple, mais particulièrement utile dans les environnements EUC.
Lorsqu’un utilisateur signale que son bureau distant est lent ou que la vidéo est saccadée, il est souvent difficile de savoir immédiatement si le problème vient du réseau, du client, du serveur ou du protocole lui-même.
Grâce à ses métriques en temps réel et à sa capacité à modifier certains paramètres graphiques à la volée, Remote Display Analyzer permet de mieux comprendre le comportement du protocole d’affichage distant.
Pour les administrateurs travaillant avec Azure Virtual Desktop, Windows 365, Citrix ou Horizon, c’est clairement un outil que je recommande d’avoir dans sa boîte à outils de troubleshooting.
Le rachat de VMware par Broadcom a agi comme un électrochoc. Aujourd’hui, la question n’est plus faut-il migrer? , mais comment migrer sans tout casser ou y perdre tous ses cheveux?. Entre les solutions tierces payantes et les méthodes manuelles risquées, Microsoft a discrètement sorti une arme redoutable : l’extension VM Conversion pour Windows Admin Center (WAC).
Après avoir testé l’outil encore en préversion, je voulais partager avec vous mon expérience. Et pour vous guider plus facilement dans cet article très long, voici des liens rapides :
Le rachat de VMware par Broadcom a agi comme un électrochoc. Beaucoup de clients ont vu les coûts augmenter fortement après le rachat, car Broadcom a changé le modèle de licences (par exemple passage d’une licence perpétuelle à un modèle d’abonnement) et restructuré les offres. Certains ont reçu des renouvellements jusqu’à plusieurs fois plus chers qu’avant pour les mêmes besoins.
Ces changements rapides dans la structuration des produits, des bundles et du support ont créé de l’incertitude sur la roadmap et l’avenir des produits VMware, ce qui amène les DSI à repenser leurs choix technologiques à long terme
On retrouve d’ailleurs pas mal de blogueurs parlant de cet exode :
Présent depuis des années, Windows Admin Center (souvent abrégé WAC) est un outil d’administration web développé par Microsoft pour gérer des serveurs Windows, des clusters et des environnements hyperconvergés, depuis une interface moderne accessible via navigateur.
Concrètement, Windows Admin Center vous permet d’administrer, sans passer par du RDP, un grand nombre de services Microsoft :
Windows Server
Hyper-V
Clusters (Failover Clustering)
Machines virtuelles
Serveurs distants (on-prem ou Azure)
Stockage (Storage Spaces Direct)
Qu’est-ce que l’extension VM Conversion ?
C’est un nouvel outil Microsoft intégré à Windows Admin Center qui permet de migrer des machines virtuelles depuis VMware vCenter/ESXi vers Hyper-V, en mode agentless :
Actuellement, Il s’agit d’une extension prévue pour minimiser le temps d’arrêt grâce à la réplication en ligne des disques.
Attention, cette extension n’est pas pour but de migrer vers Azure Local. Un autre article déjà écrit il y a plusieurs mois traite de ce type de migration : de VMware à Azure Local.
Combien coûte VM Conversion ?
L’extension est actuellement en préversion. Son usage n’implique aucun coût de licence supplémentaire, mais pas non plus de support garanti par Microsoft.
Tous les vCenter VMware 6.x, 7.x et 8.x sont pris en charge
Côté OS invités :
Windows Server 2025, 2022, 2019, 2016, 2012 R2
Windows 10/11
Ubuntu 20.04, 24.04
Debian 11, 12
Alma Linux
CentOS
Red Hat Linux 9.0
L’extension fonctionne également dans un environnement Hyper-V en cluster (WSFC) : elle est cluster-aware et détecte correctement les nœuds et ressources.
Il supporte la migration de VM depuis ESXi vers des clusters Windows Server Failover (WSFC) sous Hyper-V. Vous pouvez donc distribuer les VM migrées sur plusieurs nœuds Hyper-V pour HA ou performances.
Quels sont les prérequis pour VM Conversion?
Côté Windows Admin Center :
WAC en version au moins v2410 build 2.4.12.10 ou supérieure
PowerShell et PowerCLI installés
VMware VDDK version 8.0.3 installé
Visual Studio 2013 et 2015 installés
Côté Hyper-V :
le rôle Hyper-V doit être installé sur le (s) hôte (s) cible
Le compte utilisé durant le processus doit être administrateur local ou membre du groupe Hyper-V Administrators).
Si des VMs migrées sont sous Linux, les modules Hyper-V (hv_vmbus, hv_netvsc, hv_storvsc) et Linux Integration Services (hyperv-daemons ou linux-cloud-tools) doivent être pré-installés dans l’initramfs avant migration.
Combien de VM puis-je migrer simultanément ?
Jusqu’à 10 machines virtuelles par lot. On peut grouper ces machines selon leur dépendance applicative, leur placement dans un cluster ou même selon des critères métier (ex : séparer environnement de test/prod). Cela facilite les migrations massives par workload.
Comment l’outil VM Conversionmarche ?
Microsoft explique bien les deux phases présentes dans l’outil VM Conversion :
Synchronisation : l’extension effectue une copie complète initiale des disques de la machine virtuelle pendant que la VM source continue de fonctionner. Cette phase minimise les temps d’arrêt en vous permettant de planifier la migration finale à un moment qui vous convient.
Migration : l’extension utilise la fonctionnalité Change Block Tracking (CBT) pour rechercher et répliquer uniquement les blocs modifiés depuis la dernière synchronisation. Pendant la transition, la machine virtuelle source est mise hors tension et une synchronisation delta finale capture toutes les modifications restantes avant d’importer la machine virtuelle dans Hyper-V.
Pendant la phase de synchronisation, la VM source continue de tourner, pendant qu’une copie initiale des disques est envoyée sur l’hôte Hyper-V, via la création d’un snapshot pour suivre les changements.
Au moment de la bascule, la VM source est arrêtée pour un dernier delta-sync avant import; ce processus réduit donc au minimum la fenêtre d’arrêt.
Que devient VMware Tools sur le VM migré ?
La présence de VMware Tools dans une VM sous Hyper-V peut provoquer des conflits de pilotes, donc il vaut mieux les retirer.
Initialement, il fallait supprimer les outils VMware Tools manuellement après la bascule vers Hyper-V.
Depuis la version 1.8.0, l’extension supprime automatiquement VMware Tools sur les VM Windows migrées en fin de processus.
Pour les VM Linux, il est recommandé de ne pas réinstaller open-vm-tools sur la cible Hyper-V (on s’appuie uniquement sur les pilotes Hyper-V ajoutés).
Et enfin, comme toujours, je vous propose dans la suite de cet article d’effectuer ensemble un pas à pas pour couvrir la migration de machines virtuelles hébergées sur VMware vers Hyper-V :
Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Hyper-V via Windows Admin Center. Pour tout cela, j’ai utilisé :
Un environnement VMware
Un environnement Hyper-V
Une connexion réseau entre le réseau les deux hyperviseurs
Commençons par l’installation de Windows Admin Center sur une nouvelle machine hébergée sur VMware.
Etape I – Installation de Windows Admin Center :
Sur une machine virtuelle dédiée dans votre environnement VMware, téléchargez la dernière version de Windows Admin Center depuis la page officielle de Microsoft :
Choisissez l’installation avec l’option Express :
Dans cette démonstration, utilisez un certificat temporaire :
Lancez l’installation :
Une fois l’installation terminée, ouvrez la page de Windows Admin Center, puis authentifiez-vous avec votre compte :
Une fois connecté dans la console Windows Admin Center, attendez quelques minutes la fin de l’installation des extensions préinstallées :
Rendez vous dans les paramétrages dans WAC afin d’ajouter l’extension dédiée à la migration :
Etape II – Installation de prérequis WAC :
Comme indiqué dans la documentation Microsoft, certains prérequis doivent être installés sur la machine de Windows Admin Center.
Récupérez et décompressez VMware Virtual Disk Development Kit (VDDK), en version 8.0.3, dans le dossier WAC suivant :
Redémarrez ensuite votre machine virtuelle contenant Windows Admin Center.
Etape III – Connexion à Hyper-V depuis WAC :
Une fois la machine virtuelle WAC redémarrée, rouvrez la console, puis cliquez ici pour ajouter une connexion vers votre serveur Hyper-V :
Cliquez sur Ajouter :
Renseignez l’adresse IP de votre Hyper-V, les éléments d’identification, puis cliquez sur Ajouter :
La connexion est établie, cliquez dessus pour l’ouvrir :
Dans le menu de gauche, cherchez l’extension consacrée à la migration, cochez la case suivante pour installer PowerCLI, puis cliquez ici :
Attendez la fin de l’installation de PowerCLI :
Une fois l’installation terminée, cliquez ici ajouter une connexion à votre vCenter, renseignez vos informations de connexion, puis cliquez ici :
Une fois la connexion établie avec vCenter, les machines virtuelles s’afficheront :
Le protocole de test est maintenant en place. Commençons les tests par la migration d’une machine virtuelle fonctionnant sous Windows Server.
Etape IV – Test Windows : Synchronisation de la VM :
Toujours dans la liste des machines virtuelles, cochez sur une des VMs Windows disponibles, puis cliquez ici pour démarrer la synchronisation :
Renseignez le dossier de destination sur votre serveur Hyper-V, puis cliquez sur Synchroniser :
La phase de vérification préalable à la migration vient de démarrer (accessibilité, compatibilité matérielle, compatibilité OS, configuration réseau, …) :
La première copie des disques VMDK vers Hyper-V est en cours pour la création des fichiers VHDX par la suite :
Constatez d’ailleurs la création du dossier sur le serveur Hyper-V :
La migration passe en mode synchronisation différentielle afin de ne copier que les blocs modifiés depuis la synchronisation initiale, réduisant ainsi le volume de données à transférer avant le cutover :
Provisioning du disque cible Hyper-V (VHDX) : l’infrastructure prépare le stockage avant l’application des blocs synchronisés issus de la VM VMware :
Phase de delta sync : les blocs modifiés identifiés via CBT sont appliqués au disque Hyper-V afin d’aligner la VM cible avec l’état courant de la VM source :
Le monitoring de la carte réseau montre bien le transfert des données :
Synchronisation complète (100 %) : l’intégralité des données de la VM source est maintenant répliquée côté Hyper-V :
La VM cible est maintenant entièrement alignée avec la VM VMware et peut être basculée vers Hyper-V avec un dernier delta minimal.
Nous allons pouvoir procéder à la migration.
Etape V – Test Windows : Migration de la VM :
A ce stade, la machine virtuelle sous VMware est toujours allumée :
Testez le delta de migration en rajoutant sur votre machine virtuelle source de nouveaux fichiers :
Retournez ensuite sur Windows Admin Center afin de lancer la migration de celle-ci :
Choisissez ou non de désinstaller les outils VMware, puis cliquez ici :
Lancement de la migration : exécution des vérifications préalables avant bascule définitive vers la VM Hyper-V cible :
Vérifications pré-migration terminées : la synchronisation finale des blocs modifiés (delta sync) est en cours avant l’arrêt et la bascule de la VM :
Un snapshot est bien créé côté VMware :
Delta Sync en cours : application des derniers blocs modifiés afin d’aligner définitivement la VM cible avant le cutover final vers Hyper-V.
Arrêt de la VM source : la machine VMware est éteinte et la phase finale de synchronisation est lancée avant le démarrage côté Hyper-V :
La machine virtuelle est bien arrêtée côté VMware :
Migration terminée (100 %) : la VM cible Hyper-V est créée, synchronisée et prête à être démarrée en production :
La VM migrée s’exécute désormais sur Hyper-V, confirmant le succès du cutover depuis l’environnement VMware :
Windows détecte un arrêt inattendu lié au cutover, confirmant que la VM a bien été basculée depuis l’environnement VMware vers Hyper-V :
Erreur VMware Tools au premier démarrage : les anciens composants VMware, désormais incompatibles sous Hyper-V, doivent être désinstallés après la migration :
Désinstallez les VMware Tools devenus inutiles après le passage de la VM sous Hyper-V :
Les fichiers créés avant la commande Migrate sont bien présents après la bascule, confirmant l’intégrité de la synchronisation finale :
Notre serveur Windows a bien été migré depuis VMware vers Hyper-V avec succès. Testons maintenant la même opération avec un serveur Linux.
Etape VI – Test Linux : Synchronisation de la VM :
Exemple réalisé ici sur AlmaLinux / RHEL-like. Le but étant de :
Désinstaller VMware Tools
Installer composants Hyper-V
Recréer initramfs si nécessaire
Reboot
Pour cela créez une machine virtuelle Linux dont l’OS est compatible avec l’outil de Migration :
Avant la migration, ajoutez les pilotes Hyper-V à l’initramfs, reconstruction avec dracut, puis redémarrage pour assurer un démarrage correct sous Hyper-V.
Toujours avant la migration, installez des services d’intégration Hyper-V (hyperv-daemons) afin d’optimiser les performances et l’interaction entre la VM Linux et l’hôte Hyper-V.
Exemple réalisé sur une distribution RHEL-like (AlmaLinux / Rocky / RHEL). (Adaptez la commande si vous êtes sur Ubuntu ou Debian) :
sudo dnf install hyperv-daemons -y
Vérifiez le chargement des modules Hyper-V (hv_*) dans le noyau Linux afin de confirmer la bonne prise en charge de l’environnement Hyper-V :
Toujours dans la liste des machines virtuelles, cochez sur une des VMs Linux disponibles, puis cliquez ici pour démarrer la synchronisation :
Renseignez le dossier de destination sur votre serveur Hyper-V, puis cliquez sur Synchroniser :
La phase de vérification préalable à la migration vient de démarrer (accessibilité, compatibilité matérielle, compatibilité OS, configuration réseau, …) :
La première copie des disques VMDK vers Hyper-V est en cours pour la création des fichiers VHDX par la suite :
Constatez d’ailleurs la création du dossier sur le serveur Hyper-V :
La migration passe en mode synchronisation différentielle afin de ne copier que les blocs modifiés depuis la synchronisation initiale, réduisant ainsi le volume de données à transférer avant le cutover :
Phase de delta sync : les blocs modifiés identifiés via CBT sont appliqués au disque Hyper-V afin d’aligner la VM cible avec l’état courant de la VM source :
Le monitoring de la carte réseau montre bien le transfert des données :
Synchronisation complète (100 %) : l’intégralité des données de la VM source est maintenant répliquée côté Hyper-V :
La VM cible est maintenant entièrement alignée avec la VM VMware et peut être basculée vers Hyper-V avec un dernier delta minimal.
Nous allons pouvoir procéder à la migration.
Etape VII – Test Linux : Migration de la VM :
Retournez ensuite sur Windows Admin Center afin de lancer la migration de celle-ci :
Lancement de la migration : exécution des vérifications préalables avant bascule définitive vers la VM Hyper-V cible :
Arrêt de la VM source : la machine VMware est éteinte et la phase finale de synchronisation est lancée avant le démarrage côté Hyper-V :
La machine virtuelle est bien arrêtée côté VMware :
Migration terminée (100 %) : la VM cible Hyper-V est créée, synchronisée et prête à être démarrée en production :
La VM migrée s’exécute désormais sur Hyper-V, confirmant le succès du cutover depuis l’environnement VMware :
Conclusion
La migration d’un environnement VMware vers Hyper-V n’est jamais une décision anodine. Elle est souvent motivée par des enjeux économiques, stratégiques ou organisationnels. Mais quelle qu’en soit la raison, elle doit rester avant tout une opération maîtrisée, structurée et techniquement fiable.
L’extension VM Conversion de Windows Admin Center n’est pas un simple assistant graphique. Elle propose une approche orchestrée et cohérente : synchronisation initiale, delta via CBT, puis phase de bascule contrôlée. Ce n’est pas “magique” et cela ne dispense pas d’une préparation sérieuse. En revanche, l’outil apporte un cadre clair qui simplifie fortement un processus historiquement complexe.
Dans mes tests, l’expérience s’est révélée stable et lisible. La gestion des clusters Hyper-V (WSFC), la logique de synchronisation progressive et l’interface unifiée dans WAC rendent la migration bien plus accessible qu’avec des méthodes artisanales. Cela reste une extension en preview, donc à évaluer sérieusement en environnement de test avant toute utilisation en production, mais la base technique est solide.
Ce qui est certain, c’est qu’une alternative crédible existe désormais pour les organisations qui souhaitent diversifier ou repositionner leur stratégie d’hyperviseur. La migration ne doit plus être perçue comme un saut dans l’inconnu, mais comme un projet structuré, pilotable et documenté.
![Entra ID → Enterprise Applications — bouton Grant admin consent for [tenant] sur l'app du storage account](https://jlou.eu/wp-content/uploads/2026/05/image-347-1024x511.png)
