Configuration simplissime de System Center 2012 Configuration Manager SP1

Ayant eu récemment à faire l’exercice de manière théorique et pour un client, je me permets de vous transmettre mes réflexions pour une infrastructure de quelques milliers de clients, quand il n’est pas nécessaire de monter une infrastructure très complexe.

En concentrant au maximum, il est possible de tout faire tenir sur un même serveur. Il n’y a pas d’abaques fournies par Microsoft pour déterminer un dimensionnement car les sollicitations sont très variables d’un client à l’autre, notamment pour ce qui est relatif aux distributions et inventaires, mais aussi en fonction des mises à jour logicielles à mettre en œuvre (langues et produit, mais aussi types de mises à jour).

Le premier rôle qui pourrait être dédié est celui de point de mise à jour logicielle ou Software Update Point (SUP). Pour des questions de sécurité, beaucoup de clients préfèrent séparer ce rôle de manière à ne connecter à Internet que ce serveur quand bien même ce serveur n’est pas accessible depuis Internet, mais accède à quelques serveurs décrits dans l’article kb885819 de la base de connaissances de Microsoft.

Pour une question de facilité d’administration, d’autres clients séparent le serveur de base de données de site ConfigMgr et le point Reporting Services ou Reporting Services Point (RSP) ; ce qui permet, également d’augmenter la montée en charge tout en séparant des flux liés aux bases de données et aux fonctions des rapports. Il est, ainsi, possible d’éviter de placer un rôle Internet Information Server (IIS) sur un serveur lié à SQL Server. Pour mémoire, SQL Server Reporting Services ne repose plus sur IIS, mais délivre directement ses pages.

Toujours dans l’esprit de faciliter l’exploitation, j’aime bien utiliser et séparer le rôle de point d'état de secours ou Fallback Status Point (FSP). Ce rôle, quand il est mutualisé avec un point de gestion ou Management Point (MP) ne garantit pas d’être prévenu d’une impossibilité pour le client à joindre le MP car si, par exemple, le nom du MP ne parvient pas à être résolu via le DNS, il ne sera pas plus résolu pour sa fonction de FSP.

Au final, une infrastructure minimaliste serait, donc, composée de 4 serveurs, plus des éventuels points de distribution ou Distribution Point (DP) à proximité des clients à desservir, notamment pour faire de la distribution de système d’exploitation. Ces DP peuvent être mutualisés avec d’autres fonctions comme un serveur de partage de fichiers.

D’autres rôles peuvent être ajoutés en fonction des évolutions des utilisations que vous ferez de ConfigMgr, mais ces rôles pourront se greffer sur cette base de départ. Ainsi, si vous voulez faire du déploiement de systèmes d’exploitation, pourrez-vous ajouter les fonctions liées à cet usage sur un ou plusieurs DP. Si vous mettez en œuvre un catalogue applicatif à destination des utilisateurs, vous pourrez rajouter les rôles liés au catalogue sur le serveur du MP. Si vous souhaitez synchroniser le catalogue de la gestion des actifs, pourrez-vous mutualiser le rôle de SUP avec celui du point de Synchronisation Asset Intelligence ou Asset Intelligence Synchronization Point (AISP).

Dans tous les rôles de serveur de ConfigMgr, on évitera de mutualiser les rôles avec un contrôleur de domaine dont le modèle de sécurité est très différent de celui d’un serveur membre.

J’espère vous avoir permis de déterminer vos besoins en termes de nombre de serveurs. N’hésitez pas à revenir vers vos contacts chez Microsoft ou vos partenaires habituels ou vers moi si vous avez besoin de plus de précisions, notamment pour une migration depuis des versions précédentes.