System Center Configuration Manager 2012 :

Un grand nombre de points sont laissés sous silence pour tenir en quelques pages, dont les (pourtant très importantes) modifications apportées à la console. Les différences saillantes vis-à-vis des versions précédentes seront toutefois mises en exergue (en tout cas celles que je préfère).

Configuration Manager est un membre de la famille System Center de Microsoft. Il est donc nommé le plus souvent SCCM, et la version 2012 est donc naturellement appelée SCCM12, ou ConfigMgr12. Cette version est le digne héritier de la lignée mais présente des évolutions significatives vis-à-vis de la version 2007.

ConfigMgr permet de collecter des informations sur les ressources d’une organisation (inventaires) et d’effectuer des actions telles que télédistribution de logiciel ou prise de main à distance. La solution est de type client-serveur : elle repose sur un client déployé sur les systèmes à gérer et sur un ou plusieurs serveurs formant dans ce dernier cas une hiérarchie. Les informations collectées sont enregistrées dans une base de données SQL.

–    Elle utilise l’architecture et plusieurs informations de l’Active Directory.
–    Les services de télédistribution et de télé-inventaire impliquent l’utilisation du réseau.
–    La sécurité de la solution utilise Kerberos et peut être encore renforcée en utilisant les mécanismes de PKI et d’authentification forte.
Très discipliné, le monde de Configuration Manager repose sur deux principes simples :
–    les ordres partent d’en haut (le serveur) et descendent vers les clients
–    les informations remontent des clients vers le serveur
Dans tous les échanges, c’est systématiquement le client qui demande au serveur s’il y a du « nouveau » le concernant. Le serveur ne contacte jamais le client.

La plupart des fonctionnalités offertes sont optionnelles, et plusieurs pilotent d’autres fonctionnalités de Windows (NAP, IIS, WSUS, PKI, WDS, etc.). Sans même parler de SQL, autant dire que travailler sur ce produit, loin de nous enfermer dans une technologie, nous ouvre sur une multitude d’autres.

Distribution

Une des fonctions assurées par ConfigMgr est de distribuer des programmes, des correctifs ou des mises à jour de système d’exploitation à distance. Pour cela, il utilise un agent sur les machines gérées avec lequel il communique régulièrement.

Client

Le fonctionnement de la solution repose sur la présence d’un agent sur les postes à gérer. Or comment déployer cet agent lorsque la solution de distribution n’est pas encore en place ?

Plusieurs solutions à cet apparent paradoxe :

–    l’installer à la main ; pour un test c’est envisageable, en environnement réel c’est bien trop coûteux en temps
–    intégrer l’agent dans le master ; dans ce cas, le déploiement se fait au rythme de la mise à jour des postes avec le nouveau master
–    déployer l’agent par GPO ou par script
–    télé-déployer l’agent depuis le serveur. Dans ce dernier cas de figure, le serveur devra être administrateur du poste : pour cela, on utilise le plus souvent le compte machine du serveur et on l’inclut dans un groupe lui-même administrateur de l’ensemble des stations, ou alors on indique à ConfigMgr un couple « compte / mot de passe » administrateur des postes, à utiliser pour l’installation. Ainsi, lorsque l’on active l’installation poussée du client, toute nouvelle machine découverte sur le réseau ou dans le domaine et dont ConfigMgr est censé s’occuper recevra – sans intervention – l’agent. Bien sûr, outre cette question de droits, il y a plusieurs autres conditions à remplir. Les principales sont que les partages administratifs soient activés, que le firewall des postes n’interdise pas l’accès et que les ports nécessaires ne soient pas bloqués par les équipements entre le serveur et le poste.

Retenons simplement que l’agent doit être déployé, et qu’il est possible de le faire sans intervenir sur chaque poste.

Nouveauté de cette version, la gestion annoncée d’autres systèmes d’exploitation, comme certaines distributions de Linux ou, via ActiveSync, Symbian, IOS ou Android. Exit Mobile Device Manager, bienvenue à ConfigMgr !

Policies

Le serveur fonctionne à la façon d’un poste restante. Chaque client vient, à intervalle régulier, relever ce qui le concerne. Il s’agit en fait des instructions découlant des actions des administrateurs : tel programme doit être installé avant telle date, tel correctif doit être installé immédiatement, il est temps de faire un inventaire des programmes du poste, etc. Ces instructions, ou « policies », sont téléchargées par le client, suite à quoi il effectue les tâches associées.

Cela explique pourquoi ConfigMgr ne peut pas envoyer instantanément un programme à un poste. C’est le poste qui ira vérifier, comme tous les autres, selon la fréquence paramétrée, ce qu’il y a de nouveau pour lui. Pour éviter que tous viennent en même temps, une répartition statistique est effectuée entre les clients.

