Cloud Management Gateway : architecture et flux de gestion Configuration Manager sur Internet

L’essentiel

Cloud Management Gateway permet aux clients Configuration Manager itinérants de recevoir policy, inventaire, applications et mises à jour prises en charge sans VPN et sans publication entrante de l’infrastructure on-premises.

L’architecture actuelle utilise un virtual machine scale set Azure, un certificat serveur, une ou plusieurs app registrations Entra et le CMG connection point installé sur un site system. Les management points et software update points doivent accepter le trafic CMG.

L’authentification client peut utiliser Microsoft Entra, un certificat PKI ou un token Configuration Manager selon le scénario. Le choix détermine capacités user-centric, dépendances CRL et onboarding des postes Internet.

Cloud Management Gateway permet aux clients Configuration Manager itinérants de recevoir policy, inventaire, applications et mises à jour prises en charge sans VPN et sans publication entrante de l’infrastructure on-premises.

Pourquoi cette technologie existe

Le client détermine s’il est intranet ou Internet selon sa capacité à joindre un contrôleur de domaine ou un management point on-premises. En Internet, il utilise le CMG connu par sa policy de localisation.

Le service CMG s’exécute dans Azure sur VM scale set et reçoit le trafic HTTPS. Microsoft gère la plateforme; l’organisation ne place pas un firewall ou proxy d’inspection devant les instances CMG.

Le CMG connection point est un rôle de site system qui initie des connexions sortantes persistantes vers le service. Il transporte les requêtes vers le site sans ouverture entrante depuis Internet.

Architecture Cloud Management Gateway s’appuie sur la chaîne Client → Azure CMG → Connection point → Site roles. 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 supporté, abonnement Azure et droits séparés, certificat serveur CMG, app registrations Entra. 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 Provisioning failed, CMG Ready, client offline et Policy OK, contenu absent. 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: Détecte Internet et ouvre HTTPS vers le CMG. Azure CMG prend ensuite le relais: Préauthentifie et relaie sans exposer le site. Le traitement se poursuit avec Connection point, où Maintient le canal sortant vers Azure. Enfin, Site roles ferme la boucle: MP, SUP et content traitent la demande. 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. « Provisioning failed » conduit d’abord à vérifier CloudMgr/CMGSetup, car la cause possible est Azure, app ou certificat. Pour « CMG Ready, client offline », la preuve utile devient LocationServices/CcmMessaging. Les cas « Policy OK, contenu absent » et « Erreur certificat » 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 Cloud Management Gateway expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions Configuration Manager supporté, abonnement Azure et droits séparés, certificat serveur CMG, app registrations Entra doivent être réunies en même temps. La validation porte ensuite sur Dessiner authentification et rôles cibles, Créer le CMG VM scale set en pilote, Ajouter le connection point et Autoriser MP, SUP et contenu nécessaires. 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

Le client détermine s’il est intranet ou Internet selon sa capacité à joindre un contrôleur de domaine ou un management point on-premises. En Internet, il utilise le CMG connu par sa policy de localisation.

Le service CMG s’exécute dans Azure sur VM scale set et reçoit le trafic HTTPS. Microsoft gère la plateforme; l’organisation ne place pas un firewall ou proxy d’inspection devant les instances CMG.

Le CMG connection point est un rôle de site system qui initie des connexions sortantes persistantes vers le service. Il transporte les requêtes vers le site sans ouverture entrante depuis Internet.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose Configuration Manager supporté, abonnement Azure et droits séparés, certificat serveur CMG, app registrations Entra, CMG connection point. Ces conditions permettent de distinguer une limite de Architecture Cloud Management Gateway d’un scénario simplement non éligible.

• Configuration Manager supporté
• abonnement Azure et droits séparés
• certificat serveur CMG
• app registrations Entra
• CMG connection point
• MP/SUP compatibles
• budget, alertes et runbook certificat

Cycle de fonctionnement, étape par étape

Le cycle de Architecture Cloud Management Gateway traverse Client → Azure CMG → Connection point → Site roles. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Architecture Cloud Management Gateway, 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 Cloud Management Gateway

Le client détermine s’il est intranet ou Internet selon sa capacité à joindre un contrôleur de domaine ou un management point on-premises. En Internet, il utilise le CMG connu par sa policy de localisation.

Le service CMG s’exécute dans Azure sur VM scale set et reçoit le trafic HTTPS. Microsoft gère la plateforme; l’organisation ne place pas un firewall ou proxy d’inspection devant les instances CMG.

Le CMG connection point est un rôle de site system qui initie des connexions sortantes persistantes vers le service. Il transporte les requêtes vers le site sans ouverture entrante depuis Internet.

• Configuration Manager supporté
• abonnement Azure et droits séparés
• certificat serveur CMG
• app registrations Entra

