Co-management MECM/Intune : comprendre l’autorité de chaque workload

Résumé

Le co-management permet à un client Configuration Manager également enrôlé dans Intune de répartir plusieurs workloads entre les deux services. La bascule n’est pas un interrupteur unique : chaque workload possède son propre état et peut utiliser une collection pilote.

Une console correctement configurée ne prouve pas la situation d’un endpoint. Je vérifie l’identité Entra, l’enrôlement MDM, les tâches EnterpriseMgmt, l’état du client MECM, la collection pilote et les politiques locales.

Pour Windows Update, je sépare workload, source de scan et politiques effectivement appliquées. Un poste peut être co-managed tout en continuant d’utiliser WSUS si les réglages clients et la source de scan le maintiennent.

Le co-management permet à un client Configuration Manager également enrôlé dans Intune de répartir plusieurs workloads entre les deux services. La bascule n’est pas un interrupteur unique : chaque workload possède son propre état et peut utiliser une collection pilote.

Contexte, objectif et périmètre

La migration progressive de MECM vers Intune évite une rupture, mais elle crée une période où deux agents et deux plans de contrôle coexistent. Sans matrice d’autorité, les équipes attribuent facilement une configuration au mauvais service.

Tenant attach et co-management sont liés mais distincts. Une action visible depuis le cloud ne signifie pas nécessairement que le workload correspondant est géré par Intune.

Je traite « Autorité des workloads en co-management » 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.

Pour expliquer la technologie, je sépare le plan de contrôle, le transport, les composants locaux et les données de résultat. Cette lecture évite d’attribuer au portail une décision prise par Windows, ou à un agent local une limitation qui appartient en réalité au service cloud, à la licence ou au modèle d’affectation.

Les détails internes observés dans les journaux ou le registre servent à établir une hypothèse de diagnostic. Ils ne deviennent pas pour autant une interface publique stable. Toute automatisation durable doit s’appuyer sur une API ou une configuration officiellement supportée, puis être revalidée quand la version du service ou du client change.

• Objectif : expliquer la distribution des workloads
• Objectif : prouver l’autorité sur un endpoint
• Objectif : préparer une bascule pilote réversible
• Périmètre : clients MECM co-managed et enrôlés Intune
• Périmètre : workloads officiels et collections pilotes
• Périmètre : configuration, conformité, applications, sécurité et Windows Update

Architecture et fonctionnement général

Configuration Manager configure le cloud attach et la position de chaque workload. Une valeur Pilot Intune ajoute la condition d’appartenance à une collection ; Intune signifie que la population ciblée doit recevoir la gestion cloud pour ce workload.

L’enrôlement automatique MDM crée les artefacts Intune, mais le client MECM reste actif. Les deux agents continuent leurs cycles et journaux. L’autorité fonctionnelle se lit donc workload par workload.

Les conflits sont évités en retirant les politiques concurrentes lors de la bascule. Déplacer le curseur sans nettoyer les paramètres WSUS, GPO ou profils existants laisse des valeurs capables de contredire l’intention.

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.

• version MECM supportée et hiérarchie saine
• tenant attach et co-management configurés
• identité Entra et enrôlement Intune du poste
• collections pilotes stables
• matrice des policies historiques et cloud

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.

Les preuves locales de co-management

Je commence par dsregcmd /status pour l’identité, puis je vérifie les branches d’enrôlement et les tâches EnterpriseMgmt. Côté MECM, CoManagementHandler.log, MDMEnrollment.log et les journaux du workload fournissent la chronologie.

Une tâche MDM présente ne prouve pas que toutes les politiques Intune sont appliquées. Je corrèle Enrollment ID, certificat, heure de synchronisation et état de la charge.

Les données du portail peuvent être en retard. La preuve finale est le réglage ou le comportement local, relié à la politique qui l’a produit.

Windows Update : trois questions différentes

Je sépare qui configure les paramètres Windows Update, quelle source le client scanne et quel service approuve le contenu. Ces réponses peuvent diverger pendant une migration.

La scan source policy remplace les raisonnements historiques autour de Dual Scan. Les GPO WSUS, client settings MECM et profils WUfB doivent être inspectés ensemble.

Le rollback restaure à la fois le workload et les paramètres de source. Sans cela, le curseur peut revenir dans MECM tandis que Windows continue de scanner Windows Update.

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.

dsregcmd /status
sc.exe query CcmExec
schtasks.exe /Query /TN \"Microsoft\Windows\EnterpriseMgmt\*\" /FO LIST

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é.

• poste réellement co-managed
• collection pilote correcte
• workload reçu localement
• ancienne policy retirée
• réglage final conforme
• rollback testé

Journaux, diagnostic et constitution des preuves

CoManagementHandler.log décrit le traitement général de co-management. MDMEnrollment.log aide pour l’inscription. WUAHandler.log, ScanAgent.log, UpdatesDeployment.log et WindowsUpdateClient deviennent pertinents pour Windows Update.

Je synchronise les horodatages entre CCM logs, événements Windows et journaux MDM. Une même machine peut avoir plusieurs Enrollment IDs historiques ; je sélectionne celui associé au certificat et aux tâches actives.

• CoManagementHandler.log
• MDMEnrollment.log
• ClientIDManagerStartup.log
• DeviceManagement-Enterprise-Diagnostics-Provider/Admin
• registre Enrollments et tâches EnterpriseMgmt
• journaux spécifiques au workload

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 : replacer le workload sur MECM
• Rollback : restaurer client settings et source de scan
• Rollback : retirer les profils Intune pilotes
• Vigilance : ne pas confondre tenant attach et co-management
• Vigilance : ne pas basculer plusieurs workloads sans isoler les effets
• Vigilance : documenter les GPO restantes