Concevoir les stratégies Intune pour éviter conflits et empilement

Résumé

Je structure les politiques par fonction et responsabilité plutôt que par une succession de projets. Un paramètre critique doit avoir une seule source d’autorité pour une population donnée.

Settings Catalog est le choix général lorsque le paramètre y existe. Endpoint Security et les baselines restent pertinents pour leurs flux opérationnels, mais je documente les recouvrements et je n’applique pas les valeurs par défaut sans revue.

Les groupes expriment qui reçoit l’intention ; les filtres affinent l’applicabilité à partir de propriétés fiables. Les exclusions servent à une exception temporaire gouvernée, pas à masquer une conception devenue incompréhensible.

Je structure les politiques par fonction et responsabilité plutôt que par une succession de projets. Un paramètre critique doit avoir une seule source d’autorité pour une population donnée.

Contexte, objectif et périmètre

Intune facilite la création de profils, ce qui encourage l’empilement. Après plusieurs années, le même réglage peut apparaître dans une baseline, un profil sécurité, un Settings Catalog et une ancienne stratégie personnalisée.

Le portail signale certains conflits, mais il ne remplace pas une matrice de conception. Des réglages différents peuvent aussi produire un comportement concurrent sans partager exactement le même nom.

Je traite « Concevoir les stratégies Intune sans conflits » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

La configuration recommandée n’est pas une valeur universelle. Elle constitue un point de départ argumenté, à rapprocher des licences, des contraintes réseau, des responsabilités de support et de la maturité opérationnelle. Lorsque plusieurs méthodes existent, je privilégie celle qui réduit les autorités concurrentes et rend le résultat le plus facilement vérifiable.

Le passage en production suit une progression explicite : validation technique isolée, pilote métier, extension contrôlée puis généralisation. Chaque vague dispose de critères GO et NO-GO, d’une durée d’observation et d’un propriétaire capable d’arrêter ou de revenir en arrière sans attendre une décision improvisée.

• Objectif : définir une taxonomie et un nommage
• Objectif : réduire les autorités concurrentes
• Objectif : gouverner affectations, exceptions et migrations
• Périmètre : Windows géré par Intune
• Périmètre : Settings Catalog, Endpoint Security, baselines et OMA-URI sous exception
• Périmètre : groupes, filtres, exclusions et scope tags

Architecture et fonctionnement général

Je commence par une intention, par exemple protéger les secrets LSASS, puis je choisis le canal de configuration le plus adapté. Le nom du profil expose plateforme, domaine, cible, niveau et version sans intégrer une donnée sensible.

Un profil regroupe des réglages qui partagent propriétaire, population et rythme de changement. Un profil immense réduit le nombre d’objets mais augmente l’impact d’une modification et complique le rollback.

L’affectation est traitée comme du code : groupe source, exclusions, filtre, dépendances et justification sont revus ensemble. La preuve comprend le rapport par paramètre et l’état réel du CSP ou du registre.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• inventaire exporté des politiques existantes
• cartographie CSP/setting et propriétaire
• conventions de nommage
• groupes pilotes et filtres validés
• processus d’exception avec date d’expiration

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Choisir le bon type de profil

Settings Catalog offre une surface large et des métadonnées proches des CSP. Endpoint Security apporte une organisation adaptée aux équipes sécurité et aux rapports du domaine. Une baseline accélère le point de départ mais doit être examinée setting par setting.

Je n’utilise un OMA-URI personnalisé que lorsque le paramètre est officiellement documenté, absent des interfaces recommandées et validé sur les builds ciblées. Je documente LocURI, type, portée, valeur et rollback.

Lorsqu’une baseline change de version, je compare les valeurs plutôt que de mettre à niveau aveuglément. Un ancien profil peut devenir en lecture seule ; la migration est un changement à piloter.

Groupes, filtres et exceptions

Les groupes restent la population d’intention. Les filtres réduisent cette population en fonction de propriétés évaluées par Intune. Une propriété instable ou tardive pendant l’enrôlement peut produire une absence temporaire de policy.

Je limite les exclusions en cascade. Une exception possède un ticket, un propriétaire, un motif, un contrôle compensatoire et une date de revue.

Les scope tags organisent la visibilité administrative ; ils ne remplacent ni les affectations ni les permissions précises. Je teste la délégation avec un compte réel du rôle prévu.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• un propriétaire par setting
• noms et versions cohérents
• aucun conflit pilote
• preuve locale conforme
• exception datée
• rollback démontré

Journaux, diagnostic et constitution des preuves

Pour un conflit, je relève le paramètre exact, les profils qui le configurent, les affectations et l’état local. Le rapport par paramètre est plus utile que le seul état global du profil.

Côté poste, DeviceManagement-Enterprise-Diagnostics-Provider et PolicyManager permettent de relier l’application CSP à la policy. Une valeur de registre seule ne révèle pas toujours son propriétaire.

• rapport de configuration par paramètre
• affectations et filtres
• DeviceManagement-Enterprise-Diagnostics-Provider/Admin
• état PolicyManager/CSP
• RSOP pour les GPO restantes
• matrice de responsabilité

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : restaurer les affectations exportées
• Rollback : réappliquer explicitement la valeur précédente si le CSP l’exige
• Rollback : conserver l’ancien profil pendant la fenêtre de rollback
• Vigilance : ne pas confondre moins de profils et meilleure conception
• Vigilance : ne pas utiliser All users et All devices sans justification
• Vigilance : revalider les baselines lors des changements de version