ConfigMgr : comprendre SCCM sans se perdre dans la console

Un parc de 300 postes peut sembler sain dans la console et rater un déploiement entier à cause d’un client mal réparé. ConfigMgr mérite donc moins un discours marketing qu’une lecture méthodique de ses preuves : état du client, frontières réseau, contenu distribué, règles de collection et journaux côté machine.

Fabien Coste, persona de Transferts Numériques, a surtout connu l’outil en formation et en reprise de parcs déjà installés. Son angle est simple : ConfigMgr devient clair quand on arrête de regarder tous les menus et que l’on suit le chemin réel d’un ordre envoyé à un poste.

ConfigMgr, SCCM, MECM : remettre les noms dans l’ordre

Microsoft a changé les noms, pas la logique de fond. SCCM a longtemps désigné System Center Configuration Manager, puis le produit a été renommé Microsoft Endpoint Configuration Manager avant de rester, dans l’usage courant, Configuration Manager ou ConfigMgr. Dans une équipe, ces trois appellations parlent souvent du même socle.

La confusion arrive quand on mélange le produit avec Intune, avec le Centre logiciel ou avec un simple serveur de mises à jour. ConfigMgr n’est pas une application isolée sur un poste : c’est une plateforme qui distribue des consignes à des clients, conserve un inventaire et applique des politiques selon des groupes de machines.

Pour lever un doute, je conseille de noter le nom utilisé dans votre documentation interne et de l’employer partout. Une procédure qui dit SCCM dans le titre, MECM dans les captures et ConfigMgr dans les scripts fabrique déjà une future erreur.

Dans mes notes de formation, je fais dessiner ce chemin sur une seule page. Un rectangle pour le serveur, un pour le poste, un pour le contenu, puis des flèches pour la politique et le retour d’état. Ce schéma très simple évite de transformer ConfigMgr en boîte noire et oblige à nommer l’étape que l’on contrôle.

Le chemin d’un déploiement, de la console au poste

Point de contrôle	Ce que Fabien vérifie	Décision utile
Client installé	Version, affectation au site, dernier contact	Réparer le client avant de toucher au serveur
Contenu distribué	Présence sur le point de distribution utilisé	Redistribuer puis tester sur une machine pilote
Collection cible	Membres au moment du déploiement	Valider la portée avant production

Le parcours commence dans la console avec une application, un package, une séquence de tâches ou une mise à jour. Ensuite viennent la distribution du contenu, le ciblage par collection, la politique récupérée par le client et enfin l’exécution locale. Chaque étape laisse une trace différente.

Sur le terrain, le piège consiste à conclure trop vite que le serveur est en panne. Si le contenu n’est pas sur le bon point de distribution, si la collection ne contient pas le poste, ou si le client n’a pas encore récupéré sa politique, la console peut donner une impression de lenteur alors que la mécanique suit simplement son délai.

Un bon test consiste à déployer une petite application silencieuse sur cinq machines connues. Si ces cinq postes couvrent deux sous-réseaux, un portable en VPN et un poste fraîchement installé, vous verrez très vite si ConfigMgr souffre d’un problème d’architecture ou seulement d’un mauvais ciblage.

La documentation officielle donne les termes exacts, mais l’équipe a aussi besoin de repères locaux : nom du site, plages IP, points de distribution et délai moyen de récupération de stratégie. Sans ces repères, chaque incident ressemble à une découverte complète du produit.

Clients, limites réseau et points de distribution

Le client ConfigMgr installé sur Windows est la pièce que l’on oublie le plus. Sans lui, pas d’inventaire fiable, pas de Centre logiciel exploitable et pas de retour d’état. Sa version, son affectation au bon site et sa capacité à joindre le serveur comptent davantage qu’une jolie collection dans la console.

Les limites réseau, souvent appelées boundaries dans la documentation, indiquent au poste où aller chercher son contenu. Une mauvaise frontière transforme un déploiement banal en téléchargement lent depuis un site distant. Dans les parcs multi-sites, c’est la première zone que je contrôle avant d’accuser le WAN.

Le point de distribution doit contenir le bon paquet, dans la bonne version. Une application modifiée mais non redistribuée produit des symptômes trompeurs : l’administrateur voit une configuration récente, le poste télécharge encore l’ancien contenu ou ne trouve rien.

Quand un déploiement échoue, je refuse les corrections en rafale. On vérifie d’abord que le poste appartient au bon site, puis que le contenu existe, puis que la politique descend. Cette séquence paraît scolaire, pourtant elle économise beaucoup de redémarrages inutiles.

Collections et règles de ciblage : le risque silencieux