Télédistribution d’applications

La distribution permet de mettre à disposition ou d’imposer l’installation d’applications sur les postes dotés d’un agent.

Il peut s’agir d’applications du commerce (Visio, Acrobat Reader, Winzip, etc.) ou d’applications métier développées spécifiquement.

Les formats de distribution pris en charge sont l’installation classique (MSI, SETUP), la distribution par streaming (App-V), l’envoi d’un script ou la publication depuis un serveur multi-sessions (Citrix, RDS…).

Une application est traditionnellement constituée d’un éventuel contenu et d’un ordre de lancement. Avec cette nouvelle version, une application comporte maintenant la notion de mode d’installation. Ainsi, les trois packages MS Project en mode MSI, en mode App-V ou en mode RDP sont désormais considérés comme la même application.

Cette distribution repose sur:

–    La présence de sources d’installation
–    Un mécanisme d’installation sur le poste capable d’interpréter les sources. Pour les MSI, il s’agit de Windows Installer intégré dans Windows, et pour les applications au format App-V il s’agit du client App-V qui devra être présent.

Qu’il s’agisse d’un téléchargement de MSI ou (dans une moindre mesure) d’un streaming App-V, le réseau est sollicité. Plusieurs mécanismes permettent de limiter l’impact sur le réseau :

–    L’utilisation de BITS
–    Le « throttling » (limitation) de la bande passante
–    Un paramétrage approprié du cache pour App-V
–    L’utilisation de mécanismes peer-to-peer (de type BranchCache ou NomadBranch)
–    La présence de relais de distribution à proximité (au sens réseau) du poste demandeur.

Côté utilisateur, ces opérations de distribution peuvent être plus ou moins invisibles selon la politique retenue. Cela peut ainsi être totalement invisible (de nuit par exemple), partiellement visible mais sans interaction possible, visible avec possibilité de repousser le moment de l’installation, voire proposé au moyen d’un portail de libre-service, n’offrant bien sûr que les applications auxquelles l’utilisateur a droit.
Une des nouveautés de ConfigMgr12 est en effet que l’utilisateur peut demander une application au moyen de ce portail, et si cette application ne lui a pas encore été attribuée, cela déclenche une demande dont la validation entraînera l’installation sans autre intervention. Des mécanismes plus évolués de workflows peuvent être développés à l’aide d’outils tiers.

Correctifs

ConfigMgr s’appuie sur WSUS qu’il pilote complètement. Les quatre notions clefs sont le Point de Mise à Jour (SUP, Software Update Point), les listes, les modèles de déploiement et les packages de déploiement.

Point de mise à jour logicielle : ConfigMgr fonctionne directement avec un serveur Windows Server® Update Services (WSUS) dédié qui joue le rôle de point de mise à jour logicielle (SUP) pour fournir les téléchargements de métadonnées et l’analyse des clients.

Liste de déploiement : Les mises à jour accessibles directement depuis la console ConfigMgr (administration centralisée de l’ensemble des fonctionnalités apportées par la solution) peuvent être regroupées par liste afin de permettre un suivi/reporting et une délégation d’administration, organisés suivant les besoins métiers. On pourra ainsi (par exemple) distinguer les correctifs ciblant les serveurs SQL de ceux ciblant les serveurs IIS pour confier la responsabilité de leur déploiement à des équipes différentes, et les correctifs ciblant les postes à une troisième équipe.

Modèles de déploiement : Les modèles de déploiement contiennent des paramètres courants (planification, collection cible…) utilisés pendant le déploiement des mises à jour logicielles, et sont créés pour réduire le temps de déploiement des mises à jour.

Packages de déploiement : Les packages de déploiement sont identiques aux packages ConfigMgr standard, en ce sens qu’ils définissent les détails du déploiement: répertoire source, points de distribution, mode de téléchargement, etc. Ils sont indépendants du déploiement proprement dit et sont essentiellement un emplacement servant à stocker les mises à jour.

Enfin, le module SCUP permet de créer des catalogues d’updates personnalisés pour les intégrer à WSUS via ConfigMgr. Il permet par exemple d’intégrer les catalogues constructeurs de Dell, IBM, HP… afin de mettre à jour les firmwares et drivers des matériels concernés.

L’identification précise des catégories de population, des scénarii et des modèles de délégation doit être traduite en stratégies techniques ; Le patching de serveurs est soumis à des contraintes généralement plus fortes que celui des postes de travail. La chaîne de décision est par ailleurs souvent différente de celle du parc client.

Masters

