Azure Virtual Desktop multi-session : comprendre la gestion Intune des session hosts

L’essentiel

Le support Intune vise les session hosts Windows Enterprise multi-session placés dans un host pool Azure Virtual Desktop ARM et joints au même tenant Microsoft Entra.

Un host Microsoft Entra joined peut être inscrit dans Intune lors de sa création. Un host hybrid joined utilise le parcours d’enrollment par informations d’identification appareil ou la co-gestion selon l’architecture.

Les paramètres en portée device s’appliquent au host. Les paramètres en portée user dépendent de leur prise en charge multi-session et doivent cibler les utilisateurs ; une combinaison non supportée peut apparaître en erreur ou non applicable.

Le support Intune vise les session hosts Windows Enterprise multi-session placés dans un host pool Azure Virtual Desktop ARM et joints au même tenant Microsoft Entra.

Pourquoi cette technologie existe

Le host pool AVD doit utiliser le modèle Azure Resource Manager et une image Windows Enterprise multi-session prise en charge. L’agent AVD doit atteindre la version minimale documentée pour le scénario Intune.

Avec Microsoft Entra join, l’option Enroll the VM with Intune inscrit le host pendant le déploiement si les licences et le scope MDM sont corrects. L’objet apparaît ensuite comme un appareil Windows multi-session.

Avec hybrid join, l’enrollment automatique peut utiliser les informations d’identification appareil par GPO ou être piloté par la co-gestion. Je n’emploie pas un token d’enrollment capturé dans une image clonée.

Intune et Windows Enterprise multi-session s’appuie sur la chaîne Host pool → Enrollment → Policies → Profiles. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont host pool AVD ARM, Windows Enterprise multi-session supporté, tenant Entra commun, agent AVD à jour. Elles font partie du fonctionnement de la technologie : leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Host absent d’Intune ; 0x8007064c ; Policy non applicable. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Host pool ouvre la séquence : AVD répartit les sessions sur les hosts. Enrollment prend ensuite le relais : Chaque host devient un appareil Intune. Le traitement se poursuit avec Policies, où Device et user sont évalués séparément. Enfin, Profiles ferme la boucle : FSLogix transporte le profil utilisateur. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Host absent d’Intune » conduit d’abord à vérifier Scope MDM et déploiement, car la cause possible est Enrollment non déclenché. Pour « 0x8007064c », la preuve utile devient Image et registre enrollment. Les cas « Policy non applicable » et « App visible pour certains users » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage : elle fait partie du modèle de fonctionnement et explique la manière dont Intune et Windows Enterprise multi-session expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions host pool AVD ARM, Windows Enterprise multi-session supporté, tenant Entra commun, agent AVD à jour doivent être réunies en même temps. La validation porte ensuite sur Valider édition et agent AVD. ; Choisir le parcours d’enrollment. ; Construire une image non inscrite. ; Inscrire un host pilote.. Ce croisement est important : un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Le host pool AVD doit utiliser le modèle Azure Resource Manager et une image Windows Enterprise multi-session prise en charge. L’agent AVD doit atteindre la version minimale documentée pour le scénario Intune.

Avec Microsoft Entra join, l’option Enroll the VM with Intune inscrit le host pendant le déploiement si les licences et le scope MDM sont corrects. L’objet apparaît ensuite comme un appareil Windows multi-session.

Avec hybrid join, l’enrollment automatique peut utiliser les informations d’identification appareil par GPO ou être piloté par la co-gestion. Je n’emploie pas un token d’enrollment capturé dans une image clonée.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose host pool AVD ARM, Windows Enterprise multi-session supporté, tenant Entra commun, agent AVD à jour, licences Intune pour les utilisateurs. Ces conditions permettent de distinguer une limite de Intune et Windows Enterprise multi-session d’un scénario simplement non éligible.

• host pool AVD ARM
• Windows Enterprise multi-session supporté
• tenant Entra commun
• agent AVD à jour
• licences Intune pour les utilisateurs
• image non inscrite avant capture
• architecture FSLogix et stockage validée

Cycle de fonctionnement, étape par étape

Le cycle de Intune et Windows Enterprise multi-session traverse Host pool → Enrollment → Policies → Profiles. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Intune et Windows Enterprise multi-session, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Intune et Windows Enterprise multi-session

Le host pool AVD doit utiliser le modèle Azure Resource Manager et une image Windows Enterprise multi-session prise en charge. L’agent AVD doit atteindre la version minimale documentée pour le scénario Intune.

Avec Microsoft Entra join, l’option Enroll the VM with Intune inscrit le host pendant le déploiement si les licences et le scope MDM sont corrects. L’objet apparaît ensuite comme un appareil Windows multi-session.

