Ministère de la Cybersécurité et du Numérique (MCN), Québec

SUP-03 — Diagnostic et résolution des incidents sur les postes Windows en cogestion SCCM/Intune

Méthode de diagnostic des postes Windows 10/11 cogérés : identité et enregistrement, état client SCCM, synchronisation Intune, attribution des politiques, charges de travail, cycles, journaux et nouvelle évaluation.

Période: Juillet 2023 – aujourd'hui
Mon rôle: Ingénieur systèmes Modern Workplace (consultant)
Organisation: Ministère de la Cybersécurité et du Numérique (MCN), Québec

SCCM / MECM
Microsoft Intune
Windows 10/11
Microsoft Entra ID
PowerShell
Cogestion

Sur cette page

Résumé destiné aux recruteurs
Contexte de cogestion
Objectifs de l’administration
Responsabilités personnelles documentées
Architecture A — Cogestion Microsoft
Architecture B — Flux des politiques
Architecture C — Cycles clients SCCM
Architecture D — Arbre de diagnostic
Journaux et diagnostics techniques
Procédures de résolution — cadre documentaire
Compétences démontrées
Résultats vérifiables et limites

Résumé destiné aux recruteurs

SUP-03 rend visible la méthode utilisée pour diagnostiquer les incidents sur des postes Windows 10/11 en cogestion SCCM/MECM et Microsoft Intune au MCN : problèmes de synchronisation, analyse des appareils cogérés, diagnostic des cycles client SCCM et vérification des politiques et états client. Le point de départ est toujours le même : déterminer quelle plateforme porte la charge de travail concernée, puis vérifier le chemin réel de la politique jusqu’à son état final sur le poste.

Étude de cas complémentaire et conceptuelle. SUP-03 complète les études consacrées au déploiement applicatif et ne remplace pas une vue de production. Les diagrammes illustrent les mécanismes Microsoft de manière générique ; ils ne révèlent aucun paramètre de cogestion, tenant, groupe, serveur, collection, seuil de conformité ou charge de travail effectivement configuré au MCN.

Contexte de cogestion

La cogestion permet à un poste Windows d’être administré simultanément par le client SCCM/MECM et par Microsoft Intune, avec une répartition des charges de travail entre les deux plans de gestion. Elle ne signifie pas que chaque réglage est appliqué deux fois : pour chaque incident, il faut identifier le mécanisme attendu — politique client SCCM ou stratégie MDM Intune — avant d’interpréter une absence de configuration, une non-conformité ou un échec applicatif.

Les symptômes visibles sont souvent ambigus : appareil absent d’une console, état non conforme, politique non appliquée, application non installée, cycle SCCM sans effet ou communication interrompue. La résolution nécessite une lecture ordonnée de l’identité, de l’enregistrement, des communications, des politiques et des journaux, plutôt qu’une succession de relances non ciblées.

Objectifs de l’administration

Confirmer que le poste est identifié, joint et enregistré dans le contexte attendu.
Vérifier la présence et la santé du client SCCM, ainsi que sa capacité à recevoir et évaluer les politiques.
Vérifier la synchronisation Intune, l’affectation de stratégie et le retour d’état MDM.
Distinguer les mécanismes SCCM des mécanismes Intune pour la charge de travail concernée.
Interpréter les écarts de conformité et d’application à partir de preuves techniques.
Conduire une correction autorisée, documenter le résultat et provoquer une nouvelle évaluation lorsque nécessaire.

Responsabilités personnelles documentées

Diagnostic des problèmes de synchronisation.
Analyse des appareils en cogestion.
Diagnostic des cycles clients SCCM.
Vérification des politiques et des états clients.

Ces activités s’inscrivent dans les interventions Modern Workplace N2/N3. Cette fiche ne prétend pas décrire une topologie ou des réglages MCN spécifiques ; elle explicite la logique de diagnostic applicable à un environnement de cogestion.

Architecture A — Cogestion Microsoft

