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

L’essentiel

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.

Pourquoi cette technologie existe

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.

Autorité des workloads en co-management s’appuie sur la chaîne MECM → Cloud Attach → Intune → Endpoint. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont 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. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Poste absent d’Intune, Workload ne bascule pas et Policies en conflit. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. MECM ouvre la séquence: Client, site, policies et collections. Cloud Attach prend ensuite le relais: Configuration du tenant, co-management et tenant attach. Le traitement se poursuit avec Intune, où Politiques cloud pour les workloads transférés. Enfin, Endpoint ferme la boucle: Arbitre selon workload, pilotage et policy reçue. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Poste absent d’Intune » conduit d’abord à vérifier MDMEnrollment.log et événements, car la cause possible est Enrôlement MDM incomplet. Pour « Workload ne bascule pas », la preuve utile devient CoManagementHandler.log. Les cas « Policies en conflit » et « Updates restent sur WSUS » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Autorité des workloads en co-management expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions 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 doivent être réunies en même temps. La validation porte ensuite sur poste réellement co-managed, collection pilote correcte, workload reçu localement et ancienne policy retirée. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

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, compatibilité et limites de support

Le fonctionnement décrit suppose 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. Ces conditions permettent de distinguer une limite de Autorité des workloads en co-management d’un scénario simplement non éligible.

• 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

Cycle de fonctionnement, étape par étape

Le cycle de Autorité des workloads en co-management traverse MECM → Cloud Attach → Intune → Endpoint. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Autorité des workloads en co-management, les étapes « Inventorier les autorités », « Qualifier le poste », « Basculer un workload pilote », « Généraliser par vagues » séparent l’intention, son transport, son traitement et le résultat final.

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.

Le champ de gestion affiché dans un inventaire ne remplace pas l’état détaillé des workloads. Deux postes indiqués comme co-managed peuvent recevoir des politiques différentes si l’un appartient à la collection pilote et l’autre au groupe de production.

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.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles CoManagementHandler.log, MDMEnrollment.log, ClientIDManagerStartup.log, DeviceManagement-Enterprise-Diagnostics-Provider/Admin. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Autorité des workloads en co-management, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

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

Observabilité : où lire l’état réel

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

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque poste réellement co-managed, collection pilote correcte, workload reçu localement et ancienne policy retirée. Ces contrôles relient la configuration du service au résultat réellement observé.

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

Limites, modes de panne et lecture des erreurs

Les écarts connus de Autorité des workloads en co-management incluent Poste absent d’Intune, Workload ne bascule pas, Policies en conflit, Updates restent sur WSUS. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Autorité des workloads en co-management commence sur le périmètre clients MECM co-managed et enrôlés Intune, workloads officiels et collections pilotes, configuration, conformité, applications, sécurité et Windows Update. Les limites et actions de réversibilité ci-dessous cadrent la progression.