Intune : choisir entre assignment filters et groupes dynamiques Entra

Position recommandée

Un groupe définit la population principale. Le filtre Intune est évalué lors de l’enrôlement, du check-in ou de l’évaluation d’une policy pour inclure ou exclure un appareil selon des propriétés supportées.

Les groupes dynamiques restent adaptés aux usages multi-services, à Autopilot lorsque le profil exige une appartenance avant démarrage, aux licences et à Conditional Access. Les filtres ne sont visibles ni consommables par ces services.

Je recommande All devices ou un groupe stable comme portée, puis un filtre pour le modèle, le constructeur, l’ownership, la catégorie ou enrollmentProfileName. Je n’associe pas une inclusion utilisateur à une exclusion device non supportée.

Un groupe définit la population principale. Le filtre Intune est évalué lors de l’enrôlement, du check-in ou de l’évaluation d’une policy pour inclure ou exclure un appareil selon des propriétés supportées.

Besoin, cas d’usage et périmètre de la recommandation

Le moteur de groupe Entra calcule une appartenance persistante utilisable par plusieurs services. Le filtre Intune calcule l’applicabilité dans le contexte d’une affectation et ne crée pas une appartenance réutilisable.

Pour les propriétés simples d’un appareil utilisé uniquement dans Intune, Microsoft recommande d’évaluer le remplacement du groupe dynamique par un filtre. Cela retire une étape de traitement de membership et réduit les surprises de latence.

Un filtre peut fonctionner en include ou exclude sur une affectation compatible. Je vérifie la plateforme, le type de policy et les propriétés prises en charge, car toutes les charges Intune n’offrent pas les mêmes possibilités.

Critères de décision et options possibles

Pour Filtres Intune ou groupes dynamiques, je commence par trois résultats concrets: Identifier l’intention et les consommateurs, Choisir groupe de base et filtre et Valider syntaxe et preview. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Group → Assignment → Filter → Result. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Identifier l’intention et les consommateurs, Choisir groupe de base et filtre et Valider syntaxe et preview. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Identifier l’intention et les consommateurs, Choisir groupe de base et filtre et Valider syntaxe et preview. Les responsabilités se répartissent ainsi: Group: Définit la population de base et les usages partagés. Assignment: Associe app ou policy à la population. Filter: Évalue les propriétés du device au check-in. Result: Applicable ou exclu avec reporting. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Policy absente à l’OOBE », « Device exclu à tort », « Effet variable selon utilisateur » et « Groupe supprimé, CA cassé » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: ne pas mélanger user include et device exclude, vérifier les valeurs exactes, Autopilot exige un groupe et documenter les groupes partagés. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

Le moteur de groupe Entra calcule une appartenance persistante utilisable par plusieurs services. Le filtre Intune calcule l’applicabilité dans le contexte d’une affectation et ne crée pas une appartenance réutilisable.

Pour les propriétés simples d’un appareil utilisé uniquement dans Intune, Microsoft recommande d’évaluer le remplacement du groupe dynamique par un filtre. Cela retire une étape de traitement de membership et réduit les surprises de latence.

Un filtre peut fonctionner en include ou exclude sur une affectation compatible. Je vérifie la plateforme, le type de policy et les propriétés prises en charge, car toutes les charges Intune n’offrent pas les mêmes possibilités.

Prérequis, gouvernance et préparation

La préparation de Filtres Intune ou groupes dynamiques couvre inventaire des groupes et consommateurs, propriétés device fiables, matrice user/device, policies compatibles avec filtres, groupe pilote stable. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Identifier l’intention et les consommateurs. Choisir groupe de base et filtre. Valider syntaxe et preview. Affecter au pilote sans doublon contradictoire. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• inventaire des groupes et consommateurs
• propriétés device fiables
• matrice user/device
• policies compatibles avec filtres
• groupe pilote stable
• reporting par affectation
• rollback vers ancien ciblage

Fonctionnement détaillé de Filtres Intune ou groupes dynamiques

Le moteur de groupe Entra calcule une appartenance persistante utilisable par plusieurs services. Le filtre Intune calcule l’applicabilité dans le contexte d’une affectation et ne crée pas une appartenance réutilisable.

Pour les propriétés simples d’un appareil utilisé uniquement dans Intune, Microsoft recommande d’évaluer le remplacement du groupe dynamique par un filtre. Cela retire une étape de traitement de membership et réduit les surprises de latence.

Un filtre peut fonctionner en include ou exclude sur une affectation compatible. Je vérifie la plateforme, le type de policy et les propriétés prises en charge, car toutes les charges Intune n’offrent pas les mêmes possibilités.

• inventaire des groupes et consommateurs
• propriétés device fiables
• matrice user/device
• policies compatibles avec filtres

