Wenn man sich mit Administratoren über deren Arbeit und die alltäglichen Aufgaben unterhält, wird einem immer wieder bewusst, welch hoher Anteil hiervon selbst heute noch und auch in großen Unternehmen nach dem Prinzip der „Turnschuh-Administration“ erfolgt. Dabei muss das gar nicht sein, vieles lässt sich problemlos vom eigenen Arbeitsplatz bzw. zentral erledigen. Der System Center 2012 Configuration Manager ist dabei ein sehr hilfreiches und mächtiges Werkzeug, welches im folgenden Artikel näher vorgestellt werden soll.
Der System Center Configuration Manager hat bereits eine etwas längere Vorgeschichte, die allerdings oft unbekannt ist. So erschien bereits 1994 der erste „Microsoft Systems Management Server“, welcher damit quasi der Urvater des Configuration Manager ist. Von diesem gab es mehrere Versionen, bevor er 2007 in „System Center Configuration Manager“ umbenannt wurde. Der ursprüngliche Name bzw. dessen Abkürzung „SMS“ findet sich auch heute noch an vielen Stellen im aktuellen Produkt.
Als Mitglied der System-Center-2012-Familie muss der auch als „SCCM“ bezeichnete Configuration Manager in seiner neuesten Version nicht mehr separat erworben werden sondern ist ohnehin Bestandteil der Standard- oder Datacenter-Edition der System-Center-2012-Lizenz. Neben einem Microsoft SQL Server ab Version 2008 SP2 sind neben den Rollen und Features eines Windows Server 2008 bzw. Server 2008 R2 keine weiteren Produkte nötig.
Installation & Standorte
Die Installation des SCCM erfolgt in sogenannten „Sites“. Hiervon gibt es 3 Typen: Die CAS (Central Administration Site), die PS (Primary Site) und die SS (Secondary Site). Dabei hat man die Wahl, ob man entweder eine einzelne Primary-Site (stand-alone) installiert, oder eine größere Hierarchie bestehend aus allen 3 Site-Typen verwendet. Mit dem SP1 für den Configuration Manager wird es auch die Möglichkeit geben, diese Entscheidung nachträglich zu verändern. Die Verwendung mehrerer Sites bedingt zwingend den Aufbau einer Hierarchie (mindestens bestehend aus einer CAS und einer oder mehreren PS – wie bspw. in Abb. 1) und bietet sich vor allem dann an, wenn Clients und Server an mehreren Standorten verteilt sind und zwischen diesen Standorten nicht immer eine optimale Daten-Anbindung vorhanden ist, um die Anzahl der verwaltbaren Clients über 100.000 zu steigern oder Lastverteilung und Redundanz zu ermöglichen. Eine Hierarchie besteht an oberster Stelle immer genau aus einer CAS, der eine oder mehrere Primary Sites untergeordnet sind, denen wiederum Secondary Sites untergeordnet werden können. Diese Hierarchie lässt sich auch nachträglich um weitere Primary und Secondary Sites erweitern.
Abbildung 1: Eine einfach Hierarchie mit CAS und einer PS
Jede Site benötigt hierbei immer eine eigene SQL-Instanz, für die Secondary Sites ist auch eine Express-Version zulässig. Unterhalb der Primary Sites und Secondary Sites lassen sich auch unabhängig von der Installation einer kompletten Site sogenannte „Distribution Points“ (Verteilungspunkte) installieren. Diese fungieren dann sozusagen als „Datenhalde“ für den vom SCCM zu verteilenden Content wie z.B. Applikationen oder Betriebssystemabbilder. Dadurch kann sichergestellt werden, dass diese Daten bereits vor der eigentlichen Installation in den entsprechenden Niederlassungen vorhanden sind, ohne dass hierfür ein kompletter Server nebst SQL-Datenbank nötig ist. Bei Bedarf kann hierfür auch ein einfacher Windows-7-PC verwendet werden, solange dieser dauerhaft online ist. Dies bietet sich vor allem für kleine Niederlassungen an.
Erste Einrichtung
Vor der eigentlichen Installation ist eine Schema-Erweiterung im Active Directory nötig, außerdem müssen ein Container erstellt und für diesen Rechte delegiert werden. Nach der Installation beginnt die Einrichtung des Systems. Dabei sind anfangs insbesondere die als „Discoveries“ bezeichneten Erkennungsmethoden für die zu verwaltenden Server und Clients sowie die als „Boundaries“ bezeichneten Begrenzungen von Interesse. Es existieren sechs verschiedene Discovery-Varianten (siehe Abb. 2), jede mit unterschiedlichen Zielen und Vorteilen. Eine davon erkennt z.B. im AD gespeicherte Computer-Konten, eine andere ist in der Lage, DHCP-Server abzufragen. Außerdem dient die Erkennung dazu, Benutzerkonten aufzufinden, deren Relevanz in SCCM 2012 im Vergleich zum Vorgänger stark gestiegen ist. So ist es z.B. möglich, dass Benutzer festlegen, welches ihr primäres Arbeitsgerät ist, was wiederum bei der Softwareverteilung von Interesse sein kann.
Abbildung 2: Die verschiedenen Ermittlungsmethoden (Discoveries)
Die Begrenzungen haben den Zweck, zu definieren, in welchem Rahmen der SCCM tätig ist. Dabei sind AD-Sites, IPv4-Subnetze, IPv6-Präfixe sowie IP-Adressbereiche möglich, wie in Abb. 3 zu sehen.
Abbildung 3: Einige der zur Verfügung stehenden Grenzen
Ein weiterer Bereich, dem man schon von Beginn an eine gewisse Aufmerksamkeit schenken sollte sind die Sammlungen: Es lassen sich Gerätesammlungen und Benutzersammlungen anlegen. Diese Sammlungen sind dann später die Basis, wo bzw. an wen man z.B. Software verteilen will. Diese Sammlungen haben immer eine übergeordnete Sammlung, lassen sich dadurch also sehr gut in einer Art Hierarchie organisieren. Weiterhin kann man das Befüllen der Sammlungen automatisieren, um so z.B. per WMI das Betriebssystem der verwalteten Geräte auszulesen (siehe Abb. 4) und dann diese entsprechend des verwendeten Systems in entsprechende Gerätesammlungen einzusortieren oder nach verwendeter Hardware zu gruppieren.
Abbildung 4: Eine WMI-Abfrage für eine Gerätesammlung
Der Configuration Manager Client
Damit die Clients wie gewünscht mit dem SCCM kommunizieren und agieren können, ist im Allgemeinen das Vorhandensein des „Configuration Manager Clients“ auf den verwalteten Endgeräten notwendig. Dieser Client stellt eine Sammlung notwendiger Agents zur Verfügung, die dann die einzelnen Aufgaben auf den Maschinen ausführen bzw. die Kommunikation mit dem SCCM übernehmen. Dieser Client lässt sich auf verschiedene Weise auf den Endgeräten installieren, u.a. über die (automatisierbare) Push-Installation, via Software-Update, über Gruppenrichtlinien (GPO) oder auch über ein Startskript. Der Client stellt auch sicher, dass entsprechend gesetzte Einstellungen und Policies des SCCM auf den Clients umgesetzt werden.
Modularität durch Rollen
Nach dem Herstellen einer gewissen Grundkonfiguration lässt sich der SCCM nun mit den verschiedensten Rollen – auch „Points“ genannt – versehen. Einige davon sind in Abbildung 5 zu sehen. Dabei stehen die Rollen im Wesentlichen für die verschiedenen Möglichkeiten, die der Configuration Manager bietet.
Abbildung 5: Einige bereits installierte Rollen sowie die Möglichkeit, weitere Rollen zu installieren
Eine schnell und einfach installierte, aber in ihrer Wirkung recht große Rolle ist der „Endpoint Protection Point“. Dabei stellt Endpoint Protection eine zentral verwaltete und für die gewerbliche Verwendung freigegebene Version einer Schutzsoftware ähnlich der Security Essentials dar – also eine Suite zum Schutz der Clients vor Schadsoftware wie z.B. Viren und Würmer. Dabei kennt man dieses Produkt bereits schon etwas länger unter dem Namen „Forefront Endpoint Protection“. Aus der Oberfläche von System Center 2012 Configuration Manager lässt sich diese Software nun auf den gewünschten Clients und Servern im Unternehmen installieren, konfigurieren und betrieben werden. Der SCCM stellt hierzu vielfältige Werkzeuge für Management, Reporting, Alarmierung und natürlich Update Management bereit. Dabei lassen sich dann z.B. Updates und Scans für eine größere Gruppe von Endgeräten planen und verwalten, aber auch beispielsweise ein „on-demand Scan“ eines einzelnen Computers auslösen. Ebenso kann man hier auch verschiedenste Alarm-Meldungen konfigurieren, unter anderem für das gehäufte Auftreten einer speziellen Schadsoftware oder von Schadsoftware im Allgemeinen.
Abbildung 6: Der Endpoint-Protection-Client erinnert stark an den Windows Defender bzw. die Security Essentials
Der Application Catalog
Eine zweite Rolle, die eigentlich aus zwei Teilen besteht, ist der „Application Catalog“ (bestehend aus „Website Point“ und „Webservice Point“ – siehe Abb. 7). Dieser bietet die Möglichkeit, die Anwendungen, die dafür im SCCM entsprechend hinterlegt und aktiviert wurden, in einer Bibliothek zur Auswahl zu stellen. Die Mitarbeiter bekommen dadurch also die Möglichkeit, sich Anwendungen auf den PC zu installieren, die nicht Bestandteil der üblichen „Standardsoftware“ des Unternehmens sind. Dabei wäre denkbar, dass alle Mitarbeiter ein Office-Paket haben, aber eben nur die Mitarbeiter, die das möchten, ein Visio installiert bekommen. Dieser Katalog lässt sich mit einer Berechtigungs-Funktion versehen, die dafür sorgt, dass die Mitarbeiter die Installation eines gewünschten Produktes beantragen und ein Administrator dies dann entsprechend genehmigen muss (siehe Abb. 8). Natürlich kann man aber auch ohne diese Bibliotheks- oder Katalog-Funktion Software administratorgesteuert auf den verwalteten Maschinen installieren. Dazu muss die entsprechende Software ebenfalls im SCCM hinterlegt werden und kann dann auf Benutzersammlungen oder Gerätesammlungen zugewiesen werden. Damit lassen sich sehr leicht essentielle Softwarepakete unternehmensweit oder auch nur auf ausgewählte Bereiche ausrollen, beispielsweise ein Flash-Player, Java oder eben Office-Produkte.
Abbildung 7: Installation des Anwendungskataloges
Abbildung 8: Der Anwendungskatalog stellt dem Benutzer Programminstallationen zur Verfügung
Betriebssystem-Installation
Neben dem Deployment von einzelnen Anwendungen lassen sich mit dem SCCM, gestützt auf die „Microsoft Windows Deployment Services“ (WDS) und PXE, ganze Betriebssysteminstallationen durchführen. Dabei werden die gewünschten Betriebssysteme entweder als komplette Installation (quasi von der DVD) oder als WIM-Images (original oder auch angepasst) in SCCM hinterlegt und können dann im Rahmen von sogenannte Tasksequenzen (siehe Abb. 9) genutzt werden. Dabei stellen diese Tasksequenzen sehr einfach zu erstellende Listen von abzuarbeitenden Schritten dar. Diese sehen üblicherweise so aus, dass von einem angegebene Startabbild gestartet wird, die Festplatte partitioniert und formatiert wird, dann das entsprechende Betriebssystem angewendet wird und danach die weiter gewünschten Schritte abgearbeitet werden, zum Beispiel die Installation von Treibern, das Konfigurieren der Netzwerkeinstellungen inkl. Hostname und dem Domänenbeitritt, Installation weiterer Software oder einfach dem abarbeiten hinterlegter Skripte und Kommandos. Dadurch lassen sich fabrikneue PCs ohne größere Handarbeit direkt installieren. Der Aufwand für jeden einzelnen PC besteht dann im Idealfall nur noch im Anschließen der PCs und dem Anlegen der PCs in SCCM (am einfachsten über den Import via Liste). Der PC wird dann entsprechend vom SCCM mittels Wake-on-LAN gestartet, bootet via PXE vom Netzwerk und arbeitet die zugewiesene Tasksequenz ab.
Abbildung 9: Eine Tasksequenz für Betriebssystem-Deployment
Bei Bedarf können diese Tasksequenzen auch im „Application Catalog“ hinterlegt werden, um den Mitarbeitern selber die Möglichkeit zu geben, ihren PC neu installieren zu lassen. Diese Tasksequenzen müssen auch nicht immer zwingend bei der Formatierung einer Festplatte beginnen oder ein Betriebssystem installieren – man könnte u.a. auch „nur“ einzelne Konfigurationsschritte lokal auf den jeweiligen PCs abarbeiten lassen. Bei der Einführung einer neuen Betriebssystemversion kann durch die Einbindung des „User State Migration Tool“ (USMT) der Benutzerzustand gesichert und nach der Installation des neuen System zurückgespielt werden, analog zu einer händischen Migration.
Software Updates
Eine weitere sehr nützliche Rolle, welche sich auf den WSUS stützt, ist der „Software Update Point“. Mit diesem lassen sich Updates automatisch für die einzelnen Geräte bereitstellen. Das ist vom Prinzip nicht neu, greift hier allerdings zum einen direkt auf die bereits im SCCM angelegten Strukturen und Organisation, z.B. die Gerätesammlungen. Ausserdem kann durch die Verwendung eines SUP das Installieren von Updates direkt in den Prozess der Betriebssysteminstallation einbezogen werden und die im SCCM hinterlegten Betriebssystemabbilder können regelmäßig „offline gewartet“ werden, also mit den jeweils passenden Updates versehen werden, ohne dass diese Abbilder auf eine Maschine ausgerollt, gepacht und neu als Image aufgezeichnet werden müssen. Die SUPs stützen sich dabei auch auf die Architektur der SCCM-Umgebung und nutzen deren Verteilungsmechanismen. So bezieht beispielsweise die CAS die Updates direkt von den Microsoft-Servern, die Primary Sites werden von der CAS versorgt und die Secondary Sites wiederum von den ihnen übergeordneten Primary Sites.
Weitere Rollen
Weitere Rollen stellen beispielsweise ein umfangreiches Reporting zur Verfügung, dienen als Anlaufstelle für mobile Endgeräte oder bieten Unterstützung für das Out-of-Band-Management von entsprechend ausgerüsteten Clients (Intel AMT). Eine weitere sehr interessante Möglichkeit bietet „Asset Intelligence“. In Kombination mit dem „Hardware Inventory“ und dem Reporting kann man damit Fragen beantworten, welche Clients ein künftig einzuführendes Softwareprodukt nicht ausführen werden können und wo z.B. das Aufrüsten des Arbeitsspeichers nötig ist. Dazu können Systemanforderungen für diese Softwareprodukte formuliert und dann entsprechend ausgewertet werden. Ebenso ist es hier möglich, die Verwendung eines Softwareproduktes festzustellen. Zum einen kann überprüft werden, ob eine bestimmte Software installiert ist, um zu prüfen, ob die Anzahl der vorhandenen Lizenzen ausreicht, zum anderen lässt sich aber auch messen, welche Software wie oft und wie lange in einem definierten Zeitfenster eingesetzt wurde.
Remote-Zugriff
Zusätzlich zu den eher auf eine größere Anzahl von Clients bezogene Verwaltung bietet der SCCM den Administratoren die Möglichkeit, direkt über Remote-Tools an einem speziellen Client oder Server zu arbeiten. Neben den beiden klassischen Varianten „Remoteunterstützung“ und „Remotedesktop“ steht auch ein eigenes Protokoll zur Verfügung, bei dem der Administrator auf die Maschine zugreifen kann und der User weiterhin alles mitverfolgen kann, ohne dass hierfür der eher aufwändige Weg der Remoteunterstützung mit einer Einladung gegangen werden muss – und zwar direkt aus der SCCM-Konsole heraus.
Abbildung 10: Die Remotezugriff-Möglichkeiten
Rollenbasierte Administration
Bezüglich der Aufgabenverteilung im SCCM stellt die „Rollenbasierte Administration“ eine interessante und praktikable Möglichkeit dar, die einzelnen administrativen Aufgaben im Unternehmen zu definieren und den entsprechenden Benutzerkonten der Administratoren zuzuordnen. Damit kann man u.a. sicherstellen, dass jeder der Administratoren nur in seinem Arbeitsfeld tätig ist bzw. hier Änderungen vornehmen kann. Dazu sind bereits einige Rollen im System von Anfang an vorhanden, z.B. ein „Software Update Manager“ oder ein „Application Deployment Manager“, es können aber nach Bedarf weitere Rollen hinzugefügt werden (siehe Abbildung 11). Diesen werden dann in den jeweiligen Bereichen des SCCM die entsprechenden Rechte zugewiesen. Zusätzlich kann man über sogenannte „Scopes“ noch weiter einschränken, wer mit welchen Objekten, wie z.B. bestimmten Applikationen, Betriebssysteminstallationen oder Software-Updates arbeiten darf.
Abbildung 11: Ein Beispiel für eine Sicherheitsrolle
Zusammenfassung
Zusammenfassend lässt sich festhalten, dass der SCCM nach einer kurzen Aufbau- und Einarbeitungszeit die tägliche bzw. regelmäßige Administration und Wartung aller Clients und Server deutlich erleichtern kann. Dabei werden alle wesentlichen Facetten des „Lifecycle Management“ eines klassischen Clients in einem Unternehmen abgedeckt. Zusätzlich lässt sich der SCCM auch mit dem „System Center Operations Manager“ kombinieren, um eine Überwachung der Dienste und Aufgaben zu ermöglichen. Der modulare Aufbau des Configuration Manager bietet die Möglichkeit, dieses Produkt Schritt für Schritt einzuführen und zu nutzen, so dass man nicht gleich zu Beginn von der riesigen Funktionsvielfalt „erschlagen“ wird.
