Architecture SCCM 2012

Un site est un ensemble de ressources gérées par un serveur. La délimitation de ces ressources se fait le plus souvent au moyen de frontières de sites.

À l’intérieur d’une frontière, les nouvelles ressources peuvent être ajoutées de façon dynamique, grâce aux méthodes de découverte.

Frontières

Les frontières servent à déterminer le périmètre de responsabilité d’un serveur de site. Elles peuvent être soit définies sur des plages IP, soit sur des subnets IP, soit sur des définitions de site AD.

Avec la version 2012, les frontières peuvent être découvertes en activant la découverte de « forêt ». Contrairement aux versions précédentes, une frontière ne peut être attribuée directement à un site mais doit être incluse dans un groupe qui sera attribué au site.

Découvertes

ConfigMgr est capable de découvrir les ressources raccordées à un Active Directory. Ce mécanisme dit « de découverte » scrute l’AD à intervalles réguliers et note les ajouts ou modifications.

Ainsi, toute nouvelle ressource est automatiquement ajoutée en fonction de la stratégie retenue (il y a même une découverte ultra-rapide dite Delta qui est reprise de ConfigMgr07 R3). De la même façon (même si cela ne repose pas sur les découvertes mais sur un autre mécanisme), la suppression des ressources inutiles (tombées en obsolescence, retirées du parc) permet à ConfigMgr de fournir un inventaire qui soit le reflet le plus fidèle possible de la réalité du parc.

Rôles & Hiérarchie

Plusieurs sites peuvent être organisés en hiérarchie. Au sein d’un site ou d’une hiérarchie, des rôles peuvent être activés pour proposer une fonctionnalité précise. Dans le cas d’une hiérarchie complexe, quatre types de serveurs peuvent être utilisés : Central, Primaire, secondaire et point de distribution, mais il est possible de n’installer qu’un serveur Primaire pour des environnements simples (on parle tout de même de plusieurs dizaines de milliers de postes sur un Primaire).

CAS

Le Serveur Central d’Administration (ou « CAS ») est une nouveauté de 2012. Il est nécessaire dans toute hiérarchie de plus d’un Primaire et se trouve dans ce cas au sommet de la pyramide. Il ressemble donc fortement au Primaire « racine » d’une hiérarchie ConfigMgr07, comme lui il dispose de l’intégralité des données d’inventaire de la hiérarchie. Toutefois, il ne peut jouer que quelques rôles (reporting et console centrale pour simplifier) et surtout il ne peut gérer aucun client en direct.

Il est important de noter que jusqu’à présent, le CAS doit être installé avant tout autre serveur Primaire. Ce qui signifie que la réflexion sur l’architecture (y aura-t-il plus d’un Primaire ?) est un pré-requis absolu si on ne souhaite pas tout casser et reconstruire plus tard.

Primaires

Le serveur Primaire est un serveur doté d’une base de données et d’une autonomie d’administration. Il s’agit du rôle qui a le moins changé dans l’architecture depuis SMS 2003, même si des évolutions sont apparues au fil des versions (comme le streaming App-V par exemple). Le nouveau modèle de sécurité et de gestion des paramètres « client » fait qu’il n’est plus nécessaire d’installer un Primaire pour segmenter les données, pour gérer des paramètres « client » différents ou pour offrir une administration décentralisée. Un Primaire supplémentaire reste justifié s’il est nécessaire de gérer plus de 100.000 clients (!), pour limiter l’impact d’une panne sur le Primaire ou si des raisons politiques l’exigent.

Secondaires

La deuxième nouveauté concernant les serveurs est l’apparition d’une base SQL sur les secondaires. Il peut s’agir d’une base sur un SQL Server s’ il y en a un de disponible ou d’une base SQL-Express, donc cet aspect n’a pas d’incidence sur le coût d’acquisition de la solution.

Le secondaire permet principalement de réguler le flot remontant des postes gérés : inventaires, statuts. Il ne propose pas d’administration locale.

Points de distribution

Le point de distribution (ou DP, Distribution Point) est un relais de transport de contenu à destination des postes gérés. Il peut être comparé à un serveur de fichiers, et n’exige donc pas un serveur dédié. En revanche, il nécessite comme les trois rôles précédents, un serveur IIS. Sa présence est justifiée si BITS ne suffit pas à réguler le trafic (si de nombreux postes sont présents sur un site par exemple), ou pour fournir des services comme le streaming App-V ou le déploiement d’OS. A noter, le trafic réseau à destination d’un DP peut désormais être contrôlé.

Des technologies de partage de cache (BranchCache si les postes sont en Vista/SP2 ou Seven et les serveurs sont en Win08R2, ou NomadBranch de 1E) permettent de limiter l’impact sur le réseau dans des environnements ne disposant pas d’un serveur capable d’héberger ce rôle de point de distribution.

Données & Réplication

Dans les versions précédentes, les échanges entre client et serveur et entre serveurs se faisaient sur la base d’échanges de fichiers. Ce mécanisme existe toujours mais est limité aux packages. Pour les autres types de données, la synchronisation utilise désormais SQL.

Pour simplifier, on peut considérer que toutes les informations créées dans la console sont disponibles sur tous les serveurs : collections, définitions des packages, etc. Ces données sont appelées « Global Data ». Comme il ne s’agit que de définitions et non de contenus, le volume reste restreint (environ 5% de la taille d’une base).

Les données créées par le système sont baptisées « Site Data ». Par exemple, les membres d’une collection, les inventaires, etc. Elles sont présentes uniquement sur le serveur Primaire (sauf s’il y a un CAS, auquel cas elles seront synchronisées sur le CAS).

On notera que le suivi de la réplication est disponible depuis la console.

Modèle de sécurité

Le fait que la définition des objets soit visible sur tous les serveurs nous amène à nous interroger sur la sécurité et le chaos que peut engendrer le fait de voir tous ce que tous les administrateurs ont créé.

Collections

La segmentation avec laquelle ConfigMgr nous a familiarisés est celle des collections ou regroupements. Ces collections sont des regroupements de ressources. Chacune peut être construite en utilisant des critères, associer des paramètres spécifiques, etc.
Par exemple, une collection pourra contenir toutes les machines dont l’OU est « comptabilité », et y associer une plage de maintenance.

RBAC

La sécurité dans les versions précédentes s’appuyait sur des classes, des instances et les sites.  Cela obligeait parfois à effectuer des tâches un peu fastidieuses pour travailler à plusieurs sur un objet.

Le nouveau modèle de sécurité repose sur des rôles et des périmètres. On peut ainsi avoir un groupe travaillant sur les postes de France et ayant tous, le droit de créer des distributions, et un autre groupe dont les membres ont tous les droits mais uniquement sur les postes de Montluçon.

Conclusion

Ce survol de la nouvelle version donne un léger aperçu de ses nouveautés. Il passe toutefois sous silence nombre d’évolutions, comme toutes celles qui concernent la console. Il reste donc largement matière à creuser ces aspects dans un futur article.