Intune Remediations : concevoir des détections et corrections sûres

Position recommandée

Le script de détection retourne 0 quand l’état est conforme et 1 quand la remédiation doit s’exécuter. Sa sortie standard est limitée et destinée au reporting ; les détails techniques restent dans un journal local protégé.

La remédiation est au minimum niveau 2 avec simulation, debug et gestion d’erreur. Elle vérifie l’état avant et après, ne modifie que la cible attendue et peut être rejouée sans dérive.

Je recommande un package par problème, une audience pilote, une cadence proportionnée et des seuils d’arrêt. Les scripts sont signés si l’option d’enforcement est activée et testés en contexte SYSTEM ou utilisateur correspondant.

Le script de détection retourne 0 quand l’état est conforme et 1 quand la remédiation doit s’exécuter. Sa sortie standard est limitée et destinée au reporting ; les détails techniques restent dans un journal local protégé.

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

La détection ne répare rien. Elle minimise le coût, gère l’absence de la ressource et produit une phrase utile sans secret. Une exception non gérée ne doit pas être confondue avec non-conformité.

La remédiation reçoit la même hypothèse et calcule un delta. SupportsShouldProcess ou -Simulation protège le pilote ; une exécution réelle nécessite le niveau convenu par le standard PowerShell.

Je commence par nommer le propriétaire de la décision, la population concernée et la preuve attendue. Cette étape paraît administrative, mais elle évite qu’un réglage technique soit utilisé pour compenser une responsabilité non définie entre identité, sécurité, support et gestion du poste.

La console cloud représente une intention et un état remonté. Je la compare toujours au résultat local, à l’identité réellement utilisée et à l’heure du dernier traitement. Une valeur verte, une affectation ou un HTTP 200 ne suffit pas à prouver tout le parcours.

• Résultat recherché : comprendre l’architecture et ses limites
• Résultat recherché : mettre en œuvre un pilote observable
• Résultat recherché : construire une exploitation avec critères GO/NO-GO
• Dans le périmètre : Intune, Remediations, PowerShell
• Dans le périmètre : postes Windows et services Microsoft documentés
• Dans le périmètre : pilote représentatif avant généralisation

Critères de décision et options possibles

Pour « Remediations sûres et observables », je formule une position recommandée, mais pas une valeur prétendument universelle. Je la confronte aux licences, au niveau de risque, aux dépendances réseau, aux responsabilités de support, aux populations visées et à la maturité opérationnelle de l’organisation.

Lorsque plusieurs méthodes sont supportées, je compare leur simplicité, leur réversibilité, leur observabilité et le risque d’autorités concurrentes. La méthode retenue doit rendre explicites la propriété du paramètre, les exceptions acceptées et la façon de prouver le résultat.

Le déploiement suit des anneaux avec critères GO et NO-GO, durée d’observation, seuils mesurables et responsable de décision. Une recommandation n’est validée qu’après un pilote représentatif et un rollback réellement exercé.

Je sépare aussi la valeur recommandée de la politique qui permet de la distribuer. Une même intention peut être portée par le Settings Catalog, Endpoint Security, une baseline, un CSP, une GPO ou un autre outil. Le bon choix dépend de l’autorité qui doit rester propriétaire, de la granularité de reporting et du risque de conflit. Je documente la méthode écartée lorsque sa présence future créerait une ambiguïté.

Les exceptions ne sont pas des oublis de ciblage. Elles disposent d’un motif, d’un responsable, d’une mesure compensatoire, d’une date d’expiration ou de revue et d’un moyen de les retrouver. Cette gouvernance évite qu’un pilote temporaire ou une exclusion de dépannage ne devienne silencieusement la configuration permanente du parc.

Architecture cible et répartition des responsabilités

La détection ne répare rien. Elle minimise le coût, gère l’absence de la ressource et produit une phrase utile sans secret. Une exception non gérée ne doit pas être confondue avec non-conformité.

La remédiation reçoit la même hypothèse et calcule un delta. SupportsShouldProcess ou -Simulation protège le pilote ; une exécution réelle nécessite le niveau convenu par le standard PowerShell.

Le contexte SYSTEM voit HKLM, les certificats machine et tous les profils différemment d’un utilisateur. Je choisis Run this script using logged-on credentials selon la ressource, pas par habitude.

Prérequis, gouvernance et préparation

Avant de créer la configuration, je définis le propriétaire fonctionnel, le propriétaire technique, la population pilote, les exclusions, la durée d’observation et la personne habilitée à déclencher le rollback.

Je capture aussi l’état initial : licences, versions, affectations, autorités, dépendances et métriques. Cette baseline rend la recommandation mesurable et évite de confondre amélioration réelle et variation naturelle du parc.

• licence Remediations
• IME sain
• niveau script choisi
• tests Pester selon criticité
• contexte et architecture définis
• journal/retention conformes
• rollback testé

Fonctionnement détaillé et frontières de responsabilité

La détection ne répare rien. Elle minimise le coût, gère l’absence de la ressource et produit une phrase utile sans secret. Une exception non gérée ne doit pas être confondue avec non-conformité.

La remédiation reçoit la même hypothèse et calcule un delta. SupportsShouldProcess ou -Simulation protège le pilote ; une exécution réelle nécessite le niveau convenu par le standard PowerShell.

Le contexte SYSTEM voit HKLM, les certificats machine et tous les profils différemment d’un utilisateur. Je choisis Run this script using logged-on credentials selon la ressource, pas par habitude.

• licence Remediations
• IME sain
• niveau script choisi
• tests Pester selon criticité

Mise en œuvre, exploitation et cas limites

L’option 64-bit PowerShell évite la redirection registre et filesystem sur OS 64 bits. La signature exige une chaîne de confiance distribuée avant le package.

