UCS@school in den Schulen der Stadt Frankfurt (Oder) – ein Bericht über zehn Jahre Erfahrung

In zwei Artikeln möchten wir Ihnen berichten, warum und wie wir in Frankfurt (Oder) die komplette IT-Infrastruktur der 16 in Trägerschaft der Stadt befindlichen Schulen modernisiert haben.

In diesem ersten Teil erfahren Sie, vor welchen Herausforderungen wir standen, unter welchen Prämissen wir welche Anforderungen formuliert haben und wie wir von Anfang an die Schulen als wichtige Stakeholder ins Boot geholt und so große Akzeptanz und Unterstützung erreicht haben. In einem zweiten Artikel, der in ein bis zwei Wochen folgen wird, gehen wir auf die konkrete Umsetzung, den Projektverlauf und technischen Details zur Server-Infrastruktur sowie unser Mobile-Device-Konzept ein. Und wir erläutern, warum wir uns beim Deployment für die Clients an den Schulen für eine selbst entwickelte Lösung entschieden haben. Und zu guter Letzt möchten wir Sie an unseren Erkenntnissen teilhaben lassen, was unserer Meinung die wichtigsten Gelingensbedingungen für so große IT-Projekte wie bei uns in Frankfurt (Oder) sind.

Start des Projekts (aus der Not heraus)

Im Jahr 2008 erkannte man bei den in Trägerschaft der Stadt befindlichen Schulen, dass sowohl die Ausstattung mit Computer-Systemen und der Infrastruktur als auch die für den IT-Service im Schulbetrieb notwendigen personellen Ressourcen unzureichend waren. So ergab eine erste Bestandsaufnahme, dass 78 % der im Unterricht eingesetzten PC-Systeme schon länger als zehn Jahre betrieben wurden. Trotz großer Anstrengungen der für den Service verantwortlichen zwei Kollegen waren die meisten Schulen auf sich allein gestellt, wenn es um Service und Störungsbeseitigung ging. Auch war es nicht möglich, die Benutzerverwaltung und das System-Management von zentraler Stelle aus zu betreiben. Sofern vorhanden wurden ausschließlich dedizierte Server eingesetzt, die nicht selten eigentlich nur Desktop-Systeme waren und die vorhandenen Netzwerke waren absolut unzureichend.

Offenkundig gab es gute Gründe, um über eine Neuaufstellung der IT-Struktur und des Servicebetriebs nachzudenken. So entstand eine Art Katalog, in dem alle Anforderungen zunächst wertneutral formuliert wurden. Im Kern wurden folgende Ziele definiert:

• Die IT-Infrastruktur sollte an allen Schulen, unabhängig vom Schultyp und von der Schulgröße, vereinheitlicht (standardisiert) werden.
• Alle administrativen Tätigkeiten (Benutzerverwaltung, Netzwerke, Endsysteme, netzwerkrelevante Dienste usw.) sollten von zentraler Stelle aus ausführbar sein.
• Die Schulen sollten selbst bestimmen können, welche Betriebssysteme auf den Endsystemen zum Einsatz kommen sofern diese Systeme „domänenfähig“ wären.
• Erhebliche Teile der Serversysteme sollten virtualisiert werden (dedizierte Server sollen vermieden werden).
• Die notwendige Trennung verschiedener Netzwerkbereiche (z. B. Edukativnetz und Schulverwaltungsnetz) sollte auf Basis von VLAN-Strukturen erfolgen.
• Das Gesamtkonzept sollte hinsichtlich der Funktionalität und der Mengengerüste erweiterbar sein.
• Serverstruktur und zentrale Dienste für die Infrastruktur sollten vereinheitlicht werden, d. h. es sollten keine unterschiedlichen Implementierungen von Domänen-Controllern (Samba, Windows usw.) zum Einsatz kommen, keine unterschiedlichen VPN-Lösungen zur Standortvernetzung und unterschiedlichen Firewall Router eingesetzt werden. Und es sollte nur eine Variante der Server-Virtualisierung angewendet werden.
• Open-Source-Lösungen sollten proprietären Produkten bei vergleichbarer Leistungsfähigkeit bevorzugt werden.
• Das gesamte System sollte überschaubar und beherrschbar sein, d. h. einerseits sollte durch Standardisierung erreicht werden, dass alle Schulen die gleiche Grundstruktur haben unabhängig vom Schultyp und den für den schulischen Einsatz vorgesehenen Stückzahlen der Endsysteme; andererseits sollten die mit dem Service beauftragten Kolleg*innen ihre Support-Aufgaben gut erfüllen können.

