Configuration Manager Tenant Attach : architecture, données et actions depuis Intune

L’essentiel

Tenant Attach synchronise vers Intune les appareils et collections sélectionnés depuis la hiérarchie Configuration Manager. Le portail peut ensuite afficher détails client, timeline, Resource Explorer et certaines actions en temps réel.

La solution mélange données synchronisées et requêtes à la demande vers le site. Le service cloud ne devient pas une copie complète de la base Configuration Manager; connectivité et composants de site restent nécessaires.

Tenant Attach peut être activé sans co-management. Dans ce cas, Managed by reste ConfigMgr et les workloads ne sont pas transférés; seules les fonctions explicitement supportées utilisent le chemin cloud attach.

Tenant Attach synchronise vers Intune les appareils et collections sélectionnés depuis la hiérarchie Configuration Manager. Le portail peut ensuite afficher détails client, timeline, Resource Explorer et certaines actions en temps réel.

Pourquoi cette technologie existe

L’assistant Co-management de la console Configuration Manager permet d’activer Tenant Attach même sans activer co-management. Le service connection point établit la relation avec le tenant et la région cloud.

L’administrateur choisit les appareils et collections à uploader. Une collection synchronisée n’est pas automatiquement autorisée pour toutes les politiques Endpoint security; cette capacité possède une option distincte et une liste de politiques supportées.

Les objets apparaissent dans Intune avec ConfigMgr dans Managed by lorsqu’ils ne sont pas enrôlés MDM. Je ne les mélange pas avec managedDevices natifs dans les rapports ou automatisations.

Architecture Tenant Attach s’appuie sur la chaîne Client → Site → Cloud → Console. 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 Configuration Manager current branch supporté, service connection point online, tenant Intune et identité Entra, collections pilotes. 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 Device absent, Fiche visible, détails vides et CMPivot incomplet. 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. Client ouvre la séquence: Le client ConfigMgr reste rattaché au site. Site prend ensuite le relais: Service connection point publie devices et collections. Le traitement se poursuit avec Cloud, où Intune stocke index et autorisations. Enfin, Console ferme la boucle: L’admin demande vues et actions supportées. 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. « Device absent » conduit d’abord à vérifier ConfigMgr logs et sync, car la cause possible est Collection ou upload. Pour « Fiche visible, détails vides », la preuve utile devient Site/component status. Les cas « CMPivot incomplet » et « Action interdite » 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 Architecture Tenant Attach expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions Configuration Manager current branch supporté, service connection point online, tenant Intune et identité Entra, collections pilotes doivent être réunies en même temps. La validation porte ensuite sur Valider versions, tenant et région, Activer Tenant Attach sur une collection laboratoire, Attendre les objets dans Intune et Comparer Managed by et identifiants. 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

L’assistant Co-management de la console Configuration Manager permet d’activer Tenant Attach même sans activer co-management. Le service connection point établit la relation avec le tenant et la région cloud.

L’administrateur choisit les appareils et collections à uploader. Une collection synchronisée n’est pas automatiquement autorisée pour toutes les politiques Endpoint security; cette capacité possède une option distincte et une liste de politiques supportées.

Les objets apparaissent dans Intune avec ConfigMgr dans Managed by lorsqu’ils ne sont pas enrôlés MDM. Je ne les mélange pas avec managedDevices natifs dans les rapports ou automatisations.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose Configuration Manager current branch supporté, service connection point online, tenant Intune et identité Entra, collections pilotes, rôles ConfigMgr et Intune. Ces conditions permettent de distinguer une limite de Architecture Tenant Attach d’un scénario simplement non éligible.

• Configuration Manager current branch supporté
• service connection point online
• tenant Intune et identité Entra
• collections pilotes
• rôles ConfigMgr et Intune
• endpoints cloud autorisés
• revue données et consentement

Cycle de fonctionnement, étape par étape

Le cycle de Architecture Tenant Attach traverse Client → Site → Cloud → Console. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Architecture Tenant Attach, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Architecture Tenant Attach

L’assistant Co-management de la console Configuration Manager permet d’activer Tenant Attach même sans activer co-management. Le service connection point établit la relation avec le tenant et la région cloud.

L’administrateur choisit les appareils et collections à uploader. Une collection synchronisée n’est pas automatiquement autorisée pour toutes les politiques Endpoint security; cette capacité possède une option distincte et une liste de politiques supportées.

Les objets apparaissent dans Intune avec ConfigMgr dans Managed by lorsqu’ils ne sont pas enrôlés MDM. Je ne les mélange pas avec managedDevices natifs dans les rapports ou automatisations.