HealthScripts.log sous les logs IME permet de corréler détection, remédiation et sortie. Un log métier séparé conserve correlationId, état avant/après et code sans PII.

La fréquence tient compte du risque et du coût. Une correction toutes les heures qui revient constamment révèle une autorité concurrente ; je corrige la cause plutôt que d’entretenir une lutte de policies.

• Valider SYSTEM/utilisateur et 64 bits
• Contrôler HealthScripts.log
• Piloter puis surveiller la récidive

Méthode de validation à l’échelle du parc

Pour remediations sûres et observables, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Je mesure la couverture, le taux de succès, le délai de convergence, le nombre d’exceptions, les incidents et le temps de retour à l’état connu. Les seuils sont définis avant le pilote afin de ne pas les adapter après coup pour justifier une généralisation.

Les cas négatifs font partie de la recette : appareil hors ligne, identité non éligible, permission absente, version non supportée, conflit volontaire et rollback. Le système doit échouer de manière visible et sûre, sans exposer de secret ni créer une dérive silencieuse.

La généralisation suit des anneaux dont la composition reste stable pendant l’observation. Chaque vague dispose d’un propriétaire, d’une fenêtre, d’une consigne support et d’un point d’arrêt. Je n’ouvre la vague suivante qu’après la clôture des écarts de la précédente.

Configuration recommandée et déploiement par étapes

La procédure applique la méthode recommandée sur un périmètre pilote. Chaque étape précise où agir, quoi configurer, le résultat attendu, la façon de le vérifier, l’impact et la méthode de retour arrière.

Je ne poursuis pas si le résultat attendu manque. Une extension réalisée sur un état partiellement compris rendrait les écarts plus coûteux à isoler et à corriger.

Paramètres, commandes et automatisation

Les commandes présentées servent à vérifier ou illustrer la configuration. Les diagnostics sont des exemples non testés de niveau 1. Toute remédiation est au minimum de niveau 2 avec simulation lorsque l’action s’y prête, puis doit être adaptée et testée avant usage réel.

Je documente le contexte utilisateur ou SYSTEM, les permissions, les valeurs attendues et les effets de bord. Un extrait ne doit jamais introduire un paramètre implicite ou masquer une modification d’état.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
 $path='HKLM:\SOFTWARE\Fabrikam\Agent'
 $version=(Get-ItemProperty -LiteralPath $path -Name Version -ErrorAction Stop).Version
 if([version]$version -ge [version]'7.5.0'){ Write-Output 'Compliant: version minimale présente'; exit 0 }
 Write-Output 'NonCompliant: version inférieure au minimum'; exit 1
}
catch { Write-Output "DetectionError: $($_.Exception.GetType().Name)"; exit 1 }

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

La validation combine un contrôle technique local, la donnée de service et un indicateur d’usage ou d’exploitation adapté. Un état vert dans le portail ne prouve pas à lui seul que le besoin initial est satisfait.

Le passage à la vague suivante exige des seuils atteints, aucune régression critique, des exceptions documentées et un rollback disponible. Toute divergence inexpliquée maintient la décision en NO-GO.

• Définir état conforme et non conforme.
• Tester détection sans mutation.
• Tester remédiation en simulation.
• Tester idempotence et rollback.
• Valider SYSTEM/utilisateur et 64 bits
• Contrôler HealthScripts.log
• Piloter puis surveiller la récidive

Exploitation, journaux et contrôle continu

Le diagnostic de « Remediations sûres et observables » relie l’heure de la demande, l’identité, l’objet cloud, le poste et le résultat final. Je conserve les identifiants de corrélation utiles, mais je masque UPN, DeviceId, TenantId, noms internes, secrets, certificats privés et contenus métiers avant tout partage.

Je différencie absence de configuration, non-applicabilité, attente, erreur transitoire, refus d’autorisation et échec du composant local. Ces états n’appellent pas la même correction. Répéter une synchronisation ne transforme pas une politique non applicable en politique valide.

La collecte initiale reste en lecture seule. Une remédiation réelle doit être écrite au minimum au niveau 2, proposer une simulation, borner sa cible et restaurer l’état précédent. Pour une opération tenant-wide, privilégiée ou critique, les niveaux 3 ou 4 et une approbation formelle sont nécessaires.

• Définir état conforme et non conforme.
• Tester détection sans mutation.
• Tester remédiation en simulation.
• Tester idempotence et rollback.
• Valider SYSTEM/utilisateur et 64 bits
• Contrôler HealthScripts.log
• Piloter puis surveiller la récidive

Exceptions, erreurs connues et traitement

Une recommandation exploitable doit prévoir les exceptions et les échecs. Je relie chaque symptôme à une cause à confirmer et à une preuve ; la correction n’est appliquée que lorsque cette preuve est obtenue.

Les exceptions durables ont un propriétaire, une justification, une date de révision et une mesure compensatoire. Elles ne sont pas dissimulées dans un groupe d’exclusion sans gouvernance.

Rollback, gestion du changement et points de vigilance

Le rollback est préparé avant le pilote et restaure explicitement la valeur, l’affectation ou l’autorité précédente. Je vérifie ensuite la convergence locale et la remontée du nouvel état au lieu de m’arrêter à la suppression de la configuration.

La recommandation doit être réévaluée lors d’une évolution de licence, de version, de support ou de responsabilité. Une validation locale ne constitue jamais une qualification de production.

• Rollback : désaffecter le package
• Rollback : exécuter la fonction de restauration testée
• Rollback : restaurer valeur/fichier depuis snapshot minimal
• Point de vigilance : remédiation réelle minimum niveau 2
• Point de vigilance : aucun secret dans stdout
• Point de vigilance : pas de boucle de correction contre une policy
• Point de vigilance : signature et architecture doivent correspondre