Die Liste zeigt, dass zur Umsetzung in vielerlei Hinsicht tiefgreifende Änderungen erforderlich sein würden, die für alle Beteiligten eine Herausforderung darstellten. Im Grunde genommen wurde die IT-Struktur ohne Tabus in technischer und organisatorischer Hinsicht faktisch neu gedacht.

Bei der anschließenden Entwicklung einer Vision und eines Konzepts wurden durch Analyse und Produktvergleiche Anforderungen laufend konkretisiert.

Strategisch erfolgreich auch durch sorgfältige Produktauswahl

Z. B. waren sich alle Beteiligten darin einig, dass serverseitig möglichst viel virtualisiert werden sollte, woraus ein konkreter Arbeitsauftrag abgeleitet wurde, um eine Entscheidungshilfe hinsichtlich der Produktauswahl zu erstellen. Schließlich wurde im Ergebnis eines Variantenvergleichs die Entscheidung getroffen, dass als Virtualisierungslösung ausschließlich das Produkt VMware ESXi angewendet werden sollte.
In ähnlicher Weise wurde die Entscheidung getroffen, dass als Firewall Router das Produkt pfSense zum Einsatz kommen sollte.

Deutlich schwieriger hat sich die Produktauswahl der Schulserver-Lösung gestaltet. Es wurden unterschiedlichste Lösungen betrachtet, einige davon auch testweise installiert.

Wir haben dabei Eigenschaften wie Administrierbarkeit, pädagogisch relevante Funktionen, Skalierbarkeit, TCO (unter Beachtung von Lizenzgebühren, Folgekosten, Support-Kosten, Maintenance-Kosten, technischen Voraussetzungen), Qualität der Dokumentation, Interoperabilität mit den unterschiedlichen Endsystemen usw. untersucht.

Schließlich stellte die Firma Univention auf dem Linuxtag in Berlin (24. bis 27. Juni 2009) das Produkt UCS mit der Erweiterung UCS@school vor. Das erste Release war für September 2009 angekündigt. UCS mit der Erweiterung UCS@school schien unsere Anforderungen zu annähernd 100 % zu erfüllen.

• Unterstützung aller domänenfähigen und marktrelevanten Betriebssysteme für die Clients (Endsysteme)
• Skalierbarkeit (zum damaligen Zeitpunkt wurden ca. 140 Schulen in Bremen darauf betrieben)
• Beim Einsatz als Multi-Server-Lösung ein zentrales Management wichtiger Objekte wie Netzwerke, Endsysteme aber auch eine zentrale Benutzerverwaltung
• Leichte Administrierbarkeit durch ein Webinterface, das fast alle Funktionen unterstützt
• Import von Informationen für Endsysteme, Netzwerke und Benutzer
• Eine aussagekräftige und vollständige Dokumentation in deutscher Sprache
• Deutschsprachiger Support
• Ein transparentes Preismodell für Maintenance und Support (kalkulierbare Folgekosten ohne „böse Überraschungen“)
• Installation durch erfahrene Administratoren auf Basis der verfügbaren Checklisten und der Handbücher und ohne Hilfe des Herstellers
• Relativ geringer Ressourcenbedarf im Vergleich zu anderen Lösungen

Deshalb haben wir die Pilotierung in einem Computerkabinett in einer Schule gestartet, um zu überprüfen, ob die Lösung auch den Anforderungen des praktischen Schulbetriebes gewachsen wäre und durch die Schüler*innen sowie Lehrkräfte akzeptiert würde und damit einen praxisnahen „Proof of Concept“ gemacht.

