In letzter Zeit fällt mir in Blogs, Foren, etc. auf, daß in vielen ConfigMgr 2012-Infrastrukturen eine CAS (Central Administration Site) zum Einsatz kommt. In vielen Fällen wäre dies aber gar nicht nötig gewesen. Eine der ConfigMgr 2012 Features – Vereinfachung der Hierarchie und entsprechend eine Reduktion der Anzahl der Site Systeme – ist damit leider nicht berücksichtigt worden.
Oftmals wird / wurde eine CAS installiert, weil man ja bei SCCM 2007 schon eine Central Site hatte. Diese Schlußfolgerung ist in den meisten Fällen aber falsch. Central Adminsitration Site (CM12) != Central Site (CM07).
Insgesamt gibt es nur wenige Gründe, wirklich eine CAS einzusetzen. Der wichtigste ist die Gesamtanzahl zu verwaltender Clients:
Eine standalone Primary Site kann bis zu 100.000 Clients verwalten. Eine CAS wird erst dann zwingend nötig, wenn man diese Anzahl überschreitet.
Oftmals wurde auch eine CAS nur “für den Fall der Fälle” installiert, falls man doch irgendwann, vielleicht einmal eine CAS brauchen sollte (Expansion der Firma, Zukauf einer weiteren, etc). Spätestens mit Service Pack (SP) 1 ist auch dieses Argument entkräftet. Bei RTM war es nicht möglich, eine bestehende Primary zu einer CAS hinzuzufügen. Mit SP1 hingegen kann eine bestehende Primary zu einer neuen CAS hinzugefügt werden.
Ansonsten sollte man sich gut überlegen, ob man nicht auch mit einer Standalone Primary Site auskommt. Neue Funktionen wie Secondary Sites (die bis zu 5.000 Clients unterstützen), sender-enabled Distribution Points, Pull-DPs (SP1) oder Branch Cache bieten viele interessante Möglichkeiten, die bei der Versorgung von entfernten Standorten unterstützen. Man spart sich dadurch Hardware, Kosten und Komplexität (SQL-Replikation / DRS (Data Replication Service).
Bei der Planung einer Hierarchie spielen sehr viele Faktoren eine Rolle, die natürlich alle untersucht werden müssen und den Rahmen eines einzigen Blog-Artikels sprengen. Dieser Artikel soll einfach als Anstoß dienen, den Einsatz einer CAS kritisch zu hinterfragen. Keep it simple!
Hallo,
ich hatte auch schon etliche Diskusionen bez. CAS, viele denken noch, man könnte damit eine administrative Trennung der Primary Sites erreichen (Mandantenfähigkeit). Das war zwar unter SCCM 2007 der Fall, allerdings nicht unter SCCM 2012. Dafür nutzt man das Rollenkonzept in Verbindung mit Security Scopes und Collections.
Schöne Grüße
JP
Leider nein. Einziger “Ausweg”, um die CAS loszuwerden: eine neue standalone Primary Site aufbauen und alles mit Migration Jobs von CM12SP1 zu CM12SP1 migrieren. Ob natürlich dann das Verhältnis zwischen Aufwand und Nutzen noch stimmt sei dahingestellt 😉
Vielen Dank für die Information. Endlich kann den Kunden empfohlen werden, dass mit SP1 auch zu einem späteren Zeitpunkt ein CAS eingerichtet werden kann.
Was ist mit den Kunden die bereits ein CAS unnötig aufgebaut haben. Kann dieser einfach abgeschaltet werden?
Danke