Avec hybrid join, l’enrollment automatique peut utiliser les informations d’identification appareil par GPO ou être piloté par la co-gestion. Je n’emploie pas un token d’enrollment capturé dans une image clonée.

• host pool AVD ARM
• Windows Enterprise multi-session supporté
• tenant Entra commun
• agent AVD à jour

Traitement, exploitation et cas limites de Intune et Windows Enterprise multi-session

L’image de référence ne doit pas être déjà inscrite dans Intune. Le clonage d’identifiants d’enrollment crée des objets incohérents et peut produire l’erreur 0x8007064c sur les nouveaux hosts.

Les stratégies device ciblent les session hosts et s’exécutent dans le contexte système. Les applications nécessaires à tous les utilisateurs suivent généralement ce modèle, avec détection et comportement compatibles multi-session.

Les stratégies user ciblent les utilisateurs qui ouvrent une session. Microsoft documente les catégories prises en charge ; un paramètre non supporté dans Windows Enterprise multi-session ne doit pas être forcé par habitude.

• Appliquer une baseline device.
• Tester profils user et FSLogix.
• Tester plusieurs sessions simultanées.

Lire les états propres à Intune et Windows Enterprise multi-session

Les conflits deviennent plus visibles sur un host partagé : plusieurs populations peuvent apporter des paramètres utilisateur différents au même système. Je limite les chevauchements et je distingue clairement baseline host et personnalisation utilisateur.

FSLogix monte le conteneur de profil à la connexion. Intune gère la configuration du host, tandis que FSLogix gère la disponibilité du profil ; une erreur de montage ne signifie pas que l’enrollment Intune a échoué.

La validation combine état du host pool, objet Intune, conformité device, stratégies user, installation d’applications, ouverture de plusieurs sessions et montage FSLogix. Chaque couche possède son propre propriétaire et ses propres journaux.

• Host absent d’Intune — Scope MDM et déploiement
• 0x8007064c — Image et registre enrollment
• Policy non applicable — Rapport par paramètre
• App visible pour certains users — Install et session

Pilote et suivi opérationnel de Intune et Windows Enterprise multi-session

Le pilote couvre le périmètre Azure Virtual Desktop, AVD, Intune, Multi-session et contrôle Valider édition et agent AVD. ; Choisir le parcours d’enrollment. ; Construire une image non inscrite.. Les résultats sont segmentés selon les populations réellement concernées par Intune et Windows Enterprise multi-session.

Les cas d’échec « Host absent d’Intune », « 0x8007064c », « Policy non applicable » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne jamais capturer une image déjà inscrite, ne pas appliquer toutes les policies de postes physiques, séparer device, user et FSLogix, tester plusieurs sessions sur un même host. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Valider édition et agent AVD., Choisir le parcours d’enrollment., Construire une image non inscrite., Inscrire un host pilote.. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Intune et Windows Enterprise multi-session, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

Observabilité : où lire l’état réel

La chronologie de Intune et Windows Enterprise multi-session relie Host pool, Enrollment, Policies, Profiles. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Valider édition et agent AVD. ; Choisir le parcours d’enrollment. ; Construire une image non inscrite. ; Inscrire un host pilote.. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Enrollment non déclenché », « Identifiant cloné dans l’image », « Portée non supportée » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Valider édition et agent AVD.
• Choisir le parcours d’enrollment.
• Construire une image non inscrite.
• Inscrire un host pilote.
• Appliquer une baseline device.
• Tester profils user et FSLogix.
• Tester plusieurs sessions simultanées.

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Valider édition et agent AVD. ; Choisir le parcours d’enrollment. ; Construire une image non inscrite. ; Inscrire un host pilote.. Ces contrôles relient la configuration du service au résultat réellement observé.

• Valider édition et agent AVD.
• Choisir le parcours d’enrollment.
• Construire une image non inscrite.
• Inscrire un host pilote.
• Appliquer une baseline device.
• Tester profils user et FSLogix.
• Tester plusieurs sessions simultanées.

Limites, modes de panne et lecture des erreurs

Les écarts connus de Intune et Windows Enterprise multi-session incluent Host absent d’Intune, 0x8007064c, Policy non applicable, App visible pour certains users. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Intune et Windows Enterprise multi-session commence sur le périmètre Azure Virtual Desktop, AVD, Intune, Multi-session, Modern Management — Host pool, Enrollment, Policies, Profiles, host pool AVD ARM, Windows Enterprise multi-session supporté, tenant Entra commun. Les limites et actions de réversibilité ci-dessous cadrent la progression.