Schlussfolgerungen auf Basis der Evaluation

Nach mehrwöchigem Probebetrieb gab es folgende Erkenntnisse:

1. Die durch UCS und die Komponente UCS@school bereitgestellte Infrastruktur (Netzwerkdienste, Benutzerverwaltung usw.) entsprachen unseren Erwartungen und Anforderungen.
2. Der damals von Univention bereitgestellte Linux-Client Univention Corporate Desktop (Debian-basiert wie UCS) war nur bedingt für den Schulbetrieb geeignet. Das hatte unter anderem seine Ursache darin, dass viele Softwarepakete aus dem Original Debian Repository nicht benutzbar bzw. nicht installierbar waren (so mussten Pakete wie z. B. die Turbo-Pascal-IDE Lazarus aufwändig neu paketiert werden).
3. Die Änderung des Zugangspasswortes der Nutzer musste im Web Frontend des Servers vorgenommen werden.
4. Die Implementierung der skriptgesteuerten Installation (unattendet Setup) von Microsoft-Windows-Systemen hat nicht zuverlässig funktioniert und war faktisch mit vertretbarem Aufwand nicht handhabbar.

Dennoch blieben die bereits erwähnten Vorteile. Der Probebetrieb konnte erfolgreich abgeschlossen werden und damit die Entscheidung zum Rollout der Lösung in allen Bildungseinrichtungen, die sich in Trägerschaft der Stadt Frankfurt (Oder) befinden, getroffen werden.

Weitere erforderliche Schritte vor dem Rollout

In mehreren Veranstaltungen haben wir den Schulleitungen und den schulinternen Administratoren (PONKS) das Konzept und die notwendigen Änderungen des IT-Betriebes an den Schulen vorgestellt.

Die Schulen wurden ermutigt, Vorschläge in diesem Kontext einzubringen. Denn jedes Team, das bereits erfolgreich IT-Projekte ausgeführt hat, weiß, dass ohne Akzeptanz der Anwender die Gefahr des Scheiterns besteht. Je mehr sich die Anwender „mitgenommen“ und einbezogen fühlen, um so mehr wird das Projekt zu ihrem „eigenen Baby“.
Ein weiteres Thema dieser Veranstaltungen war die Medienentwicklungspläne und die darin enthaltenen medienpädagogischen Konzepte mit dem schulübergreifenden Gesamtkonzept zu vereinbaren. Die freie Wahl der einzusetzenden Betriebssysteme und Anwendungssoftware durch die Schulen führte bereits im Vorfeld zu einer hohen Akzeptanz der Gesamtlösung durch die künftigen Anwender.

Handreichungen für Entscheider

Durch das Projektteam wurden anschließend zwei entscheidende Dokumente erarbeitet, die durch den Schulträger bestätigt wurden:

1. Das Betriebskonzept

Das Betriebskonzept beschrieb die Organisation des Betriebs sämtlicher Komponenten der IT-Infrastruktur w. z. B. die Aufgabenverteilung im Betrieb und bei der Bearbeitung von Störungen zwischen den sog. PONK (Pädagogisch Organisatorischer Netzwerkkoordinator), dem IT-Service und dem Schulträger zugeordnet sind.

Nach Zustimmung der Beteiligten wurde das Konzept auch dem Bildungsausschuss der Stadtverordnetenversammlung als Beschluss vorgelegt und beschlossen. Dadurch wurde erstmals für alle eine belastbare Festlegung über die Aufgabenverteilung getroffen.

Das Betriebskonzept war auch wichtig für die anstehende öffentliche Ausschreibung für den IT-Service für die Schulen, weil es den Kernbestandteil des Leistungsverzeichnisses umfasst.

2. Das technische Konzept

Das technische Konzept wurde erstellt, um die Rahmenbedingungen für den Aufbau der IT-Ausstattung in den Schulen und deren zentrale Verwaltung zu definieren. Dabei wurde darauf geachtet, dass diese Rahmenbedingungen der jeweiligen Schule ermöglicht, ihr medienpädagogisches Konzept umzusetzen.

