SCCM 2012 dans une architecture multi-forêts

Il est très fréquent dans les grandes entreprises de trouver une architecture Active Directory composée de plusieurs domaines, voire de plusieurs forêts avec ou sans relations d'approbation. Cette segmentation permet de sécuriser et de limiter l'interaction entre les différentes entités et équipements de l'entreprise. Cette organisation amène tout un ensemble de questions lorsqu'il s'agit d'implémenter SCCM afin de gérer les serveurs et/ou les postes répartis sur ces différents domaines et forêts.

Avec SCCM 2007, on avait généralement pour habitude de calquer l'architecture SCCM sur l'architecture Active Directory. On plaçait donc un premier site primaire central dans la forêt de ressources principale, puis des sites enfants dans les sous-domaines et forêts. Au sein d'un même domaine, on pouvait créer plusieurs sites SCCM 2007 afin de maîtriser la bande passante nécessaire aux réplications entre des sites géographiques différents.

Note : Contrairement à une idée répandue, il n'est pas nécessaire d'avoir une architecture en mode natif (authentification des clients via certificat) pour établir des liens entre des sites SCCM 2007 situés dans des forêts différentes même sans aucune relation d'approbation.

Quels sont désormais les grands principes dans SCCM 2012 pour gérer des postes répartis dans des forêts AD différentes ?

• Créer un site enfant dans une forêt distante. Gros changement par rapport à SCCM 2007 : Cette solution impose d'avoir une relation d'approbation bi-directionnelle entre les 2 forêts. Attention, de nombreux blogs (même officiels) oublient ce pré-requis et construisent des architectures SCCM 2012 comme sous 2007. Le Technet et le support sont pourtant fermes et sans appel : ce prérequis est obligatoire pour permettre aux réplications SQL d'opérer correctement.

• Installer un site system (un serveur disposant d'un rôle SCCM) dans une forêt distante. En effet, il n'est pas nécessaire que tous les serveurs d'un site SCCM 2012 soient dans le même domaine ni dans la même forêt. Il n'est même pas nécessaire que les différents domaines/forêts aient la moindre relation d'approbation. Lors de l'installation du site system, il est nécessaire de fournir un compte disposant des droits d'administrateur local sur ce serveur. C'est ensuite ce compte qui servira pour communiquer en le Site System et le Site Server (serveur principal d'un site SCCM)

• Gérer directement les postes depuis des serveurs SCCM situés dans une autre forêt. En effet, rien n'impose encore qu'un poste et le serveur SCCM qui le gère soient dans le même domaine. Rappelons à ce titre, qu'il est même possible de gérer des postes en workgroup. Quelques précautions s'imposent néanmoins pour localiser correctement les serveurs SCCM quand on ne peut pas utiliser Active Directory.

Pour plus d'information : Planning for Communications in Configuration Manager

Quelles sont les impactes directes sur l'architecture ?

Nous voyons clairement que SCCM ne peut plus suivre l'architecture Active Directory si les différentes forêts ne sont pas liées entre elles par des relations d'approbation bi-directionnelles !

Retenons 2 principes de bases sous SCCM 2012 :

• Tous les Site Servers doivent être situés dans la même forêt (ou dans des forêts ayant une relation bi-directionnelle, ce qui est rarement le cas quand on souhaite justement isoler les différents environnements).
• Par contre, au sein d'un même site primaire, il est possible de créer plusieurs Management Point et Distribution Point que l'on répartira dans les différentes forêts et domaines à couvrir.

Je rappelle qu'il est possible d'avoir jusqu'à 10 Management Point par site primaire. Il est donc possible de couvrir 10 forêts/domaines différents par site primaire. S'il faut en couvrir d'avantage ou si on souhaite mettre plusieurs MP par forêt/domaine, il faut alors multiplier le nombre de sites primaires et avoir recours à un CAS.

Et dans la pratique, çà donne quoi ?

Prenons l'exemple d'une entreprise avec :

 - 2 forêts appelées ROOT (la forêt de ressource) et CORP (la forêt contenant les postes de l'entreprise)

 - 3 emplacements géographiques : Londres, Paris et New-York

Les serveurs de la forêt de ressource ROOT sont principalement localisés à Paris.

Les postes de la forêt CORP sont localisés à Paris, Londres et NY

Nous souhaitons bien évidemment être capable de gérer convenablement la réplication entre les sites géographiques.

Pour commencer, voici, l'architecture à ne surtout pas faire sous SCCM 2012 :

Notons qu'il faut :
 - un site Central + 4 sites primaires (voire 6 si on avait voulu gérer des serveurs dans la forêt Root à Londre et Paris).
 - 5 serveurs SCCM (voire 7)

C'était tentant, mais c'est malheureusement tout à fait impossible. Bref, n'en parlons plus !

Maintenant regardons comment nous pouvons simplement faire une architecture SCCM 2012 en gardant quelques (vieux) réflexes de SCCM 2007 :

 - Toujours, plusieurs sites primaires (3), donc un CAS.
 - Les sites servers sont installés dans chaque pays dans la forêt de ressource (on y ajoute au passage les rôles MP et DP).
 - Dans chaque pays, on installe également un site system dans la forêt CORP avec les rôles MP et DP. Ce sont ces site system qui vont gérer les serveurs dans CORP.

Bilan : Nous avons donc au total 1 CAS, 3 sites primaires pour un total de 7 serveurs.
Pas tellement optimisé mais au moins, çà marche !


Pour aller plus loin... Je vous propose alors cette architecture :

1 seul site Primaire standalone et seulement 4 serveurs !
Nous voyons clairement comment désormais, avec SCCM 2012, il est possible de réduire le nombre de sites, de serveurs et donc le coût global de la solution.

J'entends déjà ceux qui se demandent comment je vais gérer mes réplications entre les 3 sites géographiques. Pour y répondre, je vous propose de me retrouver dans un prochain article où je détaillerai les différentes manières de gérer la bande passante dans SCCM 2012, y compris au sein d'un même site.

@Bientôt

Julien