Diagramme Mermaid d'une cogestion conceptuelle : site et Management Point SCCM/MECM, Microsoft Entra ID, Microsoft Intune, poste Windows cogéré et répartition générique des charges de travail. Les politiques et états circulent entre le poste et chaque plan de gestion. — **Plans de gestion complémentaires.** SCCM/MECM et Intune communiquent chacun avec le poste cogéré ; la charge de travail concernée détermine le mécanisme à diagnostiquer. Ouvrir le schéma Mermaid exporté en SVG

Prérequis, identité et enregistrement

Le diagnostic commence par la preuve qu’un appareil existe dans l’état attendu, sans en déduire une configuration particulière :

Contrôle	Ce qu’il permet d’établir	Interprétation prudente
Identité Microsoft Entra ID	État de jonction et identité de l’appareil	Une identité présente ne prouve pas à elle seule la réception d’une stratégie
Enregistrement MDM	Présence d’une relation de gestion Intune	L’enregistrement doit être recoupé avec la synchronisation et l’affectation
Client SCCM	Service, attribution et santé du client	Un client installé ne garantit pas une politique à jour
Connectivité	Accès aux services requis par le mécanisme visé	Un défaut réseau peut expliquer un état ancien, pas automatiquement toutes les erreurs

Les commandes et consoles de vérification sont utilisées selon les accès autorisés. Aucun identifiant, URL de service, nom de tenant ou paramètre interne n’est intégré dans cette documentation.

Architecture B — Flux des politiques

Diagramme Mermaid des flux de politiques : une attribution ciblée alimente soit la politique client SCCM, soit une affectation Intune avec synchronisation MDM. Le poste cogéré évalue et applique selon la charge de travail, puis retourne son état vers SCCM ou Intune. — **Deux flux à ne pas confondre.** Le schéma distingue l'attribution et le retour d'état SCCM de l'affectation, de la synchronisation MDM et du retour d'état Intune. Ouvrir le schéma Mermaid exporté en SVG

Méthodologie de diagnostic des politiques

Qualifier le symptôme : appareil absent, état non conforme, stratégie non appliquée ou application non installée.
Déterminer la charge de travail attendue sans présumer de son basculement réel dans le tenant ou le site.
Contrôler le ciblage : collection/politique côté SCCM ou groupe/affectation côté Intune, selon la plateforme.
Vérifier la réception : politique client SCCM ou synchronisation MDM Intune.
Vérifier l’évaluation locale et l’application : client, contexte, prérequis et éventuelle règle de détection pour une application.
Lire les états et journaux dans l’ordre chronologique, puis isoler la cause documentée.
Appliquer une correction autorisée et vérifier le résultat après nouvelle évaluation ou synchronisation.

Architecture C — Cycles clients SCCM

Diagramme Mermaid des quatre cycles SCCM : Machine Policy Retrieval and Evaluation, Application Deployment Evaluation, Software Updates Scan et Hardware Inventory, chacun associé à son contrôle de diagnostic. — **Cycles SCCM et preuves associées.** Un cycle sert à déclencher ou accélérer une évaluation ciblée ; il ne remplace pas la validation du ciblage, de la connectivité ou de la configuration. Ouvrir le schéma Mermaid exporté en SVG

Cycle SCCM	Rôle	Contrôles associés
Machine Policy Retrieval & Evaluation	Demande puis évalue la politique client disponible	Réception de politique, ciblage, état du client et journalisation de la politique
Application Deployment Evaluation	Réévalue les déploiements applicatifs connus	Présence du déploiement, règles de détection, état d’installation et journaux applicatifs
Software Updates Scan	Met à jour l’évaluation des mises à jour applicables	Source attendue, résultats de scan, prérequis et état de mise à jour
Hardware Inventory	Collecte puis transmet l’inventaire défini côté client	Déclenchement, données collectées et retour d’état inventaire

Un cycle est exécuté uniquement dans le cadre d’une procédure et des droits appropriés. Il n’est pas présenté ici comme une solution automatique : l’analyse de la cause précède la relance ciblée.

Architecture D — Arbre de diagnostic

