Etendre son infrastructure MEM Configuration Manager dans Azure – Partie 1 – Déploiement d’une Passerelle de Gestion Cloud (Cloud Management Gateway)

Le contexte

Les derniers mois ont démontré toute la complexité de gérer les postes de travail lorsqu’ils sont déconnectés du réseau d’entreprise ou connecté avec un client VPN. Bon nombre d’entreprises n’étaient pas préparées à ce type de situation et les administrateurs systèmes et réseaux ont dû passer de longues heures à déployer des solutions de connectivité pour “récupérer” leurs ordinateurs lâchés dans la nature et ainsi pouvoir continuer à les gérer.

Microsoft EndPoint Manager Configuration Manager est traditionnellement identifié comme étant le composant “on-premise” de la suite Microsoft EndPoint Manager et Microsoft EndPoint Manager Intune comme le pendant “cloud” de cet ensemble d’outils.

Cela peut être schématisé de la sorte mais, depuis la version 1610 (4 ans déjà !), une infrastructure SCCM (on l’appellera encore longtemps comme cela) peut être complétée d’une passerelle de gestion cloud (CMG) pour la gestion des postes en mode Internet.

Nous allons donc décrire dans cet article la finalité de ce composant, comment le déployer et ensuite nous positionner côté client pour valider le bon fonctionnement.

Mais au fait : à quoi ça sert ?

Mais pourquoi vouloir déployer une Cloud Management Gateway me direz-vous ? Si vous vous intéressez à la gestion des postes de travail et que vous n’êtes pas restés dans une grotte les 5 dernières années, on vous a rabâché le discours suivant : “si vous voulez gérer des postes sur Internet, vous avez Intune mon bon monsieur !”

OUI, MEM Intune est un formidable outil de management, multi-plateformes, en capacité à prendre en charge beaucoup de cas d’usages MAIS quand vous avez investi depuis plusieurs années sur SCCM, vous n’allez pas mettre à la poubelle toutes vos applications, vos scripts, vos séquences de tâches pour tout basculer dans MEM Intune.
Au delà de l’effort et des coûts engendrés, MEM Intune ne recouvre pas le même périmètre fonctionnel que MEM Configuration Manager et ne le fera jamais (je m’avance peut-être un peu là).