• Configuration Manager current branch supporté
• service connection point online
• tenant Intune et identité Entra
• collections pilotes

Traitement, exploitation et cas limites de Architecture Tenant Attach

Les données de base sont synchronisées pour présenter les appareils. Certaines vues riches récupèrent des données volatiles depuis le site en temps réel, ce qui explique qu’une fiche existe alors qu’une action échoue si le chemin on-premises est indisponible.

Les actions supportées incluent selon versions CMPivot, scripts, installation d’applications, timeline, Resource Explorer et détails client. Chaque action applique des permissions Intune, Configuration Manager et parfois des exigences de collection.

CMPivot exécute une requête sur les clients en ligne et retourne les résultats via l’infrastructure Configuration Manager. Un résultat incomplet signifie souvent que certains clients sont offline ou ne répondent pas dans la fenêtre.

• Tester détails, timeline et CMPivot
• Tester RBAC positif et négatif
• Étendre les collections progressivement

Lire les états propres à Architecture Tenant Attach

L’identité et le consentement créés pour cloud attach doivent être gouvernés. Je revois application/service principal, rôles, compte d’activation, scopes et audit logs sans conserver un Global Administrator permanent.

Les données envoyées sont documentées par Microsoft. L’équipe sécurité et protection des données valide la région, la finalité, les champs, la rétention et les rôles avant activation.

Le pilote confirme upload, latence, RBAC, trois vues et une action non destructive. Le rollback désactive l’upload des collections ou Tenant Attach sans modifier les workloads déjà placés ailleurs.

• Device absent — ConfigMgr logs et sync
• Fiche visible, détails vides — Site/component status
• CMPivot incomplet — Online count
• Action interdite — Audit et permissions

Pilote et suivi opérationnel de Architecture Tenant Attach

Le pilote couvre le périmètre Configuration Manager, Tenant Attach, Intune, CMPivot et contrôle Valider versions, tenant et région. Activer Tenant Attach sur une collection laboratoire. Attendre les objets dans Intune. Les résultats sont segmentés selon les populations réellement concernées par Architecture Tenant Attach.

Les cas d’échec « Device absent », « Fiche visible, détails vides », « CMPivot incomplet » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve visibilité ne signifie pas gestion MDM, données temps réel dépendent du site, consentement à gouverner, collections et RBAC doivent converger. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Valider versions, tenant et région. Activer Tenant Attach sur une collection laboratoire. Attendre les objets dans Intune. Comparer Managed by et identifiants. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Architecture Tenant Attach, 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.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-Service CcmExec | Select-Object Name,Status,StartType
  Get-CimInstance -Namespace 'root\ccm' -ClassName SMS_Client | Select-Object ClientVersion
  Get-CimInstance -Namespace 'root\ccm' -ClassName SMS_Authority | Select-Object CurrentManagementPoint,Name
} catch { Write-Error "Collecte client ConfigMgr impossible : $($_.Exception.Message)"; exit 1 }

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

La chronologie de Architecture Tenant Attach relie Client, Site, Cloud, Console. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Valider versions, tenant et région. Activer Tenant Attach sur une collection laboratoire. Attendre les objets dans Intune. Comparer Managed by et identifiants. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Collection ou upload », « Canal temps réel indisponible », « Clients offline » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Valider versions, tenant et région.
• Activer Tenant Attach sur une collection laboratoire.
• Attendre les objets dans Intune.
• Comparer Managed by et identifiants.
• Tester détails, timeline et CMPivot
• Tester RBAC positif et négatif
• Étendre les collections progressivement

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Valider versions, tenant et région, Activer Tenant Attach sur une collection laboratoire, Attendre les objets dans Intune et Comparer Managed by et identifiants. Ces contrôles relient la configuration du service au résultat réellement observé.

• Valider versions, tenant et région.
• Activer Tenant Attach sur une collection laboratoire.
• Attendre les objets dans Intune.
• Comparer Managed by et identifiants.
• Tester détails, timeline et CMPivot
• Tester RBAC positif et négatif
• Étendre les collections progressivement

Limites, modes de panne et lecture des erreurs

Les écarts connus de Architecture Tenant Attach incluent Device absent, Fiche visible, détails vides, CMPivot incomplet, Action interdite. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Architecture Tenant Attach commence sur le périmètre Configuration Manager, Tenant Attach, Intune, CMPivot, Inside Endpoint — Client, Site, Cloud, Console, Configuration Manager current branch supporté, service connection point online, tenant Intune et identité Entra. Les limites et actions de réversibilité ci-dessous cadrent la progression.