La télédistribution de Systèmes d’Exploitation (ou d’images masters) est possible depuis le SP1 de SMS 2003. Bien mieux intégrée, cette brique technique permet de supporter les scénarii de déploiement de systèmes d’exploitation suivants :

–    Installation d’un système d’exploitation sur un poste n’en disposant pas (Scénario NEW COMPUTER)
–    Installation d’un système d’exploitation en remplacement d’un ancien avec récupération de la configuration actuelle et des données utilisateurs (Scénario REFRESH)
–    Migration d’un système d’exploitation vers une version supérieure (Scénario REFRESH)
–    Installation d’un nouveau poste avec transfert des données utilisateurs depuis son ancien poste (Scénario REPLACE)

Ces scénarii sont les mêmes que ceux adressés avec MDT (Microsoft Deployment Toolkit), qui d’ailleurs sans être pour autant nécessaire peut être intégré, pour ajouter des fonctionnalités à ConfigMgr. Le moteur d’exécution des actions à effectuer (les « séquences de tâches ») est partagé par ces deux outils.

Lors d’une migration d’OS ou d’un rafraîchissement de poste (XP vers XP, XP vers Seven ou demain vers Windows 8), il est souvent nécessaire de récupérer des données et de l’environnement utilisateur.

ConfigManager s’appuie sur un mécanisme de transfert des paramètres utilisateurs mis en œuvre par USMT, intégré nativement. Cet outil est paramétrable et ceci afin de préciser quelles données et autres composants de l’environnement utilisateur devant être transférés.

Le mode de fonctionnement d’USMT est le suivant :

–    SCAN STATE: Une capture des données utilisateur est faite. Les règles spécifient les données à sauvegarder (nature, localisation, etc.) et où les enregistrer.
–    LOAD STATE : Une fois le poste remasterisé, l’outil recopie sur le poste les données précédemment sauvegardées. Là encore il est possible de paramétrer cette recopie.

Cette brique de déploiement de systèmes d’exploitation permet sans intervention manuelle l’installation d’une image master sur tout poste géré par l’infrastructure ConfigMgr. L’initialisation d’un tel déploiement peut se faire depuis la console centrale, en bootant sur le réseau grâce au protocole PXE, ou encore en bootant sur un média d’amorçage type DVD ou USB.

Le niveau de service dépendant très fortement du réseau, il est fréquent de proposer la mise en place d’un banc de déploiement isolé du réseau de production (pour déploiement massif), voire de bancs itinérants pour un mode campagne.

La mise en place de ce service requiert d’identifier les modèles à prendre en compte. Pour chacun, il est nécessaire d’identifier et de collecter les drivers. Plusieurs modes de fonctionnement sont envisageables, mais l’objectif est généralement de disposer d’une ou deux images s’adaptant à tous les modèles, et de procéder à des aiguillages dans la logique des Task Sequence de déploiement. Les serveurs peuvent également faire l’objet d’images, ce qui permet d’accélérer leur mise en production. Evidemment, la volumétrie est impactée de façon significative (en dizaines de GO).

Multicast

Certaines étapes de la distribution d’un master peuvent bénéficier du multicast. Le multicast est une technologie comparable à la diffusion d’une émission de radio. Cette diffusion est unique, mais (quasi) tous ceux dont le récepteur est allumé peuvent l’écouter. La distribution de la première partie d’un déploiement de master (le WinPE) peut bénéficier de cette fonctionnalité. Une seule diffusion sur le réseau, et un grand nombre de stations qui la « reçoivent ». C’est hélas limité à cette étape du déploiement. Il s’agit d’une limitation du composant Windows.

Wake-On-Lan

Un poste éteint électriquement peut être allumé à distance. Les pré-requis sont:

•    Que la carte réseau supporte cette opération, ce qui est le cas sur les postes récents
•    Que l’option soit bien activée dans le BIOS (dans ce cas, la carte réseau clignote faiblement quand le poste est éteint)
•    Que les équipements réseau entre le serveur et le poste ne filtrent pas le type de paquet utilisé

Pour cela, il suffit d’envoyer une trame réseau particulière (on parle d’un paquet « Magic ») comportant une séquence particulière et l’identifiant de la carte réseau (la « MAC Address »). La carte réseau, en mode de quasi sommeil, écoute le trafic et réagit à cette trame en rallumant l’ordinateur.

ConfigMgr est capable d’envoyer ce paquet quelques instants avant une distribution planifiée de nuit, permettant ainsi de rallumer les postes. Comme le poste est éteint, le système n’est pas actif, la couche TCP/IP non plus. Il s’agit d’un message de couche basse, diffusé en mode « broadcast » ; le plus souvent les équipements réseau bloquent ce type de trafic, et on peut dans ce cas utiliser des relais tiers.