Im Landkreis Kassel betreuen wir mit 12 Mitarbeitern die IT von insgesamt 72 Schulen (49 Grundschulen, 14 Gesamtschulen, 3 Gymnasien, 2 Berufsschulen und 4 Förderschulen) und rund 27.000 Benutzeraccounts (ca. 25.000 Schülerinnen und Schüler sowie 2.000 Lehrkräfte). Wir kümmern uns nicht nur um die Hardware (Server, PCs, iOS-Geräte usw.), das Netzwerk und die Telefonanlagen, sondern auch um die Betriebssysteme, die Software und die Mobilgeräteverwaltung.
In diesem Blogbeitrag möchte ich vorstellen, vor welchen Herausforderungen wir als flächenmäßig großer Kreis, mit vielen kleineren, verstreuten Gemeinden, gestanden haben, als es darum ging, den Einsatz mobiler Geräte an unseren Schulen möglich zu machen und gleichzeitig die Einführungs- und Supportaufwände überschaubar zu halten.
Ausgangssituation
Bevor wir uns für UCS@school entschieden haben, setzten die meisten Schulen des Landkreises auf eigene Lösungen. Viele Lehranstalten betrieben einen KSaN-Server (Kasseler Schulen Schüler ans Netz). Diese Linux-Rechner, Linux-Server, dienten als Firewall und DHCP-Server und integrierten dank Samba auch Windows-Geräte. Da das KSaN-Projekt im Frühjahr 2018 gekündigt wurde, mussten wir ein neues Konzept erarbeiten und realisieren.
Dieses sollte nach Möglichkeit auch ein weiteres Problem am bisherigen Setup beheben: Es gab keine zentrale Domäne mit Benutzerverwaltung, Gruppenrichtlinien und Rollenkonzepten sowie modulare Erweiterbarkeit. Wegen der unzureichenden Internetanbindung vieler Schulen implementierten die Lehranstalten häufig eigene Lösungen. Dabei kamen auch iPads zum Einsatz, welche die Schulen selbstständig beschafft und eingerichtet haben.
Auf den Apple-Geräten gab es keine Restriktionen und die Apps wurden über iTunes bezogen, was schnell die Grenze der Lizenzierung (begrenzte Anzahl von Geräten pro iTunes-Account) erreichte. Was aber vor allem fehlte: ein durchgängiges System zur Beschaffung und Verwaltung der mobilen Geräte. Erste Erfahrungen mit dem Apple-Profilmanager zeigten schnell, dass der Funktionsumfang für unsere Zwecke und für die Anzahl der eingesetzten iPads nicht ausreichte.
Anforderungen
Neben einer professionellen Wartung durch den Hersteller, standen vor allem diese Punkte auf der Liste unserer Anforderungen an eine neue Lösung: Linux als Basis, Funktionsumfang wie beim KSaN-Server (oder besser), modular erweiterbar, Unterstützung diverser Plattformen (iOS, Android, Windows und Linux), einfache Benutzung (z.B. über den Webbrowser) und Unterstützung von Rollenkonzepten und Gruppenrichtlinien.
Uns war darüber hinaus wichtig, dass wir vorhandene Thin Clients, Terminalserver und bereits verfügbare Serverhardware der Schulen weiterverwenden können, dass der Hersteller professionellen Service und Support anbietet und dass wir das System (mit möglichst wenig Aufwand) zentral pflegen können. Alle Benutzerdaten sollten auf den Servern des Landkreises verbleiben.
Und natürlich wollten wir eine MDM-Lösung (Mobile Device Management) etablieren, die sich gut in das System integrieren lässt. Dabei wollten wir die iPads zentral verwalten, diese aber gleichzeitig an die individuellen Bedürfnisse der jeweiligen Schulen anpassen. Und nicht zu vergessen natürlich die Erfüllung datenschutzrechtlicher Gesichtspunkte. Deshalb war es uns auch wichtig, dass wir eine MDM-Software auf unseren eigenen Servern betreiben und dass alles aus einer Hand ist.
UCS@school als Lösung
Wie mein Kollege Matthias Woede bereits in seinem Artikel „Aufbau einer zentral managebaren IT-Struktur mit Einbindung lokaler Schulserver im Landkreis Kassel – Vorbereitung ist alles!“ beschrieben hat, haben wir uns schließlich für UCS@school als zentrales Identity-Management entschieden. Uns gefällt vor allem die Kombination aus Zentralisierung (Betrieb und Verwaltung im Rechenzentrum in Hofgeismar), Dezentralisierung (einzelne Dienste wie DHCP, RADIUS und SAMBA (Fileserver können wir in den Schulen vor Ort anbieten). Es ist zudem leicht, weitere Dienste – darunter auch die gewünschte MDM-Lösung – anzubinden.
Unsere klare Präferenz war, eine MDM-Lösung aus dem Univention App Center zu nehmen, da hier eine einfache und tiefe Integration in das IDM von UCS gegeben ist. Im App Center stehen gleich mehrere unterschiedliche MDM-Systeme bereit. Wir haben uns schließlich für die Lösung Relution entschieden, da es neben einigen anderen Vorteilen vor allem die Möglichkeit bietet, die komplette Lösung im eigenen Rechenzentrum zu betreiben. Nach ein paar wenigen Anpassungen und einer kurzen Testphase konnten wir im Juli 2018 damit in den Produktivbetrieb gehen.
Zusammenspiel von UCS, Relution und Apple
Damit Sie besser verstehen, worauf es dabei ankam, möchte ich Ihnen das technische Zusammenspiel von UCS und Relution ein wenig detaillierter beschreiben. Wir betreiben einen virtuellen UCS-Server als Master und einen weiteren UCS-Server (ebenfalls virtuelle Maschinen). Auf einer der virtuellen Maschinen haben wir Relution installiert. Für die Anbindung an Apple haben wir die Firewall und das Routing angepasst: Jedes iPad meldet sich beim Apple-Server, um u.a. Updates einzuspielen und Push-Nachrichten zu erhalten. Die Schul-iPads werden dann an das zentrale MDM-System weitergeleitet, wozu wir diverse Ports öffnen mussten.
Als nächsten Schritt haben wir angefangen, die Geräte mit dem Device Enrollment Programm (DEP) von Apple zu verwalten. Zunächst haben wir die Beschaffungsrichtlinie neu aufgebaut. Der Landkreis ist nun der Besitzer der Geräte.
Relution ist mandantenfähig – das heißt, dass wir auf dem Relution-Server für jede Schule eine eigene Organisationseinheit (Mandant) eingerichtet haben, um so festlegen zu können, welche Apps und iPads zu welcher Lehranstalt gehören. Das macht gleichzeitig transparent, für wie viele iPads es noch freie Lizenzen für Apps und Relution-Lizenzen gibt.
Die iPads richten wir über vorher definierte Richtlinien ein. Neue Konfigurationen und Apps verteilt der Relution-Server per Push-Nachricht. Zusätzlich können wir zentral Einschränkungen vornehmen und beispielsweise bestimmen, dass Schüler keine Apps installieren oder löschen dürfen. Die Steuerung des Proxyservers und des WLAN Zugangs der Geräte erfolgt über das Managementsystem von UCS. Für die Bezeichnung der Server und PCs nutzen wir eine sehr einfache und nachvollziehbare Namenskonvention, die dem Muster „Gerät_Schule_Typ“ folgt.
Bandbreite schonen – Mac Minis als Caching Server in den Schulen
Um Bandbreite zu schonen, werden in den Schulen Mac Minis als Caching Server eingesetzt. So müssen die iPads ihre Updates nicht einzeln aus dem Internet saugen und die Internetanbindung blockieren. Stattdessen wird ein Update einmalig auf den Mac Mini heruntergeladen, der es dann im lokalen Netz der Schule verteilt.
Beschaffung der iPads über Device Enrollment Program (DEP) und kommunales Gebietsrechenzentrum
Wir haben ein Apple-School-Manager-Konto über unser kommunales Gebietsrechenzentrum Ecom21 eingerichtet, das ein eigenes Apple School Manager Konto bei dem zertifizierten Apple-Partner REDNET AG hat, über den wir die iPads und Lizenzen beziehen und der sie dem Landkreis zuweist (DEP, Device Enrollment Program). Die Lizenznummern werden zunächst dem DEP Konto zugeordnet und tauchen im Apple School Manager auf, der sie dann der jeweiligen Schule zuordnet. Bei der nächsten Anmeldung tauchen sie dann im Relution Server auf. Ein neues iPad zieht sich die Lizenznummer herunter, wenn es das erste Mal ans Netz geht. Vorteil von diesem Verfahren ist, dass Nutzer*innen nicht aus Versehen alle Einstellungen zurücksetzen können. Außerdem wird dadurch auch ein Diebstahl sinnlos, weil sich das Gerät immer wieder beim Authentifizierungsserver anmeldet und sich neu konfiguriert, wodurch eine außerschulische Nutzung nicht möglich ist.
Ausrollen neuer iPads an den Schulen – Schritt für Schritt effizient
Der Prozess bei uns im Landkreis Kassel für das Ausrollen neuer iPads erfolgt folgendermaßen: Zunächst erfragen wir bei jeder Schule deren Bedarf und klären die technischen Gegebenheiten vor Ort und die Wünsche der Schule für den Einsatz der Tablets in einem Gespräch: Ist Breitband und Schul-WLAN vorhanden oder müssen die Geräte offline betrieben werden, gibt es eine Firewall, muss ein Beschaffungsantrag gestellt werden…
Auf Basis dieser Informationen setzen wir dann einen festen Ablaufplan in Gang, zu dem u.a. das Abarbeiten einer bedarfsangepassten Checkliste gehört. Insgesamt können das bis zu 26 Schritte sein, bis der komplette Prozess von der Beschaffung bis zur Inbetriebnahme abgewickelt ist. Je nach dem, welche Voraussetzungen gegeben sind, kann das in nur wenigen Wochen abgewickelt werden. Diesen Ablaufplan optimieren wir momentan laufend und ergänzen weitere Prozessbeteiligte. Momentan sind zwei Personen im LK Kassel für die Anschaffung, Konfiguration und den Roll Out neuer und alter iPads zuständig.
Bei der Umstellung haben wir zuerst neue Geräte eingerichtet und erst danach die vorhandenen iPads umgestellt. Dafür mussten die alten Geräte vom Apple Profilmanager in den Relution-Server übernommen werden. Wir haben sie vor Ort eingesammelt und konfiguriert. Praktisch war dabei, dass die Konfiguration und Vorbereitung der vorhandenen iPads über den Configurator2 und Caching-Dienst auf einem MacMini erfolgen konnte.
Ausblick
Derzeit verwaltet Relution rund 510 Geräte, ca. 10 laufen noch mit dem Profilmanager – der Roll Out geht weiter.
Demnächst wollen wir den Relution-Shared-Devices-Modus einführen, der die bedenkenlose Nutzung der iPads durch mehrere Schüler*innen ermöglicht. Jeder Benutzer sieht nur seine eigenen Apps; lediglich die gerätespezifischen Konfigurationen gelten für alle.
Außerdem ist geplant, dass sich Benutzer mit ihren UCS-Zugangsdaten auf den iPads anmelden können. So müssen die Schüler*innen keine eigenen Apple-Accounts mehr anlegen und wir können auch im Bedarfsfall schauen, welcher Schüler das Gerät genutzt hat.
Last but not least, wollen wir das Einbinden von privaten Geräten von Lehrern und ggf. Schülern erleichtern (BYOD, Bring Your Own Device). Diese sollen Schullizenzen nutzen können, und die Anmeldung soll über QR-Codes laufen.