Une collection dynamique est pratique, mais elle peut être dangereuse quand sa requête WMI ou son critère d’inventaire est trop large. Un simple filtre mal pensé peut envoyer une application métier à un service entier ou, à l’inverse, exclure les postes qui en ont le plus besoin.

Je préfère nommer les collections avec leur intention : pilote, production, retrait, test, exception. Ce vocabulaire évite de confondre un groupe de validation avec une cible finale. Les membres directs doivent rester rares, car ils se documentent mal et vieillissent très vite.

Avant un déploiement sensible, exportez ou capturez la liste des membres. Cette photographie vous protège si la règle change après coup. Elle aide aussi à expliquer pourquoi un poste a reçu, ou n’a pas reçu, une action précise.

Les collections méritent une revue régulière. Les machines retirées, renommées ou réinstallées laissent parfois des traces qui faussent les rapports. Un nettoyage trimestriel des groupes pilotes, des exceptions et des requêtes anciennes garde ConfigMgr plus lisible.

Journaux ConfigMgr : les fichiers qui répondent vraiment

La console donne une synthèse. Les logs racontent l’histoire. AppEnforce.log aide pour une application, CAS.log et ContentTransferManager.log parlent du téléchargement, LocationServices.log renseigne la localisation, UpdatesDeployment.log suit les mises à jour. Côté serveur, d’autres journaux complètent le tableau.

Le réflexe utile consiste à lire le log au moment de l’action, pas deux heures plus tard. Lancez la récupération de stratégie, ouvrez le fichier avec CMTrace ou un lecteur équivalent, puis observez l’erreur exacte. Un code de sortie applicatif n’a pas le même sens qu’un contenu introuvable.

Mon avis est tranché : une équipe qui ne lit jamais les logs ConfigMgr administre à l’aveugle. La console rassure, mais le poste décide. Tant que le journal local n’a pas confirmé l’étape bloquée, le diagnostic reste une hypothèse.

Pour les logs, je garde une fiche courte par scénario : application, mise à jour, inventaire, séquence de tâches. Chaque fiche indique trois fichiers à ouvrir et le symptôme attendu. Le but n’est pas de tout apprendre par cœur, mais de commencer au bon endroit.

Le même réflexe de prudence vaut pour une logique de sauvegarde déjà éprouvée, un exemple de support à préserver et une méthode de contrôle avant manipulation. Le contexte change, mais la méthode reste la même : identifier la source, protéger les données, vérifier le résultat.

ConfigMgr et Intune : une transition à piloter, pas une opposition

Intune convient très bien à des postes mobiles, cloud-first, avec des règles modernes et moins de dépendance au réseau interne. ConfigMgr garde une force dans les environnements lourds : séquences de tâches, contenus volumineux, serveurs internes, exigences précises autour de Windows et de l’inventaire.

Beaucoup d’organisations vivent une période hybride. Ce n’est pas un échec, à condition de décider quel outil pilote quoi. Les mises à jour, les applications, la conformité et l’enrôlement ne doivent pas se marcher dessus. Une double consigne mal comprise produit des postes qui semblent capricieux.

La bonne question n’est donc pas de remplacer ConfigMgr par principe. Demandez plutôt quelles machines ont besoin d’une gestion locale fine et lesquelles peuvent rejoindre un modèle plus léger. Le choix devient alors opérationnel, pas idéologique.

La transition vers Intune doit être accompagnée d’un inventaire des usages encore dépendants du réseau interne. Images de référence, gros packages, sites isolés et contraintes métiers donnent des réponses plus fiables qu’une préférence personnelle pour le cloud.

Conclusion

ConfigMgr devient beaucoup moins opaque quand on suit le trajet d’une consigne au lieu de cliquer partout dans la console. Vérifiez le client, la collection, le contenu et les journaux avant de conclure. Cette méthode lente en apparence évite les déploiements ratés et les diagnostics spectaculaires mais faux. Pour un parc en production, commencez petit, documentez les exceptions et gardez Intune comme un complément possible, pas comme un slogan de remplacement.

Questions fréquentes

Quelle est la différence entre SCCM et ConfigMgr ?

Dans la pratique, SCCM et ConfigMgr désignent le même outil de gestion Microsoft, même si le nom officiel a évolué. L’important est de documenter le nom retenu dans l’équipe pour éviter les procédures contradictoires.

À quoi sert ConfigMgr ?

Il sert à inventorier les postes, déployer des applications, gérer des mises à jour, exécuter des séquences de tâches et suivre les états de conformité sur un parc Windows.

ConfigMgr remplace-t-il Intune ?

Non. Les deux outils peuvent coexister. Intune est plus adapté au cloud et à la mobilité, ConfigMgr reste solide pour les environnements internes complexes et les déploiements lourds.