Traitement, exploitation et cas limites de Architecture Cloud Management Gateway

Le certificat serveur du CMG établit le canal TLS et son nom doit correspondre au service. Son renouvellement est planifié longtemps avant expiration en conservant exactement les exigences de nom et chaîne.

Les clients Microsoft Entra joined ou hybrid joined peuvent s’authentifier avec leur identité Entra. Les certificats PKI prennent en charge d’autres scénarios, mais nécessitent chaîne de confiance et CRL publique si la vérification de révocation est activée.

Les management points et software update points choisis autorisent le trafic CMG. Le contenu peut être servi depuis le stockage associé si l’option est activée et si les packages sont distribués au CMG.

• Tester un client Internet
• Lire logs de chaque segment
• Mesurer trafic, coût et résilience

Lire les états propres à Architecture Cloud Management Gateway

Les boundary groups peuvent référencer le CMG et préférer les sources cloud. Cette préférence influence VPN et agences; je mesure coût d’egress, latence et impact sur le WAN avant activation large.

CloudMgr.log et CMGSetup.log suivent le provisioning; CMGService.log et SMS_Cloud_ProxyConnector.log suivent le service et la connexion; LocationServices.log, ClientLocation.log et CcmMessaging.log décrivent le client.

Le pilote teste un poste Internet pur, policy, inventaire, application, software update, rotation de certificat et panne du connection point. Les alertes de trafic et coût Azure sont calibrées sur les volumes réels.

• Provisioning failed — CloudMgr/CMGSetup
• CMG Ready, client offline — LocationServices/CcmMessaging
• Policy OK, contenu absent — ContentTransferManager
• Erreur certificat — TLS et CMG properties

Pilote et suivi opérationnel de Architecture Cloud Management Gateway

Le pilote couvre le périmètre Configuration Manager, Cloud Management Gateway, CMG, Azure et contrôle Dessiner authentification et rôles cibles. Créer le CMG VM scale set en pilote. Ajouter le connection point. Les résultats sont segmentés selon les populations réellement concernées par Architecture Cloud Management Gateway.

Les cas d’échec « Provisioning failed », « CMG Ready, client offline », « Policy OK, contenu absent » 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 CMG ne remplace pas le site, pas d’inspection devant le service Azure, certificat à renouveler, coût contenu à mesurer. 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 Dessiner authentification et rôles cibles. Créer le CMG VM scale set en pilote. Ajouter le connection point. Autoriser MP, SUP et contenu nécessaires. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Architecture Cloud Management Gateway, 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 Status,StartType
  Get-CimInstance -Namespace 'root\ccm' -ClassName SMS_Authority | Select-Object CurrentManagementPoint,Name
  Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\CCM' -ErrorAction SilentlyContinue | Select-Object CMGFQDNs
  Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\CCM\Security' -ErrorAction SilentlyContinue | Select-Object ClientAlwaysOnInternet
} catch { Write-Error "Collecte CMG impossible : $($_.Exception.Message)"; exit 1 }

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

La chronologie de Architecture Cloud Management Gateway relie Client, Azure CMG, Connection point, Site roles. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Dessiner authentification et rôles cibles. Créer le CMG VM scale set en pilote. Ajouter le connection point. Autoriser MP, SUP et contenu nécessaires. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Azure, app ou certificat », « Location ou auth », « Package non distribué » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Dessiner authentification et rôles cibles.
• Créer le CMG VM scale set en pilote.
• Ajouter le connection point.
• Autoriser MP, SUP et contenu nécessaires.
• Tester un client Internet
• Lire logs de chaque segment
• Mesurer trafic, coût et résilience

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Dessiner authentification et rôles cibles, Créer le CMG VM scale set en pilote, Ajouter le connection point et Autoriser MP, SUP et contenu nécessaires. Ces contrôles relient la configuration du service au résultat réellement observé.

• Dessiner authentification et rôles cibles.
• Créer le CMG VM scale set en pilote.
• Ajouter le connection point.
• Autoriser MP, SUP et contenu nécessaires.
• Tester un client Internet
• Lire logs de chaque segment
• Mesurer trafic, coût et résilience

Limites, modes de panne et lecture des erreurs

Les écarts connus de Architecture Cloud Management Gateway incluent Provisioning failed, CMG Ready, client offline, Policy OK, contenu absent, Erreur certificat. 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 Cloud Management Gateway commence sur le périmètre Configuration Manager, Cloud Management Gateway, CMG, Azure, Inside Endpoint — Client, Azure CMG, Connection point, Site roles, Configuration Manager supporté, abonnement Azure et droits séparés, certificat serveur CMG. Les limites et actions de réversibilité ci-dessous cadrent la progression.