CAS ou Pas CAS... avec le SP1

Débat débuté dès la sortie des premières versions de SCCM 2012 et qui continue à faire parler de lui dans les entreprises : "Faut-il installer un CAS ou pas ?"

Pour bien commencer, rappelons ce qu'est un CAS :
Par rapport à SCCM 2007, l'organisation des Sites SCCM 2012 s'est vue fortement réduite : il n'est plus possible de mettre un site primaire enfant sous un autre site primaire parent. Un site primaire peut seulement héberger des sites secondaires (250 max par site primaire). En contrepartie, il est possible de mettre jusqu'à 10 Management Point par site primaire et de gérer jusqu'à 100.000 clients (25.000 client max par MP).

Dans certains cas, on peut faire le choix d'implémenter un site central appelé CAS (Central Administrative Site) permettant d'administrer plusieurs sites primaires. Ce site n'a pas vocation à gérer de clients mais seulement à :

• Gérer la réplication entre les sites primaires
• Donner une vision globale de l'infrastructure (reporting...)
• Centraliser l'administration des différents sites primaires

Note : On parle de hiérarchie quand une infrastructure SCCM contient un CAS avec un ou plusieurs sites primaires. Une infrastructure constituée d’un site primaire "standalone" (sans CAS) et de sites secondaires n’est pas considérée comme une hiérarchie puisque les sites secondaires ne sont pas acteurs dans l’administration de la solution.


Quand doit-on mettre un CAS ?
Je vous renvoie à l'excellent article de Brian Mason listant les raisons pour lesquelles il faut installer ou éviter d'installer un CAS :
http://myitforum.com/myitforumwp/2012/04/22/cas-considerations-for-cm12/

Retenons les grands principes :
OUI :

• Si vous avez plus de 100.000 clients à gérer
• Si votre infrastructure SCCM contient plusieurs sites primaires (voir le chapitre dédié à ce sujet)
• Si vous souhaitez simplifier certains aspects de vos restaurations (je parle de recovery, pas de manger pour pas cher, hin ;)). En effet, votre paramétrage étant répliqué entre le CAS et ses sites primaires, lors de la restauration d'un site il est possible de récupérer certaines données depuis le reste de l'infrastructure. Cependant, cela ne dispense absolument pas de faire des backup, mais disons que votre infrastructure sera plus rapidement opérationnelle avec notamment un inventaire à jour.

NON :

• Parce que cette fonctionnalité requière une machine super puissante (http://technet.microsoft.com/en-us/library/hh846235.aspx)
• Parce que cette machine supplémentaire requière nécessairement des licences, des coût de runtime...
• Parce que ce serveur supplémentaire, entraînant des réplications SQL et complexifiant votre infrastructure, demande un effort supplémentaire de gestion et apporte son lot de causes de pannes supplémentaires.

Grosso modo, on peut estimer que dans 95% de cas, il n'est pas utile d'installer de CAS.

 
Quand doit-on avoir plusieurs sites primaires ?
Avoir plusieurs sites primaires implique forcément avoir un CAS. Reste à savoir si le contexte nécessite d'avoir plusieurs sites primaires comme dans SCCM 2007, au risque (encore une fois) de complexifier l'infrastructure.


En effet, SCCM 2012 a fortement diminué les raisons pour lesquelles il faut installer plusieurs primaires : il est notamment possible d'avoir plusieurs politiques clients au sein d'un même site, d'avoir des connexion HTTP et HTTPS (mode mixte et natif sous SCCM 2007) et la délégation a été très nettement améliorée.
Sous SCCM 2007, il était aussi souvent nécessaire de créer plusieurs sites pour gérer des forêts sans relations d'approbations. Au contraire sous SCCM 2012, les relations inter-sites nécessitent des relations inter-forêts bi-directionnelles (réplication SQL oblige). Les relations inter-forêt non-bidirectionnelles ne peuvent être gérées qu'au sein d'un site. (Nous étudierons cette question épineuse dans un prochain message).



On peut vous imposer politiquement ou pour des raisons de sécurité... d'avoir plusieurs sites primaires mais avec ce CAS, vous aurez de toute façon une vision centrale, des réplications et la possibilité de lancer des opérations sur tous vos sites primaires.


Bref, vous l'avez compris, si vous avez moins de 100.000 clients, il est peu probable que vous ayez besoin d'avoir plusieurs sites primaires.

Sur le technet, Microsoft présente un scénario avec 2 sites primaires (et encore, on n'exclue pas d'utiliser un site secondaire et une délégation correctement appliquée) : 2 sites géographiques gérés par 2 équipes techniques différentes selon des règles de gestions différentes. On pourrait envisager d'avoir 2 sites primaires standalone mais ils veulent avoir une vision de l'ensemble ce qui implique l'installation du CAS.
Si le scénario est intéressant, le cas risque d'être assez rare dans la vie réelle :o)






Pourquoi un tel débat ?
Jusqu'à présent ce choix était crucial puisque contrairement à SCCM 2007 qui permettait d'attacher/détacher n'importe quand un site primaire à une hiérarchie, sous SCCM 2012, un site primaire doit être rattaché dès son installation à son CAS ; sinon, il restera à jamais un site Standalone.
Le problème se pose donc par exemple quand aux potentiels projets de fusion/acquisition d'une entreprise : Certains administrateurs souhaitent installer un CAS dans le cas où l'entreprise voudrait rattacher une entité indépendante à son infrastructure SCCM 2012. Notons pourtant qu'il ne sera pas possible de rattacher à postériori une site primaire à un CAS. A partir de là, le débat fait rage quand à la vraisemblance de tels scénarios et au travail qu'il faudra de toute façon fournir.

Prochainement, cette limitation ne sera plus un argument puisque parmi les améliorations annoncées dans SCCM 2012 SP1, on trouve la possibilité "d'étendre" un site primaire standalone en installant un CAS qui lui est alors rattaché. Le Technet indique déjà la marche à suivre : http://technet.microsoft.com/en-us/library/jj591551

A noter qu'il sera seulement possible d'étendre un primaire standalone. Il ne sera donc toujours pas possible de rattacher à postériori un site primaire standalone à une hiérarchie existante. Par contre, le SP1 encore nous permettra de réaliser des migrations d'un environnement SCCM 2012 SP1 vers un autre environnement SCCM 2012 SP1. Typiquement, il sera donc possible de fusionner ou d'exporter des infrastructures SCCM 2012 SP1. On pourra aussi utiliser cette fonctionnalité pour faire communiquer des environnements de test, pré-production et production. Promis, on en reparle...


Pour info, voici la liste complète des améliorations prévues dans le SP1 : http://blog.coretech.dk/kea/configmgr-2012-sp1-announced-teched-2012/


@bientôt
Julien


Ajout du 14 sept 2012 : Je vous disais qu'un CAS pouvant simplifier les opérations de restauration... mais elle peut aussi les compliquer grandement.
Simplifier : parce que si un primaire ou un CAS tombe, l'autre site peut retransmettre des informations à l'autre site après la restauration. Pratique donc surtout si les sauvegardes sont espacées.
Compliquer grandement : Lors de la restauration d'un CAS, celui-ci passe en mode maintenance tant que TOUS les sites primaires ne sont disponibles. De son coté, lors de la restauration d'un site primaire, il fait indiquer le nom du serveur CAS et que celui-ci soit fonctionnel. Dans le cas (extrême mais possible) où il faudrait restaurer un CAS + un site primaire, la réinstallation de chaque site nécessitant que l'autre site soit opérationnel, l'affaire tourne à la réinstallation intégrale de l'infra :-(