Diagramme Mermaid d'un arbre de diagnostic : incident de poste absent, non conforme ou stratégie non appliquée ; vérification de l'identité et de l'enregistrement, de l'état SCCM et de la connectivité, de la synchronisation Intune et de l'affectation, puis branche SCCM ou Intune, correction validée et nouvelle évaluation. — **Arbre de décision conceptuel.** L'incident est séparé par mécanisme attendu avant d'inspecter les cycles/journaux SCCM ou les diagnostics MDM et de conformité Intune. Ouvrir le schéma Mermaid exporté en SVG

Journaux et diagnostics techniques

Domaine	Éléments à examiner	Finalité
Politique et localisation SCCM	`PolicyAgent.log`, `LocationServices.log`, `ClientLocation.log`	Confirmer la récupération/évaluation de politique et la capacité du client à localiser les services attendus
Application SCCM	`AppIntentEval.log`, `AppDiscovery.log`, `AppEnforce.log`	Distinguer intention, détection et exécution d’application
Contenu SCCM	`CAS.log`, `ContentTransferManager.log`	Vérifier localisation, préparation et transfert de contenu lorsque l’incident est applicatif
MDM Windows / Intune	État de synchronisation, affectations, rapport de stratégie, journaux MDM Windows et Intune Management Extension selon le scénario	Relier l’appareil, la stratégie, l’exécution et le retour d’état sans réduire l’analyse à une console
Conformité	État et critères visibles autorisés, dépendances de politique	Établir si l’écart concerne l’évaluation, le retour d’état ou la configuration elle-même

Les noms de journaux sont des repères génériques de diagnostic SCCM. Leur présence et leur interprétation dépendent de la version client, du type de déploiement et du scénario. Aucun extrait provenant d’un poste MCN n’est publié.

Procédures de résolution — cadre documentaire

Symptôme	Séquence de contrôle	Résolution documentée possible
Appareil absent ou non conforme	Identité, jonction, enregistrement, synchronisation, affectation, retour d’état	Corriger la cause identifiée selon la procédure autorisée, puis synchroniser/réévaluer
Échec de synchronisation Intune	État MDM, connectivité, date du dernier échange, affectation et journaux pertinents	Restaurer le prérequis ou l’affectation validée ; contrôler le nouvel état sans supposer une réinscription automatique
Politique non appliquée	Identifier la charge de travail, contrôler ciblage, réception et évaluation	Corriger le ciblage ou le prérequis documenté, puis provoquer la réévaluation appropriée
Application non installée	Distinguer flux SCCM/Intune, vérifier intention, contenu, commande et détection	Suivre le journal correspondant et appliquer le correctif de package, contenu ou détection validé
Client SCCM défaillant / communication	Santé du client, services, localisation, politique et connectivité	Escalader ou corriger dans le périmètre autorisé, puis vérifier une politique et un état récents

Compétences démontrées

Domaine	Démonstration
Cogestion Microsoft	Lecture séparée des plans SCCM/MECM et Intune, et compréhension de la répartition des charges de travail
SCCM / MECM	Diagnostic de cycles client, politiques, états, localisation, inventaire et journaux pertinents
Microsoft Intune	Synchronisation MDM, affectations Entra ID, stratégies, conformité et retours d’état
Windows 10/11	Identité, jonction, enregistrement, client de gestion et diagnostics locaux
PowerShell	Vérifications et collecte de diagnostic dans les procédures autorisées
Support N2/N3	Qualification, preuve technique, correction contrôlée, nouvelle évaluation et documentation

Résultats vérifiables et limites

Les réalisations documentées portent sur le diagnostic de synchronisation, l’analyse des appareils cogérés, les cycles SCCM et la vérification des politiques/états clients.
Les quatre diagrammes sont des sources Mermaid exportées en SVG, conservées dans contenu/projets/sup03/.
Aucun chiffre, paramètre de charge de travail, serveur, tenant, groupe ou scénario de production MCN n’est inventé.
Les délais, taux de conformité et volumes ne sont pas publiés ; ils relèvent des données opérationnelles de l’organisation.