~ 7 min readFR

Azure Virtual Desktop : du POC à la prod, la checklist de durcissement

Un POC AVD privé fonctionne — mais il manque la sécurité, l'observabilité, la scalabilité et la DR avant la prod. La roadmap priorisée (P1→P5) + la dette technique à solder : NTFS ACLs FSLogix, rotation de secrets, AVD Insights, custom image, Conditional Access, backup FSLogix.

azureavdazure-virtual-desktopterraformterragruntfslogixobservabilityfinopsconditional-access

TL;DR. Un POC AVD 100 % privé qui marche, ce n’est pas une prod. Entre les deux : durcir le storage FSLogix (ACLs NTFS, backup), automatiser la rotation des secrets, brancher l’observabilité (AVD Insights + LAW dédié), scaler les session hosts (custom image, sessionHostConfiguration), prévoir la DR (FSLogix GZRS / Cloud Cache) et activer les features enterprise (Conditional Access/MFA, Intune, App Attach). Voici la roadmap priorisée par ROI, plus la dette technique du POC à solder.

Publié le 22 juin 2026. Suite de l’article retex AVD en Landing Zone. Stack : Terraform · Terragrunt · azurerm ~> 4.0 · FSLogix / Azure Files Premium · Windows 11 multi-session.

Le POC est validé : AVD déployé en spoke d’une Landing Zone, zéro endpoint public, profils FSLogix sur Entra Kerberos, Autoscale en place. Mais un POC optimise pour « ça marche », pas pour « ça tient en prod ». Voici ce qu’on rajoute par-dessus, par ordre de priorité / ROI.

P1 — Hygiène & sécurité minimale

NTFS ACLs sur le share FSLogix

Le share profiles est accessible en SMB via Entra Kerberos + RBAC Storage File Data SMB Share Contributor. Mais au niveau NTFS, tout le monde voit les dossiers de tous les autres utilisateurs. Il faut appliquer les ACLs recommandées par Microsoft (depuis une session loggée sur un session host) :

icacls \\<storage>.file.core.windows.net\profiles `
  /inheritance:r `
  /grant "<domain>\<grp_avd_users>:(M)" `
  /grant "CREATOR OWNER:(OI)(CI)(IO)(M)" `
  /grant "BUILTIN\Administrators:(F)"

À automatiser via un Custom Script Extension la première fois, ou un Azure Run Command planifié.

Rotation automatique des secrets Key Vault

Le mot de passe admin local des session hosts et la clé du storage account FSLogix expirent à 90 jours. Aujourd’hui la rotation est manuelle. À automatiser :

  • Logic App déclenchée par Event Grid (event SecretNearExpiry), ou
  • Azure Function en timer trigger,
  • Action : az storage account keys renew + az keyvault secret set.

Le module qui gère les secrets a ignore_changes = [value] → la rotation out-of-band ne crée pas de drift Terraform.

Exemption de policy pour les opérations KV manuelles

Deny-PublicPaaS + Key Vault en public_network_access_enabled = false implique qu’on doit être sur le VPN corp pour lire/écrire un secret via le portail. Deux options : une policy exemption ciblée sur le RG du KV (avec justification + date d’expiration), ou maintenir un accès public restreint par firewall ACLs (IP allowlist) — au risque que la policy le refuse.

Activity log + diagnostic settings

Aucune route vers Log Analytics aujourd’hui. Pour chaque ressource critique (host pool, workspace, session host), activer les diagnostic settings → LAW.

P2 — Observabilité

AVD Insights (LAW dédié)

Microsoft recommande un Log Analytics Workspace dédié AVD. À créer :

  • law-avd (rétention 30 j en POC, 90 j en prod),
  • une DCR (Data Collection Rule) avec les perf counters + event logs requis par Insights,
  • l’association DCR ↔ session hosts,
  • les diagnostic settings host pool / workspace / app group → LAW,
  • le workbook AVD Insights.

Côté IaC, ça se traduit par de nouveaux déploiements Terragrunt : law-avd/, dcr-avd/, l’association dcra-avd/, et les diag-*-avd/. Coût indicatif : ingestion LAW ~2–3 €/Go ; pour un session host à faible usage, budget ~10 €/mois.

Action groups + alertes AMBA

Les events du scaling plan, les échecs d’agent des session hosts et les seuils de quota storage sont remontables via Azure Monitor Baseline Alerts. La Landing Zone fournit déjà une base — il reste à ajouter les alertes spécifiques AVD.

P3 — Scalabilité

Plusieurs session hosts

Passer de 1 à 3+ session hosts pour tester un load balancing BreadthFirst + un ramp-up Autoscale réaliste. Points d’attention :

  • Availability zones : le module répartit automatiquement sur les zones 1/2/3.
  • NSG : vérifier que les règles inbound/outbound passent à l’échelle.
  • FSLogix : 1 conteneur par utilisateur ; un share supporte ~3000 users concurrents avant d’envisager du sharding multi-shares.

Le nouveau pattern sessionHostConfiguration

Aujourd’hui on gère les session hosts via un compteur de VMs + des extensions. Microsoft a récemment GA le pattern sessionHostConfiguration (sous-ressource du host pool) qui automatise create/update/scale des VMs : plus de gestion individuelle des extensions, update d’image automatique, intégration avec l’Autoscale dynamique. À vérifier : la version d’azurerm qui le supporte.

On part aujourd’hui de l’image Marketplace win11-24h2-avd. Pour standardiser avec les apps métier pré-installées :

  1. Créer une VM template, installer les apps + la config.
  2. Sysprep + generalize.
  3. Capturer l’image dans une Shared Image Gallery.
  4. Azure Image Builder pour automatiser le build + le patching mensuel.
  5. Pointer le module session host sur l’image custom.

P4 — Déploiement prod

Subscription prod

Le placeholder de subscription ID pour l’AVD prod doit être remplacé par le vrai ID une fois la subscription provisionnée, puis :

export TG_ENV="prod"
cd landing-zone/corporate/avd
terragrunt run-all apply

Variables à double-vérifier entre prod et nprd :

  • quota FSLogix : dimensionner selon le nombre d’utilisateurs (~30 GiB/user typique).
  • nombre de session hosts : baseline + provision pour le pic.
  • taille VM : D4ds_v5 ou plus pour des users lourds (Office, Teams, IDE).
  • ramp_down_force_logoff_users : passer à true pour vraiment éteindre les VMs en fin de journée (en POC c’est false pour les tests).
  • locks sur toutes les RGs (pas seulement network + KV).

DR / région secondaire

Le control plane AVD est redondant automatiquement côté Microsoft (metadata multi-région). Côté données utilisateur (FSLogix) :

  • GZRS sur Azure Files (réplication cross-region), ou
  • FSLogix Cloud Cache (réplication entre deux storage accounts dans deux régions).

Les session hosts n’ont pas besoin de DR : ils sont stateless (tout l’état user vit dans FSLogix).

P5 — Features enterprise

MFA / Conditional Access

Enforcer le MFA sur la connexion AVD via une policy Conditional Access Entra ID ciblant l’application Azure Virtual Desktop (appId public Microsoft 9cdead84-a844-4324-93f2-b2e6bb768d07). Le provider AzureAD gère ça avec azuread_conditional_access_policy.

Enrollment Intune automatique

Les session hosts Entra-joined peuvent s’enrôler automatiquement dans Intune (policies, déploiement logiciel, compliance) — via le support mdmId sur l’extension AADLoginForWindows.

RDP Shortpath, session recording, App Attach

  • RDP Shortpath (UDP, moins de latence) : nécessite d’exposer l’UDP 3390 ou de passer par STUN/TURN public — peu compatible avec un design full-private simple. À reconsidérer face à un vrai besoin perf.
  • Session recording (audit/compliance) : Microsoft Purview (en preview) ou solutions tierces. Pas une priorité POC.
  • App Attach / MSIX : packager les apps métier en MSIX et les attacher dynamiquement au session host plutôt que les figer dans l’image → image plus légère + versioning des apps.

La dette technique du POC à solder

  • shared_access_key_enabled = true sur le storage FSLogix — activé pour que Terraform gère le share via data plane. À durcir en prod : désactiver la shared key, donner au SP Terragrunt le rôle adéquat pour gérer les shares via control plane, et passer le provider en storage_use_azuread = true.
  • Pas de backup FSLogix — aucun backup des conteneurs VHDX. Le ZRS protège contre une panne de zone, pas contre l’erreur humaine ou la suppression. Prévoir Azure Backup pour Azure Files (ou des snapshots planifiés).
  • Pas de scaling horizontal FSLogix — un seul storage account pour tous les profils. Au-delà de ~3000 users concurrents, prévoir du sharding multi-comptes (FSLogix CCDLocations / répartition par groupe AD).
  • Résolution DNS non-IaC — la NRPT côté poste et le wire de la zone privatelink-global.wvd.microsoft.com sont manuels. À industrialiser : une policy ALZ custom Deploy-Private-DNS-AVD-Global qui auto-wire le zone group quand un PE global est détecté, ou un ignore_changes conditionnel sur le module PE.

Aucune de ces évolutions n’est bloquante pour démontrer la valeur d’AVD. Mais entre un POC qui tourne et une prod régulée qui tient, c’est précisément cette liste qui fait la différence — et la trier par ROI évite de tout vouloir faire d’un coup.