Durch den Schulträger wurde kein Einfluss darauf genommen, welche Software im Unterricht eingesetzt wird. Allerdings wurde darauf geachtet, dass das jeweilige Softwareportfolio (der sogenannte „Warenkorb“) nicht unnötig „ausufert“. Z. B. waren verschiedene Tipptrainer-Programme im Einsatz. Deshalb wurde festgelegt, dass eins dieser Programme Bestandteil des „Warenkorbs“ werden soll. Die übrigen Programme waren deshalb nicht verboten, sondern lediglich der Support war eingeschränkt. Auch dadurch wurde Akzeptanz bei den Schulen geschaffen.

Aus vielerlei Gründen wurde Open Source Software bei vergleichbarer Leistungsfähigkeit bevorzugt. Das hatte teilweise technische Gründe, da die zur Zeit des Projektstarts eingesetzte Hardware , die zu großen Teilen älter als zehn Jahre war, aktuelle Windows-Systeme nicht zuließ.

Weitere Gründe waren die Kosten und Folgekosten für den Schulträger. Außerdem gab es auch soziale Gründe. In der Stadt Frankfurt (Oder) ist, wie im Bundesland Brandenburg, der Anteil von leistungsbeziehenden Haushalten überdurchschnittlich hoch. Bei einkommensschwachen Familien kann der Einsatz von Open Source Software ein sinnstiftender Beitrag sein, um Teilhabe an Bildung zu ermöglichen oder zu erleichtern. Auch aus diesem Grund erklärte die Schulleiterin einer Schule mit Gymnasialer Oberstufe (GOST) ihre Schule zur „Microsoft freien Zone“. Das wurde von vielen Beteiligten als sehr mutig angesehen. Heute wissen wir, dass es realisiert wurde, nicht nur in einer Schule sondern in vielen Schulen in der Stadt Frankfurt (Oder).

Bei der Wahl von Linux als Betriebssystem für Schüler*innen wurde noch ein weiterer Aspekt betrachtet. Die Mehrzahl der PC-Systeme werden in der alltäglichen Praxis benutzt, um im Internet zu surfen, E-Mails zu lesen und zu schreiben sowie Kalkulationstabellen, Dokumente und Präsentationen zu erstellen. Anwendungsprogramme, die auf mehreren, marktrelevanten Plattformen (Windows, MacOS und Linux) verfügbar sind und die genannten Tätigkeiten am PC unterstützen, sind deshalb von besonderem Interesse. Bemerkenswert ist, dass viele Open-Source-Programme diese Anforderungen erfüllen, wie zum Beispiel LibreOffice, Mozilla Firefox und Thunderbird.

Serverseitig wurde entschieden, dass möglichst keine dedizierte Hardware für einzelne Server eingesetzt werden sollte. Dadurch konnten erhebliche Kosteneinsparungen bei Hardware und Betrieb (Energie, Management, etc.) erzielt und gleichzeitig die Verfügbarkeit signifikant gesteigert werden.

Die Stadt Frankfurt (Oder) hat sich dazu entschlossen, eine Ausschreibung der IT-Dienstleistungen für den IT-Service in den Schulen durchzuführen, um einen externen Dienstleister mit dieser Aufgabe zu beauftragen. Eine durch die Stadt angestellte Kraft sollte die Aufgaben des IT-Services koordinieren. Mit dem Betriebskonzept und dessen Bestätigung durch den zuständigen Bildungsausschuss war auch die Grundlage für eine Ausschreibung des IT-Services gelegt, da das Betriebskonzept wesentlicher Bestandteil des für die Ausschreibung notwendigen Leistungsverzeichnisses war.

In einem weiteren Artikel berichten wir Ihnen in Kürze über die konkrete Umsetzungsphase. Beschäftigt haben uns dabei die Implementierung verschiedener Server-Rollen, ein virtuelles Konzept und das Deployment-Verfahren beim Ausrollen der Systeme. Und wir erklären, warum wir uns für die Einführung von Linux Clients entschieden haben.