Traitement, exploitation et cas limites de Filtres Intune ou groupes dynamiques

Les noms et valeurs diffèrent parfois des règles de groupes dynamiques: deviceOwnership peut devenir Corporate, le constructeur peut être normalisé et operatingSystemSKU ne se lit pas comme deviceOSType. Je valide la syntaxe dans l’éditeur du tenant.

Autopilot reste un cas particulier: le profil doit être attribué avant l’enrôlement. Les groupes restent nécessaires pour les profils Autopilot, même si enrollmentProfileName peut ensuite servir de filtre pour des policies ou applications compatibles.

Les groupes utilisateur conviennent aux intentions attachées à la personne; les groupes device aux réglages qui doivent exister avant connexion. Mélanger une inclusion user et une exclusion device peut produire un comportement non pris en charge ou imprévisible.

• Comparer résultats groupe/filtre
• Tester OOBE et premier check-in
• Retirer l’ancien mécanisme après preuve

Lire les états propres à Filtres Intune ou groupes dynamiques

Un groupe dynamique partagé avec Conditional Access, licensing, SharePoint ou une automatisation ne doit pas être supprimé au seul motif qu’Intune pourrait utiliser un filtre. Je cartographie d’abord tous ses consommateurs.

Le reporting d’affectation indique si le filtre a évalué l’objet comme inclus, exclu ou non applicable. Je capture cette preuve avant de conclure à un problème de synchronisation du client.

La migration se fait par duplication contrôlée: nouvelle affectation filtrée sur un pilote, comparaison avec le groupe historique, mesure des écarts, puis retrait du groupe uniquement lorsque tous les consommateurs sont connus.

• Policy absente à l’OOBE — Profil et timing du groupe
• Device exclu à tort — Résultat du filtre
• Effet variable selon utilisateur — Support matrix
• Groupe supprimé, CA cassé — Audit des usages

Pilote et suivi opérationnel de Filtres Intune ou groupes dynamiques

Le pilote couvre le périmètre Intune, Assignment filters, Dynamic groups, Microsoft Entra et contrôle Identifier l’intention et les consommateurs. Choisir groupe de base et filtre. Valider syntaxe et preview. Les résultats sont segmentés selon les populations réellement concernées par Filtres Intune ou groupes dynamiques.

Les cas d’échec « Policy absente à l’OOBE », « Device exclu à tort », « Effet variable selon utilisateur » 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 pas mélanger user include et device exclude, vérifier les valeurs exactes, Autopilot exige un groupe, documenter les groupes partagés. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Filtres Intune ou groupes dynamiques se déploie par les étapes « Mesurer l’état de départ », « Configurer la population pilote », « Observer les indicateurs », « Décider la généralisation ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Identifier l’intention et les consommateurs. Choisir groupe de base et filtre. Valider syntaxe et preview. Affecter au pilote sans doublon contradictoire. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Group, Assignment, Filter, Result doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  $uri = 'https://graph.microsoft.com/beta/deviceManagement/assignmentFilters'
  $result = Invoke-MgGraphRequest -Method GET -Uri $uri
  $result.value | Select-Object id,displayName,platform,rule,assignmentFilterManagementType
} catch { Write-Error "Inventaire des filtres impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Identifier l’intention et les consommateurs, Choisir groupe de base et filtre, Valider syntaxe et preview et Affecter au pilote sans doublon contradictoire. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Identifier l’intention et les consommateurs.
• Choisir groupe de base et filtre.
• Valider syntaxe et preview.
• Affecter au pilote sans doublon contradictoire.
• Comparer résultats groupe/filtre
• Tester OOBE et premier check-in
• Retirer l’ancien mécanisme après preuve

Exploitation, journaux et contrôle continu

La chronologie de Filtres Intune ou groupes dynamiques relie Group, Assignment, Filter, Result. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Identifier l’intention et les consommateurs. Choisir groupe de base et filtre. Valider syntaxe et preview. Affecter au pilote sans doublon contradictoire. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Membership pas calculé », « Valeur de propriété différente », « Ciblage mixte user/device » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Identifier l’intention et les consommateurs.
• Choisir groupe de base et filtre.
• Valider syntaxe et preview.
• Affecter au pilote sans doublon contradictoire.
• Comparer résultats groupe/filtre
• Tester OOBE et premier check-in
• Retirer l’ancien mécanisme après preuve

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Filtres Intune ou groupes dynamiques apparaissent notamment sous la forme Policy absente à l’OOBE, Device exclu à tort, Effet variable selon utilisateur, Groupe supprimé, CA cassé. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Filtres Intune ou groupes dynamiques crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Filtres Intune ou groupes dynamiques restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.