Donc, pourquoi vouloir déployer une CMG (à partir de maintenant, j’emploierai cet acronyme) ? Pour fournir un grand nombre de fonctionnalités disponibles depuis MEM CM “on-premise” (https://docs.microsoft.com/fr-fr/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#support-for-configuration-manager-features) :

Note : ces fonctionnalités s’enrichissent à chaque nouvelle version. C’est bien là un signe, selon nous, de la volonté de Microsoft de pousser les entreprises à adopter cette fonctionnalité qui repose sur les services fournis par Azure.

Déploiement de la CMG depuis la console EndPoint Manager

Je vais vous présenter les grandes étapes du déploiement d’une CMG et ensuite vous montrer comment cela se matérialise du côté du client MEMCM.

Au final, notre infrastructure de gestion ressemblera à cela :

Prérequis

Abonnement Azure (pas d’abonnement CSP)
Il est nécessaire de disposer d’une souscription Azure pour déployer la Cloud Management Gateway. Pour l’heure, pas d’abonnement Azure en mode CSP (Cloud Solution Provider). En Technical Preview MEMCM 2009 ; vers une disponibilité générale en version MEMCM 2010 ?

Certificat (public dans notre cas)
Idéalement, un certificat signé par une autorité de confiance de type Wildcard (*.<nomdomaine>) limitera le risque d’indisponibilité du nom choisi pour le Cloud Service.

Compte Administrateur général Azure AD & compte ayant le rôle  Propriétaire d’abonnement Azure
L’administrateur général est nécessaire pour intégrer le site avec Azure AD. Le rôle Propriétaire d’Abonnement est requis pour pouvoir déployer des ressources.

Fournisseurs de ressources Microsoft.ClassicCompute & Microsoft.Storage inscrits dans l’abonnement Azure
La Passerelle de Gestion Cloud s’appuie sur des ressources de type Classic Compute et Storage. Si ces ressources ne sont pas inscrites dans l’abonnement, le déploiement échouera.

Nous allons maintenant décrire les étapes nécessaires pour le déploiement de la CMG. La majorité des actions s’effectuent depuis la console EndPoint Manager.
Note : toutes les captures d’écran sont effectuées depuis une console en anglais car cela facilite la recherche ultérieure d’information… au cas où cela ne fonctionnerait pas !

Activation de la fonctionnalité

Par défaut, Configuration Manager n’active pas cette fonctionnalité facultative. Vous devez activer cette fonctionnalité avant de l’utiliser.
Pour ce faire, depuis la console EndPoint Manager, dans l’onglet Administration>Update and Servicing>Features :

Activation service Cloud Management Gateway

Vous aurez à confirmer cette activation :

Confirmation activation CMG

Une fois cette confirmation acquittée, vous verrez apparaitre dans le dossier Cloud Services, un nouvel icône Cloud Management Gateway, juste en dessous de Cloud Distribution Points :

Service CMG activé

Déploiement et configuration de la Cloud Management Gateway

En cliquant sur l’icône Create Cloud Management Gateway, nous allons démarrer le processus de déploiement de la CMG.

La première étape consiste à se connecter à l’environnement Azure :

Connexion à la souscription Azure
Renseignement du login de l’Administrateur de la souscription

Une fois authentifié, la ou les souscriptions Azure répertoriées dans le tenant Azure Active Directory sont listées et l’application Azure AD et le nom du tenant Azure AD sont présentées :

Authentification Azure

Cliquer sur Next>

En tout premier lieu, il faut sélectionner le certificat wilcard permettant d’authentifier le service vis-à-vis des clients.

Note : dès lors que vous allez sélectionner un certificat de type wilcard (*.<nomdomaine>), un message d’avertissement vous indiquera que le certificat wildcard a été détecté :

L’avantage d’utiliser un certificat wildcard est qu’il permet de définir le nom du service “à la volée” et ne nécessite pas de demander au fournisseur de certificat de “coder” le nom du service cloud Azure au risque que le nom ne soit plus disponible au niveau de la souscription Azure (si, si ça arrive, je parle en connaissance de cause).

Passons en revue les informations de cet écran (du haut vers le bas) :

Paramétrage de la CMG

Certificate file : certificat pour authentifier le service Cloud
Service Name : nom qui sera donné au service (nom FQDN de la CMG en fait)
Deployment name : champ rempli automatiquement sur la base du nom du service renseigné au dessus. Comme la CMG est un Cloud Service Azure, son extension est en .cloudapp.net
– Description : champ texte permettant de décrire le service
Region : région Azure dans laquelle la CMG sera déployée
Resource Group : groupe de ressource Azure dans lequel les composants de la CMG seront déployées (VNet, Cloud Service, Stockage…)
VM Instance : nombre (entre 1 et 16) de machines virtuelles (de type Standard A2_V2) associées au Cloud Service (pour des éléments de dimensionnement : https://docs.microsoft.com/fr-fr/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#performance-and-scale)
Verify Client Certificate Revocation : pour de plus amples renseignements (https://docs.microsoft.com/fr-fr/archive/blogs/ieinternals/understanding-certificate-revocation-checks). En résumé, on s’assure que le client vérifie la validité du certificat avant d’accéder au service
Enforce TLS 1.2 : forcer la communication à l’aide du protocole TLS 1.2
Allow CMG to function… : si coché, la CMG fera aussi office de Cloud Distribution Point et hébergera donc le contenu des applications, scripts et définition des updates comme le ferait un Cloud Distribution Point. Cela permet d’économiser une machine virtuelle dans Azure. Rien n’empêche cependant de déployer ensuite d’autres Cloud DP pour répartir les sources géographiquement.

Cliquer sur Next>
Un nouveau panneau de configuration s’affiche, il permet de configurer les alertes de consommation au niveau des échanges sortants (outbound data transfer) et du stockage.
Le service peut automatiquement être stoppé lorsqu’un des seuils Critique est atteint en cochant la case “Stop this service…”

Seuil d’alertes consommation CMG

Cliquer sur Next>

Résumé informations CMG

Un panneau présentant le résumé des informations saisies s’affiche avant de déclencher le déploiement en cliquant sur Next>

Progression déploiement CMG

Le déploiement de la Cloud Management Gateway est maintenant lancé, la progression du provisionnement peut s’effectuer depuis la console. Le premier statut sera Provisioning :

Lorsque le provisionnement est terminé, le statut passera en Ready :

La Cloud Management Gateway est maintenant opérationnelle dans Azure MAIS elle n’est pas exploitable par l’infrastructure MEM Configuration Manager car aucun serveur ne peut communiquer avec elle. C’est ce que nous allons faire dans les prochaines étapes de la procédure.

Création du Point de connexion de service pour la communication avec la CMG

Afin que l’infrastrucure MEM Configuration Manager puisse “dialoguer” avec la Cloud Management Gateway que nous venons de déployer, il est nécessaire de déployer un nouveau rôle dans notre environnement : il s’agit du rôle Cloud management gateway service connection point (n°4 dans le schéma ci-dessous). Ce rôle servira à établir et maintenir le canal de communication sécurisé entre notre environnement on-premise et l’environnement Cloud.
Il est nécessaire de disposer d’au moins 1 service connection point mais, à des fins de haute-disponibilité, il est possible d’en déployer plusieurs.
Une fois de plus, pour toute interrogation sur le fonctionnement, je vous renvoie vers la documentation Microsoft : https://docs.microsoft.com/fr-fr/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#ports-and-data-flow.

L’image suivante schématise le fonctionnement de ce rôle et son importance :

Flux de données vers la CMG au travers du Service Connection Point

Conclusion

Notre Passerelle de Gestion Cloud est maintenant opérationnelle. Pour autant, les postes de travail ne sont pas encore en mesure de se connecter dessus. Il est nécessaire de procéder à la configuration des paramètres du client, d’associer éventuellement la CMG à un groupe de limites (Boundary Group), de distribuer des sources sur le Cloud Distribution Point qu’elle renferme…

Je vous décrirai la suite de la configuration dans un prochain article ainsi que les éléments de troubleshooting (logs, tests à effectuer côté client).

Bonne mise en place !

A propos de l'auteur

David RIBEROT

Référent Technique Modern Workplace et Microsoft Certified Trainer, il a pour volonté de de transmettre ses connaissances à ses collègues et clients. Il anime régulièrement des sessions de présentation de solutions et participe à des événements organisés par Microsoft ou ses partenaires technologiques. Ses domaines de prédilection sont le poste de travail, les environnements de virtualisation et le cloud Azure.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *