Migrationsleitfaden - IT-Beauftragter der Bundesregierung

Transcription

Migrationsleitfaden
Version 3.0
Leitfaden für die
Migration von Software
Publikation des Bundesministerium des Innern
April 2008
Publikation des Bundesministerium des Innern
Nachdruck, auch auszugsweise, ist genehmigungspflichtig
Interessenten erhalten die derzeit lieferbaren Veröffentlichungen
des Bundesministerium des Innern
und weiterführende Informationen zu den Dokumenten beim
Bundesministerium des Innern
Referat IT 2
11014 Berlin
Homepage: http://www.kbst.bund.de/
E-Mail: IT2@bmi.bund.de
Migrationsleitfaden
Version 3.0
Leitfaden für die
Migration von Software
1. Auflage
Berlin, April 2008
Herausgegeben vom
Bundesministerium des Innern
Vorwort zur dritten Version des Migrationsleitfadens
Der Migrationsleitfaden hat sich als praxisrelevantes, konkret anwendbares Werkzeug zu
vielschichtigen Migrationsfragestellungen etabliert und ist in der Bundesverwaltung und
darüber hinaus akzeptiert und hoch geschätzt. Das Dokument bietet IT-Entscheidern
neben reichhaltigen technischen Informationen zu proprietärer und Open Source Software eine praktische Hilfe für die Planung und Durchführung von Softwaremigrationen in
verschiedenste Richtungen.
Aufgrund der immer kürzer werdenden Innovationszyklen der Technik wird nun mit dem
Migrationsleitfaden 3.0 eine inhaltlich aktuelle Fassung bezüglich der derzeit und in den
kommenden Jahren in Migrationsprojekten anzutreffenden Technologien vorgelegt. Bewährte Elemente der Vorgängerversionen, wie beispielsweise den praktischen Hinweisen zum Vorgehen bei Wirtschaftlichkeitsbetrachtungen und den rechtlichen Rahmenbedingungen, in denen sich Softwaremigrationsprojekte bewegen, werden in der Version
3.0 in aktualisierter Form fortgeführt.
Die wesentliche Neuerung des Migrationsleitfaden 3.0 gegenüber seinen Vorgängerversionen besteht in Form eines komplett überarbeiteten Strukturkonzeptes mit stärker ausgeprägter Modularisierung. Der Nutzwert des Dokumentes wird insbesondere durch dieses Element gesteigert, da es die Zuordnung der Fragestellungen der Leserinnen und
Leser zu den Dokumenteninhalten vereinfacht.
Die modularisierte Dokumentenstruktur bildet auch die Basis für eine einfachere Aktualisierung der einzelnen Dokumenteninhalte. Kürzere Veröffentlichungszyklen werden zukünftig einfacher umsetzbar. Zudem markiert die Einführung der neuen Dokumentenstruktur einen wichtigen Meilenstein auf dem Weg zu einer neuen Publikationsform des
Migrationsleitfadens als interaktives Web-Angebot.
Die Autoren wünschen den Leserinnen und Lesern des Migrationsleitfadens eine anregende und gewinnbringende Lektüre sowie die gewinnbringende Anwendung der skizzierten Lösungsszenarien in der täglichen Arbeitspraxis.
Seite 4
Aufbau und Inhalt des Migrationsleitfadens
Behörden und Organisationen stehen wiederholt vor der Entscheidung, wie sie ihre ITSystemlandschaften zukünftig entwickeln wollen. Die Gründe dafür sind vielfältig:

Auslaufender Hersteller-Support für wesentliche Produkte

Erweiterte technische Anforderungen

Konsolidierung der bestehenden Systemlandschaften

Strategische Ziele, wie beispielsweise verstärkte Herstellerunabhängigkeit und
erhöhte Interoperabilität.
Ihnen stellt sich somit aktuell die Frage, welche Systeme und Komponenten zukünftig
die Basis ihrer IT-Struktur bilden sollen. Der Migrationsleitfaden will ihnen dabei durch
seinen strukturellen und modularen Aufbau sowie durch seine Inhalte eine Hilfestellung
geben.
Änderungen gegenüber der Version 2.0
Die erste Fassung des Migrationsleitfadens wurde in der Version 1.0 im Jahr 2003 veröffentlicht. Dieses Dokument wurde über 100.000 Mal aus dem Netz herunter geladen und
in mehrere Sprachen übersetzt.
Im Jahr 2005 wurde die Version 1.0 durch eine Fortschreibung des Dokumentes auf die
Version 2.0 aktualisiert. Die auf diesem Dokument aufbauende, zuletzt veröffentlichte
Version 2.1 beinhaltete gegenüber ihrer Vorgängerversion bereits Ausführungen und
praktische Tipps zu Wirtschaftlichkeitsbetrachtungen und rechtlichen Aspekten geplanter
Software-Migrationen.
Mit dem Migrationsleitfaden 3.0 legt die KBSt nun eine komplett überarbeitete und aktualisierte Fassung mit stärker ausgeprägter Modularisierung der technischen Themen vor.
Darüber hinaus wurden vor allem weitere Produkte und Technologien aufgenommen,
zum Beispiel der Themenbereich Teaming- und Workgroupsoftware (Collaborationsoftware) mit den Produkten „Microsoft Office SharePoint Server―, „O3Spaces Work-place
2―, „Novell Teaming + Conferencing―, „Lotus Quickr 8.0― und die Open Source Software
„Mindquarry―.
Aufbau des Migrationsleitfadens
Eingebettet in ein Rahmenkapitel enthält der Migrationsleitfaden 3.0 die drei Kernmodule
Querschnittsthemen, Infrastrukturen und Anwendungen. Diese Module markieren in der
Arbeitspraxis klar voneinander abgrenzbare Themengebiete mit spezifischen Aufgabenstellungen.
Um den Leserinnen und Lesern eine klare Orientierung im Dokument zu ermöglichen,
werden die drei Kernmodule mit einer einheitlichen Untergliederung ausgestattet. Diese
enthält die fünf Ebenen:

Modul,

Themen,
Seite 5

Produkte,

Migrationspfade und

Bezüge.
Entlang dieser Untergliederung entsteht ein einheitlicher Strukturrahmen für alle Kernmodule, der es den Leserinnen und Lesern ermöglicht, Problemstellungen auf stets
gleich bleibenden Pfaden zu lösen. Diese Struktur ist in der nachfolgenden Grafik dargestellt.
Nutzung durch
Anwender
Beispiel:
Migration DBMS
• In welchem
Umfeld habe
ich ein
Problem?
Modul
• Zu welchem
Thema gehört
mein Problem?
• Datenbanken
Themen
• Welche
Produkte sind
betroffen?
• Welcher
Migrationspfad
hilft mir?
• Infrastruktur
Produkte /
Technologien
Migrationspfade
• Was muss ich
sonst noch
beachten?
Bezüge
• MySQL
• PostgreSQL
• SQL-Server
• z.B. SQL-Server
nach
PostgreSQL
• z.B. Datenquellen in
Office-Anwendungen
Abbildung 1: Struktur des Migrationsleitfaden
In der Grafik sind die Fragen des sich orientierenden Lesers den Bezugspunkten des
Dokumentes auf dessen inhaltlichen Ebenen zugeordnet. So wird ein Leser, der beispielsweise die Migration eines Datenbankmanagementsystems plant, die Problemlösung auf dem in der Grafik skizzierten Pfad durch die Dokumentenstruktur finden. Sucht
derselbe Leser nach einer anderen Problemlösung, beispielsweise in einem Thema des
Moduls Anwendungen, so wird er zu dieser unter Verwendung desselben strukturellen
Pfades durch das Dokument gelangen.
Das Modul Querschnittsthemen weicht von dieser vorgegebenen Struktur ab, da hier
innerhalb des Moduls nur noch eine Unterteilung nach Themen erfolgt.
Inhalt des Migrationsleitfadens
Der Migrationsleitfaden beschäftigt sich inhaltlich mit der Migration von Software. Nach
wie vor liegt bei den technischen Betrachtungen aktuell der Fokus auf den Basissoftwarekomponenten von IT-Infrastrukturen. Der Migrationsleitfaden hat aber den Anspruch, zukünftig alle für die Verwaltung relevanten Softwarekomponenten in seine Betrachtungen einzubeziehen. Diese Zielsetzung wird durch die oben beschriebene neue
Seite 6
Struktur und stärkere Modularisierung unterstützt, sie ermöglicht eine effiziente Erweiterung beziehungsweise Anpassung der Inhalte des Leitfadens an die Bedürfnisse der
öffentlichen Verwaltung.
Innerhalb der Kernmodule „Infrastrukturen― und „Anwendungen― betrachtet der Leitfaden,
untergliedert nach Themen, wie zum Beispiel Netzwerkdienste oder Datenbankmanagementsysteme, zunächst die einzelnen Produkte und Technologien hinsichtlich
ihres technischen Aufbaus und der technischen Besonderheiten sowie ihrer Funktionalitäten. Darüber hinaus wird auch ein Blick auf die bisherige Entwicklung, die Verfügbarkeit unterschiedlicher Versionen und Editionen sowie der Lizenzbedingungen, unter
denen die Produkte und Technologien eingesetzt werden können, geworfen. Betrachtet
wird dabei proprietäre und Open Source Software in gleichem Maße.
Definition:
Open Source Software, Free Software, Freie Software
Die Begriffe „Open Source Software“ und „Free Software“ oder „Freie Software“ werden innerhalb dieses Migrationsleitfadens synonym angewendet. Im Rahmen des Leitfadens wird
hierfür die Abkürzung OSS eingesetzt.
OSS erlaubt es jedem, den frei verfügbaren Quellcode zu nutzen, zu analysieren, zu modifizieren und zu verbreiten. Diese Offenheit gibt den Nutzern die Möglichkeit, aus dem Quellcode selbst zu lernen beziehungsweise ihn an die persönlichen Bedürfnisse anzupassen.
OSS ist frei von Lizenzkosten und darf auch in modifizierter Form kopiert und weitergegeben werden. Die Freiheit der Software wird durch die entsprechenden Lizenzen geregelt.
Proprietäre Software
Im Gegensatz zu Open Source Software ist proprietäre Software das Eigentum einer Person oder einer Organisation. In der Regel handelt es sich dabei um den Hersteller der Software. Die Nutzung der Software unterliegt den Lizenzbestimmungen, die der Eigentümer
der Software festgelegt hat. Dabei ist ihre Vervielfältigung, Weiterverbreitung und Modifizierung meist untersagt.
Unter der Voraussetzung, dass die entsprechenden Lizenzbedingungen akzeptiert werden,
wird sie in einigen Fällen auch kostenlos angeboten. Diese Software ist jedoch keine Open
Source Software.
Im Anschluss an die Produkt- und Technologiebetrachtung erfolgt innerhalb jedes
Themenblockes die Betrachtung ausgewählter Migrationspfade. Zum Zeitpunkt der
Veröffentlichung der ersten Version des Migrationsleitfadens im Jahre 2003 bestand
hinsichtlich der Ausgangssituation der IT-Infrastrukturen bei den Behörden ein relativ
homogenes Bild. Dieses hat sich in den letzten Jahren deutlich gewandelt. Zwar werden
immer noch überwiegend Windows-basierte IT-Infrastrukturen betrieben, aber selbst hier
gibt es sehr unterschiedliche Ausgangslagen. Daneben haben sich die unterschiedlichsten Linux-basierten und auch heterogenen IT-Landschaften entwickelt.
Diese zunehmende Heterogenität der IT-Landschaften führt dazu, dass differenziertere
Möglichkeiten zur Migration bestehen und beschrieben werden müssen. Es wird unterschieden zwischen den ablösenden und den fortführenden Migrationspfaden.
Seite 7
Definition
Fortführende Migration
In den bisherigen Versionen des Migrationsleitfadens wurde dieser Begriff aufgrund der damals in den Behörden vorliegenden, weitgehend einheitlichen Ausgangslage (Windows NT
basierte IT-Infrastrukturen) in erster Linie mit der Fortführung der Produktlinien von Microsoft verbunden. Heute gibt es sehr unterschiedliche Ausgangslagen, deshalb wird unter
„Fortführende Migration“ die Fortführung einer bestehenden Produktlinie beziehungsweise
eines bestehenden Produktes, also zum Beispiel die Migration von StarOffice 7 nach StarOffice 8 oder die Migration von MS Office 2003 nach MS Office 2007 verstanden.
Ablösende Migration
Dementsprechend handelt es sich bei einer ablösenden Migration um die Ablösung einer
bestehenden Produktlinie oder eines Produktes durch eine andere Produktlinie oder ein
anderes Produkt. Dies kann zum Beispiel die Ablösung von StarOffice 7 durch MS Office
2007 oder MS Office XP durch OpenOffice.org 2.3 oder auch die Ablösung der Groupware
Scalix durch Kolab sein.
Als mögliche ablösende Pfade kommen in Betracht:

Ablösung einer proprietären Lösung durch eine OSS-Lösung

Ablösung einer proprietären Lösung durch eine andere proprietäre Lösung

Ablösung einer OSS-Lösung durch eine proprietäre Lösung

Ablösung einer OSS-Lösung durch eine andere OSS-Lösung
Und bei den fortführenden Pfaden gibt es folgende Möglichkeiten:

Fortführung einer proprietären Lösung

Fortführung einer OSS-Lösung
Die Erfahrungen der Vergangenheit haben gezeigt, dass Migrationen sowohl in die eine
als auch in die andere Richtung technisch machbar sind. Insbesondere das Vorurteil,
dass nur mit proprietärer Software sinnvolle Wege beschritten werden können, wurde in
vielen Migrationsprojekten und an unzähligen Stellen im betrieblichen Einsatz widerlegt.
Die Praxis macht auch deutlich, dass unter entsprechenden Randbedingungen im Einzelfall auch heterogene IT-Umgebungen durchaus wirtschaftlich, bedarfs- und praxisgerecht sein können. Diese praktischen Erfahrungen belegen, dass bei punktuellen Migrationen oder Migrationen in Teilbereichen durchaus darüber nachgedacht werden darf,
ablösende Migrationspfade zu beschreiten, auch wenn dadurch Heterogenität in der ITLandschaft geschaffen oder gegebenenfalls verstärkt wird. Eine wichtige inhaltliche Frage, die sich hierbei ebenfalls häufig stellt, lautet: „Welcher Grad an Integration wird benötigt und lässt sich dieser auch in einer heterogenen Umgebung realisieren?― Das heißt,
lassen sich die Funktionalitäten, die nur durch ein bestimmtes Maß an Integration bereitgestellt werden können, auch in einer heterogenen Umgebung bereitstellen. Das Thema
Integration wird im Abschnitt I.A 3 näher betrachtet.
Seite 8
Letztendlich hängt die Wahl der Migrationspfade und die Gesamtausrichtung einer ITLandschaft von den Anforderungen und den Rahmenbedingungen einer Organisation,
einer Behörde ab. Diese sind in der Regel aber innerhalb jeder Behörde sehr unterschiedlich ausgeprägt. Es liegen sehr unterschiedliche Ausgangslagen vor, auch auf den
Grad der Heterogenität einer IT-Umgebung bezogen. Die Anforderungen hängen sehr
stark von den jeweiligen Aufgaben ab, Know-how, Anzahl des verfügbaren Personals
differieren und die finanziellen Ressourcen sind sehr unterschiedlich ausgeprägt. Daher
wird im Migrationsleitfaden auf die Betrachtung von Migrationen gesamter IT-Infrastrukturen verzichtet.
Grundsätzliche Unterschiede gibt es bei den einzelnen Pfaden nicht zu beachten. Die
Machbarkeit ist in der Regel gegeben, es sei denn, dass für den einen oder anderen
Pfad ein geeignetes Migrationsziel (Produkt oder Technologie) fehlt. Dies kann folgende
Ursachen haben:

Fehlen von Alternativen für eine fortführende oder ablösende Migration:
In bestimmten Bereichen fehlen die notwendigen Alternativen, um ablösende
Migrationspfade aufzeigen zu können. Entweder sind die am Markt verfügbaren
Produkte und Lösungen (proprietär wie OSS) noch nicht ausgereift genug oder
verfügen nicht über den nötigen Funktionsumfang. Weiterhin kann es sein, dass
ein Produkt (proprietär wie OSS) nicht mehr weiterentwickelt wird, womit dann
kein fortführender Pfad betrachtet werden kann.

Geringe Unterschiede zwischen aufeinanderfolgenden Versionen:
In einigen Fällen macht die explizite Beschreibung eines fortführenden Migrationspfades keinen Sinn, insbesondere wenn zwischen der aktuell eingesetzten
und der Folgeversion nur geringfügige Unterschiede (zum Beispiel überwiegend
in Form von Verbesserungen bestehender Funktionalität) bestehen oder wenn es
sich um einen Bereich mit grundsätzlich stabilen Funktionsanforderungen handelt.
Fehlenden Migrationszielen auf der einen Seite und einer in vielen Themenbereichen
anzutreffende Produkt- und Technologievielfalt auf der anderen Seite ist es geschuldet,
dass nicht alle möglichen Migrationspfade betrachtet werden können. Daher wurden im
Rahmen der Erstellung des Migrationsleitfadens Workshops mit Experten und Vertretern
der Hersteller durchgeführt, in denen wichtige Migrationspfade identifiziert wurden, die in
den nachfolgenden Betrachtungen berücksichtigt wurden.
Neben den technischen Betrachtungen beschäftigt sich der Migrationsleitfaden im Modul
Querschnittsthemen auch mit produktübergreifenden Technikthemen, zum Beispiel der
Integration von Softwarekomponenten und der Verwendung von Standards sowie den
rechtlichen und wirtschaftlichen Aspekten von Softwaremigrationen.
Bezug zu anderen E-Gouvernement-Dokumenten
Für die Behörden des Bundes ist das Bundesministerium des Innern der kompetente
und zentrale Ansprechpartner in Sachen Informations- und Kommunikationstechnik. In
dieser Rolle hat die "Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung" (KBSt) als zuständige Stelle bis zum heutigen Tage eine Vielzahl von IT-bezogenen Dokumenten veröffentlicht, die zum Teil einer
Seite 9
kontinuierlichen Fortschreibung und Aktualisierung unterzogen werden. Hierzu gehören
insbesondere die folgenden Dokumente und Informationsbereiche1:

DOMEA- Konzept2 in der Version 2.1

E-Gouvernement 2.0 – Das Programm des Bundes

EVB-IT3 Vertragstypen

Migrationsleitfaden 2.1

Leitfaden plattformunabhängige Fachanwendungen 1.0

SAGA4 4.0

IT-Architekturkonzept für die Bundesverwaltung 1.0

UfAB5 IV Version 1.0

V-Modell XT6 Release 1.2.1

WiBe7 4.1

XML Infopoint
Mit Ausnahme von DOMEA 2.1 hat der Migrationsleitfaden 3.0 zu allen anderen Dokumenten einen grundsätzlich mehr oder weniger intensiven Bezug. Geht es im Rahmen
einer Migration um die Beschaffung neuer Software, die bestimmten Kriterien folgen
muss, zum Beispiel um zukünftige Migrationen zu reduzieren und zu vereinfachen, dann
zeigt sich der Bezug zu EVB-IT und UfAB. Geht es jedoch um die eigentliche
Durchführung, dann ist der Bezug zu V-Modell XT und gegebenenfalls auch EVB-IT
gegeben. Allen voran sind es jedoch SAGA 3.0, das IT-Architekturkonzept für die
Bundesverwaltung 1.0, der Leitfaden plattformunabhängige Fachanwendungen und die
WiBe 4.1, zu denen ein direkter Bezug des Migrationsleitfadens besteht. Wenn es darum
geht, die Häufigkeit von Migrationen zu reduzieren, Migrationen zu vereinfachen oder die
Kosten von Migrationen zu reduzieren, dann sollten diese Dokumente bei der
Durchführung von Softwaremigrationen stets herangezogen werden.
Die in diesen Dokumenten gelegten Grundlagen und Rahmenbedingungen nimmt der
aktualisierte Migrationsleitfaden 3.0 in seine Betrachtung von Produkten, Technologien
und Migrationspfaden ergänzend auf.
1
2
3
4
5
6
7
www.kbst.bund.de
DOMEA - Dokumenten-Management und elektronische Archivierung (in der öffentlichen
Verwaltung)
EVB-IT - Ergänzenden Vertragsbedingungen für die Beschaffung von IT-Leistungen
SAGA - Standards und Architekturen für E-Government-Anwendungen
UfAB - Unterlage für die Ausschreibung und Bewertung von IT-Leistungen
V-Modell XT - Vorgehensmodell zum Planen und Durchführen von Projekten - XT steht für
„extreme tailoring―
WiBe - Wirtschaftlichkeitsbetrachtungen
Seite 10
Inhaltsverzeichnis
Vorwort zur dritten Version des Migrationsleitfadens ........................ 4
Aufbau und Inhalt des Migrationsleitfadens ........................................ 5
Inhaltsverzeichnis ................................................................................. 11
I.
Modul Querschnittsthemen........................................................... 19
A
Thema: Strategische Aspekte von Softwaremigrationen ............................19
1
Herstellerunabhängigkeit, Stärkung des Wettbewerbs, offene Standards ...............19
2
Neue Migrationsalternativen ...................................................................................21
3
Integration vorteilhaft herstellen und einsetzen .......................................................23
B
3.1
Formen und Grade der Integration ...................................................................24
3.2
Integration und Standardisierung ......................................................................26
3.3
Standardisierung und Open Source Software ...................................................27
3.4
Klassifikation der Integrationstiefe ....................................................................27
3.5
Vor- und Nachteile integrierter und standardisierter Lösungen .........................30
3.6
Kriterien zur Beurteilung integrierter Lösungen .................................................33
3.7
Beispiele und Vergleich verbreiteter integrierter Infrastrukturlösungen .............33
3.8
Fazit .................................................................................................................39
Thema: Rechtliche Aspekte von Softwaremigrationen................................41
1
Einleitung ................................................................................................................41
2
Methode..................................................................................................................42
3
Notwendigkeit der Rechtsberatung im Einzelfall .....................................................42
4
Vertragsrecht ..........................................................................................................43
4.1
Einleitung .........................................................................................................43
4.2
Vertragsverhältnisse bei OSS: Vertrag mit Zwischenhändler ............................45
4.3
Vertragsverhältnisse bei OSS: Vertrag mit Rechtsinhabern ..............................47
4.4
Vergleich der Migration zu proprietärer Software und zu OSS ..........................49
5
Urheberrecht ...........................................................................................................51
5.1
Einleitung .........................................................................................................51
5.2
Zulässigkeit von OSS-Lizenzen nach deutschem Urheberrecht .......................51
Seite 11
5.3
Umfang der Rechtseinräumung bei OSS-Lizenzen ..........................................52
5.4
Entgegenstehende Urheberrechte Dritter .........................................................53
5.5
6
Patentrecht .............................................................................................................57
6.1
Einleitung .........................................................................................................57
6.2
Entgegenstehende Patentrechte Dritter bei Nutzung von OSS .........................58
6.3
7
Haftung und Gewährleistung...................................................................................59
7.1
Einleitung .........................................................................................................59
7.2
Einsatz von OSS: Vertragliche Haftung und Gewährleistung bei
Überlassungsverträgen ....................................................................................60
7.3
Einsatz von OSS: Vertragliche Haftung und Gewährleistung bei Open
Source Lizenzverträgen....................................................................................63
7.4
Einsatz von OSS: Vertragliche Haftung und Gewährleistung bei Erstellung
und Änderung von Freier Software ...................................................................64
7.5
Einsatz von OSS: Außervertragliche Haftung ...................................................65
7.6
Einsatz von OSS: Mitverschulden.....................................................................66
7.7
8
Vergaberecht ..........................................................................................................67
8.1
Allgemeines......................................................................................................67
8.2
Beschaffung von OSS: Neutrale Ausschreibung ...............................................67
8.3
Beschaffung von OSS: transparente Ausschreibung ........................................69
8.4
Beschaffung von OSS: Vergabeentscheidung ..................................................70
8.5
9
C
Fazit........................................................................................................................72
Thema: Wirtschaftliche Aspekte von Softwaremigrationen ........................73
1
Vorwort ...................................................................................................................73
2
Einleitung ................................................................................................................73
3
Methodische Grundsätze ........................................................................................75
3.1
Ziele und Rahmenbedingungen ........................................................................77
3.2
Monetäre Analyse ............................................................................................78
3.3
Grundsätzliche Überlegungen zur Kostenerhebung..........................................78
3.4
Nutzwert-Analyse .............................................................................................83
3.5
Vollkostenansatz ..............................................................................................84
Seite 12
3.6
Vergleichbarkeit................................................................................................84
3.7
Einsatzbereiche ................................................................................................85
4
Analyse der Ausgangssituation ...............................................................................86
4.1
Infrastruktur Server...........................................................................................87
4.2
Infrastruktur APC ..............................................................................................87
4.3
Infrastruktur Netzwerk ......................................................................................88
4.4
Infrastruktur Druck ............................................................................................89
4.5
Serverdienste ...................................................................................................89
4.6
Standardsoftware .............................................................................................91
4.7
Dokumentvorlagen und Makros ........................................................................91
4.8
IT-Fachverfahren ..............................................................................................93
5
Wirtschaftlichkeit nach WiBe ...................................................................................97
5.1
Vorbemerkung ..................................................................................................97
5.2
Monetäre Wirtschaftlichkeit.............................................................................103
5.3
Erweiterte Wirtschaftlichkeit............................................................................121
6
D
Fazit......................................................................................................................135
Thema: Empfehlungen.................................................................................. 137
1
Grundsätzliche Empfehlungen ..............................................................................137
2
Vorgehensempfehlungen für Migrationsprojekte ...................................................139
2.1
Vorgehensmodelle .........................................................................................142
2.2
Mögliche Auswirkungen der Migrationspfade .................................................146
2.3
Checkliste der Erfolgsfaktoren ........................................................................147
II.
Modul Infrastrukturen .................................................................. 151
A
Thema Datenbank-Systeme ......................................................................... 151
1
Produkte / Technologien .......................................................................................152
1.1
MySQL ...........................................................................................................152
1.2
PostgreSQL....................................................................................................155
1.3
Firebird ...........................................................................................................157
1.4
MaxDB ...........................................................................................................159
1.5
Microsoft SQL Server 7.0/2000/2005 ..............................................................161
1.6
Oracle ............................................................................................................165
1.7
IBM DB2 .........................................................................................................167
Seite 13
2
B
Migrationspfade ....................................................................................................169
2.1
Die ablösende Migration proprietärer und offener Datenbank-Systeme ..........172
2.2
Fortführende Migration von Datenbank-Systemen..........................................175
Thema Webserver ......................................................................................... 176
1
1.1
Apache HTTP Server .....................................................................................176
1.2
Microsoft Internet Information Services (IIS) ...................................................180
2
2.1
Die ablösende Migration proprietärer und offener Webserver .........................184
2.2
Fortführung der Produktlinie von Webservern.................................................186
3
C
Bezüge .................................................................................................................186
3.1
Dateiablage ....................................................................................................186
3.2
Netzwerkdienste .............................................................................................187
3.3
Authentifizierung.............................................................................................187
3.4
Anwendungen ................................................................................................187
Thema Authentisierungs- und Verzeichnisdienste .................................... 189
1
1.1
Linux und Samba mit OpenLDAP und Kerberos (MIT/Heimdal) .....................190
1.2
Fedora Directory Server (OSS-Lösung mit Multimasterfähigkeit) ....................198
1.3
Windows NT 4 Server als sogenannter Domänencontroller (DC) ...................200
1.4
Windows 2000/2003 Server mit Active Directory und Kerberos ......................205
2
2.1
Migration von Windows NT DC nach Linux mit OpenLDAP, Samba und
Kerberos.........................................................................................................215
2.2
Migration von Windows 2000 mit Active Directory nach Linux OpenLDAP,
Samba und Kerberos......................................................................................217
2.3
Migration von Linux und OpenLDAP, Samba und Kerberos nach Windows
2003 mit Active Directory ................................................................................220
2.4
Migration von Windows NT als DC auf Windows 2003 mit Active Directory ....221
3
D
1
Bezüge .................................................................................................................223
3.1
Grundlegende Überlegungen .........................................................................223
3.2
Verzeichnisdienst ...........................................................................................223
Thema Netzwerkdienste ............................................................................... 225
Seite 14
1.1
NetBIOS, WINS, DNS und DHCP unter Windows NT/2000/2003 ...................225
1.2
WINS, DNS und DHCP unter Linux mit Samba ..............................................233
2
2.1
Migration Netzdienste Windows NT/2000 nach Windows 2003 ......................236
2.2
Migration von Windows DNS (BIND 8) nach Linux BIND 9 .............................238
2.3
Migration von Windows DHCP nach Linux DHCP ..........................................239
2.4
WINS/NetBIOS(Windows) nach Samba mit WINS/NMDB ..............................240
3
E
Bezüge .................................................................................................................240
Thema Dateiablage ....................................................................................... 241
1
1.1
Linux und Samba mit SMB/CIFS und POSIX .................................................241
1.2
Linux-Server mit NFS .....................................................................................249
1.3
Linux-Server mit OpenAFS .............................................................................250
1.4
Windows NT 4.0/2000/2003 mit NTFS ...........................................................251
2
2.1
Migration von Windows Server NT 4 mit NTFS 4 nach Linux mit Samba
(SMB/CIFS) und POSIX .................................................................................265
2.2
Von Windows Server 2000/2003 nach Linux Server (unter Beibehaltung von
Active Directory) .............................................................................................266
2.3
Von Linux NFS/OpenAFS nach Windows 2003 NTFS 5 .................................267
2.4
Von Windows Server NT4 nach Windows Server2000/2003 ..........................268
3
Bezüge .................................................................................................................269
3.1
F
Authentifizierungsdienst .................................................................................269
Thema Druckdienste ..................................................................................... 270
1
1.1
Allgemeine Betrachtungen .............................................................................270
1.2
Common Unix Printing System (CUPS) ..........................................................275
1.3
Common Unix Printing System (CUPS) mit Samba ........................................282
1.4
Windows Print Services ..................................................................................284
2
2.1
Migration von Windows Print Services nach CUPS in Kombination mit
Samba unter Linux .........................................................................................292
2.2
Migration von CUPS in Kombination mit Samba unter Linux nach Windows
Print Services .................................................................................................293
Seite 15
2.3
3
G
Migration von Windows NT4/2000 Print Services nach Windows 2003 Print
Services .........................................................................................................293
Bezüge .................................................................................................................293
3.1
Systemmanagement und -überwachung ........................................................293
3.2
Authentifizierung und Verzeichnisdienste .......................................................294
3.3
Thema System-Überwachungs- und -Management-Dienste ..................... 295
1
1.1
Systemmanagement mit OSS – Nagios, u.a., Linux .......................................297
1.2
Microsoft Systems Management Server (SMS) 2.0/2003 und Microsoft
Operations Manager (MOM) ...........................................................................301
1.3
HP OpenView.................................................................................................304
1.4
IBM Tivoli System-Management .....................................................................306
2
2.1
Migration von Tivoli System-Management nach HP Open View .....................307
2.2
Migration von proprietärer Systemüberwachungssoftware nach Nagios .........308
2.3
Migration von SMS 2.0 nach SMS 2003 .........................................................308
3
Bezüge .................................................................................................................309
3.1
3.2
Webserver ......................................................................................................309
III. Modul Anwendungen ................................................................... 310
A
Thema Messaging und Groupware .............................................................. 310
1
1.1
OpenGroupware.org .......................................................................................310
1.2
OpenXchange ................................................................................................314
1.3
eGroupWare ...................................................................................................319
1.4
Zarafa .............................................................................................................322
1.5
Kolab ..............................................................................................................326
1.6
Scalix .............................................................................................................331
1.7
Microsoft Exchange Server 2007 ....................................................................336
1.8
Lotus Notes ....................................................................................................340
2
2.1
Migration von MS Exchange 5.5/2003 nach Kolab 2.......................................342
Seite 16
2.2
Migration von Kolab 2 nach MS Exchange 2007 ............................................345
2.3
Migration von MS Exchange 5.5 nach MS Exchange 2007 ............................346
2.4
Migration von eGroupware nach Lotus Notes 8 ..............................................348
2.5
Scalix nach eGroupware ................................................................................351
3
B
Bezüge .................................................................................................................353
3.1
Webserver und Netzwerkdienste ....................................................................353
3.2
Authentisierungs- und Verzeichnisdienste ......................................................353
3.3
Backend-Integration .......................................................................................353
Thema Teaming-/Workgroup Software........................................................ 354
1
C
1.1
Mindquarry .....................................................................................................356
1.2
Microsoft SharePoint Server und –Services ...................................................363
1.3
O3Spaces Workplace 2 ..................................................................................384
1.4
Novell Teaming + Conferencing .....................................................................391
1.5
Lotus Quickr 8.0 .............................................................................................406
Thema Office / Desktop ................................................................................ 423
1
1.1
OpenOffice.org 2 und 1 / StarOffice8 und 7 ....................................................423
1.2
Microsoft Office 2007/2003/2002/97 ...............................................................435
2
2.1
Interoperabilität von Officeanwendungen........................................................452
2.2
Vorbereitung der Migration .............................................................................456
2.3
Migration von MS Office 97 - 2003 nach StarOffice 8/OOo 2 ..........................459
2.4
Migration von MS Office 97 - 2003 nach MS Office 2007 ...............................464
2.5
Migration von StarOffice 7/8 u. OOo1/2 nach MS Office 2007 ........................467
2.6
Migration von StarOffice 7/OOo1 nach StarOffice 8/OOo2Star .......................469
3
Bezüge .................................................................................................................472
3.1
D
Teaming-/Workgroup Software .......................................................................472
Thema Backend-Integration ......................................................................... 473
1
Produkte/Technologien .........................................................................................473
1.1
Microsoft .NET-Plattform (COM, DCOM, OLE, ActiveX) .................................473
1.2
SUN J2EE-Plattform .......................................................................................477
1.3
Object Management Group CORBA ...............................................................482
Seite 17
2
2.1
E
Migration einer Anwendung auf Basis .NET nach J2EE .................................483
Thema Terminal-Dienste und Client-Konzepte ........................................... 489
1
1.1
Linux Terminal Server Project ........................................................................493
1.2
NoMachine NX Server ....................................................................................494
1.3
Microsoft Windows Terminal Server ...............................................................496
1.4
Citrix Presentationserver ................................................................................498
2
2.1
Migration von Microsoft Windows Terminal Server nach NoMachine NX
Server ............................................................................................................503
2.2
Migration von Microsoft Windows Terminal Server 2000 nach Microsoft
Windows Terminal Server 2003 ......................................................................505
2.3
Von Microsoft Windows Terminal Server nach Citrix Presentationserver ........507
3
Bezüge .................................................................................................................509
3.1
Authentifizierungs- und Verzeichnisdienste ....................................................509
3.2
IV.
Anhang ...................................................................................... 510
A
Abkürzungsverzeichnis ................................................................................ 510
B
Glossar ........................................................................................................... 523
C
Abbildungsverzeichnis ................................................................................. 530
D
Tabellenverzeichnis ...................................................................................... 533
E
Anhang –WiBe für Migrationen .................................................................... 536
1
Kriterienkatalog WiBe für Migrationen ...................................................................536
2
Matrix zur Soft- und Hardware-Kostenermittlung...................................................540
3
Rechtsgrundlagen.................................................................................................541
Seite 18
I. Modul Querschnittsthemen
A Thema: Strategische Aspekte von Softwaremigrationen
1
Herstellerunabhängigkeit, Stärkung des Wettbewerbs, offene
Standards
Die Migration von Software wird von Organisationen nur durchgeführt, wenn dies durch
äußere wie innere Zwänge nötig wird. Solche Zwänge sind zum Beispiel:


Äußere Zwänge:
o
Die Aufkündigung des Supports für ein bestimmtes Produkt oder eine
Produktversion durch den Hersteller.
o
Die Einstellung der Entwicklung eines Open Source-Projektes beziehungsweise die Aufgabe der Unterstützung für eine bestimmte Softwareversion.
o
Die Kompatibilität mit dem neuesten Produkt in Partnerorganisationen
zwingt zum Mitmachen.
Innere Zwänge:
o
Das Fehlen von bestimmten Funktionalitäten.
o
Die Notwendigkeit der mittel- bis langfristigen Einsparung von Kosten.
o
Die Konsolidierung der IT-Infrastruktur.
Da Migrationen meist auch einen beträchtlichen Kostenaufwand mit sich bringen, vom
Personalaufwand ganz abgesehen, ist wahrscheinlich jede Behörde daran interessiert,
diesen Aufwand weitestgehend zu minimieren. Im Gegensatz zu den äußeren Zwängen
lassen sich innere Zwänge überwiegend selbst steuern, sodass selbst bestimmt werden
kann, ob und wann eine Migration durchgeführt werden soll. Hinsichtlich der äußeren
Anlässe bestehen zunächst einmal weit weniger Möglichkeiten der Einflussnahme. Hier
bestimmen in erster Linie die Software-Hersteller durch ihre Marktpolitik oder die OSSEntwickler durch ihre Entscheidungen. Bezüglich der Marktpolitik der Software-Hersteller
bedeutet dies, dass man sich von dieser Politik, die in der Regel alle paar Jahre eine
neue Version einer Software auf den Markt bringt und kurz darauf den Support für die
alte Version aufkündigt, nur dann nicht fremdbestimmen lassen muss, wenn man von
dem Hersteller so weit wie möglich unabhängig ist. Open Source Projekte sind dagegen
nicht davon geprägt in kurzen regelmäßigen Abständen grundlegend neue Versionen
einer Software zu veröffentlichen und gleichzeitig die Unterstützung alter Versionen einzustellen. Daher ist die Aufgabe von OSS-Projekten ein eher selten anzutreffender äußerer Zwang für Migrationen. Darüber hinaus ist durch die Offenheit auch gleichzeitig ein
großes Maß an Unabhängigkeit gegeben, denn es besteht jederzeit die Möglichkeit einen geeigneten Dienstleister mit entsprechenden Supportleistungen zu beauftragen.
Damit wird deutlich, dass es sich hierbei nicht um ein Ad-hoc-Problem, sondern um ein
langfristiges strategisches Problem handelt, welches angegangen werden muss. Das
Seite 19
Ziel für die Behörden muss die Unabhängigkeit von Herstellern und die Stärkung des
Wettbewerbs sein, um damit langfristig Auswahlmöglichkeiten und Wahlfreiheiten zu
erhöhen und die Anzahl der Migrationen zu reduzieren sowie gleichzeitig Kosten und
Aufwand zu einzusparen.
Durch die Minimierung der Fremdbestimmung wird gegebenenfalls erreicht, dass die
Anzahl und Häufigkeit der Migrationen abnimmt, dennoch wird es von außen bestimmte
Migrationen sicherlich auch künftig geben. Damit stellt sich die zweite Frage: Wie lassen
sich die Migrationskosten einzelner Migrationsprojekte reduzieren?
Migrationen sind vor allem davon geprägt, vorhandene Informationen (Daten, Dokumente usw.) sowie automatisierte Prozesse und Strukturen in die neue Umgebung zu überführen, um sie dort mit den benötigten Funktionen weiterverarbeiten und -verwenden zu
können. Darüber hinaus stellt sich immer wieder die Frage, insbesondere bei punktuellen Migrationen oder der Durchführung von stufenweisen Migrationen: Wie fügen sich
die migrierten Systeme in die bestehende IT-Landschaft ein? Sind sie kompatibel und
interoperabel mit den vorhandenen Systemen?
Je einfacher die Übernahme von vorhandenen Informationen, Prozessen und Strukturen
ist, desto geringer sind die Kosten für eine Migration. Je einfacher es ist, vorhandene
Software durch andere zu ersetzen und in vorhandene Systemlandschaften zu integrieren, desto stärker ist der Wettbewerb zwischen den Anbietern am Markt. Dies beeinflusst wiederum die Preise für Software, deren Wartung und den Support positiv für die
Nutzer und hilft damit die Kosten weiter zu reduzieren.
Offenheit ist ein wesentlicher Faktor, um zum Beispiel mit minimalem Aufwand
Informationen von A nach B zu überführen und Software in bestehende Systemlandschaften zu integrieren. Wenn bekannt ist, wie Informationen abgelegt werden, dann
lassen sie sich auch ohne größere Probleme überführen. Wenn Schnittstellen und ihre
Funktionen bekannt sind, dann lassen sich entsprechende Schnittstellen finden oder
implementieren, um neue Software zu integrieren.
Offenheit allein reicht aber nicht aus, denn nur mit Offenheit lässt sich noch keine Interoperabilität schaffen. Ein weiterer wesentlicher Faktor ist die Verwendung von Standards
für Schnittstellen und für die Ablage von Informationen. Die Kombination von beiden
Faktoren ist die beste Voraussetzung für die Schaffung von Interoperabilität und Kompatibilität zwischen allen Softwaresystemen einer IT-Landschaft. Darüber hinaus führt sie
zur deutlichen Reduzierung von Kosten, der Stärkung des Wettbewerbs und damit zur
Verbesserung der Herstellerunabhängigkeit.
Der Begriff eines „offenen Standards― ist schillernd und wird teilweise zum inhaltsleeren
Marketinglabel degradiert. Beispiele für konstruktive und aussagekräftige Definitionen
finden sich im European Interoperability Framework (EIF)8, im Initiativpapier der Bundesregierung für den Einsatz offener Dokumentenformate 9 oder den Mindestanforderungen
bezüglich der Offenheit von Standards, wie sie in SAGA10 definiert sind. Diese Mindest-
8
9
10
siehe http://ec.europa.eu/idabc/en/document/3761/5583
siehe http://www.kbst.bund.de
Siehe SAGA 4.0, Kapitel 2.2, Seite 20 unter www.kbst.bund.de
Seite 20
anforderungen bezüglich der Offenheit von Standards sind in SAGA aus Sicht der Bundesverwaltung folgendermaßen definiert:

Der Standard wurde veröffentlicht und die Dokumentation der Standardspezifikation ist entweder kostenlos oder maximal gegen eine Schutzgebühr erhältlich.

Das geistige Eigentum (beispielsweise in Form von Patenten) am Standard oder
an Teilen des Standards ist möglichst lizenzkostenfrei zugänglich.

Die Verwendung des Standards ist für die Bundesverwaltung und die Nutzer ihrer
Dienstleistungen uneingeschränkt möglich.

Der Standard muss auch in Zukunft veröffentlicht und frei nutzbar bleiben.
Übergreifend werden in fast allen Definitionen prinzipiell ähnliche Anforderungen an
Standards gestellt, damit sie als offen eingestuft werden können.
Unbestritten ist dabei, je weniger Einschränkungen für die Nutzung dieses Standards
bestehen (z.B. durch Lizenzkosten), desto einfacher ist seine Nutzbarkeit und desto größer ist seine Verbreitung. Erst hieraus kann ein funktionierender Wettbewerb bei gleichzeitig größtmöglicher Interoperabilität verschiedener, auf diesem Standard basierender
Lösungen entstehen.
Der Einsatz wirklich offener Standards muss ebenso wie die Herstellerunabhängigkeit
und die Stärkung des Wettbewerbs ein strategisches Ziel der Behörden sein. Das bedeutet: Um langfristig eine Verbesserung der heutigen Situation hinsichtlich der Häufigkeit von Migrationen und der damit verbundenen hohen Kosten herbeizuführen, sollten
die Behörden die vorgenannten Ziele in ihre IT-Strategie aufnehmen und auch durchsetzen, insbesondere ist es wichtig die wirklich offenen Standards zu verwenden, da diese
eine gewichtige Grundlage für die Umsetzung der anderen Ziele sind.
2
Neue Migrationsalternativen
Lag die Notwendigkeit einer Migration vor, wurde bisher die Frage gestellt, wie ein
vorhandenes Softwareprodukt durch ein anderes, aber ähnliches Softwareprodukt
ersetzt werden kann. Wie kann man zum Beispiel den einen Fileserver durch einen
anderen Fileserver oder eine vorhandene Textverarbeitung durch eine andere
Textverarbeitung ersetzen  günstigerweise durch eine Alternative mit offenen, standardisierten Schnittstellen und Datenformaten? Diese Sichtweise hat auch der
Migrationsleitfaden aufgegriffen und die Migrationsalternativen diesbezüglich betrachtet.
Migrationen von Softwarelösungen innerhalb derselben Lösungsgattung sind der Standardfall der Migration. Der Migrationsleitfaden hilft bei der Entscheidung darüber, wohin
solche Migrationen führen und wie sie gestaltet werden sollen. Damit wird jedoch nicht
gesagt, dass die Entscheidung für eine Migration innerhalb einer Lösungsgattung immer
unausweichlich ist.
Derzeit finden zwei Entwicklungen statt, die sich zwar außerhalb des Themas des
Migrationsleitfadens befinden, aber immer größeren Einfluss auf Migrationsentscheidungen gewinnen werden und damit auch auf die Anwendung des Migrationsleitfadens.
Seite 21
Zum einen entstehen neue Technologien, neue Verwendungsweisen von Technologien
und neue Nutzungsmuster, die in innovative Lösungen münden. 11 Die meisten dieser
Nutzungsmuster sind kollaborativ und erobern sich ― beispielsweise in Gestalt von
Wikis ― ihren Platz im Werkzeug-Repertoire auch großer und traditionsreicher Organisationen.
Die andere Entwicklung ist der grundlegende Wandel im Selbstverständnis der öffentlichen Verwaltung, der durch den Begriff E-Gouvernement beschrieben wird, und der unter anderem darauf abzielt, Prozesseffizienz und Kundenorientierung maßgeblich durch
Prozessautomatisierung zu steigern.
Aus beiden Entwicklungen zusammen ergibt sich die neue Leitfrage, die Migrationsentscheidungen künftig immer stärker prägen wird: Ist eine Migration innerhalb der
Lösungsgattung überhaupt der richtige Schritt? Sind die fraglichen Lösungen und ihre
Anwendung gemessen am Markt der Lösungen und an den Zielen des IT-Einsatzes
überhaupt noch auf der Höhe der Zeit?
Zur Illustration dieser Überlegung können Textverarbeitungs-Anwendungen dienen. Sie
wurden in einer Behörde beispielsweise in den späten 80er Jahren eingeführt und seither von Produkt-Generation zu Produkt-Generation migriert, verbunden mit einem stetigen Anwachsen des Leistungsvermögens. Damit einher ging die Entwicklung der (proprietären) Dateiformate, und aus deren Verbreitung ergab sich ursächlich die Notwendigkeit zur Migration.
Ein tieferer Blick auf den tatsächlichen Gebrauch dieser Anwendungen dürfte in vielen
Fällen zwei Einsichten gewähren:
Erstens sind die Leistungsmerkmale der Anwendungen, die heute tatsächlich regelmäßig genutzt werden, immer noch dieselben wie in den 80er Jahren, und dort, wo weitere
eingesetzt werden, stiften sie wenig Nutzen, aber viele Interoperabilitäts- und Migrationsprobleme.
Zweitens orientieren sich die Prozesse, die mithilfe dieser Anwendungen ausgeführt
werden, immer noch an ihren papierbasierten Vorbildern. Das ist nicht verwunderlich,
gerade im Fall von Textverarbeitungen. Historisch verstehen sie sich schließlich als
elektronifizierte Schreibmaschine und ihr unreflektierter Gebrauch führt zu (streckenweise)
elektronifizierten
Papierprozessen.
Das
Optimierungsund
Automatisierungspotenzial der Prozesse bleibt auf diese Weise unerschlossen.
Die Frage nach der Optimierbarkeit des Portfolios von IT-Lösungen und ihres Einsatzes
wird sich künftig immer intensiver stellen, ausgelöst vielleicht durch Migrationszwänge.
Beantwortet werden muss sie jedoch im Vorfeld der Migrationsentscheidung. Eine
solche Optimierungsentscheidung könnte sein, nicht mehr (oder nicht nur) einen
existierenden Dateidienst aufzurüsten, da dieser ohnehin nur dazu verwendet wird, elektronifizierte Papierprozesse zu unterstützen. Stattdessen (oder ergänzend) sollen Kollaborationslösungen, Dokumentenmanagement- oder sogar Workflow-Systeme eingeführt
werden.
11
Viele dieser Entwicklungen werden häufig unter dem Stichwort „Web 2.0" zusammengefasst.
Seite 22
Die Einführung von Workflow-Systemen könnte zur Folge haben, dass anstelle von
Textverarbeitungen ― den elektronifizierten Schreibmaschinen ― Maskenwerkzeuge
eingesetzt werden. Daten würden dann in klar geordneten Strukturen („Datensätze―)
gespeichert und nicht in den Formatierungsinformationen eines Dokumentes vergraben
werden.
Der
kontinuierliche
Leistungszuwachs
beispielsweise
der
Formatierungsmöglichkeiten von Textverarbeitungen würde dadurch unerheblich für das
Funktionieren des Geschäftsprozesses, und ein wiederkehrender Migrationsgrund würde
aus der Perspektive des Prozesses ganz einfach entfallen.
Das Thema Textverarbeitung ist in diesem Kontext sicherlich nur eine Facette, die zu
betrachten wäre. Sie zeigt aber deutlich, dass zur Vermeidung von Migrationszwängen
nicht nur die Verwendung offener und standardisierter Schnittstellen und Datenformate
beitragen kann, sondern auch ein kritischer Blick auf die Entwicklung im IT-Lösungsmarkt und die eigenen Geschäftsprozesse. Wie schon die Durchsetzung offener
Standards ist auch diese Betrachtung eine strategische Aufgabe. Gelingt ihre Bewältigung, dann werden Migrationen künftig weniger häufig und weniger umfangreich.
Betrachtet man die zuvor beschriebenen Ideen im Zusammenhang mit den Entwicklungen am IT-Lösungsmarkt für Kollaborationslösungen, dann wird sogar deutlich, dass es
sich hierbei keinesfalls um Utopien handelt, sondern dass auch die Hersteller diese Möglichkeiten entdeckt haben und ansatzweise schon versuchen, diese in ihre Lösungen
aufzunehmen. Der Begriff Dokument bekommt hier eine zum Teil neue Bedeutung, da er
nicht mehr immer gleich mit Datei zu setzen ist, wie bei den klassischen Office-Suiten.
Gerade für die Zusammenarbeit mit externen Partnern (andere Behörden, Unternehmen)
zeigen sich hierfür neue Modelle, für die es sich lohnt, sie näher zu betrachten, wenn
man darüber nachdenkt, für die externe wie interne Zusammenarbeit gemeinsame und
einheitliche Prozesse zu schaffen, wie sie zum Beispiel die E-Gouvernmentstrategie des
Bundes vorsieht.
Der Migrationsleitfaden wird in der Zukunft diese Entwicklungen genau betrachten und
die sich daraus ergebenden alternativen Migrationsziele aufzeigen.
3
Integration vorteilhaft herstellen und einsetzen
Eine der zentralen Aufgaben beim Betrieb von Informationstechnologie besteht darin, die
verschiedenen, aus Soft- oder Hardware bestehenden Komponenten einer Umgebung
miteinander zu integrieren.
Betriebs- oder Virtualisierungssysteme müssen mit Hardwarekomponenten integriert
werden, wozu in der Regel Treiber installiert oder konfiguriert werden müssen. Anwendungen müssen gemeinsam mit anderen Anwendungen in Betriebssystemumgebungen
integriert werden, darüber hinaus müssen sie sich in der Regel in Softwareverteilungsoder Systemmanagementlösungen einfügen. Server- und Clientanwendungen müssen
Benutzer authentifizieren und autorisieren, wozu sie mit Identity-Management-Systemen
integriert werden müssen. Spätestens nach der Autorisierung greifen die meisten Anwendungen auf Daten zu, wozu sie mit Datenbanksystemen, Servern (welche Datenablagen oder andere Anwendungen bereitstellen) integriert werden müssen. Diese Liste
ließe sich nach Belieben fortsetzen.
Seite 23
Ab einer gewissen Größe einer IT-Infrastruktur ist dieser Integrationsprozess ein kontinuierlicher Vorgang, da Hard- oder Softwarekomponenten ständig erneuert, erweitert,
konsolidiert oder an neue Rahmenbedingungen oder Anforderungen angepasst werden
müssen.
Die ständige Integration von IT-Komponenten ist in der Regel ein aufwendiger und natürlich immer wieder mit Risiken verbundener Prozess. Aus diesem Grund bietet es sich auf
den ersten Blick an, vermehrt solche Komponenten einzusetzen, die mit anderen Komponenten bereits integriert oder einfach integrierbar sind, um dadurch Kosten zu sparen,
Risiken zu minimieren oder sogar Mehrwerte hinsichtlich der Funktionalität und Leistungsfähigkeit der Gesamtsysteme zu erreichen.
Am Markt besteht dazu gelegentlich die Auffassung, die verschiedenen Softwareprodukte und Komponenten von proprietärer Software würden untereinander einen höheren
Grad an Integration aufweisen, während die im Umfeld der verfügbaren Open Source
Produkte und Komponenten tendenziell aufwendiger und oft noch manuell miteinander
integriert werden müssten. Dieser so angenommene, höhere Integrationsgrad im Bereich der proprietären Software würde dann letztlich zu einer höheren Wirtschaftlichkeit
bei ihrer Verwendung führen.
Dieses Kapitel beschäftigt sich damit, ob und unter welchen Bedingungen integrierte
Lösungen vorteilhaft sind beziehungsweise sein können. Nach einer allgemeinen Betrachtung dieser Thematik erfolgt am Ende ein beispielhafter Vergleich von drei unterschiedlichen Lösungen.
3.1
Formen und Grade der Integration
Unter Integration werden im Zusammenhang mit IT-Infrastruktur eine Reihe unterschiedlicher Dinge verstanden, sodass hier zunächst der Versuche der Kategorisierung unternommen werden soll.
Konfigurationsintegration
Eine einfache Form von Integration besteht in der Bildung kombinierter Softwarepakete,
bei denen die enthaltenen Komponenten gemeinsam installiert und während der Installation automatisch für das optimale Funktionieren miteinander konfiguriert werden. Solche kombinierten Pakete findet man zum Beispiel oft im Bereich der Softwareappliances.
Der Anwender erhält damit ein „out-of-the-box― funktionierendes System mit einem definierten Satz an Eigenschaften, ohne dass er die Details von Konfiguration und Implementierung der einzelnen Komponenten kennen muss. Im Fall einer ausschließlich im
Bereich der Konfiguration realisierten Integration unterscheiden sich die enthaltenen
Komponenten dabei nicht von denen, die auch separat erhältlich, installierbar und manuell für das korrekte Miteinander konfiguriert werden können. Diese Form der Integration erspart im Wesentlichen Aufwände bei Konfiguration und Implementierung, ohne die
Flexibilität der einzelnen Komponenten oder des Gesamtsystems einzuschränken.
Administrationsintegration
Systeme, die aus miteinander integrierten Softwarekomponenten bestehen, müssen in
der Regel mithilfe einer Reihe von Parametern konfiguriert werden können. Das Ändern
eines bestimmten Parameters betrifft dabei oft mehrere der integrierten Komponenten.
Seite 24
Die Integration von Programmen, Diensten oder Softwarekomponenten über Mechanismen, die sicherstellen, dass die administrative Beeinflussung von Konfigurationsparametern die Integrität des Gesamtsystems nicht stört und alle relevanten Komponenten
entsprechende rekonfiguriert werden, wird hier als „Administrationsintegration― bezeichnet.
Funktionsintegration
Eine weitere Form der Integration besteht in der Verwendung von Funktionen eines
Programms oder einer Softwarekomponente durch ein anderes Programm beziehungsweise eine andere Softwarekomponente. Ein bekanntes Beispiel dafür sind die aus
dem Bereich von Office-Paketen bekannten OLE-Verknüpfungen, mit denen Funktionen
zum Rechnen mit Tabellen beispielsweise von einem Tabellenkalkulationsprogramm
bereitgestellt und die innerhalb eines Textverarbeitungsprogramms dargestellt werden
können. Zur Funktionsintegration gehört aber auch die Bereitstellung bestimmter, von
vielen verschiedenen Programmen benötigter Funktionen, zum Beispiel zum Zugriff auf
das Internet oder zur Durchführung mathematischer Operationen. Die Integration auf
dieser Ebene ist deswegen oft durch das Vorhandensein von Programmbibliotheken
gekennzeichnet, die von vielen unterschiedlichen Anwendungen genutzt werden.
Datenintegration
Die letzte hier genannte Form der Integration ist die Datenintegration. Dabei greifen
mehrere Anwendungen oder Dienste auf die (physikalisch) selben Daten zu, wodurch
Redundanzen vermieden werden sollen. Voraussetzung für die Datenintegration ist die
gemeinsame Verwendung eines einheitlichen Datenmodells durch alle beteiligten Komponenten sowie die Benutzung definierter Mechanismen zum Zugriff auf die Daten, um
Inkonsistenzen etwa durch zeitgleichen Zugriff von zwei Anwendungen zu vermeiden.
Diese Mechanismen werden in der Regel durch Funktionsintegration einheitlich zur Verfügung gestellt.
Beispiele für Datenintegration im Bereich der IT-Infrastruktur sind zum Beispiel Identityund Infrastrukturmanagementsysteme, die an zentraler Stelle Informationen beispielsweise über Benutzer, deren Rechte und Rollen oder Systeme und deren Konfiguration
bereithalten. Betriebssysteme und Anwendungen greifen auf diese Daten über definierte
Schnittstellen und Protokolle zu, um beispielsweise die Rechte eines Benutzers mit bestimmten Anwendungen und Daten festzustellen.
In der Praxis findet man meistens Komponenten, die mithilfe unterschiedlicher Integrationsmethoden miteinander integriert sind. Am Beispiel der Integration des Mail- und Kalenderdienstes Microsoft Exchange mit Active Directory lässt sich dies gut zeigen:

Hier wird Datenintegration verwendet, sodass Windows-Anmeldedienst und der
Mailserver zum Beispiel dieselben Benutzerdaten und Credentials verwenden.

Funktionsintegration stellt über das Verwenden derselben Programmbibliotheken
durch alle miteinander integrierten Komponenten sicher, dass auf die entsprechenden Daten immer über dieselben Mechanismen und Protokolle zugegriffen
wird und es so zu keinen Inkonsistenzen kommt.

Mit Methoden der Administrationsintegration werden die einzelnen Dienste aus
Sicht von Administratoren miteinander verknüpft, Administratoren können in der
Seite 25
Folge beim Anlegen eines neuen (Windows-) Benutzers auch gleich dessen
Mailkontoeinstellungen festlegen, ohne dazu eine andere Applikation bemühen
zu müssen.

3.2
Schließlich verwenden die einzelnen Komponenten die gleichen Installationsund Konfigurationsmethoden (wie zum Beispiel die Windows Registry und darauf
aufbauende Werkzeuge), sodass während der Installation eine aufeinander abgestimmte Konfiguration sichergestellt werden kann.
Integration und Standardisierung
Jede Form der Integration erfordert Schnittstellen, welche die Kommunikation der
beteiligten Komponenten miteinander ermöglichen. Bei der Konfigurationsintegration
werden Programme zur optimalen Funktionsweise miteinander eingerichtet, wobei das
gemeinsame Funktionieren ohne Schnittstellen zur Kommunikation der Anwendungen
miteinander nicht möglich wäre. Bei der Administrationsintegration sorgen Systeme, die
der Konfiguration der einzelnen Komponenten übergeordnet sind oder gemeinsam
genutzte Schnittstellen für die Abstimmung der Konfigurationen mit festgelegten
Parametern sowie für die Sicherstellung der Integrität des Gesamtsystems. Schließlich
werden bei Funktions- und Datenintegration Schnittstellen und Protokolle benötigt, um
auf Daten oder Funktionen zuzugreifen.
Schnittstellen und Kommunikation bilden die Grundlage jeder Integration, allerdings beinhaltet der Begriff der Integration keine Aussage darüber, in wie weit die Komponenten
einer integrierten Umgebung standardisierte Schnittstellen und standardisierte Protokolle
zur Kommunikation miteinander benutzen.
Als standardisiert kann man Schnittstellen oder Protokolle u.a. dann bezeichnen, wenn
sie in einer öffentlich zugänglichen Dokumentation beschrieben sind und diese Beschreibung auf einem Konsens der daran interessierten Parteien beruht. Ein wesentlicher Nutzen standardisierter Protokolle und Schnittstellen besteht darin, dass sie von
unterschiedlichen Herstellern verschiedener Komponenten genutzt werden können, ohne dass sich dabei ein Hersteller von einem anderen, der die entsprechenden Protokolle
oder Schnittstellen in seinen Komponenten verwendet, in einem für ihn gefährlichen Maß
abhängig machen würde.
Bei der Verwendung proprietärer, nicht offen gelegter Schnittstellen besteht auch für
Anwender stets die Gefahr, dass diese von Anwendungen Dritter nicht genutzt werden
können oder sich im Rahmen von Updates oder neuen Versionen bestimmter Komponenten ändern. Durch die Verwendung standardisierter Protokolle und Schnittstellen bei
der Integration von Softwarekomponenten kann dieses Risiko erheblich minimiert werden und es entsteht für die Betreiber von IT-Infrastruktur eine höhere Sicherheit.
Standardisierung ist weitgehend unabhängig von Integration. Integrierte Lösungen können ausschließlich standardisierte Protokolle und Schnittstellen, aber genauso gut auch
proprietäre und undokumentierte Kommunikationswege verwenden. Miteinander wenig
oder nicht integrierte Anwendungen sind für die Kommunikation miteinander oder den
Datenaustausch untereinander in der Regel auf eine herstellerübergreifende Definition
der verwendeten Schnittstellen und Protokolle angewiesen, da diese sonst kaum unab-
Seite 26
hängig voneinander und über mehrere Versionen der entsprechenden Programme hinweg gepflegt werden könnten.
3.3
Standardisierung und Open Source Software
Standardisierungsprozesse weisen verschiedene Parallelen zu häufig verwendeten Entwicklungsmodellen von Open Source Software auf. Insbesondere alle Open Source Projekte, die es auf die Mitwirkung einer Community abgesehen haben, veröffentlichen den
Programmcode schnell, regelmäßig und versuchen, Entscheidungs- und Diskussionsprozesse in einer Öffentlichkeit „derer, die daran Interesse haben― zu halten. Dies ist
vergleichbar mit Standardisierungsverfahren, bei denen der Standard selbst beziehungsweise die während seiner Entwicklung diskutierten Entwürfe einer (Fach-) Öffentlichkeit
verfügbar gemacht und von dieser diskutiert werden.
Hierin besteht allerdings kein Automatismus. Open Source Lizenzierung bedeutet nicht
zwangsläufig, dass der Quellcode einer Anwendung einer breiten Öffentlichkeit verfügbar gemacht oder dass über seine Weiterentwicklung in einer Öffentlichkeit diskutiert
werden muss.
Der Anwender einer unter Open Source Lizenz stehenden Software erhält damit allerdings immer das Recht, den zugehörigen Quellcode zu lesen, wodurch er zumindest
eine Form einer lückenlosen Beschreibung der von dieser Software verwendeten Protokolle und Schnittstellen erhält. Gegenüber proprietärer Software ist er damit besser gestellt, weil ihn der Quellcode in die Lage versetzt, die entsprechenden Schnittstellen zu
verwenden und er seine Open Source Applikation sogar verändern kann, beispielsweise
um die Interoperabilität mit anderen Anwendungen sicher zu stellen.
Mit Open Source Software ist im Hinblick auf verwendete Protokolle und Schnittstellen
ein Aspekt von Standardisierung immer sichergestellt, nämlich die Verfügbarkeit einer
Beschreibung für den Lizenznehmer. Viele Open Source Projekte bemühen sich darüber
hinaus um die auch im Rahmen von Standardisierung wichtige öffentliche Diskussion
und Entwicklung. Trotzdem müssen Open Source und Standardisierung voneinander
abgegrenzt bleiben, insbesondere weil Standards auch von proprietärer Software implementiert werden können und Open Source Lizenzen nicht gleichbedeutend mit allgemeiner Veröffentlichung des Quellcodes und öffentlichem Entwicklungs- und Entscheidungsmodell sind.
3.4
Klassifikation der Integrationstiefe
Um den Integrationsgrad von Softwarekomponenten und die damit verbundenen Vorund Nachteile zu beurteilen, soll die mögliche Tiefe der Integration von Komponenten
hier in vier Stufen (keine, leichte, mittlere und hohe) eingeteilt werden.
Mit der Integrationstiefe steigt in der Regel die Herstellerabhängigkeit, sodass darauf bei
der Beschreibung der vier Stufen eingegangen wird.
3.4.1
Keine Integration
Keine Integration liegt dann vor, wenn die betroffenen Programme oder Komponenten
unabhängig voneinander installiert und (sinnvoll) unabhängig voneinander betrieben
werden können. Dabei benutzen sie keine funktionalen Bestandteile der übrigen KomSeite 27
ponenten und greifen nicht auf die Daten der anderen zu. Die Kommunikation der betroffenen Bestandteile untereinander erfolgt über öffentlich dokumentierte Schnittstellen, die
im Idealfall standardisiert sind. In der Regel müssen die Komponenten manuell konfiguriert und aufeinander abgestimmt werden.
Die Herstellerabhängigkeit ist bei der Verwendung eines Systems nicht miteinander integrierter Komponenten naturgemäß sehr gering. Gleichzeitig müssen in der Regel vergleichsweise hohe Aufwände in die manuelle Integration beziehungsweise die parallele
Pflege und Administration nicht miteinander integrierter Komponenten gesteckt werden.
3.4.2
Leichte Integration
Bei einer leichten Integration sind die betroffenen Programme ebenfalls unabhängig voneinander installier- und betreibbar. Sie sind jedoch auf eine oder mehrere der folgenden
Arten miteinander integriert:

Konfigurationsintegration:
Die Komponenten können automatisiert gemeinsam installiert werden und sind
dann bereits automatisch gut aufeinander abgestimmt, dabei werden jedoch nur
die öffentlich dokumentierten und von jedermann benutzbaren Konfigurationsschnittellen und -parameter der einzelnen Komponenten genutzt.

Administrationskonfiguration:
Die Komponenten können über ein gemeinsames oder übergeordnetes System
verwaltet werden, wobei jede Komponente weiterhin auch unabhängig von den
übrigen administrierbar bleibt.

Funktionsintegration:
Die Komponenten können Funktionen anderer Komponenten benutzen, wenn
diese in der Umgebung vorhanden sind. Sie bleiben ohne die anderen Komponenten jedoch voll funktionsfähig und sind nicht zwingend darauf angewiesen.

Datenintegration:
Die Komponenten können bestimmte, von anderen Anwendungen verwaltete Daten nutzen und greifen über dokumentierte Schnittstellen und Protokolle darauf
zu oder stellen selbst anderen Anwendungen Daten über eigene Schnittstellen
und Protokolle zur Verfügung. Sie sind auf das Vorhandensein der anderen Programme jedoch nicht angewiesen und können alle wesentlichen Daten auch selbst
verwalten.
Hinsichtlich der Herstellerabhängigkeit stellt die leichte Integration den Anwender nicht
schlechter als die Verwendung nicht miteinander integrierter Komponenten. Er erwirbt
durch die leichte Integration zwar die mit der Integration verbundenen Vorteile (s.u.)
kann aber jederzeit auch andere, nicht integrierte Komponenten verwenden, wobei er
dann die für nicht integrierte Komponenten typischen Aufwände zu tragen hat.
3.4.3
Mittlere Integration
Von einer mittleren Integration spricht man, wenn bestimmte Komponenten des Gesamtsystems mit anderen so eng verbunden sind, dass wesentliche Funktionen gar nicht
oder nur mit erheblichem Aufwand bereitgestellt werden können, wenn die entsprechenden Komponenten fehlen oder durch andere mit vergleichbarer Funktion aber fehlender
Seite 28
Integration mit dem Gesamtsystem ersetzt werden sollen. Im Bezug auf die genannten
vier Integrationsarten bedeutet das:

Konfigurationsintegration:
Die Konfiguration der Komponenten setzt das Vorhandensein der anderen Komponenten voraus und muss angepasst werden, falls bestimmte Komponenten
nicht vorhanden oder durch andere ersetzt werden sollen.

Administrationsintegration:
Für eine einfache Administration setzen die Komponenten das Vorhandensein
bestimmter Administrationssysteme voraus. Wenn diese fehlen oder andere Systeme genutzt werden sollen, müssen die entsprechenden Komponenten aufwendig manuell administriert oder an die Alternativsysteme angepasst werden.

Funktionsintegration:
Die Komponenten verwenden auch in wesentlichen Bereichen Funktionen und
Bestandteile der übrigen Komponenten. Der Betrieb der Einzelbestandteile und
die Verwendung alternativer Komponenten, welche ähnliche Funktionen zur Verfügung stellen, ist technisch zwar möglich, jedoch mit hohem Aufwand verbunden.

Datenintegration:
Wo immer sinnvoll, greifen die Komponenten auf Daten zu, die von anderen
Komponenten verwaltet werden. Auch hier gilt, dass der alleinstehende Betrieb
der Komponenten, beziehungsweise die Bereitstellung der benötigten Daten über
andere Komponenten zwar möglich, aber deutlich aufwendiger als der Betrieb
der integrierten Variante ist.
Aus dieser Integrationstiefe entsteht eine gewisse Herstellerabhängigkeit, weil es für den
Anwender vergleichsweise aufwendig ist, Komponenten der integrierten Lösung durch
andere zu ersetzen.
3.4.4
Hohe Integration
Bei einer hohen Integration fällt es oft schwer, die einzelnen Komponenten überhaupt
noch als auch separat voneinander oder mit anderen, alternativen Bestandteilen nutzbare Programme oder Systeme zu erkennen. Die Komponenten werden in der Regel gemeinsam installiert und administriert, das Herauslösen einer Komponente birgt stets die
Gefahr, dass sie ohne die übrigen nicht mehr vernünftig oder gar nicht mehr betreiboder administrierbar ist. Dasselbe gilt für Funktionen und Daten: Alle Komponenten nutzen von anderen Bestandteilen bereitgestellte Funktionen oder von diesen verwaltete
Daten, wobei es auch hier nur mit hohem Aufwand oder gar nicht möglich ist, die entsprechenden Programme allein oder mit Komponenten anderer Hersteller einzusetzen,
auch wenn die Kommunikation zwischen den Komponenten über Standard-Protokolle
und –Schnittstellen erfolgt.
Durch ein so hohes Maß an Integration entsteht auch ein sehr hohes Maß an Herstellerabhängigkeit. Die einzelnen Komponenten der integrierten Lösung können in der Regel
nicht mehr unabhängig von anderen betrieben werden, gleichzeitig ist nicht oder nur mit
sehr hohem Aufwand möglich, an einer Stelle alternative Komponenten zu verwenden.
Seite 29
Der Anwender wird deswegen in der Regel alle benötigten Komponenten vom selben
Hersteller einsetzen wollen.
3.5
Vor- und Nachteile integrierter und standardisierter Lösungen
Der wesentliche Vorteil integrierter Lösungen besteht darin, dass die einzelnen Komponenten bereits aufeinander abgestimmt sind und ohne großen Aufwand sofort miteinander funktionieren.
Weil die betreffenden Komponenten auch von ihren Lieferanten als miteinander integrierte Komponenten gepflegt werden, gilt dies nicht nur während der Implementierung eines
Systems, sondern während seiner gesamten Laufzeit. So kann bei einer integrierten
Lösung zum Beispiel erwartet werden, dass sich die einzelnen Komponenten besser und
einfacher gemeinsam aktualisieren lassen, als wenn die Einzelbestandteile jeweils separat bezogen und nach jedem Update wieder aufeinander abgestimmt und miteinander
getestet werden müssten. Die einzelnen Bestandteile integrierter Lösungen passen also
zueinander und können oft entsprechend dem Baukastenprinzip einfach miteinander
kombiniert werden.
Dies hat eine Reihe wirtschaftlicher Konsequenzen: So sinkt der Aufwand für Konzeption
und Implementierung, etwa weil die Art und Weise des Zusammenwirkens zweier Anwendungen nicht neu konzeptioniert, das Rad also nicht immer wieder neu erfunden
werden muss und Tests im geringeren Umfang notwendig sind, als bei manuell miteinander integrierten Komponenten. Durch die beim Hersteller und gegebenenfalls auch
bei Dienstleistern, Administratoren und anderen Experten vorhandene Kenntnis von der
Art und Weise, wie die Integration der Komponenten realisiert wurde, sind entsprechende Lösungen darüber hinaus einfacher und somit kostengünstiger supportbar. Außerdem
ist das Know-how für die Implementierung und den Betrieb integrierter Lösungen aufgrund der gegenüber einer Individuallösung häufigeren Realisierung am Markt tendenziell einfacher verfügbar.
Weitere Vorteile können sein, dass zwischen den miteinander integrierten Komponenten
Daten oder Dokumente einfacher ausgetauscht werden können, weil viele Teile des Gesamtsystems dieselben Funktionen zum Anzeigen oder Bearbeiten der entsprechenden
Daten nutzen. Integrierte Systeme und Lösungen können sowohl auf Administratorenals auch auf Anwenderseite Arbeitsprozesse vereinfachen und dadurch Zeit und Kosten
einsparen.
Im Gegensatz dazu wird die Herstellerunabhängigkeit und Flexibilität durch Integration
nicht gefördert. Wie im vorhergehenden Abschnitt gezeigt, steigt vielmehr die Herstellerabhängigkeit mit dem Grad der Integration und die Flexibilität sinkt.
Demgegenüber ist die Verwendung standardisierter Schnittstellen und Protokolle ein
wichtiges Mittel zur Sicherung von Herstellerunabhängigkeit und Flexibilität.
Mit Lösungen, die einen hohen Integrationsgrad besitzen oder welche für die Kommunikation der Komponenten untereinander keine standardisierten Schnittstellen und Protokolle verwenden, ist eine Reihe von Gefahren verbunden:
Seite 30

Durch die fehlende Offenlegung von Schnittstellen und Protokollen ist nur der
Hersteller der integrierten Lösung in der Lage, Komponenten zu tauschen, zu ergänzen oder zu erneuern.

Dadurch entsteht eine hohe Herstellerabhängigkeit („Vendor Lock-In―): Der Anwender ist darauf angewiesen, die Gesamtlösung mit allen von ihm benötigten zu
nutzen; die Möglichkeit, Komponenten anderer Hersteller zu verwenden, besteht
nicht oder ist nur mit oft unvertretbar hohem Aufwand möglich.

Hersteller werden so in die Lage versetzt, bei IT-Anwendern Erwerb und Einsatz
zusätzlicher Produkte durchzusetzen, wodurch zusätzliche Kosten zusätzliche
planerische, integrative und administrative Aufwände entstehen.

Fehlende Standardisierung führt außerdem oft dazu, dass die entsprechenden
Komponenten im Wesentlichen nur mit sich selbst, beziehungsweise mit anderen
(integrierten) Komponenten desselben Herstellers kompatibel sind, während sich
der Datenaustausch zu Programmen oder Komponenten anderer Hersteller als
schwierig oder unmöglich gestaltet.
Ein bekanntes Beispiel für die durch hohe Integration entstehende Herstellerabhängigkeit ist der von Microsoft mit Exchange 2000 eingeführte Zwang zur Verwendung von
Microsoft Active Directory. Durch diese Voraussetzung sind Anwender, die diese oder
eine neuere Version von Exchange einführen wollen, nicht nur auf die Anschaffung von
Active Directory Lizenzen, sondern auch auf die Konzeption dieses Verzeichnisdienstes,
die Integration von Active Directory mit bestehenden Identity-Management-Systemen
sowie die laufende Administration von Active Directory angewiesen.
Als Gegenbeispiel dazu kann das Groupwaresystem Kolab dienen. Dieses, selbst als
Open Source Software entwickelte System, integriert verschiedene, weit verbreitete
Open Source Komponenten miteinander zu einem Mail- und Groupwaresystem, das in
vielen Szenarien alternativ zu Microsoft Exchange eingesetzt werden kann. Dabei
werden jedoch nur allgemein zugängliche Schnittstellen und Protokolle verwendet,
sodass es sich um eine leichte Integration handelt. Das System verwendet OpenLDAP
als Verzeichnisdienst. Aufgrund der leichten Integration, der Verwendung von standardisierten Protokollen und Schnittstellen und der Open Source Lizenz ist es aber auch
möglich, das System mit jedem anderen Verzeichnisdienst zu integrieren. Dasselbe gilt
für andere in Kolab verwendete Komponenten wie SMTP- oder Webserver.
Allgemein gilt vor allem für hoch integrierte Lösungen, dass diese ihre wesentlichen Vorteile verlieren, wenn einzelne Komponenten durch andere, vom Hersteller nicht dafür
vorgesehene Komponenten ausgetauscht werden können.
Die folgende Tabelle zeigt angestrebte Ziele für eine flexible und wirtschaftliche ITInfrastruktur und welche Auswirkungen Integration und Standardisierung hierauf haben.
Es wird gezeigt, in wie weit die genannten Ziele tatsächlich eine direkt aus der Integration resultierende Eigenschaft sind oder nicht und in wie weit sie ein Resultat aus der
Verwendung von standardisierten Schnittstellen und Protokollen sind. Für eine Reihe
von Zielen gilt dabei, dass sie sich direkt aus der Integration oder der Standardisierung
von Schnittstellen und Protokollen ableiten lassen, während andere nur eine indirekte
Seite 31
Folge der beiden Kriterien sind. So ist beispielsweise die Eigenschaft, dass Komponenten eines Systems aufeinander abgestimmt sind, eine direkte Folge der Integration der
entsprechenden Komponenten, während Standardisierung eine gute Abstimmung von
Komponenten aufeinander nur begünstigt, nicht aber zusichert. Standardisierung ist
deswegen in diesem Fall nur eine Eigenschaft, welche das „aufeinander abgestimmt
sein― von Komponenten begünstigt.
Ziel
Auswirkung
Integration
Standardisierung
Aufeinander abgestimmte Komponenten („Baukastenprinzip―)
direkter Vorteil
begünstigend
Ein zentraler Lieferant / Hersteller /
Ansprechpartner für alle Komponenten
direkter Vorteil
begünstigend
Geringerer Aufwand bei Konzeption
und Implementierung
direkter Vorteil
begünstigend
Gute Unterstützung für die Aktualisierung aller Komponenten als Gesamtsystem
direkter Vorteil
begünstigend
Einfach supportbar
direkter Vorteil
begünstigend
Geringerer Testaufwand
direkter Vorteil
begünstigend
Know-how am Markt potenziell leichter
verfügbar
begünstigend
direkter Vorteil
Vereinfachung der Arbeitsprozesse
von Anwendern und Administratoren
direkter Vorteil
begünstigend
Flexibilität beim Tausch von Komponenten gegen Komponenten anderer
Hersteller
nachteilig
direkter Vorteil
Flexibilität bei der Verwendung von
Komponenten, die ursprünglich nicht
für die Verwendung mit der Lösung
vorgesehen wurden
Hersteller- beziehungsweise Lieferantenunabhängigkeit
(mit zunehmender Integrationstiefe)
nachteilig
direkter Vorteil
nachteilig
direkter Vorteil
Tabelle 1: Auswirkungen von Integration und Standardisierung
auf ausgewählte Ziele einer Behörde
Die Tabelle zeigt, dass es eine Reihe positiver, kostensenkender Eigenschaften von ITInfrastrukturkomponenten gibt, die durch Integration direkt gefördert werden, interessanterweise werden alle diese Eigenschaften gleichzeitig durch Standardisierung gefördert.
Seite 32
3.6
Kriterien zur Beurteilung integrierter Lösungen
Bei der Auswahl neuer IT-Systeme stellt sich die Frage, in wie weit bereits miteinander
integrierte Komponenten oder voneinander unabhängige Einzelbestandteile genutzt
werden sollen. Zur Erleichterung entsprechender Entscheidungen werden hier einige
Fragen angeboten, deren positive oder negative Beantwortung als Grundlage für die
Beurteilung integrierter Lösungen dienen kann:
1.
Welcher Grad der Integration liegt vor?
2.
Ist die technische Realisierung der Integration öffentlich zugänglich dokumentiert?
3.
In wie weit ist es dokumentiert und vorgesehen, alternative Komponenten zu
verwenden?
4.
Verwendet die Lösung zur Kommunikation der Komponenten untereinander die
von den entsprechenden Komponenten implementierten Standardprotokolle oder
gibt es Erweiterungen, welche nur für die Integrationslösung bestimmte Schnittstellen oder Protokolle implementieren?
5.
Falls keine standardisierten Protokolle und Schnittstellen verwendet werden,
handelt es sich bei den Integrationskomponenten um Open Source Software, deren Quellcode einsehbar und veränderbar ist?
6.
Falls herstellerspezifische Schnittstellen und Protokolle verwendet werden: Sind
die verwendeten Protokolle offen und frei zugänglich dokumentiert?
7.
Falls herstellerspezifische Schnittstellen und Protokolle verwendet werden: Gibt
es frei zugängliche Referenzimplementierungen?
8.
Falls herstellerspezifische Schnittstellen und Protokolle verwendet werden: Gibt
es vom Hersteller der Lösung unabhängig entwickelte Software, welche die entsprechenden Protokolle implementiert, beziehungsweise die Schnittstellen nutzen?
Bei einer Beurteilung integrierter Lösungen kommt es also darauf an, in wie weit diese
intern standardisierte Schnittstellen und Protokolle verwenden und in wie weit sie selbst
offen und standardisiert sind. In allererster Näherung kann zur Beurteilung auch die Integrationstiefe herangezogen werden. Eine zu hohe Integration birgt zumindest potenziell die Gefahr einer hohen „Verstrickung― von Komponenten miteinander, das heißt, die
Abhängigkeit der Komponenten untereinander lässt den Austausch von einzelnen Teilen
nicht zu, auch wenn standardisierte Protokolle und Schnittstellen verwendet werden. Auf
der anderen Seite bieten miteinander leicht integrierte Komponenten, welche für die
Kommunikation untereinander standardisierte Schnittstellen und Protokolle verwenden,
erhebliche Vorteile in Bezug auf Konzeption, Implementierung, Test, Administration und
Pflege.
3.7
Beispiele und Vergleich verbreiteter integrierter Infrastrukturlösungen
In diesem Abschnitt wird der Versuch unternommen, am Beispiel der integrierten Lösungen von Microsoft, Novell und Univention die Umsetzung der Integration verschiedener
Komponenten auf Basis der genannten Kriterien zu beurteilen. Diese drei wurden als
Seite 33
Beispiele ausgewählt, weil sie die Kategorien rein proprietär (Microsoft), rein Open Source (Univention) und gemischt proprietär und Open Source (Novell) repräsentieren.
Bei allen drei Lösungen handelt es sich um Komponenten-basierte Gesamtsysteme mit
unterschiedlich hohem Integrationsgrad. Ihre Hersteller versprechen im Vergleich zu
Lösungen, die aus projektspezifisch und manuell miteinander verbundenen Einzelkomponenten bestehen, durch Integration und Eigenschaften wie „Single-Point-ofAdministration― Vorteile hinsichtlich Wirtschaftlichkeit, Sicherheit, Verfügbarkeit und Administrationsaufwänden.
Die Lösungen bestehen jeweils im Wesentlichen aus den folgenden Komponenten: Serverbetriebssystem, Verzeichnisdienst für Identity- und zum Teil auch Infrastrukturmanagement, Anmelde-, Datei- und Druckdienste, E-Mail- und Kalenderdienste, System zum
IP-Management, Software- und Updatemanagement sowie Clientbetriebssystem mit
Officepaket, Mail- und Kalenderclient sowie Webbrowser. Damit decken die Lösungen
den Basisinfrastrukturbedarf von Organisationen einschließlich der zum Betrieb notwendigen Managementwerkzeuge ab.
3.7.1
Microsoft
Microsoft liefert ein System aufeinander abgestimmter und miteinander integrierter Softwareprodukte, welche die genannten Komponenten bereitstellen. Im Einzelnen sind dies:
Windows 2003 Server, Microsoft Operations Manager12 und Systems Management Server13 sowie Microsoft Exchange 2007 und Windows XP/Vista, einschließlich Microsoft
Internet Explorer sowie Microsoft Office 2007 einschließlich Microsoft Outlook.
Die entsprechenden Produkte werden an anderen Stellen (siehe Themen der Module II
und III) dieses Werkes ausführlich behandelt, sodass an dieser Stelle auf eine wiederholende Beschreibung verzichtet wird.
3.7.2
Novell
Vergleichbar zu Microsoft liefert auch Novell ein System aufeinander abgestimmter und
miteinander integrierter Softwareprodukte. Die oben genannten Funktionen werden hier
durch die Produkte SUSE Linux Enterprise Server 10, Open Enterprise Server 2,
Groupwise 7, ZenWorks, SUSE Linux Enterprise Desktop 10 mit integriertem OfficePaket OpenOffice.org, Mail- und Kalenderclient Evolution und Webbrowser Mozilla
Firefox bereitgestellt. Die entsprechenden Einzelprodukte werden von Novell unter dem
Namen „Open Workgroup Suite― auch als integrierte Gesamtlösung vertrieben.
Ergänzende Informationen findet man auf den Webseiten von Novell über den Link
http://www.novell.com/products/openworkgroupsuite/.
SUSE Linux Enterprise Server
Die dabei von Novell verwendeten Client- und Serverbetriebssystemen SUSE Linux Enterprise Server (SLES) beziehungsweise -Desktop (SLED) sind Linux-Distributionen, die
vom Hersteller komplett als Open Source Software veröffentlicht und im Rahmen eines
Maintenance- (oder Abo-) Modells vertrieben werden.
12
13
System Center Operations Manager 2007 ist die aktuelle Version
System Center Configuration Manager 2007 ist die aktuelle Version
Seite 34
Open Enterprise Server
Mit „Open Enterprise Server― (OES) bietet Novell auf der Grundlage von SLES als Serverbetriebssystem einen großen Teil der in der Vergangenheit ausschließlich mit Novell
Netware gelieferten Serveranwendungen, wie den Verzeichnisdienst eDirectory, IPManagementdienste (DHCP, DNS), Datei- und Druckdienste sowie die dazu gehörenden
Managementwerkzeuge. Dadurch wird Anwendern der „klassischen― Novell-Produkte ein
möglichst einfacher Weg geboten, nach Linux als Betriebssystemplattform zu migrieren,
während aufbauend darauf weiterhin die gleichen, proprietären Dienste genutzt werden
können. Gleichzeitig erweitert OES den Leistungsumfang klassischer LinuxServerdistributionen um die Novell-spezifischen Dienste wie Novell iFolder oder Novell
iPrint.
Groupwise
Mit Novell Groupwise ist ein Groupwaresystem in die Gesamtlösung integriert, welches
SLES als Betriebssystemgrundlage und den in OES enthaltenen Verzeichnisdienst eDirectory zur Verwaltung u.a. von Benutzern und E-Mail-Konten nutzt. Groupwise bietet die
für Groupwaresysteme typischen Funktionen E-Mail, Kalender- und Kontaktverwaltung
sowie Aufgaben- und Dokumentenverwaltung an. Darüber hinaus ist eine InstantMessaging-Lösung enthalten. Auf Groupwise kann mit einem eigenen Client für Windows sowie über einen Konnektor von Microsoft Outlook und von Linux aus mit Novell
Evolution zugegriffen werden. Das System unterstützt außerdem eine Reihe mobiler
Geräte.
ZenWorks
Für das Client- und Softwaremanagement ist mit Novell ZenWorks ein weiteres Produkt
in die Lösung integriert. Wie Groupwise verwendet ZenWorks standardmäßig den Verzeichnisdienst eDirectory als Basis für das Identity- und Infrastrukturmanagement. ZenWorks ermöglicht das Konfigurations- und Softwaremanagement von Windows- und Linux-basierten Clients und bringt u.a. Funktionen zur Inventarisierung mit.
SuSE Linux Enterprise Desktop
Der SuSE Linux Enterprise Desktop (SLED) ist eine auf den Einsatz am Arbeitsplatz
optimierte Linux-Distribution, welches Komponenten wie OpenOffice.org, den Mail-Client
Evolution oder den Webbrowser Mozilla Firefox bereits in einer vorkonfigurierten und auf
die Gesamtlösung abgestimmten Variante enthält. Das Desktop-System ist als Client für
die übrigen Komponenten konzeptioniert und kann durch diese zentral verwaltet werden.
Im Vergleich zu den Lösungen von Microsoft und Univention kann das Softwaresystem
von Novell als eine Art Mittelweg angesehen werden: Während die Betriebssystemplattform von Server und Client zwar Open Source sind und die typischen Open Source
Programme und Dienste enthalten, werden die darauf aufsetzenden Dienste wie Verzeichnisdienst, Software- und Clientmanagement oder Groupwaresystem sowie die entsprechenden Managementwerkzeuge wie bei Microsoft als proprietäre Software geliefert.
Seite 35
3.7.3
Univention Corporate Server
Univention bietet mit Univention Corporate Server eine mit den Systemen von Novell und
Microsoft vergleichbare, integrierte Infrastrukturlösung an, die vollständig als Open Source Software veröffentlicht wird. Die genannten Funktionen werden von den folgenden
UCS-Komponenten zur Verfügung gestellt: UCS-Basissystem, UCS-Managementsystem
mit Univention Directory Manager, „Kolab für UCS― sowie Univention Corporate Desktop
(UCD) mit dem Office-Paket OpenOffice.org, dem Mail- und Kalenderclient KDE Kontact
sowie dem Webbrowser Mozilla Firefox.
UCS-Basissystem
Die Basis von Univention Corporate Server (UCS) bildet eine Linux-Distribution, das
sogenannte UCS-Basissystem. Das UCS-Basissystem basiert auf der freien LinuxDistribution Debian GNU/Linux und ist in weiten Teilen identisch damit. Univention
verwendet darin jedoch einige als Open Source Software veröffentlichte Eigenentwicklungen, wie einen eigenen Installer und ein eigenes Konfigurationsmanagement.
UCS-Managementsystem
Aufbauend auf der Kerndistribution liefert Univention mit dem sogenannten UCSManagementsystem ein Identity- und Infrastrukturmanagementsystem, das weitverbreitete Open Source Komponenten, wie den Verzeichnisdienst OpenLDAP, Heimdal Kerberos oder OpenSSL als Basis benutzt.
Ähnlich wie die auf Active Directory beziehungsweise eDirectory aufbauenden Identityund Infrastrukturmanagementsysteme von Microsoft beziehungsweise Novell, kann das
UCS-Managementsystem flexibel genutzt werden, um darin unterschiedliche Objekte,
Standorte, Richtlinien oder organisatorische Einheiten zu verwalten.
Es enthält einen Konnektor zu Microsoft Active Directory, mit dem viele Aspekte von
Active Directory über das UCS-Managementsystem verwaltet werden können und umgekehrt. Dieser Konnektor unterstützt vor allem Migrationen von Microsoft-Systemen
nach UCS sowie den dauerhaften Parallelbetrieb. Auch die Anbindung anderer Systeme
und Verzeichnisdienste ist über verschiedene Schnittstellen und APIs möglich.
Die Bedienung des UCS-Managementsystems kann sowohl über den Web-basierten
UCS Directory Manager als auch ein Kommandozeilen-orientiertes Interface vorgenommen werden.
Eine Besonderheit des UCS-Managementsystems ist der sogenannte LDAP-ListenerMechanismus. Damit können auf UCS-Systemen Plugins registriert werden, die das System dann aufruft, wenn bestimmte im Plugin definierte Objekte (wie zum Beispiel Benutzer, Gruppen oder Rechner) erzeugt, modifiziert oder geändert werden.
Das UCS-Managementsystem verwendet intern ein Domänenkonzept, das sich konzeptionell an den von Microsoft Windows her bekannten „Domänen― orientiert. Analog zu
den Systemen von Microsoft und Novell lassen sich so anspruchsvolle, über viele Standorte verteilte IT-Infrastrukturen zentral verwalten (siehe Abbildung „UCS-Umgebung―)
Seite 36
UCS-Module
Univention und andere Hersteller liefern Module, mit denen bestimmte Dienste oder
Programme in das UCS-Managementsystem integriert und darüber administrierbar gemacht werden. Wichtige von Univention gelieferte Module sind:
Services für Windows: Dieses Modul stellt auf der Basis von Samba und anderen Open
Source Komponenten alle für Rollout und Betrieb von Windows-basierten Clients und
Servern benötigten Funktionen zur Verfügung.
Univention Corporate Desktop ist ein auf KDE basierender in UCS enthaltener Desktop,
der über das UCS-Managementsystem hinsichtlich von Eigenschaften wie über Menüs
zugängliche Funktionen, Desktop-Icons, Drucker- und Sharezuordnungen, Nutzerberechtigungen usw. administriert wird.
Kolab für UCS ist eine in UCS integrierte Variante des Open Source Groupwaresystems
Kolab 2 auf das von verschiedenen Clients wie KDE Kontact, Microsoft Outlook, webbasiert oder mobil zugegriffen werden kann.
Eine weitergehende Beschreibung der UCS-Module ist auf den Webseiten von Univention verfügbar (www.univention.de). Module anderer Hersteller sind u.a.: die Groupwaresysteme Scalix und Zarafa sowie die Softwareverteilung und -inventarisierung OPSI .
3.7.4
Komponenten- und Protokollübersicht
Die folgende Tabelle zeigt, welche Produkte oder Produktkomponenten die jeweiligen
Hersteller zur Bereitstellung der oben aufgeführten Funktionen verwenden:
Komponente
Microsoft
Novell
Univention
Serverbetriebssystem
Windows 2003 Server SuSE Linux Enterprise Server 10
Univention Corporate
Server 2.0 (auf Basis
von Debian GNU
Linux „Etch―)
Verzeichnisdienst
Active Directory
eDirectory
OpenLDAP
Anmeldedienste
Kerberos, NTLMv2,
u.a.
NMAS, Kerberos,
NTLMv2, u.a.
Kerberos, NTLMv2
(Samba), PAM, u.a.
Dateidienste
CIFS, NFS
NCP, NFS, CIFS
(Samba)
NFS, CIFS (Samba)
Druckdienste
Windows Druckdiens- iPrint
te
CUPS (Common Unix
Print System)
E-Mail- und Kalenderdienste
Exchange 2007
Groupwise 7
Kolab 2 für UCS
IP-Management
Active Directory
ZenWorks
OpenLDAP, Univention Directory Manager, ISC DHCPD,
ISC DNS
Seite 37
Komponente
Microsoft
Novell
Univention
Software- und UpdateManagement
Active Directory / MSI ZenWorks
OpenLDAP, Univention Directory Manager APT, OPSI für
UCS
Client-Betriebssystem
Windows XP / Windows Vista
SuSE Linux Enterprise Desktop
Univention Corporate
Desktop
Officepaket
Office 2007
OpenOffice.org
OpenOffice.org
Mail- und Kalenderclient
Outlook 2007
Novell Evolution
KDE Kontact
Webbrowser
Internet Explorer
Mozilla Firefox
Mozilla Firefox
Tabelle 2: Übersicht der Komponenten und Protokolle der Beispiele für Integrationslösungen
3.7.5
Integrationsgrad und Herstellerabhängigkeit
Die Systeme von Microsoft und Novell weisen beide einen sehr hohen Integrationsgrad
auf. So sind manche Komponenten wie zum Beispiel Microsoft Exchange und Microsoft
Active Directory zwingend aufeinander angewiesen. Auch bei Novell ist zum Beispiel
ZenWorks zwingend auf den Verzeichnisdienst eDirectory angewiesen.
Bei der Univention-Lösung gibt es zwar im Bereich von Konfiguration und Administration
ebenfalls eine relativ hohe Integration: Die Komponenten können aufeinander abgestimmt installiert werden, sie werden außerdem über einheitliche Mechanismen wie Registratur und Verzeichnisdienst-basiertes Managementsystem einheitlich administriert.
Allerdings unterscheiden sich die verwendeten Komponenten praktisch nicht von den
auch unabhängig von Univention verfügbaren Open Source Komponenten, sodass die
Integration auf Funktions- und Datenebene nur sehr gering ist.
Bezüglich der Lizenzierung ist Univention der einzige Hersteller, der sämtliche Bestandteile der integrierten Gesamtlösung als Open Source Software veröffentlicht. Bei Novell
ist zwar das Basisbetriebssystem (SUSE Linux Enterprise Server, beziehungsweise
Desktop) mit den enthaltenen Distributionskomponenten Open Source Software, die
darauf aufbauenden Komponenten von Open Enterprise Server wie eDirectory oder
Groupwise sind aber proprietär und werden nicht im Quellcode veröffentlicht. Microsoft
stellt keine der hier betrachteten Komponenten unter einer Open Source Lizenz zur Verfügung.
Aufgrund des Umstands, dass die Integrationstiefe bei Univention im Vergleich zu den
Systemen von Microsoft und Novell eher gering ist und weil Univention alle Bestandteile
als Open Source Software mitliefert, ist hier die Verwendung alternativer Komponenten
beziehungsweise die alleinstehende Verwendung einzelner UCS-Komponenten am
ehesten möglich, die Herstellerabhängigkeit also am geringsten, wenngleich dann die
Vorteile der Integrationslösung zumindest teilweise verloren gehen können.
Die folgende Tabelle stellt die zur Beurteilung integrierter Lösungen relevanter Fragen
am Beispiel der skizzierten Infrastrukturlösungen von Microsoft, Novell und Univention
im Überblick dar:
Seite 38
Kriterium
Welcher Integrationsgrad
besteht?
Microsoft
hoch
Novell
Univention
mittel bis hoch
leicht bis mittel
Ist die technische Realisie- teilweise
rung der Integration öffentlich dokumentiert?
teilweise
teilweise / durch
Quellcode vollständig
Ist der Einsatz alternativer
Komponenten technisch
möglich?
teilweise
teilweise
vollständig
Verwendet die Lösung
ausschließlich Standardprotokolle und Schnittstellen?
nein
nein
ja
Handelt es sich bei den
nein
Integrationskomponenten
um Open Source Software, deren Quellcode
einsehbar und veränderbar
ist?
teilweise
ja
Werden proprietäre, nicht
offengelegte oder lizenzpflichtige Protokolle verwendet?
teilweise
teilweise
nein
Sind die verwendeten Pro- teilweise
tokolle offen und frei zugänglich dokumentiert?
teilweise
ja
Tabelle 3: Beurteilung des Integrationsgrades der Beispiellösungen
3.8
Fazit
Die Verwendung integrierter Lösungen bietet aus der Sicht von IT-Anwendern eine Menge Vorteile: Die Komponenten passen zueinander, es reduzieren sich Konzeptions-,
Test- und Implementierungsaufwände und während des Betriebs sind integrierte Lösungen oft leichter zu supporten und zu warten.
Gleichzeitig bringen integrierte Lösungen die Gefahr der Herstellerabhängigkeit mit sich.
Insbesondere die Integrationstiefe, aber auch die Frage, in wie weit trotz Integration
standardisierter Schnittstellen und Protokolle verwendet werden, können bei der Beurteilung der Frage helfen, in wie weit man sich mit einer integrierten Lösung tatsächlich in
die Abhängigkeit zu einem Hersteller begibt. Grundsätzlich ist diese Abhängigkeit auch
dann geringer, wenn die entsprechende Lösung als Open Source Software veröffentlicht
wird. In diesem Fall besteht jederzeit die Möglichkeit den Source Code zu analysieren
und ihn zu verändern, sei es nun, dass dies die Behörde selbst tut oder einen beliebigen
und geeigneten Dienstleister damit beauftragt.
Seite 39
Am Beispiel von Univention Corporate Server und in weiten Teilen auch bei der von Novell angebotenen Lösung zeigt sich, dass im Umfeld von Linux und Open Source Software mittlerweile ebenfalls integrierte Systeme verfügbar sind, die viele der Vorteile der
aufeinander ausgerichteten Systembestandteile von Microsoft bieten, aber durch geringere Integrationstiefe und Open Source Lizenzierung eine deutlich geringere Herstellerabhängigkeit mit sich bringen.
Seite 40
B Thema: Rechtliche Aspekte von Softwaremigrationen
1
Einleitung
Die Wahl einer Behörde zwischen einer Migration zu proprietärer und einer Migration zu
Open Source Software (OSS) beruht in erster Linie auf technischen und wirtschaftlichen
Kriterien. Die Entwicklungen der letzten Jahre haben dagegen gezeigt, dass die
rechtlichen Aspekte eine eher untergeordnete Rolle spielen. Zwar verweisen die
Anbieter proprietärer Softwareprodukte regelmäßig auf angebliche rechtliche Risiken für
die Nutzer bei der Verwendung von OSS, bei näherer Betrachtung liefern die
Rechtsfragen jedoch keine entscheidungserheblichen Argumente, die gegen den Einsatz
von OSS sprechen.
Zahlreiche Behörden und Unternehmen setzen seit Jahren OSS ein, ohne dass es zu
einer Realisierung der immer wieder betonten Risiken gekommen wäre. Zudem haben
mehrere deutsche Gerichte in den letzten Jahren die Tragfähigkeit des Lizenzmodells
nach deutschem Recht bestätigt14. Auch hat der Gesetzgeber mittlerweile vier Sondervorschriften zugunsten des OSS-Lizenzmodells in das Urheberrechtsgesetz aufgenommen15, welche zu einer Klärung der dort behandelten Einzelfragen geführt und den
Willen des Gesetzgebers gezeigt haben, das Lizenzmodell durch legislative Änderungen
zu stärken. Die Rechtsprobleme beim Einsatz von OSS haben sich in den letzten Jahren
in der Praxis deshalb als überschaubar erwiesen. Das Argument „Rechtsrisiko OSS―
wird zusätzlich relativiert, wenn man die rechtliche Situation bei OSS mit den möglichen
Rechtsproblemen beim Einsatz von proprietärer Software vergleicht. Auch beim Einsatz
herkömmlich lizenzierter Programme sind zahlreiche rechtliche Risiken zu beachten.
Schließlich gilt es, die spezifischen rechtlichen Vorteile zu berücksichtigen, die der
Einsatz von OSS mit sich bringen kann. Behörden können beim Einsatz von OSS sehr
weitreichende Nutzungsrechte und dadurch strategische Vorteile erwerben.
Das folgende Kapitel will den Entscheidern in Behörden die für die Auswahlentscheidung
notwendigen rechtlichen Basisinformationen vermitteln. Die Migration zu OSS oder zu
proprietärer Software bringt es mit sich, dass die Behörde mit neuen Vertragspartnern
zusammenarbeiten muss. Das Profil der in Anspruch genommenen Dienstleistungen
ändert sich, das Gleiche gilt für die rechtliche Bewertung dieser Vertragsverhältnisse.
Hierbei sind auch urheber- und patentrechtliche Fragen zu beurteilen. Zudem gilt es Haftungsrisiken zu evaluieren und zu fragen, welche Ansprüche die Behörde gegenüber
ihren Vertragspartnern und Dritten geltend machen kann, wenn die eingesetzten Programme fehlerhaft sind oder einer Nutzung Rechte Dritter entgegenstehen. Schließlich
sind die Beschaffungsvorgänge so zu gestalten, dass Ausschreibungen und Vergabeentscheidungen den Anforderungen des Vergaberechts entsprechen. Dabei sind jeweils
14
15
Siehe insb. Landgericht München, Urteil vom 19.05.2004, AZ 21 O 6123/04, Computer und
Recht 2004,S. 774; LG Frankfurt a.M., Urteil v. 06.09.2006, AZ 2-6 O 224/06, Computer
und Recht 2006, S. 729; LG München, Urteil v. 12.07.2007, AZ 7 O 5245/07, Computer und
Recht 2008, 57 (nicht rechtskräftig).
Siehe §§ 31a Abs. 1 S. 2, 32 Abs. 3 S. 3, 32a Abs. 3 S. 3, 32c Abs. 3 S. 3 UrhG.
Seite 41
die rechtlichen Risiken und Chancen des Einsatzes von OSS oder proprietärer Software
miteinander zu vergleichen.
Im Folgenden soll die Behörde als Nutzer von Informationstechnologie im Vordergrund
stehen. Fragen, die sich bei der Entwicklung und beim Vertrieb von OSS durch Behörden ergeben, werden dagegen nur am Rande betrachtet. Sie liegen außerhalb des
Fokus des Migrationsleitfadens. Das Kapitel wird vier Fragenkomplexe schwerpunktmäßig beleuchten:
2

Vertragsrecht

Urheber- und Patentrecht

Haftung und Gewährleistung

Vergaberecht
Methode
Grundsätzlich werden bei den rechtlichen Fragestellungen beide Migrationswege
betrachtet. Als Ausgangspunkt bei der Betrachtung der genannten Unterthemen soll die
rechtliche Situation bei einer Nutzung von OSS untersucht werden. Am Ende der
einzelnen Abschnitte werden vergleichende Hinweise zur Situation bei einer Migration zu
proprietärer Software gegeben. Die rechtlichen Besonderheiten, die sich bei der Nutzung
von OSS ergeben, stehen im Vordergrund. Diese Schwerpunktbildung ist gerechtfertigt,
weil sich bei einer Migration zu proprietärer Software für die Behörde zumeist keine
Unterschiede zur Ausgangslage ergeben. Dagegen bringt die Migration zu OSS
erhebliche Veränderungen für die Rechtslage mit sich. Vor diesem Hintergrund ist es
verständlich, dass Entscheider primär Fragen zu der Rechtslage der OSS haben. Der
Migrationsleitfaden richtet sich an diesem Interessenschwerpunkt aus.
Die Rechtsfragen der OSS haben in den letzten Jahren zu einer regelrechten Flut juristischer Fachveröffentlichungen geführt16. Hinzukommen die bereits erwähnten Entscheidungen deutscher Gerichte, welche die Wirksamkeit zentraler Aspekte der GPL bestätigt
haben. Es ist dennoch darauf hinzuweisen, dass bislang keine höchstrichterlichen Entscheidungen zu den Rechtsfragen der OSS ergangen sind, welche die hier dargestellten
Rechtsfragen abschließend geklärt hätten. Zudem werden in der stark akademisch geprägten Fachliteratur einige Fragen uneinheitlich beurteilt. Es ist nicht die Aufgabe dieses Leitfadens sein, jedes Detail dieser juristischen Fachdiskussion nachzuzeichnen,
vielmehr soll eine nachvollziehbare Darstellung und kurze Erläuterung der jeweils vorherrschenden Auffassung die Leser bei ihren Entscheidungen unterstützen. Abweichungen in der juristischen Fachliteratur zu einzelnen Fragen sind also möglich.
3
Notwendigkeit der Rechtsberatung im Einzelfall
Der Abschnitt zu den rechtlichen Aspekten verfolgt zwei Ziele. Er will zum einen dabei
helfen, unberechtigten Ängsten durch gezielte Informationen entgegenzutreten. Zum
anderen erscheint es als notwendig, dort auf rechtliche Probleme hinzuweisen, wo sie
16
Eine Auflistung von ca. 60 deutschsprachigen und zahlreichen fremdsprachigen Beiträgen
findet sich unter http://www.ifross.de.
Seite 42
tatsächlich bestehen. Wo eines der aufgezeigten Rechtsprobleme auftritt, kann der Migrationsleitfaden eine individuelle Rechtsberatung nicht ersetzen. Hier müssen die Behörden auf Rechtsämter, Rechtsabteilungen oder externen Sachverstand, insbesondere
Rechtsanwälte zurückgreifen. Dies gilt auch für die Vertragsgestaltung im Einzelfall.
4
4.1
Vertragsrecht
Einleitung
Ein regelmäßig gegen den Einsatz von OSS vorgebrachtes Argument betrifft die
angeblich unklaren Vertragsverhältnisse. Anbieter proprietärer Programme weisen oft
darauf hin, dass Behörden bei ihrem Vertriebsmodell alles aus einer Hand erwerben
können, wodurch die Ansprechpartner für die Behörden fest stehen, während der Nutzer
bei
OSS
einer
dezentralen,
weltweit
verstreuten
Entwicklergemeinschaft
gegenüberstehe, sodass die Verantwortlichen, etwa bei einem Haftungs- oder
Gewährleistungsfall, nicht zu erreichen seien. Betrachtet man die Vertragsverhältnisse
beim Erwerb von OSS im Einzelnen, so erweist sich das Argument als nicht stichhaltig.
In der typischen Fallgestaltung, in der eine Behörde OSS bei einem Zwischenhändler
oder Serviceanbieter erwirbt, um sie bestimmungsgemäß einzusetzen, kommt es nur zu
einem Vertragsschluss mit ebendiesem Zwischenhändler oder Serviceanbieter. Die
rechtliche Situation ist dann weder komplexer noch rechtlich nachteilhafter als bei
proprietärer Software.
Bei Softwareüberlassungsverträgen sind grundsätzlich zwei Vertragsgegenstände zu
unterscheiden: Die Software als solche, also die Bits und Bytes und die Nutzungsrechte
an der Software, welche oftmals entsprechend internationaler Sprachgewohnheiten als
Einräumung einer "Lizenz" bezeichnet wird. Die Lizenz kann dem Nutzer Unterschiedliches gestatten. Sie kann das einfache Laufenlassen der Software gestatten, sie kann
dem Nutzer aber auch Entwicklungs- und Vertriebsbefugnisse einräumen. Proprietäre
Softwarelizenzen erlauben in der Regel nur das Ablaufenlassen des Programms; OSSLizenzen sind demgegenüber durch besonders weitgehende Rechtseinräumungen gekennzeichnet.
Typischerweise erhält der Nutzer von OSS die Software als solche nicht direkt von den
Rechtsinhabern, also den Inhabern der geistigen Eigentumsrechte an OSS - das sind die
Entwickler oder Unternehmen, die die Programme erstellt haben. Der Nutzer wird in aller
Regel eine Distribution erwerben, und zwar entweder vom Distributor direkt oder von
einem Dienstleister. Gerade für kleinere Behörden ebenfalls denkbar, aber praktisch
weniger relevant, dürfte der Erwerb einer Distribution im Einzelhandel sein. In allen genannten Konstellationen fallen der Erwerb der Rechte vom Rechtsinhaber einerseits und
der Erwerb der Bits und Bytes andererseits auseinander. Es handelt sich deshalb typischerweise um ein Dreipersonenverhältnis zwischen Nutzer, Rechtsinhaber und Zwischenhändler (Distributor, Softwarehaus, Beratungsunternehmen, Einzelhandel, Dienstleister) mit jeweils rechtlich unabhängigen Vertragsverhältnissen:
Seite 43
Nutzer
Rechteinhaber
Zwischenhändler
Abbildung 2: Vertragsverhältnisse
Der Nutzer braucht für die Benutzung der Software zunächst lediglich einen Vertrag mit
dem Zwischenhändler, auf dessen Grundlage er die Software als solche erwirbt. Bereits
durch den Erwerb einer rechtmäßig in Verkehr gebrachten Programmkopie erwirbt der
Nutzer die Befugnis, das Programm bestimmungsgemäß zu benutzen.
Möchte der Nutzer die zusätzlichen Rechte aus der GPL oder einer anderen OSS-Lizenz
wahrnehmen, so muss er einen weiteren Vertrag abschließen, diesmal mit den Rechtsinhabern. Nur wenn eine solche Nutzung der OSS gewünscht wird, ist die OSS-Lizenz
überhaupt relevant. Möchte der Nutzer die Software dagegen nur ablaufen lassen, so
bedarf es nicht des Abschlusses eines Lizenzvertrags mit den Rechtsinhabern.
Die wichtigsten OSS-Lizenzen (GPL Version 217, GPL Version 318 und Lesser GPL
Version 319) klammern die einfache Benutzung des Programms aus ihrem Anwendungsbereich aus, vgl. Ziffer 0 Absatz 2 GPL Version 2 ("Activities other than copying,
distribution and modification are not covered by this license; they are outside its scope.
The act of running the program is not restricted [...].") sowie Ziffer 9 GPL Version 3 ("You
are not required to accept this license in order to receive or run a copy of the Program.").
Dies korrespondiert mit den Regelungen des deutschen Urheberrechts. Gemäß § 69d
Abs. 1 UrhG bedarf es für die "bestimmungsgemäße Benutzung" eines Computerprogramms keiner Lizenz oder sonstigen Erlaubnis des Rechtsinhabers, sofern das
Programm rechtmäßig in Verkehr gebracht worden ist. Solange sich also der Distributor
und der Zwischenhändler an die Bedingungen der Lizenz gehalten haben und der
Vertrieb rechtmäßig gewesen ist, bedarf der Nutzer für die einfache Benutzung des
Programms keines Vertrags mit den Inhabern der Rechte an dem Programm. Die GPL
oder sonstige OSS-Lizenz ist dann irrelevant.
Einige OSS-Lizenzen klammern die einfache Benutzung nicht ausdrücklich aus, dies gilt
insbesondere für BSD Lizenzen20. Dies ändert aber nichts an der Tatsache, dass der
Nutzer eines rechtmäßig in Verkehr gebrachten Programms im Normalfall keiner
weiteren Lizenz bedarf, wenn er das Programm nur bestimmungsgemäß benutzen
17
Siehe http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Siehe http://www.fsf.org/licensing/licenses/gpl.html
19
Siehe http://www.gnu.org/licenses/lgpl.html
20
Siehe http://www.opensource.org/licenses/bsd-license.php
18
Seite 44
möchte. Kommt es nicht zum Abschluss des Lizenzvertrags, so handelt es sich um ein
einfaches Zweipersonenverhältnis zwischen dem Nutzer und dem Dienstleister. Das
heißt, dass von vornherein nur der Dienstleister für vertragliche Ansprüche auf Haftung
und Gewährleistung in Frage kommt.
Zur bestimmungsgemäßen Benutzung gehört nach dem Urheberrechtsgesetz auch das
Erstellen einer Sicherungskopie (§ 69d Abs. 2 UrhG), die Fehlerberichtigung (§ 69d
Abs. 1 UrhG) sowie die Dekompilierung zur Herstellung der Interoperabilität mit anderen
Programmen (§ 69e UrhG). Erst wenn mehr Programmkopien als nur eine Sicherungskopie erstellt und weitergegeben werden oder wenn das Programm jenseits der
Fehlerberichtigung verändert wird, ist der Abschluss eines Lizenzvertrags erforderlich.
Ob die OSS-Lizenzen für die Behörde im Einzelfall von Bedeutung sind, hängt also von
der Art der Nutzung des Programms ab. Wenn eine Behörde zum Beispiel mit einer
einzelnen Linux-Distribution eine Vielzahl von Arbeitsplätzen ausrüstet, so wird man bei
Anwendung des deutschen Urheberrechts von einer Vervielfältigung auszugehen haben,
sodass eine OSS-Lizenz abgeschlossen werden muss. Gleiches gilt für die Weitergabe
von Programmkopien an andere Behörden, die öffentliche Zugänglichmachung in
Datennetzen und die Weiterentwicklung.
Nutzung ohne Lizenzvertrag
Nutzung mit Lizenzvertrag
Ablaufenlassen
Ablaufenlassen
Erstellen Sicherungskopie
Erstellen Sicherungskopie
Fehlerberichtigung
Fehlerberichtigung
Dekompilieren für Interoperabilität
Dekompilieren für Interoperabilität
-
Vervielfältigung
-
Veränderung
-
Verbreitung
-
Öffentlich Zugänglichmachen
Tabelle 4: Relevanz der OSS-Lizenzen für Nutzer
4.2
Vertragsverhältnisse bei OSS: Vertrag mit Zwischenhändler
Für das Verhältnis zwischen der Behörde als Nutzer und demjenigen, von dem sie das
Programm erhalten hat, sind unterschiedliche Fallgestaltungen denkbar, in denen unterschiedliche Gesetzesregelungen anzuwenden sind. Dies ist vor allem für die Haftung
und Gewährleistung von Bedeutung.
In der einfachsten Konstellation erwirbt die Behörde eine Standard-OSS, ohne weitere
Leistungen ihres Vertragspartners in Anspruch zu nehmen. Ist ein Entgelt zu zahlen, so
finden die Vorschriften über den Kaufvertrag Anwendung. Wird die Software dagegen
kostenlos abgegeben, so sind die Vorschriften des Schenkungsrechts maßgeblich. Hierher gehört zum Beispiel der kostenlose Download eines Programms von der Website
eines Distributors. Entsprechende Angebote können auch von Behörden wahrgenommen werden.
Seite 45
Wird das Programm dagegen im Rahmen einer Gesamtleistung überlassen, so ist die
rechtliche Beurteilung schwieriger. Als Grundregel kann hier festgehalten werden, dass
eine künstliche Aufspaltung der einzelnen Teilleistungen in Einzelverträge zum Nachteil
der Behörde vertragsrechtlich nicht möglich ist. Wird etwa Hardware mit vorinstallierter
OSS vertrieben und wird für die Gesamtleistung ein einheitliches Entgelt verlangt, so
handelt es sich um einen einheitlichen Kaufvertrag. Wird dagegen die Software ausdrücklich verschenkt, während die Hardware verkauft wird, so sind die Vorschriften von
Kauf- und Schenkungsvertrag zu kombinieren. Entsprechendes gilt für die Einbindung
der Softwareüberlassung in ein umfassendes Dienstleistungsangebot. Hier wird man die
gesetzlichen Vorschriften zum Dienstleistungsvertrag mit denjenigen des Kauf- oder
Schenkungsvertrags kombinieren müssen, je nach dem, ob für das Programm ein Entgelt zu leisten ist oder nicht.
Die Entwicklung neuer Software kann hier nur im Überblick erläutert werden. Die
Behandlung des Vertrags über die Entwicklung von Individualsoftware ist im juristischen
Schrifttum gegenwärtig stark umstritten. Bis zu einer Klärung durch die Gerichte wird
man damit leben müssen, dass manche von der Anwendung des Werkvertragsrechts
ausgehen, während andere das Kaufvertragsrecht für maßgeblich halten. 21 Soll bestehende OSS im Auftrag einer Behörde weiterentwickelt werden, so hängt die rechtliche
Beurteilung davon ab, ob die vorbestehenden Programmbestandteile bereits bei der
Behörde vorhanden waren oder erst vom Auftragnehmer geliefert wurden. Im ersten Fall
ist von einem isolierten Werk- bzw. Kaufvertrag über die hinzugefügten Programmbestandteile auszugehen, dagegen ist im zweiten Fall ein einheitlicher Vertrag anzunehmen.
Bei Verwendung der EVB-IT bzw. BVB22 ist im Einzelnen zu prüfen, ob die Vertragsbestimmungen im Einklang mit den jeweils maßgeblichen OSS-Lizenzen stehen. Eine unveränderte Heranziehung der Standardverträge kann mitunter problematisch sein. Dies
soll an zwei Beispielen näher dargestellt werden:
Die EVB-IT Überlassung Typ A und Typ B können bei der Beschaffung von StandardOpen Source Software von einem Zwischenhändler nicht ohne Weiteres benutzt werden.
Die genannten Vertragswerke sehen eine Rechtseinräumung durch den Auftragnehmer
(das heißt den Zwischenhändler) vor; dies kommt beim Erwerb von OSS in aller Regel
aber nicht in Frage, da der Zwischenhändler keine entsprechenden Rechte innehat und
deswegen auch keine Nutzungsrechte einräumen kann. Die Klauseln über die Nutzungsrechtseinräumung müssten hier also gestrichen werden, um das Formular benutzen zu
können.
Die BVB-Erstellung kann ohne Veränderung nur verwendet werden, wenn die Behörde
eine völlige Neuentwicklung in Auftrag gibt. Für Aufträge über die Weiterentwicklung von
bereits bestehender GPL-Software bedarf das Vertragsmuster dagegen gewisser Ver-
21
22
Eine aktuelle Übersicht über den Meinungsstand findet sich bei Redeker, IT-Recht (4. Aufl.
2007), S. 91 f.
Abrufbar unter http:///www.kbst.bund.de/.
Seite 46
änderungen: Es enthält Klauseln, die nicht mit den Vorgaben der GPL vereinbar sind
und die dementsprechend gestrichen oder verändert werden müssten23.
Der Vertrag zwischen Behörde und Dienstleister richtet sich immer dann nach deutschem Recht, wenn sowohl die Behörde als auch der Dienstleister ihren Sitz in Deutschland
haben. In diesem Fall richtet sich sowohl die Wirksamkeit der Verträge als auch die vertragliche Haftung und Gewährleistung nach deutschem Recht. Hat der Dienstleister dagegen seinen Sitz im Ausland, so kann ausländisches Recht maßgeblich sein, es sei
denn, die Behörde vereinbart in dem Vertrag eine Rechtswahl zugunsten des deutschen
Rechts. Hierzu ist dringend zu raten. Da für dieses Vertragsverhältnis die OSS-Lizenzen
ohne Bedeutung sind, sind die Parteien in der Vertragsgestaltung im Rahmen der gesetzlichen Möglichkeiten frei.
Art der Leistung des Zwischenhändlers
Vertragstyp
Standard-OSS gegen Entgelt
Kaufvertrag
Standard-OSS kostenlos
Schenkungsvertrag
Kombination Hardware und Standard-OSS:
beide gegen Entgelt oder Software kostenlos
Einheitlicher Kaufvertrag
Neuentwicklung von OSS
Werkvertrag (andere Auffassung: Kauf)
Fortentwicklung von OSS
Werkvertrag (andere Auffassung: Kauf)
Tabelle 5: Vertragsverhältnisse Nutzer-Zwischenhändler
4.3
Vertragsverhältnisse bei OSS: Vertrag mit Rechtsinhabern
Für das bloße Ablaufenlassen des Programms durch die Behörde bedarf es nicht des
Abschlusses von Lizenzverträgen; insoweit kommt es allein zu vertraglichen Verhältnissen mit dem Zwischenhändler, von dem die Behörde die Software erworben hat. Möchte
die Behörde die Software jedoch in einer Weise nutzen, die über eine "bestimmungsgemäße Benutzung" im Sinne des § 69d UrhG hinausgeht, so bedarf sie hierfür
der Zustimmung der Rechtsinhaber. Nur in diesem Fall sind die OSS-Lizenzen überhaupt von praktischer Bedeutung.
Damit die OSS-Lizenzen rechtliche Geltung erlangen, bedarf es eines entsprechenden
Vertragsschlusses, also eines Angebots und der Annahme dieses Angebots. Rechtstechnisch handelt es sich bei einem Programm, welches einer OSS-Lizenz unterstellt
worden ist, um ein Angebot an jedermann auf Abschluss eines Lizenzvertrags mit dem
Inhalt der jeweiligen Lizenzbedingungen (GPL o.ä.). Wer einen solchen Lizenzvertrag
abschließen möchte, kann seine Annahme dadurch erklären, dass er eine Handlung
vornimmt, die nach der Lizenz jedem Lizenznehmer gestattet ist, also eine Vervielfältigung, eine Verbreitung oder eine Veränderung des Programms. Der Lizenzvertrag
kommt durch die bloße Vornahme dieser Handlung automatisch zustande, es bedarf
23
Dies gilt insbesondere für die Nutzungsrechtsklausel in Ziffer 6 und die Regelung im Hinblick auf die Offenlegung der Quelltexte gegenüber dem Auftraggeber.
Seite 47
keines direkten Kontakts mit den Rechtsinhabern per E-Mail oder Ähnlichem. Das
deutsche Vertragsrecht erkennt einen Vertragsschluss an, bei dem der Anbietende auf
den Zugang der Annahme verzichtet24. Einem solchen Vertragsschluss steht auch nicht
entgegen, dass die üblicherweise verwandten OSS-Lizenzen ausschließlich in englischer Sprache rechtlich bindend sind. Dies gilt nach der Entscheidung des Landgerichts
München vom 19.05.200425 und der weit überwiegenden Zahl der juristischen Fachautoren jedenfalls dann, wenn ein Unternehmen oder eine Behörde Lizenznehmer
werden möchte.
Ein vertragsrechtliches Problem besteht bei OSS darin, dass die Rechtsinhaberschaft
oftmals sehr unübersichtlich ist. Dies gilt für alle diejenigen OSS-Programme, die in einer
weit verstreuten Entwicklergemeinschaft geschrieben worden sind. GNU/Linux ist hier
das bekannteste Beispiel. Hunderte Programmierer, die weltweit verstreut sind, haben
an dem Programm mitgearbeitet. Manche haben als freie Entwickler mitgewirkt und sind
Inhaber der Urheberrechte an den Teilen, die sie beigesteuert haben. Andere haben als
angestellte Programmierer gearbeitet. Hier sind in der Regel die Arbeitgeber Inhaber der
wichtigsten Rechte26. Wieder andere haben ihre Rechte auf Organisationen, wie die
Free Software Foundation Europe übertragen, welche die Rechte treuhänderisch wahrnehmen.27 Wer heute eine Lizenz an GNU/Linux erwirbt, schließt mit allen diesen
Rechtsinhabern gleichzeitig identische Verträge mit dem Inhalt der GPL/LGPL ab. Dadurch sind die rechtlichen Verhältnisse in der Theorie kompliziert. In der Praxis ergeben
sich daraus für die Nutzer jedoch keine entscheidungserheblichen Nachteile. Da die
Rechtsinhaber bei einem nach den Bedingungen der GPL lizenzierten Programm alle die
gleichen Vertragsbedingungen verwenden und zur gleichen Zeit den Vertrag mit dem
Nutzer abschließen, macht es für diesen letztlich keinen spürbaren Unterschied, ob er
den Erwerb von Nutzungsrechten an dem Programm von einem oder von mehreren
Rechtsinhabern angeboten bekommt.
Zudem tritt das Problem einer weit verstreuten Gemeinschaft von Rechtsinhabern nicht
bei allen OSS-Programmen in gleichem Maße auf. Einige der am häufigsten genutzten
Programme wurden in Unternehmen entwickelt und erst später nach den Bedingungen
einer OSS-Lizenz freigegeben. Dies trifft zum Beispiel für OpenOffice.org zu. Hier liegen
die Rechte an den wichtigsten Bestandteilen bei einem Unternehmen, dementsprechend
sind die Vertragsverhältnisse einfacher.
Im Hinblick auf das anwendbare Recht muss für die Lizenzverträge differenziert werden.
Alle (Vor-)Fragen des Urheber- und Patentrechts, also insbesondere, ob entsprechende
Rechte bestehen, wer Inhaber des Rechts ist, unter welchen Voraussetzungen Lizenzen
eingeräumt werden können, richten sich nach deutschem Recht, sofern die jeweils in
Frage stehende Nutzungshandlung (Vervielfältigung, Verbreitung, Veränderung etc.) in
Deutschland stattfindet. Für die vertragsrechtlichen Fragen, insbesondere die Voraussetzungen des Vertragsschlusses, die Auslegung der Lizenzen, die vertragliche Haftung
und Gewährleistung, findet dagegen deutsches Recht nur dann Anwendung, wenn die
24
25
26
27
Vgl. § 151 BGB.
Vgl. Landgericht München, Urteil vom 19.05.2004, siehe oben Fn. ■
Vgl. § 69b UrhG.
Vgl. das entsprechende Projekt der Free Software Foundation Europe unter
http://www.germany.fsfeurope.org/projects/ftf/fla.de.html.
Seite 48
Rechtsinhaber ihren Sitz oder gewöhnlichen Aufenthalt in Deutschland haben. Oft werden die Rechtsinhaber aber nicht in Deutschland sitzen, sondern in den USA oder einem
anderen Land. Dann findet das jeweilige ausländische Recht auf die genannten Fragen
Anwendung. Hier kann zumeist auch eine Rechtswahlklausel nicht weiterhelfen. Wenn
die Rechte an einem Programm bei einer weltweiten Entwicklergemeinschaft liegen,
dürfte es kaum möglich sein, Sondervereinbarungen jenseits der standardisierten OSSLizenzen zu erreichen. Liegen die Rechte hingegen bei einem Unternehmen oder einer
kleineren Community, ist es ggf. möglich, eine Sondervereinbarung zum anwendbaren
Recht zu erreichen.28
Rechtsfrage
Vertrag mit
Zwischenhändler
Zustandekommen des
Vertrags
Auslegung
Anwendbares Recht
Recht des Landes, in dem
Zwischenhändler seinen Sitz
hat
Rechtsfolgen bei Nichtleistung
Vertragliche Haftung und
Gewährleistung
Vertrag mit
Rechtsinhabern
Zustandekommen des
Vertrags
Recht des Landes, in dem der
Rechtsinhaber seinen Sitz hat
Auslegung
Rechtsfolgen bei entgegenstehenden Rechten Dritter
Schutzfähigkeit des Werks
bzw. der Erfindung
Bestehen von Urheber- und
Patentrechten
Recht des Landes, für das
Schutz beansprucht wird (= in
dem urheber- bzw. patentrechtlich relevante Handlungen stattgefunden haben)
Rechtsinhaberschaft
Übertragbarkeit
Lizenzierbarkeit
Tabelle 6: Anwendbares Recht
4.4
Vergleich der Migration zu proprietärer Software und zu OSS
Glaubt man den Aussagen der Anbieter von proprietärer Software, so sind die Vertragsverhältnisse bei der Nutzung proprietärer Software einfacher als bei OSS und dadurch
vorteilhafter. Dies trifft aber nur in bestimmten Fallkonstellationen zu, bei anderen Sachverhaltsgestaltungen sind die Vertragsverhältnisse proprietärer Software mit Nachteilen
gegenüber OSS verbunden. Es ist deswegen notwendig zu differenzieren.
28
Beispielsweise MySQL bietet zwei Lizenzmöglichkeiten an. Nutzer können die Software
entweder nach den Bestimmungen der GPL nutzen oder eine "Commercial license" erwerben, vgl. http://www.mysql.com/company/legal/licensing. Hier sind dann ggf. auch Rechtswahlklauseln möglich.
Seite 49
Bei beiden Vertriebsmodellen sind Konstellationen möglich, in denen die Behörde nur
einen Vertrag mit einem Vertragspartner für die Softwareüberlassung abschließen muss.
In bestimmten Fällen wird der Inhaber der Rechte an einer proprietären Software diese
der Behörde auch direkt überlassen. In diesem Fall handelt es sich um einen Vertrag
zwischen zwei (juristischen) Personen, in dem sowohl die Überlassung der Bits und
Bytes als auch die Einräumung von Nutzungsrechten geregelt sind.29 Dies hat den
Vorteil der Übersichtlichkeit und Einfachheit. Solange die Behörde die Software nur
bestimmungsgemäß benutzt, hat es allerdings auch bei OSS mit einem solchen
Zweipersonenverhältnis sein Bewenden. Denn bei einer bloß bestimmungsgemäßen
Benutzung von OSS durch Behörden (und damit im Regelfall) werden keine Lizenzverträge mit den Rechtsinhabern abgeschlossen.
Handelt es sich dagegen um ein Dreipersonenverhältnis zwischen Nutzer, Rechtsinhaber und Zwischenhändler, so sind die rechtlichen Probleme bei proprietärer Software
größer. Proprietäre Software wird nicht immer im Zweipersonenverhältnis überlassen.
Gerade kleinere Behörden werden Software oft nicht direkt beim Rechtsinhaber erwerben, sondern im Einzelhandel oder über sonstige lokale Dienstleister. In diesem Fall
kann es ebenfalls zu Dreipersonenverhältnissen kommen, und zwar dann, wenn der
Rechtsinhaber den Abschluss eines Lizenzvertrags wünscht. Anbieter proprietärer Programme verlangen regelmäßig vom Erwerber einer Standardsoftware, dass dieser neben
dem Kaufvertrag mit dem Einzelhändler ein zusätzliches "End User License Agreement"
(EULA) mit dem Rechtsinhaber direkt abschließt. Dieser Lizenzvertrag soll typischerweise durch das Anwählen eines "o.k."-Buttons oder die Benutzung der Software zustande
kommen.30 Die Wirksamkeit entsprechender Verträge wird von namhaften Fachautoren
mit guten Argumenten verneint.31 Gerichtsentscheidungen liegen hierzu allerdings nicht
vor. Es fehlt an entsprechenden Klagen der Rechtsinhaber gegen die Kunden auf Einhaltung der oftmals restriktiven Lizenzverträge.
Demgegenüber ist der Vertrieb von OSS über Einzel- oder Zwischenhändler beziehungsweise Dienstleister weniger problematisch. Solange die Behörde die Software
lediglich bestimmungsgemäß benutzt, kommt es überhaupt nicht zum Abschluss eines
Lizenzvertrags mit den Rechtsinhabern. Ist aber ein Lizenzvertrag erforderlich, weil die
Behörde die Rechte aus der GPL oder einer anderen OSS-Lizenz wahrnehmen möchte
(etwa weil man Vervielfältigungen oder Veränderungen des Programms vornehmen
möchte), so wirft das dadurch entstehende Dreipersonenverhältnis weniger rechtliche
Probleme auf als im Fall der EULAs. Während die OSS-Lizenz dem Nutzer Rechte
einräumt, die über die bereits nach dem Gesetz erlaubte bestimmungsgemäße
Benutzung hinausgehen, beschränken EULAs diese Rechte, indem Weitergabeverbote,
CPU-Klauseln und Ähnliches zulasten des Nutzers vereinbart werden. Warum aber
sollte ein Nutzer, der durch den Erwerb einer rechtmäßig in Verkehr gebrachten
Programmkopie bereits das Recht zur bestimmungsgemäßen Benutzung gemäß §§ 69d
29
30
31
Vgl. z.B. die hierauf zugeschnittenen EVB-IT Überlassung Typ A, abrufbar unter
http//www.kbst.bund.de/.
Vgl. zu den heute üblichen Vertragsgestaltungen in diesem Bereich exemplarisch Marly,
Softwareüberlassungverträge (4. Aufl. 2003), S. 213 ff. mit zahlreichen Beispielen aus der
Vertragspraxis.
So im Ergebnis auch Marly, a.a.O., S. 225; vgl. auch Dreier/Schulze, Urheberrechtsgesetz
(2. Aufl. 2006), § 69c, Rz. 33; Redeker, IT-Recht (4. Aufl. 2007), S. 170 f.
Seite 50
und § 69e UrhG erworben hat, nachträglich einer Beschränkung dieser Rechte zustimmen wollen? Es ist mehr als fragwürdig, ein Anwählen des "o.k."-Buttons als Zustimmung zu werten, wenn dem Nutzer keine andere Möglichkeit offensteht, die bereits
erworbene Software überhaupt verwenden zu können. Diese spezifischen Probleme der
EULAs treffen auf OSS-Lizenzen nicht zu.
5
5.1
Urheberrecht
Einleitung
Eine zweite Gruppe von rechtlichen Argumenten, die angeblich gegen den Einsatz von
OSS sprechen, betrifft urheberrechtliche Fragen. So wird von Anbietern proprietärer
Lösungen häufig ins Feld geführt, dass die Rechtseinräumung in den üblicherweise
genutzten OSS-Lizenzen nicht mit dem deutschen Urheberrecht vereinbar sei. Auch wird
auf ein erhöhtes Risiko der Verletzung von Urheberrechten Dritter beim Einsatz von OSS
und daraus folgende Schadensersatzansprüche verwiesen. Die in diesem Zusammenhang genannten Rechtsfragen führen in der Praxis jedoch zu keinen nennenswerten
Gefahren für die Nutzer. Im Vergleich zu üblichen Lizenzbedingungen proprietärer Software zeigt sich vielmehr, dass die Nutzung von OSS für Behörden in urheberrechtlicher
Sicht von Vorteil ist.
5.2
Zulässigkeit von OSS-Lizenzen nach deutschem Urheberrecht
Sofern es für eine Behörde notwendig ist, eine OSS-Lizenz abzuschließen, stellt sich die
Frage nach der urheberrechtlichen Zulässigkeit der in den Lizenzen geregelten Rechte
und Pflichten. Dies ist von Bedeutung für die Planungssicherheit im Hinblick auf die
erworbenen Rechte und die damit einhergehenden Pflichten.
Will man die Fülle der hierzu erschienenen Fachveröffentlichungen in einem Satz
zusammenfassen, so könnte man festhalten, dass die GPL und die anderen weitverbreiteten OSS-Lizenzen im Grundsatz mit dem deutschen Urheberrecht vereinbar sind.
Dies ist auch das Ergebnis der bereits erwähnten Entscheidungen der Landgerichte
München und Frankfurt am Main, welche die zentralen Bestimmungen der GPL (Ziffern
2, 3 und 4) für urheberrechtlich unbedenklich erklärt haben.32 Die in der Fachliteratur
geäußerten rechtlichen Bedenken gegen einzelne Klauseln der OSS-Lizenzen haben
bislang ebenfalls nicht zu gerichtlichen Auseinandersetzungen oder sonstigen
Problemen in der Praxis geführt. Sie sollen hier gleichwohl behandelt werden, um
etwaige Befürchtungen von Behörden auszuräumen.
Als ein erstes Problem wird oftmals darauf hingewiesen, dass es nach deutschem
Urheberrecht wegen § 31 Abs. 4 UrhG (a.F.) nicht möglich sei, für Nutzungsarten Rechte
einzuräumen, die zum Zeitpunkt des Vertragsschlusses noch nicht bekannt gewesen
sind. Würde man auf den Zeitpunkt der ersten Lizenzierung durch den Rechtsinhaber
abstellen, so die Argumentation, so wäre es etwa für den Linux-Kernel durchaus fraglich,
ob auch solche Nutzungsarten umfasst sind, die erst Ende der 90er Jahre in ihrer
32
Vgl. Landgericht München, Urteil vom 19.05.2004, oben Fn. ■; LG Frankfurt a.M., Urteil v. 06.09.2006, oben Fn. ■; LG München, Urteil v. 12.07.2007, oben Fn. ■.
Seite 51
wirtschaftlichen Bedeutung bekannt geworden sind.33 Als Beispiel wird hier das
sogenannte Application Service Providing genannt. Dieses Problem hat in der
Vergangenheit zu keinen erkennbaren Problemen in der Praxis geführt. Es wurde zudem
durch die zum 01.01.2008 in Kraft getretene Urheberrechtsnovelle für die Zukunft gelöst.
Gemäß § 31a Abs. 1 S. 2 UrhG können in OSS-Lizenzen künftig auch Nutzungsrechte
an unbekannten Nutzungsarten eingeräumt werden, ohne dass es der Einhaltung der
Schriftform wie sonst nach § 31a UrhG vorgesehen bedürfte. Für die Einräumung
entsprechender Nutzungsrechte ist auch nicht die Zahlung einer besonderen Vergütung
geschuldet, da der Gesetzgeber in § 32c Abs. 3 S. 3 UrhG insoweit eine Ausnahmevorschrift für OSS-Lizenzen geschaffen hat.
Als zweiter Problembereich wird auf den Erschöpfungsgrundsatz aus § 69c Nr. 3 Satz 2
UrhG verwiesen.34 Die Frage der Erschöpfung des Verbreitungsrechts ist aus Sicht der
Behörde als Nutzer jedoch irrelevant. Die OSS-Lizenzen verbieten die Weitergabe einer
einmal rechtmäßig in den Verkehr gebrachten Programmkopie nicht, auch werden keine
Bedingungen an die Weitergabe dieser Programmkopie geknüpft.
Genannt werden schließlich die Urheberpersönlichkeitsrechte der Softwareentwickler. 35
Gemäß §§ 69a Abs. 4, 14 UrhG kann sich der Urheber eines Computerprogramms
gegen Entstellungen oder Beeinträchtigungen seines Werkes zur Wehr setzen, sofern
diese geeignet sind, seine persönlichen oder geistigen Interessen zu verletzten. Dieses
Verbotsrecht steht im Konflikt zur Veränderungsfreiheit, welche die OSS-Lizenzen jedem
Nutzer einräumt. Bei Veränderungen eines Computerprogramms dürften Verletzungen
des Urheberpersönlichkeitsrechts allerdings nur in Ausnahmefällen gegeben sein. Auch
dieses Problem hat bislang in der Praxis zu keinen bekannt gewordenen Konflikten
zwischen Rechtsinhabern und Nutzern von OSS geführt.
5.3
Umfang der Rechtseinräumung bei OSS-Lizenzen
Die genannten theoretischen Probleme bei der Einräumung von Nutzungsrechten durch
OSS Lizenzen sollten nicht den Blick darauf verstellen, dass die Rechtseinräumung
durch OSS Lizenzen für den Nutzer mit erheblichen praktischen Vorteilen verbunden ist.
Diese können für die Migrationsentscheidung von Behörden bedeutsam sein. Ist für eine
Behörde eine Nutzung von Software notwendig oder wünschenswert, die über eine bloß
bestimmungsgemäße Benutzung hinausgeht, so ist dies bei OSS ohne Weiteres möglich. Eine Lizenz entspricht nur dann den Kriterien der Open Source Definitionen36 und
der Free Software Definition37, wenn sie dem Nutzer umfangreiche "Freiheiten" im Umgang mit dem Programm einräumt, insbesondere das Programm in veränderter oder
unveränderter Form vervielfältigen und verbreiten zu können.
Rechtstechnisch handelt es sich hierbei um die Einräumung einfacher, urheberrechtlicher Nutzungsrechte gemäß § 31 Abs. 2 UrhG. Dieser umfassende Rechtserwerb geht
denkbar einfach vonstatten. Wer die Rechte aus den Lizenzen wahrnehmen möchte,
33
34
35
36
37
Vgl. etwa Spindler, Rechtsfragen bei Open Source (2004), S. 75 ff.
Vgl. Spindler, Rechtsfragen bei Open Source (2004), S. 91 ff.
Vgl. hierzu exemplarisch Teupen, "Copyleft" im deutschen Urheberrecht (2007), S. 192.
Abrufbar unter http://opensource.org/docs/osd.
Abrufbar unter http://www.gnu.org/philosophy/free-sw.html.
Seite 52
kann dies ohne Weiteres tun, solange er auch die Verpflichtungen einhält, die die
jeweilige Lizenz mit sich bringt. Die Einräumung der Nutzungsrechte erfolgt kostenfrei.
Einige Autoren weisen darauf hin, dass die Einräumung des Rechts für den unkörperlichen Vertrieb, insbesondere das Bereithalten zum Download im Internet, bei einigen
der wichtigsten OSS-Lizenzen zweifelhaft sei.38 Die GPL Version 2 und die BSD Lizenz
räumen zwar ausdrücklich das Recht ein, das Programm in körperlicher Form zu verbreiten ("distribute"), erwähnen aber den unkörperlichen Vertrieb nicht explizit. Verwiesen
wird in diesem Zusammenhang auch auf § 31 Abs. 4 UrhG a.F.; es sei zu fragen, ab
welchem Zeitpunkt der Vertrieb in Datennetzen in seiner wirtschaftlichen Bedeutung
bekannt gewesen sei.39
Dem ist entgegenzuhalten, dass in der US-amerikanischen Terminologie das Wort "distribute" auch den unkörperlichen Vertrieb umfasst. Oft wird ohnehin für die Auslegung
eines der 50 US-amerikanischen Vertragsrechte maßgeblich sein, weil der Lizenzgeber
in den USA sitzt. In den Fällen, in denen eine Auslegung nach deutschem Recht vorzunehmen ist, muss berücksichtigt werden, dass die genannten OSS-Lizenzen in ihrer
Terminologie auf das US-amerikanische Recht Bezug nehmen. Dessen Begriffe sind
deswegen auch bei Anwendung des deutschen Rechts zu berücksichtigen.40 Schließlich
ist auf den letzten Absatz von Ziffer 3 GPL Version 2 hinzuweisen. Dort heißt es: "If distribution of executable or object code is made by offering access to copy from a designated place [...]; mit "designated place" kann in diesem Zusammenhang nur eine Internetadresse gemeint sein, von der das Programm abgerufen werden kann. Dies spricht
ebenfalls für eine Einbeziehung des unkörperlichen Vertriebs. Im Hinblick auf § 31 Abs.
4 UrhG kann auf das oben Ausgeführte verwiesen werden. Im Ergebnis ist deswegen
davon auszugehen, dass auch der Vertrieb in Datennetzen wie dem Internet nach der
GPL Version 2 und der BSD-Lizenz gestattet ist.
Die GPL Version 3 sieht in Ziffer 2 nunmehr auch ausdrücklich die Erlaubnis zum
Onlinevertrieb vor. Der dort verwendete Begriff „propagate― umfasst nach der Definition
in Ziffer 0 der Lizenz auch das Recht der öffentlichen Zugänglichmachung. 41 Das
Problem wird sich deshalb in Zukunft ohnehin weiter entschärfen, weil bereits heute
zahlreiche OSS-Programme nach den Bedingungen der GPL Version 3 genutzt werden
können und zudem mit dem Übergang weiterer Projekte auf die neue Lizenz zu rechnen
ist.
5.4
Entgegenstehende Urheberrechte Dritter
Eine verbreitete Befürchtung beim Einsatz von OSS betrifft entgegenstehende Urheberrechte Dritter. Sind die Nutzer von OSS einer erhöhten Gefahr von Schadensersatz- und
Unterlassungsansprüchen ausgesetzt? Ein Praxisbeispiel bietet hier der seit Jahren aus-
38
39
40
41
Vgl. insbesondere Spindler, a.a.O., 82.
Vgl. insbesondere Spindler, a.a.O., 82.
Vgl. Metzger, in: Hilty/Peukert, Interessenausgleich im Urheberrecht (2004), 253, 260 mit
weiteren Nachweisen.
Siehe hierzu Jaeger/Metzger, Die neue Version 3 der GNU General Public License, Gewerblicher Rechtsschutz und Urheberrecht 2008, 130, 134.
Seite 53
gefochtene Rechtsstreit zwischen SCO und IBM42. SCO beschuldigt IBM, Bestandteile
von Programmen, an denen SCO behauptet die Rechte innezuhaben, ohne die erforderliche Erlaubnis in Linux integriert und damit Geschäftsgeheimnisse, Verträge sowie die
Urheberrechte an den fraglichen Modulen verletzt zu haben.43 Es soll hier nicht um die
Details dieses Rechtsstreits gehen. Dieser dient nur als Illustration der folgenden Frage:
Welche Risiken hat eine Behörde zu befürchten, wenn sich im Nachhinein herausstellt,
dass an genutzter OSS Rechte Dritter bestehen?
Für die Beantwortung sind zwei Situationen zu unterscheiden. Es macht einen Unterschied, ob die Behörde die Software (1.) vervielfältigt, verbreitet oder verändert oder (2.)
ob sie sie nur bestimmungsgemäß benutzt hat.
Im ersten Fall liegt es auf der Hand, dass eine entsprechende Nutzung nur urheberrechtlich zulässig ist, wenn der Rechtsinhaber hierfür die entsprechenden Rechte eingeräumt hat, insbesondere das Programm oder die Programmteile, an denen er die Rechte
hält, einer OSS-Lizenz unterstellt hat. Stellt sich im Nachhinein heraus, dass der
vermeintliche Lizenzgeber nicht Inhaber der Rechte an dem gesamten Programm ist, so
kann der Behörde die weitere Verbreitung des Gesamtprogramms für die Zukunft
untersagt werden. Für die Vergangenheit können Schadensersatzforderungen geltend
gemacht werden, sofern die Behörde ein Verschulden trifft. 44 Wer urheberrechtlich
geschützte Güter nutzt, muss sich über die hierfür erforderlichen Rechte Gewissheit
verschaffen, um nicht seine Sorgfaltspflichten zu verletzen. Handelt es sich bei den
fraglichen Programmen um bekannte OSS-Programme oder Module, die seit längerer
Zeit ohne Beanstandung frei verfügbar sind und die zudem eine weite Verbreitung gefunden haben, etwa durch die Aufnahme in einen offiziellen Release eines der großen
Distributoren, so sollte eine Behörde in der Regel darauf vertrauen dürfen, dass die
vermeintlichen Lizenzgeber die Rechte an den Programmen innehaben. Bei weniger
weitverbreiteten, erst für kürzere Zeit als OSS erhältlichen Programmen kann dagegen
auch eine aktive Überprüfung der Rechtsinhaberschaft, insbesondere durch Erkundigung bei den vermeintlichen Rechtsinhabern und Anbietern ähnlicher, proprietärer
Konkurrenzprodukte anzuraten sein. Unterlassungs- als auch Schadensersatzansprüche
beziehen sich dabei stets nur auf den Teil des Programms, für den entgegenstehende
Rechte Dritter bestehen. Das heißt, die anderen Programmteile, die nicht mit Rechten
Dritter belastet sind, dürfen weiter verbreitet werden.
Im zweiten Fall ist die Rechtslage etwas komplizierter. Hier kann es so sein, dass der
Zwischenhändler, von dem die Behörde das Programm erhalten hat, dieses nicht vertreiben durfte, da die OSS-Lizenz ihm hierfür nicht die erforderlichen Rechte vermittelt
hat. Dies führt dazu, dass sich die Behörde nicht auf § 69d Abs.1 UrhG berufen kann, da
ihre Programmkopie nicht rechtmäßig in den Verkehr gelangt ist.
Auf den ersten Blick scheint als Ergebnis festzustehen, dass sie das gesamte Programm
nicht mehr benutzen darf; schließlich ist das Programm nicht rechtmäßig in Verkehr
42
43
44
Siehe den Text der 06.03.2003 in Salt Lake City erhobenen Klage unter
http://www.sco.com/scoip/lawsuits/ibm/
Siehe zum Prozessverlauf die zahlreichen unter http://www.groklaw.net abrufbaren Prozessdokumente.
Zur Berechnung des Schadensersatzes vergleiche Schricker-Wild, Urheberrecht (2. Aufl.
1999), § 97, Rz. 56 ff.
Seite 54
gebracht worden. Dieser erste Anschein trügt aber. Es wurde bereits darauf
hingewiesen, dass manche OSS-Lizenzen, etwa die BSD-Lizenz, dem Nutzer auch das
Recht einräumen, die Software einfach nur zu benutzen, das heißt, bestimmungsgemäß
ablaufen zu lassen. Diese Klauseln erlangen Bedeutung, wenn sich der Nutzer nicht auf
die gesetzliche Lizenz des § 69d Abs. 1 UrhG berufen kann, weil es hierfür an den
Voraussetzungen fehlt. Auch die GPL, welche an sich ja die einfache Benutzung aus
ihrem Anwendungsbereich ausklammert, hält für diese Situation ein Hilfsmittel
zugunsten der Nutzer bereit. Ziffer 7 GPL Version 2 und Ziffer 12 GPL Version 3 verbieten den Vertrieb eines Programms unter der GPL, wenn dieses durch ein
Gerichtsurteil oder auf andere Weise untersagt worden ist. In diesem Fall sollen gemäß
Ziffer 4 GPL Version 2 und Ziffer 8 GPL Version 3 aber nur die Rechte des Lizenznehmers entfallen. Rechtspositionen Dritter, die vom Lizenznehmer Programmkopien
erhalten haben, sollen hingegen fortbestehen, solange der Dritte die Bestimmungen der
Lizenz einhält.
Freilich kann das nur für die Programmteile gelten, an denen die Lizenzgeber auch tatsächlich die Rechte innehaben. Diese Programmteile dürfen weiter benutzt werden. Für
die Teile des Programms, auf denen Rechte Dritter lasten, können gegen die Behörde
unter den oben genannten Voraussetzungen Unterlassungs- und Schadensersatzansprüche geltend gemacht werden.
Man stelle sich etwa folgenden Beispielfall vor. Ein Entwicklungsprojekt stellt eine
umfangreiche Datenbanksoftware unter die GPL und verbreitet das Programm. Die
Behörde A lädt sich die Software herunter, modifiziert sie für die besonderen Anforderungen von Behörden und vertreibt sie an die Behörden B, C und D. Stellt sich im
Nachhinein heraus, dass einer der Programmierer des Projekts unsauber gearbeitet und
einzelne Teile des Programms in urheberrechtlich unzulässiger Weise übernommen hat,
so kann der Inhaber der Rechte an diesen Programmteilen grundsätzlich nur die
Verbreitung und Benutzung dieser Programmteile untersagen. Daraus folgt, dass A die
Verbreitung dieser Programmteile untersagt werden kann, nicht aber die Verbreitung der
sonstigen Programmteile. Lässt sich der problematische Bestandteil ersetzen, so kann
das auf diese Weise bereinigte Gesamtprogramm weiter verbreitet werden. B, C, und D
kann ebenfalls nur die Benutzung der Programmteile untersagt werden, an denen
Rechte Dritter bestehen. Können diese ersetzt oder gelöscht werden, etwa weil der
jeweilige Benutzer diese Programmbestandteile gar nicht benötigt, so darf das Restprogramm weiterhin benutzt werden.
Wo sich eine Behörde aufgrund entgegenstehender Rechte Dritter entsprechenden
Ansprüchen ausgesetzt sieht, ist jeweils zu fragen, ob sie ihrerseits Ansprüche gegen
ihre Vertragspartner geltend machen kann. Dies ist eine Frage der Gewährleistung
(siehe auch I.B 7).
5.5
Im Hinblick auf die urheberrechtlichen Fragestellungen ergeben sich aus der Sicht einer
Behörde als Nutzer eine Reihe relevanter Unterschiede zwischen einer Migration zu
proprietärer Software und einer Migration zu OSS.
Seite 55
Hierbei ist zunächst festzustellen, dass die unter I.B 5 thematisierten rechtlichen Probleme der OSS-Lizenzen, soweit diese praktisch überhaupt relevant werden, auch bei
proprietären Lizenzmodellen auftreten können. Es handelt sich hier nicht um spezifische
Rechtsfragen der OSS. Vielmehr können entsprechende rechtliche Probleme sowohl bei
OSS als auch bei proprietärer Software auftreten.
Erhebliche Vorteile von OSS gegenüber proprietären Konkurrenzprodukten sind im
Hinblick auf den Umfang der Rechtseinräumung festzuhalten. OSS-Lizenzen erlauben
den Behörden eine denkbar umfassende Nutzung der Programme, der Erwerb dieser
Rechte ist kostenfrei und in der Abwicklung denkbar einfach. Demgegenüber gestatten
proprietäre Softwarelizenzen in der Regel nur eine bestimmungsgemäße Benutzung der
Software. Hinzu kommen die mannigfaltigen Verwendungs- und Weitergabebeschränkungen in üblichen Softwarelizenzen, die den ohnehin geringen Spielraum der
Nutzer zusätzlich einengen. Benötigt der Nutzer zusätzliche Rechte, etwa weil er die
Software verändern oder in weiterem Umfang einsetzen möchte, so muss er in aller
Regel eine erhöhte Lizenzgebühr hinnehmen. Entsprechende Vertragsgestaltungen sind
üblich und oft auch rechtlich wirksam, etwa die Erhöhung der Lizenzgebühren bei der
Verwendung von Software auf einer leistungsstärkeren Hardware.45
Für die unter I.B 5.4 genannten Unterlassungs- und Schadensersatzansprüche können
sich dagegen gewisse Vorteile für eine Migration zu proprietärer Software ergeben. Es
ist zwar festzuhalten, dass eine Behörde als Softwarenutzer nie absolut sicher sein
kann, dass der weiteren Nutzung eines Programms keine Rechte Dritter entgegenstehen. Entsprechende Probleme sind allerdings umso weniger wahrscheinlich, je
seriöser und transparenter die Herkunft eines Programms ist. OSS wird hier mitunter mit
Nachteilen behaftet sein, wenn die Herkunft eines Programms nicht oder nur mit
erheblichem Aufwand geklärt werden kann, während das konkurrierende, proprietäre
Produkt eindeutig zuzuordnen ist. Hier zeigen sich die Nachteile der dezentralen Entwicklung im Rahmen von mitunter weltweit verstreuten Communities. Freilich ist auch die
umgekehrte Situation denkbar, in der die Herkunft eines proprietären Programms
weniger transparent ist als diejenige der konkurrierenden OSS; dies gilt umso mehr, als
die Behörde bei OSS in jedem Fall den Quellcode untersuchen und dadurch Hinweise
auf die Herkunft des Programms erhalten kann. Man muss hier also die jeweils in
Konkurrenz stehenden Produkte im Einzelfall vergleichen. Zu berücksichtigen ist bei der
Evaluierung der Migration zu proprietärer Software durchaus auch, welche diesbezüglichen Erfahrungen die Behörde mit den jeweiligen Anbietern in der Vergangenheit
gemacht hat.
Migration zu OSS
Migration zu proprietärer
Software
Urheberrechtliche Zulässig- Aus der Sicht der Nutzer keine Bei entsprechender Vertragskeit einzelner Lizenzklauseln praktisch relevanten Rechtsgestaltung keine praktisch
probleme
relevanten Rechtsprobleme
45
Siehe hierzu Bundesgerichtshof, Urteil vom 24.10.2002, Neue Juristische Wochenschrift
2003, 2014.
Seite 56
Migration zu OSS
Migration zu proprietärer
Software
Umfang der Rechtseinräumungen
Sehr weitgehend
Oft restriktiv
Risiko entgegenstehender
Rechte Dritter
Erhöht bei unklarer Herkunft,
geringer bei seriösen Projekten
Erhöht bei unklarer Herkunft,
geringer bei seriösen Anbietern
Tabelle 7 Urheberrechtliche Fragen:
6
6.1
Patentrecht
Einleitung
Die Fragen des Patentrechts haben in der Diskussion der letzten Jahre um die Rechtssicherheit von OSS breiten Raum eingenommen. Die Angst vor rechtlichen Risiken
durch Patente wird dabei sowohl von den konkurrierenden Anbietern proprietärer
Produkte geschürt als auch von den OSS-Projekten selbst, die regelmäßig auf die rechtlichen Gefahren durch Softwarepatente hinweisen, zuletzt an prominenter Stelle in der
Präambel der GPL Version 3. Bei näherer Betrachtung sind die rechtlichen Risiken bei
der Nutzung von OSS jedoch beherrschbar. Im Folgenden sollen die vielfach diskutierten
rechtspolitischen Fragen ausdrücklich ausgeklammert werden. Der Migrationsleitfaden
konzentriert sich auf den juristischen Status quo aus der Perspektive einer Behörde als
Nutzer. Versucht man diesen zu beschreiben, so ist zunächst darauf hinzuweisen, dass
allein das europäische Patentamt seit 1993 über 30.000 Patente für programmbezogene
Erfindungen in allen Technikbereichen erteilt hat, zu denen auch Erfindungen zum Beispiel im Automobilbau, im Maschinenbau und in der Mess- und Regeltechnik gehören,
weil bei ihnen Computerprogramme eingesetzt werden. Hinzu kommen die vom Deutschen Patent- und Markenamt in diesem Bereich erteilten Patente. Dadurch ist es
bereits heute möglich, ein realistisches Bild von den rechtlichen Problemen zu gewinnen,
welche sich für die Nutzer von OSS durch Patente in den verschiedenen Bereichen der
Informationstechnologie ergeben können, unabhängig von der im Juli 2005 gescheiterten europäischen "Richtlinie über die Patentierbarkeit computerimplementierter Erfindungen".46 Es liegt allerdings in der Natur der Sache, dass die im Folgenden dargestellten rechtlichen Probleme mit einer wachsenden Zahl von Patenten in zunehmendem
Maße auftreten dürften. Ein Beispiel aus der Vergangenheit für ein Migrationsprojekt
eines öffentlichen Trägers, welches wegen patentrechtlicher Fragestellungen vorübergehend gestoppt wurde, hat das "Limux"-Projekt der Stadt München geboten.47 Ein von
der Stadt München in Auftrag gegebenes Kurzgutachten kam dabei zu dem Ergebnis,
dass "das Risiko einer Verstrickung der Stadt München in einen Patentverletzungs-
46
47
Vgl. zu den Entwürfen der Europäischen Kommission, des Rats und des Europäischen
Parlaments im Einzelnen Metzger, Softwarepatente im künftigen europäischen Patentrecht,
Computer und Recht 2003, 313 und Metzger, EP: Eindämmung der Softwarepatente verabschiedet, Computer und Recht 2003, 871.
Siehe http://www.muenchen.de/limux.
Seite 57
prozess nach der bestehenden Rechtslage als gering einzustufen" sei. 48 Die Stadt hat
das Projekt daraufhin fortgesetzt. Patentrechtliche Verletzungsverfahren gegen Nutzer
von OSS wegen dieser Nutzung sind bisher nicht bekannt geworden.
6.2
Entgegenstehende Patentrechte Dritter bei Nutzung von OSS
Patentrechtliche Probleme könnten sich vor allem dann für Behörden als Nutzer von
OSS ergeben, wenn Dritte Inhaber von Patenten sind, die durch die Nutzung von Software verletzt werden.
Ob eine Patentverletzung vorliegt, ist gemäß § 9 PatG zu bestimmen. Man wird sowohl
bei einem sogenannten Erzeugnispatent gemäß § 9 Nr. 1 PatG (Verbindung von Hardund Software; programmgesteuerte Maschinen etc.) als auch bei einem Verfahrenspatent gemäß § 9 Nr. 2 PatG (in Software umgesetzte Lehren zum technischen Handeln,
zum Beispiel ein programmgesteuertes Messverfahren) davon auszugehen haben, dass
bereits die bloße bestimmungsgemäße Benutzung einer geschützten Software eine
Verletzung dieses Patents darstellen kann. Für das Erzeugnispatent kann es sich bei der
Benutzung eines Programms um ein "Gebrauchen" im Sinne von § 9 Nr. 1 PatG
handeln. Wenn etwa in einer Behörde eine patentrechtlich geschützte Maschine benutzt
wird, so liegt eine Patentverletzung vor. Einschränkungen sind hier nur denkbar, wenn
lediglich ein Teil der von der Behörde genutzten Vorrichtung patentrechtlich geschützt
ist. Hier kommt es darauf an, ob der geschützte Teil für das Ganze wesentlich ist. Bei
einem Verfahrenspatent kann die bloße Benutzung von Software eine "Anwendung" des
geschützten Verfahrens im Sinne von § 9 Nr. 2 PatG und damit eine Patentverletzung
darstellen.
Als Patentverletzung ist in beiden Fällen auch der Vertrieb des Programms anzusehen
("Inverkehrbringen" oder "Anbieten").
Liegt eine Patentverletzung vor, so können gegen die Behörde Unterlassungs- und
Schadensersatzansprüche geltend gemacht werden. Schadensersatz ist auch im Patentrecht nur unter der Voraussetzung zu leisten, dass die Behörde ein Verschulden trifft,
wobei leichte Fahrlässigkeit ausreichen kann. Die Gerichte legen gerade bei Unternehmen hierbei einen strengen Maßstab an. Es wird im Grundsatz erwartet, dass man sich
über bestehende Schutzrechte informiert. Gewisse Milderungen sind allerdings in den
Fällen möglich, in denen ein Unternehmen das Programm wie ein Endabnehmer nutzt,
ohne genauere Fachkenntnis zu haben.49 Diese Grundsätze wird man auch bei
Behörden anzuwenden haben. Behörden dürfen sich beim Einsatz von Programmen, die
sie von professionellen Distributoren oder Dienstleistungsunternehmen erworben haben
und die sie als Endabnehmer selbst nutzen, in der Regel darauf verlassen, dass der
Anbieter bei der Zusammenstellung der Programme die Schutzrechtslage geprüft und
beachtet hat. Besondere Prüfpflichten seitens der Behörde bestehen dann nicht. In
diesen Fällen dürfte es auch nur selten zu einer Inanspruchnahme der Behörde
kommen, da sich die Schutzrechtsinhaber hier zunächst an den Anbieter halten werden.
48
49
Vgl. das Kurzgutachten von Sedlmaier/Gigerich vom 10.09.2004, abrufbar unter
http://www.jurpc.de/aufsatz/20050010.htm
Vgl. Kraßer, Patenrecht (5. Aufl. 2004), S. 876; Benkard, Patentgesetz (10. Aufl. 2006), §
139, Rz. 47.
Seite 58
Bei konkreten Hinweisen auf bestehende Patente kann jedoch erhöhte Aufmerksamkeit
auch seitens der Behörde gefordert sein. Erhöhte Sorgfaltspflichten können sich zudem
ergeben, wenn die Behörde besondere Sachkenntnis in dem spezifischen Bereich der
Informationstechnik hat oder wenn sie das Programm in großem Umfang verbreitet. Bei
der Feststellung des Verschuldens kommt es letztlich immer auf die Umstände des
Einzelfalls an, sodass die genannten Kriterien nur als grobe Richtschnur herangezogen
werden können.
Bei entgegenstehenden Patentrechten Dritter bleibt schließlich stets zu fragen, welche
Ansprüche die Behörde ihrerseits gegen die eigenen Lieferanten geltend machen kann.
Dies ist eine Frage der vertraglichen Gewährleistung.
6.3
Die oben ausgeführten Rechtsprobleme, die sich bei der Nutzung von OSS aufgrund
entgegenstehender Rechte Dritter ergeben können, sind keineswegs spezifisch für diese
Entwicklungs- und Vertriebsform. Entsprechende Probleme können genauso bei proprietären Konkurrenzprodukten auftreten.
Im Hinblick auf patentrechtliche Ansprüche kann auch nicht für eine Migration zu proprietärer Software auf das Argument der größeren Transparenz der Herkunft der einzelnen
Softwarebestandteile verwiesen werden. Auch wenn im Einzelnen dokumentiert ist, wer
welchen Part eines Programms geschrieben hat und dass die entsprechenden Rechte
erworben worden sind, so kann daraus nicht gefolgert werden, inwieweit Patente Dritter
berührt werden. Da das Patent die zugrunde liegenden technischen Lösungen schützt
und nicht die konkrete Form der Programmierung, genügt es mit Blick auf etwaige Patentrechte nicht, alle Rechte der jeweiligen Programmierer erworben zu haben. Um wirkliche Rechtssicherheit zu erreichen, bedarf es einer Patentrecherche und gegebenenfalls
den Erwerb von Patentlizenzen Dritter. In patentrechtlicher Hinsicht ergeben sich dabei
für beide Migrationswege im Grundsatz die gleichen rechtlichen Risiken.
7
7.1
Haftung und Gewährleistung
Einleitung
Einer der wesentlichen Punkte in der Bewertung der unterschiedlichen Risiken einer
Migration zu proprietärer Software oder zu OSS ist die Frage nach dem Umfang der
jeweiligen Haftung und Gewährleistung. Dieser ergibt sich im Einzelfall erst in der
Zusammenschau von gesetzlichen Regeln und den konkret getroffenen vertraglichen
Vereinbarungen. Die pauschale Aussage, bei OSS gebe es keine Haftung und Gewährleistung, weil die Software kostenlos erhältlich sei, während bei proprietärer Software die
volle Absicherung durch den Vertragspartner geschuldet sei, gibt die Rechtslage nicht
zutreffend wieder. Bei entsprechender Vertragsgestaltung bestehen für Behörden keine
erheblichen Unterschiede zwischen dem Einsatz von OSS oder proprietärer Software.
Zunächst gilt es allerdings die verschiedenen Ansprüche und Anspruchsgegner auseinanderzuhalten. Unter Gewährleistung versteht man das Einstehen müssen für die
Vertragsgemäßheit des Programms. Der Begriff der Haftung beschreibt zunächst das
vertragliche Einstehen müssen für Schäden, die sich beim Vertragspartner an sonstigen
Seite 59
Rechtsgütern ergeben, etwa Schäden an Hardware oder anderer Software (vertragliche
Haftung). Mit Haftung bezeichnet man darüber hinaus auch jedes sonstige außervertragliche Einstehen müssen für Schäden (außervertragliche Haftung).
Die Haftung und Gewährleistung kann, abhängig von der Ausgestaltung der jeweiligen
vertraglichen Beziehungen, unterschiedlichen gesetzlichen Maßstäben unterliegen. So
gelten insbesondere bei unentgeltlichen Verträgen vielfach weitreichende Gewährleistungs- und Haftungserleichterungen, während bei der entgeltlichen Softwareüberlassung
voll gehaftet wird. Von den gesetzlichen Regelungen können die Vertragsparteien innerhalb bestimmter gesetzlicher Grenzen abweichen und einen schärferen oder milderen
Haftungs- und Gewährleistungsmaßstab vertraglich vereinbaren. Behörden sollten darauf bedacht sein, dass die Haftung und Gewährleistung nicht zu ihrem Nachteil ausgeschlossen wird. Werden diese Vereinbarungen nicht wirksam getroffen, etwa weil man
sich außerhalb des gesetzlich zulässigen Rahmens befindet, gilt wiederum der gesetzliche Haftungsmaßstab. Gesetzlich zulässig und in der Praxis verbreitet ist die Vereinbarung einer zusätzlichen vertraglichen Haftung. Distributoren von OSS bieten vielfach die
vertragliche Übernahme des Haftungsrisikos ihrer Kunden gegenüber Ansprüchen Dritter
an („Indemnification Program―, „Assurance Program― o.ä.)
Für die Behörde kommen bei der Migration zu OSS unterschiedliche vertragliche
Haftungs- und Gewährleistungsschuldner in Betracht. Einerseits können Ansprüche
gegenüber dem Distributor oder sonstigen Lieferanten der Software bestehen. Andererseits können dort, wo die Behörde eine Open Source Lizenz erworben hat, um die
Software zu verändern, zu vervielfältigen und weiterzugeben, Ansprüche auch gegenüber den jeweiligen Lizenzgebern bestehen. Auch bei der außervertraglichen Haftung
kann es unterschiedliche Anspruchsgegner geben.
Im Einzelnen gelten für die verschiedenen Vertragsverhältnisse die folgenden Grundsätze.
7.2
Einsatz von OSS: Vertragliche Haftung und Gewährleistung bei
Überlassungsverträgen
Verträge über die Überlassung von Open Source Software von einem Zwischenhändler
an die Behörde sind regelmäßig als Kauf oder als Schenkung einzuordnen, abhängig
davon, ob die Parteien die Überlassung gegen (Einmal-) Entgelt oder aber die unentgeltliche Überlassung verabreden. Ein entgeltlicher Erwerb kann dabei insbesondere auch
deshalb interessant sein, da der Lieferant bei einer entgeltlichen Überlassung in größerem Umfang Gewährleistungs- und Haftungsrisiken übernehmen muss. Das Risiko einer
Migration zu OSS wird hierdurch unter Umständen besser kalkulierbar.
Ist Kaufrecht anwendbar, hat die Behörde einen Anspruch darauf, dass der Zwischenhändler die OSS frei von Sach- und Rechtsmängeln verschafft. Der Zwischenhändler
muss dafür einstehen, dass der Vertragsgegenstand die vertraglich vereinbarte oder
vorauszusetzende Beschaffenheit aufweist und dass keine Rechte Dritter, insbesondere
Urheber- und Patentrechte, an dem Vertragsgegenstand bestehen, die die bestimmungsgemäße Benutzung behindern. Diese Gewährleistung schulden Distributoren und
sonstige Zwischenhändler bereits bei Abschluss eines einfachen Softwareüberlassungsvertrags. Einer besonderen vertraglichen Vereinbarung bedarf es dafür nicht.
Seite 60
Beim Abschluss eines „Indemnification Program― oder „Assurance Program― mit dem
Distributor sollte deshalb im Einzelnen geprüft werden, ob sich hieraus zusätzliche
Ansprüche des Kunden gegenüber dem Anbieter ergeben. Diese können beispielsweise
darin bestehen, dass sich der Anbieter zur aktiven Unterstützung des Kunden in Rechtsstreitigkeiten mit Dritten verpflichtet oder dass für den Fall einer Patentverletzung des
Kunden auf das Patentportfolio des Distributors oder weiterer vertraglich verbundener
Parteien zur Verteidigung zurückgegriffen werden kann.
Liegen Mängel vor, so kann die Behörde in erster Linie Nacherfüllung verlangen. Schlägt
diese Nacherfüllung fehl, dann hat der Käufer die Auswahl unter mehreren Ansprüchen.
Er kann vom Vertrag zurücktreten (§§ 440, 323 BGB). Als Alternative steht dem Erwerber das Recht zu, am Vertrag zwar festzuhalten, den Kaufpreis aber zu mindern
(§ 441 BGB). Schließlich hat der Käufer auch einen Anspruch auf Schadensersatz auf
Grundlage der §§ 280, 440 BGB, wenn der Zwischenhändler – was gesetzlich vermutet
wird – den Schaden zu vertreten hat. Zu vertreten hat der Schuldner dabei regelmäßig
auch leichte Fahrlässigkeit.
Auch für Schäden an sonstigen Rechtsgütern der Behörde, insbesondere Hardware oder
andere Software, hat der Zwischenhändler grundsätzlich zu haften. Die Behörde kann in
diesem Fall Ersatz ihres Schadens verlangen; Anspruchsgrundlage ist § 280 BGB. Voraussetzung ist wiederum, dass der Zwischenhändler den Schaden zu vertreten hat. Ein
Verschulden wird aber auch hier grundsätzlich vermutet; es ist Aufgabe des Verkäufers,
sich zu entlasten.
Von dieser gesetzlichen Verteilung des Haftungs- und Gewährleistungsrisikos können
die Parteien innerhalb bestimmter Grenzen abweichen. Zwischenhändler versuchen
oftmals unter Verweis auf die üblichen Lizenzklauseln in Open Source Lizenzen, eine für
sie günstigere vertragliche Regelung durchzusetzen und die Haftung und Gewährleistung weitestgehend auszuschließen. Entsprechende Ausschlussklauseln sind aber in
aller Regel nicht gerechtfertigt, da die Zwischenhändler die Software entgeltlich
weitergeben. Behörden sollten sich hier keinesfalls auf einen Ausschluss ihrer
Ansprüche einlassen, sondern auf der Beibehaltung der gesetzlichen Standards
bestehen. Im Übrigen ist zugunsten der Behörde zu beachten, dass gerade in Standardverträgen ("Allgemeine Geschäftsbedingungen") Haftungs- und Gewährleistungsbeschränkungen nur begrenzt vereinbart werden können. Ein vollständiger Ausschluss der
Haftung und Gewährleistung, wie er sich im Kleingedruckten mancher GNU/LinuxStandarddistribution findet, ist deswegen zumeist unwirksam. Hierauf sollten sich
Behörden aber nicht verlassen, sondern von vornherein darauf dringen, dass eine sinnvolle vertragliche Lösung gefunden wird. Die Regelungen der EVB-IT Überlassung TYP
A und B zur Gewährleistung und Haftung50 sind grundsätzlich auch beim Erwerb von
Standard OSS geeignet.
Hat sich die Behörde die Software kostenlos verschafft, ist auf den Vertrag in der Regel
Schenkungsrecht anzuwenden. In diesen Fällen haftet der Lieferant nur in engen
Grenzen. Dafür, dass die Software die vorauszusetzende Beschaffenheit aufweist und
Rechte Dritter einer Verwendung nicht entgegenstehen, hat der Schenker nur dann
50
Ziffern 7-9 EVB-IT Überlassung Typ A und Ziffer 7-9 EVB-IT Überlassung Typ B (Haftung
bei Mängeln).
Seite 61
einzustehen, wenn er den Mangel arglistig verschwiegen hat (§§ 523, 524 BGB). Der
Lieferant muss den Mangel kennen oder zumindest für möglich halten. Zudem muss
eine Aufklärungspflicht bestehen, das heißt, der Beschenkte muss eine vorherige
Aufklärung über den jeweiligen Mangel erwarten können. Für die Haftung im Hinblick auf
die sonstigen Rechtsgüter des Erwerbers hat der Lieferant bei kostenloser Überlassung
nur Vorsatz und grobe Fahrlässigkeit zu vertreten (§ 521 BGB). Falls es durch das Programm also zu einer Verletzung der sonstigen Rechtsgüter des Erwerbers kommt, so
haftet er nur, wenn er die Rechtsverletzung wissentlich herbeiführt oder seine Sorgfaltspflichten in besonders schwerem Maße verletzt.
Oftmals wird zugleich mit dem Softwareüberlassungsvertrag auch ein Supportvertrag
abgeschlossen, in dem sich der Softwarelieferant zur Pflege und Instandhaltung der
überlassenen Programme verpflichtet. Hier stellt sich die Frage nach dem Verhältnis der
Mängelgewährleistung aus dem Überlassungsvertrag und den Pflichten des Dienstleisters aus dem Supportvertrag. Wird die Software gegen Entgelt überlassen, so hat die
Behörde grundsätzlich einen Anspruch darauf, dass Mängel beseitigt werden, ohne dass
hierfür ein besonderes Entgelt bezahlt werden muss. Während der Gewährleistungsfrist
darf also nur für solche Leistungen ein Entgelt verlangt werden, die über das hinausgehen, was eine Behörde bereits im Rahmen der gesetzlichen Mängelgewährleistung
verlangen kann, etwa 24-Stunden-Service und die Garantie, Ausfälle in bestimmten
Reaktionszeiten zu beheben. Schwierig zu beurteilen sind solche Vertragsgestaltungen,
in denen der Behörde die Software kostenlos überlassen wird, während für den Support
ein Entgelt verlangt wird. Hier ist zugunsten der Behörde davon auszugehen, dass eine
künstliche Aufspaltung in einen unentgeltlichen Teil mit nur geringer Gewährleistung und
einen entgeltlichen Teil, für den eine erhöhte Einstandspflicht besteht, nicht wirksam
vorgenommen werden kann. Stellt sich eine Dienstleistung aus Sicht der Behörde als
eine einheitliche entgeltliche Leistung dar, so muss der Anbieter auch dafür einstehen,
dass das Programm grundsätzlich funktionsfähig ist. Entsprechende Einstandspflichten
für diese Basisgewährleistung dürfen nicht als kostenpflichtiger Support abgerechnet
werden.
Entgeltlicher Erwerb
Sachmangel
Nacherfüllung
Rechtsmangel
Bei Fehlschlag der Nacherfüllung:


Minderung
Rücktritt
Bei Verschulden Schadensersatz
Unentgeltlicher
Erwerb
Schäden an sonstigen Rechtsgütern
Bei Verschulden Schadensersatz
Sachmangel
Bei Arglist Schadensersatz
Rechtsmangel
Schäden an sonstigen Rechtsgütern
Bei grober Fahrlässigkeit / Vorsatz Schadensersatz
Tabelle 8: Vertragliche Ansprüche auf Haftung und Gewährleistung gegen den Zwischenhändler
Seite 62
7.3
Einsatz von OSS: Vertragliche Haftung und Gewährleistung bei Open
Source Lizenzverträgen
Von den Verträgen mit den Lieferanten über die Überlassung der Software sind die
Open Source Lizenzverträge zu unterscheiden. Letztere werden direkt mit den Rechtsinhabern abgeschlossen. Gegenstand dieser OSS-Lizenzen ist die Einräumung
bestimmter Nutzungsrechte an der Software, insbesondere der Rechte zur Vervielfältigung, Verbreitung und Bearbeitung.
Die Erkenntnis, dass es sich um unterschiedliche Geschäfte handelt, ist für die Frage der
vertraglichen Haftung und Gewährleistung von weitreichender Bedeutung. Denn jeder
Vertragspartner hat nur für die von ihm zu verschaffenden Vertragsgegenstände eine
Gewährleistung zu übernehmen und haftet auch nur für die Einhaltung seiner eigenen
vertraglichen Verpflichtungen. Daraus folgt, dass die Urheber dem Lizenznehmer der
OSS-Lizenz im Wesentlichen für den Bestand und Erhalt der Nutzungsrechte einzustehen haben. Nur insoweit kann die Behörde vertragliche Ansprüche gegenüber diesen
geltend machen. Die tatsächliche Eignung der Software für die Programmbenutzung ist
hingegen eine Frage des Einstehen müssens der Distributoren oder der sonstigen
Zwischenhändler aufgrund des Überlassungsvertrages. Das Gleiche gilt für die Befugnis
der Behörde, die Software bestimmungsgemäß benutzen zu können; dieses Recht ergibt
sich in der Regel bereits aus dem Erwerb einer rechtmäßig in Verkehr gebrachten
Programmkopie. Fehlt es hieran, so ist der Distributor in Anspruch zu nehmen und nicht
die Rechtsinhaber.
Bei der Frage, in welchem Umfang die jeweiligen Urheber für den Bestand der Nutzungsrechte einzustehen haben, gilt es zunächst festzuhalten, dass sich der Gewährleistungs- und Haftungsmaßstab in der Regel nicht nach den entsprechenden Klauseln in
den jeweiligen OSS-Lizenzen richtet. Denn die allermeisten OSS-Lizenzen verwenden
einen umfassenden, vollständigen Haftungs- und Gewährleistungsausschluss.51 Entsprechende Klauseln sind nach deutschem Recht nichtig.52 Rechtsfolge dieser Unwirksamkeit ist, dass die gesetzlichen Regelungen Anwendung finden.
Open Source Lizenzen stellen sogenannte Lizenzverträge dar, deren Haftung und
Gewährleistung im Gesetz nicht ausdrücklich geregelt sind. Da die Nutzungsrechte
jedoch von den Urhebern gewährt werden, ohne dass die Zahlung einer Lizenzgebühr
verlangt wird, wird überwiegend davon ausgegangen, dass auf diese Verträge das
Haftungs- und Gewährleistungsrecht der verschiedenen unentgeltlichen Verträge
entsprechend anzuwenden ist.53 Weil zentraler Vertragsgegenstand der OSS-Lizenzen
die Einräumung von Rechten ist, steht im Mittelpunkt gewährleistungsrechtlicher Fragen
dabei das Einstehen müssen für Rechtsmängel. Sachmängelgewährleistung spielt
daneben in der Regel keine Rolle. Für Rechtsmängel, also insbesondere dafür, dass der
Lizenzgeber Inhaber der lizenzierten Nutzungsrechte ist und Rechte Dritter einer
51
52
53
Vgl. z.B. Ziffern 11 und 12 GPL Version 2, Ziffern 15 und 16 GPL Version 3.
Dazu ausführlich Jaeger/Metzger, Open Source Software: Rechtliche Rahmenbedingungen
der Freien Software (2. Aufl. 2006), Rz. 219 ff.
Siehe Jaeger/Metzger, a.a.O., Rz. 210 ff.; Spindler, Rechtsfragen bei Open Source (2004),
S. 152 ff. Andere Ansicht aber Hoeren, Open Source und das Schenkungsrecht - eine
durchdachte Liaison?, in: Recht und Risiko - Festschrift für Helmut Kollhosser , Bd. 2
(2004), S. 229 ff.
Seite 63
Lizenzierung nicht entgegenstehen, hat dieser in Anlehnung an die schenkungs- und
leihrechtlichen Vorschriften nur dann einzustehen, wenn er den Mangel arglistig
verschwiegen hat. Liegt kein Fall der Arglist vor, so hat die Behörde nach der
gesetzlichen Regelung das Risiko des Bestehens von Rechtsmängeln zu tragen.
Insoweit bieten auch die von OSS-Distributoren angebotenen Zusatzabsicherungen
gegenüber Rechten Dritter („Assurance Program―, „Indemnification Program― o.ä.)
regelmäßig keinen Schutz, weil sie den Kunden nur im Hinblick auf den
bestimmungsgemäßen Gebrauch des Programms absichern, nicht aber im Hinblick auf
eine weitergehende Verbreitung oder sonstige Nutzung. Für diese weitergehende
Nutzung bieten allenfalls spezielle Versicherungsprodukte entsprechenden Schutz.
Hinsichtlich der Schäden an sonstigen Rechtsgütern der Behörde ist die Haftung der
Rechtsinhaber ebenfalls in Anlehnung an die Vorschriften für unentgeltliche Verträge auf
Vorsatz und grobe Fahrlässigkeit beschränkt. Diese haften daher nur, wenn sie wissentlich gehandelt oder aber ihre Sorgfaltspflichten in besonders schwerem Maße verletzt
haben.
7.4
Einsatz von OSS: Vertragliche Haftung und Gewährleistung bei Erstellung
und Änderung von Freier Software
Wird Software gegen Entgelt im Kundenauftrag erstellt, ist Werkvertragsrecht oder nach
anderer Auffassung im Wesentlichen Kaufvertragsrecht anwendbar. Auch bei der entgeltlichen Anpassung von Software an die spezifischen Bedürfnisse der Behörde besteht
eine Gewährleistung und Haftung nach werk- oder kaufvertraglichen Grundsätzen, abhängig von der jeweiligen Einordnung des Geschäftes.
Unabhängig davon, ob es sich bei den genannten Verträgen um Kauf- oder Werkverträge handelt, kann die Behörde von ihrem jeweiligen Vertragspartner bei Mängeln
zunächst Nacherfüllung verlangen, wobei Unterschiede in der Ausübung je nach
vertragstypologischer Einordnung der Verträge bestehen. Scheitert die Nacherfüllung,
stehen dem Besteller Minderung, Rücktritt und – bei Verschulden der anderen Vertragspartei – Schadensersatzansprüche zu. Ob darüber hinaus die Behörde berechtigt ist,
den Mangel selbst zu beseitigen oder beseitigen zu lassen und Ersatz der hierzu
erforderlichen Aufwendungen verlangen kann, ist davon abhängig, ob man den Vertrag
als Werkvertrag ansieht und nicht als einen Vertrag, auf den Kaufrecht Anwendung
findet.
Für die vertragliche Haftung des Auftragnehmers gilt, dass dieser für schuldhaft verursachte Schäden an sonstigen Rechtsgütern des Erwerbers einzustehen hat. Eine fahrlässige Herbeiführung des Schadens begründet bereits eine entsprechende Haftung.
Wie bei allen Verträgen gilt auch hier, dass die Parteien innerhalb bestimmter Grenzen
abweichende Abreden treffen können. Im Hinblick auf die keineswegs eindeutige
Rechtslage sollte davon gerade auch im Bereich der OSS-Erstellungs- und Anpassungsverträge Gebrauch gemacht werden. Hier bietet es sich an, die Pflichten und Obliegenheiten der Vertragsparteien, insbesondere eine (aus dem Werkvertragsrecht bekannte)
Abnahme ausdrücklich zu regeln sowie Vereinbarungen über Mängelrügefristen etc. zu
treffen.
Seite 64
7.5
Einsatz von OSS: Außervertragliche Haftung
Schäden im Zusammenhang mit der Migration zu OSS können nicht nur zu vertraglichen
Ansprüchen gegenüber den jeweiligen Partnern führen. Vielmehr sind auch außervertragliche Haftungstatbestände zu beachten, insbesondere nach dem Produkthaftungsgesetz und dem allgemeinen Deliktsrecht der §§ 823 ff. BGB. Das Produkthaftungsgesetz begründet eine Haftung nur für Personenschäden und solche Sachschäden, die
an einer anderen Sache als dem fehlerhaften Produkt eintreten. Eine Haftung besteht
nach diesem Gesetz, das in erster Linie den Verbraucher schützen soll, dabei jedoch
nicht für solche Sachen, die nicht primär privat verwendet werden. 54 Sachschadensersatzforderungen aus dem nichtprivaten Bereich sieht sich der Hersteller auf der
Grundlage dieses Gesetzes nicht ausgesetzt. Insoweit ist gerade für die Behörde die
Geltendmachung von Sachschäden aufgrund des Produkthaftungsgesetzes weitestgehend ausgeschlossen.
Neben der verschuldensunabhängigen Haftung nach dem Produkthaftungsgesetz
kommt auch eine außervertragliche Haftung aufgrund allgemeiner außervertraglicher
Haftungstatbestände (Deliktstatbestände) vor. Gerade weil das Produkthaftungsgesetz
bei Sachschäden nur private Güter schützt, haben diese Regelungen für Behörden besondere Relevanz. Eine Geltendmachung auf Grundlage deliktsrechtlicher Vorschriften
setzt kein Vertragsverhältnis voraus. Wenn beispielsweise eine Behörde ein Programm
von einem Zwischenhändler erwirbt, so kommen gegenüber dem Distributor nur außervertragliche Ansprüche in Betracht, da insoweit kein Vertragsverhältnis besteht.
Interessant ist insbesondere die Regelung des § 823 BGB. Nach dieser Vorschrift ist
derjenige zum Schadensersatz verpflichtet, der vorsätzlich oder fahrlässig Leben,
Körper, Eigentum oder sonstige ähnlich „absolut― geschützte Rechtspositionen widerrechtlich verletzt. Schwierig und nur im Einzelfall zu beurteilen ist dabei die Frage, wann
die Verletzung „fahrlässig― erfolgte. Fahrlässigkeit setzt die Verletzung von Sorgfaltspflichten voraus. Bei den einzelnen Entwicklern der Software wird man den zu beachtenden Sorgfaltsmaßstab nicht zu hoch ansetzen dürfen. Bei der Entwicklung von OSS
werden regelmäßig auch unfertige Lösungen verbreitet, an denen die Community
arbeitet. Deutlich weitreichender stellt sich hingegen die außervertragliche Haftung der
Distributoren von OSS dar. Diese stellen in der Regel ein fertiges Endprodukt zur Verfügung, sodass von vornherein höhere Sorgfaltsanforderungen angezeigt erscheinen.
In der Praxis bestehen zum Teil Schwierigkeiten, das Vorliegen aller Tatsachen für das
Bestehen eines Schadensersatzanspruchs zu beweisen. Dort, wo das Produkt in
industrieller Weise gefertigt und vertrieben wird, kommt jedoch unter Umständen eine
Anwendung der von der Rechtsprechung entwickelten Grundsätze der sog. Produzentenhaftung in Betracht. Dies betrifft vor allem die Herstellung fertiger Betriebssystemdistributionen durch Distributoren. Im Rahmen einer solchen Produzentenhaftung wird in
verschiedener Hinsicht die Beweisführung des Verletzten erleichtert.55
54
55
Vgl. § 1 Abs. 1 ProdHaftG.
Vgl. dazu Schiffner, Open Source Software (2002), S. 253 f.
Seite 65
7.6
Einsatz von OSS: Mitverschulden
Sowohl bei der vertraglichen als auch bei der außervertraglichen Haftung ist zu berücksichtigen, dass die Ansprüche jeweils durch ein Mitverschulden der Behörde ganz oder
teilweise im Umfang begrenzt sein können. Im Grenzfall können sie sogar wegen eines
„überwiegenden― Mitverschuldens der Behörde vollständig entfallen.
Ein wichtiger Bereich, in dem in der Praxis gehäuft Probleme eines möglichen Mitverschuldens auftreten, ist die Haftung für den Verlust von Datenbeständen. Hier ist zu
beachten, dass es im gewerblichen Anwenderbereich vielfach als selbstverständlich
angesehen wird, dass der Anwender eine zuverlässige, zeitnahe und umfassende
Sicherung der Daten sicherstellt. Entsprechende Anforderungen wird man auch an
Behörden stellen dürfen.
7.7
Ein Vergleich zwischen der Migration zu proprietärer Software und zu OSS zeigt, dass
dort, wo entgeltliche Verträge geschlossen werden, weitgehende Parallelen in der Haftung und Gewährleistung bestehen.
Beim Erwerb der Software zur Benutzung innerhalb der Behörde ist Anspruchsgegner
der vertraglichen Haftung und Gewährleistung der jeweilige Vertragspartner des Überlassungsvertrages. Dies gilt sowohl für eine Migration zu OSS als auch für eine Migration
zu proprietärer Software. Arbeitet die Software nicht vertragsgemäß oder stehen Rechte
Dritter einer Benutzung entgegen, ist stets der Händler zur Beseitigung der Beeinträchtigung verpflichtet. Der Händler haftet auch für Schäden an sonstigen Rechtsgütern der
Behörde. Der gesetzliche Haftungsumfang ist dabei derselbe, solange die Software entgeltlich erworben wird.
Macht die Behörde hingegen von der bei Migration zu OSS bestehenden Möglichkeit
Gebrauch, die Software kostenlos zu erwerben, so muss sie Abstriche im Haftungs- und
Gewährleistungsumfang hinnehmen, da das Gesetz den Softwarelieferanten bei einer
unentgeltlichen Überlassung privilegiert. Hier kann zu überlegen sein, ob die ersparten
Erwerbskosten für eine Risikoabsicherung (Supportverträge, Garantieverträge, Versicherungen) eingesetzt werden. Bei Abschluss entsprechender Verträge ergeben sich keine
entscheidungserheblichen Unterschiede zwischen OSS und proprietärer Software bei
der Frage der Haftung und Gewährleistung.
Will die Behörde Lizenzrechte erwerben, etwa um die Software zu vervielfältigen, anzupassen oder an andere Behörden weiterzugeben, so werden bei OSS diese Rechte stets
kostenlos eingeräumt. Bei der Migration zu proprietärer Software bedarf es hingegen
regelmäßig – soweit überhaupt eine entsprechende Rechtseinräumung erfolgt – der
Zahlung einer Lizenzgebühr. Aufgrund dieser Unterschiedlichkeit der zugrunde liegenden Verträge variiert auch der Haftungs- und Gewährleistungsmaßstab beträchtlich. Bei
kostenloser Einräumung besteht eine weitgehende Privilegierung. Hier steht es der
Behörde bei der Migration zu OSS allerdings offen, ersparte Erwerbskosten für den
Abschluss einer Versicherung einzusetzen.
Gewisse Unterschiede im Haftungsumfang bestehen im Bereich der außervertraglichen
Haftung. Da der proprietäre Hersteller auf sämtliche Schritte im Entwicklungsprozess
Einfluss nehmen kann, wird man auch einen höheren Sorgfaltsmaßstab anlegen können.
Seite 66
Allerdings spielt die außervertragliche Haftung des Herstellers von Computerprogrammen in der Praxis bisher allenfalls eine untergeordnete Rolle.
8
8.1
Vergaberecht
Allgemeines
Die Wahl der Behörde zwischen einer Migration zu proprietärer Software und einer
Migration zu OSS hat unter Beachtung der Prinzipien des Vergaberechts zu erfolgen56.
Die Beschaffung von Informationstechnologie muss grundsätzlich nach Maßgabe des
Wettbewerbsprinzips erfolgen, vgl. § 97 Abs. 1 GWB. Hierbei sind alle Bewerber gleich
zu behandeln ("Gleichbehandlungsgrundsatz", vgl. § 97 Abs. 2 GWB). Vergabefremde
Kriterien, die nicht an die Wirtschaftlichkeit des Angebots oder die Fachkunde,
Leistungsfähigkeit und Zuverlässigkeit des Bewerbers anknüpfen, dürfen nicht berücksichtigt werden (vgl. § 97 Abs. 4 GWB).
Überschreitet der Beschaffungsauftrag die Schwellenwerte der Vergabeverordnung57, so
besteht für die übergangenen Bieter die Möglichkeit, eine Nachprüfung der Vergabeentscheidung nach den Vorschriften des GWB zu beantragen. Dies kann zu einer
Verzögerung der Beschaffung führen und birgt das Risiko zusätzlicher Kosten für das
Verfahren vor der Vergabekammer und die gegebenenfalls erforderliche erneute Ausschreibung, falls die Behörde die Vergaberechtsprinzipien missachtet hat. Deswegen
sollte sich die Vergabestelle an die folgenden Hinweise halten. Diese basieren auf einer
Auswertung der vergaberechtlichen Fachliteratur. Eine Klärung der Rechtslage durch die
Vergabekammern des Bundes und der Länder sowie der Gerichte fehlt bislang.
8.2
Beschaffung von OSS: Neutrale Ausschreibung
Aus dem Wettbewerbsprinzip und dem Gleichbehandlungsgrundsatz ergibt sich als erste
Anforderung an eine vergaberechtskonforme Beschaffung, dass in der Ausschreibung
die geforderten Leistungen neutral beschrieben werden. Die Anforderungen an eine
neutrale Leistungsbeschreibung sind in § 8 VOL/A näher bestimmt. Gemäß § 8 Nr. 3
Abs. 3 VOL/A ist es nur gestattet, bestimmte Erzeugnisse oder Verfahren vorzuschreiben, wenn "dies durch die Art der zu vergebenden Leistung gerechtfertigt ist.― In Abs. 4
heißt es weiter, dass die Beschreibung technischer Merkmale nicht die Wirkung haben
darf, "dass bestimmte Unternehmen oder Erzeugnisse bevorzugt oder ausgeschlossen
werden, es sei denn, dass eine solche Beschreibung durch die zu vergebende Leistung
gerechtfertigt ist.― In der juristischen Fachliteratur wird zum Teil unter Berufung auf die
genannten Bestimmungen gefordert, dass eine Ausschreibung für IT-Aufträge nicht von
vornherein auf Open Source Software beschränkt erfolgen darf. Eine solche Sichtweise
erscheint jedoch als zu undifferenziert.
56
57
Vgl. zum Folgenden eingehend Heckmann, IT-Vergabe, Open Source Software und Vergaberecht, Computer und Recht 2004, 401 sowie Demmel/Herten-Koch, Vergaberechtliche
Probleme bei der Beschaffung von Open-Source Software, Neue Zeitschrift für Baurecht
2004, 187; Müller/Gerlach, Open-Source-Software und Vergaberecht, Computer und Recht
2005, 87.
IT-Aufträge der obersten und oberen Bundesbehörden und vergleichbarer Bundeseinrichtungen: 137.000 €, alle anderen IT-Aufträge: 211.000 €.
Seite 67
Im Grundsatz gilt, dass die Ausschreibung die geforderten Leistungen in einer Weise
beschreiben muss, die es auch den proprietären Konkurrenzprodukten ermöglicht, ihre
Leistungen anzubieten, soweit die Ziele der Behörde auch mit diesen erreicht werden
können. Danach muss im Grundsatz sowohl auf eine Leistungsbeschreibung "LinuxServer" als auch auf die Bezeichnungen "Open Source oder quelloffene Software" verzichtet werden. Stattdessen sind die konkreten Merkmale der geforderten Leistungen
abstrakt zu beschreiben, damit auch proprietäre Konkurrenten ihre Leistungen anbieten
können.
Es ist also statt der Bezeichnung "Linux-Server" neutral zu beschreiben, welche Merkmale der Server erfüllen soll. Sind die Vorgaben entsprechend neutral formuliert, sollten
zumindest auch Server, die mit anderen UNIX-Derivaten betrieben werden, die Spezifikationen erfüllen können.
Statt "Open Source Software" sollte beschrieben werden, welche konkreten Ziele die
Behörde hiermit erreichen möchte. Es erscheint als vergaberechtlich bedenklich, pauschal die Offenlegung der Quellcodes zu verlangen, wenn für die Bieter nicht erkennbar
ist, warum die Behörde die geforderten Merkmale verlangt. Dagegen erscheint der
Hinweis auf das Erfordernis offener Quellcodes als zulässig, sofern die Behörde beispielsweise angibt, dass ein erhöhtes Maß an Sicherheit gegen "backdoors", Virenattacken und Ähnliches für die Erfüllung der öffentlichen Aufgabe erforderlich ist oder die
spätere Anpassung oder Pflege der Software den Erhalt der Quellcodes voraussetzen.
Dies bietet proprietären Bietern die Möglichkeit, sich durch eine Offenlegung im Einzelfall
an der Ausschreibung zu beteiligen.58
Die gleichen Grundsätze gelten für Leistungsbeschreibungen, die die OSS-Lizenzen als
Leistungsanforderungen beinhalten ("GPL-Software" o.ä.). Entsprechende Anforderungen sollten durch neutrale Beschreibungen ersetzt werden, die auf den Umfang der gewünschten Nutzungsrechte hinweisen und erkennen lassen, wofür die Behörde diese
Rechte einsetzen möchte. Es kann sachlich gerechtfertigt sein, wenn die Behörde die
Nutzungsrechte erwerben möchte, um das Programm später durch eigene Mitarbeiter
oder andere Anbieter fortentwickeln zu lassen oder wenn sie das Programm zu möglichst kostengünstigen Konditionen auf weiteren Arbeitsplätzen oder an weiteren Dienststellen einsetzen möchte. Dennoch sollte auch im Hinblick auf die Nutzungsrechte proprietären Geboten eine Chance gegeben werden, in dem der gewünschte Umfang der zu
erwerbenden Nutzungsrechte abstrakt beschrieben wird. Die Vorzüge von OSS dürfen
bei der Leistungsbeschreibung also durchaus inhaltlich berücksichtigt werden.
Anforderungen aus dem Gesichtspunkt der neutralen Ausschreibung ergeben sich auch
für den Zuschnitt der Ausschreibung. In diesem Zusammenhang wird insbesondere die
Frage diskutiert, ob Softwareüberlassung und Support stets gemeinsam auszuschreiben
sind oder auch getrennt beschafft werden können. Zum Teil wird in der Aufspaltung der
beiden Leistungen ein Verstoß gegen das Gebot der neutralen Ausschreibung gesehen,
weil die Vergabestelle durch die Aufspaltung der einzelnen Bestandteile die eigentliche
58
Dass dies proprietären Anbietern eine realistische Chance eröffnet, zeigt das "Shared
Source"-Programm von Microsoft, welches bestimmten Lizenznehmern Einblick in die
Quelltexte der Microsoft-Programme gewährt. Siehe hierzu
http://www.microsoft.com/resources/sharedsource/default.mspx.
Seite 68
Wirtschaftlichkeitsentscheidung umgehe.59 Dies sei insbesondere dann der Fall, wenn
die Lieferung von Open Source als kostenlos eingeordnet wird, was unter Umständen
sogar zur Folge hätte, dass die Leistung überhaupt nicht ausgeschrieben werden
müsste, 60 während der kostenpflichtige Support ausgeschrieben wird. Ein vollständiges
Bild könne nur gewonnen werden, wenn jeweils Software und Support gemeinsam als
einheitliches Erfüllungsgeschäft verglichen werden. Die Ausschreibung müsse den
Vergleich der jeweiligen Gesamtwirtschaftlichkeit gestatten, um nicht von vornherein die
proprietären Anbieter zu benachteiligen. Diese Sichtweise erscheint jedoch als zu
restriktiv61. Das einheitliche Angebot von Software und Support durch einen Anbieter
entspricht nicht der branchenüblichen Praxis und ist vergaberechtlich nicht erforderlich.
Im Übrigen ist darauf zu verweisen, dass das Vergaberecht – wie das Wettbewerbsrecht
insgesamt – der Kopplung von Leistungen eher kritisch gegenübersteht.
Dementsprechend schreibt § 97 Abs. 3 GWB ausdrücklich vor, dass Ausschreibungen
grundsätzlich in Teillosen erfolgen sollen, um auf diese Weise kleinen und
mittelständischen Unternehmen die Beteiligung an entsprechenden Ausschreibungen zu
ermöglichen.
8.3
Beschaffung von OSS: transparente Ausschreibung
Um einen echten Wettbewerb zwischen den Angeboten zu erreichen, sind in der Ausschreibung alle die Entscheidung beeinflussenden Umstände aufzunehmen (vgl. § 97
Abs. 1 GWB, § 8 Abs. 2 VOL). Faktoren, die in der Ausschreibung nicht genannt wurden,
dürfen später bei der Entscheidung nicht berücksichtigt werden.
Behörden, die eine Migration zu OSS in Betracht ziehen, müssen deswegen bereits in
der Ausschreibung auf die Eigenschaften hinweisen, die für eine solche Entscheidung
sprechen könnten. Dies sollte allerdings in einer Weise geschehen, die es auch
Anbietern proprietärer Produkte ermöglicht, sich an der Ausschreibung zu beteiligen. Es
erscheint als vergaberechtlich unbedenklich, wenn auf die besondere Bedeutung der
Kompatibilität der Programme und der mit diesen Programmen erzeugten Dateien mit
anderen Programmen und deren erzeugten Dateien hingewiesen wird. Auch sollte auf
die Bedeutung der Verwendung von Standardschnittstellen verwiesen werden. Es kann
auch dazu angeführt werden, dass eine größtmögliche Unabhängigkeit von einzelnen
Anbietern im Hinblick auf andere Informationstechnologien, aber auch im Hinblick auf
Supportdienstleistungen gewünscht wird. Auch sollte bereits in der Ausschreibung
klargestellt werden, dass Leistungen gefordert sind, die eine nachhaltige Entwicklung der
Behördenhard- und -software versprechen.
Entsprechende Leistungsbeschreibungen sollten es allen Bietern gestatten, sich auf die
Entscheidungskriterien der Behörde einzustellen und die Gebote entsprechend auszurichten.
59
60
61
So insb. Heckmann, a.a.O., 402.
Vgl. § 99 GWB: "Öffentliche Aufträge sind entgeltliche Verträge [...].
So Müller/Gerlach, a.a.O., 89.
Seite 69
8.4
Beschaffung von OSS: Vergabeentscheidung
Der vergaberechtlich richtige Zeitpunkt für eine Migrationsentscheidung ist die Wertung
der Angebote bei der Vergabeentscheidung. Der Zuschlag ist gemäß § 97 Abs. 5 GWB
auf das wirtschaftlichste Angebot zu erteilen. § 25 Nr. 3 VOL/A bestimmt näher, dass der
niedrigste Angebotspreis nicht allein entscheidend ist. Es ist deswegen vergaberechtlich
nicht zu beanstanden, wenn sich Behörden entgegen kurzfristiger monetärer Anreize für
ein höherwertiges Angebot entscheiden. Entscheidend für die Wirtschaftlichkeit eines
Angebots ist das günstigste Verhältnis zwischen der gewünschten Leistung und dem
angebotenen Preis.
Vergabefremde Kriterien sind dabei auszuscheiden, es sei denn, sie sind ausdrücklich
durch Bundes- oder Landesgesetz vorgesehen (vgl. § 97 Abs. 4 GWB). Entsprechende
Gesetze, welche eine bevorzugte Beschaffung von OSS vorschreiben, sind bislang nicht
erlassen worden, und zwar weder auf Bundes- noch auf Landesebene. "Grundsatzbeschlüsse", wie etwa der des Deutschen Bundestags vom 09.11.2003, in welchem der
Bundestag "die Einführung von unter Open-Source-Lizenzen erstellten Produkten in der
Bundesverwaltung" gefordert hat62, können weder als Ersatz für ein Gesetz im Sinne von
§ 97 Abs. 4 GWB bewertet werden, noch entbinden sie Behörden von den Vorgaben des
Vergaberechts. Die Vergabeentscheidung ist also auch bei Vorliegen entsprechender
Empfehlungen nach dem Wirtschaftlichkeitsprinzip auszurichten.
Bei Anlegung dieser Grundsätze ergibt sich das folgende Bild: Pauschale Hinweise auf
die Förderung von OSS oder des Wettbewerbs auf den IT-Märkten sind als vergabefremde Kriterien unzulässig. Die IT-Beschaffung durch Behörden ist nicht der richtige
Platz, um Wettbewerbspolitik zu betreiben. Das Gleiche gilt für sozialpolitische oder
sonstige allgemeine Erwägungen. Behörden dürfen entsprechende Argumente bei der
Begründung einer Vergabeentscheidung nicht zugrunde legen.
Es ist aber darauf hinzuweisen, dass sich Behörden nicht mit einem einfachen
Preisvergleich der Gesamtangebote begnügen müssen. Die Erfahrung zeigt, dass
kurzfristige finanzielle Vorteile oftmals später teuer bezahlt werden müssen. Dies kann
insbesondere dann der Fall sein, wenn Behörden Produkte anschaffen, die nur mit
Produkten desselben Anbieters kombiniert werden können oder für die ausschließlich
dieser Anbieter Supportleistungen anbietet. Kurzfristige Preisnachteile können
mittelfristig durch die Unabhängigkeit von einzelnen Anbietern auf den Folgemärkten
ausgeglichen werden. OSS bietet hier einen strategischen Vorteil. Offene Quelltexte und
die Freiheit, Änderungen an diesen vorzunehmen, sorgen dafür, dass wichtige
Folgemärkte für eine Mehrzahl von Anbietern offen stehen. Dies sorgt für Wettbewerb
und Kostenvorteile. Eine entsprechende Einbeziehung konkret absehbarer Begleit- und
Folgekosten ist im Sinne einer nachhaltigen Verwendung öffentlicher Mittel
wünschenswert. Es sollte hierbei aber nicht direkt auf die zu erwartenden mittel- und
langfristigen Kosten verwiesen werden, denn die Vergabekriterien müssen stets auf die
ausgeschriebene Leistung bezogen sein. Vielmehr müssen die genannten
Eigenschaften von OSS als Vorteil einer Migration zu OSS im Rahmen des PreisLeistungs-Vergleichs berücksichtigt werden. Die technische und rechtliche
62
Vgl. den dem Beschluss zugrunde liegenden Antrag der Regierungsfraktionen, Bundestags-Drucksache 14/5246, S. 4 ff.
Seite 70
Unabhängigkeit auf Folgemärkten ist deshalb als werthaltige Eigenschaft des Angebots
zu berücksichtigen.
Vergaberechtlich zulässig sind auch alle sonstigen Kriterien, denen Aussagekraft für die
Leistungsfähigkeit der einzelnen Angebote zukommt. Hier können unter anderem einbezogen werden: die technische Sicherheit der IT-Angebote, die Kompatibilität mit anderen
Programmen, die Kompatibilität der mit dem Programm erzeugten Dokumente, die technischen und rechtlichen Nutzungsmöglichkeiten, Fragen der Haftung und Gewährleistung. Entsprechende Kriterien dürfen allerdings nur unter der Voraussetzung berücksichtigt werden, dass sie in der Ausschreibung ausdrücklich benannt worden sind.
8.5
Die Anforderungen des Vergaberechts gelten in gleichem Maße für eine Migration zu
OSS wie eine Migration zu proprietärer Software. Ausschreibungen dürfen nicht so
gestaltet sein, dass bestimmte Bieter, seien es Anbieter proprietärer oder OSS-Produkte,
von vornherein faktisch ausgeschlossen sind. Hierauf zielen der Grundsatzbeschluss
des Deutschen Bundestags vom 09.11.2003 und ähnliche Entschließungen im Ergebnis
ab.
Allerdings bestehen im Hinblick auf proprietäre IT-Produkte vergaberechtliche Probleme,
die auf OSS nicht in gleichem Maße zutreffen. Dies gilt insbesondere für das oft anzutreffende Problem der mangelnden Kompatibilität von Software einzelner Anbieter mit
den Produkten anderer Anbieter. Hier hat sich in der Vergangenheit für Behörden häufig
das Problem gestellt, dass bei der Migration von Teilen der eigenen IT-Infrastruktur letztlich nur Leistungen desselben Bieters in Betracht gezogen worden sind, da eine Migrationsstrategien auf Produkte anderer Anbieter mit technischen Hürden verbunden gewesen wäre.
Andere Bieter hatten es auch in solchen Fällen schwer, sich durchzusetzen, in denen die
Behörde elektronische Dokumente mit anderen Behörden oder Privaten austauschen
muss, wobei die Programme eines Anbieters bei den anderen Behörden oder Privaten
eine Art faktischer Standard darstellen, ohne dass auf die Dokumente mit anderen Programmen zugegriffen werden kann. Dieses Problem hat in den letzten Jahren beispielsweise eine Migration zu OSS von MS Office zu anderen Produkten aus der Sicht vieler
Behörden verhindert. Das Wettbewerbsprinzip ist bei entsprechenden Beschaffungsvorgängen oft auf vergaberechtlich unzulässige Weise ausgehebelt worden, indem eine
Überprüfung der Kompatibilität anderer Programme gar nicht erst vorgenommen worden
ist.63
Entsprechende Probleme ergeben sich bei OSS in geringerem Maße, da OSSProgramme oftmals auf eine größtmögliche Kompatibilität mit anderen, auch proprietären Produkten ausgelegt sind. So gestattet etwa OpenOffice.org den Export von Textdateien als PDF-Dokumente sowie das Abspeichern als MS Word Dokument. Von besonderer Bedeutung ist auch, dass das standardmäßige Dateiformat in OpenOffice.org
ein offenes XML-Dateiformat ist. Es kann damit auch auf entsprechende Dokumente
63
Vgl. beispielsweise Bundeskartellamt, 2. Vergabekammer des Bundes, Beschluss vom
08.08.2003, AZ: VK 2-52/03, S. 30-32 (abrufbar unter http://www.bundeskartellamt.de).
Seite 71
zugegriffen werden, ohne OpenOffice.org zu benutzen. Die Systemabhängigkeit ist dadurch abgeschwächt, die technischen Hürden für eine Migration sind geringer. Der Einsatz von technischen Lösungen, welche den Übergang zu anderen Produkten erleichtert,
verringert vergaberechtliche Probleme bei der Beschaffung von IT-Produkten.
9
Fazit
Eine Gesamtschau der untersuchten rechtlichen Fragen lässt weder den Schluss auf ein
erhöhtes Rechtsrisiko bei einer Migration zu proprietärer Software, noch einer Migration
zu OSS zu. Behörden sollten sich deswegen nicht mit dem pauschalen Hinweis auf
angebliche rechtliche Gefahren von einer Migration zu OSS abschrecken lassen. In der
Summe erscheinen die Risiken von OSS und proprietärer Software als durchaus
vergleichbar. Eine abschließende Evaluierung hängt allerdings in jedem Einzelfall von
den in Frage stehenden Programmen, den Anbietern, den jeweiligen Vertragsgestaltungen und sonstigen Konditionen sowie der gewünschten Nutzung durch die
Behörde ab.
Neben den rechtlichen Risiken sollten die lizenzrechtlichen Vorteile von OSS bei der
Auswahlentscheidung berücksichtigt werden. OSS Lizenzen gestatten die Nutzung der
Programme in umfassender Weise. OSS darf von jedem Nutzer beliebig eingesetzt,
verändert, vervielfältigt und verbreitet werden. Daraus ergeben sich für Behörden
strategische Vorteile. Dienstleistungen und Anpassungen der Programme können nicht
nur vom Anbieter des Programms, sondern von unterschiedlichen Serviceunternehmen
erbracht werden. Dies kann zu Kostenvorteilen führen. Möchte die Behörde später den
Umfang oder die sonstigen Bedingungen der Nutzung verändern, so bedarf es nicht
eines kostenintensiven Nachkaufs von entsprechenden Nutzungsrechten. Gleiches gilt
bei Anpassungen des Programms. Diese lizenzrechtlichen Vorteile sollten einbezogen
werden, um zu einer sachgerechten Auswahlentscheidung zwischen OSS und proprietärer Software zu gelangen.
Seite 72
C Thema: Wirtschaftliche Aspekte von Softwaremigrationen
1
Vorwort
In dem vorliegenden Abschnitt wird eine angepasste Methodik zur Durchführung von
Wirtschaftlichkeitsbetrachtungen zur Migration von Basissoftwarekomponenten 64 auf
Server- und Arbeitsplatz-Systemen offeriert. Grundlage dafür sind die Bewertungsmethoden und -kriterien der WiBe 4.165, der IT-Updates66 sowie des Migrationsleitfadens
1.067.
Mit den Hinweisen und Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen bei IT-Update- beziehungsweise Umstellungsvorhaben aus dem Jahre 2000
existierte schon damals eine spezifische Anleitung. Diese wurde im Jahr 2003 durch den
Migrationsleitfaden ergänzt. In 2004 folgte eine vollständig überarbeitete Ausgabe der
WiBe in der Version 4.0 und im Jahre 2007 wurde die WiBe 4.1 veröffentlicht.
In einer behördenübergreifenden Expertengruppe wurden die in diesen Basiswerken
vorhandenen Kriterien und deren Definition auf die Anwendbarkeit speziell für Migrationen geprüft, selektiert und gegebenenfalls ergänzt beziehungsweise modifiziert. Somit
ist ein Leitfaden entstanden, der dem Anwender gezielte Unterstützung für Migrationsvorhaben geben soll.
2
Einleitung
Wie die Diskussion über die auf dem Markt verfügbaren Studien zum Thema Total Cost
of Ownership (TCO) beim Einsatz von Open Source Software (OSS) und proprietärer
Software unter Linux zeigt, ist die Durchführung einer Wirtschaftlichkeitsbetrachtung für
IT-Maßnahmen generell sehr schwierig und wird bei den häufig multidimensionalen Wirtschaftlichkeitsmodellen zu einer nahezu unlösbaren Aufgabe.
Bei einer breit gefächerten und facettenreichen Analyse – was beim Vergleich von Kosten für Microsoft- und OSS/Linux-Plattformen zweifelsohne der Fall ist – gehört die Herstellung der Vergleichbarkeit der Untersuchungsobjekte sowie des richtigen Umfangs der
Analyse zu den wesentlichen Aufgaben.
Eine weitere Notwendigkeit bei der Untersuchung besteht in der Berücksichtigung der
Nutzerstrukturen. Insbesondere die Größe von Organisationen und die unterschiedlichen
Ausgangsszenarien der IT-Umgebung sind relevant für die Wirtschaftlichkeitsbetrach-
64
65
66
67
Im Einzelnen sind darunter folgende Komponenten zu verstehen: Serverdienste, Standardsoftware, Bürokommunikation, Dokumente und Makros; siehe auch Kapitel I.C 4.
Siehe hierzu WiBe 4.1, Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen
in der Bundesverwaltung, insbesondere beim Einsatz der IT, Version 4.1, Schriftenreihe der
KBSt, Band 92, Januar 2007, www.kbst.bund.de.
Siehe hierzu Hinweise und Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen bei IT-Update- beziehungsweise Umstellungsvorhaben auf Grundlage der IT-WiBe97, Schriftenreihe der KBSt, ISSN 0179-7263´, Brief 04/2000, November 2000.
Siehe hierzu Migrationsleitfaden, Leitfaden für die Migration der Basissoftwarekomponenten auf Server- und Arbeitsplatz-Systemen, Version 1.0, Schriftenreihe der KBSt, ISSN
0179-7263, Band 57, Juli 2003.
Seite 73
tung einer Migration. Häufig kann beobachtet werden, dass in kleineren Behörden (beispielsweise im kommunalen Sektor) die IT-Infrastruktur mit einfachen Mitteln und ohne
intensive Ausbildung der Beteiligten aufgebaut und betrieben werden kann. Auf der anderen Seite erfordert der zuverlässige Betrieb von Infrastrukturen oder Rechenzentren
für große und/oder spezialisierte Behörden und Datenzentralen mit Service Level Agreements einen erhöhten Ausbildungsstand der Mitarbeiter, organisatorische Regelungen für Ausfall- und Notfallzeiten sowie häufig eine andere Hardware-Ausstattung.
Unter Berücksichtigung dieser Randbedingungen ist für die IuK-Wirtschaftlichkeit eine
mehrdimensionale Betrachtung notwendig. Im Vorfeld der Untersuchung der IT-Kosten
gilt, dass ein wesentlicher Beitrag zur Erhöhung der Wirtschaftlichkeit zunächst einmal
durch personelle, organisatorische und rationalisierende Maßnahmen in den Verwaltungen erreicht werden kann. Darüber hinaus kann jedoch durch eine entsprechend ausgelegte IT-Strategie ebenfalls ein wesentlicher Beitrag zur Erhöhung der Wirtschaftlichkeit
geliefert werden.
Die Gesamtwirtschaftlichkeit der IT wird stark beeinflusst durch:

den Grad der funktionalen Abdeckung durch preiswerte Standardprodukte,

Qualität, Änderungsflexibilität und Entwicklungsfähigkeit der eingesetzten Standards, Technologien und Produkte,

effizientes Einführungs- und Systemmanagement,

bruchfreie Integration von Komponenten und Systemen in einer prozessorientierten Wertschöpfungskette,

gute (interne oder externe) Service-Organisation sowie hochwertiges Know-how,

wirtschaftliche Lebenszyklen der Produkte,

Kosten und Effizienz des Beschaffungsprozesses, sowie

Wettbewerb bei Produkten und Dienstleistungen
Erst ein optimales Zusammenspiel all dieser Faktoren über einen längeren Betrachtungszeitraum bedingt und beeinflusst die Wirtschaftlichkeit insgesamt, sodass eine vereinfachte Betrachtung von Einzelkosten das Gesamtbild in der Regel nicht korrekt widerspiegeln kann.
Neben der Ermittlung und dem Vergleich von Kosten bedeutet auch die Beurteilung der
möglichen Nutzwerte einen wesentlichen Aspekt der Wirtschaftlichkeitsbetrachtung. Insbesondere in diesem Bereich spielen strategische Überlegungen und prognostizierte
Vorteile eine wichtige Rolle, um sowohl die Ausgangssituation als auch die Perspektive
ganzheitlich beurteilen zu können.
Beispiel: Die auf eine vereinzelte Komponente bezogenen Mehrkosten können in der
strategischen Betrachtung durch die erreichte Herstellerunabhängigkeit eine bessere
Verhandlungsposition bei Softwarelizenzpreisen zu einem insgesamt deutlich günstigeren Gesamtergebnis führen. Diese Zusammenhänge einer Gesamtbetrachtung von Kosten und Nutzwert werden besonders deutlich im Ergebnis der „Client Studie der Landes-
Seite 74
hauptstadt München―68, die im Ergebnis der monetären Wirtschaftlichkeitsbetrachtung
eine Migration nach Windows XP und Office XP als wirtschaftlicher sieht und dagegen in
der Gesamtbetrachtung von monetärer Wirtschaftlichkeit und Nutzwertbetrachtung ein
Zielsystem mit Linux und Open Office.org präferiert69.
Sowohl die Methode als auch das Ergebnis kann aus diesen Gründen lediglich als Hilfe
bei der Ermittlung der eigenen Wirtschaftlichkeit und somit bei der Formulierung der eigenen IT-Strategie dienen.
Das Hauptaugenmerk liegt auf der Methodenvermittlung. Berechnungsbeispiele werden
nur und ausschließlich zu Verständniszwecken eingefügt.
Eine Produktivitätsbetrachtung in der IT-Wertschöpfungskette findet im Umfang dieses
Leitfadens nicht statt, da entsprechende neutrale Langzeituntersuchungen, insbesondere in der Verwaltung, nicht vorhanden sind. Sie würde auf Basis heutiger Erfahrungen
und insbesondere im Hinblick darauf, dass es sich sowohl bei Linux/Unix- als auch Microsoft-Plattformen um reife Produkte mit langjähriger Entwicklungszeit handelt, voraussichtlich zu einem ausgewogenen Ergebnis führen.
Weiterhin werden im Rahmen der nachfolgenden Wirtschaftlichkeitsbetrachtungen die
Auswirkungen von besonderen Integrationsaspekten nicht tiefer gehend betrachtet. Eine
detaillierte Berücksichtigung der Integrationsaspekte kann aufgrund der Zielsetzungen
nur im Rahmen der Behörden und damit anforderungsspezifischen Wirtschaftlichkeitsbetrachtungen hinreichend qualifiziert erfolgen.
3
Methodische Grundsätze
Nr. 2.1 der Verwaltungsvorschrift zu § 7 Bundeshaushaltsordnung (BHO) führt aus:
„Wirtschaftlichkeitsuntersuchungen in der Planungsphase bilden die Grundlage für die
begleitenden und abschließenden Erfolgskontrollen. Wirtschaftlichkeitsuntersuchungen
müssen mindestens Aussagen zu folgenden Teilaspekten enthalten:
68
69

Analyse der Ausgangslage und des Handlungsbedarfs,

Ziele, Prioritätsvorstellungen und mögliche Zielkonflikte,

relevante Lösungsmöglichkeiten und deren Nutzen und Kosten (einschl. Folgekosten), auch soweit sie nicht in Geld auszudrücken sind,

finanzielle Auswirkungen auf den Haushalt,

Eignung der einzelnen Lösungsmöglichkeiten zur Erreichung der Ziele unter Einbeziehung der rechtlichen, organisatorischen und personellen Rahmenbedingungen,
Erstellt durch Unilog Integrata Unternehmensberatung GmbH, Unilog Management,
unterstützt durch die Landeshauptstadt München, Direktorium AfID, Abt. 5, München 2003
http://www.muenchen.de/vip8/prod2/mde/_de/rubriken/Rathaus/40_dir/limux/publikationen/
clientstudie_kurz.pdf.
Bei der Betrachtung der Ergebnisse der Studie lohnt es sich genau hin zu sehen. Zu einem
wo die Gründe für die Vorteile von XP bei der monetären Wirtschaftlichkeit herrühren und
zum anderen, woraus sich die Gründe Vorteile von Linux und OSS in einer Nutzwertbetrachtung herleiten lassen.
Seite 75

Zeitplan für die Durchführung der Maßnahme,

Kriterien und Verfahren für Erfolgskontrollen
he Nr. 2.2, VV zu § 7 BHO)."
(sie-
Diese Anforderungen stellen prinzipiell den Rahmen und die Struktur für die Wirtschaftlichkeitsbetrachtungen dar.
Alternativen
Alternativen
vergleichen
vergleichen
Ziele
Ziele // RahmenRahmenBedingungen
Bedingungen
identifizieren
identifizieren
Vorgaben
Vorgaben //
Annahmen
Annahmen
definieren
definieren
Wirtschaftlichkeit
Wirtschaftlichkeit
(Kosten/
(Kosten/ Nutzen)
Nutzen)
ermitteln
ermitteln
Modell
Modell der
der
WirtschaftlichWirtschaftlichkeitsbetrachtung
keitsbetrachtung
abstimmen
abstimmen
Personaleinsatz
Personaleinsatz
planen
planen
Projektplan
Projektplan mit
mit
Maßnahmen
Maßnahmen
erstellen
erstellen
Kostenansätze
Kostenansätze
für
für Lösungen
Lösungen
erheben
erheben
Ausgangssituation
Ausgangssituation
erheben
erheben
Technische
Technische
LösungsLösungsmöglichkeiten
möglichkeiten
eruieren
eruieren
Abbildung 3: Regelkreis der Wirtschaftlichkeitsbetrachtung
Ein wesentlicher Bestandteil sind die Zielvorstellungen der Behörde, in diesem Zusammenhang auch mögliche Zielkonflikte sowie Rahmenbedingungen in Form von Vorgaben
und Annahmen. Die Abstimmung des Modells der Wirtschaftlichkeitsbetrachtung gehört
auch in diesen Bereich. Daneben ist die Ist-Situation der zu migrierenden IT-Landschaft
zu erheben, wobei Informationen zur Infrastruktur, der Hard- und Softwareprodukte, der
IT-Fachverfahren sowie behördenspezifischer Dokumentvorlagen ermittelt werden. Auf
dieser Basis werden technische Lösungsmöglichkeiten eruiert und mit Kostenansätzen
unterlegt. Dazu gehören neben den Kosten für Hard- und Software auch die Aufwendungen für externes und internes Personal. Die sich nun anschließende Ermittlung der
Wirtschaftlichkeit berechnet Kosten und Nutzen der IT-Maßnahme und die Auswirkungen auf den Haushalt. Zur Einschätzung der Personalkosten wird eine grobe Projektplanung erforderlich, die auch einen Zeitplan für die Durchführung der IT-Maßnahme beinhaltet.
Seite 76
3.1
Ziele und Rahmenbedingungen
3.1.1
Ziele
Vor der Durchführung einer jeden IT-Maßnahme sollten die im IT-Rahmenkonzept festgelegten oder aus strategischen Vorgaben abgeleiteten operativen Behördenziele festgestellt werden. Ein Abgleich dieser Ziele mit den IT-Maßnahmen reduziert mögliche
Konflikte mit den Zielvorgaben und anderen Projekten. Weiterhin wird hiermit der Grundstein für die in Nr. 2.2 der VV zu § 7 BHO geforderten Zielerreichungskontrolle gelegt.
Die Erstellung eines grundsätzlichen Ziel- und Anforderungssystems für die ITMaßnahme hilft, mögliche Lösungen unabhängig von der Wirtschaftlichkeit auf ihre Eignung hin zu prüfen. Hiermit wird konkret die Definition von Anforderungskriterien angesprochen, die für die einzelnen Lösungsalternativen in Form von Nutzwertanalysen 70 zu
bewerten sind. Einzelne dieser Kriterien oder Kriteriengruppen können im Rahmen der
Zielerreichungskontrolle als Messgröße dienen.
An dieser Stelle sei der Hinweis gegeben, dass die Definition der Zielsetzungen der Behörde und die damit verbundenen notwendigen Aktivitäten in einem separaten Strategieprozess gefunden werden sollten. Hierfür sind in der Praxis erprobte Methodiken verfügbar, die die Gesamt-Strategie einer Behörde definieren helfen und die strategische
Ableitung für die IT unterstützen.
3.1.2
Prämissen und Annahmen
Jede IT-Maßnahme muss im Kontext einer vorhandenen IT-Landschaft, einer existenten
Organisation und bestehender Gesetze, Vorschriften und Vorgaben durchgeführt werden. Daher wird es für den Erfolg der IT-Maßnahme zwingend notwendig, diese externen Einflussfaktoren zu identifizieren und zu dokumentieren. Auch die Ausgestaltung der
Durchführung der Wirtschaftlichkeitsberechnung beinhaltet i. d. R. spezifische Festlegungen, die einmal generell genannt und kurz beschrieben werden sollten. Grundsätzliche Wertansätze, die nicht in der Wirtschaftlichkeitsrechnung selbst ermittelt werden,
sondern von außerhalb des Systems übernommen werden (z. B. Personalkostenansätze). Solche Informationen, die eine wichtige Grundlage für die Berechnung darstellen,
sind festzuhalten. Als Beispiel sind nachfolgend einige als „Annahmen― bezeichnete
Rahmenbedingungen dargestellt.
Der Wirtschaftlichkeitsbetrachtung können z. B. folgende Prämissen zugrunde liegen:
70
1.
Zur Berechnung von Kapitalwerten wird ein Zinssatz in Höhe des empfohlenen Nominalzinses aus den Personalkostensätzen des BMF verwendet.
(Quelle: www.bundesfinanzministerium.de – Stichwort: Personalkostensätze)
2.
Personalkosten intern gemäß den Personalkostensätzen des BMF. (Quelle:
www.bundesfinanzministerium.de – Stichwort: Personalkostensätze)
siehe WiBe 4.0, Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der
Bundesverwaltung, insbesondere beim Einsatz der IT, Version 4.0 – 2004, „Berechnung
der erweiterten Wirtschaftlichkeit", S. 80 ff.
Seite 77
3.
Personalkosten extern: durchschnittlich 1.200 €/PT
4.
Der Abschreibungszeitraum für Hardware und Software wird auf 5 Jahre
festgelegt.
5.
Der Betrachtungszeitraum ist auf 8 Jahre definiert von 2005-2012.
6.
Die Betrachtung richtet sich auf Ist-Kosten.
7.
Prozessbezogene Produktivitätsveränderungen/-verbesserungen werden
nicht berücksichtigt.
3.2
Monetäre Analyse
Für die monetären Auswirkungen der Vorhaben wird die Kapitalwertmethode angewandt.
Als dynamisches Verfahren beurteilt sie Investitionsprojekte nach ihrem Kapitalwert, d. h.
durch belastbare Erfassung der mit der Investition zusammenhängenden Finanzströme
(Einnahmen und Ausgaben, haushaltswirksam und nicht haushaltswirksam), fokussiert
auf einen gemeinsamen Bezugszeitpunkt. Einnahmen, Ausgaben und Ersparnisse, die
mit dem Vorhaben zusammenhängen, können für die Jahre der wirtschaftlichen Nutzungsdauer im Voraus geplant werden. Für die künftigen Werte wird der aktuelle Zeitwert durch Abzinsung mit dem vom Bundesministerium der Finanzen festgelegten Zinssatz ermittelt.
3.3
Grundsätzliche Überlegungen zur Kostenerhebung
Nachfolgend werden grundsätzliche Überlegungen zur Erhebung der notwendigen Kosten durchgeführt. Dabei werden insbesondere die einzelnen Migrationsphasen und die
damit verbundenen Maßnahmen sowie die Personalkosten und die Preisstrukturen der
Anbieter in Augenschein genommen.
3.3.1
Migrationsphasen
Die Kosten für eine Migration lassen sich am besten identifizieren, wenn man sich ein
Phasenmodell zugrunde legt und die mit den einzelnen Phasen verbundenen Maßnahmen definiert. Das Modell, das hier zugrunde gelegt wird, umfasst drei Hauptphasen
(siehe Tabelle 9):

Planungsphase (Grob- und Feinkonzept)71
o
71
Workshops
(Kick-off, betroffene Fachabteilungen und IT-Disziplinen beteiligen, Identifizieren aller relevanten Themen, Prioritäten setzen, Entscheidungsbedarf
identifizieren, Vorgehensweise und Projektplan festlegen, detaillierte Aufwandsschätzung, Teilprojekte festlegen und Arbeitsgruppen zuweisen)
Die Wirtschaftlichkeitsbetrachtung begleitet dabei die gesamte Qualifizierungsphase.
Seite 78


o
Ist-Aufnahme
(Anwendungslandschaft, Kommunikationsbeziehungen, Netzwerkinfrastruktur, zentrale Dienste, Betriebsverfahren, zukünftige Anforderungen)
o
Lösungsansätze/ Grob- und Feinkonzepte
(Pflichtenheft erstellen, Projektplan verfeinern und Arbeitspakete definieren, technische Machbarkeit, Aufbau einer Integrations- und Testumgebung, Abbildung der übrigen Produktionsumgebung, Anwendungsintegration, Hardware-Auswahl und Evaluierung)
Realisierungsphase (Verfahrenserstellung/-entwicklung und Erprobung und Abnahme)
o
Konzepte, Verfahren, Installationen
(detaillierte Festlegung des Funktionsumfangs, Integration in die übrige
IT-Umgebung, Entwicklung der Installationsverfahren und Softwareverteilung, Integration in den Betrieb, Rollout-Planung, Pilotplanung, Ausbildung des DV-Personals)
o
Erprobung von Verfahren und Überprüfung der Funktion von Installationen (Feature Stop, repräsentative Benutzergruppe versorgen, Lasttests,
Einbindung des UHD (User Help Desk), erstmalige Sizing-Kontrolle,
Rückkopplung in Feinkonzept)
Einsatzphase (Einführung und Betrieb, Roll-Out)
Bereitstellen von Funktionen im Netzwerk und Installationen in der Fläche (Inbetriebnahme der Installationsverfahren, Serversysteme vervielfältigen, Benutzerinformation und –schulung, Begleitung durch Projektteam, Übergabe in den Regelbetrieb)
Planungsphase
(Grob- und Feinkonzepte, Workshops,
Lösungsansätze)
1
Feinkonzept/Pflichtenheft
2
Migrationsplan Infrastruktur
3
Migrationsplan Systemmanagement
4
Migrationsplan Client
5
Verabschiedung konsolidierter Migrationsplan
(fachliches Feinkonzept)
Seite 79
Realisierungsphase
(Verfahrenserstellung/-entwicklung,
Konzepte, Verfahren, Installationen)
(Erprobung und Abnahme von Verfahren, Funktionstest von Installationen)
6
Implementierung Basis Infrastruktur
7
Infrastrukturdienste
8
Systemmanagement
9
Groupware - Messaging
10
Terminalserver
11
Design Desktop
12
Installationsverfahren Desktop
13
Migration Funktionen Systemmanagement
14
Paketierung: 1 – 2 Applikationen / 1 MT
15
Pilotbetrieb 1 Monat / 20 – 50 Benutzer
16
Testlauf Migrationshandbuch
17
Dokumentation Migrationshandbuch
18
Migration der Daten-/Rechte Strukturen
19
Migration der Client Strukturen
Einsatzphase
(Einführung und Betrieb, Funktionen im
Netzwerk bereitstellen, Installationen in
der Fläche)
Tabelle 9: Migrationsphasen
3.3.2
Personalbedarf für die Migration
Personalaufwand entsteht bei der Migration an den unterschiedlichsten Positionen. In
Tabelle 9 sind die einzelnen Phasen in migrationstypische Aktivitäten untergliedert worden. Zu diesen Aktivitäten sind zusätzlich die Umstellung der Dokumente und Makros
sowie Projektmanagement, Qualitätssicherung und vor allen Dingen die Anwenderbetreuung zu planen. Die nachfolgenden Tabellen72 geben beispielhaft einen Überblick
über die prozentuale Verteilung der Personentage- und der Personalkosten-Planung73.
In der Abbildung 4 werden für drei Beispiel-Alternativen Personalaufwände in den einzelnen Aktivitäten dargestellt. In der Abbildung 5 werden für die drei Beispiel-Alternativen
die Personalaufwendungen um die oben aufgeführten zusätzlichen Aktivitäten mit denen
der Migrationsphasen zu einer Gesamtsicht zusammengeführt.
72
73
Da die Tabellen keine Nachkommastellen enthalten, können sich in Einzelfällen Rundungsdifferenzen ergeben.
Die hier abgebildeten Daten stehen beispielhaft für eine größere Behörde.
Seite 80
Nr Beschreibung
Phase
Variante 1
intern
Variante 2
extern
intern
Variante 3
extern
intern
extern
Su Kosten Gesamt €
Su Kosten intern/extern €
391.972
84.972 307.000
329.944
72.944 257.000
385.552
98.552 287.000
Su Personentage (PT) Gesamt
Su Personentage (PT) intern/extern
526,0
219,0
307,0
445,0
188,0
257,0
541,0
254,0
287,0
Planungsphase
(Workshops,
Lösungsansätze,
Grob- und Feinkonzepte)
62,0
30,0
10,0
10,0
10,0
2,0
122,0
30,0
30,0
30,0
30,0
2,0
62,0
30,0
10,0
10,0
10,0
2,0
107,0
30,0
25,0
25,0
25,0
2,0
62,0
30,0
10,0
10,0
10,0
2,0
122,0
30,0
30,0
30,0
30,0
2,0
137,0
155,0
111,0
130,0
132,0
135,0
72,0
15,0
20,0
12,0
20,0
5,0
98,0
17,0
25,0
16,0
35,0
5,0
51,0
8,0
10,0
8,0
20,0
5,0
77,0
10,0
15,0
12,0
35,0
5,0
65,0
15,0
20,0
12,0
15,0
3,0
77,0
10,0
25,0
12,0
30,0
Paketierung für APC-Implementierung
12 Installationsverfahren Desktop
13 Migration Funktionen Systemmgmt.
14 Paketierung: 1-2 Applikationen / 1MT
25,0
5,0
15,0
5,0
27,0
7,0
15,0
5,0
20,0
5,0
10,0
5,0
23,0
7,0
11,0
5,0
27,0
4,0
18,0
5,0
23,0
7,0
11,0
5,0
Pilot und Test
15 Pilotbetrieb 1 Monat / 20 - 50 Benutzer
16 Testlauf Migrationsverfahren
17 Dokumentation Migrationshandbuch
40,0
25,0
10,0
5,0
30,0
15,0
5,0
10,0
40,0
25,0
10,0
5,0
30,0
15,0
5,0
10,0
40,0
25,0
10,0
5,0
35,0
20,0
5,0
10,0
18 Migration der Daten-/Rechte Strukturen
19 Migration der Client Strukturen
20,0
10,0
10,0
30,0
20,0
10,0
15,0
5,0
10,0
20,0
10,0
10,0
60,0
10,0
50,0
30,0
20,0
10,0
Realisierungsphase
(Konzepte, Verfahren,
Installationen)
(Erprobung von Verfahren,
Funktionstest von
Installationen)
Einsatzphase (Funktionen im
Netzwerk bereitstellen,
Installationen in der Fläche)
1
2
3
4
5
Feinkonzept / Pflichtenheft
Migrationsplan Infrastruktur
Migrationsplan Systemmanagement
Migrationsplan Client
Verabschiedung konsoliderter Migr.plan
6
7
8
9
10
11
Implementierung Basis Infrastruktur
Systemmanagement
GroupWare - Messaging
Terminalserver
Design Desktop
Abbildung 4: Beispiel: Personalaufwendungen in den Migrationsphasen
Szenarien
Variante 1
Personentage Faktor
Su Kosten Gesamt €
Variante 2
extern
intern
765.795
Su Kosten intern/extern €
234.938
Su PT Gesamt
Migr.phasen
intern
Variante 4
Variante 3
extern
703.411
intern
extern
709.044
530.857 218.982 484.429 230.717 478.327
1136,4
1048,8
1073,0
Su PT intern/extern
605,5
530,9
564,4
484,4
594,6
478,3
Planung
162,2
220,2
135,7
194,7
159,1
199,7
Realisierung
40,8
30,6
40,8
30,6
40,8
35,7
Einsatz
20,4
30,6
15,3
20,4
40,2
30,6
Dokumente/ Anwendungen
50,0
50,0
50,0
50,0
25,0
25,0
PM/ QS/ Anwenderbetreuung
332,0
199,4
322,6
188,7
329,5
187,3
- davon Projekt-Mgmt. (PM)
15,00%
41,0
49,7
36,3
44,4
39,8
43,7
- davon Qualitätssicherung (QS)
15,00%
41,0
49,7
36,3
44,4
39,8
43,7
- davon Anwenderbetreuung
0,00%
0,0
0,0
0,0
0,0
0,0
0,0
- davon Anwenderbetreuung1)
absolut
250,0
100,0
250,0
100,0
250,0
100,0
Abbildung 5: Beispiel: Gesamtpersonalaufwand
3.3.3
Preisstrukturen der Anbieter
Einen weiteren wesentlichen Bereich stellen neben den Personalaufwänden die Kosten
für Soft- und Hardware dar. Hier sind i. d. R. Preisinformationen bei den Herstellen / Lieferanten einzuholen. Diese Daten sollten für unterschiedliche Finanzierungsmodelle abgefragt werden. So kann es im Einzelfall zu spürbaren Unterschieden zwischen Kauf,
Miete und Leasing kommen. Basis bilden generell die Preislisten der Anbieter. In jedem
Seite 81
Fall sind für diese Informationen jedoch evtl. vorhandene Rahmenabkommen der Behörde mit den Anbietern zu verwenden.
Da sich Migrationen in der Regel auf der Serverseite und gegebenenfalls zusätzlich auf
der Clientseite abspielen, wird die Erhebung der Preisinformationen in diese beiden Bereiche gegliedert.
3.3.3.1
Server
In diesem Bereich wird folgende Struktur empfohlen:
Server
Software
Betriebssystem
Betriebssystem
Directory
Anmeldedienst
File
Druck
DNS/ DHCP/ BOOTP
Systemmanagement
Softwareverteilung
Inventarisierung
Helpdesk
Systemüberwachung
Netzwerküberwachung
Datenbanken
DBMS (DatenbankenManagementsysteme)
Groupware & Messaging
Groupware
Mail
Terminalserver
Hardware
Tabelle 10: Erhebungsstruktur Preisinformationen Hard-/ Software - Server
Seite 82
3.3.3.2
APC
Auch auf der Seite der Arbeitsplatzrechner hat sich nachfolgende Strukturierung als hilfreich erwiesen:
Arbeitsplatzcomputer
Software
Betriebssystem
Betriebssystem
Standardsoftware
Dokumentenaustauschformat,
PDF-Betrachter/-Erstellung
Webbrowser und Mailclient
Textverarbeitung
Tabellenkalkulation
Präsentation
Komprimierung
Werkzeuge (Bildbearbeitung, etc.)
Terminalserver (Client Zugriff)
Hardware
Tabelle 11: Erhebungsstruktur Preisinformationen Hard-/ Software - Arbeitsplatzcomputer
Diese Informationen sind wiederum in der Projektmatrix abzulegen, um sie der Berechnung der Wirtschaftlichkeit zugänglich zu machen.
3.4
Nutzwert-Analyse
Gilt es bei der Entscheidungsfindung nicht monetär erfassbare Auswirkungen mit einzubeziehen, stehen für Migrationen selektierte Kriterien zur Verfügung (siehe Kapitel I.C
5.3.1, „Dringlichkeitskriterien― und Kapitel I.C 5.3.2, „Qualitativ-strategische Kriterien―).
Die Nutzwertanalyse der WiBe für Migrationen verfolgt dasselbe Prinzip wie die WiBe
4.074 und bewertet einzeln und unabhängig voneinander gewichtete Zielkriterien, um sie
anschließend zu einer Gesamtbewertung zusammenzufassen. Hier werden die sogenannten qualitativen Faktoren über Bewertungsskalen quantifiziert.
74
Bundesverwaltung, insbesondere beim Einsatz der IT, Version 4.0 – 2004, S. 80 ff.
Seite 83
Für die Ergebnisauswertung empfehlen wir in zwei Schritten vorzugehen:
1. Die Ergebnisse der monetären Wirtschaftlichkeitsbetrachtung für Migrationen haben Priorität. Hier werden Kosten und Nutzen der Maßnahmen nach der oben
aufgeführten Methodik75 in einer Rentabilitätskennzahl dargestellt.
2. Die Ergebnisse der Nutzwertanalyse für Migrationen führen zu Kennzahlen für
folgende Bereiche:
o
Dringlichkeit der IT-Maßnahme
o
qualitativ-strategische Bedeutung der IT-Maßnahme
Anmerkung: Migrationen haben grundsätzlich keine oder nur geringe unmittelbare Effekte auf Kunden der Behörde. Daher werden die Kriterien für externe Effekte der IT-Maßnahme bei Migrationen, soweit erforderlich, im Bereich der qualitativ-strategischen Kriterien behandelt.
Dieser zweite Schritt dient primär dem Fall, dass eine Wirtschaftlichkeitsbetrachtung nach monetären Gesichtspunkten grundsätzlich nicht ausreicht beziehungsweise keine eindeutige Rentabilitätsaussage liefert. Aufgrund von Dringlichkeits, Strategiekriterien kann das Projekt stets unabhängig von monetären Kriterien
eine hohe Priorität zur Durchführung erhalten.
Die Methodik der Nutzwertanalyse ist ausführlich in den Unterlagen der WiBe 4.0 beschrieben und wird aus diesen Gründen hier nicht mehr aufgeführt.
3.5
Vollkostenansatz
In der Wirtschaftlichkeitsbetrachtung ist grundsätzlich der Vollkostenansatz zu verwenden. D. h. alle unmittelbar und mittelbar monetär quantifizierbaren Kosten und Nutzen
sind der IT-Maßnahme zuzuordnen. Daraus ergibt sich die Erfordernis auch die nicht
haushaltswirksamen76 Kosten zu berücksichtigen.
3.6
Vergleichbarkeit
Um Vergleichbarkeit der verschiedenen Auswertungen zu gewährleisten, wird die Wirtschaftlichkeitsbetrachtung in zwei Szenarien durchgeführt:

die Migration einzelner oder mehrerer Migrationsobjekte77 (Teilmigration), bei klar
abgrenzbaren Produkten oder Produktgruppen78

die Gesamtmigration, d. h. Migration einer kompletten DV-Umgebung - Server,
Clients, Infrastruktur, Fachanwendungen
Für die Migration von Migrationsobjekten sowie bei einer Gesamtmigration sind die selektierten Bewertungskriterien der WiBe für Migrationen anzuwenden. Da im Falle von
75
76
77
78
siehe die Kapitel zur WiBe 4.0
Haushaltswirksame Kosten und Nutzen entstehen erst aufgrund der betrachteten Maßnahme und führen im kommenden Haushaltsplan zu Mehr- oder Minderbeantragungen.
Siehe hierzu im Kapitel Vorgehensweise die Abgrenzung der Objekte.
Desktop-Anwendungen als Migrationsobjekte mit Textverarbeitung, Tabellenkalkulation,
Grafik und Internetbrowser als Produkte.
Seite 84
Gesamtmigrationen oftmals auch die Umstellung von Fachanwendungen diskutiert wird,
sei an dieser Stelle darauf verwiesen, dass solche Vorhaben in separaten Projekten zu
realisieren sind. Dafür werden auch eigenständige Wirtschaftlichkeitsbetrachtungen erforderlich. Die darin identifizierten Ersparnisse können durchaus zu einem entsprechenden Teil der Migrationsmaßnahme zugerechnet und hier dargestellt werden.
Ein weiterer Aspekt wird dadurch hinzugefügt, dass vergleichende Wirtschaftlichkeitsanalysen nur bei technisch und funktional vergleichbaren Alternativen Sinn macht. Als
vergleichbar können folgende Einsatzbereiche erachtet werden:

Infrastruktur-Dienste
o
File-Dienste
o
Print-Dienste
o
Anmeldungs-Dienste
o
Netzwerk-Dienste

Messaging- und Groupware-Systeme

Office-Pakete

Datenbank- und Web-Anwendungsserver
3.7
Einsatzbereiche
Um ein aussagekräftiges Ergebnis zu erhalten, wird die Analyse in einem aus mehreren
Einsatzbereichen bestehenden Gesamtkontext durchgeführt. Die Gesamtbetrachtung
der zu untersuchenden Kosten umfasst dabei folgende Einsatzfelder:


Server-Infrastruktur
o
Datei-Dienste
o
Druck-Dienste
o
Anmeldedienste
o
Netzwerkdienste
Desktop-Infrastruktur
o
Office
o
Web

Messaging/Groupware

Datenbank- und Web-Anwendungen
Obwohl sicherlich nicht vollständig, bildet diese Aufzählung einen gemeinsamen Nenner
für die meisten Infrastrukturbereiche einer Behörde.
Die Migration der IT-Fachverfahren stellt unterschiedliche Anforderungen an Organisationseinheit und die Dienstleister / Lieferanten der Software.
Seite 85
Werden die IT-Fachverfahren in verschiedene Technik-Cluster gegliedert (Terminal,
Web, Dos, MS Access, Makros, Standalone), so bilden sich drei Risikoklassen für die
Migration heraus (siehe Tabelle 12):
1. Einfache Migration möglich
2. Mittlerer Schwierigkeitsgrad; Migrationsweg variabel, Emulation, Terminalserver,
Ablösung
3. Migration schwierig; in der Regel durch Hersteller
Die zu analysierenden Fachverfahren können entsprechend der Informationserhebung
und auf Basis der Migrationsmatrix beispielhaft wie folgt beurteilt werden:
Typ
Risiko
Migrationsszenario
Terminal
i.d.R. vernachlässigbar
nicht zutreffend
Web
i.d.R. browserabhängig
z. B. Standard-Konformität herstellen
DOS
Einfacher Schwierigkeitsgrad
z. B. Dos-Emulation,
Terminalserver und
Ablösung
MS Access79
Mittler bis hoher Schwierigkeitsgrad
möglich; vornehmliche Risikobereiche: hohe Anzahl, keine Dokumentation, kein Hersteller, kaum Akzeptanz
z. B.: Neuentwicklung durch Entwickler (gegebenenfalls Web, Access2WEB), Emulation (WINE), Terminalserver, Ablösung
Sonstiges (Vorlagen, Makros,
Formulare)
Alle Schwierigkeitsgrade möglich,
abhängig von Situation, vornehmliche
Risikobereiche: Anzahl und Komplexität der Makros
z. B.: Beibehaltung der OfficeAnwendungen durch Emulation, Portierung nach OpenOffice.org, Ablösung
C/S
Migration i. d. R. schwierig
Portierung durch Hersteller, Möglichkeiten: Web, Emulation,
Portierung nur durch Hersteller möglich
Terminalserver, Ablösung
Tabelle 12: Erhebungsstruktur Preisinformationen Hard-/ Software - Arbeitsplatzcomputer
4
Analyse der Ausgangssituation
Die Analyse der Ausgangssituation beschäftigt sich zum einen mit der hardwaretechnischen Infrastruktur (Server, APC, Netzwerk und Druck) und andererseits mit den vorhandenen Softwarediensten und -systemen zum Betrieb der IT-Landschaft und zur Un-
79
Hierbei sind Eigenentwicklungen (z. B. C++, etc.) als IT-Fachanwendungen zu betrachten,
die per Definition nicht in dieser Studie berücksichtigt werden, sondern als eigenständiges
Projekt abzuwickeln sind.
Seite 86
terstützung der Geschäftsprozesse. Zur Erhebung80 hat sich folgende Struktur in verschiedenen Projekten bewährt:
4.1

Infrastruktur Server

Infrastruktur APC

Infrastruktur Netz

Infrastruktur Druck

Serverdienste

Standardsoftware

Office

IT-Fachverfahren

Dokumentvorlagen
Infrastruktur Server
Die Datenerhebung für die eingesetzten Server soll Aufschluss darüber geben, ob mit
dem vorhandenen Material eine Migration bewerkstelligt werden kann, oder ob auch hier
neue Hardware benötigt wird. Folgende Informationen (siehe Abbildung 6) sind erforderlich: Dienst/Einsatz, Distribution, Version, Erstinstallation, Anzahl gesamt, Alter (< 1 Jahr,
1 – 3 Jahre, > 3 Jahre), Investitionen beziehungsweise Anschaffungs-/Leasing- und
Wartungskosten.
RZ - Infrastruktur
- Server
Name
Dienst/ Einsatz Distribution
Version Erst-Inst. Gesamt
Alter in Jahren
<1
1-3
>3
Invest/ Kosten
Anmerkungen
Summen
Abbildung 6: Beispiel Erhebungsbogen - Infrastruktur der Server
4.2
Infrastruktur APC
Niveau. Beispielsweise werden neben Rechnern mit aktuellen Systemumgebungen auch
Geräte mit einem Alter von bis zu 8 Jahren (und den entsprechend alten Systemumgebungen) eingesetzt. Da bestimmte Migrationsszenarien in diesem Bereich enorme Auswirkungen haben (z. B. muss für neue Softwareprodukte neue Hardware beschafft wer-
80
Die in den folgenden Ausführungen gezeigten Beispiele zu den verschiedenen Erhebungsbereichen können aus dem Internet herunter geladen werden. siehe www.kbst.bund.de
Seite 87
den, da diese auf älteren Systemumgebungen nicht laufen), kommt den hier zu erhebenden Informationen große Bedeutung zu.
Die vorhandenen Clients können nun in Gruppen zusammengefasst werden. In manchen Fällen wurde dies schon im Rahmen einer Inventarisierung und der Aufnahme der
Informationen in eine Anlagenbuchhaltung durchgeführt. Ist dies nicht der Fall, so können sinnvolle Gruppen für die Clients gebildet werden, die sich vornehmlich an Majoritäten der zu erhebenden Informationen (siehe Abbildung 7) ausrichten können. Diese sind
folgendermaßen strukturiert: Betriebssystem, Anzahl Arbeitsplatzcomputer (APC) im
Netz, zentrale Installation, zentrale Administration, Leistungsfähigkeit (z. B.: Alter > 5 - 8
Jahre, Prozessor < 100 MHz, Memory < 32MB; Alter > 3 - 5 Jahre, Prozessor 100-400
MHz, Memory < 64MB; Alter > 2 - 3 Jahre, Prozessor 400 - 700 MHz, Memory 64 - 128
MB; Alter bis zu 2 Jahre, Prozessor > 700 MHz, Memory > 128MB), Eingabehilfen.
RZ - Infrastruktur
- Arbeitsplatzrechner (APC [1])
Leistungsfähigkeit [2]
Erhebungsbereich [3]
BetriebsSystem
Anzahl
APCs
im Netz
8 Jahre
Alter
Prozessor < 100 MHz
Memory < 32 MB
5 Jahre
3 Jahre
2 Jahre
100 - 400 MHz
400 - 700 MHz,
> 700 MHz
< 64MB
64 - 128 MB
> 128 MB
… davon …
zentrale
zentrale
Installation
Administration
Eingabe- Anmerkungen
Hilfen
Summen
APC-Kat. 1
APC-Kat. 2
APC-Kat. 3
APC-Kat. 4
Einzelplatz-PC
[1] APC = Arbeits-Platz-Computer
[2] Die Kriterien der Leistungsfähigkeit bitte an die aktuelle Situation anpassen.
[3] Die Erhebungsgruppen (hier beispielhaft mit "APC-Kat. 1 bis 4" bezeichnet) bitte an der eigenen Situation orientieren und anpassen.
Abbildung 7: Beispiel Erhebungsbogen - Infrastruktur der Arbeitsplatz-Computer
4.3
Infrastruktur Netzwerk
Die vorhandene Netzwerkausstattung (siehe Abbildung 8) stellt die Basis für die Zusammenarbeit der APCs mit den Servern dar. Zur Definition von Migrationsszenarien
stellt dieser Bereich eine nicht zu vernachlässigende Größe dar.

Netzausstattung
o
Ethernet
o
ATM
o
Token ring

Geschwindigkeit

Router

Switches
Seite 88
RZ - Infrastruktur
- Netzwerk
Erhebungsbereich
Anzahl
Betriebseingesetzte System
Systeme
eingesetztes Hersteller Anzahl
Produkt
Lizenzen
Anzahl
Clients
Schnittstellen
zu OfficeAnwendungen
Anmerkungen
Netzwerkinfrastruktur
Netzausstattung
- Ethernet
- ATM
- Tokenring
Geschwindigkeit
Router
Switches
Abbildung 8: Beispiel Erhebungsbogen - Infrastruktur des Netzwerks
4.4
Infrastruktur Druck
Drucker ergänzen die Informationen zu der bisher erhobenen Hardware. Manche Softwareprodukte sind nicht mit allen Druckertypen kompatibel. Daher ist zur Verifizierung
möglicher Migrationsszenarien auch deren Erhebung notwendig. Folgende Daten (siehe
Abbildung 9) sind zu ermitteln: Anzahl gesamt, Alter (< 1 Jahr, 1 – 3 Jahre, > 3 Jahre),
Investitionen beziehungsweise Anschaffungs-/ Leasing- und Wartungskosten.
RZ - Infrastruktur
- Drucker
Alter in Jahren
< 1 1 - 3 > 3 Gesamt
Gesamt
Kosten
Anzahl
Erhebungsbereich
Kosten für
Kauf Leasing Wartung Anmerkungen
Summen
Netzwerkdrucker
Faxgeräte
Netzwerkarten
Grafikkarten
Beschleunigung
Scanner
Arbeitsplatzdrucker
Aufstellung der Treiber für Arbeitsplatzdrucker
Abbildung 9: Beispiel Erhebungsbogen - Drucker-Infrastruktur
4.5
Serverdienste
In diesem Bereich werden die zentralen auf Servern im Rechenzentrum verfügbaren
Dienste erhoben – z. B.:

o
Dateiablage (File-Server)
o
Druckdienste (Print-Server)
Seite 89
o
o


Netzwerkdienste

DNS

DHCP

WINS

RAS

VPN

BOOTP
Authentisierungsdienste
System und Managementdienste
o
Softwareverteilung
o
System- und Netzwerküberwachung
o
Datensicherungssysteme
Verzeichnisdienste
o
NDS
o
OpenLDAP

Messaging und Groupware

Terminalserver

Dokumentenmanagementsysteme
Die Erhebung wird in folgende Bestandteile (siehe Abbildung 10) gegliedert: Anzahl eingesetzte Systeme, Betriebssystem, eingesetztes Produkt, Hersteller, Anzahl Lizenzen,
Anzahl Clients, Schnittstellen zu Office-Anwendungen.
Seite 90
RZ - Infrastruktur
- Zentrale Serverdienste
Erhebungsbereich [1]
Anzahl
Betriebs- eingesetztes
eingesetzte System
Produkt
Systeme
Hersteller
Anzahl Anzahl
Lizenzen Clients
Schnittstellen Anmerkungen
zu OfficeAnwendungen
Dateiablage (File-Server)
Druckdienste (Print-Server)
Netzwerkdienste
- DNS
- DHCP
- WINS
- RAS
- VPN
- BOOTP
…
Authentisierungsdienste
System- und Managementdienste
Softwareverteilung
System- und Netzwerküberwachung
Datensicherungssysteme
Verzeichnisdienste
NDS
OpenLDAP
Messaging & Groupware
eGroupware
Terminalserver
Dokumentenmanagementsysteme
[1] Die Erhebungsgruppen bitte an der eigenen Situation orientieren und anpassen.
Abbildung 10: Beispiel Erhebungsbogen - Erhebungsbogen für Serverinfrastrukturdienste
4.6
Standardsoftware
Standardsoftware stellt häufig einen erheblichen Anteil an den Softwarelizenzen dar. Die
eingesetzten beziehungsweise lizenzierten Produkte werden in folgender Strukturierung
(siehe Abbildung 11) erhoben: Hersteller, Verwendungszweck, Lizenzen (Anzahl heute,
künftig benötigt), Kosten heute und künftig (Lizenzen und Wartung).
Standard-Software
Name
Version
Hersteller
Verwend.Zweck
Lizenzen
Kosten heute
Anz.heute künftig Lizenzen Insurance
Kosten künftig
Lizenzen Insurance Anmerkungen
Acrobat Reader
Mozilla
Open Office
Outlook
WinZip
Access
Excel
Powerpoint
Word
Abbildung 11: Beispiel Erhebungsbogen - Standardsoftware
4.7
Dokumentvorlagen und Makros
Ein wesentlicher Faktor für die Migrationsaufwände stellen die umzustellenden Dokumentvorlagen (z. B. in der Textverarbeitung, der Tabellenkalkulation, etc.) und Makros
dar. Hier baut die Praxis bei der Erhebung oftmals recht große Hürden auf – in vielen
Fällen existieren keine Übersichten über diese Dokumente. Dies betrifft neben den serSeite 91
verbasierten Dateien vor allem die, die auf den Arbeitsplatzrechnern der Anwender liegen.
In Abhängigkeit der Güte und Akzeptanz eventuell vorhandener Standard-Verfahren für
Prozessunterstützung nutzen die Anwender diese oder haben sich auf ihren Rechnern
eigene Makro-Anwendungen (je nach Programmierkenntnissen) erstellt.
Soll die Migration für die gesamte Behörde zu einem Erfolg werden und vor allen Dingen
von den Anwendern vor Ort akzeptiert werden, so ist es unerlässlich, diesen Bereich „in
den Griff― zu bekommen. Das bedeutet, dass ernsthafte Versuche unternommen werden
sollten, die Dokumentvorlagen und Makros zu erheben und in nachfolgend vorgeschlagene Klassifizierung (siehe Tabelle 13) einzuordnen.
Dokumente
Klassifizierung
Dokumentvorlagen
geringe Komplexität, Erstellung < 0,5 Tage
mittlere Komplexität, Erstellung 0,5-2 Tage
hohe Komplexität, Erstellung 2-4 Tage
sehr hohe Komplexität, Erstellung > 4 Tage
Makros
geringe Komplexität, Erstellung < 0,5 Tage
mittlere Komplexität, Erstellung 0,5-2 Tage
hohe Komplexität, Erstellung 2-4 Tage
sehr hohe Komplexität, Erstellung > 4 Tage
Tabelle 13: Klassifizierung von Dokumentvorlagen und Makros
Office
- Dokumentvorlagen und Makros
Erhebungsbereich
Programm
Verzeichnis
Anzahl
Su
Tage
Dokumentvorlagen
Komplexität der Erstellung
gering
mittel
hoch sehr hoch
Makroanwendungen
Komplexität der Erstellung
gering
mittel
hoch sehr hoch
< 0,5
< 0,5
0,5 - 2
2-4
>4
0,5 - 2
2-4
Word
Excel
PowerPoint
Access
. . Sonstige . .
Unverzichtbare, produktive …
Abbildung 12: Beispiel Erhebungsbogen - Office
Seite 92
>4
Anmerkungen
4.8
IT-Fachverfahren
Für die Fachverfahren treffen die gleichen Einschätzungen zu, wie für die Dokumentvorlagen und Makros. Diese Verfahren sollen die tägliche Arbeit der Anwender unterstützen. Bietet die Migration die Chance, diese in manchen Punkten zu verbessern (wenn
zum Beispiel neu oder umprogrammiert werden muss), so wird sich automatisch eine
Akzeptanz der Anwender einstellen. Andernfalls muss nach der Migration mindestens
der vorhandene Standard wieder hergestellt werden. Die Fachverfahren sollten in folgenden Informationsclustern aufgenommen werden:
Architektur
Nutzer
Client-/ Serverbetriebssysteme
Datenbanksysteme
Applikationsserver
Benutzerverwaltung
Rechteverwaltung
Schnittstellen
Hosting
Verfahrensentwicklung
Ausprägung
Ausblick
Kosten
Anmerkungen
Tabelle 14: Informationscluster für die Erhebung der IT-Fachverfahren
Für die Fachverfahren treffen die gleichen Einschätzungen wie für die Dokumentvorlagen und Makros zu. Diese Verfahren sollen die tägliche Arbeit der Anwender unterstützen. Bietet die Migration die Chance, diese in manchen Punkten zu verbessern (wenn
z. B. neu oder umprogrammiert werden muss), so wird sich automatisch eine Akzeptanz
der Anwender einstellen. Andernfalls muss nach der Migration mindestens der vorhandene Standard wieder hergestellt werden. Die Fachverfahren sollten in folgenden Informationsclustern aufgenommen werden:

Architektur und Nutzer

Client-/ Serverbetriebs-, Datenbanksysteme und Applikationsserver

Benutzer-/ Rechteverwaltung und Schnittstellen

Hosting, Verfahrensentwicklung und Ausprägung

Ausblick, Kosten und Anmerkungen
4.8.1
Architektur und Nutzer
Bei der Architektur sollte nach einschichtig und 2 bis n-schichtig unterschieden werden.
Als Erhebungskriterien bei einer 2- und mehrschichtigen Architektur kommen in Frage:
Client/Sever, Terminal, Host und Web.
Die Erhebung der Nutzer je IT-Fachanwendung liefert Informationen zur Verbreitung der
Anwendung. Die Anzahl der Nutzer bezogen auf deren Gesamtheit hilft, die Anwendungen zu priorisieren. An dieser Stelle sind auch wieder die Ziele und die Rahmenbedingungen zu berücksichtigen. Es kann durchaus sein, dass Anwendungen, die nur von
sehr wenigen Mitarbeitern genutzt werden, trotzdem einen hohen strategischen Wert
Seite 93
haben und somit automatisch zu priorisieren sind. Im Erhebungsbereich der Nutzer sollten Angaben erfragt werden, zum Einsatzbereich der Anwendung in der Behörde, zu der
Gesamtzahl der Nutzer je Anwendung, zu Anzahl der Nutzer in den einzelnen Abteilungen und ob die Anwendung abteilungsübergreifend im Einsatz ist. (siehe Abbildung 13)
IT-Fachverfahren1
- Architektur und Nutzer
Bezeichnung
Architektur
Produkt1
2-/ n-schichtig
GesamtName
Schicht C/S Term. Host Web Anzahl
Summen
Einsatz in
Abteilung
1
2
3
4
5
6
Nutzer
Abteilungen
7 8 9 10 11 12 13 14 15
1
2
3
Fachbereiche
4 5 6 7
8
9
10
Abbildung 13: Beispiel Erhebungsbogen - IT-Fachverfahren – Architektur und Nutzer
4.8.2
Client-/ Serverbetriebssysteme, Datenbanksysteme und
Applikationsserver
An dieser Stelle sollen die Betriebssysteme, Datenbanken und Applikationsserver erhoben und ermittelt werden sowie unter welchem Betriebssystem/Produkt/Version das jeweilige IT-Verfahren laufen kann beziehungsweise im Hause eingesetzt wird.
Hierfür bietet sich die Gliederung in folgende zurzeit verbreitete Betriebssysteme (siehe
Abbildung 14) an: Windows NT, Windows 2000/ 2003/ XP, Linux und Unix.
IT-Fachverfahren21
- Client-/Serverbetriebssysteme
Bezeichnung
ProduktName
Client-Betriebssystem(e)
eingesetzt
verfügbar
Windows Linux Unix Windows Linux Unix
NT
XP
NT
XP
Server-Betriebssystem(e)
eingesetzt
verfügbar
Windows Linux Unix Netware Windows Linux Unix Netware
NT
XP
NT
XP
Summen
Abbildung 14: Beispiel Erhebungsbogen - IT-Fachverfahren – Client-/Serverbetriebssysteme
Seite 94
IT-Fachverfahren22
- Datenbanksysteme, Applikationsserver
Bezeichnung
ProduktName
Datenbanksysteme
eingesetzt
verfügbar
NT XP
NT
XP
Applikationsserver
eingesetzt
verfügbar
NT
XP
NT
XP
Summen
Abbildung 15: Beispiel Erhebungsbogen - IT-Fachverfahren – Datenbanksysteme und
Applikationsserver
4.8.3
Benutzer-/ Rechteverwaltung und Schnittstellen
Für die Benutzer- und Rechteverwaltung (siehe Abbildung 16) soll ermittelt werden, ob
sie innerhalb der Anwendung einen Verzeichnisdienst oder Sonstige besitzt.
Schnittstellen können existieren zu: anderen IT-Verfahren, Standard-Software, Dokumentvorlagen und Makros. Bei Letzteren stellt sich die Frage nach der Komplexität der
Applikation, siehe daher Tabelle 13.
IT-Fachverfahren3
- Client-/Serverbetriebssysteme, Datenbanksysteme, Applikationsserver
Bezeichnung
ProduktName
Verwaltung
Schnittstellen
zu anderen
zu Stand.
zu Dokumentvorlagen
zu Makros
Benutzer
Rechte
innerhalb
über
sonstiges innerhalb
über
sonstiges IT-Verfahren, Software, Komplex- gering mittel hoch sehr gering mittel hoch
der
Verzeichn.der
Verzeichn.Name de
Name de
ität
hoch
Anwendg. Dienst
Anwendg. Dienst
Verfahrens Verfahrens Erstellgs.- < 0,5 0,5 - 2 2-4
> 4 < 0,5 0,5 - 2 2-4
Dauer [1]
sehr
hoch
>4
Summen
[1] Erstellungsdauer in Tagen
Abbildung 16: Beispiel Erhebungsbogen - IT-Fachverfahren – Benutzer-/Rechteverwaltung und
Schnittstellen
Seite 95
4.8.4
Hosting, Verfahrensentwicklung und Ausprägung
Für nicht eigene IT-Verfahren ist es wichtig die Verfahrensverantwortung und die Verfahrensbetreiber (Hosting durch externe Firma, externe(r) Abteilung/ Bereich, eigene ITAbteilung) zu kennen.
Die Verfahrensentwicklung (siehe Abbildung 17) soll Aufschluss über den Kostenrahmen
des Verfahrens geben. Hier stellen sich folgende Fragen: Handelt es sich um eine Eigen- oder Fremdentwicklung, wie hoch gestaltete sich der Aufwand der Entwicklung in
internen und externen Personentagen und den entsprechenden Kosten, wie heißt das
Produkt (Name und Version) und durch wen (Firma, Abteilung) kann Support geliefert
werden?
Für eine eventuelle Neuprogrammierung im Rahmen der Migration sind folgende Ausprägungsinformationen von Bedeutung: Komplexität, Anforderungen an die Verfügbarkeit und Betreuungsaufwand (jeweils in den Stufen hoch mittel gering).
IT-Fachverfahren4
- Verantwortung, Entwicklung, Hosting, Ausprägung
Bezeichnung
ProduktName
Verfahrens
Verantwortung
Hosting
Verfahrens-Entwicklung
Ausprägungen
VerfahrensArt
Aufwand
Entwicklg.-Umgebng
Komplexität
Anforderung
BetreuungsBetreiber
[1] Kosten Tage Tage Produkt Support
Verfügbarkeit
Aufwand
A B C selbst
Version
durch: Hoch Mittel Gering Hoch Mittel Gering Hoch Mittel Gering
intern extern
Summen
[1] e = eigen, f = fremd
Abbildung 17: Beispiel Erhebungsbogen - IT-Fachverfahren – Hosting, Verfahrens-Entwicklung
und Ausprägung
4.8.5
Ausblick, Kosten und Anmerkungen
Mit dem Ausblick (siehe Abbildung 18) sollen Informationen zur Zukunft des Verfahrens
erhoben werden (bspw. Einstellung, Fortschreibung oder Ablösung durch ein anderes
Produkt). Bei Verfahren, die zurzeit noch nicht unter Linux verfügbar sind, wird die geplante Linux-Verfügbarkeit abgefragt. Auch die Plattformunabhängigkeit und seit Neuestem auch die SAGA-Konformität stellen in diesem Zusammenhang wichtige Kriterien dar.
Im Bereich der Kosten wird der jährliche Aufwand für folgende Kostenarten erhoben:
interne und externe Betreuung, Lizenzen (aus internen Umlagen und/oder externen Lizenzen), Miete, Wartung, Schulung, Sonstiges.
Seite 96
IT-Fachverfahren5
- Ausblick, Kosten, Anmerkungen
Bezeichnung
Produkt- KurzName Beschreibung
Fort- Ablöschrei- sung
bung
Ausblick
Kosten
Ein- Linux Platt- Gesamt
Betreuung
Lizenzen
stel- Ver- form- Kosten Intern
Extern
interne externe
lung füg- Unabin Euro in Euro Umlagen Lizenzen
bar- hängig/Jahr
/Jahr
keit
keit
Anmerkungen
Miete
Wartung Schulung Sonstiges
Summen
Abbildung 18: Beispiel Erhebungsbogen - IT-Fachverfahren – Ausblick, Kosten und Anmerkungen
5
Wirtschaftlichkeit nach WiBe
5.1
Vorbemerkung
5.1.1
Aufbau und Vorgehensweise der WiBe für Migrationen
5.1.1.1
Aufbau der WiBe für Migrationen
Die im Rahmen dieses Dokumentes dargestellte Wirtschaftlichkeitsbetrachtung basiert
auf der von der KBSt herausgegebenen Methodik zur Ermittlung der Wirtschaftlichkeit
von Migrationsmaßnahmen.
Grundlage der vorliegenden WiBe für Migrationsmaßnahmen waren die Bewertungsmethoden und -kriterien der WiBe 4.081 sowie des IT-Updates82 der KBSt, die inhaltlich und
methodisch an die spezifischen Gegebenheiten und Besonderheiten von Migrationsmaßnahmen angepasst beziehungsweise weiterentwickelt wurden83.
Die grundlegende Struktur der WiBe wurde dabei beibehalten. Neben der Bewertung der
monetären Wirtschaftlichkeit erfolgt die Ermittlung der erweiterten Wirtschaftlichkeit. Die
monetäre Wirtschaftlichkeit setzt sich zusammen aus der Bewertung der

Entwicklungskosten/ Einführungskosten und –nutzen

Betriebskosten und Betriebsnutzen.
Bei den Kriterien der erweiterten Wirtschaftlichkeit wurde (gegenüber der Systematik der
WiBe 4.0) auf die Kriteriengruppe „Ermittlung der externen Effekte― verzichtet, da diese
bei Migrationsmaßnahmen keine beziehungsweise nur eine unwesentliche Rolle spielt.
Daher beinhaltet die erweiterte Wirtschaftlichkeit eine qualitative Bewertung der
81
82
83
Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der Bundesverwaltung, insbesondere beim Einsatz der IT, WiBe 4.0, August 2004.
Hinweisen und Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen bei
IT-Update- beziehungsweise Umstellungsvorhaben auf Grundlage der IT-WiBe-97, November 2000.
Eine Übersicht der modifizierten Kriterien zeigen die Abbildungen 25 bis 30 im Anhang.
Seite 97

Dringlichkeit der Migrationsmaßnahmen sowie

qualitativ-strategischen Kriterien.
5.1.1.2
Fragenkataloge nach dem Ist- und Soll-Zustand im Vorfeld der WiBe
Neu zur bisher bekannten WiBe-Systematik wurden der WiBe für Migrationen zwei Fragenkataloge vorangestellt, die im Vorfeld der eigentlichen WiBe-Durchführung zur Klärung spezifischer Migrationsfragestellungen beitragen sollen.
Zum einen wurde ein Katalog an Fragestellungen zur qualitativen Beurteilung des IstZustandes konzipiert, mit dessen Hilfe der konkrete Handlungsbedarf für ein
Migrationsvorhaben beziehungsweise -projekt festgestellt werden kann. Zum anderen
wurde ein Fragenkatalog erstellt, in dessen Mittelpunkt die qualitative Beurteilung des
Soll-Zustandes steht. Mit dem zweiten Fragenkatalog können mögliche Migrationsalternativen dahin gehend überprüft werden, ob diese grundsätzlich weiter verfolgt werden
sollen. Beide Fragenkataloge stellen im Vorfeld der eigentlichen WiBe-Durchführung
eine Orientierungs- und Beurteilungshilfe für Migrationsalternativen und -szenarien dar.
5.1.1.3
Vorgehensweise im Rahmen der monetären und nicht monetären WiBe
Ergibt sich aus der qualitativen Beantwortung des Fragenkataloges nach dem IstZustand ein konkreter Handlungsbedarf bezüglich der Durchführung eines Migrationsprojektes, ist die Wirtschaftlichkeit des Projektes innerhalb der Planungsphase durch die
nachfolgenden monetären und nichtmonetären Wirtschaftlichkeitskriterien zu beurteilen.
Hierbei ist zu beachten:
84

Der Betrachtungszeitraum der WiBe soll sich auf die Umsetzungszeit des Projektes und einen entsprechend nachgelagerten Zeitraum der Nutzung beziehen.
Damit kann der Betrachtungszeitraum von der in den bisherigen Versionen der
WiBe enthaltenen Vorgabe von 5 Jahren abweichen, da für strategische Migrationsmaßnahmen längere Zeiträume als 5 Jahre begründbar sind / sein können.
Die in den bisherigen Fachkonzepten enthaltene Aussage zur Nutzungsdauer
(Betriebsnutzen) von 5 Jahren ist keine absolute Vorgabe, sondern eine Richtgröße. Abweichungen sind mit Begründung zulässig 84.

Absehbare Änderungen in der Technik oder in den Prozessen und hiermit verbundene Nutzenpotenziale sind in gesonderten Alternativen zu bewerten. D. h.
ergeben sich für eine Migration mehrere technische Lösungen, so soll deren wirtschaftliche Betrachtung in separaten Alternativen erfolgen. Da unterschiedliche
technische Lösungen auch differente Auswirkungen auf die Prozesse haben
können, werden sich in der Regel in den jeweiligen Alternativen unterschiedliche
Nutzenpotenziale ergeben.
Bei großen IT-Maßnahmen mit mehrjähriger Entwicklungszeit kann es zweckmäßig sein,
den 5-Jahres-Zeitraum um diese Entwicklungsdauer zu erhöhen. Bei Infrastrukturprojekten
(beispielsweise der Verkabelung von Gebäuden) kann es sinnvoll sein, auch über diesen
Zeitraum hinauszugehen. Bei IT-Maßnahmen dagegen, deren Einsatzdauer bereits jetzt
absehbar und begründet unter 5 Jahren liegen wird, ist ein kürzerer Zeithorizont für die ITWiBe zwingend erforderlich.
Seite 98

Technische Änderungen beziehungsweise neue Features sind u. U. als „nice to
have― – Funktionalitäten zu beurteilen. Im Rahmen der Migration ist deshalb die
Frage zu stellen, welche Funktionalitäten wirklich für die jeweilige Aufgabenerledigung benötigt werden.

Prozessoptimierungen werden nicht Gegenstand einer Wirtschaftlichkeitsbetrachtung für Migrationsmaßnahmen. Verbindet der Anwender mit der Migration eine
komplette Prozessbetrachtung, beziehungsweise wird diese notwendig, ist diese
in einer gesonderten Maßnahme durchzuführen.

Demzufolge ist eine Abstimmung über jene Nutzenpotenziale erforderlich, die in
die WiBe einbezogen werden sollen. Nutzenpotenziale können von den Komponenten (Personal, Dienstleistungen, Hardware, Software, etc.) abgeleitet werden.
Prozessoptimierungen werden im Rahmen von Migrationsmaßnahmen grundsätzlich nicht betrachtet. Dies können zusätzliche Effekte aus anderen Maßnahmen sein.
Im Rahmen der monetären Bewertung kommen Haushaltsinformationen zum Tragen,
d. h. Aufwendungen und Erträge beziehungsweise Ersparnisse, die zu einem Projektnutzen saldiert werden. Auf dessen Basis wird letztlich ein Kapitalwert errechnet. Ist der
Kapitalwert positiv (d. h. die Ersparnisse (oder Erträge) sind größer als die Aufwendungen), ergibt sich daraus eine Empfehlung für die Durchführung der Migrationsmaßnahme85. Zur Risikoabsicherung der künftigen Planwerte beinhaltet die WiBe für Migrationsmaßnahmen die Möglichkeit Risikofaktoren für die einzelnen Kriterien zu benennen,
die den Kapitalwert letztendlich reduzieren.
Bei einer Kostenbetrachtung im Hinblick auf die Einführung neuer Technologien muss
grundsätzlich zwischen der Neueinführung und der Migration von Verfahren und Systemen unterschieden werden. Dabei gilt als „Daumenregel―, dass eine Neueinführung
grundsätzlich einfacher und preiswerter zu bewerkstelligen ist, als eine Migration, bei der
verschiedene, zum Teil historisch gewachsene Architekturen abgelöst und Daten migriert werden müssen, ohne dass es zu einer wesentlichen Betriebsstörung oder zum
Datenverlust der Altanwendung kommt.
Da ein Migrationsverfahren grundsätzlich von seiner Ausgangssituation abhängt, erweist
sich eine allgemeingültige und allumfassende Aussage zu dessen Kosten als kaum möglich. Während eine Migration in einigen Fällen als problemlos und nahezu ohne Aufwand
möglich ist, führt die Existenz von selbst entwickelten Anwendungen, die ebenfalls abgelöst werden müssen, Überführung von Altdaten, spezielle Nutzer- und Zugriffsrechtestrukturen oder andere Besonderheiten zu einem erheblichen Projektaufwand, der behördenspezifisch – auch unter Berücksichtigung der Kritikalität - beurteilt werden muss.
Lässt sich im monetären Bereich keine Wirtschaftlichkeit darstellen (Aufwendungen sind
größer als die Ersparnisse), so verfügt die WiBe für Migrationen über die zwei ergänzenden Bereiche der erweiterten Wirtschaftlichkeit (Dringlichkeitskriterien, qualitativstrategische Kriterien). Die entsprechenden Kriterien werden in Form von Nutzwertanalysen bearbeitet, die für jeden der zwei Bereiche einen Punktwert zwischen 0 und 100
85
Bundesverwaltung, insbesondere beim Einsatz der IT, Version 4.0 – 2004, S. 71 ff..
Seite 99
als Ergebnis liefern. Im Fall eines negativen Kapitalwertes des Migrationsvorhabens
kann mit einem hohen Punktwert die Durchführung der IT-Maßnahme befürwortet werden86.
5.1.2
Fragenkatalog Ist-Zustand
Anhand der nachfolgenden beispielhaften Fragen (aa bis ag) sollte geprüft werden, ob
ein konkreter Handlungsbedarf für ein Migrationsprojekt besteht.
Die Antworten zu den einzelnen Fragen sind grundsätzlich (im Vorfeld der eigentlichen
WiBe) in schriftlicher Form zu erläutern und geeignet zu dokumentieren.
Mögliche Ergebnisse der Fragenbearbeitung zur Ist-Situation sind:

Die Migration kann realisiert werden. Erfordernis: Eine WiBe ist zu erstellen, um
eine detaillierte Entscheidung zu treffen.

Eine Migration ist nicht notwendig und somit wird auch keine WiBe benötigt.
Die Fragen im Einzelnen:
aa) Unterstützungs-Kontinuität Altsystem

Gibt es noch Unterstützung für das Altsystem?
(Hersteller, alternative Anbieter, Hardware, eigenes Personal)
ab) Stabilität Altsystem - Fehler und Ausfälle („downtime“)

Häufen sich die Fehler und Ausfälle?

Führen diese zu merkbaren Beeinträchtigungen der Arbeitserledigung?

Wird die Arbeitserledigung gegebenenfalls soweit beeinflusst, dass Arbeitsergebnisse und Fristen nicht oder nur erschwert eingehalten werden können?

Liegen Fehler und Ausfälle gegebenenfalls über den in den Service Level Agreements vereinbarten Toleranzwerten?
(Bitte beachten Sie bei Ihrer Erläuterung insbesondere die Häufigkeiten und Ursachen).
ac) Stabilität Altsystem - Wartungsprobleme, Personalengpässe

Führt der Betrieb des Altsystems gegenwärtig beziehungsweise kurz- bis mittelfristig absehbar zu erhöhten Wartungsleistungen beziehungsweise sind gravierende Wartungsprobleme zu erwarten?

Sind damit Personalengpässe verbunden (z. B. hinsichtlich Qualifikation des Personals, rechtliche Gegebenheiten)?
ad) Flexibilität Altsystem - Ausbau-/Erweiterungsgrenzen

86
Sind notwendige Ausbau- und/oder Erweiterungen nicht möglich?
Bundesverwaltung, insbesondere beim Einsatz der IT, Version 4.0 – 2004, „Berechnung
der erweiterten Wirtschaftlichkeit", S. 80 ff..
Seite 100
ae) Flexibilität Altsystem
tuell/zukünftig

-
Interoperabilität,
Schnittstellenprobleme
ak-
Sind notwendige Schnittstellen nicht verfügbar?
af) Flexibilität Altsystem - Bedienbarkeit und Ergonomie (Benutzerfreundlichkeit)

Gibt es erhebliche Mängel in der Bedienbarkeit und Ergonomie, die den Nutzer
wesentlich behindern?
ag) Erfüllung Datenschutz/ -sicherheit

5.1.3
Gibt es Sicherheitsmängel, die zu einer Beeinträchtigung im Betrieb führen?
Anforderungen Soll-Zustand
Anhand der nachfolgenden beispielhaften Fragen (ba bis bj) sollten mögliche Migrationsalternativen geprüft werden, um zu beurteilen, ob die entsprechenden Alternativen
weiter verfolgt werden sollen.
Die Antworten zu den einzelnen Fragen sind grundsätzlich (im Vorfeld der eigentlichen
WiBe) in schriftlicher Form zu erläutern und geeignet zu dokumentieren.
Mögliche Ergebnisse der Fragenbearbeitung zur Sollsituation sind:

Es gibt unterschiedliche realistische Migrationsalternativen, die auf die spezifische Situation passen.
Erfordernis: Für jede Alternative ist eine WiBe ist zu erstellen und in einer Vergleichsrechnung eine Priorisierung vorzunehmen.

Es gibt nur eine realistische Migrationsalternative, die auf die spezifische Situation passt.
Erfordernis: Hierfür ist eine zusätzliche Beschreibung erforderlich, die die Frage
beantwortet, warum es keine andere Alternative gibt. Für diese eine Alternative
ist eine WiBe zu erstellen.
Die Fragen für das Soll-System im Einzelnen:
ba) Verbreitung/ Verfügbarkeit der Ausbildung

Hat das eigene Personal ausreichend Kenntnisse?

Ist ausgebildetes Personal am Markt verfügbar?

Sind qualifizierte Ausbildungsgänge und Fortbildungen am Markt verfügbar?
Erläuterung: Sind Qualifizierungs- oder Rekrutierungsmaßnahmen notwendig, ergeben
sich hieraus Kosten, die im monetären Teil der WiBe KN zu berücksichtigen sind.
bb) Marktdurchdringung

Wie ist die Marktdurchdringung der Software?

Und welche Schlussfolgerungen können daraus gezogen werden?
Erläuterung: Hier wird der Marktanteil betrachtet, den die einzusetzende Software am
Markt hat. Bei schwindender oder nicht mehr wahrzunehmender Marktdurchdringung
besteht die Gefahr, dass die Software beziehungsweise deren Weiterentwicklung einSeite 101
gestellt wird. Darüber hinaus zeugt eine gute Marktdurchdringung von hoher Akzeptanz
beziehungsweise intensiver Nutzung der Software bei den Anwendern, woraus sich der
Umkehrschluss auf den weiteren Bestand der Software ableiten lässt.
Bei einer ausreichenden Marktdurchdringung der/des Produkte/Produkts ist im Allgemeinen eine ausreichende Investitionssicherheit anzunehmen.
bc) Software-Zertifizierung

Wird eine Zertifizierung benötigt?

Wenn ja, ist eine Zertifizierung der Software vorhanden?
Erläuterung: Mit dieser Frage soll überprüft werden, ob die einzusetzende Software gesetzlichen beziehungsweise behörden-/ branchenspezifischen Anforderungen genügt,
oder aber diese selbst organisiert werden müssen. In ersterem Fall sorgt der Hersteller/
Lieferant der Software für die Zertifizierung, sodass keine eigenen Kosten anfallen. In
letzterem Fall muss selbst für die laufende Zertifizierung gesorgt werden, um übliche
Abdeckung der Geschäftsprozesse zu gewährleisten. In diesem Fall entstehen eigene
Kosten, die nicht pauschal kalkulierbar sind.
bd) Systemmanagement-Tools

Sind Systemmanagement-Tools (bspw. Admin-Tools) für die Software verfügbar?
Werden diese benötigt?
Erläuterung: Die Administration der einzusetzenden Softwareprodukte erweist sich in
manchen Fällen unkomfortabel bis schwierig. Hier stehen Tools im Mittelpunkt, die die
Verwaltung der Tabellen und Stammdaten übernehmen oder diese unterstützen.
Mit entsprechenden Tools für das Systemmanagement können Volumen und Qualität
gesteigert und der Ressourceneinsatz optimiert werden. Andernfalls müssen Sie die
erhöhten Kosten für Fachpersonal in der WiBe KN berücksichtigen.
be) IT-Sicherheit

Welches Sicherheitsniveau gemäß den IT-Grundschutz-Katalogen87 wird benötigt?
Erläuterung: Es ist zu prüfen, ob die betreffende Migrationsalternative die entsprechenden Sicherheitsanforderungen erfüllt, z. B. in Bezug auf die Kommunikationssicherheit,
Applikationssicherheit und Ausfallsicherheit.
bf) Software Ergonomie

Existieren im Rahmen der Software-Ergonomie z. B. grafische Bedienoberflächen, verständliche Fehlerdialoge, deutschsprachige Menüführung?
Erläuterung: Bei der Beantwortung dieser Fragestellung ist der konkrete Nutzerkreis zu
beachten.
87
Siehe IT-Grundschutz-Kataloge des Bundesamtes für Sicherheit und Informationstechnik
(BSI), http://www.bsi.de/gshb/deutsch/index.htm, Stand 2006 (8. Ergänzungslieferung).
Seite 102
bg) Skalierbarkeit

Gibt es Anforderungen an die Skalierbarkeit der Software, z. B. hinsichtlich der
Anzahl der Nutzer?
bh) Flexibilität

Ausbau auf notwendige beziehungsweise zu erwartende fachliche und technische Anforderungen, z. B. Mobile-Computing?
bi) Schnittstellen

Sind notwendige oder zu erwartende Schnittstellen verfügbar?
bj) Dokumentation

5.2
Sind in ausreichender Form Dokumentationen und Handbücher verfügbar?
Monetäre Wirtschaftlichkeit
5.2.1
Systematik
In der Bundesverwaltung richten sich Wirtschaftlichkeitsbetrachtungen nach den Vorschriften des § 7 BHO und nach den hierzu erlassenen Verwaltungsvorschriften, die vor
allem betriebswirtschaftliche Verfahren berücksichtigen (siehe auch Kapitel I.C 3,
„Methodische Grundsätze―). Um diese Vorschriften auf die speziellen Erfordernisse der
Informationstechnik anzupassen, hat die Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt) bereits in 1992
eine Handlungsanweisung mit dem Titel „Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen beim Einsatz der IT in der Bundesverwaltung (IT-WiBe)― erarbeitet. 2004 ist sie in einer völlig überarbeiteten Fassung erschienen. Im Wesentlichen beinhaltet die WiBe drei Schritte:

Einflussgrößen festlegen (Kriterien selektieren)

Daten erheben/ bewerten

Kennzahlen ermitteln
Seite 103
Schritt 2
Daten
erheben
Risiken
schätzen
Schritt 3
Wirtschaftlichkeit berechnen1)
KN
Wirtschaftlichkeit berechnen1)
KN/R
Kosten/ Nutzen/
Risko
Kosten/ Nutzen
Einfluss-
monetär
Schritt 1
festlegen
 Abgestimmte
Kriterien
Kriterien bewerten
Dringlichkeit ermitteln2) D
Kriterien bewerten
Qualitativ/ strategische .
Bedeutung ermitteln2) Q
 Konsistentes
Datengerüst
nicht-monetär
größen
 Kennzahlen
1) Kapitalwertmethode, 2) Nutzwertanalyse
Abbildung 19: Methodik WiBe Migrationen
5.2.1.1
Spezifischer Kriterienkatalog für Migrationen
Der spezifische Kriterienkatalog für Migrationen stellt das Grundschema für die WiBe für
Migrationen dar. Er enthält alle Kriterien, die bei einer WiBe dieser Kategorie zu berücksichtigen sind. Mithilfe des Kriterienkataloges erfassen Sie die Wirkungen Ihrer Maßnahme.
Die Maßnahme wird monetär quantifizierbare Kosten und Nutzen haben (1. Wirkungsdimension; Wirtschaftlichkeit im monetären Sinn), es kann in unterschiedlichem Maß
Dringlichkeit (2. Wirkungsdimension) und qualitativ-strategische Bedeutung (3. Wirkungsdimension) aufweisen.
5.2.1.2
Wirtschaftlichkeit im monetären und im weiteren Sinn
Monetär quantifizierbare Kosten und Nutzen (WiBe KN) bilden die Wirtschaftlichkeit im
monetären Sinne.
Die Dringlichkeit (WiBe D) und die qualitativ-strategische Bedeutung (WiBe Q) der Maßnahme fließen in die erweiterte Wirtschaftlichkeit ein.
Bei der Zusammenstellung der Kosten und Nutzen in der WiBe KN wird die Kapitalwertmethode zugrunde gelegt, um den zeitlichen Verlauf von Kosten und Nutzen angemessen zu berücksichtigen.
Die Berechnung von Dringlichkeit und qualitativ-strategischer Bedeutung in der WiBe D
und Q bedienen sich der Nutzwertanalyse, einem Standardverfahren zur Bewertung
qualitativer Faktoren.
Mit diesem kurzen Überblick sind die Bausteine der WiBe aufgelistet. Das Verfahren
selbst ist im Weiteren detailliert in seinen einzelnen Stufen dargelegt und mit Hinweisen
zur Anwendung und Umsetzung versehen.
Seite 104
Einen Gesamtüberblick der monetären Kriterien sowie die Zuordnung der Kosten/ Nutzen zu den Bereichen „haushaltswirksam― und „nicht haushaltswirksam― liefern die Tabellen im Anhang.
5.2.2
Kriterien der monetären Wirtschaftlichkeit
Kriteriengruppe 1
Entwicklungskosten/Einführungskosten und –nutzen
In der Gruppe 1 des Kriterienkataloges sind die Entwicklungskosten und Entwicklungsnutzen aufgeführt, die vor der Einführung einer IT-Maßnahme anfallen werden; den eigentlichen Entwicklungskosten (Kriteriengruppe 1.1) stehen unter Umständen monetäre
Nutzen aus der Ablösung des alten, bisherigen Verfahrens gegenüber (Kriteriengruppe
1.2).
 Es ist unbedingt darauf zu achten, alle monetären Angaben aufzuteilen in den haushaltswirksamen und in den nicht haushaltswirksamen Anteil.
Für alle monetären Einzelkriterien gilt generell:

Soweit Wirkungen bei einem Kriterium nicht hinreichend exakt bezifferbar sind,
wirkt sich dieses Kriterium sowohl in der WiBe KN als auch in der ergänzenden
Kennzahl WiBe KN/R aus.
Bei der Datenermittlung ist ein "plausibel begründeter" Ansatz vorzulegen, der als
„wahrscheinlicher Schätzwert― in die monetäre Wirtschaftlichkeitsbetrachtung
(WiBe KN) übernommen wird. Die im ungünstigen Fall möglichen Überschreitungen dieses Schätzwertes sind als Risikozuschlag für die Risikoabwägung (WiBe
KN/R) einzugeben.

Soweit Wirkungen bei einem monetären Nutzenkriterium (Einsparung) nur qualitativ beschreibbar erscheinen, ist für dieses Kriterium kein monetärer Wert anzusetzen.
Die qualitative Wirkung ist stattdessen in die Bewertung des entsprechenden
qualitativ-strategischen Kriteriums in der WiBe Q (im Regelfall in den Untergruppen 4.2, 4.3 oder 4.4) einzubringen.
Kriteriengruppe 1.1
Zur Ermittlung der Entwicklungskosten
Entwicklungskosten fallen vor dem Einsatz (beziehungsweise der Fertigstellung) der
neuen IT-Maßnahme an und enden, sobald die IT-Maßnahme offiziell den anwendenden
Organisationseinheiten zur Nutzung übergeben wird. Alle danach auftretenden Kosten
sind als Betriebskosten unter der Gruppe 2 des Kriterienkataloges erfasst. Migrationsprojekte beinhalten bei der Umstellung einer gesamten Landschaft auch die Fachanwendungen, für die Neuentwicklungen oder Umprogrammierungen erforderlich werden.
Diese Aktivitäten sind unter den „Entwicklungskosten― darzustellen. Bei der Migration
von Migrationsobjekten fallen in der Regel keine Entwicklungskosten an, aber Kosten für
die Einführung. Um diesen Umstand hervorzuheben, wird das Kriterium „Entwicklungskosten― um den Begriff „Einführung― erweitert.
Seite 105
Kriteriengruppe 1.1.1
Planungs- und Entwicklungskosten
Unter diese Position fallen alle haushaltswirksamen und auch nicht unmittelbar haushaltswirksamen Kosten, die mit der Vorbereitung, der Planung und der Entwicklung für
die IT-Maßnahme verbunden sind. Beispiele dafür sind i.e.S. die Personalkosten für das
eigene Projektteam sowie die Kosten für externe Beratung. Beispiele i.w.S. dafür sind
spezielle Schulungen für die Bearbeiter der IT-Maßnahme und gegebenenfalls die technische Ausstattung, Reisekosten.
Nicht zu den Planungs- und Entwicklungskosten zählen die Kosten der Betreuung und
Pflege des Systems nach dessen Einführung: diese sind unter den Betriebskosten (den
Kriterien der Gruppe 2) zu erfassen.
Grundsätzlich sind die Kosten(-arten) im Sinne einer Vollkostenbetrachtung in die WiBe
einzustellen: es sind alle Kosten(-arten) zu berücksichtigen und zu berechnen, auch
wenn dafür keine gesonderte Mittelbeantragung im Haushalt erforderlich sein wird.
Kriterium 1.1.1.1
Personalkosten (eigenes Personal)
Darstellung von Kosten
nicht haushaltswirksam
Aufwände, die im Rahmen der Projektphasen für das eigene Personal entstehen.
Die Kosten für das amtseigene Personal (der Zeitaufwand für die Bearbeiter der ITMaßnahme) sind mittelbar zu quantifizieren. Voraussetzung dafür ist eine Projektplanung, aus der sich die „Personentage― -Ansätze der Bearbeiter ergeben. Die Zeitangaben können Sie mithilfe der Personalkostensätze88 (hrsg. vom Bundesministerium der
Finanzen) in die Personalkosten der IT-Maßnahme umrechnen. Im Wesentlichen werden
die Entwicklung des organisatorisch-technischen Gestaltungskonzepts und die Anforderungsdefinition für die Systemauswahl die erforderlichen Personalkosten bestimmen.
Hier sind gegebenenfalls auch die Besichtigung von Referenzinstallationen und Teststellungen einzubringen. Berücksichtigen Sie bei der Planung erforderlicher Personentage
angemessen, dass die sog. Interoperabilität gewahrt bleiben muss, auch über Ihre eigene Behörde hinaus - den Zeitaufwand dafür sollten Sie sorgfältig prüfen. Eine Vernachlässigung der internen („kalkulatorischen―) Personalkosten verfälscht die Wirtschaftlichkeitsbetrachtung: die Einbeziehung dieser Kosten ist grundsätzlich zwingend erforderlich.
Ein Projektplan in der Struktur der Migrationsphasen sowie deren Einzelaktivitäten erleichtert die Aufwandskalkulation (siehe Tabelle 9 u. Abbildung 4 u. Abbildung 5). Die
Aufwände sollten der einfachen Zuordnung halber getrennt nach Vergütungsgruppen
geplant werden. Dies erscheint im ersten Moment als zu detailliert, in der Praxis hat sich
jedoch schon oft gezeigt, dass eine detaillierte Planung zum einen die spätere Nachvollziehbarkeit erleichtert sowie zum anderen die in der Umsetzungsphase beginnende
Fortschrittsverfolgung wesentlich vereinfacht. Ist dies nicht möglich oder nicht gewünscht, so sollte aus den anteilig involvierten Vergütungsgruppen ein Durchschnitts-
88
Zu Personalkostensätzen gibt es Downloads auf der Web-Seite des BMF unter:
www.bundesfinanzministerium.de – Stichwort: Personalkostensätze
Seite 106
wert gebildet werden, mit dem dann einheitlich die Personalanteile bewertet werden. Die
entsprechend angewandte Methode sollte in den Annahmen und Prämissen beschrieben
werden (siehe Kapitel 3.1.2).
Alternativ bietet sich auch an, diese Aufwände anhand des benötigten Projektteams zusammenzustellen. Dabei sollte dann die zeitanteilige Mitarbeit in dem Projektteam des
betroffenen Personals abgeschätzt werden.
Der Aufwand lässt sich in beiden Vorgehensweisen anhand der Vergütungsgruppe aus
dem Rundschreiben des BMF ermitteln.
Der ermittelte Betrag ist regelmäßig in voller Höhe unter der Rubrik „nicht haushaltswirksam― zu erfassen.
Kriterium 1.1.1.2
Kosten externer Beratung
haushaltswirksam
Die Kosten externer Beratung sind mehr oder minder unmittelbar aus dem Vertragswerk
zu entnehmen.
Beachten Sie, dass sich dieses Kriterium unter Umständen mit dem Kriterium 1.1.2.2
überschneiden kann. Wenn die externe Beratung sich sowohl auf fachkonzeptionelle als
auch auf softwarebezogene Aspekte bezieht und eine anteilige Trennung nicht möglich
oder nicht sinnvoll ist, dann sind die Kosten unter diesem Kriterium 1.1.1.2 auszuweisen.
Es gilt das Bruttoprinzip: zu den Kosten externer Beratung zählen auch die Nebenkosten
(z. B. Reisekosten-Vergütungen, gesetzliche Umsatzsteuer u. ä.).
Hier werden die externen Personalaufwände dargestellt. Auch hier dient als Basis der
Projektplan. Es empfiehlt sich, die Aufwände der einfachen Zuordnung halber getrennt
nach Lieferanten zu planen.
Der ermittelte Betrag ist regelmäßig in voller Höhe als „haushaltswirksam― zu erfassen.
Kriterium 1.1.1.3
Kosten der Entwicklungsumgebung
haushaltswirksam
Unter diesem Kriterium sind alle Kosten auszuweisen, die bei der Beschaffung von Hardund Software für das Entwicklerteam anfallen. Auch Beschaffungen von Hard- und Software für Teststellungen fallen unter dieses Kriterium.
Zu den Kosten der Entwicklungsumgebung im weiteren Sinne zählen auch die Kosten,
die sich aus dem notwendigen Konfigurationsmanagement beziehungsweise allgemein
aus dem Vorgehensmodell des Bundes ergeben.
Wird bereits vorhandene Hard- und Software (mit-)genutzt, dann kann die Berechnung
dieser anteiligen (nicht haushaltswirksamen) Kosten unterbleiben. Soweit auch Kosten
für die externe Schulung der Bearbeiter der IT-Maßnahme anfallen, sind die reinen
Schulungskosten (‗Seminargebühren‘) unter diesem Kriterium auszuweisen.
Seite 107
Kriterium 1.1.1.4
Sonstige Kosten für Sach-/Hilfsmittel
haushaltswirksam und/ oder nicht haushaltswirksam
Unter die Kosten für Sach- und Hilfsmittel fallen (analog zum vorigen Kriterium) Kosten
für Material und Hilfsmittel und Ausstattungskosten, die zur Unterstützung der Bearbeiter
der IT-Maßnahme erforderlich werden. Werden dabei bereits vorhandene Sach-/ Hilfsmittel (mit-)genutzt, dann kann die Berechnung dieser anteiligen (nicht haushaltswirksamen) Kosten unterbleiben.
Soweit für bereits vorhandene Räumlichkeiten interne Verrechnungssätze vorliegen, sind
auch diese Kosten hier als „nicht haushaltswirksam― in die WiBe aufzunehmen. Falls für
die Vorhabensbearbeiter geeignete Räume erst angemietet werden müssen, sind diese
Kosten haushaltswirksam zu erfassen.
Kriterium 1.1.1.5
Reisekosten (eigenes Personal)
haushaltswirksam
Das Kriterium Reisekosten (eigenes Personal) beinhaltet alle Kosten für Reisen, Unterbringung, Tagegelder der Projektmitarbeiter89 (bspw. Besichtigungs- oder Informationsreisen zu anderen Behörden oder Lieferanten), die im Rahmen der Vorbereitung und
Durchführung des Migrationsprojektes abfallen.
Der ermittelte Betrag ist regelmäßig in voller Höhe unter der Rubrik „haushaltswirksam―
zu erfassen.
Insbesondere sollte überprüft werden, inwieweit Reisekosten überhaupt begründet sind:
fast alle Anbieter sind heute mit einem umfangreichen Informationsangebot im Internet
vertreten, sodass Informationsreisen selektiv geplant werden können.
Systemkosten
Unter diese Position fallen alle haushaltswirksamen und auch nicht unmittelbar haushaltswirksamen Kosten, die mit der Erstellung (Bereitstellung) der erforderlichen Hardund Software anfallen.
Nicht zu diesen Kosten zählen die Kosten für die eigentliche Systemeinführung: diese
sind unter der Kriteriengruppe 1.1.3 gesondert zu erfassen.
Es ist zu klären, ob die IT-Maßnahme ein vorhandenes IT-System ablöst und ob daraus
ein einmaliger Aufwand für das Alt-System entsteht. Solche kalkulatorischen „Restwerte―
sind zusätzlich unter dem Kriterium 1.1.2.1 aufzunehmen (eventuelle Veräußerungserlöse erfassen Sie später unter 1.2.2).
89
Zu den Reisekosten zählen ebenfalls bspw. Kosten für Flugtickets, Bahntickets, Kosten für
öffentliche Verkehrsmittel, Kilometergelder, Taxi- und Parkkosten, etc..
Seite 108
Kriteriengruppe 1.1.2.1
Hardwarekosten
Hardware-Kosten (und zugehörige Kosten für Systemzubehör beziehungsweise Material) können Sie regelmäßig unmittelbar monetär quantifizieren: dazu liegen auch in der
Vorstudie Offerten beziehungsweise Richtwerte der verschiedenen Anbieter vor.
Das Kriterium ist unterteilt in Host/Server, Netzbetrieb (1.1.2.1.1) und Arbeitsplatzrechner (1.1.2.1.2). Soweit Ihr Haus in den nächsten Jahren in größerem Umfang Arbeitsplatzrechner installieren wird, ist es zweckmäßig, dafür pauschale Kostensätze einzusetzen, um die Berechnung in einzelnen WiBe zu vereinfachen und zu vereinheitlichen.
Der ermittelte Betrag ist regelmäßig unter der Rubrik „haushaltswirksam― zu erfassen.
Bei jeder der Migrationsalternativen ist zu prüfen, ob die vorhandene Hardware noch
verwendbar ist beziehungsweise ob für eine der Alternativen längere Nutzungsdauern
angenommen werden können.
Kriterium 1.1.2.1.1
Host/ Server, Netzbetrieb
haushaltswirksam
In der Regel wird eine Migration vor dem Hintergrund notwendiger und umfangreicher
Hardwareerneuerung geplant. Somit entstehen in jedem Fall durch die Migration Hardwareausgaben. Dazu können z. B. gehören: Datenbank-Server, Applikations-Server,
Firewall, Web-Applikationen, Infrastruktur/Netz, Router, Drucker (soweit serverseitig),
und so weiter.
Kriterium 1.1.2.1.2
Arbeitsplatzrechner
haushaltswirksam
Auch bei den Arbeitsplatzrechnern kann es zu Neuinvestitionen kommen. Die entstehenden Kosten (z. B. für PCs, Notebooks, Drucker, etc.) sind unter diesem Kriterium
aufzuzeigen.
Kriteriengruppe 1.1.2.2
Softwarekosten
Kosten für Software lassen sich bei Fremderstellung beziehungsweise -bezug unmittelbar monetär quantifizieren und in voller Höhe als haushaltswirksame Kosten ausweisen.
Soweit Software hausintern entwickelt wird, prüfen Sie, ob Sie diese Kosten bereits unter
der Position 1.1.1.1 (Personalkosten, eigenes Personal) berücksichtigt haben. Andernfalls müssen die Software-Kosten mittelbar berechnet werden: der erforderliche Personentage-Aufwand der Software-Entwickler ist mit dem jeweiligen Personalkostensatz zu
multiplizieren (und unter nicht haushaltswirksamen Kosten auszuweisen). Hier werden
Sie zu Beginn der IT-Maßnahme auf Schätzungen angewiesen sein, sofern Sie nicht auf
Erfahrungswerte aus vergleichbaren IT-Maßnahmen zurückgreifen können. Vermeiden
Sie dabei „geschönte― Aussagen: die Ansätze für den Systementwicklungsaufwand erweisen sich häufig als zu optimistisch. Das Kriterium ist unterteilt in Kosten für die eigentliche Entwicklung (1.1.2.2.1; Kern der IT-Maßnahme), Kosten für die Anpassung von
Seite 109
anderer Software und von Schnittstellen (1.1.2.2.2) und Kosten für die Evaluierung, Zertifizierung und Qualitätssicherung von Software (1.1.2.2.3).
Zu beachten ist, dass ein Mehr an nicht genutzten Funktionalitäten keine Berücksichtigung in der WiBe findet.
Kriterium 1.1.2.2.1
Kosten für Entwicklung beziehungsweise Beschaffung von Software
haushaltswirksam
Hier werden Kostenansätze für Lizenzen, Miete und/ oder Kauf ausgewiesen.
Für Open Source Software fallen üblicherweise keine Lizenzkosten an, da die erworbene
Kopie legal multipliziert und weitergegeben werden kann. Darin liegt im Vergleich zur
proprietären Software ein erhebliches Einsparungspotenzial, das Sie anhand der betroffenen Arbeitsplätze berechnen können.
Kriterium 1.1.2.2.2
Kosten für Anpassung von Software und/ oder Schnittstellen, Treiber
haushaltswirksam
Sind für die Software Anpassungen erforderlich, so können die Aufwände hier erfasst
werden. Dabei ist unerheblich, ob es sich um Personentageaufwände 90 oder um Festpreisverträge handelt.
Bei OSS-Projekten haben Sie die freie Wahl des Anbieters, wenn es um die Anpassung
von Schnittstellen, Treibern u. ä. geht - die transparentere Wettbewerbssituation kann
günstigere Angebote herbeiführen.
Kriterium 1.1.2.2.3
Kosten für Evaluierung, Zertifizierung und Qualitätssicherung
haushaltswirksam
Unter diese Position fallen alle haushaltswirksamen und auch nicht unmittelbar haushaltswirksamen Kosten, die durch das Testen der Software auf Eignung für den spezifizierten Verwendungszweck entstehen. Weiterhin zählen dazu auch Kosten für eine
eventuell notwendige Zertifizierung der Software durch eine anerkannte Firma oder Organisation, Kosten für die Erhebung einer Mängelliste und für die Nachbesserung oder
Problembehebung (sofern diese Kosten nicht durch Garantie- und Supportleistungen
oder durch Berücksichtigung in anderen Kriterien der IT-WiBe bereits abgedeckt sind).
90
Interne Personentageaufwände sind nach der eingangs beschriebenen Methode zu ermitteln. Dabei wird die Projektplanung zugrunde gelegt und die betreffenden Personentage mit
den jeweiligen Kostenansätzen bewertet. In den Prämissen und Annahmen ist festgelegt,
ob mit einem durchschnittlichen Verrechnungspreis oder nach Vergütungsgruppen bewertet
wird.
Seite 110
(Kosten lokal erforderlicher Anpassungen der Software werden unter Kriterium 1.1.2.2.2;
Beratungsleistungen erfasst, die als „bundle― mit der Software angeboten werden, bringen Sie unter Kriterium 1.1.3.2 ein.)
Kosten der Systemeinführung
Unter diese Position fallen alle haushaltswirksamen und auch nicht unmittelbar haushaltswirksamen Kosten, die sich auf die Umstellung vom alten Verfahren auf die neue ITMaßnahme beziehen und mit denen sichergestellt wird, dass die neue IT-Maßnahme
von den Anwendern in vollem Umfang auch benutzt werden kann.
Nicht zu diesen Kosten zählen die Kosten der laufenden Betreuung und Pflege des Systems nach der Einführungsphase; diese sind später unter den laufenden Betriebskosten
der Kriteriengruppe 2.2.3 zu erfassen.
Kriterium 1.1.3.1
System- und Integrationstest(s)
haushaltswirksam/ nicht haushaltswirksam
Vor Abnahme des Systems muss geprüft werden, ob die gewünschte Funktionalität vorhanden ist. Insbesondere wenn die Systemlösung eine Integration unterschiedlicher Systemkomponenten beinhaltet, ist ein anwendungsorientierter Test der Schnittstellen empfehlenswert.
Zu beachten ist, dass Sie die sog. Interoperabilität (insbesondere mit anderen Behörden)
sicherstellen, das heißt, die wechselseitige Verwendung von Informationen muss einfach
und zuverlässig gelöst sein. In einer „Mischform― verschiedener proprietärer SW Produkte beziehungsweise von Open Source SW und proprietärer SW wird diese Prüfung umfangreicher und zeitaufwendiger ausfallen.
Kriterium 1.1.3.2
Kosten der Systeminstallation
haushaltswirksam
Unter diesem Kriterium sind alle Personalkosten, soweit diese nicht unter 1.1.1.1 erfasst
sind, und alle Sachkosten anzuführen, die sich auf die Installation des neuen Verfahrens
beziehen. Sachkosten der System-Installation entstehen z. B. aus der Anschaffung von
Werkzeugen für die SW-Verteilung.
Bei großem Installationsumfang ist zu prüfen, ob die Installationsroutine automatisiert
werden kann; daraus ergeben sich erhebliche Zeiteinsparungen im Vergleich zur Einzelinstallation.
Kriterium 1.1.3.3
Übernahme von Datenbeständen
Im Rahmen der Migration wird es zu Datenübernahmen kommen. Die dafür notwendigen
Aufwendungen sind hier zu planen. Die Aufnahme der Ist-Situation bietet eine Basis, um
Seite 111
die entsprechenden Aktivitäten abzuschätzen. Diese können entweder in Personentagen
ausgedrückt werden oder in Festpreisangeboten von externen Lieferanten, die für spezielle Datenbereiche Übernahme- oder Umstellungsarbeiten anbieten.
Bei diesem Kriterium ist zu prüfen, inwieweit die neue Anwendungssoftware die bisherigen Datenformate lesen kann oder ob hier zusätzliche Entwicklungsarbeiten mit entsprechenden (haushaltswirksamen und/ oder nicht haushaltswirksamen) Kosten entstehen. Anpassungen beziehungsweise Erweiterungen können bei OSS aufgrund der offen
gelegten Schnittstellen grundsätzlich bei verschiedenen Dienstleistern „im Wettbewerb―
beauftragt werden.
Auch manuelle Nachbearbeitung bei der Übernahme von Datenbeständen ist zu berücksichtigen. Sie werden über einen geeigneten Maßstab das Datenvolumen bestimmen
und die Kosten daraus ableiten. Sofern die betreffende(n) Applikation(en) sowohl im bisherigen (proprietären) Betriebssystem als auch im OSS-Betriebssystem angeboten werden, dürften die Kosten der Datenübernahme gering ausfallen.91
Kriterium 1.1.3.4
Erstschulung Anwender und IT-Fachpersonal
Die Kosten für die Erstschulung von Anwendern und IT-Fachpersonal lassen sich je
Teilnehmer bei externen Schulungen exakt quantifizieren. Sofern für das ITFachpersonal besondere Kosten der Zertifizierung (beispielsweise durch den SoftwareHersteller) anfallen, sind diese ebenfalls unter diesem Kriterium zu berücksichtigen.
Auch hier ist eine Trennung zwischen haushaltswirksamen und nicht haushaltswirksamen Kostenanteilen vorzunehmen: nach der Vollkostenbetrachtung zählen dazu nicht
nur die Seminargebühren und Nebenkosten (Dienstreise, Unterbringung), sondern auch
die Personalkosten der entfallenden Anwesenheitszeit am Arbeitsplatz.
Bei größeren Behörden wird es sinnvoll sein, für interne Schulungen Pauschalsätze zu
berechnen, die die Schulungskosten je Schulungstyp und Schulungstag ausweisen und
die zusammen mit den Personalkosten der jeweiligen Besoldungsstufe beziehungsweise
Vergütungsgruppe die Kosten der Schulung insgesamt ausdrücken.
Die Erstschulungskosten für IT-Fachpersonal bei einem Umstieg auf OSS lassen sich
nicht in einem Pauschalsatz ausdrücken. In der Regel wird die Schulung extern durchgeführt und verursacht damit haushaltswirksame Kosten, deren Höhe Sie durch Angebotsvergleich verschiedener Anbieter ermitteln.
Bei allen Migrationsalternativen sind gleiche Qualifizierungs- und Schulungsziele festzulegen.
Die den Ausfallzeiten der zu schulenden Mitarbeiter gegenüberstehenden Kosten sind
hier ebenfalls zu planen. Diese Kosten werden nicht haushaltswirksam erfasst.
91
Lassen Sie dabei auch überprüfen, ob gegebeenfalls andere Behörden bereits entsprechende Konvertierungstools in Auftrag gegeben haben. Sofern es sich dabei um OSS handelt, kann diese von Ihrer Behörde kostenfrei verwendet werden.
Seite 112
Kriterium 1.1.3.5
Einarbeitungskosten Anwender und IT-Fachpersonal
Einarbeitungskosten für den Anwender entstehen immer dann, wenn (trotz Erstschulung)
eine Umstellungsphase zur Eingewöhnung erforderlich ist. Bei neuer Software wird der
Anwender nicht sofort alle Funktionen in der gewünschten Routine nutzen können. Dies
führt in einer Übergangszeit zu verminderter (quantitativer) Arbeitsleistung. Diese (auch
individuell unterschiedlichen) Einarbeitungskosten sind nur schwer quantifizierbar. Eine
pauschale Aussage ist deshalb nicht möglich. Die Erfahrung zeigt, dass dieses Kriterium
kaum herangezogen wird, obwohl es fast immer relevant ist.
Grundsätzlich kann bei einem erstmaligen Einsatz von neuen Oberflächen/ Benutzerschnittstellen im Client-Bereich dieses Kriterium von Bedeutung sein: hier sind vorübergehende Leistungsreduzierungen möglich.
Kriterium 1.1.3.6
Sonstige Umstellungskosten
Unter dieser Position können sonstige Umstellungskosten der Migration zu erfasst werden. Auf eine nachvollziehbare Begründung beziehungsweise Kommentierung der einzelnen Kostenpositionen ist zu achten.
Darüber hinaus sollte hinreichend überprüft werden, ob die einzustellenden Kostenpositionen nicht auch unter den spezifischen monetären Kriterien der WiBe erfasst werden
können.
Kriteriengruppe 1.2
Entwicklungs-/Einführungsnutzen aus Ablösung des alten Verfahrens
„Entwicklungsnutzen― steht in diesem Zusammenhang für den monetär quantifizierten
Nutzen, der vor dem (flächendeckenden) Einsatz der IT-Maßnahme anfällt; er endet,
sobald die IT-Maßnahme offiziell der anwendenden Organisationseinheit zum Einsatz
übergeben wird.
Kriterium 1.2.1
Einmalige Kosteneinsparungen (Vermeidung von Erhaltungs-/
Erweiterungskosten Altsystem)
Darstellung von Kosten/ Nutzen
Mit dem Entwicklungsnutzen sind zunächst die eher seltenen Fälle von Einsparungen
gemeint, die sich aus vermeidbaren Investitionen in das vorhandene Alt-System aufgrund der IT-Maßnahme ergeben können. Soweit Investitionen beziehungsweise Erhaltungsaufwände für das Alt-System fest eingeplant oder technisch unumgänglich sind,
können diese Beträge als Einsparungen eingerechnet werden.

Sachkosten für die Erhaltung umfassen beispielsweise anstehende Ersatzinvestitionen in Hardware-Komponenten u. ä. Sachkosten für die Erweiterung wären
Seite 113
beispielsweise Zukauf von Speicherkapazität, Peripheriegeräten sowie Kauf von
Fremdsoftware mit erweitertem Funktionsumfang.

Personalkosten für die Erhaltung beziehungsweise Erweiterung fallen z. B. an bei
Änderungen der technischen oder softwaremäßigen Eigenschaften, wenn dies intern geleistet wird.
Wenn die IT-Maßnahme derartige Kosten vermeiden hilft, sind diese Beträge in der WiBe anzusetzen. Sofern im Haushaltsplan dafür bereits ein Ansatz erfolgt ist, sind diese
Einsparungen auch haushaltswirksam. In jedem Fall aber sind die Berechnungswege
solcher Kosteneinsparungen präzise zu begründen und zu dokumentieren.
Kriterium 1.2.2
Einmalige Erlöse (aus Verwertung Altsystem)
Darstellung von Nutzen
haushaltswirksam
Einmalige Erlöse ergeben sich - wenn überhaupt - aus der Verwertung des Alt-Systems.
Dabei handelt es sich um den Verkauf von Hardware (seltener von Software).
Soweit für diese Veräußerungserlöse keine konkreten Beträge bereits vereinbart sind, ist
sorgfältig zu prüfen, ob und zu welchem Preis eine Veräußerung möglich ist. Die Erlöse
gehen als (einmaliger) monetärer Entwicklungsnutzen in die WiBe ein.
Kriteriengruppe 2
Betriebskosten und Betriebsnutzen
In der Gruppe 2 des Kriterienkataloges sind die Betriebskosten und Betriebsnutzen
enthalten, die nach der Einführung der IT-Maßnahme anfallen werden.
Diese Betriebskosten und Betriebsnutzen sind im Regelfall für einen Zeitraum zu ermitteln, der zusammen mit der Entwicklungs-/Einführungsdauer der IT-Maßnahme insgesamt eine Berechnungsdauer von 5 Haushaltsjahren ergibt. Von diesem Zeitraum kann
in begründeten Fällen abgewichen werden92.
 Es ist unbedingt darauf zu achten, alle monetären Angaben aufzuteilen in den haushaltswirksamen und in den nicht haushaltswirksamen Anteil.
Grundüberlegungen zur Datenermittlung:
92

Betriebskosten und Betriebsnutzen können sich beziehen auf Sachkosten (Kriterium 2.1), auf Personalkosten (2.2), auf Wartung beziehungsweise Systempflege
(2.3) oder auf sonstige Positionen (2.4).

Betriebskosten entstehen ursächlich aus dem Einsatz des neuen Verfahrens. Im
Sinne einer Vollkostenbetrachtung sind dabei alle Kosten anzusetzen.

(Monetäre) Betriebsnutzen entstehen als Einsparungen, die sich aus dem Wegfall des bisherigen, alten Verfahrens ergeben.
Bei großen IT-Maßnahmen mit mehrjähriger Entwicklungszeit kann es zweckmäßig sein,
den 5-Jahres-Zeitraum um diese Entwicklungsdauer zu erhöhen. Bei Infrastrukturprojekten
(beispielsweise der Verkabelung von Gebäuden) kann es sinnvoll sein, auch über diesen
Zeitraum hinauszugehen. Bei IT-Maßnahmen dagegen, deren Einsatzdauer bereits jetzt
absehbar und begründet unter 5 Jahren liegen wird, ist ein kürzerer Zeithorizont für die ITWiBe zwingend erforderlich.
Seite 114

Die Ermittlung fragt grundsätzlich bei jedem Einzelkriterium nach den Kosten des
Einsatzes des neuen Verfahrens und stellt diesem sodann die Einsparungen gegenüber, die aus dem Wegfall des alten Verfahrens entstehen können.

Aus der Saldierung ergeben sich laufende Mehrkosten oder aber laufende Minderkosten (Einsparungen) bei jedem Kriterium. Diese Salden gehen später in die
WiBe KN ein.
Für alle folgenden Einzelkriterien gilt generell:

Soweit Wirkungen bei einem Kriterium nicht hinreichend exakt bezifferbar sind,
wirkt sich dieses Kriterium sowohl in der WiBe KN als auch in der ergänzenden
Kennzahl WiBe KN/R aus. Bei der Datenermittlung ist ein „plausibel begründeter―
monetärer Ansatz vorzulegen, der als „wahrscheinlicher Schätzwert― in die monetäre Wirtschaftlichkeitsbetrachtung (WiBe KN) übernommen wird. Die im ungünstigen Fall möglichen Überschreitungen dieses Schätzwertes sind als Risikozuschlag für die Risikoabwägung (WiBe KN/R) einzugeben.

Soweit Wirkungen bei einem monetären Nutzenkriterium (Einsparung) nur qualitativ beschreibbar erscheinen, ist für dieses Kriterium kein monetärer Wert anzusetzen.
Die qualitative Wirkung ist stattdessen in die Bewertung des entsprechenden
qualitativ-strategischen Kriteriums in der WiBe Q (im Regelfall in den Untergruppen 4.2, 4.3 oder 4.4) einzubringen.
Kriteriengruppe 2.1 Laufende Sachkosten/ Sachkosteneinsparungen
Laufende Sachkosten sind solche Kosten, die durch den Betrieb der neuen ITMaßnahme verursacht werden und weder Personalkosten, noch Wartungskosten sind.
Laufende Sachkosteneinsparungen sind alle Kosten des alten Verfahrens, die ab der
Einführung der neuen IT-Maßnahme entfallen und die weder Personalkosten noch Wartungskosten sind.
Kriterium 2.1.1
(Anteilige) Host-, Server- und Netzkosten
nicht haushaltswirksam/ nicht haushaltswirksam
Das Kriterium ‗(Anteilige) Host, Server- und Netzkosten‘ bezieht sich auf solche (kalkulatorischen) Kosten, die durch die IT-Maßnahme im zentralen Rechenzentrum, im Hostbetrieb, beziehungsweise in lokalen Netzen (Client-Server-Architektur) verursacht werden.
Diese Kosten sind üblicherweise als nicht haushaltswirksam in die WiBe einzustellen
(Ausnahme: die betrachtete IT-Maßnahme macht Aufrüstungen erforderlich).
Zu den Kosten zählen (neben eventuell anfallenden Mieten für die Hardware) die Kosten
des Personals, das für den Betrieb des Hosts/ Servers beziehungsweise für die Funktionsfähigkeit der Infrastruktur interner Netze zuständig ist.
Die genaue Berechnung dieser Kosten (sowohl für das Ist-Verfahren als auch für das
neue Verfahren) ist dann problematisch, wenn in Ihrem Amt keine detaillierte Kostenrechnung (Kostenerfassung) vorhanden ist. Zumindest ein Verrechnungssatz „Ist-Kosten
Seite 115
je CPU-Sekunde― sollte verfügbar sein, den Sie näherungsweise Ihren Berechnungen
zugrunde legen können.
Kriterium 2.1.2
(Anteilige) Kosten für Arbeitsplatzrechner
Das Kriterium ‗(Anteilige) Kosten für Arbeitsplatzrechner‘ bezieht sich auf solche Betriebskosten, die durch die IT-Maßnahme am Arbeitsplatz („Endplatz―) der Anwender
entstehen. Die Kosten sind üblicherweise als nicht haushaltswirksame Betriebskosten in
die WiBe einzustellen. (Ausnahme: die betrachtete IT-Maßnahme macht Aufrüstungen
beziehungsweise Auswechslungen bei gemieteter Hardware am Arbeitsplatz der Anwender erforderlich). Zu diesen Kosten zählen auch Kosten für die zugehörige Peripherie (Arbeitsplatzdrucker etc.). Im Standardfall wird die Hard- und Software für die einzelnen Arbeitsplätze erworben und nicht gemietet: es fallen dann keine Beträge bei diesem
Kriterium an.
Kriterium 2.1.3
Energie- und Raumkosten
Die Berechnung beziehungsweise Berücksichtigung von Energie- und Raumkosten kann
unterbleiben,

solange in eine Verrechnung auch bei anderen Vorhaben und bei der Kalkulation
eingesetzter IT-Maßnahmen nicht erfolgt,

bei kleineren IT-Maßnahmen beziehungsweise bei Maßnahmen, bei denen Sie
den Nettoeffekt zwischen ‗altem und neuem‘ Verfahren mit 0 begründen.
In anderen Fällen werden Sie eine detaillierte Berechnung vornehmen, bei der Sie die
technischen Daten der Hardware berücksichtigen (bei Energiekosten also im Wesentlichen den Verbrauch je Gerät in kWh, die Betriebsstunden pro Jahr je Gerät, die Anzahl
der Geräte, die Energiekosten je KW).
Bei den Raumkosten kann auf die tatsächliche Miete, auf die Ansätze der KostenLeistungsrechnung oder auf die Personalkostensätze des BMF zurückgegriffen.
Kriteriengruppe 2.2
Laufende Personalkosten/ Personalkosteneinsparungen
Laufende Personalkosten sind solche Kosten, die durch den Betrieb der neuen ITMaßnahme verursacht werden und weder Sachkosten noch Wartungskosten sind. Laufende Personalkosteneinsparungen sind alle Kosten des alten Verfahrens, die ab der
Einführung der neuen IT-Maßnahme entfallen und die weder Sachkosten noch Wartungskosten sind.
Seite 116
Kriterium 2.2.1
Personalkosten aus Systembenutzung
nicht haushaltswirksam
Das Kriterium „Personalkosten aus Systembenutzung― ist dann zu berücksichtigen, wenn
sie damit rechnen, dass der Zeitbedarf der Anwender für die Systembenutzung sich ändert. Es handelt sich dabei um alle Personalkosten, die in den AnwenderOrganisationseinheiten im Zusammenhang mit dem neuen Verfahren stehen. Dabei sind
auch Ausfallzeiten des Systems („downtime―) zu berücksichtigen. Es ist also erforderlich,
die gesamte jährliche Arbeitszeit zu ermitteln, die bei allen beteiligten Dienstposten beziehungsweise Organisationseinheiten durch den Einsatz des neuen Verfahrens „gebunden― sein wird. Laufende Personalkosteneinsparungen bei der Systembenutzung
sind alle Personalkosten, die in den Anwender-Organisationseinheiten im Zusammenhang mit dem alten Verfahren gebunden waren und die jetzt entfallen.
Die Personalkosten insgesamt ergeben sich aus der Besoldungseinstufung beziehungsweise Vergütungsgruppe (unter Anlegung der jeweiligen Personalkostensätze). Der
„Nutzen-Inkasso― von errechneten Personalkosteneinsparungen ist in vielen Fällen die
kritische Größe einer IT-Maßnahme: zumeist sind es die möglichen Personalkosteneinsparungen, die eine IT-Maßnahme erst mit einem positiven Kapitalwert versehen. Auf
die Berechnung des Nettoeffektes der Personalkosten ist deshalb besondere Sorgfalt zu
verwenden. Nettoeffekte, die eine Personalreduzierung ausweisen („kw-Stellen―), werden besondere Aktionen nahe liegen, damit diese Einsparungspotenziale auch haushaltswirksam umgesetzt werden.
Kriterium 2.2.2
Systembetreuung und –administration
Laufende Personalkosten für die Systembetreuung und -administration des neuen ITSystems entstehen, wenn Mitarbeiter in zentralen Unterstützungsstellen (Benutzerservice) als Ansprechpartner für Fragen der Systembenutzer benannt sind. (Die Kosten beziehen sich nicht auf Wartungs- und Pflegekosten.) Die Kosten sind mittelbar zu berechnen aus der jährlichen Stundenzahl (beziehungsweise aus dem prozentualen Anteil an
der gesamten Jahresarbeitszeit), mit dem die Mitarbeiter für die Einsatzbetreuung dieser
IT-Maßnahme voraussichtlich in Anspruch genommen werden. Das Kriterium erfasst
weiterhin alle Personalkosten, die in zentralen Unterstützungsstellen (Rechenzentrumsbetrieb) für die Administration des IT-Systems anfallen. Die Personalbedarfsermittlung
für die Systembetreuung und –administration ist insbesondere abhängig vom Ausbaustand der IT sowie von der Komplexität der Anwendungen (siehe „Grundsätze zur Bemessung des IT-Fachpersonals in obersten Bundesbehörden―, BMI-Schreiben vom
1.7.96 an IMKA – OI3 – 195 052-1/12).
Unter Umständen sind diese Kosten bereits in die anteiligen Host-Kosten (2.1.2) eingerechnet, sodass diese Position hier entfallen kann. Andernfalls ist eine Quantifizierung
erforderlich: die jährlichen Arbeitsstunden für die System-Administration sind überschlägig mit den Personalkostensätzen der jeweiligen Besoldungsstufe in die WiBe zu übernehmen. Diese Überlegungen gelten analog für die Berechnung der Personalkosteneinsparungen aus dem Wegfall des alten Verfahrens.
Seite 117
Werden jedoch neue Dienstposten erforderlich, so sind die dafür anzusetzenden Aufwände haushaltswirksam zu planen.
Kriterium 2.2.3
Laufende Schulung/ Fortbildung
Laufende Personalkosten für die Schulung und Fortbildung der Systembenutzer ergeben
sich aus der Notwendigkeit, nach der Erstschulung (siehe Kriterium 1.1.3.3) neue Anwender an das System heranzuführen beziehungsweise alle Anwender mit späteren
Änderungen in der Systembedienung vertraut zu machen. Hinzu kommen gegebenenfalls gezielte Nachschulungen in ausgewählten Nutzergruppen.
Die Überlegungen zur Erstschulung gelten analog (siehe Kriterium 1.1.3.3).
Als Pauschalwert kann ersatzweise (sofern keine anderen, spezifischen Daten vorliegen
beziehungsweise sofern solche Daten mit vertretbarem Aufwand nicht berechenbar erscheinen) ein jährlicher Ansatz von 10% der Kosten der Erstschulung verwendet werden.
Externe Schulungskosten werden haushaltswirksam dargestellt. Die bewerteten Ausfallzeiten der zu schulenden Mitarbeiter hingegen sind nicht haushaltswirksam.
Kriteriengruppe 2.3
Laufende Kosten/Einsparungen bei Wartung /Systempflege
Laufende Kosten bei diesem Kriterium sind solche Kosten, die durch den Einsatz des
neuen Verfahrens verursacht werden und die weder Host-, Server-, Netzkosten noch
Personalkosten sind.
Laufende Einsparungen bei diesem Kriterium sind alle Kosten des alten Verfahrens, die
ab der Einführung des neuen Verfahrens entfallen und die weder Host-, Server-, Netzkosten noch Personalkosten sind.
Kriterium 2.3.1
Wartung/ Pflege der Hardware
In der Regel wird eine Gewährleistung auf Hardware vom Hersteller/ Lieferanten geboten. In vielen Fällen auch schon 36 Monate. Ist der Betrachtungszeitraum der WiBe länger, so sind hier für die Zeit ab dem 4. Jahr Kosten zu veranschlagen. Diese können
entweder aufgrund eines vorliegenden Angebotes direkt angegeben werden oder mit
marktüblichen Ansätzen von 10% – 20% auf den Kaufpreis geschätzt werden. Hier sollte
jedoch in jedem Fall eine Recherche durchgeführt werden, um diesen Ansatz auf den
wahrscheinlichsten Wert einzugrenzen. Diese Kosten werden haushaltswirksam dargestellt.
Wird die Wartung hausintern durchgeführt, so sind in diesem Fall die Kosten für das eigene Personal anzusetzen. Dabei sind auch Kosten für die Infrastruktur beziehungsweise für die Ausrüstung der Mitarbeiter zu berücksichtigen, mit der sie die WartungsarbeiSeite 118
ten erst bewerkstelligen können. Wenn es sich um normale IT-Arbeitsplätze handelt,
kann hier durchaus auch die Sachkostenpauschale mit Zuschlag für Bildschirmarbeitsplätze des BMF angewandt werden. Diese internen Kosten werden nicht haushaltswirksam ausgewiesen.
Kriterium 2.3.2
Wartung/ Update der Software
Lizenzkosten für Update- und Servicereleases sind mit diesem Kriterium zu erfassen.
Die fast regelmäßig anfallenden Updates haben bei proprietärer Software erhebliches
Gewicht; diese Kosten entfallen grundsätzlich bei OSS.
Neben dem eigentlichen Update-Preis sind auch Installationskosten (als Zeitaufwand
des eingesetzten Personals) zu berücksichtigen. Zu den Update-/Wartungskosten im
weiteren Sinne zählt auch der erforderliche Support, der gegebenenfalls als externe
Dienstleistung eingekauft wird. (Bei OSS können Sie im Regelfall auf verschiedene Anbieter „im Wettbewerb― zugehen – diese Möglichkeit besteht bei proprietärer Software
zwar grundsätzlich auch, aber nicht immer in gleichem Ausmaß.)
Weiterhin sind hier die (Personal-) Kosten zu berücksichtigen, die im Zusammenhang
mit der laufenden Lizenzierung von Softwareprodukten beziehungsweise mit dem Nachweis der Lizenzrechte anfallen.
Dieser Aufwand kann bei proprietärer Software erheblich sein; er wird bei Open Source
Software deutlich geringer ausfallen.
Bei eigenerstellter Software liegen u. U. bereits konkretere Erfahrungswerte beziehungsweise Ausbaupläne vor (Versionenkonzept). Der Wartungsaufwand ist dann mittelbar
zu berechnen aus den erforderlichen Personal- und Rechnerzeiten.
Kriterium 2.3.3
Ersatz-/ Ergänzungskosten
Mit diesem Kriterium werden über die standardmäßige Wartung hinaus diejenigen Kosten erfasst, die möglicherweise während der Betriebsphase der IT-Maßnahme durch die
laufende, geplante Ergänzung von Hard- und Software entstehen können.
Ersatzkosten beziehen sich auf den teilweisen oder vollständigen Austausch handelsüblicher Hardware-Ausstattung (beispielsweise Komponenten von Arbeitsplatzdruckern
usw.).
Ergänzungskosten beziehen sich auf bereits absehbare Erweiterungen handelsüblicher
Hard- und Software während der Betriebsphase.
Sofern bei alternativen Lösungen von einer längeren technisch möglichen Nutzungsdauer vorhandener Hardware ausgegangen werden kann, sind diese Wirkungen monetär wie folgt zu berücksichtigen:
Seite 119
5.2.3
Migrations- und Anbieterszenarien
Eine Migration wird grundsätzlich verschiedene Szenarien zur Auswahl haben und unterschiedliche Anbieter werden für unterschiedliche Szenarien oder Teile davon Angebote abgeben. Die Wirtschaftlichkeitsbetrachtung sollte dies in jedem Fall berücksichtigen.
Die Ausführungen in Kapitel I.C 5.2.1, „Systematik―, stellen die Basis für das Grundgerüst der WiBe dar.
Eine alternative Betrachtung der WiBe hilft, die verschiedenen Szenarien und Angebotssituationen abzubilden. Die Kriterien, die von eventuell unterschiedlichen Angeboten
betroffen sind, werden in verschiedenen Alternativen der Wirtschaftlichkeitsbetrachtung,
mit den jeweiligen Angebotswerten gefüllt. Somit liefern die verschiedenen Alternativen
der WiBe eigenständige Aussagen zu Kapitalwert und Rentabilität. Ein Vergleich der
Alternativen kann dann die einzelnen Versionen zueinander in Relation setzen und eine
Entscheidungsbasis liefern.
Die folgenden Abbildungen zeigen exemplarisch eine monetäre WiBe für die Bereiche
der Einführungs- und Betriebskosten/ Nutzen (siehe die beiden nachfolgenden Abbildungen).
IT-Vorhaben: Migration von Server- und Clientarchitekturen
Pos.
Kriterium, Erläuterung zur Selektion
WiBe
Hinweis: Startjahr = 2005, Laufzeit = 8 Jahre,
Diskontierungs-Zins = 3,8%,
Break even gesamt im 5. Jahr, 2009
KN
Kosten + Nutzen - Entwicklung/ Einführung und Betrieb
Nominal Gesamt, 8 Jahre
gesamt
hh.wirks.
Barwerte Gesamt, 8 Jahre
n.hh.wirks.
gesamt
hh.wirks. n.hh. wirks.
2.307.062
-127.577
3.077.501
29.819
3.047.682
…davon Kosten
… davon Nutzen
KN Kumuliert
-3.802.487
6.879.987
3.077.501
-2.437.901
2.467.720
29.819
-1.364.586
4.412.267
3.047.682
1
Entwicklungs-/Einführungskosten und Entwicklungsnutzen
-2.349.509
-1.422.031
-927.478
-2.349.509 -1.422.031
-927.478
1.1
1.1.1
1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.1.5
1.1.2
1.1.2.1
1.1.2.2
1.1.3
1.2
1.2.1
1.2.2
…davon Kosten
… davon Nutzen
Entwicklungs-/Einführungskosten für das neue IT-Verfahren
-2.554.829
Planungs- und Einführungskosten
-1.165.910
Personalkosten (eigenes Personal)
-568.175
Kosten externer Beratung
-452.632
Kosten der Entwicklungsumgebung
0
Sonstige Kosten für Sach-/Hilfsmittel
-139.303
Reisekosten (eigenes Personal)
-5.800
Systemkosten
-786.596
Hardwarekosten
-165.880
Softwarekosten
-620.716
Kosten der Systemeinführung
-602.322
Entwicklungs-/Einführungsnutzen aus Ablösung des alten Verfahrens
205.320
Einmalige Kosteneinsparungen (Vermeidung von Erhaltungs205.320
/Erweiterungskosten
Altsystem)
Einmalige Erlöse (aus Verwertung Altsystem)
0
-1.627.351
205.320
-1.627.351
-641.235
-43.500
-452.632
0
-139.303
-5.800
-786.596
-165.880
-620.716
-199.520
205.320
205.320
0
-927.478
0
-927.478
-524.675
-524.675
0
0
0
0
-2.554.829 -1.627.351
205.320
205.320
-2.554.829 -1.627.351
-1.165.910
-641.235
-568.175
-43.500
-452.632
-452.632
0
0
-139.303
-139.303
-5.800
-5.800
-786.596
-786.596
-165.880
-165.880
-620.716
-620.716
-602.322
-199.520
205.320
205.320
205.320
205.320
0
0
-927.478
0
-927.478
-524.675
-524.675
0
0
0
0
-402.802
0
0
2.434.639
-3.630.750 -2.325.694 -1.305.056
5.937.812 2.198.118 3.739.695
2.307.062
-127.577 2.434.639
-402.802
Abbildung 20: WiBe - Beispielhafte WiBe Kalkulation 1, Einführungskosten/ -nutzen
Seite 120
0
0
IT-Vorhaben: Migration von Server- und Clientarchitekturen
Pos.
Kriterium, Erläuterung zur Selektion
WiBe
Hinweis: Startjahr = 2005, Laufzeit = 8 Jahre,
Diskontierungs-Zins = 3,8%,
Break even gesamt im 5. Jahr, 2009
KN
Kosten + Nutzen - Entwicklung/ Einführung und Betrieb
Nominal Gesamt, 8 Jahre
gesamt
hh.wirks.
Barwerte Gesamt, 8 Jahre
n.hh.wirks.
gesamt
hh.wirks. n.hh. wirks.
2.307.062
-127.577
3.077.501
29.819
3.047.682
…davon Kosten
… davon Nutzen
KN Kumuliert
-3.802.487
6.879.987
3.077.501
-2.437.901
2.467.720
29.819
-1.364.586
4.412.267
3.047.682
1
Entwicklungs-/Einführungskosten und Entwicklungsnutzen
-2.349.509
-1.422.031
-927.478
2
Betriebskosten und Betriebsnutzen
5.427.009
1.451.850
3.975.159
4.656.571
1.294.455
3.362.117
-810.550
2.262.400
-437.108
4.412.267
-1.075.921
5.732.492
-698.343
1.992.798
-377.578
3.739.695
2.1
2.1.1
2.1.1.1
2.1.1.2
2.1.2
2.1.2.1
2.1.2.2
2.1.3
2.1.3.1
2.1.3.2
2.2
2.2.1
2.2.1.1
2.2.1.2
2.2.2
2.2.2.1
2.2.2.2
2.2.3
2.2.3.1
2.2.3.2
2.3
2.3.1
2.3.1.1
2.3.1.2
2.3.2
2.3.2.1
2.3.2.2
2.3.3
2.3.3.1
2.3.3.2
2.4
2.4.1.1
2.4.1.2
…davon Kosten
… davon Nutzen
Laufende Sachkosten/ Sachkosteneinsparungen
(Anteilige) Host-, Server- und Netzkosten
Lfd. Kosten aus IT-Verfahren NEU
Lfd. Nutzen aus Wegfall IT-Verfahren ALT
(Anteilige) Kosten für Arbeitsplatzrechner
Lfd. Nutzen aus Wegfall Verfahren ALT
Energie- und Raumkosten
Laufende Personalkosten/-einsparungen
Personalkosten aus Systembenutzung
Systembetreuung und -administration
Laufende Schulung/Fortbildung
Laufende Kosten/Einsparungen bei Wartung /Systempflege
Wartung/Update der Hardware
Wartung/Update der Software
Ersatz-/Ergänzungskosten
Sonstige Laufende Kosten und Einsparungen
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3.882.359
4.412.267
0
4.412.267
-437.108
-437.108
0
-92.800
-92.800
0
1.544.650
303.850
-230.550
534.400
1.240.800
-487.200
1.728.000
0
0
-92.800
0
0
-81.741
-81.741
0
1.376.196
274.964
-195.754
470.717
1.101.232
-420.848
1.522.080
0
0
3.362.117
3.739.695
0
3.739.695
-377.578
-377.578
0
0
0
0
0
3.280.375
3.739.695
0
3.739.695
-377.578
-377.578
0
-81.741
-81.741
0
1.376.196
274.964
-195.754
470.717
1.101.232
-420.848
1.522.080
0
0
-81.741
0
0
-92.800
-92.800
0
1.544.650
303.850
-230.550
534.400
1.240.800
-487.200
1.728.000
0
0
3.975.159
4.412.267
0
4.412.267
-437.108
-437.108
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2.434.639
-3.630.750 -2.325.694 -1.305.056
5.937.812 2.198.118 3.739.695
2.307.062
-127.577 2.434.639
-2.349.509 -1.422.031
0
0
-927.478
0
0
0
0
0
0
Abbildung 21: Beispielhafte WiBe Kalkulation 2, Betriebskosten/ -nutzen
Ergebnis einer WiBe sollte auch ein Überblick der haushaltswirksamen Kosten sein. Dieser Überblick wird punktuell in den Zeilen obiger WiBe-Darstellung mit der Bezeichnung
„davon Kosten― gegeben.
5.3
Erweiterte Wirtschaftlichkeit
Die erweiterte Wirtschaftlichkeit wird mit qualitativen Kriterien bewertet. Dazu wird für
jedes Kriterium eine Nutzwert-Analyse durchgeführt, wobei die Beantwortung des jeweiligen Kriteriums anhand einer beschriebenen Notenskala von 0 – 10 vorgenommen93
wird. Jedes Kriterium ist in seiner Gruppe (Dringlichkeit; Qualität) mit einer Gewichtung94
versehen, deren Summe sich in der Gruppe auf 100 addiert.
93
94
Es handelt sich dabei um eine Ordinalskala mit aufsteigender Wertigkeit der vorgefundenen
Umstände, wobei 0 die Minimalbewertung und 10 die Maximalbewertung darstellt.
siehe die Kriterienkataloge Dringlichkeit (siehe Abbildung 76 im Anhang) und Qualität (siehe Abbildung 78 im Anhang), sowie deren Gewichtungstabellen, Gewichtung Dringlichkeit
(siehe Abbildung 77, im Anhang) Gewichtung Qualität (siehe Abbildung 79 im Anhang).
Seite 121
5.3.1
Dringlichkeitskriterien
Dringlichkeitskriterien beziehen sich einerseits auf die technische Ablösedringlichkeit des
Altsystems, andererseits auf die Einhaltung von Verwaltungsvorschriften und Gesetzen.
Diese Kriterien sind nicht monetär quantifizierbar. Sie werden stattdessen in eine Nutzwertbetrachtung eingebracht. Die zu beurteilenden Kriterien werden qualitativ beschrieben. Diese Beschreibung wiederum ist in eine Punktbewertung je Kriterium umzusetzen.
Dafür steht zu jedem Kriterium eine „Notenskala― von 0 bis 10 zur Verfügung.
Unter Bezugnahme auf die Ordnungsnummer des Kriterienkataloges für Migrationen ist
jeweils zunächst eine Erläuterung beziehungsweise Abgrenzung des Kriteriums zu finden. Darauf folgt die Tabelle mit der Skalierung, aus der die Umsetzung in einen Punktwert abzuleiten ist.
Kriteriengruppe 3.1
Kriterium 3.1.1
Ablösedringlichkeit Altsystem
Unterstützungskontinuität Altsystem
Dieses Kriterium zielt auf den derzeitigen Ist-Zustand: soweit dort Hard- und Software
verwendet wird, ist das Ausmaß an (zukünftiger) Unterstützung durch den Lieferanten
von Bedeutung. Stellt der Lieferant von sich aus diese Unterstützung ein, kann sich daraus der Zwang zur internen Ablösung des (an sich funktionstüchtigen) Altsystems ergeben. Die Bedeutung dieses Kriteriums ist qualitativ zu schätzen.
3.1.1 Unterstützungs-Kontinuität Altsystem
0
2
nicht
gefährdet
4
soweit absehUnterstützung
bar besteht kein läuft aus, Ersatz
Engpass
derzeit nicht
erforderlich
6
8
10
Unterstützung
läuft aus, kurzfristig keine
Probleme
Unterstützung
läuft aus, Ersatz
dringend
Unterstützung
entfällt, Neulösung zwingend
Tabelle 15: Punktbewertungsskala Unterstützungskontinuität Altsystem
Kriterium 3.1.2
Stabilität Altsystem
Dieses Kriterium bewertet die vorhandene Ist-Lösung hinsichtlich ihrer Funktionstüchtigkeit im „tagtäglichen― Einsatz. Dabei interessieren sowohl qualitative Aussagen über
Fehlerhäufigkeiten bis hin zu Systemabstürzen, als auch Bewertungen zu Problemen der
Systemwartung (technischer Aspekt) beziehungsweise dabei bestehenden Personalengpässen (Verfügbarkeit von Know-how im Umgang mit auftretenden Fehlern).
Seite 122
Kriterium 3.1.2.1
Fehler und Ausfälle („downtime“)
3.1.2.1 Stabilität des Altsystems: Fehler und Ausfälle („downtime―)
0
2
4
6
8
10
nicht gefährdet
kaum
beeinträchtigt
gering beeinträchtigt, noch
tolerabel
durchschnittlich
beeinträchtigt,
störend
überdurchschnittlich beeinträchtigt,
belastend
sehr stark beeinträchtigt,
intolerabel
Tabelle 16: Punktbewertungsskala Fehler und Ausfälle („downtime―)
Kriterium 3.1.2.2
Wartungsprobleme, Personalengpässe
3.1.2.2 Stabilität des Altsystems: Wartungsprobleme, Personalengpässe
0
2
4
6
8
10
nicht von Bedeutung
selten, gering
gering, noch
tolerabel
gering, aber
absehbar zunehmend
mittel,
zunehmend
anhaltend
gravierend
Tabelle 17: Punktbewertungsskala Wartungsprobleme, Personalengpässe
Kriterium 3.1.3
Flexibilität Altsystem
Dieses Kriterium bewertet die vorhandene Ist-Lösung hinsichtlich ihrer zu-künftigen
Funktionstüchtigkeit. Dabei interessieren Aussagen über die weiteren Ausbaumöglichkeiten, über die Interoperabilität beziehungsweise über (künftige) Schnittstellenprobleme
zu anderen IT-Systemen und zur Bedienbarkeit und Ergonomie des Altsystems.
Die Unterkriterien sind nur qualitativ beschreibbar.
Kriterium 3.1.3.1
Ausbau-/Erweiterungsgrenzen
3.1.3.1 Flexibilität des Altsystems: Ausbau-/Erweiterungsgrenzen
0
2
4
6
8
10
nicht eingeschränkt
wenig eingeschränkt
eingeschränkt,
kleinere Anforderungen
können erfüllt
werden
eingeschränkt,
mittlere Anforderungen können nur aufwendig erfüllt
werden
stark eingeschränkt, viele
Anforderungen
können nicht
realisiert werden
Ausbau beziehungsweise
Erweiterung
nicht möglich,
aber erforderlich
Tabelle 18: Punktbewertungsskala Ausbau-/Erweiterungsgrenzen
Seite 123
Kriterium 3.1.3.2
Interoperabilität, Schnittstellenprobleme aktuell/zukünftig
3.1.3.2 Flexibilität
tuell/zukünftig
des
Altsystems:
Interoperabilität,
Schnittstellenprobleme
ak-
0
2
4
6
8
10
nicht eingeschränkt
Probleme derzeit nicht wahrscheinlich
Probleme
absehbar,
Anpassungen
problemlos
erforderliche
Anpassungen
aufwendig, aber
nicht dringend
Zahlreiche
aufwendige
Anpassungen,
dringend
Anpassungen
dringend
erforderlich,
überfällig
Tabelle 19: Punktbewertungsskala Interoperabilität, Schnittstellenprobleme aktuell/zukünftig
Kriterium 3.1.3.3
Bedienbarkeit und Ergonomie (Benutzerfreundlichkeit)
3.1.3.3 Flexibilität des Altsystems: Bedienbarkeit und Ergonomie
0
2
4
6
8
10
nicht von
Bedeutung
kleine ergonomische
Mängel
geringe Beeinträchtigungen
mittlere Beeinträchtigungen
erhebliche Mängel, Änderungsbedarf
gravierende
Mängel,
unzumutbar
Tabelle 20: Punktbewertungsskala Bedienbarkeit und Ergonomie (Benutzerfreundlichkeit)
Kriteriengruppe 3.2 Einhaltung von Verwaltungsvorschriften und Gesetzen
Kriterium 3.2.1
Einhaltung gesetzlicher Vorgaben
Mit diesem Kriterium wird bewertet, inwieweit vorhandene Altsysteme dem vorhandenen
beziehungsweise geänderten gesetzlichen Handlungsauftrag, d. h. einem formellen Gesetz entsprechen.
Dieses Kriterium ist ein sog. MUSS-Kriterium: wenn bei diesem Kriterium die Bewertung „10 Punkte― vorzunehmen ist, muss die IT-Maßnahme in jedem Fall umgehend durchgeführt werden.
3.2.1 Einhaltung gesetzlicher Vorgaben
0
2
4
6
8
10
Gewährleistet
Absehbare
Rechtsänderung, ist bereits
berücksichtigt
absehbare
Rechtsänderung, ist ansatzweise berücksichtigt
anstehende
Rechtsänderungen
sind nicht
berücksichtigt
geltende
Rechtsnormen
sind mangelhaft
eingehalten
geltende
Rechtsnormen
sind nicht eingehalten
Tabelle 21: Punktbewertungsskala Einhaltung gesetzlicher Vorgaben
Seite 124
Kriterium 3.2.2
Erfüllung Datenschutz/ -sicherheit
Das Kriterium zielt darauf ab, ob das vorhandene IT-System beziehungsweise die gegenwärtige Verfahrenslösung alle datenschutzrechtlichen Forderungen erfüllt. Weiterhin
ist hier die Datensicherheit zu bewerten, das heißt, inwieweit das vorhandene System
technisch und organisatorisch gegen den Verlust der Vertraulichkeit, Integrität und Verfügbarkeit von Daten gesichert ist.
Bei hohen Sicherheitsanforderungen ist zu prüfen, inwieweit die Forderungen des BSI
(beispielsweise hinsichtlich Einsichtnahme in Quellcodes) erfüllt sind. Durch das Vorliegen des Source Codes ist es bei OSS grundsätzlich immer möglich, hohe Prüftiefen bei
der Evaluierung/ Zertifizierung zu erreichen. Bei proprietärer Software ist der Hersteller
vielfach nicht bereit, den Sourcecode zur Verfügung zu stellen, womit höhere Prüftiefen
prinzipiell nicht erreichbar sind. In diesem Fall müsste bei nachträglicher Forderung einer
höheren Prüftiefe das gesamte Verfahren ersetzt werden. Dieser Aspekt ist bei Forderungen des Datenschutzes und der Datensicherheit nach Zertifizierung zu berücksichtigen.
Soweit sich bei der (Über-) Prüfung des vorhandenen IT-Systems Abweichungen zu Auflagen und Empfehlungen (beispielsweise den KBSt-Empfehlungen) ergeben haben
(z. B. IT-Grundschutz-Kataloge beziehungsweise IT-Sicherheitshandbuch), sind diese
hier zu berücksichtigen.
Mit diesem Kriterium wird die Sicherheit bei der internen und vor allen Dingen bei der
externen Kommunikation abgefragt. Wie wird die Datenübertragung gesichert? Werden
sichere Protokolle eingesetzt? Existiert eine Übertragungssicherung, Zugriffskontrolle,
und so weiter?
Ist die Software prüfbar bzgl. IT-Sicherheit? Wie anfällig ist sie für externe Angriffe, Viren
und so weiter? Ist die Software modular aufgebaut (Trennung von System und Anwendungsprogrammen, Minimierbarkeit von Anwendungsprogrammen auf notwendige Funktionen)? Existieren Zugangs- und Zugriffskontrollen?
Existiert ein Sicherheitsmanagement? Gibt es ein Sicherheitskonzept, das allen Beteiligten bekannt ist? Existiert ein beschriebener Prozess zu Sicherheitsüberprüfung sowie
deren Dokumentation?
3.2.2 Erfüllung von Datenschutz und Datensicherheit
0
2
nicht
beeinträchtigt
4
6
kleine unbedeu- geringe Mängel, geringe Mängel,
tende Mängel
aber
mittelfristiger
anderweitig
Änderungsbeabzustellen
darf
8
10
Datenschutz
und Datensicherheit mangelhaft eingehalten
gravierende
Verstöße, Anpassungen
dringlich
Tabelle 22: Punktbewertungsskala Erfüllung von Datenschutz/ -sicherheit
Seite 125
Kriterium 3.2.3
Ordnungsmäßigkeit Arbeitsabläufe
Arbeitsabläufe beziehungsweise Geschäftsprozesse und die eingebundenen ITMaßnahmen müssen bestimmte Verfahrensrichtlinien - beispielsweise nach GGO - einhalten. Diese Richtlinien ergänzen bestehende gesetzliche Regelungen (z. B. bezogen
auf Nachprüfbarkeit, Aktenmäßigkeit beziehungsweise Dokumentation). Das Kriterium
drückt aus, in welchem Umfang diese (internen) Richtlinien durch das vorhandene ITSystem eingehalten sind. Als Bewertungshilfe kann die Fehlerquote des Altsystems dienen.
Darüber hinaus gilt die Ordnungsmäßigkeit der Arbeitsabläufe auch als wesentliche Voraussetzung für die Reduktion von Korruption im Amt. Gewährleistet das bestehende
System die Ordnungsmäßigkeit der Arbeitsabläufe nicht, besteht Investitionsbedarf in ein
neues System, welches die Ordnungsmäßigkeit wiederherzustellen vermag und so möglichen Missbrauch begrenzt.
3.2.3 Ordnungsmäßigkeit der Arbeitsabläufe
0
2
4
6
8
10
nicht von Bedeutung
Kleine Beeinträchtigungen
Ordnungsmäßigkeit gegeben, aber aufwendiges Verfahren
Ordnungsmäßigkeit zeitweise beeinträchtigt und aufwendiges Verfahren
Ordnungsmäßigkeit dauerhaft beeinträchtigt und aufwendiges Verfahren
Ordnungsmäßigkeit nicht
gegeben
Tabelle 23: Punktbewertungsskala Ordnungsmäßigkeit der Arbeitsabläufe
Kriterium 3.2.3
Erfüllung von Auflagen und Empfehlungen
Weiterhin von Bedeutung ist auch die Bewertung, ob und beziehungsweise in welchem
Umfang derzeit lizenzkonformes Arbeiten in der Behörde sichergestellt ist: so unterliegt
beispielsweise proprietäre Software Lizenz- beziehungsweise Nutzungseinschränkungen, die je nach Produkt beziehungsweise Vertragsbedingungen unterschiedlich ausfallen und deren Einhaltung besondere Sorgfalt erfordert.
3.2.4 Erfüllung sonstiger Auflagen und Empfehlungen
0
2
4
6
keine Abweichungen
geringe, nicht
substanziellen
Abweichungen
geringe Abweichungen, sind
aber auch ohne
Neusystem zu
beheben
zahlreiche Abweichungen
8
Verfahren inVerfahren wisgesamt verderspricht konkbesserungsbe- reten Auflagen
dürftig, da subs- oder Empfehtanzielle Abweilungen
chungen
vorhanden
Tabelle 24: Punktbewertungsskala Erfüllung von Auflagen und Empfehlungen
Seite 126
10
5.3.2
Qualitativ-strategische Kriterien
In dieser Gruppe des Kriterienkataloges sind die qualitativ-strategischen Kriterien von ITMaßnahmen aufgeführt. Sie beziehen sich auf die Priorität der IT-Maßnahme, auf behördeninterne Qualitätsverbesserungen und auf die Wirkung auf Mitarbeiter der öffentlichen Verwaltung. Wie in der WiBe D, werden auch in der WiBe Q die Kriterien qualitativ
in einer Punkteskala mit Begründung bewertet.
Kriteriengruppe 4.1
Kriterium 4.1.1
Priorität der IT-Maßnahme
Bedeutung innerhalb IT- Rahmenkonzept
Mit diesem Kriterium wird die IT-Maßnahme qualitativ eingeordnet hinsichtlich ihres Beitrages zur Verwirklichung des geltenden IT-Rahmenkonzeptes (und zwar letztlich im
Vergleich zu anderen laufenden beziehungsweise geplanten IT-Maßnahmen). Die Bedeutung der IT-Maßnahme als Voraussetzung für andere, folgende Maßnahmen ist zu
begründen.
Dieses Kriterium ist ein „Quasi-MUSS-Kriterium“: wenn hier die Bewertung „10
Punkte― vorzunehmen ist, muss die IT-Maßnahme grundsätzlich durchgeführt werden.
Eine solche Bewertung setzt voraus, dass die betroffene IT-Maßnahme unabdingbare
Voraussetzung für die Realisierung eines Großteils der Planungen des ITRahmenkonzeptes darstellt. Daraus folgt, dass nur wenige IT-Maßnahmen einer Behörde die Punktzahl 10 erzielen können und zwar nur jene IT-Maßnahmen mit höchster Priorität. Es empfiehlt sich daher, alle IT-Maßnahmen einer Behörde zu priorisieren und dies als Grundlage für die Begründung der Punktvergabe in diesem Kriterium
zu verwenden.
4.1.1 Bedeutung innerhalb des IT-Rahmenkonzeptes
0
2
4
6
8
10
nicht von Bedeutung
untergeordnete
Bedeutung
wichtige ITMaßnahme,
zeitlich nicht
dringend
Realisation ist
Vorbedingung
für weitere
wichtige ITMaßnahmen
bedeutendes
zeitkritische ITMaßnahme
Schlüsselstellung im ITRahmenkonzept
Tabelle 25: Punktbewertungsskala Bedeutung innerhalb IT- Rahmenkonzept
Kriterium 4.1.2
samt
Einpassung in den IT-Ausbau der Bundesverwaltung insge-
Mit diesem Kriterium ist zu bewerten, ob sich die IT-Maßnahme in die Informationsmanagement-Strategie der Bundesregierung einpasst, das heißt, die behördenübergreifende Bedeutung der IT-Maßnahme ist hier auszuformulieren: hier sind alle Überlegungen
einzubringen, die auf einen gemeinsamen (integrativen, standardsetzenden beziehungsweise standardgemäßen) Ausbau der Informationstechnik abzielen.
Seite 127
4.1.2 Einpassung in den IT-Ausbau
0
2
4
6
8
10
nicht von Bedeutung beziehungsweise
keine positive
Auswirkung
geringfügige
Förderung des
IT-Ausbaus
weitergehende
Förderung des
IT-Ausbaus
IT-Maßnahme
ist wichtig, aber
nicht zeitkritisch
IT-Maßnahme
ist wichtig und
zeitkritisch
IT-Maßnahme
ist zwingend für
die ITIntegration in
der Bundesverwaltung
Tabelle 26: Punktbewertungsskala Einpassung in den IT-Ausbau der Bundesverwaltung
insgesamt
Kriterium 4.1.3
Folgewirkung für Kommunikationspartner
Mit diesem Kriterium wird die behördenübergreifende Verknüpfbarkeit (Interoperabilität)
der IT-Maßnahme bewertet. Der Einstieg in OSS-Lösungen kann andere Standardformate für den Datenaustausch erbringen beziehungsweise andere Aufbereitungsmechanismen für die Weiterverwendung erforderlich machen. Dieser Effekt kann innerhalb eines
Ressorts (speziell im Verhältnis Ministerium zu Geschäftsbereich), aber auch zwischen
Ressorts bedeutsam sein. Je unmerklicher dabei die Folgewirkungen für andere Kommunikationspartner (auch außerhalb der öffentlichen Verwaltung) sind, desto höher ist
die Qualität der Lösung zu bewerten.
Des Weiteren sind unter diesem Kriterium auch Wirkungen auf Dritte außerhalb der eigenen Verwaltung (Bürger, Unternehmen, andere Verwaltungen) zu fassen. So ist z. B.
darauf zu achten, dass Bürger, Unternehmen und andere Verwaltungen bei der Nutzung
von Online-Dienstleistungen nicht zum Erwerb bestimmter Softwareprodukte (Browser,
Textverarbeitungsprogramme) gezwungen werden. Ist der Zugang zu solchen Onlineangeboten nur mit einer bestimmten (kostenpflichtigen) Software möglich, würde dies die
Akzeptanz bei diesen Dritten und damit mögliche Synergieeffekte in der eigenen Verwaltung verringern.
4.1.3 Folgewirkungen für den Kommunikationspartner
0
2
keine positiven
Wirkungen
behördenübergreifend
keine für den
Anwender
merkbaren
Verbesserungen im
Informationsaustausch
zu erwarten
4
6
punktuelle Vererhebliche
besserungen im Verbesserung
behördenbezogen auf
übergreifenden
einen VorInformations- gangstypus sind
austausch zu
erreichbar
erwarten
8
10
erhebliche
Verbesserung
bezogen auf
mehrere Vorgangstypen
sind
erreichbar
erhebliche
Verbesserung
durch behördenübergreifende Vereinheitlichung von
Datenstrukturen
und Verfahrensroutinen
Tabelle 27: Punktbewertungsskala Folgewirkung für Kommunikationspartner
Seite 128
Kriterium 4.1.4
Pilot-Projekt-Charakter des IT-Investitionsvorhabens
Die erstmalige Entwicklung und der Einsatz innovativer Verfahren im Rahmen von Migrationsprojekten können für die investierende Verwaltungseinheit im Sinne der W iBe KN
monetär unwirtschaftlich sein. Gleichzeitig kann dieses Verfahren aber für Folgevorhaben wichtige Erkenntnisse liefern, welche zu Einsparungen von Entwicklungskosten in
anderen Verwaltungseinheiten führen. Im Idealfall sollten die entwickelten Migrationsverfahren und –lösungen auf andere Verwaltungseinheiten des Bundes übertragbar sein
(Einer für Alle – Prinzip).95
Im Mittelpunkt dieses Kriteriums steht sowohl der Pilotierungscharakter des Migrationsprojektes, als auch die Nachnutzbarkeit der gesamten Projektergebnisse für Dritte.
Im Folgenden sind einige Kriterien gelistet, welche zeigen, ob die Ergebnisse der Migrationsmaßnahme für eine Nachnutzung durch andere Projekte aufbereitet wurden beziehungsweise geeignet sind:

Güte und Umfang der Ergebnisdokumentation,

Projektaufbau und –vorgehensweise (bspw. nach V-Modell),

Grad der erforderlichen Modifikationen (Anpassungsaufwand),

Möglichkeiten zur Kooperationen bei Implementierung und Weiterentwicklung.
Der strategische Rang ist umso höher zu bewerten: je weiter und flächendeckender das
Einsatzspektrum der innovativen Lösung in der Bundesverwaltung anzusetzen und je
schlüssiger das Nachnutzungskonzept einer Migrationsmaßnahme ist.
4.1.4 Pilot-Projekt-Charakter der IT-Maßnahme
0
2
nicht von Bedeutung
Ersteinsatz
einer Standardlösung
4
6
Ersteinsatz
behördenintereiner Eigenent- nes Pilotprojekt,
wicklung, weite- keine Standardre Ausbaustulösung, Folgefen geplant
investitionen
8
10
Pilotprojekt mit
weiteren Einsatzfeldern
behördenübergreifend
Pilotprojekt mit
flächendeckender Einsatzabsicht behördenübergreifend
(Einer für Alle
- Prinzip)
Tabelle 28: Punktbewertungsskala Pilot-Projekt-Charakter des IT-Investitionsvorhabens
Kriterium 4.1.5
Nachnutzung bereits vorhandener Technologien
Dieses Kriterium bewertet, ob in der geplanten IT-Maßnahme technische Lösungen (Verfahren) zum Einsatz kommen, die sich bereits in anderen Verwaltungseinheiten des
Bundes bewährt haben. Die Nachnutzung bereits vorhandener technischer Lösungen
wirkt sich zumeist nicht nur minimierend auf die Höhe der Investitionskosten aus, son-
95
Die Nachnutzung von Projektergebnissen für vergleichbare Projekte ist ein Ziel öffentlicher
Investition (sie hierzu insbesondere die Kieler Beschlüsse).
Seite 129
dern bewirkt darüber hinaus, dass sich innerhalb der Verwaltung technologische Standards etablieren und somit Insellösungen vermieden werden.
Achtung: Monetär bewertbare Ansätze der Nachnutzung bereits vorhandener Technologie werden bereits in der WiBe KN bewertet. Es gilt in diesem Kriterium Aspekte zu erfassen, die nur qualitativ bewertbar sind.
4.1.5 Nachnutzung bereits vorhandener Technologien
0
2
4
6
8
10
Übernahme
eines Verfahrens nicht möglich
Übernahme
eines Verfahrens: großer
Anpassungsaufwand,
besitzt geringe
Verbreitung
Übernahme
eines Verfahrens: mittlerer
Anpassungsaufwand, besitzt
geringe Verbreitung
Übernahme
eines Verfahrens: geringer
Anpassungsaufwand,
besitzt geringe
Verbreitung
Übernahme
eines Verfahrens: mittlerer
Anpassungsaufwand,
besitzt große
Verbreitung
Übernahme
eines Verfahrens: geringer
Anpassungsaufwand, besitzt
große Verbreitung
Tabelle 29: Punktbewertungsskala Nachnutzung bereits vorhandener Technologien
Kriterium 4.1.6
Plattform-/Herstellerunabhängigkeit
Mit diesem Kriterium bewerten Sie, inwieweit die angestrebte Lösung es erlaubt, (auch)
künftig einerseits auf unterschiedlichen Plattformen eingesetzt werden zu können und
andererseits weitere Ausbaustufen der IT-Architektur96 möglichst frei und ohne Vorgaben
des Hard- oder Softwareherstellers bzw. bestehender oder zukünftig geplanter Plattformen gestalten und auf verschiedene Anbieter zurückgreifen zu können.
Plattformunabhängige Lösungen stellen sich mit Blick auf die Einführung aus monetärer
Sicht häufig weniger günstig dar als vergleichbare Lösungen, die auf proprietäre Plattformen festgelegt sind. Plattformunabhängigkeit bezieht sich dabei auf unterschiedliche
Typen von Plattformen:.
 Hardware
 Betriebssystem
 Infrastruktursoftware (z.B. Datenbank Management System)
 Standardsoftware (z.B. Officeanwendungen)
 Entwicklungsplattformen
Plattformunabhängigkeit verfolgt eher einen (mittel- bis) langfristigen strategischen Ansatz. Mit plattformunabhängigen Lösungen kann sowohl der Produktlebenszyklus als
auch die Einsatzdauer verlängert werden. Damit überwiegen dann die wirtschaftlichen
Vorteile einer plattformunabhängigen Lösung in der Zukunft, wenn einerseits eine Überarbeitung oder gar der Austausch der Lösung nicht mehr nur durch den Austausch einer
Plattform notwendig wird und andererseits die Plattform bei Bedarf (z.B. aus wirtschaftli-
96
Architektur einer Behörde über die Gesamtheit ihrer Anwendungen.
Seite 130
chen Gründen) ausgewechselt werden kann, ohne dass gleichzeitig alle darauf aufsetzenden Lösungen ausgewechselt werden müssen.
Umso geringer der Aufwand ist, mit dem eine Lösung zwischen Plattformen gewechselt
werden kann, desto höher der Grad der Plattformunabhängigkeit und in der Regel auch
höher der Grad der Herstellerunabhängigkeit (sofern es unterschiedliche Anbieter von
Plattformen gibt).
4.1.6 Plattform-/Herstellerunabhängigkeit
0
2
4
6
Nicht von BeGeringfügige
Software kann
deutung bzw.
qualitative Ver- mit geringfügikeine ersichtlibesserungen
gem Aufwand
chen Wirkungen ohne strategiauf andere
zu erwarten
sches Gewicht
Plattformen
(z.B. Lösung
portiert werden.
steht in mehreVorhandene
ren Versionen Hardware/ Perifür unterschiedpherie kann
liche Plattforauch weiterhin
men zur Verfü- in den geplangung (Pseudoten Fristen
unabhängigeingesetzt werkeit))
den.
8
Plattform-/
Plattform-/
Herstellerunab- Herstellerunabhängigkeit ist
hängigkeit und
gewährleistet
Investitionsund die angestschutz sind
rebte Lösung
gewährleistet,
trägt zur Erwei- Vorgaben aus
terung der Ausder IT-Archi97
und Umbauop- tektur werden
tionen bei.
eingehalten.
10
Weitgehende
Gestaltungsautonomie verbunden mit der
Weiternutzung
vorhandener
Hard- und Software.
Tabelle 30: Punktbewertungsskala Plattform-/Herstellerunabhängigkeit
Kriteriengruppe 4.2
Qualitätszuwachs bei Erledigung von Fachaufgaben
Kriterium 4.2.1
Qualitätsverbesserung bei der Aufgabenabwicklung (Leistungssteigerung bei …)
In diesem Kriterium werden die qualitativen Wirkungen, bezogen auf die Aufgabenabwicklung, bewertet. Insbesondere, ob der Arbeitsprozess als solcher und somit auch das
Produkt an Qualität gewinnt. Zu beurteilende qualitative Verbesserungen können bspw.:
eine Vereinfachung der behördeninternen Arbeitsabläufe sowie die Entlastung von Doppel- und Routinearbeiten sein. Aber auch aktuellere, redundanzfreiere und vollständigere
Informationsquellen und eine geringere Fehlerquote durch interaktive Hilfefunktionen zur
Anwenderunterstützung sind Beispiele für eine Bewertung. IT-Maßnahmen können weiterhin bei komplizierten Vorgängen hohe Qualitätsstandards (z. B. ein Qualitätsmanagement nach der ISO 9001 oder dem EFQM-Modell) einhalten/beachten helfen.
Die Neuentwicklung von Fachanwendungen, die beispielsweise bei einer Umstellung auf
OSS-Lösungen notwendig sein wird, kann so gleichzeitig einen Qualitätssprung in der
Aufgabenabwicklung durch den Anwender möglich machen.
97
Interne Vorgaben einer Behörde zur Umsetzung ihrer Architektur, Festlegung von Standards, Technologien, Schnittstellen usw.
Seite 131
Bei der Bewertung dieses Kriteriums sollte auf die Trennung der Wirkungen in Bezug auf
formale (die Aufgabenabwicklung selbst verbessert sich) und materielle (das Ergebnis
der Aufgabenabwicklung verbessert sich) Verbesserungen geachtet werden.
4.2.1 Qualitätsverbesserung bei der Aufgabenabwicklung
0
2
4
6
8
10
keine positiven
Wirkungen
geringe Verbesserung des
formalen Arbeitsablaufs
mittlere
Verbesserung
hinsichtlich
des formalen
Arbeitsablaufs
erhebliche
Verbesserungen des formalen Arbeitsablaufs
erhebliche
Verbesserung
des materiellen
Arbeitsergebnisses
erhebliche
Verbesserung
des formalen
Arbeitsablaufs
und des materiellen Arbeitsergebnisses
Tabelle 31: Punktbewertungsskala Qualitätsverbesserung bei der Aufgabenabwicklung
Kriterium 4.2.2
Beschleunigung von Arbeitsabläufen und -prozessen
IT-Maßnahmen bewirken in der Regel eine qualitative Verbesserung der Aufgabenabwicklung in Form einer Beschleunigung der Arbeitsabläufe und -prozesse. Diese Effekte
sind, soweit sie sich als kürzere Bearbeitungszeit berechnen lassen, bereits unter den
laufenden Betriebsnutzen monetär in der WiBe KN erfasst.
Die Beschleunigung von Arbeitsabläufen und -prozessen ermöglicht eine Senkung der
Durchlaufzeit. Die Wirkungen entstehen durch elektronische Kommunikation, den Abbau
von Medienbrüchen, den Zugriff auf aktuelle und allen Berechtigten zugängliche Datenbanken bis hin zum Wegfall einzelner Bearbeitungsstationen. Aktuellere, präzisere
Kommunikationsformen verringern die Transport-, die Liege- und die Rüstzeiten.
Die Einschätzung des qualitativen Kriteriums ergibt sich aus einer kritischen Bewertung
der Verbesserungen, welche die IT-Maßnahmen dem amtsinternen Anwender bieten
wird.
4.2.2 Beschleunigung von Arbeitsabläufen und –prozessen
0
2
4
6
8
10
keine positiven
Wirkungen
geringe Beschleunigung zu
erwarten, aber
Effekte nicht
einschätzbar
Verkürzung bis
zu 10% der
bisherigen
Durchlaufzeit
möglich
Verkürzung bis
zu 30% der
bisherigen
Durchlaufzeit
möglich
Verkürzung bis
zu 50% der
bisherigen
Durchlaufzeit
möglich
Verkürzung
mehr als 70%
der bisherigen
Durchlaufzeit
möglich
Tabelle 32: Punktbewertungsskala Beschleunigung von Arbeitsabläufen und -prozessen
Kriterium 4.2.3
Einheitliches Verwaltungshandeln
Das Kriterium stellt darauf ab, inwieweit durch die neue IT-Maßnahme bislang unterschiedliche Vorgangsbearbeitungen (sowohl formal als auch materiell) zukünftig einheitSeite 132
lichen Standards folgen. Dies kann sich ergeben aus dem jeweils aktuellen Zugriff auf
gleich strukturierte Daten und durch die organisatorische und informationstechnische
Harmonisierung von Verwaltungsvorgängen. In jedem Fall ist bei diesem Kriterium die
Außenwirkung zu beachten (im Sinne von „wie wirkt das Verfahren auf unterschiedliche
externe Adressaten?―).
4.2.3 Einheitliches Verwaltungshandeln
0
2
4
6
keine positiven
Wirkungen
keine spürbare
Reduzierung
von Sonderfällen zu erwarten
punktuelle Verbesserung
behördenintern
erhebliche
Verbesserung
bezogen auf
einen Vorgangstypus
8
10
erhebliche
erhebliche
Verbesserung
Verbesserung
durch behördurch behördeninterne
denübergreiVereinheitlifende Vereinchung von
heitlichung von
Datenstrukturen Datenstrukturen
und Verfahrens- und Verfahren
routinen
Tabelle 33: Punktbewertungsskala Einheitliches Verwaltungshandeln
Kriterium 4.2.4
Erhöhung von Verständlichkeit und Nachvollziehbarkeit
Dieses Kriterium bewertet den Beitrag der IT-Lösung zur Erhöhung der Verständlichkeit
und Nachvollziehbarkeit sowohl für interne als auch externe Adressaten. Ein wesentlicher Aspekt kann z. B. die Informationsbereitstellung, die Informationsvermittlung sowie
die Transparenz von (Management)-Entscheidungen sein.
4.2.4 Erhöhung von Verständlichkeit und Nachvollziehbarkeit
0
2
keine positiven
Wirkungen
4
6
nur geringfügige verschiedene,
Änderung zum kleinere Mängel
derzeitigen Istbehoben
Zustand
wesentliche
bisherige Mängel
abgestellt
8
10
qualitativ unmit- qualitativ unmittelbar ersichtlitelbar ersichtliche Erhöhung
che, bedeutsafür einzelne
me Erhöhung
Adressaten
für zahlreiche
Adressaten
Tabelle 34: Punktbewertungsskala Verständlichkeit und Nachvollziehbarkeit
Kriterium 4.2.5
Imageverbesserung
Das Image der öffentlichen Verwaltung ist in manchen Bereichen eher negativ geprägt
(„Bürokratie―). Eine Imageverbesserung kann erfolgen durch verbesserte Dienstleistungen (wie oben bewertet) und durch eine wirksamere Vermittlung dieser Leistungssteigerungen an die externen Adressaten. Soweit die IT-Maßnahme dazu (trotz aller subjektiven Einschätzung und vieler Unwägbarkeiten) einen positiven Beitrag leisten kann, ist
dieser Effekt hier einzubringen.
Seite 133
4.2.5 Imageverbesserung
0
2
keine positiven
Wirkungen
4
6
8
10
Kurzfristig keine
positive Wirpositive Wirnachhaltig posi- nachhaltig posiwahrnehmbare kung bei einzel- kung mittelfristig tive Wirkung bei tive Wirkung bei
Änderung
nen Adressaten bei vielen Adeinigen Adres- vielen Adressazu erwarten
ressaten
saten
ten
Tabelle 35: Punktbewertungsskala Imageverbesserung
Kriteriengruppe 4.3
Kriterium 4.3.1
Mitarbeiterbezogene Effekte
Attraktivität der Arbeitsbedingungen
Die Einführung neuer IT-Lösungen verändert regelmäßig bisherige Arbeitsabläufe und ist
auch mit dem Einsatz neuer Hard- und Software verbunden. Dies steigert für den Anwender gegebenenfalls die (subjektiv erlebte) Attraktivität seines Arbeitsplatzes, was
auch durch eine höhere Qualifikation via Einsatz moderner Technik erreicht werden
kann. Eine positive Beeinflussung der Arbeitsplatz-Attraktivität wird sich tendenziell fördernd auf die Arbeitszufriedenheit und damit auch auf die Produktivität auswirken.
Bei OSS-Lösungen im Client-Bereich ist dieses Kriterium zu prüfen. Der Umstieg auf
eine neue, andersartige Arbeitsoberfläche kann im ungünstigen Fall zur Verunsicherung
und zu Ängsten bis hin zu Widerständen führen. Diesen hinlänglich bekannten Effekten,
die sich aus der Einführung von Neuerungen ergeben können, stehen andererseits positive Wirkungen gegenüber: OSS-Lösungen erlauben dem Anwender auch die Nutzung
im privaten Bereich ohne rechtliche und steuerliche Probleme - dies trägt zur Attraktivität
der Arbeitsbedingungen bei.
4.3.1 Attraktivität der Arbeitsbedingungen
0
2
nicht verbessert/ ist nicht
von Bedeutung
leichte Verbesserung
4
6
mittlere Verbes- mittlere Verbesserung in weni- serung in mehgen Bereichen reren Bereichen
8
10
erhebliche
Verbesserung
in wenigen
Bereichen
erhebliche
Verbesserung
in mehreren
Bereichen
Tabelle 36: Punktbewertungsskala Attraktivität der Arbeitsbedingungen
Kriterium 4.3.2
Qualifikationssicherung/ -erweiterung
Die Einführung neuer IT-Lösungen kann (mittelfristig) die Qualifikation der betroffenen
Mitarbeiter in zweierlei Weise beeinflussen. Einerseits führen IT-Lösungen zum Erwerb
von Fertigkeiten im Umgang mit IT-Systemen: die Einführung solcher Lösungen trägt
dann zur indirekten Qualifikationserweiterung der Anwender bei. Andererseits kann mit
dem Einsatz neuer IT-Lösungen auch die Übernahme anspruchsvollerer, umfassenderer
Seite 134
Aufgabenbereiche verbunden sein. Zusammen mit der Anwenderschulung resultiert daraus eine Qualifikationserweiterung im direkten fachlichen Aufgabenbereich.
4.3.2 Qualifikationssicherung/-erweiterung
0
2
4
nicht beeinflusst
Geringe
Erhebliche
beziehungswei- Effekte hinsich- Effekte bei ITse keine
tlich ITHandhabung zu
positiven
Handhabung zu
erwarten
Wirkungen
erwarten
6
8
10
erhebliche
Effekte bei ITHandhabung
und aufgabenbezogene Weiterentwicklung
deutliche Erweiterung der aufgabenbezogenen Qualifikation
Erhebliche
fachbezogene
Höherqualifikation
Tabelle 37: Punktbewertungsskala Qualifikationssicherung/ -erweiterung
6
Fazit
Es sei abschließend an dieser Stelle darauf hingewiesen, dass sich pauschale Empfehlungen für das eine oder andere Migrationsszenario aus der hier vorgestellten Methodik
der Wirtschaftlichkeitsbetrachtung nicht belastbar ableiten lassen. Die Praxis zeigt sehr
unterschiedliche Anforderungen bei vermeintlich gleichen Ausgangsbedingungen, sodass allgemein verbindliche Aussagen hier keinen Sinn machen.
Es ergibt sich also die Notwendigkeit, jedes Migrationsprojekt nach den vorgeschlagenen Methodiken zu planen und die Wirtschaftlichkeit entsprechend zu berechnen.
Die im Kapitel 5.1.1 „Aufbau und Vorgehensweise der WiBe für Migrationen― erläuterte
Vorgehensweise bei Migrationen und insbesondere auf die "Vorgehensweise im Rahmen der monetären und nicht monetären WiBe" (Kapitel I.C 5.1.1.3) gibt dem Anwender
einen Einstieg in die Vorüberlegungen zur Wirtschaftlichkeitsbetrachtung für Migrationen.
Hierbei handelt es sich um:

Fragen zur Ist-Situation
Hiermit wird die Ausgangssituation für die Migration beurteilt. Anhand der dort
aufgeführten Fragen wird ein konkreter Handlungsbedarf abgeleitet, der in eine
Migration münden kann, für die eine WiBe zu erstellen ist. Mit der kommentierten
und dokumentierten Beantwortung dieser Fragen wird eine solide Basis für die
Begründung der Migration gelegt (Beantwortung der Frage: „Warum soll migriert
werden?―).

Fragen zur Soll-Situation
Mit diesen Fragestellungen können die gewählten Migrationsalternativen schon
im Vorfeld verifiziert werden. Die fokussierte Migrationsalternative ist hinreichend
zu kommentieren und begründen. Damit entsteht eine Dokumentation, die wiederum die Grundlage für die Begründung der Migrationsalternative liefert (Beantwortung der Frage: „Wohin soll migriert werden?―).
Seite 135

Rahmenbedingungen
Diese Informationen helfen, den Rahmen abzustecken und gewisse Aktivitäten
schon im Vorfeld entsprechend zu kanalisieren (z. B. Prozessanalyse in eigenständigem Projekt).
Hat der Anwender mit den oben aufgeführten Aktivitäten seinen Migrationsbedarf und
die Migrationsalternative verifiziert, kann er die Wirtschaftlichkeitsbetrachtung erstellen.
Dazu empfiehlt sich eine schrittweise Vorgehensweise, die sich an folgenden Kapiteln
ausrichtet:

Grundsätzliche Überlegungen zur Kostenerhebung (Kapitel I.C 3.3)
Hier werden Informationen gegeben zu möglichen Migrationsphasen, dem Personalbedarf bei der Migration sowie der Eruierung der Soft- und Hardwarekosten.
Diese stellen die Grundlage dar für die spätere Berechnung der Personal- und
Technikkosten für den Migrationsprozess und den anschließenden Betrieb des
migrierten Szenarios.

Analyse der Ausgangssituation (Kapitel I.C 4)
Zur Abschätzung der mengenmäßigen Aufwände ist eine Erhebung der IstSituation des zu migrierenden Szenarios erforderlich. Die Mengen helfen später
die neue Soll-Situation zum einen kostenmäßig einzuschätzen und zum anderen
erzielbare Ersparnisse oder Optimierungen zu lokalisieren.

Monetäre Wirtschaftlichkeit (Kapitel I.C 5.2)
Hier erfolgt nun die eigentliche Berechnung der Wirtschaftlichkeit. Im monetären
Bereich werden über die Bereiche der Einführung (also das Migrationsprojekt
selbst) und den Betrieb Kennzahlen für Kosten und Nutzen ermittelt. Eine positive Kennzahl an dieser Stelle ergibt schon einen sehr hohen Befürwortungsfaktor
für die Migration.

Erweiterte Wirtschaftlichkeit (Kapitel. I.C 3.3)
Mit der erweiterten Wirtschaftlichkeit werden die qualitativen Faktoren bewertet.
Dies geschieht mit Nutzwertanalysen, in denen ein ähnlicher Fragenkatalog wie
im Kap. 1.4.1 abgebildet zu bearbeiten ist. Als Ergebnis werden zwei quantifizierte Kennzahlen errechnet, die mit jeweiligen hohen Werten die Migration ersatzweise zur monetären Kennzahl befürworten (niedrige Werte sollten sich aufgrund
der in den Vorüberlegungen getroffenen Entscheidungen nicht mehr einstellen).
Seite 136
D Thema: Empfehlungen
Die nachfolgenden Empfehlungen zur Migration von Software (von der Entscheidung bis
zum Betrieb) enthalten zunächst einige allgemeine und grundsätzliche Empfehlungen,
die sich aus den im Leitfaden betrachteten Weiterentwicklungen am Softwaremarkt ergeben. Empfehlungen, die schon in Vorgängerversionen gegeben wurden und die nach
wie vor Bestand haben, werden auch weiterhin nachfolgend beschrieben. Hierzu gehören unter anderem die empfohlenen Vorgehensmodelle, nach denen Migrationen durchgeführt werden können sowie deren bedarfsgerechten Verwendungsmöglichkeiten. Ergänzend benennen die Autoren des Leitfadens die aus ihrer Sicht wesentlichen Punkte,
die für eine erfolgreiche Durchführung von Migrationsprojekten wichtig sind.
1
Grundsätzliche Empfehlungen
An den grundsätzlichen Empfehlungen des Migrationsleitfadens hat sich seit der ersten
Version nichts geändert. Es ist vielmehr so, dass die Gültigkeit der zu Beginn ausgesprochenen Empfehlungen heute noch sehr viel stärker zu unterstreichen ist.
Die Machbarkeit eines Wechsels von proprietären Lösungen hin zu OSS-basierten Lösungen, sei es punktuell oder vollständig, ist noch viel deutlicher gegeben, als dies
schon bei der Veröffentlichung des ersten Migrationsleitfadens der Fall war. Unterstützt
wird dies durch eine weiter gestiegene Produktvielfalt, insbesondere bei den quelloffenen Lösungen und einer weitergehenden Anpassung des Funktionsumfangs an proprietäre Lösungen.
Insbesondere (jedoch nicht ausschließlich) hat durch die Verabschiedung und laufende
Fortschreibung von SAGA mit der verwaltungseigenen Hausstandardisierung die Investitionssicherheit für kommerzielle Anbieter von Linux- und Open Source Software
kontinuierlich zugenommen. Dies spiegelt sich in dem gewachsenen Softwareangebot
wider.
Daneben zeigt die zunehmende Abkehr von proprietären Schnittstellen, Formaten, Protokollen und die ständig wachsende Nutzung von Standards bei den Anbietern proprietärer Software, dass die Forderungen nach mehr Offenheit und die Verwendung von Standards durch maßgebliche Stellen in der öffentlichen Verwaltung und eine Reihe von ITUnternehmen ihre Wirkung zeigen und der richtige Weg sind. Diesen Forderungen sollten sich die gesamte öffentliche Verwaltung und auch die Wirtschaft anschließen, damit
Interoperabilität und Kommunikationsfähigkeit verbessert sowie die Kosten für den ITEinsatz minimiert werden können. Denn es gilt unbestritten, dass mit einem wachsenden
Grad der Standardisierung auf Basis von wirklicher offenen Standards die Wirtschaftlichkeit des Softwareeinsatzes gestärkt wird durch:

den einsetzenden beziehungsweise sich verstärkenden Wettbewerb von Produkten und Lösungen,

eine geringere Herstellerabhängigkeit und

einen insgesamt breiteren Dienstleistungsmarkt.
Allgemeingültige Aussagen zu Wirtschaftlichkeitsvorteilen der unterschiedlichen Plattform-Strategien (siehe Abschnitt I.D 2.1) können allerdings aufgrund der inzwischen
Seite 137
noch unterschiedlicheren Ausgangssituationen und Produktqualitäten nur selten getroffen werden. Es gilt jedoch, dass bis zu einem gewissen Punkt, wie aus den Betrachtungen im Abschnitt I.A 3 deutlich wird, mit wachsendem Grad der Integration der Produkte
einer Plattform die Wirtschaftlichkeit aus mehreren Gründen zunimmt:

Durch höhere Produktivität, bei gut (ohne Systembrüche) aufeinander abgestimmten Produkten.

Durch die wachsende Wiederverwendbarkeit von Komponenten und Lösungen,
die mit gleicher Middleware-Technologie entwickelt wurden.

Durch Einsparungen bei Vereinheitlichung von Beschaffungs- und Wartungsprozessen und gegebenenfalls -verträgen.
Hinsichtlich der Wirtschaftlichkeit der alternativen Ziele, Windows-basierte Plattform versus Linux-basierte Plattform, lässt sich festhalten, dass sich eine Umstellung auf eine
Linux-basierte Plattform heute mehr denn je als ökonomisch sinnvolle Variante gegenüber der Migration auf eine neue Microsoft-Version erweisen kann. Insbesondere der
Wegfall oder die Reduzierung von Lizenzkosten kann in mehreren Fällen zu direkten
(monetären) Einsparungen führen, beispielsweise bei:

serverseitiger Teilmigration, verbunden mit einer HW- und SW-Konsolidierung,
insbesondere wenn Linux-Know-how und Linux-Systeme bereits vorhanden sind
oder bei

clientseitiger Teilmigration von MS Office Produkten.
Dies wird zusätzlich durch die größere Nähe von Open Source Software zu Standards
und die ihr eigene Offenheit unterstützt. Insbesondere, wenn zur Beurteilung der Einsparungen die strategische Dimension herangezogen wird, auf die ausführlich im Thema
Wirtschaftlichkeit von Softwaremigrationen eingegangen wird.
Zusammenfassend können folgende Grundsatzempfehlungen formuliert werden:

Verankerung der Wirtschaftlichkeit als Leitbild der IT-Gesamtstrategie bei angemessener Berücksichtigung der Faktoren Innovation und Organisation.

Einsatz von offenen, von IT-Industrie und Open Source Community gleichermaßen ohne Einschränkung nutzbarer Standards als Grundlage zur Auswahl und Integration von Software-Produkten zur Vermeidung extremer Herstellerabhängigkeiten

Einbeziehung von Lösungen auf Basis von Open Source Software in die projektbezogenen Wirtschaftlichkeitsbetrachtungen im Rahmen der Migrationsentscheidung. (siehe hierzu Kapitel I.C)

Auch der Einsatz des Betriebssystems Linux als Basis der IT-Plattform ist für alle
Anwendungsbereiche machbar und kann wirtschaftlich sein.

Berücksichtigung der vorangegangenen Grundsatzempfehlungen bei der Entscheidungsfindung für Migrationsvorhaben (siehe I.D 2.1).
Auch wenn die Grundsatzempfehlungen nicht die Anforderungen und Rahmenbedingungen einer konkreten Ausgangssituation berücksichtigen können, soll an dieser Stelle auf
detaillierte Empfehlungen unter Berücksichtigung unterschiedlicher Szenarien verzichtet
Seite 138
werden. Diese können aufgrund der gewachsenen Vielfalt an unterschiedlichen Ausgangsszenarien und Produkten und Lösungen nur beispielhaft und punktuell sein und
versperren womöglich den Blick auf die große Vielfalt an Möglichkeiten. Dafür werden
konkretere Einsatzempfehlungen innerhalb der Module II, „Modul Infrastrukturen― und III,
„Modul Anwendungen―, zu den betrachteten Produkten, Technologien und Migrationspfaden gegeben, dort wo dies sinnvoll ist.
Weiterhin beinhalten die beiden nachfolgenden Themen „Rechtliche Aspekte von Softwaremigrationen― und „Wirtschaftlichkeitsbetrachtung von Softwaremigrationen― themenbezogene Hinweise und Empfehlungen.
2
Vorgehensempfehlungen für Migrationsprojekte
In den folgenden Abschnitten werden unterschiedliche Vorgehensmodelle zur Durchführung von Migrationen und Migrationsprojekten betrachtet.
Migrationsprojekte sind in der Regel komplexe und vielschichtige Vorhaben. Dies betrifft
sowohl vollständige Migrationen, das heißt die Migration der gesamten IT-Infrastruktur
(Client- und Serverbereich) als auch Migrationen in Teilen, also die Migration eines klar
abgegrenzten Bereiches der IT-Infrastruktur, zum Beispiel nur die Server, nur die Clients
oder auch nur eine einzelne Anwendung. Im letzten Fall spricht man auch gelegentlich
von punktueller Migration. Migrationsprojekte besitzen neben ihrer in der Regel vorhandenen Komplexität noch ein paar weitere Eigenschaften, auf die besondere Aufmerksamkeit gelegt werden sollte. Ansonsten ist ein Migrationsprojekt ein IT-Projekt wie jedes
andere und es sind die entsprechenden Aufgabenfelder zu bearbeiten.
Die nachfolgende Abbildung verdeutlicht einen typischen, mehrere Phasen umfassenden
Migrationsprozess mit seinen Teilaspekten. Die Abbildung zeigt deutlich, dass eine Migration wesentlich mehr als nur die Umstellung der verwendeten Produkte und Technologien beinhaltet.
PHASE 1
PHASE 2
Entscheidung
ProjektPlanung
AnwenderInformation
IstAnalyse
Feinkonzept
Realisierung
Tests
Systemintegration
Einführung
PHASE 3
Einf.-Schulung
Administratoren
Einf.-Schulung
Anwender
PHASE 4
Betrieb
Wartung
Support
Abbildung 22: Phasen eines Migrationsprozesses
Seite 139
Schulungen
Phase 1: Entscheidungsfindung
Ausschlaggebend für eine Migrations- oder Weiterentwicklungsempfehlung sind die Ergebnisse einer langfristig angelegten Wirtschaftlichkeitsbetrachtung. Auch wenn aus
technischer und juristischer Sicht der Weg für eine Komplett- oder Teilmigration ohne
Einschränkungen möglich und gegeben ist, können wirtschaftliche Überlegungen ihn
unter gegebenen Rahmenbedingungen als wenig sinnvoll erscheinen lassen. Aufgrund
vielfältiger Zusammenhänge zwischen den einzelnen Komponenten und Systemen einer
IT-Infrastruktur und der Anwendungswelt muss bei der Entscheidungsfindung daher
stets eine langfristige Perspektive (siehe Kapitel I.C 2, Einleitung zu den Wirtschaftlichkeitsbetrachtungen) beachtet werden.
Dabei unterscheidet sich die Betrachtung aus dem Blickwinkel der Einführung der Open
Source Software nicht von den üblichen Beurteilungsanalysen in der IT, beispielsweise
im Kontext der Hardware- oder Softwarekonsolidierung. Die üblicherweise in den Verwaltungen und der Wirtschaft gleichermaßen verfolgten Plattform-Strategien sind:

Auf Basis von offenen Standards und Spezifikationen eng aufeinander abgestimmte System- und Anwendungsplattformen, gegebenenfalls unter zusätzlichem Einsatz von spezialisierten Integrationsprodukten.

Auf Basis von herstellerspezifischen (nicht oder nur zum Teil offen gelegten
Schnittstellen und Spezifikationen), eng aufeinander abgestimmte System- und
Anwendungsplattformen, gegebenenfalls unter Einsatz von herstellereigenen Integrationsprodukten.

(historisch) Einsatz von Insel-Lösungen zur punktuellen Abdeckung von Fachverfahren und –anwendungen.
Da die Open Source Software von ihrem Ursprung her häufig mit dem Einsatz von
offenen Standards verbunden ist, bildet sie eine weitere besondere Variante hierzu.

Auf Basis von offenen Standards und Spezifikationen aufeinander abgestimmte
System- und Anwendungsplattformen mit Nutzung des offenen (wieder verwendbaren) Source Codes.
Während die Entscheidung zum punktuellen Einsatz eines weitverbreiteten quelloffenen
Produktes wie beispielsweise des Webservers Apache in der Regel sehr pragmatisch
und zügig entschieden werden kann, erfordert eine Entscheidung, beispielsweise zur
flächendeckenden Einführung von Open Source Software und Ablösung proprietärer
Inseln, aufgrund ihrer langfristigen Tragweite eine methodische Vorgehensweise. Deren
elementaren Meilensteine sind:

Erarbeitung einer IT-Gesamtstrategie unter Berücksichtigung der bestehenden finanziellen, organisatorischen, innovationsbedingten und personellen Zielsetzungen.

Definition der künftigen Open-Source-Plattform-Strategie unter Berücksichtigung
der langfristigen Wirtschaftlichkeitsberechnungen im Hinblick auf den Einsatz von
freien und proprietären Standardprodukten.

Festlegung aller zur Sicherstellung der internen und externen Wiederverwendbarkeit sowie Interoperabilität notwendigen Standards.
Seite 140

Auswahl der Produkte zur Abdeckung der Anforderungen.

Definition des Vorhabens mit dem dazugehörigen Zeit- und Aktionsplan sowie Sicherstellung der Haushaltsfinanzierung.
Bei diesem Prozess kann für die einzelnen Phasen auf bereits gängige Methoden und
Werkzeuge aus der öffentlichen Verwaltung zurückgegriffen werden, wie die nachfolgende Abbildung darstellt.
Strategie
Plattform
Standards
Produkte
Vorhaben
Migrationsleitfaden
IT-Strategie
E-Government 2.0
WiBe
IT-Architekturkonzept
Plattformunabhängigkeit
von Fachanwendungen
SAGA
WiBe
EVB-IT
UfAB
V-Modell
Abbildung 23: Entscheidungsprozess zur Durchführung einer Migration
Phase 2: Planung und Konzeption
Die Phase der Entscheidung liefert letztendlich die grundlegende Zielrichtung der Migration, die konkrete Ausgestaltung erfolgt dann in der Phase 2, der konkreten Planung und
Konzeption. Eine gute Planung und Vorbereitung der eigentlichen Migration ist um so
wichtiger, umso größer das Migrationsvorhaben ist. Dies gilt vor allem dann, wenn ein
großes Migrationsvorhaben auch noch in einem relativ kurzen, überschaubaren Zeitraum
durchgeführt werden soll. In einem solchen Fall ist der Fokus insbesondere auf die Anwender zu richten, da diese hiervon besonders stark belastet werden.
Je mehr Anwender von den Auswirkungen eines Migrationsprojektes betroffen sind und
je stärker sich diese Auswirkungen im täglichen Umgang mit der IT bemerkbar machen,
desto wichtiger ist eine frühzeitige aktive Einbeziehung und umfassende Information aller
relevanten Gruppen (siehe auch Abschnitt I.D 2.3, „Checkliste der Erfolgsfaktoren―).
Hierzu gehören neben den Anwendern und dem IT-Personal insbesondere auch die
Interessenvertreter, wie Personalvertretung, Sicherheitsbeauftragte, Datenschutzbeauftragte und so weiter. Diese sind zwar in der Regel bei jedem IT-Projekt zu beteiligen, bei
Migrationsprojekten und insbesondere, wenn es um eine Umstellung der gesamten ITInfrastruktur geht, ist es hilfreich, die relevanten Beteiligten mit im Boot zu haben, da sie
intensiv mit dazu beitragen können, die Akzeptanz bei den Anwendern zu verbessern.
Im Übergang von der Konzeption zur Implementierung stellen sich vor allem noch einmal
die Fragen nach der Wirtschaftlichkeit und in diesem Zusammenhang nach dem „Make
or Buy―. Auch hier spielt wiederum die IT-Strategie eine wichtige Rolle, die Aussagen
über Ziele der Personalentwicklung beim eigenen IT-Personal enthalten sollte und Vorgaben beinhalten, die eine Entscheidung an dieser Stelle deutlich vereinfachen. Solche
Vorgaben und Zielsetzungen können unter anderem sein, das IT-Personal für bestimmte
Plattformen auszubilden, Softwareentwicklung als eigene Aufgabe zu definieren oder
von vornherein auszuschließen.
Seite 141
Phase 3 und 4: Umsetzung und Betrieb
Die weiteren Phasen der Implementierung und des späteren Betriebs gestalten sich in
Migrationsprojekten nicht anders als in jedem anderen IT-Projekt.
2.1
Vorgehensmodelle
Insbesondere bei vollständigen Migrationen oder Migrationen von größeren Teilbereichen der IT-Infrastruktur lassen sich zwei unterschiedliche Wege bei einem Migrationsvorhaben beschreiten. Das eine ist der schnelle Weg, bei dem man ohne lange Umwege
und Pausen vom Ausgangspunkt zum Ziel gelangt. Man spricht auch oft vom „Big Bang―.
Der andere Weg ist eher ein sanfter, bei dem man sich Stück für Stück weiterbewegt und
sich immer mehr an die sich wechselnde Landschaft gewöhnt. Beide Wege der Migration
haben ihre Vor- und Nachteile.
In punktuellen Migrationen stellt sich meist nicht die Frage nach dem besten Weg, denn
es ist zum Beispiel nur selten sinnvoll eine Anwendung über einen längeren Zeitraum
und in mehreren Einzelschritten zu migrieren.
2.1.1
Schnelle Migration („Big Bang“)
Eine schnelle Migration ist nicht, wie der Name vermuten lässt, durch ihre Schnelligkeit
geprägt, sondern dadurch, dass die Migration innerhalb eines überschaubaren und vor
allem festgelegten Zeitraumes durchgeführt wird. Eine schnelle Migration hat einen def inierten Beginn (Anfangsdatum) und ein definiertes Ende (Enddatum). Am Ende steht der
Beginn des vollständigen Wirkbetriebes.
Die Durchführung einer schnellen Migration stellt hohe bis sogar sehr hohe Anforderungen an:

die Organisation des Projektes

die Organisation der betroffenen Behörde

die Technik

die Finanzen

die Administratoren

die Benutzer.
Insbesondere die Anforderungen an die Administratoren und die Benutzer dürfen dabei
nicht unterschätzt werden. Dies gilt umso mehr, je weniger Know-how bezüglich der
neuen IT-Landschaft bei den Administratoren und den Benutzern verfügbar ist. Andererseits besteht der Vorteil einer schnellen Migration darin, dass die Administratoren sich
nicht über einen längeren Zeitraum mit zwei unterschiedlichen IT-Ausrichtungen auseinandersetzen müssen. Sie können sich schon nach relativ kurzer Zeit (den Anforderungen des Projektes angemessen) ausschließlich auf die neuen Systeme konzentrieren.
Wichtig ist ferner, dass die benötigten Finanzen innerhalb eines relativ kurzen Zeitraumes verfügbar sein müssen. Umfang und vor allem die Komplexität und die Vielfalt der
zu migrierenden Anwendungen und Systeme bestimmen, wann und wie viel Finanzmittel
Seite 142
bereitzustellen sind. Dieser Aspekt wird am Ende mit über die Machbarkeit einer schnellen Migration entscheiden.
Die hohen Anforderungen an die Organisation der Behörde konzentrieren sich zum einen auf die Qualifizierung der Mitarbeiter, die weiterhin ihren täglichen Pflichten nachgehen müssen. Das heißt, dass Störungen des Betriebes der Behörde unbedingt minimiert
werden müssen. Zum anderen muss der laufende IT-Betrieb aufrecht erhalten bleiben.
Insbesondere eine Umstellung der gesamten Serverlandschaft stellt hier hohe Ansprüche an alle Beteiligten, da sich die Migration der einzelnen Serverdienste nicht beliebig
partitionieren lässt und die Administratoren den laufenden Betrieb garantieren und zugleich auf die neuen Systeme eingewiesen werden müssen.
Diese Anforderungen können durch geeignete Umstellungs- und Rollout-Konzepte gelöst werden. Auch der Aufbau einer parallelen IT-Landschaft hierfür ist möglich, wodurch
jedoch erhöhte Anforderungen an die Technik und letztlich zusätzliche Kosten entstehen.
Aufgrund dieser hohen Anforderungen stellt sich natürlich die Frage, ob eine schnelle
Migration überhaupt sinnvoll ist, beziehungsweise für wen zu empfehlen ist.
Gründe für eine schnelle Migration sind:

Es besteht der Zwang zu einer Migration, das heißt, dass zum Beispiel der Support für die alten Systeme ausläuft.

Die Administratoren und Benutzer werden zwar intensiv, dafür aber nur einmal
mit Neuerungen konfrontiert und nicht jährlich fortlaufend.

Die Administratoren müssen sich nicht über längere Zeiträume mit der Komplexität heterogener Welten auseinandersetzen.
Unter welchen Voraussetzungen und für wen ist eine schnelle Migration sinnvoll?
Liegt eine überschaubare und nicht übermäßig „verwobene― Systemlandschaft vor, ist
dies zunächst eine gute Voraussetzung für eine schnelle Migration. Dies ist der Fall,
wenn nur wenige Anwendungen und Dienste für die Aufgabenerfüllung eingesetzt werden.
Diese Voraussetzung trifft nicht immer nur auf kleine und einfach strukturierte Verwaltungen und Organisationen zu. Behörden und Organisationen egal wie groß, die mit wenigen großen, meist serverbasierten Fachanwendungen ausgestattet sind und mit denen
der überwiegende Teil der Aufgaben erledigt wird, sind gute Beispiele hierfür. Die Voraussetzungen treffen aber auch auf kleine bis mittlere Behörden mit wenigen Fachanwendungen, Standardbürokommunikation und Office-Einsatz mit wenig komplexen Dokumenten und Vorlagen zu.
Eine weitere gute Voraussetzung ist in den Behörden gegeben, die bereits über das
notwendige Know-how für die zukünftige IT-Landschaft bei den Administratoren verfügen. Sei es, dass diese sich in ihrer Freizeit mit diesen Systemen auseinandersetzen
oder bereits schon einzelne Anwendungen und Dienste mit neuer Technik vorhanden
sind. In diesem Zusammenhang kann auch wieder eine rechtzeitig festgelegte Strategie
dafür Sorge getragen haben, dass die IT-Mitarbeiter rechtzeitig auf die neuen Aufgaben
vorbereitet wurden.
Seite 143
Ist außerdem bei den Mitarbeitern auch noch die nötige Offenheit für Neuerungen und
Interesse an den neuen Aufgaben vorhanden, sind dies ebenfalls ideale Voraussetzungen für eine schnelle Migration.
2.1.2
Sanfte Migration
Die Gründe für die Wahl eines sanften Migrationsweges werden deutlich bei einem
Rückblick auf die Anforderungen und die Gründe für eine schnelle Migration:

Behörden und Verwaltungen mit knappen Budgets können die notwendigen Kosten der Haushaltslage angepasst verteilen.

Fehlendes Know-how kann sukzessive aufgebaut und damit Kosten eingespart
werden.
Da die Migration komponentenweise erfolgt, können die einmal geschulten ITMitarbeiter anschließend als Multiplikatoren fungieren, sodass bei der Migration
der nächsten Komponente schon ein höherer Grad an Know-how verfügbar ist.

Bestehende Widerstände können langsam abgebaut und Vorbehalte aufgelöst
werden.

Komplexe IT-Strukturen können Stück für Stück aufgelöst werden.
Know-How-Aufbau
Die nachfolgende Abbildung skizziert beispielhaft, wie eine möglichst sanfte Migration
aussehen könnte.
gra
Mi
F
er
d
n
tio
en
ng
u
nd
we
n
A
ef ic
f
O
File- & Printnd
u
Server
h
ac
Mail- &
KalenderServer
Office/Desktop
DNS- &
DHCPServer
Verzeichnis Server
Web-Server
DBMSServer
SERVERMIGRATION
EVTL.
OFFICEMIGRATION
DESKTOPMIGRATION
Zeitlicher Verlauf
Abbildung 24: Beispiel einer sanften und stufenweisen Migration
Zu Beginn sollte eine einfach herauszulösende Komponente für die Migration gewählt
werden. In dem obigen Beispiel steht dort der DBMS-Server. Dabei geht es nicht um die
Migration der Datenbankanwendungen, sondern um das Aufsetzen eines parallelen
DBMS. Grundkenntnisse zu DBMS dürften vorhanden sein und spätestens bei der Migration der nächsten Komponente, der Web Server, wird in der Regel auch ein DBMS
Seite 144
benötigt. Der Directory Server ist zunächst eine alleinstehende Komponente, kann aber
eventuell schon im Zusammenhang mit dem Webserver genutzt werden und ist möglicherweise eine Voraussetzung für die folgende Groupware-Migration. Anschließend erfolgt die Migration der Datei-, Netz- und Druckdienste. Letztendlich wird der Desktop
migriert, nachdem parallel zu den Komponentenmigrationen alle Fach- und Officeanwendungen im Hintergrund migriert wurden.
Wie gesagt, hierbei handelt es sich um ein mögliches Beispiel und je nach bestehender
IT-Infrastruktur und vorhandenen Abhängigkeiten kann sich die Reihenfolge auch ganz
anders gestalten.
Bei einer sanften Migration können die Komponenten für die einzelnen Schritte nicht
beliebig ausgetauscht und verschoben werden; was zusammengehört, soll auch zusammenbleiben. Ferner ist wichtig, dass der Prozess zeitlich nicht überstrapaziert und
ein realistischer Endtermin gesetzt wird. Der Realisierungszeitraum muss jedoch der
Komplexität von Pflege und Wartung und damit dem Aufwand, der für die Administratoren anfällt, Rechnung tragen. Da der administrative Aufwand in einer bunten ITLandschaft meist höher als in einer homogenen Landschaft ist, sollte der gesamte Umstellungsprozess auch bei einer sanften Migration 2 bis 3 Umstellungsabschnitte mit einem insgesamt zeitlich überschaubaren Horizont nicht überschreiten.
Abbildung 24 zeigt die drei Umstellungsabschnitte der Beispielmigration. Beispielhaft
angewandt auf eine Migration weg von einer Windows-basierten IT-Infrastruktur hin zu
einer Linux-basierten IT-Infrastruktur kann die Migration zunächst serverseitig relativ weit
vorangetrieben werden. Vor allem mit Samba, Terminalservices und auch der Möglichkeit, Outlook als Groupware- und Messaging-Client weiterzuverwenden, stehen Hilfen
zur Verfügung, welche die zwischenzeitliche Heterogenität der IT-Landschaft ermöglichen, ohne dabei Einschränkungen hinnehmen zu müssen.
Erst ganz am Ende, wenn alle Fach- und Officeanwendungen parallel zu serverseitigen
Migrationsprozess umgestellt wurden, kann die Migration des Desktops, heißt die clientseitige Migration von Windows nach Linux vorgenommen werden. Sofern die Umstellungen der Fach- und Officeanwendungen dies zulassen, kann sogar überlegt werden, in
einem Zwischenschritt MS Office nach OpenOffice.org oder StarOffice auf einem Windows-Client zu migrieren.
2.2
2.2.1
Mögliche Auswirkungen der Migrationspfade
Aufwand
Bezüglich des Aufwandes zur Durchführung einer Migration gibt es keine Abhängigkeiten zwischen Aufwand und dem Typ des Migrationspfades. Ob fortführend oder ablösend, ob Ablösung von Windows-basierten Infrastrukturen oder umgedreht, der für eine
Migration notwendige Aufwand ist am Ende immer von den jeweiligen Anforderungen,
der bestehenden Ausgangssituation und den strategischen Zielsetzungen abhängig.
Dies gilt auch für den Aufwand, der durch den nachfolgenden Betrieb entsteht. Vereinfachende und falsche Annahmen, wie zum Beispiel, dass OSS-Produkte zwar einerseits keine Lizenzkosten verursachen, dem aber hohe Aufwendungen durch komplexere
Seite 145
Administration, mehr Schulungsbedarf und unzureichenden Support entgegenstehen,
haben keine Gültigkeit.
Aufwand für Support, Wartung und Pflege der Software hängen von den jeweiligen Systemen und ihrer Nutzung ab, wie oft und welche Änderungen und Erweiterungen an Konfiguration, Aufbau und Funktionalitäten durchgeführt werden müssen, welche Tools und
welches Know-how zur Verfügung stehen, wie die verfügbaren Lizenzmodelle gestaltet
sind, ob Lizenzkosten anfallen und unter welchen Bedingungen und in welcher Höhe.
Diese und noch viel mehr Faktoren sind ausschlaggebend für die Folgeaufwendungen
eines gewählten Migrationspfades.
Dies macht deutlich, dass prinzipiell alle sinnvollen und machbaren Varianten hinsichtlich
der Wirtschaftlichkeit zu prüfen sind, wobei die mittel- bis langfristigen Folgekosten so
gut und umfassend wie möglich zu berücksichtigen sind.
In diesem Zusammenhang wird empfohlen, auch einen Blick auf die in diesem Leitfaden
diskutierten strategischen Aspekte zu werfen (siehe I.A 1) und die Aspekte der Herstellerabhängigkeit und der Verwendung von offenen Standards bei der Prüfung dringend zu
berücksichtigen.
2.2.2
Nachfolgender Migrationsbedarf
Nicht selten legt bereits die aktuell durchgeführte Migration einen Grundstein für die
Nachfolgende. Das gilt natürlich besonders für die Migrationspfade, an deren Ziel ein
bestimmtes Produkt eines Herstellers steht.
Da es im Interesse des Herstellers liegt, auch die Folgeversionen seiner Produkte zu
verkaufen, wird zwangsläufig der Support für ein bestimmtes Produkt nach einem gewissen Zeitraum eingestellt. Dieser grundsätzlich abzusehende Migrationsbedarf wird noch
dadurch zusätzlich ungünstig beeinflusst, dass durch den kommerziellen Charakter der
herstellerspezifischen Produkte auch der zeitliche Abstand zwischen den Migrationen
sowie der Umfang der einzelnen Migrationen fast vollständig außerhalb der eigenen
Kontrolle liegt.
Eine erneute Migration wird also dann notwendig, wenn das gewählte Produkt nicht
mehr weiterentwickelt wird. Diese Situation kann auch bei Open Source Software eintreten, zum Beispiel durch eine Abnahme des Interesses bei den Entwicklern und der nachfolgenden Auflösung der entsprechenden OSS-Entwicklergemeinde. Die Erfahrungen
zeigen jedoch, dass erfolgreiche OSS-Projekte langfristig bestehen, auch wenn vielleicht
einzelne Entwickler aus dem Kernteam sich anderen Interessen zuwenden. In den meisten Fällen findet sich Ersatz.
Darüber hinaus kann man dem entgegen wirken, indem man einen geeigneten und zuverlässigen Support-Partner verpflichtet und im Vorfeld die Bestandsfähigkeit und Zuverlässigkeit der Entwicklergemeinde prüft, so wie man dies auch bei der Beschaffung von
proprietärer Software durch Prüfung der Leistungsfähigkeit des Dienstleisters und des
Softwareherstellers tut.
2.2.3
Auswirkungen auf spätere Migrationen
Wird eine Migrationsentscheidung aufgrund der Tatsache getroffen, dass nur ein bestimmtes proprietäres Produkt die Anforderungen vollumfänglich erfüllt, ist es offensichSeite 146
tlich, dass damit die Möglichkeiten für spätere Migrationen eingeschränkt werden. Allerdings kann eine solche Einschränkung auch auf weniger direkten Wegen entstehen.
Die meisten Migrationsmöglichkeiten sind in einer Umgebung vorhanden, die ausschließlich auf standardisierte Funktionalität setzt. Viele Produkte weichen jedoch mehr
oder weniger stark von den zugrunde gelegten Standards ab. Insbesondere proprietäre
Produkte setzen zum Teil solche Abweichungen in Form von zusätzlichen Funktionalitäten als Alleinstellungsmerkmal ein. Gute Beispiele hierfür findet man bei den unterschiedlichen Datenbankmanagementsystemen.
Wenn diese produktspezifischen Zusatzfunktionen intensiv genutzt werden, dann kann
dies in der Folge zu erhöhten Migrationskosten kommen, wenn man einen ablösenden
Pfad beschreiten möchte. Dies kann im schlimmsten Fall zu einer extremen Produktund Herstellerabhängigkeit führen.
Daher sollte man im Rahmen eines Migrationsvorhabens genau prüfen, welche Standardfunktionalitäten gebraucht werden und welche darüber hinaus, wie diese von den
verschiedenen Produkten unterstützt werden und welche Abhängigkeiten beziehungsweise Folgekosten in der Zukunft daraus entstehen können.
2.3
Checkliste der Erfolgsfaktoren
Damit Migrationsprojekte als IT-Projekte im Allgemeinen und als Innovationsprojekte im
Besonderen zu einem erfolgreichen Abschluss geführt werden können, sind die kritischen Erfolgsfaktoren bereits im Vorfeld zu definieren und zu bewerten. Erfolgreich für
alle Beteiligten ist ein Migrationsprojekt zunächst dann, wenn das gewünschte Ziel beziehungsweise Ergebnis innerhalb des geplanten beziehungsweise vereinbarten Zeitund Budgetrahmens erbracht wird.
Hinzu kommen sogenannte weiche Faktoren, die einen nicht zu unterschätzenden Beitrag zum Gesamterfolg leisten. Dazu zählen beispielsweise die Mitarbeiterzufriedenheit,
eine reibungsfreie Kommunikation und damit Vermeidung beziehungsweise Reduzierung
von Misserfolg, Frust und Doppelarbeiten sowie die bedarfsgerechte Auswahl und natürlich Akzeptanz der neuen IT-Landschaft bei den Anwendern.
Nachfolgend werden wichtige zu beachtende Erfolgsfaktoren technischer, wirtschaftlicher und organisatorischer Art – ergänzt um wesentliche Erfahrungen aus Migrationsprojekten – aufgeführt.
2.3.1

Technische Erfolgsfaktoren
Detaillierte Bestandsaufnahme mit Definition der funktionalen Anforderungen:
Je genauer die Aufnahme des Ausgangszustands erfolgt, desto geringer ist die
Wahrscheinlichkeit, dass bei der Definition des Zielzustandes entscheidende Aspekte übersehen werden.

Migrationen müssen im Gesamtkontext betrachtet werden:
Nicht nur das migrierte Produkt ist entscheidend, sondern auch der Rest der Systemlandschaft.

Optimale Produkt- und Dienstleistungsauswahl:
Seite 147
Anhand des definierten Zielzustands lassen sich die Anforderungen an benötigte
Produkte und Dienstleistungen recht gut ermitteln. Ob die von verschiedener
Seite angebotenen Produkte und Dienstleistungen diese Anforderungen tatsächlich erfüllen, muss sorgfältig geprüft werden.
Außer wenn zwingende technische oder wirtschaftliche Gründe dafür sprechen,
sollten Migrationen auf neueste Produktversionen, mit denen nur wenig oder
kaum Erfahrungen bestehen, vermieden werden.

Dokumentation:
Im Laufe eines Migrationsprojekts werden zahlreiche Entscheidungen getroffen,
die dokumentieren werden müssen, um spätere Validierungen dieser Entscheidungen – insbesondere, wenn sich technische oder wirtschaftliche Voraussetzungen geändert haben – zu ermöglichen.
Auch die Dokumentation des Ausgangs- und des Zielzustands (sowohl geplant
als erreicht) sind sinnvoll.

Einsatz standardkonformer Technologien:
Darüber hinaus ist es vorteilhaft, standardkonforme Technologien einzusetzen.

Berücksichtigung verwendeter proprietärer Funktionalität:
Die in der umzustellenden Systemlandschaft verwendete proprietäre Funktionalität stellt ein Risiko für den Migrationserfolg dar und muss vorher entsprechend
berücksichtigt werden.
2.3.2

Wirtschaftliche Erfolgsfaktoren
Klarer Nutzen des Projekts:
Ein klarer Nutzen des Migrationsprojekts muss bereits vor seinem Start erkennbar sein.

Strukturierte Zeit-, Projekt- und Ressourcenplanung:
Migrationsprojekte können sehr umfangreich werden und sich über einen längeren Zeitraum erstrecken. Damit die Kosten nicht durch unnötige Verzögerungen
und Reibungsverluste negativ beeinflusst werden, ist eine sorgfältige Planung,
die das Projekt in seinem Verlauf kontrollierbar macht, von Anfang an nötig.

Etablierung eines effektiven Projekt-Controllings:
Neben der Überwachung des Budgets und der Termineinhaltung ermöglicht ein
effektives Projekt-Controlling auch die frühzeitige Reaktion auf Abweichungen
von den ursprünglichen Planvorgaben.

Einbindung und Positionierung der Leitungs- und Entscheidungsebene:
Nur die Leitungsebene kann die Verfügbarkeit der erforderlichen Finanzmittel, zu
denen neben den reinen Investitions- und Lizenzkosten auch Kosten für Schulungen, externe Beratung und Projektunterstützung sowie interne Personalkosten
zählen können, und deren Anpassung an den Projektfortschritt sicherstellen.
Seite 148
2.3.3

Organisatorische Erfolgsfaktoren
Formulierung eindeutiger Ziele des Migrationsprojektes:
Festzulegen ist, warum die Migration überhaupt durchgeführt werden soll und wie
der angestrebte Zielzustand genau aussehen wird.
Jedes Migrationsprojekt ist anders, daher ist die Übertragbarkeit von Erfahrungen
aus früheren Projekten sehr genau zu prüfen, falls es sich dabei nicht um Projekte mit den gleichen Produkten in denselben Versionen handelt.

Einbindung und Positionierung der Leitungs- und Entscheidungsebene:
Die Entscheiderebene muss von der Notwendigkeit zur Migration und dem gewählten Weg überzeugt sein.
Weiterhin spielt die jeweilige Leitungs- und Entscheidungsebene eine nicht zu unterschätzende Rolle in Fragen der Projektorganisation, Kommunikation, Fortschrittskontrolle und Ergebnisüberprüfung, der Anstoß zur Durchführung des Projekts muss eigentlich von ihr kommen, das Projekt muss über alle Phasen durch
sie unterstützt werden.

Bildung eines qualifizierten Projektteams:
Im Idealfall sollten die an der Migrationsdurchführung beteiligten Mitarbeiter für
die Zeit des Migrationsprojekts von ihren sonstigen Aufgaben weitgehend entbunden werden, um ihre Konzentration auf den Erfolg des Migrationsprojekts zu
ermöglichen, den Koordinationsaufwand gering zu halten und Ressourcenkonflikte zu vermeiden.

Festlegung von Zuständigkeiten:
Migrationsprojekte sind deutlich risikoärmer, wenn die Zuständigkeiten in der umzustellenden Systemlandschaft klar voneinander getrennt sind.

Frühe Informationen und Einbindung der Zielgruppen/Mitarbeiter:
Nur durch eine frühzeitige Information und echte Einbindung der Betroffenen
lässt sich eine hohe Akzeptanz des Zielzustands erreichen.
Das Vorhandensein des internen Wissens über den des Zielzustands der Migration muss sichergestellt werden, insbesondere in Fragen des anschließenden Betriebs und der Administration.

Zeitnahe und nachhaltige Schulungen:
Schulungen für die neuen Produkte und Technologien sollten weitgehend auf den
individuellen Schulungsbedarf abgestimmt sein, um einen nahtlosen Übergang in
den Zielzustand zu erlauben und Produktivitätsverringerungen in der Anfangszeit
nach der Migration zu vermeiden.
Ohne detaillierte Produktkenntnisse (auch der beteiligten Versionen) sind Migrationsprojekte schwer zum Erfolg zu führen.
Seite 149
II. Modul Infrastrukturen
A Thema Datenbank-Systeme
Der Begriff Datenbank bezeichnet an dieser Stelle die strukturierte Sammlung und die
Ablage von Daten in elektronischer Form. Daten können hierbei je nach Ausprägung
einer Datenbank in unterschiedlicher Form oder unterschiedlichem Format vorliegen.
Bei den in den folgenden Kapiteln beschriebenen Produkten handelt es sich um Datenbanksysteme, in denen Datenbanken von Datenbank-Managementsystemen verwaltet
werden. Letztere ermöglichen zudem die Bearbeitung und Abfrage von Daten in einer
Datenbank.
Da die betrachteten Datenbanken die gespeicherten Daten in Form von zweidimensionalen Tabellen (Relationen) organisieren, spricht man auch von relationalen Datenbanken
und Datenbank-Managementsystemen. Weitere Ausprägungen von Datenbanken wie
zum Beispiel objektorientierte Datenbanken oder XML-Datenbanken werden aufgrund
ihres aktuell vergleichsweise geringen Verbreitungsgrades im Rahmen dieses Dokuments nicht betrachtet. Die wesentlichen Funktionen moderner, relationaler DatenbankManagementsysteme werden von allen hier betrachteten Produkten angeboten, dazu
gehören insbesondere die Folgenden:

Views
Views sind virtuelle Tabellen für wiederkehrende Abfragen. Sie können in Abfragen wie andere Tabellen verwendet werden, ihre Berechnung erfolgt bei jeder
derartigen Verwendung.

Trigger
Trigger sind Programme, deren Ausführung in Abhängigkeit von bestimmten
Aktionen (Einfügen, Ändern, Löschen) auf bestimmten Daten erfolgt und die so
zum Beispiel zur Konsistenzsicherung eingesetzt werden können.

User Defined Functions und Stored Procedures
User Defined Functions sind innerhalb der Datenbank ausführbare Programme,
mit denen Funktionen definiert werden können, die in Datenbankabfragen als
auswertbare Ausdrücke verwendet werden können. Stored Procedures sind User
Defined Functions sehr ähnlich, können allerdings nicht in Ausdrücken verwendet
werden, dafür sind sie aber erheblich flexibler bezüglich ihrer Rückgabewerte.
Seite 150

Transaktionsunterstützung
Mittels Transaktionsunterstützung können Datenbank-Managementsysteme die
atomare98, konsistente, isolierte und dauerhafte Durchführung einer logisch zusammenhängenden Operation auf den Daten, die auch aus mehreren Operationen zusammengesetzt sein kann, sicherstellen.

Save Points
Save Points bieten die Möglichkeit, innerhalb von Transaktionen Punkte zu definieren, zu denen zurückgekehrt werden kann. Alle Veränderungen des Datenbankzustands durch Aktionen nach dem entsprechenden Save Point werden
dabei wieder rückgängig gemacht.
Abweichungen von dieser Grundfunktionalität sowie spezielle Erweiterungsmöglichkeiten
werden in den nachfolgenden produktspezifischen Abschnitten behandelt.
Eine detaillierte Betrachtung von Sicherheitsaspekten der einzelnen Datenbanksysteme
würde den Rahmen des Migrationsleitfadens sprengen. Grundsätzlich enthalten die hier
vorgestellten Datenbanksysteme Sicherheitsmechanismen, die auf Benutzerebene die
Authentisierung, Autorisierung und Vergabe von bestimmten Rechten zum Datenzugriff
ermöglichen.
Einige Datenbanksysteme bieten darüber hinaus weitere Mechanismen zum Schutz der
gespeicherten Daten an, zum Beispiel durch Verschlüsselung von Daten und der Kommunikation zwischen Client und Server. Entsprechende Hinweise finden sich in den produktspezifischen Abschnitten.
Die tatsächlich erreichbare Sicherheit eines Datenbanksystems hängt jedoch zu einem
überwiegenden Teil von der konkreten Einsatzumgebung, der vorgenommenen Konfiguration und der Art der Nutzung ab. Detaillierte Hinweise und Maßnahmen zu Sicherheitsaspekten in Datenbanksystemen finden sich in den IT-Grundschutzkatalogen des
Bundesamtes für Sicherheit in der Informationstechnik (BSI) 99.
1
1.1
Produkte / Technologien
MySQL
MySQL wird von der schwedischen Firma MySQL AB entwickelt und vertrieben beziehungsweise zur Verfügung gestellt. MySQL war ursprünglich als schneller und flexibler
Ersatz für mSQL, einem Datenbanksystem von Hughes Technologies, gedacht. Die
softwaretechnische Basis stammt aus den frühen 1980er Jahren. Die aktuelle Version ist
MySQL 5.1.
98
99
Eine atomare Operation ist eine Operation, die nicht durch eine andere Operation unterbrochen werden kann. Eine Transaktion wird entweder vollständig oder gar nicht ausgeführt.
Ein typisches Beispiel in diesem Kontext ist die Durchführung einer Überweisung von einem auf ein anderes Konto, bei der der Betrag zuerst von einem Konto abgehoben und
dann dem anderen gutgeschrieben wird.
http://www.bsi.bund.de/gshb/deutsch/baust/b05007.htm (Baustein Datenbanken) und
http://www.bsi.bund.de/gshb/deutsch/m/m02126.htm (Maßnahmenkatalog Organisation Erstellung eines Datenbanksicherheitskonzepts)
Seite 151
Der Hersteller schätzt die Zahl der aktiven MySQL Installationen weltweit auf über 11
Millionen100. Die unter der Abkürzung LAMP bekannte Kombination von Linux, Apache,
MySQL und PHP ist seit Beginn der kommerziellen Internetnutzung eine der beliebtesten
Infrastrukturen für Webshops und dynamische Webseiten. MySQL ist auf über 20 Plattformen einsetzbar, darunter Linux, OS/X, HP-UX, AIX und Windows101.
Bei MySQL sind die beiden vorhandenen Lizenzmodelle an entsprechende Editionen
des Datenbanksystems gekoppelt. Der Hersteller spricht dabei von einer dualen Lizenz:

MySQL Community Edition
Diese Edition wird als Open-Source-Datenbanksystem unter der GNU General
Public License102 zur Verfügung gestellt.

MySQL Enterprise
Diese Edition wird unter einer kostenpflichtigen Lizenz103 vertrieben, die jedoch
neben dem Datenbanksystem selbst auch weitere Dienstleistungen und Support
beinhaltet. Es existieren unterschiedliche Leistungsstufen, die zum Beispiel Support, Beratungsunterstützung oder Haftungsfreistellung bei der Verletzung von
Rechten geistigen Eigentums umfassen.
Ein wesentliches Architekturmerkmal von MySQL ist die Möglichkeit der Verwendung
unterschiedlicher Speicher-Engines für die Arbeit mit unterschiedlichen Tabellentypen.
Damit lassen sich sowohl transaktionssichere als auch nicht-transaktionssichere Tabellen realisieren. Letztere sind wesentlich schneller und benötigen weniger Speicherplatz.
Folgende Speicher-Engines stehen zur Verfügung:
100
101
102
103

MyISAM zeichnet sich durch einen schnellen Datenabruf und schnelle Datenspeicherung aus, besitzt eine Volltextsuchfähigkeit, verwaltet jedoch nur nichttransaktionale Tabellen.

MEMORY stellt Tabellen im Arbeitsspeicher zur Verfügung.

InnoDB und BDB stellen transaktionssichere Tabellen zur Verfügung.

EXAMPLE ist nur für Entwickler gedacht, die Speicher-Engines entwickeln möchten, und bietet daher nicht die Möglichkeit, Daten zu speichern.

NDB Cluster wird zur Implementierung von Tabellen genutzt, die über viele Computer partitioniert sind. Sie steht derzeit nur für Linux, Solaris und Mac OS X zur
Verfügung.

ARCHIVE bietet die Möglichkeit zur Speicherung großer Datenmengen ohne Indizes mit einem sehr kleinen Speicherverbrauch.

BLACKHOLE nimmt zwar Daten entgegen, speichert sie jedoch nicht. Die Engine
kann zum Beispiel für den Test von Abfragen verwendet werden.

FEDERATED ist für die Speicherung von Daten in einer Remote-Datenbank vorgesehen.
http://www.mysql.de/why-mysql/marketshare/
http://dev.mysql.com/downloads/mysql/5.0.html#downloads
http://www.mysql.com/company/legal/licensing/opensource-license.html
http://www.mysql.com/company/legal/licensing/commercial-license.html
Seite 152
Mit MySQL 5.1 wurde eine Architektur eingeführt, die Pluggable Storage Engines erlaubt. Damit können neue, an den eigenen Bedarf angepasste Speicher-Engines erstellt
und einem laufenden MySQL Server hinzugefügt werden, ohne den Server selbst neu
kompilieren zu müssen. In der Regel sind die verfügbaren Speicher-Engines jedoch ausreichend. Die Möglichkeit, Speicher-Engines anzupassen, ist daher eher für Firmen
interessant, die sehr spezielle Anforderungen realisieren müssen.
In der aktuellen Version bietet MySQL auch Funktionen, die über die grundsätzlichen
Funktionen moderner Datenbanksysteme (siehe Einleitung) hinausgehen, darunter zum
Beispiel:

Datenbankreplikation
Um die Inhalte einer Datenbank an verschiedenen Orten verfügbar zu machen,
bietet MySQL die Möglichkeit, eine MySQL-Instanz als Master zu deklarieren und
mehrere andere Instanzen (die Slaves) anzuweisen, die Inhalte der Masterdatenbank zu replizieren. Die Datenbankreplikation kann auch für Live-Backups
verwendet werden, da sich Slave-Datenbanken nach Offline-Phasen problemlos
und automatisiert wieder auf den aktuellen Stand bringen lassen. 104

MySQL Cluster
Für Linux, MacOS X und Solaris existiert eine spezielle Speicher-Engine, mittels
derer sich Cluster von MySQL-Datenknoten realisieren lassen, die von einem
Management-Knoten verwaltet werden und auf die über spezielle MySQL-Knoten
zugegriffen werden kann105.

Tabellenpartitionierung
In MySQL lassen sich große Tabellen anhand selbst definierter Partitionierungsfunktionen auf verschiedene Partitionen eines Dateisystems verteilen. In der
aktuellen Version von MySQL sind mit den so entstehenden verteilten Tabellen
noch einige funktionale Einschränkungen verbunden106.
Stored Procedures stehen unter MySQL derzeit nur mit einem eingeschränkten
Funktionsumfang zur Verfügung, da deren Implementation noch nicht vollständig abgeschlossen ist107.
104
105
106
107
http://www.onlamp.com/pub/a/onlamp/2005/06/16/MySQLian.html
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html
Nähere Informationen zu den Beschränkungen bei der Tabellenpartitionierung finden sich
unter http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitations.html
Nähere Informationen zu den Beschränkungen bei Stored Procedures finden sich unter
http://dev.mysql.com/doc/refman/5.1/en/routine-restrictions.html
Seite 153
Zur Verwaltung eines Datenbanksystems stehen die folgenden grafischen Werkzeuge
bereit:

MySQL Query Browser
Mit diesem Werkzeug können Datenbankabfragen erstellt, ausgeführt und optimiert werden.

MySQL Workbench
Mit MySQL Workbench können Datenbankschemata grafisch erstellt, bearbeitet
und dokumentiert sowie in Form von SQL-Anweisungen exportiert werden.

MySQL Administrator
Dieses Werkzeug integriert die MySQL-Funktionen zur Datenbankadministration
und -wartung unter einer grafischen Benutzeroberfläche.
MySQL erlaubt die Verschlüsselung einzelner Zeichenketten in der Datenbank über entsprechende Funktionen. Dadurch ist eine attributweise Verschlüsselung zum Beispiel
von Passwörtern möglich. Darüber hinaus kann MySQL für die Netzwerkverschlüsselung
mittels SSL konfiguriert werden.
MySQL stellt standardbasierte Treiber für JDBC, ODBC und .NET (ADO.NET) und zahlreiche Schnittstellen zur Verfügung, sodass Entwickler die Programmiersprache ihrer
Datenbankanwendungen für MySQL verhältnismäßig frei wählen können (zum Beispiel
Java, alle .NET-Sprachen, Perl, PHP, Python, Eiffel). Darüber hinaus existiert eine CBibliothek, die eine direkte Einbettung von MySQL in entsprechende Anwendungen erlaubt.
Zusammenfassend bedeutet das: Neben der Plattformunabhängigkeit ist die Anpassbarkeit an die Einsatzbedürfnisse über austauschbare Speicher-Engines eine der
Stärken von MySQL. Für das typische Einsatzfeld von MySQL, das heißt die dynamischen Web-Anwendungen, sind insbesondere auch die mit preiswerter PC-Hardware
realisierbaren Cluster interessant.
1.2
PostgreSQL
Die Ursprünge von PostgreSQL liegen in dem 1986 an der Berkeley-Universität in Kalifornien von Michael Stonebraker entworfenem Postgres-Datenbanksystem. Seit 1996
gibt es die Software unter dem Namen PostgreSQL. PostgreSQL ist ein reines OSSProjekt und wird von einer großen internationalen Entwicklergemeinde 108 vorangetrieben.
PostgreSQL verfügt über eine große Community und wird in vielen Linux-Distributionen
standardmäßig ausgeliefert. Daher ist eine Abschätzung der Nutzerzahlen nur schwer
möglich. Die Entwicklergemeinde berichtet auf ihrer Web-Site von einer Million
Downloads der Version 8.0 (die aktuelle Version ist 8.2) innerhalb von sieben
Monaten.109
108
109
http://www.postgresql.org/developer/
http://www.postgresql.org/about/press/faq (Frage 5)
Seite 154
PostgreSQL ist für eine Reihe von Betriebssystemen verfügbar, darunter AIX, Linux,
FreeBSD, HP-UX, Mac OS X, NetBSD, OpenBSD, Solaris110, Tru64 UNIX und
Windows111.
Die Nutzung von PostgreSQL unterliegt der BSD-Lizenz112. Aufgrund der großen Community und des hohen Bekanntheitsgrades wird kostenpflichtiger Support für PostgreSQL von vielen Firmen angeboten113.
PostgreSQL beinhaltet ein objektrelationales Datenbank-Managementsystem, das heißt
es erlaubt ergänzend zu den Möglichkeiten eines relationalen Datenbank-Managementsystems die Verwendung selbstdefinierter Datentypen, die nicht atomar sein müssen
und auch unter Verwendung objektorientierter Konzepte wie Vererbung gebildet werden
können.
Auch PostgreSQL bietet in der aktuellen Version Funktionen, die über die im einleitenden Abschnitt beschriebenen grundlegenden Funktionen moderner Datenbanksysteme
hinausgehen, darunter beispielsweise:

Multiversion Concurrency Control
Mit diesem Mechanismus ermöglicht PostgreSQL das unabhängige Lesen und
Schreiben von Daten durch verschiedene Nutzer. Dazu werden bei Lesezugriffen
Snapshots des aktuellen Zustands der angeforderten Daten erstellt und nur diese
zurückgegeben. Schreibzugriffe, die nach dem Beginn eines Lesezugriffs erfolgen, haben keinen Einfluss auf die gelesenen Versionen der Daten mehr.

Write Ahead Log
PostgreSQL verwaltet ein sogenanntes Write Ahead Log, das alle an der Datenbank vorgenommenen Änderungen protokolliert und so zum Beispiel die Wiederherstellung des Datenbankzustands zu einem bestimmten Zeitpunkt (Point in time recovery) erlaubt. Darüber hinaus kann mit diesem Feature auch ein LiveBackup realisiert werden.
Für PostgreSQL gibt es eine Reihe von Erweiterungen durch unterschiedliche Organisationen oder Firmen sowohl in Form von Open-Source-Projekten114 als auch in Form
proprietärer Produkte115. Beispielsweise kann PostgreSQL mit der Erweiterung PostGIS116 als Datenbank für Geoinformationssysteme dienen. Projekte wie pgpool117 und
PGCluster118 stellen Replikationsfunktionalität für PostgreSQL-Datenbanksysteme zur
Verfügung. Darüber hinaus sind proprietäre Datenbanksysteme verfügbar, die auf PostgreSQL basieren.
110
111
112
113
114
115
116
117
118
Solaris 10 wird standardmäßig mit PostgreSQL ausgeliefert. Siehe auch:
http://www.sun.com/software/products/postgresql/
Möglich sind 2000, XP und 2003. Bisher sind nur Tests mit 32-Bit-Versionen erfolgt. Siehe
auch http://pginstaller.projects.postgresql.org/faq/FAQ_windows.html#1.1
http://www.postgresql.org/about/licence
http://www.postgresql.org/support/professional_support
http://www.postgresql.org/download/
http://www.postgresql.org/download/commercial
http://postgis.refractions.net/
http://pgpool.projects.postgresql.org/
http://pgcluster.projects.postgresql.org/index.html
Seite 155
In der aktuellen Version von PostgreSQL ist die Größe der Datenbank nur von den
Möglichkeiten der eingesetzten Hardware beschränkt. Eine einzelne Tabelle kann bis zu
32 TB groß sein. Die Anzahl der Datensätze ist dabei unbegrenzt, ihre maximale Größe
liegt bei 1,6 TB. Die Anzahl der Spalten ist je nach verwendeten Datentypen auf 250 bis
1600 begrenzt, pro Feld können bis zu 1 GB gespeichert werden.
Zur Unterstützung bei der Administration und Konfiguration sind verschiedene Werkzeuge für PostgreSQL verfügbar:

PGAdmin
PGAdmin stellt ein umfassendes Werkzeug zur Datenbankadministration mit grafischer Benutzeroberfläche dar. Neben der Verwaltung und Konfiguration von Datenbanken unterstützt PGAdmin auch die Datenbankentwicklung, beispielsweise
über den integrierten Editor mit SQL-Syntax-Highlighting.

phpPgAdmin
Dieses Werkzeug ermöglicht die Web-basierte Administration von PostgreSQLDatenbanken.
PostgreSQL bietet die Möglichkeit, die Datenkommunikation zwischen Server und Client
mit SSL zu verschlüsseln. Darüber hinaus können einzelne Spalten in Tabellen verschlüsselt werden. PostgreSQL kann so konfiguriert werden, dass die Client-Authentifizierung Kerberos-basiert erfolgt119.
Für PostgreSQL existiert neben ODBC- und JDBC-Treibern eine große Zahl von
Schnittstellen, die die Anbindung der Datenbank an selbst entwickelte Anwendungen in
zahlreichen Programmiersprachen und -umgebungen ermöglicht. Neben Ada, C/C++,
Java, Perl, Python und PHP ist auch der Einsatz der .NET-Programmiersprachen möglich.
Zusammenfassend ist festzuhalten, dass PostgreSQL unter den Open-Source-Datenbanksystemen einen sehr guten Ruf hat. Insbesondere der Funktionsumfang sowie die
Standardkonformität und die einfache Erweiterbarkeit der Datenbank werden geschätzt.
Im Laufe seiner langen Entwicklungszeit hat PostgreSQL einen hohen Reifegrad erreicht
und ist damit ein Datenbanksystem, das auch für große Datenbestände und Lösungen
mit hoher Verfügbarkeit eingesetzt werden kann.
1.3
Firebird
Firebird ist Mitte 2000 als eigenständiges Projekt aus dem von Borland in die OpenSource-Welt entlassenen Datenbanksystem Interbase 6.0 entstanden. Die Weiterentwicklung des aktuell in der Version 2.0.1 vorliegenden Datenbanksystems wird von der
Firebird Foundation vorangetrieben, in der sich ca. 300 Mitglieder (Einzelpersonen und
Firmen) engagieren120. Firebird ist sowohl für unterschiedliche 32-Bit-Windowsversionen
als auch für Linux verfügbar121.
119
120
121
http://www.postgresql.org/docs/8.2/static/auth-methods.html#KERBEROS-AUTH
Stand: August 2007
http://www.firebirdsql.org/index.php?op=files&id=engine_201
Seite 156
Der Source Code des Interbase-Datenbanksystems, das die Grundlage von Firebird
bildet, wurde als Open Source unter die InterBase Public License 122 gestellt, Weiterentwicklungen von Firebird stehen unter der Initial Developer‘s Public License123.
Die Firebird kann in zwei Architekturvarianten betrieben werden:

Classic Server und

Superserver.
Der Classic Server erzeugt für jede Datenbankverbindung mit einem Client einen eigenen Prozess mit eigenem Cache. Dies hat Auswirkungen auf unterschiedliche Datenbankparameter wie zum Beispiel die Cachegröße. Laut Herstellerangaben ist der Ressourcenverbrauch bei einer geringen Anzahl von Verbindungen niedriger als beim Superserver.
Der Superserver verwendet dagegen nur einen einzigen Prozess für alle Verbindungen
und arbeitet die Anfragen im Rahmen von einzelnen Threads ab. Er ist laut Herstellerangaben effizienter, wenn die Anzahl paralleler Verbindungen steigt.
Allerdings gibt es je nach Rahmenbedingungen weitere Restriktionen zum Beispiel in
Hinblick auf die maximale Anzahl paralleler Verbindungen. Die Entscheidung für den
Classic- oder Superserver kann daher nur aufgrund individueller Projektanforderungen
getroffen werden. Da ein Wechsel zwischen den beiden Architekturen auch zu einem
späteren Zeitpunkt noch möglich ist, kann je nach Anforderungen die geeignetere der
beiden Architekturen gewählt werden.
Auch Firebird bietet alle Funktionen, die in der Einleitung zu diesem Thema beschrieben
wurden. Zusätzlich dazu verfügt Firebird über Mechanismen zur Spiegelung von Daten
über mehrere Speicherorte, das heißt, die Daten einer Datenbankinstanz werden im
laufenden Betrieb in eine oder mehrere andere Datenbankinstanzen übernommen. Eine
synchrone Replikation, das heißt die Sicherstellung, dass eine Änderung von Daten nur
dann erfolgreich abgeschlossen werden kann, wenn sie auch erfolgreich in die Spiegeldatenbanken repliziert wurde, ist damit nicht möglich. Auch eine Synchronisation in
beide Richtungen ist nicht möglich. Ein Live-Backup der Datenbank ist mit den
mitgelieferten Werkzeugen möglich.
Grafische Administrations- und Konfigurationstools werden für Firebird nur von dritter
Seite angeboten. Dabei profitiert Firebird von der Interbase-Vergangenheit, die nicht
selten die Verfügbarkeit von Management-Werkzeugen sowohl für Interbase als auch für
Firebird zur Folge hat124.
Firebird besitzt keine eigenen Mechanismen zur Verschlüsselung von Daten125, verfügt
jedoch über verschiedene Schnittstellen. Darunter sind neben Anbindungen für .NET,
122
123
124
125
http://www.firebirdsql.org/index.php?op=doc&id=ipl
http://www.firebirdsql.org/index.php?op=doc&id=idpl
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_admin_tools
http://www.firebirdsql.org/pdfmanual/Firebird-Security.pdf
Seite 157
Java, C++, Perl, PHP und Python auch mehrere Delphi-Komponenten, was sich aus der
Borland-Interbase-Vergangenheit erklärt126, sowie ODBC-, JDBC- und OLE-DB-Treiber.
Zusammenfassend lässt sich festhalten: Als relativ neuer Mitspieler im Bereich der
Open-Source-Datenbanksysteme ist Firebird im Vergleich zu anderen Vertretern wie
MySQL oder PostgreSQL noch nicht so bekannt. Dementsprechend kleiner ist die
Community und auch das Angebot an kostenpflichtigem Support.
Als Datenbanksystem für den professionellen Einsatz kommt Firebird heute nur eingeschränkt in Frage. Auch wenn Firebird über eine ganze Reihe Funktionen der anderen
hier beschriebenen Produkte verfügt, gibt es auch Einschränkungen, zum Beispiel in
Form fehlender Replikations- beziehungsweise Synchronisationsmechanismen.
1.4
MaxDB
MaxDB ist Ende der 1970er Jahre als universitäres Forschungsprojekt an der
Technischen Universität Berlin gestartet. Das System wurde in den 1980er Jahren von
Nixdorf als DDB/4 weiterentwickelt und vermarktet, kam dann über Siemens/Nixdorf als
AdabasD zur Software AG und wurde 1997 von SAP übernommen.
Das zwischenzeitlich in SAP DB umbenannte Datenbanksystem wurde im Jahr 2000
unter der GNU Public License (GPL) der Öffentlichkeit zur Verfügung gestellt. SAP führte
jedoch auch danach die Weiterentwicklung kontinuierlich fort.
2004 wurde die SAP DB von MySQL AB erworben und mit der Bezeichnung MaxDB
versehen. MaxDB wurde nach wie vor von SAP als zertifizierte Plattform für das
R/3-System und dessen Nachfolger angeboten und als Kerntechnologie in eigenen
Produkten eingesetzt. Seit Oktober 2007 wird sowohl der Vertrieb als auch der Support
der MaxDB wieder komplett von SAP übernommen.
MaxDB ist für HP-UX, IBM AIX, Linux, Solaris und Windows 2000, XP sowie 2003
Server verfügbar. Laut Herstellerangaben setzen über 6.000 Kunden127 MaxDB als
Datenbanksystem ein.
MaxDB wird heute von SAP mit einem dualen Lizenzmodell vermarktet. Es ist sowohl
unter der MaxDB Community License128 als auch unter einer kostenpflichtigen Lizenz 129
verfügbar. Im Rahmen der kostenpflichtigen Lizenz bietet SAP auch Support für MaxDB
an.
Laut Herstellerangaben verfügt das MaxDB-Datenbank-Managementsystem über ausgereifte Backup- und Restoremechanismen und ist für große Nutzerzahlen und hohe Last
ausgelegt. MaxDB erweitert die grundlegende Funktionalität eines Datenbanksystems
unter anderem um folgende Funktionen:
126
127
128
129
Delphi ist eine von Borland aus Object Pascal entwickelte Programmiersprache, die im
Windows-Umfeld unter anderem aufgrund ihrer nahtlosen COM-Integration und guter GUIEntwicklungsmöglichkeiten eine recht große Verbreitung hat.
Darunter finden sich allerdings auch Großkunden wie Toyota, Intel, DaimlerChrysler,
Braun-Gillette, Bayer, Colgate, Yamaha und die Deutsche Post.
http://maxdb.sap.com/license/MaxDB_Community_License_2007.pdf
http://maxdb.sap.com/license/
Seite 158

Hot-Standby
MaxDB erlaubt die Konfiguration einer Master- und mehrerer Standby-Instanzen
einer Datenbank. Letztere reproduzieren in regelmäßigen Abständen die Änderungen auf der Master-Instanz. Bei einem Ausfall der Master-Instanz übernimmt
eine der Standby-Instanzen des so gebildeten Clusters automatisch die Rolle des
Masters.

Sicherung im laufenden Betrieb
Die Daten in der Datenbank können gesichert werden, ohne dass dadurch die
Benutzung der Datenbank eingeschränkt wird.

Snapshot-Funktionalität
Ein bestimmter Zustand der Datenbank kann mittels Snapshot eingefroren
werden. Änderungen nach diesem Zeitpunkt erfolgen unter Vorbehalt und können entweder vollständig verworfen werden oder durch Löschung des vorhandenen beziehungsweise Erstellung eines neuen Snapshots übernommen
werden.
Bei einer Page Size von 8 KB ist eine maximale Datenbankgröße von 32 TB möglich.
MaxDB bietet verschiedene Werkzeuge für Administration und Einsatz, so zum Beispiel:

Installation Manager
Der Installation Manager bietet eine einheitliche grafische Schnittstelle zur Installation von MaxDB auf den unterstützten Betriebssystemen.

Database Manager
Mit dem Database Manager lassen sich Datenbanken erzeugen, überprüfen,
überwachen, archivieren und wiederherstellen. Für dieses Werkzeug existieren
drei verschiedene Benutzerschnittstellen: eine Kommandozeilenschnittstelle, eine
grafische Benutzeroberfläche (nur unter Windows) und eine Web-basierte
Schnittstelle für den entfernten Zugriff.

SQL Studio
Das SQL Studio erlaubt die Interaktion mit einer Datenbank über SQLAnweisungen. Es ist nur für Windows erhältlich, kann aber auf entfernte Datenbanken auf anderen Rechnern zugreifen.

Database Analyzer
Der Database Analyzer ist ein Werkzeug zur Analyse der DatenbankPerformance. Er dient der Identifikation von Konfigurations- und Synchronisationsproblemen sowie von Problemen bei der Verarbeitung von Datenbankabfragen.

Synchronization Manager
Mit dem Synchronization Manager können die Daten zwischen einer MasterDatenbank-Instanz und mehreren Slave-Datenbank-Instanzen synchronisiert
werden. Damit kann der Synchronization Manager auch zur Replikation von
Datenbanken eingesetzt werden.
Seite 159
MaxDB bietet bei der Verwendung in einem SAP-System die Möglichkeit, auch die
Kommunikation mit der Datenbank mittels SSL zu verschlüsseln.
Neben Schnittstellen zur Anwendungsprogrammierung mit Java, Perl, PHP und Python
sowie ODBC- und JDBC-Treibern existiert für MaxDB auch eine integrierte WebDAVSchnittstelle130, über die Anwender mit Web-Browsern auf die Datenbankinhalte zugreifen können.
Zusammenfassend ist festzuhalten: Die zukünftige Weiterentwicklung der MaxDB wird
durch die Unterstützung von SAP gesichert. Schon das Einsatzszenario als zertifiziertes
Datenbanksystem für SAP/R3 macht deutlich, dass es sich um ein System handelt, das
für den Einsatz in großen SAP-Umgebungen konzipiert ist. MaxDB wird in der allgemeinen Wahrnehmung als Nischenprodukt unterschätzt. Seine Leistungsfähigkeit qualifiziert
das MaxDB-Datenbanksystem jedoch durchaus auch für den Einsatz in anderen anspruchsvollen Bereichen.
1.5
Microsoft SQL Server 7.0/2000/2005
Bei Microsoft SQL Server handelt es sich um ein proprietäres relationales
Datenbanksystem, das aktuell in der Version 2005 vertrieben wird und je nach Edition für
unterschiedliche Windows-Betriebsystem-Versionen verfügbar131 ist. Die Entwicklung
des Microsoft SQL Servers geht auf eine Kooperation zwischen Microsoft und Sybase 132
Ende der 80er Jahre zurück. Microsoft SQL Server ist bezüglich seines Marktanteils auf
Platz drei hinter Oracle und IBM, hatte jedoch 2006 eine höhere Wachstumsrate als
seine Wettbewerber133.
Für den Einsatz von Microsoft SQL Server 2005 existieren drei Lizenzmodelle134:
130
131
132
133
134

Server plus gerätebasierte Client-Zugriffslizenz (CAL)
In diesem Modell muss neben einer Lizenz für jeden Server, auf dem Microsoft
SQL Server läuft, für jedes darauf zugreifende Gerät (PC, Arbeitsplatz, Terminal,
PDA, Mobiltelefon usw.) eine entsprechende Zugriffslizenz erworben werden.

Server plus nutzerbasierte Client-Zugriffslizenz (CAL)
In diesem Modell muss neben einer Lizenz für jeden Server, auf dem Microsoft
SQL Server läuft, für jeden darauf zugreifenden Nutzer eine entsprechende Zugriffslizenz erworben werden.

Prozessor-Lizenz
Erfordert eine Einzellizenz für jede CPU in der Betriebssystemumgebung, in der
der SQL Server ausgeführt wird. Diese Lizenz beinhaltet uneingeschränkten Zugriff für Client-Geräte.
http://de.wikipedia.org/wiki/WebDAV
http://www.microsoft.com/germany/sql/uebersicht/systemanforderungen.mspx
Inzwischen (seit der Version 7) wurden die letzten Sybase-Relikte entfernt.
http://www.gartner.com/it/page.jsp?id=507466
Weitere Informationen zu den einzelnen Lizenzmodellen finden sich unter
http://download.microsoft.com/download/c/7/2/c727d265-188c-45ae-9ca0ff5fd19089e8/wp_sql_2005_lizenzierung_de.pdf
Seite 160
Microsoft bietet vier Editionen des SQL Server 2005 mit unterschiedlichem Leistungsumfang an:

Express
Diese kostenlose Edition ist auf einen Prozessor und maximal 1 GB Hauptspeicher beschränkt. Darüber hinaus ist auch die Größe der verwalteten Datenbank auf maximal 4 GB begrenzt.

Workgroup
Diese Edition ist auf zwei Prozessoren und maximal 3 GB Hauptspeicher
beschränkt. Bei dieser und den folgenden Editionen ist die Datenbankgröße
prinzipiell unbegrenzt.

Standard
Diese Edition ist auf vier Prozessoren beschränkt. Der verwendbare Hauptspeicher ist nur von den Möglichkeiten des eingesetzten Betriebssystems abhängig.

Enterprise
Diese Edition ist hinsichtlich der Prozessorzahl unbeschränkt. Der verwendbare
Hauptspeicher ist nur von den Möglichkeiten des eingesetzten Betriebssystems
abhängig.
Der Microsoft SQL Server 2005 setzt sich aus mehreren funktionalen Bestandteilen
zusammen:

Datenbankmodul
Das Datenbankmodul beinhaltet die eigentliche Datenbank-Engine zum Speichern, Verarbeiten und Sichern von Daten.

Integration Services
Die SQL Server 2005 Integration Services (SSIS) dienen der Datenintegration
und -Transformation. Es können Daten aus unterschiedlichen Quellen, zum Beispiel aus XML-Datendateien, Flatfiles oder relationalen Datenquellen extrahiert
und transformiert werden.

Reporting Services
SQL Server 2005 Reporting Services (SSRS) bietet die Möglichkeit zur Erstellung von Datenberichten. Es stehen Tools zur Verfügung, die die Erstellung und
Verwaltung von Berichten erlauben.

Analysis Services
Die Analysis Services umfassen zentrale Dienste zur Analyse von Geschäftsdaten und Data-Mining-Funktionalitäten.

Service Broker
Der Service Broker des SQL Server 2005 bietet Unterstützung im Bereich Messaging- und Warteschlangenanwendungen, indem er eine nachrichtenbasierte,
bei Bedarf auch asynchrone Kommunikation zwischen Anwendungen erlaubt, die
einen gemeinsamen oder mehrere verteilte Microsoft SQL Server verwenden.
Seite 161
Microsoft SQL Server 2005 bietet neben den in der Einleitung erwähnten Funktionen
beispielsweise auch die folgenden Funktionen:

Benutzerdefinierte Datentypen
Microsoft SQL Server erlaubt die Einbindung eigener, auch komplexer Datentypen in die Typstruktur des Datenbank-Managementsystems. Diese können dann
wie die eingebauten Datentypen in Datenbanken verwendet werden.

Ausfallsicherheit durch Clusterbildung
Microsoft SQL Server lässt sich in Windows-Clustern135, die einen gemeinsamen
Speicherbereich verwalten, so konfigurieren, dass der Ausfall eines Prozessors
oder anderer nicht speicherrelevanter Hardware kompensiert werden kann.

Replikation
Hierbei handelt es sich um Technologien, die sowohl die Duplikation von Daten in
mehreren Datenbanken als auch eine Synchronisation zwischen den einzelnen
Datenbanken, also die Sicherstellung gleicher Inhalte in den einzelnen Kopien,
ermöglichen.

Volltextsuche
Die Volltextsuche ermöglicht Volltextabfragen in rein zeichenbasierten Daten
innerhalb von SQL-Server-Tabellen.
Für die Administration des Microsoft SQL Servers 2005 steht das SQL Server Management Studio zur Verfügung, das beispielsweise die folgenden Tools und Dienstprogramme enthält:
135

Business Intelligence Development Studio
Hierbei handelt es sich um eine Entwicklungsumgebung, die die Erstellung und
das Debuggen von Datenintegrations,- Data Mining- und Berichterstellungslösungen ermöglicht.

SQL Server Konfigurationsmanager
Der Konfigurationsmanager bietet die Möglichkeit zur Konfiguration von Autostartoptionen und erweiterten Optionen.

Microsoft SQL Server Agent
Der SQL Server Agent ermöglicht das Erstellen und Planen von Aufgaben, die
einmalig oder periodisch automatisiert ausgeführt werden sollen. Es können
Warnungen für den Administrator ausgegeben werden, wenn bestimmte Systemzustände eintreten.

Microsoft SQL Server Profiler
Dieser erlaubt die Überwachung und Analyse von Server-Ereignissen.

Datenbankmodul-Optimierungsratgeber
Hierbei handelt es sich um ein Tool zur Optimierung der Datenbankleistung.
http://msdn2.microsoft.com/en-us/library/ms952401.aspx
Seite 162
Als Besonderheit bietet der Microsoft SQL Server ähnlich wie die DB2 von IBM die
Möglichkeit, eine „shared-nothing― Architektur zu realisieren. Dabei werden die Daten auf
unterschiedliche Datenbankknoten mit Datentöpfen verteilt. Jeder Datentopf verfügt
dabei über eigene Ressourcen wie Prozessor, Festplatten und Hauptspeicher. Zudem
enthält jeder Datentopf eigene Daten, das heißt in jedem Datentopf ist nur ein Teil der
Gesamtmenge an Daten vorhanden. Wird eine Anfrage an einen beliebigen
Datenbankknoten gestellt, so fragt dieser die jeweils benötigten Daten aus den einzelnen
Daten-töpfen ab und führt sie zusammen. Eine Anfrage kann daher an jeden beliebigen
Knoten gestellt werden.
Der Microsoft SQL Server 2005 verfügt über eine integrierte Infrastruktur für die
Schlüsselverwaltung. Diese definiert eine Schlüsselhierarchie, in der die Schlüssel einer
Hierarchiestufe jeweils zur Verschlüsselung der darunter liegenden Ebene verwendet
werden. Die oberste Hierarchieebene bildet dabei ein kennwortbasierter WindowsBetriebssystemdienst136. Weitere Ebenen stellen die jeweilige SQL-Server-Instanz, die
zu verschlüsselnde Datenbank und die in ihr enthaltenen Daten dar137.
Die bei der Nutzung der Analysis Services auftretende Kommunikation zwischen Client
und Server ist in der Standardeinstellung verschlüsselt. Client-Abfragen, die unverschlüsselt erfolgen oder unverschlüsselte Antworten erwarten, können von einem entsprechend konfigurierten Server explizit abgelehnt werden.
Darüber hinaus wird bei Vorhandensein eines Active Directory indirekt über das
Windows-interne Security Service Provider Interface auch eine Kerberos-basierte
Authentifizierung unterstützt138.
Zur Einbindung des Microsoft SQL Servers 2005 in eigene Anwendungen existieren
neben ODBC- und OLE-DB-Treibern auch Anbindungen an das .NET-Framework. Seit
kurzem steht darüber hinaus auch ein JDBC-Treiber zur Benutzung des Microsoft SQL
Servers aus Java-Anwendungen heraus zur Verfügung.
Microsoft SQL Server ist sehr eng mit anderen Microsoft-Produkten verbunden. So ist er
für einige Produkte (zum Beispiel Windows SharePoint Services in größeren Installationen) eine Voraussetzung. Andererseits setzen einige seiner Funktionen (zum Beispiel die Datenverschlüsselung) direkt auf Funktionen des Microsoft-Windows-Betriebssystems auf. Diese hohe Integration erlaubt zwar eine nahtlose Einbindung des
Microsoft SQL Server in eine Windows-basierte Anwendungslandschaft, impliziert jedoch
auch die Entscheidung für weitere Microsoft-Produkte und kann eine eventuell gewünschte spätere Ablösung erschweren.
Somit lässt sich feststellen: Microsoft SQL Server ist ein leistungsfähiges Datenbanksystem mit umfangreicher Funktionalität. Sein Einsatzbereich ist jedoch, anders als bei
136
137
138
Dieser Dienst implementiert die Data Protection API (DPAPI). Siehe auch:
http://msdn2.microsoft.com/en-us/library/ms995355.aspx
Eine ausführlichere Beschreibung findet sich in dieser Präsentation:
http://download.microsoft.com/download/4/1/6/416bdb4a-67e9-4269-bcdc33dedb7f64fe/encryptionatmstwpppt.ppt.
weitere Informationen unter: http://msdn2.microsoft.com/en-us/library/ms189586.aspx
Hierbei ist zu beachten, dass das SSPI auf die schwächere NTLM-Authentifizierung zurückgreift, wenn keine Kerberos-Authentifizierung möglich ist. siehe dazu:
http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx
Seite 163
den anderen hier betrachteten Produkten, auf das Windows-Betriebssystem beschränkt.
In der einsetzenden Organisation wird also entsprechendes Wissen zur Administration
von Windows-Betriebssystemumgebungen und -Netzwerken benötigt.
1.6
Oracle
Die Entwicklung des Oracle Datenbanksystems beginnt mit der Gründung der Firma
Software Development Laboratories (SDL) im Jahr 1977. Ziel war die Entwicklung einer
Datenbank, die zu IBMs System R Datenbank kompatibel ist. 1983 wurde neben dem
Datenbanksystem auch das Unternehmen in Oracle umbenannt.
Heute zählt Oracle zu den führenden Datenbanksystemen. Laut Gartner erreicht Oracle
einen Marktanteil von rund 47% im Jahre 2006.139 Oracle wird aktuell in der Version 11g
vertrieben und steht in folgenden Editionen für Linux, UNIX und Windows zur Verfügung:

Express 10g
Diese kostenlose Edition ist auf eine CPU und maximal 1 GB Hauptspeicher
beschränkt. Darüber hinaus ist auch die maximale Datenbankgröße auf 4 GB
begrenzt.

Standard Edition One
Diese Edition ist auf Servern mit maximal zwei Prozessoren einsetzbar. Der
verwendbare Hauptspeicher wird nur von den Möglichkeiten des eingesetzten
Betriebssystems begrenzt. Die Datenbankgröße ist bei dieser und den folgenden
Editionen prinzipiell unbegrenzt.

Standard
Diese Edition ist auf Servern mit maximal vier Prozessoren einsetzbar. Der
verwendbare Hauptspeicher wird nur von den Möglichkeiten des eingesetzten
Betriebssystems begrenzt.

Enterprise Edition
Diese Edition ist hinsichtlich der Prozessorzahl unbeschränkt. Der verwendbare
Hauptspeicher ist nur von den Möglichkeiten des eingesetzten Betriebssystems
abhängig.
Für die kostenpflichtigen Editionen stehen folgende Lizenzmodelle zur Verfügung:
139

Named User Plus
Hierbei ist für jeden Nutzer, der auf die Datenbank zugreift, eine Lizenz zu
erwerben. Zu beachten ist, dass auch „non-human operated devices―, also
beispielsweise Temperatursensoren, die eine Datenbank mit aktuellen Werten
versorgen, als Nutzer zählen.

Prozessor
Hierbei ist für jeden Prozessor, auf dem die Oracle-Software läuft, eine Lizenz zu
erwerben. Bei Mehrkernprozessoren zählt prinzipiell die Zahl der Prozessor-
Seite 164
kerne, allerdings gibt es für die einzelnen Prozessortypen unterschiedliche
Faktoren, mit denen die Zahl der Prozessorkerne gewichtet wird.140
Oracle ist in der Version 11g als Grid-Datenbank konzipiert. Dabei erfolgt eine Trennung
der physikalischen und der logischen Struktur der Datenbank. Die physikalische
Speicherung der Daten wird unabhängig vom Zugriff auf die logische Struktur verwaltet.
Eine große Anzahl von Servern und Speichergeräten agiert dabei als ein sich selbst
verwaltendes Grid.
Oracle verfügt im Vergleich zu anderen Datenbank-Managementsystemen über einen
sehr großen Funktionsumfang. An dieser Stelle werden beispielhaft einige Erweiterungsmöglichkeiten für Oracles Datenbanksystem dargestellt:

Real Application Testing
Diese Erweiterung ermöglicht die Übernahme und Wiederholung der aktuellen
Last eines Produktivsystems in einer Testumgebung, um Auswirkungen von
Systemänderungen unter realistischen Bedingungen prüfen zu können.

Real Application Clusters (RAC)
Durch die Verteilung einer Datenbank über mehrere Server ergibt sich die Möglichkeit, große Systeme aufzubauen. Dabei können zur Erweiterung der Datenbank weitere Server im laufenden Betrieb hinzugefügt werden.

Oracle Data Mining (ODM)
Ermöglicht den Aufbau integrierter Business Intelligence Anwendungen auf Basis
von Data-Mining-Funktionalitäten.

Oracle Active Data Guard
Ermöglicht die Auslagerung rechenintensiver Aufgaben wie komplexe Abfragen
oder Backups an Standby-Datenbanken.

Automatic Storage Management
Ermöglicht die automatische Spiegelung und das Balancing von Daten über die
verfügbaren Speichergeräte sowohl zum Schutz der Daten als auch zur Optimierung der Performance. Dabei ist auch das Hinzufügen oder Entfernen von Datenspeichern möglich.

Oracle XML DB141
Mit dieser Erweiterung steht eine Möglichkeit zur Verfügung, XML-Daten strukturiert zu speichern, sodass sie effizienter abgefragt werden können.
Zur Konfiguration und Administration von Oracle-Datenbanken existiert eine Reihe von
Werkzeugen, darunter zum Beispiel:

140
141
Oracle Enterprise Manager
Dieses Werkzeug dient der allgemeinen Verwaltung und Administration von
Datenbanken. Einzelne sogenannte Management Packs decken dabei unterschiedliche Aspekte ab.
Nähere Informationen zum insgesamt recht komplexen Lizenzmodell von Oracle finden sich
hier: http://www.oracle.com/corporate/pricing/sig.pdf
http://www.oracle.com/technology/tech/xml/xmldb/index.html
Seite 165

SQL Performance Analyzer
Dieses Werkzeug kann zur Analyse von Performance-Problemen in Datenbanken eingesetzt werden.

SQL Tuning Advisor
Der SQL Tuning Advisor kann bei der Lösung von Performance-Problemen in
Datenbanken verwendet werden.
Oracle 11g bietet für die Enterprise Edition optional die flexible Vergabe von Zugriffsrechten über sogenannte Labels auf Spalten- und Zeilenebene an. Damit kann sehr
detailliert gesteuert werden, auf welche Teile einer Tabelle welcher Nutzer in welchem
Umfang zugreifen darf142. Für die Enterprise Edition stehen darüber hinaus auch
Optionen zur Erhöhung der Datensicherheit über Verschlüsselung des Netzwerks,
einzelner Daten, von Datentypen oder kompletten Tabellenbereichen zur Verfügung143.
Oracle lässt sich wie andere Datenbanksysteme auch aus selbst entwickelten Anwendungen über entsprechende Schnittstellen ansprechen. Es existieren neben ODBC-,
OLE-DB- und JDBC-Treibern diverse APIs, sodass Datenbankanwendungen unter Verwendung von beispielsweise C, C++, Java, Perl, PHP und allen .NET-Programmiersprachen entwickelt werden können. Darüber hinaus existiert die Entwicklungsumgebung144 „Oracle-Application-Express― zur Entwicklung von webbasierten Anwendungen mit direktem Datenbankzugriff.
Zusammenfassend kann festgehalten werden, dass Oracle häufig für große Datenbestände mit hohen Lastanforderungen eingesetzt wird. Allerdings geht mit der Vielzahl
der gebotenen Funktionalitäten auch eine hohe Komplexität einher. Sollen die Möglichkeiten eines Oracle-Datenbanksystems voll genutzt werden, so sind die Konzeption und
der Betrieb auch entsprechend aufwändig
1.7
IBM DB2
DB2 wurde von IBM erstmals im Jahre 1983 vorgestellt und basiert auf den Arbeiten in
IBMs System-R-Projekt, welches die erste Umsetzung der 1970 vorgestellten Konzepte
relationaler Datenbanken darstellte145.
IBM DB2 ist für zahlreiche Betriebssysteme verfügbar, darunter Linux, UNIX und Windows146. In Großrechnerumgebungen ist IBM DB2 traditionell marktführend, hat aber
auch in den anderen Bereichen signifikante Marktanteile147.
142
143
144
145
146
147
http://www.oracle.com/database/label-security.html
http://www.oracle.com/database/advanced-security.html
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b32258/toc.htm
http://www-128.ibm.com/developerworks/db2/library/techarticle/0301jones/0301jones.html
http://www-306.ibm.com/software/data/db2/9/sysreqs.html
Seite 166
Die Lizenzmodelle orientieren sich an der Anzahl zugelassener Nutzer pro Server beziehungsweise pro Prozessor. IBM DB2 wird zudem in unterschiedlichen Editionen angeboten:

DB2 Express-C
Diese kostenlose Edition ist auf 2 CPUs und 4 GB Hauptspeicher beschränkt. Sie
enthält anders als die anderen Editionen bereits pureXML (s.u.), besitzt jedoch
einen etwas reduzierten Funktionsumfang.148

DB2 Express
Diese Edition ist auf 2 CPUs und 4 GB Hauptspeicher beschränkt, bei nutzerbasierten Lizenzen müssen mindestens 5 je Server erworben werden.

DB2 Workgroup
Diese Edition ist auf 4 CPUs und 16 GB Hauptspeicher beschränkt, bei nutzerbasierten Lizenzen müssen mindestens 5 je Server erworben werden.

DB2 Enterprise
Diese Edition ist hinsichtlich CPUs und Hauptspeicher unbeschränkt, bei nutzerbasierten Lizenzen müssen mindestens 25 je Prozessor erworben werden.
Auch IBM DB2 verfügt über einen großen Funktionsumfang. Mit Ausnahme der ExpressC-Edition bieten alle Editionen neben der in der Einleitung dieses Themas erwähnten
üblichen Funktionalität aktueller Datenbank-Managementsysteme auch eine Möglichkeit
zur Datenbankreplikation.
Wie bei Oracle kann der Funktionsumfang von DB2 optional erweitert werden. An dieser
Stelle werden beispielhaft einige dieser Optionen dargestellt:
148

Speicherplatzoptimierung
Mittels Datenkompression wird der für Tabellen benötigte Speicherplatz reduziert.

Tabellenpartitionierung
Große Tabellen können anhand der Werte in einer oder mehreren Spalten auf
mehrere Speicherobjekte verteilt werden. Die Tabellengröße wird somit nicht
mehr vom Datenbank-Managementsystem begrenzt, sondern nur noch vom vorhandenen Speicherplatz.

Datenbankpartitionierung
Große Datenbanken können über mehrere Server verteilt werden, ohne dass auf
Nutzer- und Anwendungsebene Anpassungen notwendig werden.

Verwaltung geodätischer Daten
IBM DB2 kann um Funktionen zur Verarbeitung geografischer Informationen
erweitert werden.

pureXML
Diese bei Express-C standardmäßig vorhandene und für die anderen Editionen
optional verfügbare Erweiterung speichert XML-Daten in einer speziellen hierarchischen Struktur, die deren effizientere Verarbeitung ermöglicht.
http://www-306.ibm.com/software/data/db2/express/getstarted.html
Seite 167
Zur Administration und Konfiguration von DB2-Datenbanken existieren verschiedene
Werkzeuge, darunter zum Beispiel:

DB2 Performance Expert
Die Performance von Datenbanken kann mit diesem Werkzeug analysiert werden. Zudem können Performance-Probleme identifiziert und behoben werden.

DB2 Query Patroller
Dieses Werkzeug dient der Überprüfung und Ausführungssteuerung für Abfragen. Abfragen können anhand verschiedener Parameter für eine sofortige oder
verzögerte Ausführung vorgesehen oder auch abgewiesen werden.
Als Besonderheit bezeichnet IBM die Möglichkeit eine „shared-nothing― Architektur mit
DB2 zu realisieren. Dabei werden die Daten auf unterschiedliche Datenbankknoten mit
Datentöpfen verteilt. Jeder Datentopf verfügt dabei über eigene Ressourcen wie Prozessor, Festplatten und Hauptspeicher. Zudem enthält jeder Datentopf eigene Daten,
das heißt in jedem Datentopf ist nur ein Teil der Gesamtmenge an Daten vorhanden.
Wird eine Anfrage an einen beliebigen Datenbankknoten gestellt, so fragt dieser die
jeweils benötigten Daten aus den einzelnen Datentöpfen ab und führt sie zusammen.
Eine Anfrage kann daher an jeden beliebigen Knoten gestellt werden. Laut Herstellerangaben hat diese Architektur Vorteile bei hochperformanten, parallelisierten Datenbanklösungen.
Für die Enterprise Edition existiert optional die flexible Vergabe von Zugriffsrechten auf
Spalten- und Zeilenebene über so genannte Labels. So kann sehr detailliert gesteuert
werden, auf welche Teile einer Tabelle welcher Nutzer in welchem Umfang zugreifen
darf149.
IBM DB2 lässt sich wie andere Datenbanksysteme auch aus selbst entwickelten
Anwendungen über entsprechende Schnittstellen ansprechen. Es existieren diverse
APIs150, sodass Datenbankanwendungen unter Verwendung von beispielsweise
Microsoft Visual Studio .NET, IBM WebSphere Studio Application Developer, aber auch
Eclipse entwickelt werden können. Als Programmiersprachen kommen dabei C, C++,
COBOL, Fortran, Java, Perl, PHP, REXX und alle .NET-Programmiersprachen in Frage.
Ergänzend existieren ODBC-, JDBC- und OLE-DB-Treiber.
Damit ist IBM DB2 ein leistungsfähiges Datenbanksystem mit umfangreicher Funktionalität, das in seinen unterschiedlichen Editionen verschiedenen Anforderungen gerecht
wird. Die IBM DB2 ist für eine große Zahl von Plattformen verfügbar.
2
Migrationspfade
Im Rahmen einer Migrationsstrategie spielen relationale Datenbank-Managementsysteme (RDBMS) insofern eine besondere Rolle, als sie immer mit mindestens einer
weiteren Anwendung verbunden sind. Idealerweise liegen die Daten einer Organisation
149
150
http://www-306.ibm.com/software/data/db2/9/editions_features_advaccess.html
Unter http://www-1.ibm.com/support/docview.wss?rs=71&uid=swg27009552 finden sich
zahlreiche Dokumente zu DB2, darunter insbesondere auch die folgende Datei, die einen
guten Überblick über die Möglichkeiten der Anwendungsentwicklung für DB2 bietet:
ftp://ftp.software.ibm.com/ps/products/db2/info/vr9/pdf/letter/en_US/db2axe90.pdf
Seite 168
in nur einem Datenbanksystem in normalisierter Form (ohne Redundanz) vor. Zudem ist
im Idealfall die Abfragesprache (SQL), mit der die Anwendungen auf der Datenbank
arbeiten, standardisiert und jede Anwendung sollte mit jedem RDBMS problemlos zusammenarbeiten. In der Realität finden sich in vielen IT-Infrastrukturen mehrere RDBMS,
in denen teilweise die gleichen Daten mehrfach verwaltet werden und die von verschiedenen Anwendungen mit unterschiedlichen SQL-Dialekten und hersteller-spezifischen
Spracherweiterungen sowie über herstellerspezifische Schnittstellen abgefragt werden.
Die Ausführungen in Kapitel II.A 1 zeigen, dass sich die einzelnen Datenbank-Produkte
in vielerlei Hinsicht voneinander unterscheiden. Als potenzielle Migrationshemmnisse
können sich unter anderem die Unterschiede in Bezug auf folgende Aspekte auswirken:

Erweiterte Funktionalitäten, die vom Standard abweichen oder darüber hinaus
gehen

Implementierte Datentypen

Implementierte Sicherheitsfunktionen

Angebotene Funktionen zur Notfallvorsorge und Hochverfügbarkeit, zum Beispiel
Clustering und Replikation

Unterstützte Betriebssysteme, auf denen die Datenbank-Produkte lauffähig sind

Angebotene Lizenzmodelle

Unterstützte Speicherformate

Verfügbare administrative Tools

Verfügbare Zusatzprodukte

Verfügbare Schnittstellen und Treiber

Unterstützte SQL-Dialekte

Vorgegebene Systemgrenzen, beispielsweise die maximale Größe von Feldern,
Tabellen und Datenbanken

Maximale Speicher- und Verarbeitungsgeschwindigkeit
Eine Migration bietet vor diesem Hintergrund die Chance, eine Konsolidierung der
Software- und Datenstrukturen durchzuführen. Gleichzeitig müssen bei einer Migration
neben dem Datenbestand i.d.R. auch die Anwendungen umgestellt werden, was in
vielen Fällen nicht ohne Eingriff in die Client-Software möglich ist. Unter Client-Software
wird in diesem Zusammenhang eine beliebige Anwendung verstanden, die auf die
Datenbank zugreift. Häufig läuft die Client-Software auf einem Applikationsserver. Selbst
wenn die Datenbankanbindung mittels ODBC oder JDBC standardisiert ist und keine
Trigger oder Stored Procedures verwendet werden, muss bei einer Datenbankmigration
clientseitig mindestens der ODBC/JDBC-Treiber ausgetauscht werden. Die Zentralisierung und Konsolidierung des Datenbestandes bedarf also offensichtlich einiger
Aufwände. Andererseits ist sie ein sehr attraktives Ziel, weil hierdurch im laufenden
Betrieb erhebliche Pflegeaufwände und damit Kosten reduziert werden können.
Für die Migration von Datenbankschemata gibt es herstellerunabhängige Tools, die eine
Migration zwischen beliebigen Datenbanken ermöglichen. Diese Tools können jedoch
Seite 169
längst nicht alle Probleme einer Datenbankmigration lösen. Problematisch sind in der
Regel der Einsatz proprietärer Datenbanktechnologien und die Migration der gegebenenfalls in der Datenbank vorhandenen Programmlogik. Aus diesem Grund sollten auch
im Hinblick auf zukünftige Migrationen relevante Aspekte beim Design einer Datenbanklösung beachtet werden:

Bei der Ausgestaltung einer Datenbanklösung sollte eine Orientierung an
herstellerunabhängigen Standards erfolgen. Die Anwendung von herstellerspezifischen Techniken, die Auswirkungen auf die restliche IT-Infrastruktur haben,
sollte vermieden werden. So sollten zum Beispiel die Anbindung an eine Datenbank über ODBC oder JDBC erfolgen und zur Datenabfrage ANSI SQL eingesetzt werden. Auf Stored Procedures und herstellerspezifische Erweiterungen
sollte wo immer möglich verzichtet werden.

Eine Datenbanklösung sollte sich auf die Kernfunktionalität einer Datenbank,
nämlich die strukturierte Sammlung und die Ablage von Daten in elektronischer
Form, konzentrieren. Insbesondere sollte auf die Trennung von Geschäfts- und
Datenhaltungslogik geachtet werden, wie dies u.a. auch von SAGA gefordert
wird. Das heißt die Programmlogik sollte in der Middleware realisiert werden und
nicht in der Datenbank, da ansonsten Migrationsprojekte sehr schwierig und
zeitintensiv werden können. Wenn eine Verlagerung von Geschäftslogik oder
Funktionalität vom Client hin zum Server gewünscht ist, lässt sich dies heute sehr
gut mit 3-Schicht-Architekturen erreichen. Im Sinne einer plattformunabhängigen
Implementierung bietet sich hier Java sowohl für den Client als auch für den
Applikationsserver (Tomcat u.a.) an. Wird Geschäftslogik hingegen in die
Datenbank verlagert, muss diese später ebenfalls migriert werden. Da für die
Implementierung der Geschäftslogik von den einzelnen Datenbanksystemen
unterschiedliche, häufig proprietäre Lösungen angeboten werden, können daraus
erhebliche Migrationsaufwände entstehen.

SQL Statements im Programmcode sollten isoliert und modularisiert werden.
Selbst wenn durch einen Wechsel des Datenbanksystems Änderungen an den
SQL Statements notwendig werden, lassen sich diese dann an zentralen, gekapselten Stellen innerhalb der Anwendungen durchführen.
Wurde eine Datenbank nach den oben beschriebenen Kriterien gestaltet, so ist in der
Regel eine Migration sowohl ablösend als auch fortführend möglich, unabhängig davon,
welches Quell- und Zielsystem zum Einsatz kommt. Hier spielen insbesondere die
individuellen Anforderungen, zum Beispiel an Performance oder RecoveryFunktionalitäten, eine Rolle. Aus diesem Grund werden an dieser Stelle nicht einzelne
Migrationspfade, sondern generell die ablösende beziehungsweise fortführende
Migration betrachtet. Unabhängig davon bleibt festzuhalten, dass Datenbankmigrationen
häufig komplex sind und dass in jedem Fall vor einer Migration genau geprüft werden
muss, welche spezifischen Probleme bei der jeweiligen Migration zu erwarten sind.
Neben der Datenbank an sich, muss bei einer Migration insbesondere auch die Anbindung der Anwendungen an die Datenbank berücksichtigt werden. Eine Standardisierung
der Datenbankanbindung über ODBC oder JDBC hilft hierbei, löst jedoch nicht alle Probleme. Beispielweise können Unterschiede in den SQL-Dialekten der beteiligten DatenSeite 170
banken zu erheblichen Migrationsaufwänden führen. Wurde keine saubere Trennung
zwischen Geschäftslogik und Datenhaltungslogik eingehalten, müssen zudem Stored
Procedures oder Trigger portiert werden.
Darüber hinaus können Änderungen innerhalb der Client-Anwendung selbst notwendig
werden. Neben den schon genannten Faktoren (Verwendung von Triggern und Stored
Procedures) spielt hierbei insbesondere die verwendete Programmierschnittstelle innerhalb des Clients eine Rolle. Wenn die Datenbankanbindung direkt über eine Schnittstelle
des Herstellers implementiert wurde (zum Beispiel embedded SQL), muss mit deutlich
mehr Aufwand gerechnet werden, als wenn eine Abstraktionsebene, wie zum Beispiel
ADO.NET, dazwischen geschaltet wurde. Zu beachten ist dabei, dass für eine Änderung
innerhalb der Anwendung deren Source Code verfügbar sein muss. Der Aufwand für die
notwendigen Änderungen hängt dabei auch von einer sauberen Architektur der Anwendung ab. Einen guten Überblick über Anwendungsarchitekturen vermittelt SAGA151.
Zu empfehlen ist in jedem Fall die Einbeziehung des Herstellers einer Anwendung. Die
feste Bindung an ein bestimmtes RDBMS wird auch seitens vieler Anbieter von Anwendungen als Marktnachteil gesehen, sodass von einer nennenswerten und wachsenden
Unterstützung bei einer Migration insbesondere zu einem Open Source RDBMS ausgegangen werden kann.
Zusammenfassend lässt sich sagen, dass eine erfolgreiche Migration neben den Besonderheiten der einzelnen Datenbanksysteme insbesondere davon abhängt, inwieweit im
Vorfeld der eigentlichen Migration bestimmte Regeln eingehalten wurden:
2.1

Standardisierter Datenbankzugriff z.B. über ODBC oder JDBC

Einsatz von herstellerunabhängigen Standards

Vermeidung von Programmlogik in der Datenbank

Einhaltung einer sauberen Trennung zwischen Datenhaltung und Geschäftslogik
in den Client-Anwendungen

Isolierung und Modularisierung der Datenbankzugriffe in den ClientAnwendungen

Einbeziehung der Hersteller der Client-Anwendungen

Konsolidierung von Software- und Datenstrukturen
Die ablösende Migration proprietärer und offener Datenbank-Systeme
Die technischen Betrachtungen zur Datenbank-Migration zeigen auf, dass neben den
proprietären relationalen Datenbank-Managementsystemen (RDBMS) von Microsoft,
IBM, oder Oracle durchaus leistungsfähige Lösungen auf der Basis von Open Source
Software (OSS) als Alternativen zur Verfügung stehen und eine ablösende Migration
rechtfertigen. Wichtige Vertreter solcher OSS-Lösungen sind MySQL, PostgreSQL und
Firebird.
151
siehe http://www.kbst.bund.de
Seite 171
Die aufgeführten OSS-Lösungen bieten unterschiedliche Funktionalitäten und ihre
Eignung muss im Einzelfall bezüglich der jeweiligen Anforderungen geprüft werden.
Hervorzuheben ist, dass alle genannten OSS-Lösungen plattformunabhängig sind und
auch installationsfertige Windows-Versionen als Download im Internet verfügbar sind.
Damit können diese Datenbanksysteme auch bei einer punktuellen oder einer betriebssystemübergreifenden Migration eingesetzt werden.
Datenbanken gehören zu den Wegbereitern für den Einsatz von Linux in unternehmenskritischen Anwendungsbereichen. Die Software AG hat mit AdabasD bereits 1997 ein
proprietäres (seinerzeit SAP-zertifiziertes) RDBMS für Linux angeboten. Oracle und Informix folgten 1998 und haben damit die Kredibilität von Linux im professionellen Umfeld
deutlich gesteigert. Die unter dem Acronym LAMP bekannte Kombination von Linux,
Apache, MySQL und PHP ist seit Beginn der kommerziellen Internetnutzung eine der
beliebtesten Infrastrukturen für Webshops und dynamische Webseiten. Mit PostgreSQL
und Firebird stehen vollwertige RDBMS mit Transaktionsunterstützung, Triggern und
Stored Procedures auch unter Open Source Lizenzen zur Verfügung. An hochwertigen
Optionen für den Einsatz von Linux und Open Source Software im Bereich der Datenbanksysteme mangelt es nicht.
Wenn die grundsätzliche Möglichkeit für eine Datenbankmigration gegeben ist, muss ein
geeignetes RDBMS als Zielsystem ausgewählt werden. Das Angebot an alternativen
Migrationszielen ist sowohl im proprietären als auch im Open Source Bereich vielfältig
und attraktiv. Eine pauschale, einfache und eindeutige Entscheidung für das eine oder
andere System lässt sich aus den charakteristischen Merkmalen nicht ableiten. Wichtig
ist deshalb, dass die möglichen Zielsysteme jeweils im Einzelfall anhand der tatsächlich
genutzten Funktionalitäten und anhand der als relevant erachteten Eigenschaften ausgewählt werden. Ein Ziel ist meist auch, möglichst wenig unterschiedliche Datenbanksysteme in einer Institution zu betreiben (Vereinheitlichung).
Bei der Übernahme von Daten aus Datentypen, die im Zielsystem nicht identisch vorhanden sind, ist es i.d.R. möglich, einen geeigneten Typ mit größerem Wertebereich zu
identifizieren. Hier muss vor allem bei großvolumigen Datentypen beachtet werden, dass
diese in einigen RDBMS nicht such- oder indizierbar sind, in anderen jedoch schon. Zudem muss beim Übergang zu einer ODBC-Anbindung darauf geachtet werden, dass
ODBC unterschiedliche Funktionsgruppen unterscheidet, das heißt dass zum Beispiel
ein ODBC-Treiber Level 1 nicht die gleiche Funktionalität bietet wie ein ODBC-Treiber
Level 2.
Für die ablösende Migration werden durch die Datenbankhersteller inzwischen
zahlreiche Tools angeboten. In der Regel ermöglichen diese Tools eine mehr oder
weniger automatisierte Migration von Datenbankobjekten, -schemata und den
eigentlichen Daten. Nur eingeschränkt möglich ist jedoch eine Automatisierung der
Migration der Geschäftslogik z. B. von Stored Procedures. Häufig können diese Tools
aber die Arbeit in einem Migrationsprojekt deutlich vereinfachen, da sie viele
Standardaufgaben, wie zum Beispiel die Umwandlung von Datentypen, deutlich
erleichtern. Im Folgenden werden einige Beispiele für Migrationswerkzeuge aufgeführt:
Seite 172

MySQL Migration Toolkit
Das MySQL Migration Toolkit erlaubt die Migration von Microsoft Access, Microsoft SQL Server oder Oracle Datenbanken nach MySQL. Das grafische Tool führt
anhand eines stufenweisen Vorgehens durch den gesamten Migrationsprozess.
Durch entsprechende Assistenten lassen sich Migrationsschritte automatisieren.
Darüber hinaus besteht auch die Möglichkeit, manuell in den Migrationsprozess
einzugreifen.
Laut Herstellerangaben besteht die Möglichkeit, das Toolkit beziehungsweise
einzelne Module des Toolkits anzupassen, sodass auch andere Datenbanksysteme auf MySQL migriert werden können.
Der Zugriff auf die zu migrierende Datenbankquelle erfolgt standardisiert über
JDBC. Dadurch spielt es keine Rolle, auf welchem Betriebssystem die QuellDatenbank installiert ist.

SQL Server Migration Assistant for Oracle (SSMA for Oracle)
Der SSMA for Oracle ermöglicht die weitgehend automatisierte Migration von
einer Oracle Datenbank zu einem Microsoft SQL Server. Neben der Migration der
Datenbankobjekte und der Daten erfolgt abschließend auch eine Validierung des
migrierten Codes und der Daten. Laut Herstellerangaben ist damit auch eine
Migration von Stored Procedures möglich.

Oracle Migration Workbench (OMWB)
Die Oracle Migration Workbench unterstützt die Migration von Sybase, Informix
und DB2 Datenbanken nach Oracle. Mit der Oracle SQL Developer Migration
Workbench verfügt Oracle zudem über ein Werkzeug, mit dem sich Microsoft
Access, Microsoft SQL Server und MySQL Datenbanken nach Oracle migrieren
lassen. Für die Überprüfung der Migration stellt Oracle den Database Migration
Verifier (DMV) zur Verfügung. Damit lassen sich sowohl die Struktur als auch die
Daten überprüfen.

IBM Migration Toolkit
Das IBM Migration Toolkit unterstützt unter anderem die Migration von Oracle,
Microsoft SQL Server und MySQL hin zu DB2 und Informix. Neben Datenbankschemata und Daten kann auch Logik in Form von Triggern oder Stored
Procedures migriert werden. Auch die Anwendungsmigration wird durch einen
Wizard zur Migration von Queries unterstützt (zum Beispiel Umwandlung von
proprietären Joins in Standard-Joins).

Weitere Migrationstools
Neben den Migrationstools der einzelnen Hersteller gibt es zahlreiche weitere
Tools, die eine Migration erleichtern können. Beispielhaft sei an dieser Stelle der
eva/3 Universal Database Converter genannt, der die Migration von Tabellenstrukturen und Daten zwischen allen in diesem Leitfaden beschriebenen
Datenbanksystemen unterstützt. Zudem ist es mittels sogenannter ETL-Tools
(Extraction-Tranformation-Loading) wie der OSS-Lösung Pentaho Data Integra-
Seite 173
tion möglich, auch komplexe Transformationen von einer Datenbank zu einer
anderen durchzuführen.
Generell kann festgehalten werden, dass sich Standardaufgaben im Rahmen eines Migrationsprojektes mit den angebotenen Tools gut lösen lassen. Darüber hinaus bieten
einige Werkzeuge auch Hilfestellung bei der Migration der Geschäftslogik. Die Erfahrung
zeigt jedoch, dass diese Aufgabe aufgrund ihrer Komplexität i.d.R. nur in Teilen durch
die Werkzeuge erledigt werden kann. Die Hauptarbeit muss an dieser Stelle manuell
erfolgen und stellt wohl häufig das größte Problem bei der Migration von Datenbanken
dar.
2.2
Fortführende Migration von Datenbank-Systemen
Naturgemäß haben die Hersteller ein Interesse daran, dass die aktuellen Versionen ihrer
Datenbanksysteme eingesetzt werden. Zwar wird die fortführende Migration i.d.R. von
allen Herstellern durch entsprechende Tools unterstützt, es muss aber trotzdem in jedem
Einzelfall sorgfältig geprüft werden, inwieweit Probleme aufgrund einzelner technischer
Besonderheiten zu erwarten sind. Da es sich hierbei häufig um sehr spezifische technische Feinheiten handelt, kann an dieser Stelle keine Aussage dazu getroffen werden,
welche konkreten Probleme im Einzelfall zu erwarten sind. Wie auch bei der ablösenden
Migration steigt jedoch im Allgemeinen die Anzahl der möglichen Probleme, je mehr
proprietäre Funktionalitäten eingesetzt werden und je komplexer und umfangreicher die
Geschäftslogik innerhalb der Datenbank ist.
Um einen Umstieg auf neuere Versionen auch bei problematischen Migrationsvorhaben
zu ermöglichen, bietet z. B. Microsoft die Möglichkeit, den SQL Server 2005 im Kompatibilitätsmodus zu betreiben, das heißt der SQL Server 2005 verhält sich in diesem Fall
wie ein SQL Server 2000. Eine solche Lösung sollte aber bestenfalls eine Zwischenlösung sein, bis eine „echte― Migration durchgeführt wird.
Probleme ergeben sich häufig auch, wenn bei einer fortführenden Migration mehrere
Versionen eines Datenbanksystems übersprungen werden. Oft beachten die Hersteller
bei der Entwicklung neuer Datenbanksysteme nur die letzten Versionen als Migrationsquelle und bieten daher keine Werkzeuge an, die eine Migration älterer Versionen des
Datenbanksystems unterstützen. Es ist auch nicht davon auszugehen, dass bei den
Herstellern umfassendes Wissen für eine solche Migration verfügbar ist. Es kann daher
notwendig sein, diese Art der Migration in mehreren Versionsschritten durchführen,
wodurch sich der Aufwand insbesondere beim Testen erheblich erhöht.
Neben der Migration des Datenbanksystems an sich kann auch eine Migration unter
Beibehaltung des Datenbanksystems von Vorteil sein, beispielsweise wenn nur das darunter liegende Betriebssystem ausgetauscht wird. Hierbei ist es zum Beispiel auch
denkbar, eine Mischung aus proprietärer und Open Source Software einzusetzen. So
kann ein proprietäres Datenbanksystem wie Oracle zum Beispiel auch unter Linux betrieben werden.
Seite 174
B Thema Webserver
Der ursprüngliche Einsatzzweck von Webservern ist die Bereitstellung von statischen
Informationen, insbesondere Webseiten, sodass diese über einen Webbrowser
angezeigt werden können. Durch die Einsatzmöglichkeiten von Scriptsprachen wie zum
Beispiel Perl wird diese Funktionalität um die Bereitstellung dynamischer Inhalte
erweitert. Heutige Webserver wie der Apache oder der Microsoft IIS bieten weitere
zahlreiche Funktionalitäten, die den klassischen Webserver mehr und mehr zu einem
vollwertigen Applikationsserver ausbauen, der in der Lage ist, komplexe Anwendungen
auszuführen.
Aktuell verfügen die beiden betrachteten Webserver über alle wesentlichen Merkmale,
die von einem modernen Webserver zu erwarten sind und gehen an vielen Stellen auch
darüber hinaus. Beispielsweise verfügen beide Webserver über Mechanismen zur
Authentifizierung und Verschlüsselung.
1
1.1
Apache HTTP Server
Der Apache HTTP Server geht auf eine Weiterentwicklung des NCSA HTTPd im Jahre
1995 zurück. Er wird von der Apache Software Foundation unter der Apache License als
Open Source Software frei zur Verfügung gestellt. Aktuell ist die Version 2.2 verfügbar,
aber auch die Versionen 2.0 und 1.3 werden noch angeboten und gepflegt.
Auch wenn der Apache HTTP Server Marktanteile eingebüßt hat, ist er gemäß einer
regelmäßig durch Netcraft durchgeführten Umfrage152 noch immer der am meisten eingesetzte Webserver. Seine Bedeutung zeigt sich auch darin, dass - aufbauend auf dem
Apache HTTP Server und weiteren Komponenten – festgelegte Systemarchitekturen
definiert wurden. Beispielsweise steht LAMP für eine Architektur bestehend aus den
Komponenten Linux, Apache, MySQL und PHP.
Der Apache HTTP Server besteht aus seinem Kern und einer großen Anzahl von Modulen, die in Abhängigkeit von den jeweiligen Anforderungen einkompiliert beziehungsweise geladen werden können. Durch den modularen Aufbau ist der Apache-Server sehr
leicht erweiterbar und kann an geänderte Anforderungen angepasst werden. Im normalen Lieferumfang der Software sind schon zahlreiche unterschiedliche Apache Module
enthalten. Diese können noch durch weitere Module (zum Beispiel Eigenentwicklungen)
erweitert werden.
Apache Module sind Codesegmente, die der Apache API Spezifikation entsprechen und
in den Apache HTTP Server geladen werden können. Sie werden für Funktionalitäten
verwendet, die über den herkömmlichen Dienst eines Webservers hinaus gehen. So
können zum Beispiel sichere Authentifizierung oder Techniken wie Server Side Includes
(SSI) problemlos realisiert werden. Dazu muss lediglich die Moduldatei vorhanden sein
und ein entsprechender Eintrag in der Konfigurationsdatei editiert werden. Bei Bedarf
152
http://news.netcraft.com/archives/2007/09/03/september_2007_web_server_survey.html
Seite 175
werden die Module dann von dem Webserver dynamisch geladen. Alternativ können
Module auch zum Zeitpunkt des Kompilierens statisch in den Apache Webserver eingebunden werden. Dieses Vorgehen ist dann effizient, wenn Modulfunktionalitäten sehr
häufig vom Webserver benötigt werden.
Wenn der Apache sorgfältig konfiguriert wird und nur die tatsächlich benötigten Module
benutzt werden, wird weniger Speicherplatz benötigt. Gleichzeitig bedeuten weniger Module in der Regel auch weniger Angriffsfläche, wodurch die Sicherheit des Systems erhöht wird. Der genaue Umfang der in der verwendeten Distribution enthaltenen Module
ergibt sich aus der Dokumentation zur jeweiligen Version.
Das modulare Design zur Erweiterung von Web-Server Eigenschaften erhöht die Flexibilität des Systems. Gleichzeitig verbessert sich die Effizienz und die Geschwindigkeit des
Web-Servers, wenn anstelle von externen Applikationen interne Prozesse abgearbeitet
werden können.
Für Migrationsprojekte sind heute weniger die Migration des Apache an sich von Bedeutung. Vielmehr zeigt die Praxis, dass insbesondere den Modulen besondere Aufmerksamkeit gewidmet werden muss. Zu den zahlreichen Modulen gehören u.a.:

Authentifikationsmodule (zum Beispiel mod_auth)

Sicherheitsmodule (zum Beispiel mod_ssl)

Skript- beziehungsweise Interpretermodule für Programmiersprachen, wie zum
Beispiel PHP, Java, Python, Tcl und Perl.
Die folgende Tabelle gibt eine kleine Auswahl der verfügbaren Module wieder. Die Auflistung ist nicht vollständig, sie soll jedoch einen Eindruck von den vielfältigen Möglichkeiten des Apache-Webservers vermitteln.
Modul
Funktion
Standard- und Zusatz-Module
mod_cgi
Ausführung von CGI-Skripten (Common Gateway Interface)
mod_dav
eIntegrierte DAV Unterstützung (HTTP Extensions for Distributed
Authoring – WebDAV). Bearbeiten von Dateien und Verzeichnissen
direkt über HTTP auf dem Webserver. DAV steht für Distributed
Authoring and Versioning
mod_fastcgi
Integrierte FastCGI Unterstützung
mod_frontpage
Integrierte FrontPage Unterstützung
mod_iserv
Integrierte Java Servlet Unterstützung
mod_php3
Integrierte PHP 3 Unterstützung
mod_php4
Integrierte PHP 4 Unterstützung
mod_perl
Integrierte Perl Unterstützung
mod_alias
Stellt die Alias- beziehungsweise Redirect-Anweisungen zur Verfügung
Seite 176
Modul
Funktion
mod_autoindex
Generiert Verzeichnisindizies
mod_include
Wird benötigt für Server-Sides Includes
mod_mime
Sorgt für Generierung entsprechender MIME-Headers
mod_log_config
Zur Führung von einer oder mehrerer Logfiles, der Inhalt kann an die
entsprechenden Bedürfnisse angepasst werden
mod_deflate
Dient der Komprimierung von verschiedenen Dateitypen vor der
Übertragung zum Browser. Ist insbesondere bei eingeschränkten
Bandbreiten sinnvoll, die Kompression muss von den Browsern unterstützt werden
mod_proxy
Erweitert den Apache-Webserver um die Funktionalität eines Proxys
beziehungsweise Proxy-Caches
mod_rewrite
Ermöglicht die Verwendung von internen Aliasen und externen Redirects
mod_speling
Korrigiert Tippfehler der Benutzer
mod_ssl
Stellt die Protokolle SSL (Secure Sockets Layer) und TLS (Transport
Layer Security) zur Verfügung
mod_usertrack
Mittels HTTP-Cookies wird das Nutzerverhalten protokolliert
mod_vhost_alias
Für die Konfiguration von vielen virtuellen Hosts, insbesondere für
Service-Provider interessant
Module zur Authentifizierung
mod_access
Zugriffskontrolle auf Basis von Hostnamen oder IP-Adressen
mod_auth
Für die Konfiguration von passwortgeschützten Verzeichnissen beziehungsweise Dokumenten. Sehr einfache Variante eines Authentifizierungsmoduls, sollte nur bei einer geringen Anzahl von Nutzern
angewendet werden
mod_auth_digest
Nutzer- Authentifikation mittels MD5 Digest Authentication, die
Übermittlung der Passwörter erfolgt nicht im Klartext
mod_auth-dbm
Nutzer-Authentifikation mittels Berkeley-DB-Dateien, sinnvoll für die
Verwendung bei einer größeren Anzahl von Benutzern
mod_auth_ldap
Nutzer-Authentifikation mittels LDAP
mod_auth_kerb
Nutzer-Authentifikation mittels Kerberos, unterstützt die Versionen 4
und 5
mod_auth_notes
Nutzer-Authentifikation mittels Lotus Notes Server
mod_auth_oracle
Nutzer-Authentifikation mittels Oracle-Datenbank, es gibt auch noch
weitere Module für beispielsweise MySQL und PostgresDatenbanken
mod_auth_smb
Nutzer-Authentifikation mittels SMB-Server (Samba, Windows NT)
Tabelle 38: Apache-Module
Seite 177
Nicht alle Module für den Webserver stehen kostenlos zur Verfügung. Immer mehr Unternehmen bieten die Apache Module gegen entsprechende Lizenzkosten an. Beispiele
hierfür sind:

Allaire mit der Java-Servlet-Engine Macromedia JRun und dem ApplicationServer Macromedia ColdFusion,

Sun Microsystems mit seinem Active Server Pages Modul.
Die Administration des Webservers erfolgt mittels gut dokumentierter Konfigurationsdateien (Textdateien). Für das Aktivieren einer Funktionalität genügt es häufig, in einer
entsprechenden Zeile dieser Textdatei das Kommentarzeichen mit Hilfe eines einfachen
Texteditors zu löschen. Für Administratoren, die eine grafische Oberfläche bevorzugen,
gibt es alternativ proprietäre und Open Source Tools zur Apache-GUI153.
Für die Integration einer Suchfunktionalität innerhalb einer Website kann der ApacheWebserver durch ein entsprechendes Programm ergänzt werden. Es stehen unterschiedliche Softwareeinheiten zur Auswahl, zum Beispiel das Suchsystem HTDig154.
HTDig ermöglicht die Indexierung ganzer Websites. Das Programm erzeugt mittels eines
sogenannten Robots einen Suchindex, der über ein geeignetes CGI-Skript abgefragt
werden kann. Die folgenden Punkte geben die Kernfunktionalitäten der Software wieder:

Anlage eines Suchmaschinen-Index (über eine oder mehrere Webseiten beziehungsweise Teilbereiche einer Webseite).

Einschränkung der Indexierung durch die Verwendung von Filtern (Filterkriterien
können Dateitypen und bestimmte URLs sein).

Indexierung von für Web-Server untypischen und binären Dateiformate (PDF.
DOC, usw.), durch die Verwendung von externen Zusatzprogrammen

Verwendung von zahlreichen Abfragemöglichkeiten und verschiedenen Suchalgorithmen (Wörter, Wortteile, Synonyme, usw.).

Anpassung der Suchseite und der entsprechenden Trefferliste über einfache
Templatedateien.

Unterstützung von Sonderzeichen wie Umlaute.

Unterstützung des Standards für „Robot Exclusion― und die „Basic-WWWAuthentication― durch den verwendeten Robot, zur Berücksichtigung geschützter
Inhalte bei der Indexierung.
Die HTDig-Distribution wird unter der GNU General Public License (GPL) bereitgestellt
und steht somit zur freien Verfügung.
Der Apache bietet eine ganze Reihe von Modulen, mit denen sich unterschiedlichste
Arten einer Nutzer-Authentifikation umsetzen lassen, zum Beispiel die Authentifikation
mittels Kerberos 4 oder 5. Andere Möglichkeiten sind die Authentifikation mittels Samba
oder Datenbanken wie zum Beispiel Oracle, MySQL oder Postgres. Eine verschlüsselte
Datenübertragung mittels SSL und TLS (Transport Layer Security) ist ebenfalls möglich.
153
154
http://gui.apache.org/
http://www.htdig.org/
Seite 178
Mittels HTTP 1.1 Kompression lassen sich die Daten zudem bei der Datenübertragung
komprimieren.
Eine verschlüsselte Passwortübertragung kann über eine MD5 Digest Authentication
realisiert werden.
Die Konfiguration der Zugriffskontrolle ist auf Basis von Hostnamen oder IP-Adressen
möglich. Auch die Einrichtung von virtuellen Hosts (Multiple Web Sites mit einer IPAdresse) ist möglich.
Über die unterschiedlichen Module und Komponenten lässt sich der Apache um zahlreiche unterschiedliche Schnittstellen und Technologien erweitern. So ermöglicht es zum
Beispiel Tomcat155, JSPs und Java Anwendungen unter Apache laufen zu lassen. Auf
diese Weise lässt sich eine Interoperabilität des Apache auf technischer Ebene mit den
unterschiedlichsten Technologiestacks herstellen, seien es Skriptsprachen, Java, Datenbanken oder Verzeichnisdienste. Selbst Module, die ASP.Net Anwendungen unterstützen, sind verfügbar. Mit mod_mono steht zum Beispiel ein Modul auf Grundlage von
Mono156 - einer Software für Entwicklung und Betrieb von .Net Anwendungen unter unterschiedlichen Betriebssystemen (zum Beispiel Linux oder Unix) - zur Verfügung. Durch
die Vielzahl der Module bietet der Apache damit zahlreiche Funktionalitäten, die über
einen klassischen Webserver hinausgehen und eher einem Applicationserver zuzuordnen sind. Ein weiteres Beispiel für die Einsatzmöglichkeiten des Apache HTTP Servers
ist die Microsoft FrontPage Servererweiterung, die auch mit dem Apache HTTP Server
genutzt werden kann.
Im Fazit gehört der Apache Webserver zu den führenden Webservern am Markt. Auf
Basis von LAMP (Linux, Apache, MySQL, PHP) werden große Websites wie zum Beispiel Wikipedia mit dem Apache Webserver betrieben157. Der Apache kommt nicht nur im
Open Source Umfeld vor, sondern auch in Systemumgebungen mit kommerziellem Hintergrund hat er einen hohen Marktanteil. Aufgrund seiner Modularität und der Vielfältigkeit seiner Erweiterungsmöglichkeiten lässt er sich auf unterschiedlichste Anforderungen
anpassen. Die Projekterfahrungen zeigen, dass er auch für große Systemumgebungen
geeignet ist.
1.2
Microsoft Internet Information Services (IIS)
Bei den Microsoft Internet Information Services (IIS) handelt es sich um einen proprietären Datei- und Anwendungsserver. In früheren Versionen wurde der IIS unter der Bezeichnung Internet Information Server vertrieben. Der IIS wurde von Microsoft erstmals
für Windows NT angeboten. Heute wird er in der Regel integriert in das Windows Betriebssystem ausgeliefert.
Neben dem Apache Webserver zählen die IIS zu den am meisten eingesetzten Produkten im Webserverbereich.158
155
156
157
158
http://tomcat.apache.org/
http://www.mono-project.com/
http://de.wikipedia.org/wiki/LAMP#_note-online-artikel
http://news.netcraft.com/archives/2007/09/03/september_2007_web_server_survey.html
Seite 179
Aktuell steht die Version 6.0 auf Windows Server 2003 zur Verfügung, die Version 7.0
wird voraussichtlich Anfang des Jahres 2008 als Bestandteil des Windows Server 2008
verfügbar sein.
1.2.1
Internet Information Services 5.0
Die IIS sind integraler Bestandteil der Serverversionen von Microsoft Windows ab Version Windows 2000 Server. Neben den Standardprotokollen wie zum Beispiel HTTP, FTP,
SMTP, POP3 unterstützt die Nachfolger-Version des Internet Information Servers 4.0
zahlreiche neue Funktionalitäten. Die wichtigsten Neuerungen im Bereich Datenbereitstellung werden nachfolgend erläutert:

WebDAV:
Unterstützung des WebDAV-Standards zum gemeinsamen Bearbeiten von Dateien und Verzeichnissen direkt über HTTP auf dem Webserver.

Web-Verzeichnisse:
Sie dienen den Nutzern als herkömmliche Dateiverzeichnisse auf dem WebServer und stehen unmittelbar im Zusammenhang mit der WebDAVFunktionalität.

Frontpage Unterstützung:
Zusätzliche Funktionalitäten für die Entwicklung und Verwaltung von Webinhalten
mittels Microsoft Frontpage. Mittels des grafischen Frontend kann der Administrator Web-Inhalte auf den Web-Server erstellen und verändern.

Unterstützung von multiplen Web-Sites:
Erlaubt das Hosting von verschieden Web-Sites auf einem Server und einer IPAdresse.

HTTP 1.1-Kompression:
Ermöglicht die HTTP-Kompression bei der Kommunikation zwischen dem WebServer und dem kompressionsfähigen Client-System, die insbesondere bei eingeschränkten Bandbreiten sinnvoll sein kann.

PICS Rating:
„Platform for Internet Content Selection―159-Rating ist ein technischer Standard
zum Einsatz eines Bewertungssystems von Webinhalten des W3-Konsortiums.
Mit PICS verbinden sich die inhaltliche Bewertung und die Möglichkeit der Filterung von Webseiten nach bestimmten Merkmalen. Dazu wird im HTML-Header
eines Dokuments ein PICS-Code eingefügt, der im Browser nicht sichtbar ist.
Im Bereich webbasierte Applikationen bietet der IIS 5.0 folgende Neuerungen:

159
XML-Integration:
Ein XML-Parser in Windows 2000 ist als COM-Komponente implementiert und
stellt eine vollständige XML-Basis für Anwendungen zur Verfügung.
http://www.w3.org/PICS/
Seite 180

Windows Skript Komponenten:
Entwickler können mittels der Skripting-Technologie wiederverwendbare COM
Module für Webanwendungen entwickeln.

Bestimmung der Browser-Eigenschaften:
Mittels ASP können neben der Entwicklung von ASP Anwendungen die genauen
Browser-Eigenschaften der Client-Systeme ermittelt werden.

Prozess-Trennung:
Der Administrator kann einzelne Applikations-Prozesse von den Kern-Prozessen
und anderen Anwendungsprozessen isolieren.

ADSI 2.0:
Erlaubt den Zugriff auf die Objekte, Eigenschaften und Methoden des Active Directory Service Interfaces. Die Integration des Web-Servers und des Active Directorys ermöglicht die Zuweisung von unterschiedlichen Web-Sites auf einen
Web-Server zu bestimmten Nutzer-Domänen.
Im Bereich Verwaltung bietet der IIS 5.0 im Wesentlichen folgende Funktionalitäten:

Management Delegation:
Erlaubt die Übertragung von Verwaltungsaufgaben.

Prozess Throttling:
Ermöglich die Begrenzung der CPU-Zeit für eine Netzanwendung oder Seite.
Damit kann sichergestellt werden, dass Prozessorzeit für andere Websites oder
für Nicht-Netzanwendungen verfügbar ist.
Die IIS 5.0 bieten die Möglichkeit, die Nutzer-Authentifikation mittels Kerberos durchzuführen. Die alte Windows-Anmeldung mittels Windows LAN Manager (NTLM) ist jedoch
immer noch möglich. Eine verschlüsselte Datenübertragung ist unter Anwendung von
SSL 3.0 und TLS (Transport Layer Security) möglich. Es werden Client- und Serverzertifikate unterstützt.
Über die Digest Authentication wird die verschlüsselte Passwortübertragung für die Authentifizierung ermöglicht. Die Anmeldeinformationen werden dabei als MD5-Hash
übermittelt.
Über IP- und Domänenbeschränkungen erhält der Administrator die Möglichkeit, den
Zugriff auf Inhalte für Computer und Domänen zu erlauben beziehungsweise zu verbieten.
1.2.2
Internet Information Services 6.0
Zum Lieferumfang des Windows Server 2003 gehören die Internet Information Services
6.0 (IIS 6.0), die jedoch in der Standardinstallation des Betriebssystems erstmalig nicht
automatisch installiert werden. Der Administrator muss den Installationsvorgang explizit
initialisieren und bestimmte Server-Funktionalitäten aktivieren.
Durch Kombination mit den folgenden Technologien aus der Windows 2003 Server Produktgruppe gehen die IIS über die klassischen Möglichkeiten eines Webservers hinaus
hin zu einem Applikationsserver:

ASP.NET
Seite 181

ASP

COM+

Microsoft Message Queuing (MSMQ)
Für diese neue Rolle der Internet Information Services als Bestandteil eines Applicationservers wurden einige Neuerungen implementiert, die nachfolgend skizziert werden:

Zuverlässigkeit und Skalierbarkeit:
Für Verbesserungen im Hinblick auf Zuverlässigkeit und Skalierbarkeit wurden
innerhalb der Verarbeitungsarchitektur Änderungen vorgenommen. So können
Fehler automatisch erkannt und im Bedarfsfall Prozesse neu gestartet werden.
Dadurch wird das in den bisherigen Versionen vorhandene Risiko minimiert, dass
der Ausfall einer einzelnen Anwendung zum Ausfall aller Anwendungen führt. Parallel kann der Web-Server eingehende Anforderungen in einer Warteschlange
aufnehmen. IIS 6.0 ist in der Lage, die Statusüberwachung von Arbeitsprozessen, Anwendungen und Websites durchzuführen.

.Net-Integration:
Neu ist auch die Integration von ASP.NET in IIS. Den Entwicklern werden erweiterte Funktionalitäten des .NET Framework zur Erstellung von Anwendungen angeboten. Für Entwickler und Anwender kann zur Internationalisierung UnicodeStandard genutzt werden.
Der IIS 6.0 kann in das Autorisierungsframework des Windows 2003 Servers mit eingebunden werden, zusätzlich können mit dem Autorisierungs-Manager Delegierungs- und
Autorisierungsaktionen vorgenommen werden.
Die Verwaltung des IIS 6.0 erfolgt nun auf XML-Metabasis und ermöglicht den Administratoren ein direktes Bearbeiten der Konfiguration. Eine Nutzung von Kerberos ist möglich, sofern der Client Kerberos unterstützt und ein Active Directory zur Verfügung steht.
Zusammenfassend ist zu bemerken, dass die IIS ursprünglich als reine Webserver eingeführt wurden, inzwischen haben sie sich aber insbesondere durch die Integration mit
.Net die Internet Information Services zu einem Basisbestandteil der Applicationserverlösung von Microsoft entwickelt. Im Zuge dieser Entwicklung wurde von Microsoft verstärkt
Wert auf betriebskritische Themen wie Sicherheit oder Skalierbarkeit gelegt, sodass
auch in diesen Bereichen deutliche Verbesserungen im Vergleich zu älteren Versionen
des IIS vorliegen. Konkrete Projekterfahrungen zeigen, dass sich die IIS 6.0 als stabile
Alternative zu anderen Webservern auch in größeren Systemumgebungen einsetzen
lassen.
2
Migrationspfade
Bei der Migration von Webservern können grundsätzlich zwei mögliche Herausforderungen unterschieden werden:

Migration von statischen Inhalten

Migration von dynamischen Inhalten
Seite 182
Die hierbei zu lösenden Probleme stellen sich im Wesentlichen für alle WebserverProdukte in gleicher Form.
Das klassische Einsatzszenario eines Webservers war ursprünglich die Bereitstellung
von statischen Inhalten, zum Beispiel von statischen Webseiten oder Bildern. Auch die
Bereitstellung anderer Dateien wie zum Beispiel PDF Dokumenten fällt in diese Kategorie. Wird ein Webserver nur für solche Einsatzzwecke genutzt, ist eine Migration vergleichsweise einfach, da die statischen Inhalte in der Regel lediglich vom alten auf den
neuen Webserver kopiert werden müssen. Erst wenn weitere Anforderungen wie zum
Beispiel der Schutz von Dateien vor unberechtigtem Zugriff hinzukommen, sind darüber
hinaus weitere Aktivitäten notwendig.
Anders verhält es sich bei der Nutzung eines Webservers für die Bereitstellung dynamischer Inhalte. Darunter werden Scripte (zum Beispiel in Perl oder PHP) und Anwendungen zum Beispiel auf Basis von Java oder .Net verstanden. Insbesondere im Bereich der
Anwendungen verschwimmen dabei heute die Grenzen zwischen Webserver und Applikationserver. Grundsätzlich bleibt jedoch festzuhalten, dass eine Migration von dynamischen Webseiten oder Anwendungen häufig mit vergleichsweise hohem Aufwand verbunden ist. Gegebenenfalls kann es sogar notwendig werden, die gesamten Anwendungen neu zu implementieren.
Auf welcher Plattform (Windows oder Linux) ein Webserver dabei betrieben wird, spielt
hinsichtlich der Migration, nur eine sehr untergeordnete Rolle, darin sind sich die Experten weitgehend einig. Eine weitere Betrachtung erfolgt daher nicht. Ebenso wird an dieser Stelle darauf verzichtet, das den dynamischen Inhalten typischerweise unterliegende
Datenbanksystem zu betrachten. Eine weiterführende Behandlung dieses Themas findet
sich im Abschnitt II.A 1.
Im Folgenden werden vor allem die Migrationspfade der ablösenden Migration (ein
Wechsel des eingesetzten Webserver-Produktes) sowie die fortführende Migration (die
Beibehaltung der bestehenden Produktlinie) betrachtet. Dabei werden die grundsätzlichen Möglichkeiten aufgezeigt, notwendige Schritte erläutert und Hinweise gegeben, wo
Probleme bei der Migration auftreten können und wie mit diesen umgegangen werden
kann. Dies wird beispielhaft an mehr oder weniger konkreten Sachverhalten und den
zuvor betrachteten Webserver-Produkten verdeutlicht.
2.1
Die ablösende Migration proprietärer und offener Webserver
In der Regel erfolgt eine ablösende Migration von Webservern im Rahmen eines generellen Technologiewechsels. Häufig werden dabei neue Anforderungen umgesetzt, sodass meist keine klassische Migration, sondern eine Neuimplementierung erfolgt.
Wie eingangs beschrieben, bereitet die Migration von statischen Daten in der Regel
kaum Probleme. Die Webserver unterscheiden sich jedoch durchaus in der Art und Weise, wie sich weitergehende Anforderungen zum Beispiel an den Zugriffsschutz Verschlüsselung usw. umsetzen lassen. Hier ist in jedem Fall eine Prüfung aufgrund der
individuellen Anforderungen des jeweiligen Migrationsprojekts notwendig.
Eine (automatische) Übernahme von Konfigurationsdaten ist bei einem Wechsel des
Produkts (egal ob proprietär oder offen) in der Regel nicht möglich. Daher besteht die
Seite 183
Hauptaufgabe bei einer Migration zunächst darin, die neuen Webserver so aufzusetzen
und zu konfigurieren, dass alle Anforderungen erfüllt werden.
Die bei weitem größte Herausforderung liegt erfahrungsgemäß bei der Migration dynamischer Inhalte. Hier bereiten unterschiedliche Versionsstände und kleinere Unterschiede in der Implementierung der einzelnen Technologien in den Webservern Probleme.
Beispielsweise kann es vorkommen, dass der Interpreter für die benötigte Scriptsprache
für den abzulösenden Webserver eine neuere Version der Scriptsprache unterstützt als
der Interpreter für den Zielserver. Auch wenn zum Beispiel auf den unterschiedlichen
Produkten die benötigte Scriptsprache verfügbar ist, kann nicht davon ausgegangen
werden, dass eine Migration der Scripte ohne Anpassungsbedarf möglich ist.
Aufgrund der unterschiedlichen Ausrichtungen verschiedener Produkte kann es vorkommen, dass nicht alle Technologien auf dem jeweils anderen Produkt verfügbar sind.
Während zum Beispiel die Microsoft Internet Information Services (IIS) stark auf .Net
Technologien setzen, liegt der Schwerpunkt des Apache HTTP Servers eher im Script
und Java-Umfeld. Trotzdem ist es aufgrund der verfügbaren Module möglich, auch .Net
Anwendungen unter dem Apache HTTP Server zu betreiben. Allerdings muss damit gerechnet werden, dass diese Anwendungen angepasst oder in Teilen neu entwickelt werden müssen. Umgekehrt können Java Anwendungen nicht unverändert unter den IIS
verwendet werden. Hier ist in der Regel eine vorherige Konvertierung des Codes notwendig. Auch hierbei muss mit erheblichen Problemen und größeren Anpassungen an
den Anwendungen gerechnet werden. Je nach Komplexität der zu migrierenden Anwendung kann es bei einem Wechsel des Webservers daher sinnvoll sein, die Anwendung in
der jeweils anderen Technologie komplett neu zu entwickeln
Ein weiteres Problem bei der Migration ist die möglicherweise vorhandene Integration
der Produkte in die weitere IT Infrastruktur. Insbesondere bei Microsoft entstehen in der
Praxis häufig Anwendungen mit Abhängigkeiten zu anderen Microsoft Produkten wie
zum Beispiel dem Active Directory oder Share Point. Neben der Migration des Webservers muss daher auch die Migration dieser Abhängigkeiten beziehungsweise der dahinterstehenden Produkte geplant werden.
Da auf der anderen Seite beispielsweise der Apache HTTP Server je nach Einsatzzweck
häufig durch Module oder weitere Produkte wie zum Beispiel Tomcat erweitert wird, entstehen auch hier häufig Abhängigkeiten. Somit ist hier insbesondere zu prüfen, ob die
durch die Erweiterungen bereitgestellten zusätzlichen Funktionalitäten und Technologien
(zum Beispiel Tomcat für den Einsatz von Java) auf dem neuen Webserver verfügbar
sind.
Prinzipiell lässt sich ein Webserver zwar auch so betreiben, dass diese Abhängigkeiten
minimiert werden und bei einer Migration keine Probleme bereiten. In der Praxis lassen
sich damit aber häufig nicht alle notwendigen funktionalen Anforderungen erfüllen. Spätestens dann, wenn zum Beispiel Anforderungen im Bereich Sicherheit oder dynamische
Inhalte zum Beispiel in Form von Scripten oder Anwendungen hinzukommen, lassen
sich gewisse Abhängigkeiten in der Regel nicht vermeiden.
Seite 184
2.2
Fortführung der Produktlinie von Webservern
Unabhängig davon, ob proprietäre oder offene Webserver zum Einsatz kommen, ist die
Migration des eigentlichen Webservers bei einer fortführenden Migration eher kein Problem. Auch die Übernahme der statischen Inhalte sollte problemlos möglich sein. Dabei
spielt es für gewöhnlich keine Rolle, ob bei der Migration das Betriebssystem gewechselt
wird oder nicht, wie zum Beispiel eine Migration von Apache auf Windows zu Apache auf
Linux. In diesem Fall spielt dann eher die Migration der mit dem Wechsel des Betriebssystems einhergehende Wechsel der Infrastrukturdienste eine Rolle, zum Beispiel bei
der Dateiablage mit den unterschiedlichen Dateisystemen, die zum Einsatz kommen
können. Diese können zu Problemen bezüglich Konstruktion der Pfade und der erlaubten Länge der Dateinamen führen (siehe Kapitel II.E 2).
Die Erfahrung zeigt, dass die Migration des Apache HTTP Servers an sich meist unproblematisch ist. Schwierig kann jedoch in einigen Fällen die Migration einzelner Module
werden. So kann zum Beispiel ein Wechsel des PHP Modules von PHP 4 auf PHP 5
Probleme bereiten, das heißt dass unter PHP 4 entwickelte Scripte unter dem neuen
Modul nicht immer fehlerfrei laufen und daher gegebenenfalls angepasst werden müssen. Analog gilt dies auch für unterschiedliche Versionen von Scriptinterpretern, die zusammen mit den IIS eingesetzt werden. Eine generelle Aussage zu der Migration von
Apache Modulen oder Erweiterungen der IIS lässt sich daraus jedoch nicht ableiten.
Dies muss im Rahmen eines Migrationsprojekts im Einzelfall geprüft werden. Die Beispiele zeigen aber auch, dass auch bei einer fortführenden Migration nicht davon auszugehen ist, dass die Migration der dynamischen Inhalte ohne weiteres möglich ist.
Für die Migration der IIS bietet Microsoft ein kommandozeilenbasiertes Tool an, mit dem
sich sowohl Webseiteninhalte als auch Konfigurationsdaten migrieren lassen. Über dieses Tool lässt sich eine Migration der IIS teilweise deutlich vereinfachen. Insbesondere
bei komplexen Systemumgebungen stößt das Tool jedoch an seine Grenzen, sodass
keine vollständige Migration (zum Beispiel Migration von ODBC Verbindungen) möglich
ist. Es muss daher vorab überprüft werden, inwieweit zusätzlich Aktivitäten notwendig
sind, um die Migration abzuschließen. Stellt sich bei einer solchen Prüfung heraus, dass
mehrere unterschiedlicher Migrationsprobleme durch das Tool nicht gelöst werden, kann
es durchaus sinnvoller sein, eine Migration komplett ohne das Tool durchzuführen.
3
Bezüge
3.1
Dateiablage
Webserver nutzen zum einen die Dateiablage, um ihre Daten dort abzulegen oder zu
verwalten. Gegebenenfalls wird hierfür auch eine Datenbank im Backend verwendet.
Zum anderen werden Webserver auch dazu eingesetzt, um Dateien auf Fileservern über
Webbrowser im Internet oder Intranet, zum Beispiel mittels WebDAV zur Verfügung zu
stellen. Damit besteht ein Bezug zu den Diensten der Dateiablage, bei Migrationen von
Webservern sollten daher auch das (Kapitel II.E ) und hier vor allem die Technologiebetrachtungen mit den Abschnitten:

„Linux und Samba mit SMB/CIFS und POSIX―, II.E 1.1
Seite 185

„Linux-Server mit NFS―, II.E 1.2

„Linux-Server mit OpenAFS―, II.E 1.3

„Windows NT 4.0/2000/2003 mit NTFS―, II.E 1.4
auf relevante Punkte geprüft werden.
Bei großen Webseiten muss zusätzlich geprüft werden, auf welchen Datenbanken und
Content Management Systemen die Inhalte gepflegt werden. Informationen zur Migration
von Datenbanken befinden sich im gleichnamigen Kapitel.
3.2
Netzwerkdienste
Natürlich besteht auch immer ein Bezug zwischen dem Thema Webserver und dem
Thema Netzwerkdienste. Auch hier ist im Rahmen von Migrationen zu prüfen, ob und
wie die benötigten Netzwerkdienste bereitgestellt werden können und ob und wie die
Anforderungen an die Kommunikationssicherheit gewährleistet werden können.
Daher ist es sinnvoll im Zusammenhang mit Einführung oder Migration eines Webservers die Technologiebetrachtungen zum Thema „Netzwerkdienste― (Kapitel II.D 1) zu
konsultieren.
3.3
Authentifizierung
Häufig soll auch der Zugang zum und der Zugriff auf den Webserver nicht völlig
ungeregelt erfolgen, sodass Authentifizierungsdienste benötigt werden. Dabei macht es
dann durchaus Sinn, Benutzer nicht mehrfach zu verwalten, sondern vorhandene
Infrastrukturen z.B. die der zentralen Benutzerverwaltung zu nutzen. Damit stellt sich
dann auch der Bezug her zu dem Thema Authentisierungs- und Verzeichnisdienst
(Kapitel II.C) mit den Betrachtungen der Produkte und Technologien in den Abschnitten:
3.4

„Linux und Samba mit OpenLDAP und Kerberos (MIT/Heimdal)―, II.C 1.1

"Windows NT 4 Server als sogenannter Domänencontroller (DC)―, II.C 1.3

„Windows 2000/2003 Server mit Active Directory und Kerberos―, II.C 1.4
Anwendungen
Insbesondere, wenn Webserver nicht als reine Webserver zum Einsatz kommen (siehe
Abschnitt II.B 1), spielt bei der Migration auch der Bezug zur Backendintegration (siehe
Abschnitt III.D ) eine wichtige Rolle. Bei einem Wechsel muss sichergestellt werden,
dass die Anforderungen der Anwendungen nach wie vor unterstützt beziehungsweise
die Anwendungen gegebenenfalls angepasst werden müssen. Außerdem sollte mit Blick
auf zukünftige Änderungen ein weitestgehendes Maß an Flexibilität und Unabhängigkeit
gewahrt bleiben. Hierzu soll an dieser Stelle ganz besonders auf die Ausführungen und
Hilfestellungen im Leitfaden „Plattformunabhängigkeit von Fachanwendungen― (siehe
www.kbst.bund.de) als weitere Unterstützung für eine Migration hingewiesen werden.
Seite 186
C Thema Authentisierungs- und Verzeichnisdienste
Die Themen Authentisierung und Verzeichnisdienst sind kaum von einander zu trennen.
Mit einem Verzeichnisdienst können beliebige Informationen netzwerkweit zur Verfügung
gestellt werden. Ein Verzeichnisdienst besteht typischerweise aus einer Datenbank, in
der diese Informationen gespeichert werden können, und einem Netzwerkprotokoll, mit
dem die Informationen abgefragt oder geändert werden können. Das am häufigsten eingesetzte Verzeichnisdienstprotokoll ist das Lightweight Directory Access Protocol
(LDAP). LDAP in der Version 3 wird im Kern im RFC 2251 definiert. Heute wird unter
einem LDAP-Server in der Regel die Kombination aus Datenbank und Protokollimplementierung verstanden.
Verzeichnisdienste eignen sich insbesondere für den schnellen lesenden Zugriff auf hierarchisch strukturierte Daten, die nicht regelmäßig geändert werden. Dabei lassen sich
beliebige Informationen ablegen beziehungsweise über den Dienst im Netzwerk bereitstellen.
Mit der Einführung eines Verzeichnisdienstes ist es möglich, die Benutzerkonten und die
dazugehörigen Berechtigungen zentral im Verzeichnisdienst zu speichern und alle Systeme darauf zugreifen zu lassen. Gleichzeitig können Adressbuchanwendungen, wie sie
beispielsweise in E-Mail-Software eingebaut sind, auf das Verzeichnis zugreifen und so
die E-Mail-Adressen der Mitglieder der betreffenden Organisation bereit stellen, ohne
dass diese Daten erneut manuell eingegeben werden müssen.
Verzeichnisdienste können auch zur Speicherung von Passwörtern genutzt werden
(Passwörter sind dann typischerweise ein Attribut von Personen- oder Benutzerkontenobjekten). Dadurch wird ebenfalls das Ziel der einmaligen, zentralen Datenhaltung verfolgt. Im Verzeichnis gespeicherte Passwörter werden an einer Stelle angelegt und geändert und können dann auf allen Systemen und mit allen Anwendungen genutzt werden, die das Verzeichnis zur Authentifizierung verwenden können. Außerdem können
die im Verzeichnis gespeicherten Passwörter zur Authentifizierung beim Zugriff auf Daten im Verzeichnis selbst genutzt werden.
Verzeichnisdienste werden daher an vielen Stellen, insbesondere im Zusammenhang
mit Authentisierungsdiensten eingesetzt, zum Beispiel unter Windows mit Active Directory, unter Linux/Samba mit OpenLDAP oder in der Groupware Kolab mit OpenLDAP.
Trotz dieser weit verbreiteten Praxis, Verzeichnisdienste zur Authentifizierung zu verwenden, muss dies als fragwürdige Strategie angesehen werden. Das Konzept erlaubt
keine sichere Methode zur Implementierung von Single Sign-On, da an jedem System
und jeder Anwendung erneut eine Authentifizierung stattfinden muss (wenngleich auch
mit demselben Passwort). Außerdem sind die meisten Verzeichnisdienste nicht mit dem
Ziel geschrieben worden, einen sicheren Authentifizierungsmechanismus bereit zu stellen, sondern häufig benötigte Informationen zentral zu speichern und schnell an Clients
liefern zu können. Stattdessen empfiehlt sich der Einsatz von Kerberos. Kerberos ist ein
Protokoll zur sicheren Authentisierung innerhalb offener Netze, die zum Beispiel auf dem
TCP/IP Protokoll basieren.
Bei der Verwendung von Kerberos werden nicht wie üblich, Benutzernamen und Passwort an jeden Server geschickt, dessen Dienste von einem Benutzer in Anspruch geSeite 187
nommen werden sollen. Vielmehr erfolgt hier eine einmalige Anmeldung an einem Key
Distribution Center (KDC, gelegentlich auch als Kerberos Domänencontroller bezeichnet). Der Benutzer erhält nach erfolgter Anmeldung ein Ticket, das eine definierte Gültigkeitsdauer hat und mit dem er sich dann gegenüber allen weiteren Diensten authentifizieren kann. Nach Ablauf der Gültigkeit des Tickets muss sich der Benutzer erneut authentifizieren. Durch den Einsatz von Kerberos muss die Passwortdatenbank nur noch
auf besonders vertrauenswürdigen Systemen (den Kerberos-Servern) vorhanden sein.
Andere Systeme brauchen keinen Zugriff mehr auf die Passwortdatenbank. Mit Hilfe von
Kerberos-Tickets kann außerdem Single Sign-On implementiert werden, indem Tickets
zum Zugriff auf alle im Netzwerk bereitgestellten Dienste verwendet werden (sofern die
entsprechenden Applikationen Kerberos unterstützen).
Um ein feingranulares Rechtesystem zu realisieren, das definiert, welche Objekte und
Attribute durch welche Benutzer gelesen oder geändert werden dürfen, implementieren
die meisten Verzeichnisdienste ein System von Access Control Lists (ACLs), das mit den
ACLs auf Dateisystemebene zu vergleichen ist.
Vor diesem Hintergrund werden nachfolgend die in der Überschrift genannten Themen
hier gemeinsam betrachtet.
1
1.1
Linux und Samba mit OpenLDAP und Kerberos (MIT/Heimdal)
Samba ist eine freie Software, die das SMB-Protokoll (Server-Message-Block-Protokoll)
und das CIFS (Common Internet File System) für Unix- und Linux-Systeme nutzbar
macht. Das SMB-Protokoll und dessen Erweiterung CIFS sind Windows-Protokolle für
u.a. Datei- und Druckdienste. Samba wurde erstmals 1992 veröffentlicht. Das Kernteam
zur Entwicklung von Samba umfasst ca. 20 Personen, die von einigen Firmen unterstützt
werden160. Samba liegt aktuell in der Version 3.026a vor. Gemäß der unter
http://samba.sernet.de/161 veröffentlichten Erklärung des Samba-Teams werden alle
Versionen ab der Version 3.2 unter der GNU General Public License in der Version 3
veröffentlicht. Demnach sollte die aktuelle Version noch unter GPLv2 stehen.
OpenLDAP ist die Implementierung eines LDAP-Servers als Open Source Software162.
Sie steht unter der OpenLDAP Public License V2.8.
Kerberos 5 ist ein Protokoll zur sicheren Authentisierung innerhalb offener Netze, die
zum Beispiel auf dem TCP/IP Protokoll basieren. Kerberos wurde am MIT (Massachusetts Institute of Technology)163 entwickelt und ermöglicht auch die Realisierung von
Single Sign-On, das heißt eine einmalige Anmeldung im Netz ist ausreichend, um alle
Dienste und Programme, für die eine Berechtigung besteht, nutzen zu können. Die Spezifikation ist im RFC 4120 beschrieben. Eine freie, weit verbreitete Implementierung des
160
161
162
163
http://www.samba.org
Stand 01.11.2007
http://www.openldap.org
http://www.kerberos.org/
Seite 188
Kerberosprotokolls ist die Heimdal-Implementierung164. Eine andere wichtige Open
Source Implementierung ist die des MIT 165.
In den folgenden Abschnitten wird auf architektonische und funktionale Besonderheiten
der drei Produkte OpenLDAP, Samba und Heimdal Kerberos unter dem Blickpunkt der
Realisierung eines Authentisierungsdienstes eingegangen.
1.1.1
OpenLDAP
Die Software OpenLDAP setzt sich aus folgenden Modulen zusammen

slapd - der eigentliche LDAP-Server,

slurpd - der LDAP-Update-Replication-Daemon,

Bibliotheken zur Implementierung des LDAP-Protokolls und

weiterer Werkzeuge.
Darüber hinaus setzt OpenLDAP standardmäßig als Datenbank-Backend die BerkleyDB
ein166. Die nachfolgende Tabelle zeigt die Funktionen, die von OpenLDAP unter Linux
unterstützt werden.
Funktion
Client ohne Zusatzsoftware
Möglichkeit zum hierarchischen Aufbau des Verzeichnisses
Erweiterbarkeit durch eigene Attribute und Objektklassen
Unicode Zeichensatz für Verzeichnisdaten
Zugriffsmöglichkeit auf das Verzeichnis per Standard-Protokoll (LDAP)
Sichere Zugriffsmöglichkeit per LDAP über SSL/ TLS
Unterstützung des „starttls― Protokolls
Unterstützung für SASL
Authentifizierung von NT Clients über Samba
167
Authentifizierung von W2K Clients über Samba168
Authentifizierung von Linux Clients
Möglichkeit zur Integration von Kerberos
Möglichkeit zur Verwendung eines unabhängigen / übergeordneten Kerberos-Dienstes
164
165
166
167
168
http://www.pdc.kth.se/heimdal/
http://web.mit.edu/kerberos/www/
http://www.oracle.com/technology/software/products/berkeley-db/index.html
Bei der Verwendung von Samba zur Authentifizierung von Windows Clients gegen OpenLDAP wird zwischen Windows-Client und Samba-Server das NT-LAN-Manager Protokoll
verwendet.
Bei der Verwendung von Samba zur Authentifizierung von Windows Clients gegen OpenLDAP wird zwischen Windows-Client und Samba-Server das NT-LAN-Manager Protokoll
verwendet.
Seite 189
Funktion
Verwaltung von Zugriffsrechten (ACLs) für Attribute und Objekte
Delegation von Verwaltungsaufgaben
Master-Slave-Replikation
169
Multi-Master-Replikation
Tabelle 39: Funktionen von OpenLDAP unter Linux
Zur Verwaltung der in einem Verzeichnis gespeicherten Informationen stehen unter Linux die standardmäßigen Kommandozeilenbefehle zur Verfügung:

ldapsearch

ldapadd

ldapdelete

ldapmodify

ldapmodrdn
Diese Kommandozeilenbefehle eignen sich vor allem zur Initialisierung eines Verzeichnisses, ferner zum Datenimport, zur schnellen Suche nach Verzeichnisinhalten sowie zur
automatisierten Bearbeitung eines Verzeichnisses. Darüber hinaus gibt es zur Administration etliche freie grafische Werkzeuge zur verzeichnisbasierten Benutzer- und Gruppenverwaltung unter Linux, zum Beispiel GQ170-Browser. Ebenso wichtig und viel flexibler sind browserbasierte Werkzeuge zur Verwaltung von Benutzer-, Gruppen- und Maschinenkonten sowie anderen Objekten (Mailing-Listen, DNS-Einträgen usw.) innerhalb
von Verzeichnisdiensten. Der Vorteil dieser Lösungen ist, dass sie mit einem WebBrowser unabhängig vom Server verwendet werden können, wobei eine sichere Datenübertragung (SSL/TLS), wie auch bei anderen Werkzeugen, genutzt werden kann. Häufig sind dies aber komplexere Werkzeuge für spezielle Aufgaben wie die Systemadministration, zum Beispiel Webmin171.
Linux und OpenLDAP hat sich in sehr großen Umgebungen mit mehr als 70.000 Benutzern als stabil und hinreichend performant erwiesen. Mit OpenLDAP ist es daher möglich, große Verzeichnisse, wie zum Beispiel eine zentrale Benutzerdatenverwaltung, aufzubauen.
Typisch für ein solches Verzeichnis ist die hierarchische Strukturierung der in ihm enthaltenen Informationen, ähnlich wie in einem Dateisystem. Diese Struktur des Verzeichnisses wird dabei durch das LDAP-Schema definiert. In diesem werden Objekt-Klassen
169
170
171
Die Multi-Master-Replikation in OpenLDAP gilt als experimentell und ist standardmäßig
nicht eingeschaltet.
http://gq-project.org/
http://de.wikipedia.org/wiki/Webmin
Seite 190
(zum Beispiel Person oder Organisation) mit ihren Attributen festgelegt. Aus den definierten Objektklassen ergibt sich, zu welchen Attributen zwingend Werte anzugeben sind
(Pflichtangaben). Die Verzeichniseinträge selbst heißen Objekte. Jedes Objekt ist mindestens einer, in der Regel aber mehreren Klassen zugeordnet. Innerhalb der Objekte
werden zu den Attributen die Attributwerte abgelegt. In den Attributen sind somit die gesamten Informationen eines im Verzeichniseintrag genannten Informationsobjekts
enthalten. Attribute unterscheiden sich in Attributtypen. Über diese wird u.a. festgelegt,
welche Werte für ein Attribut zulässig sind.
Die Einträge werden in einer hierarchischen Baumstruktur, dem Directory Information
Tree (DIT), eingeordnet, der den gesamten Namensraum, der von einem Server vorgehaltenen wird, abbildet. Der Distinguished Name (DN) ist der eindeutige Name des Eintrags im gesamten Datenbestand.
Als Netzwerkprotokoll verfügt LDAP über Befehle, die für das Datenmanagement (add,
delete, modify, modify DN) und für das Retrieval (search) inklusive der Möglichkeit,
komplexe Suchfilter aufzubauen, notwendig sind. Ebenso werden Befehle für die Authentisierung beziehungsweise das Anmelden (bind) und das Abmelden des Clients vom
Server (unbind, abandon) spezifiziert. Die Anmeldung ist in ein bind request und ein bind
response aufgeteilt. Der bind request enthält neben der LDAP-Protokollversionsnummer
einen Distinguished Name eines Eintrags. Dieser Eintrag kennzeichnet die zu beweisende Identität, zum Beispiel einen Personeneintrag sowie die Authentisierungsmethode
samt der zugehörigen Daten. Hierbei sind zwei Methoden definiert:
Bei der Methode Simple Bind wird zusätzlich zum Distinguished Name ein Passwort mitgeschickt, das mit dem gespeicherten Passwort verglichen wird. Eine Verschlüsselung
des zu übertragenden Passworts ist mit TLS möglich und spezifiziert.
Die Methode SASL (Simple Authentication and Security Layer) Bind kapselt den Authentisierungsvorgang in eine eigene Schicht. Damit wird vermieden, für jedes Anwendungsprotokoll einen eigenen Authentisierungsmechanismus definieren zu müssen. Der am
stärksten verbreitete SASL-Mechanismus ist GSSAPI (Generic Security Services Application Programming Interface). Die beiden wichtigsten GSSAPI-Mechanismen sind wiederum Kerberos V5 und X.509. Abhängig vom gewählten SASL-Mechanismus werden
bei der LDAP-Authentisierung im bind request anstelle des Distinguished Name andere
Identitätskennungen und Identitätsbeweise mitgeschickt. Damit lässt sich für OpenLDAP
eine Authentifizierung mittels Kerberos 5 über SASL-GSSAPI realisieren.
Zusätzlich zu einigen Authentisierungsmechanismen bietet SASL auch die Definition
einer optionalen Verschlüsselung an.
Die gesamte Kommunikation zwischen Client und Server kann mit TLS verschlüsselt
werden, sodass sich Server und Client gegenseitig authentisieren können, wodurch zum
Beispiel „man-in-the-middle―-Angriffe vermieden werden. Wie TLS zur Verschlüsselung
der Kommunikation zwischen Client und Server verwendet werden soll, wird im RFC
2830172 beschrieben.
172
http://www.faqs.org/rfcs/rfc2830.html
Seite 191
Auch bei Login-Prozessen in Betriebssystemen kann auf zentrale, durch einen LDAPServer vorgehaltene Benutzerdaten zugegriffen werden. Bei Unix-Systemen geschieht
dies über die Verwendung von NSS (Name Service Switch) und PAM (Pluggable Authentication Modules). Bei Windows-Rechnern kann eine LDAP-basierte Benutzerverwaltung durch den Einsatz von Samba verwendet werden. Samba dient neben der Bereitstellung von Dateien und Druckern über das Netz auch der Authentisierung von Windows-Clients an einer Windows-Domäne. Samba verfügt über eine LDAP-Schnittstelle,
sodass die Daten der Benutzerkonten für den Login-Prozess aus der zentralen LDAPBenutzerverwaltung verwendet werden können173.
Weitere Aufgaben eines Verzeichnisdienstes:
Durch die zentrale Verwaltung zum Beispiel von Host-Informationen in einem Verzeichnis lassen sich zahlreiche administrative Aufgaben deutlich vereinfachen. Dazu gehören

Inventarisierung vorhandener Hardware,

Erstellung und Verwaltung von DNS-Namenseinträgen,

Erstellung und Verwaltung von DHCP-Konfigurationen,

gemeinsame Speicherung der Maschinen-Accounts mit den oben genannten Informationen (für Windows-Clients) und

Speicherung beliebiger weiterer host-spezifischer Informationen in einem Verzeichnis, wie beispielsweise Informationsprofile zur automatischen Installation eines Clients.
Diese Informationen müssen nicht manuell oder über andere Verfahren auf mehrere
Rechner verteilt werden, sondern werden per LDAP-Replikation anderen Systemen zur
Verfügung gestellt. Durch eine verteilte Verzeichnis-Server-Struktur können zentral erfasste Informationen mittels Replikation auf die verschiedenen Server verteilt werden, an
die die anderen Systeme angebunden sein müssen.
Unter Linux stehen mittlerweile zahlreiche Programme zur Verfügung, mit denen HostInformationen direkt aus einem LDAP-Verzeichnis gelesen werden können:

Für den Standard DHCP-Server (ISC DHCPD) gibt es einen Patch, mit dem die
DHCP-Konfiguration aus einem LDAP-Verzeichnis gelesen werden kann
(siehe: http://home.ntelos.net/~masneyb/dhcp-3.0.5-ldap-patch)

Für BIND 9 gibt es ebenfalls einen Patch, mit dem Zonendateien durch LDAP ersetzt werden (siehe: http://bind9-ldap.bayour.com/)

Samba kann Informationen für Maschinen-Accounts direkt aus dem LDAPVerzeichnis beziehen
Darüber hinaus gibt es eine Reihe proprietärer und freier Softwareprodukte, mit denen
die BIND- und DHCP-Konfiguration transparent aus dem LDAP-Verzeichnis erzeugt
werden kann.
173
Gietz, P.: „Chancen und Risiken LDAP-basierter zentraler Authentifizierungssysteme―,
http://www.daasi.de/pub/Chancen%20und%20Risiken%20durch%20LDAPAuthentifizierung.pdf
Seite 192
Neben der Verwendung von Verzeichnisdiensten zur zentralen Speicherung von Benutzer-, Gruppen- und Host-Informationen steigt der Nutzen von Anwendungen durch den
Zugriff möglichst vieler anderer Applikationen. Auf eine vollständige Liste LDAPkompatibler Anwendungen wird an dieser Stelle verzichtet. Wichtig ist jedoch der Hinweis, dass immer mehr Applikationen LDAP-Unterstützung aufweisen, nicht zuletzt die
Microsoft E-Mail-Programme Outlook und Outlook-Express oder das Office-Paket OpenOffice.org. Diese Anwendungen können sowohl mit OpenLDAP als auch mit Active
Directory als Verzeichnisdienst arbeiten.
1.1.2
Samba
Samba ist als Client-Server-System aufgebaut und besteht aus einer Vielzahl einzelner
Module, die grundlegende Aufgaben bis hin zur Konfiguration und Dokumentation übernehmen. Da die Module auch ausgetauscht werden können, kann die Konfiguration zum
Beispiel auch über eine Webschnittstelle erfolgen. Sambas Kernmodul heißt Smbd und
stellt Datei- und Druckdienste für die SMB/CIFS-Clients zur Verfügung. Über Samba
können Informationen für Maschinen-Accounts direkt aus dem LDAP-Verzeichnis bezogen werden.
1.1.2.1
Authentifizierung mit Linux / OpenLDAP und Samba
Samba kann Windows-Clients ähnliche Funktionalitäten wie ein Windows NT-basierter
primärer Domänencontroller (also u.a. File-, Print- und Authentifizierungsservices) zur
Verfügung stellen. Als Datenbank für Benutzerkonten kann Samba dabei auf OpenLDAP
als Verzeichnisdienst zurückgreifen. Insofern stellt die Kombination Samba/OpenLDAP
eine Art Mischform zwischen Windows NT-Domänen und Active Directory dar. Aus der
Sicht von Windows-Clients handelt es sich um eine Windows NT-Domäne (die frühestens 2008 erscheinende Version Samba 4 wird sich in Richtung der Windows Clients wie
ein Active Directory Domänencontroller präsentieren). Hinsichtlich der Administration von
Benutzer-, Gruppen- und Host-Informationen geht es jedoch um eine vollständig verzeichnisdienstbasierte Lösung mit allen daraus resultierenden Vorteilen. Insbesondere
entfällt bei einer Samba/OpenLDAP-basierten Lösung das von Windows NT bekannte
Skalierungsproblem, das oft die Aufteilung einer Infrastruktur in unterschiedliche Domänen erforderlich macht.
Bei Verwendung von Linux/OpenLDAP als Verzeichnisdienst für Windows-Clients in
Verbindung mit Samba findet die Authentifizierung der Windows-Clients über das NTLMProtokoll statt. Darum müssen im Verzeichnis die gleichen verschlüsselten Passwörter
gespeichert werden wie in der SAM-Datenbank unter Windows NT/2000/2003. Mit dieser
qualitativen Einschränkung (keine Kerberos Authentifizierung für Windows 2000/XP
Clients) ist es somit möglich, auf der Basis von Linux, OpenLDAP und Samba eine vollwertige Authentifizierung für Windows-Clients aufzubauen.
Dabei scheint es zunächst problematisch zu sein, dass UNIX- und Linux standardmäßig
einen anderen Algorithmus zur Passwort-Verschlüsselung verwenden als Windows
NT/2000. Es ist deswegen bei einer OpenLDAP/Samba-basierten Lösung notwendig,
UNIX- und Windows-Passwörter nebeneinander im LDAP-Verzeichnis zu speichern und
miteinander zu synchronisieren. Aus technischer Sicht ist dies weniger problematisch,
denn Samba kann so konfiguriert werden, dass es bei einer Passwort-Änderung vom
Seite 193
Windows-Client aus auch das UNIX-Passwort ändert. Und umgekehrt können UNIXProgramme über den PAM- (Pluggable Authentication Module) Mechanismus so eingerichtet werden, dass sie auch das Windows-Passwort ändern, wenn das UNIX-Passwort
gewechselt wird. Durch richtige Konfiguration stellt die Passwort-Synchronisation somit
kein Problem dar.
Samba 3.0x unterstützt die von Windows NT bekannten Vertrauensstellungen. Diese
können sowohl zwischen Windows- und Samba-Domänen als auch zwischen zwei Domänen, die beide auf Samba basieren, eingerichtet werden.
1.1.2.2
Einschränkungen bei der Verwendung von OpenLDAP und Samba
Wie bereits erwähnt, entspricht Samba aus der Sicht von Windows-Clients einem Server
auf der Basis von Windows NT. Das bedeutet, dass die mit Active Directory neu eingeführten Eigenschaften zur Verwaltung von Windows Clients nicht zur Verfügung stehen.
Insbesondere werden Group Policy Objects (GPOs) und die Softwareverteilung via Active Directory174 nicht unterstützt. In der Praxis ist es oft völlig ausreichend, diese Features
durch andere Techniken zu ersetzen.
Samba unterstützt die sogenannten System Policies, mit denen sich Registry-Einstellung
für Benutzer, Benutzergruppen und Client-Computer festlegen lassen. Über SystemPolicies kann ein Großteil der mit GPOs verfügbaren Einstellungen ebenfalls vorgenommen werden (Einschränkungen in der Funktion der Windows-Oberfläche, Auswahl
ausführbarer Programme usw.). Die Systemrichtlinien können dynamisch mit dem in
Samba integrierten Werkzeug „editreg― erstellt werden.
Außerdem lassen sich in einer Samba-basierten Umgebung lokale Policies verwenden,
mit denen prinzipiell dieselben Einstellungen vorgenommen werden können wie mit
GPOs. Weil lokale Policies einfach im Dateisystem abgelegt werden, können diese leicht
von einem Prototypen auf eine große Anzahl von Clients synchronisiert werden.
1.1.2.3
Kombination von OpenLDAP und Active Directory
Dort, wo auf die Features von Active Directory nicht verzichtet werden kann, ist es möglich, Benutzer- und Gruppendaten aus OpenLDAP in das Active-Directory zu replizieren.
Benutzer und Gruppen müssen dann weiterhin nur im OpenLDAP-Verzeichnis gepflegt
werden, stehen aber auch im Active Directory zur Verfügung. Auf diese Weise können
die entsprechenden Eigenschaften (wie etwa GPOs) genutzt werden und der SinglePoint-of-Administration bleibt erhalten. Dabei kann Windows so konfiguriert werden,
dass für beide Teile der Umgebung ein gemeinsamer (Linux basierter) Kerberos-Server
genutzt werden kann. Allerdings ist dies mit der Einschränkung verbunden, dass Windows 95/98/NT basierte Systeme sich dann nicht mehr gegen Active Directory/Kerberos
authentifizieren können. In einer solchen Konstruktion wird deswegen die Authentifizierung dieser Clients gegenüber Samba/OpenLDAP empfohlen.
174
Softwareverteilung ist nicht Thema dieses Abschnitts und wird daher hier nicht weiter betrachtet.
Seite 194
1.1.3
Heimdal-Kerberos /MIT Kerberos 5
Zunächst einige Ausführungen zum grundsätzlichen Funktionsprinzip von Kerberos: Bei
einer kerberosgesicherten Kommunikation sind drei Parteien beteiligt:

Ein Client, der einen Dienst anfragt

Ein Server, der angefragt wird

Der Kerberos-Server, der die Berechtigungen vorhält und eine gesicherte Kommunikation ermöglicht
Der Kerberos-Dienst authentisiert dabei sowohl den Client gegenüber dem Server als
auch den Server gegenüber dem Client. Dabei muss sowohl auf dem anfragenden Client
als auch auf dem angefragten Server eine Kerberos-Unterstützung installiert sein.
Unter Kerberos sendet ein Client, in der Regel ein Nutzer oder ein Dienst, eine Ticketanfrage zum Key Distribution Center (KDC). Dieser generiert dann ein Ticket-Granting
Ticket (TGT) für den Client und verschlüsselt dieses mit dem Passwort und/oder Smartcard des Clients und sendet es an den Client zurück. Der Client entschlüsselt das TGT
mittels Passworts und/oder der Smartcard und behält das entschlüsselte TGT, das die
Identität des Clients sicherstellt. Dieses zeitlich befristete TGT ermöglicht es dem Client,
zusätzliche Tickets zu erlangen, die dem Client die Nutzung bestimmter Dienste erlauben. Der Prozess zum Erlangen eines zusätzlichen Tickets verläuft ohne weitere Aktivität des Nutzers. Der Client sendet das Ticket an den Dienst, der überprüft, ob er dem
Client den Zugriff gestatten soll.
Auf diese Art ermöglicht Kerberos eine authentisierte, optional über einen Sitzungsschlüssel auch verschlüsselte Kommunikation. Die Kerberos Tickets können dabei optional in einer Datei oder im Arbeitsspeicher des Clients gespeichert werden.
Die Referenzimplementierung des Kerberosprotokolls ist die Implementierung des MIT.
Die aktuelle Version 1.6.3 unterstützt die Versionen 4 und 5 des Protokolls. Unterstützt
werden die Standard-Kerberos-Verschlüsselungsverfahren, wie DES und 3DES, weiterhin werden RC4, das von Active Directory Kerberos genutzte Verfahren, sowie AES unterstützt. Prüfsummenverfahren, die zur Verfügung stehen, sind MD5, SHA-1, HMAC
und CRC32. MIT Kerberos steht für Linux, Windows und Mac zur Verfügung.
Heimdal-Kerberos ist eine neuere, freie Implementierung des Kerberosprotokolls für
Unix, Linux und Mac, die aktuell in der Version 1.01 vorliegt 175. Sie ähnelt der MITImplementierung stark. So werden zum Beispiel ebenfalls die Kerberos-Versionen 4 und
5 unterstützt sowie die gleichen Verschlüsselungsverfahren wie bei MIT Kerberos.
Auf Basis dieser Mechanismen lässt sich mit Kerberos auch eine sogenannte starke
Authentisierung realisieren. Eine starke Authentisierung erfordert neben dem Wissen
bzgl. des Benutzernamens und des Passworts in der Regel zusätzlich den physischen
Besitz eines Gegenstands, zum Beispiel eines Tokens, der systemabhängige Zahlen
generiert, die zur Authentisierung eingegeben werden müssen. Die erforderliche Sicherheit ist dabei vom konkreten Anwendungsfall abhängig.
175
Stand 01.11.2007
Seite 195
Da sich der Kerberos-Server als Single-Point-of-Failure erweisen kann, nach dessen
Ausfall sich zum Beispiel niemand anmelden kann, besteht die Möglichkeit, zusätzliche
Kerberos-Server als Backup einzusetzen. Zudem besteht die Möglichkeit, mehrere Server zum Load-Balancing zu nutzen.
1.1.4
Betriebssystemumgebungen von Samba und OpenLDAP
Nachdem in den vorherigen Abschnitten die drei Produkte im Hinblick auf architektonische und funktionale Besonderheiten beschrieben wurden, wird im Folgenden näher auf
mögliche Betriebssystemumgebungen von Samba und OpenLDAP eingegangen.
Samba Server ab der Version 3.0 können als Mitgliedserver in einem Active Directory
genutzt werden. Ohne den Nutzen von Microsoft Servern ist es nicht möglich, die Active
Directory Funktionen über einen Samba Server anzubieten. Mit Samba in Kombination
mit einem anderen Verzeichnisdienst, zum Beispiel OpenLDAP, lassen sich Funktionen
wie sie Active Directory bietet, in einem Netzwerk abbilden.
SMB/CIFS-Clients stehen auch für verschiedene Windows- und Unix-Varianten zur Verfügung.
OpenLDAP läuft unter verschiedenen Unix- und Windows-Varianten sowie unter Mac OS
X. Durch unterschiedliche Backend und Overlays lassen sich Erweiterungen, zum Beispiel zusätzliche Operationen, realisieren. So können zum Beispiel SQL-Abfragen in
LDAP-konforme Informationen umgewandelt werden.
Zusammenfassend ist festzustellen: Die Kombination von Samba und OpenLDAP stellt
eine etablierte Verzeichnisdienstalternative in heterogenen Netzen dar. Die Migration auf
die Kombination Samba/OpenLDAP kann für Benutzer und Clients relativ transparent
geschehen, sodass diese von dem Wechsel unberührt in ihrer Arbeit bleiben und sich
keine wesentlichen Änderungen für sie ergeben.
Kerberos ist ein modernes und weit verbreitetes Protokoll. Es bietet sichere und einheitliche Authentisierung in einem ungesicherten TCP/IP Netzwerk aus sicheren Hostrechnern. Durch Kerberos werden gemäß DFN-CERT insbesondere Angriffe durch passives
,,Sniffing'' unterbunden, aber auch ,,Spoofing'', ,,Dictionary Attacks'', ,,Replay'' und andere Angriffe werden erschwert.176
1.2
Fedora Directory Server (OSS-Lösung mit Multimasterfähigkeit)
Der Fedora Verzeichnisserver wird durch das Fedora Projekt entwickelt, das u.a. durch
eine freie Linux-Distribution bekannt ist.177
Der Fedora Verzeichnisserver ist 2005 aus dem Netscape Verzeichnisserver hervorgegangen. Er wird in der Version 1.0.4 angeboten, wobei sich die Version 1.1 bereits in der
Testphase befindet.
176
177
http://www.dfn-cert.de/infoserv/dib/dib-2002-02-Kerberos5/doc-single.html.
http://fedoraproject.org; Fedora und Red Hat basieren auf derselben Softwarebasis und
sind annähernd identisch. Unter dem Namen Red Hat werden seit 2003 kommerzielle Produkte, i.d.R. Software, an die ein Wartungsvertrag gebunden ist, für Firmenkunden vertrieben.
Seite 196
Wichtige Änderungen gegenüber der Vorgängerversion sind die Synchronisation von
Windows Usern (Active Directory User- und Gruppen-Synchronisation, Synchronisation
über Samba), ferner eine verbesserte Rechtekontrolle, die Möglichkeit der Replikation in
WANs (Wide Area Networks), die Möglichkeit der inkrementellen Replikation sowie
vereinfachtes Ändern von Passwörtern und die Möglichkeit, die Replikation von
Dateiverzeichnissen anzustoßen. Es ist zudem möglich, biometrische Daten und
Smartcards einzubinden. Insbesondere besteht die Möglichkeit, mehrere Master-Server
einzusetzen.
Ein Großteil des Fedora Verzeichnisservers wird als freie Software (GPL Exception) im
Rahmen diverser Community-Projekte, in der Regel in enger Kooperation mit dem Fedora Projekt, entwickelt. Darüber hinaus gibt es Erweiterungen wie eine Managementkonsole oder Module für den Apache Server, die unter anderen Open Source Lizenzen verfügbar sind.178
Bei Installation des Fedora Directory Server werden folgende Komponenten installiert:

Das Server Front End zur Verwaltung der Kommunikation mit den Clients via
LDAP, die per SSL/TLS verschlüsselt werden kann

Plug-Ins für Serverdienste, wie zum Beispiel Access Control und Replikation,
weitere Plug-Ins finden sich unter http://directory.fedoraproject.org/wiki/Plugins

Ein Verzeichnisbaum mit den serverbezogenen Informationen

Ein Datenbank-Plug-In zur Verwaltung der dauerhaft gespeicherten Information,
zum Beispiel zum Aufrufen der Serverinformationen
Der Fedora Verzeichnisserver ist ein LDAP basierter Verzeichnisdienst. Der Zugriff muss
demnach über LDAP erfolgen. Er ist für folgende Betriebssysteme verfügbar:

Fedora Core 3-6 (x86 und x86_64)

Red Hat Enterprise Linux Version 3 (x86) und 4 (x86 und x86_64)

Solaris 2.8 und 2.9 (32 und 64 bit) (SPARC)

HP/UX 11(pa-risc und ia64)

weitere Linux-Distributionen (u.a. Debian, gentoo, ubuntu)
Andere Betriebssysteme werden nicht offiziell unterstützt, der Server kann jedoch auch
auf anderen Betriebssystemen laufen.179
Über eine vierwege Replikation der Master-Datenbank wird sichergestellt, dass unternehmensweit konsistente Daten für die Anwendungen im Unternehmen zur Verfügung
gestellt werden. Das dahinter stehende Konzept wird Multi-Master-Replikation genannt.
Im Gegensatz zur Master-Slave-Verfahren können Änderungen von Verzeichnisinhalten
auf mehreren Servern durchführt werden, um Engpässe zu vermeiden. Eine vierwege
Replikation bedeutet in diesem Fall, dass vier Master-Datenbanken existieren. Hierüber
wird auch eine hohe Skalierbarkeit des Systems sichergestellt, die auch große Daten-
178
179
Für nähere Informationen siehe http://directory.fedoraproject.org/wiki/Licensing.
http://directory.fedoraproject.org/wiki/FAQ
Seite 197
banken (>1 GB) unterstützt. Die vierwege Replikation der Masterdaten minimiert die
Downtime des Verzeichnisdienstes für Wartungs- und Reparaturarbeiten.
Der Fedora Verzeichnisserver hält insbesondere Informationen über Anwendungen, Anwendungseinstellungen, Benutzerprofile, Gruppendaten, Richtlinien und Zugriffskontrollinformationen (ACL; Access Control List) zentral in einem vom Betriebssystem unabhängigen und netzwerkbasierten Verzeichnis bereit. Eine Authentisierung kann über
SASL, GSSAPI und Kerberos V 5 erfolgen.180 Die Zugriffsrechte können dabei bis auf
die Ebene der Attribute dediziert festgelegt werden. Wie bei allen Verzeichnisservern
vereinfacht dies das Benutzermanagement, beseitigt die Datenredundanz und automatisiert die Datenpflege durch die Erzeugung eines zentralen Speichers für eine Identitätsmanagement-Infrastruktur. Er verbessert auch die Sicherheit, indem er Richtlinien und
Zugangsinformationen speichert und eine Personalisierung ermöglicht.
Weitgehende Kompatibilität besteht sowohl mit dem Sun ONE Directory Server als auch
mit Netscape Verzeichnisserver-Varianten. So ist es beispielsweise möglich, Daten zwischen den Servern zu replizieren. Zu OpenLDAP und dem eDirectory von Novell besteht
bis auf LDAP, wobei LDAPv2 und LDAPv3 unterstützt werden, keine Interoperabilität.
Zusammenfassend lässt sich feststellen: Der Fedora Verzeichnisserver ist als Alternative
zu OpenLDAP (im Zusammenhang mit Authentisierung) zu sehen. Hervorzuheben ist,
dass Fedora multimasterfähig ist, das heißt, dass Daten im Verzeichnis auf mehreren
Servern geändert werden können. Dadurch ist eine hohe Verfügbarkeit, zum Beispiel
beim Ausfall eines Servers, gewährleistet und Engpässe bei vielen Änderungen können
vermieden werden. Der Fedora Verzeichnisserver wurde als integrierte sichere Lösung
auch für die HP/UX-11-Betriebssystemumgebung auf HP Integrity und HP 9000 Servern
sowie Solaris-Systeme konzipiert. Der Produkteinsatz fokussiert sich in erster Linie auf
große Installationen und zeichnet sich durch einen großen Funktionsumfang und sehr
gute Skalierungsmöglichkeiten aus. Der Fedora Verzeichnisserver wird zudem hohen
Sicherheitsanforderungen gerecht.
1.3
Windows NT 4 Server als sogenannter Domänencontroller (DC)
Mit Windows NT4 hat Microsoft 1996 ein leistungsfähiges Betriebssystem für Computernetze auf den Markt gebracht. Insbesondere durch die Verwendung eines neuen Dateisystems (NTFS; NT File System) wurde eine differenzierte Rechtevergabe möglich. Zusammen mit dem Domänenkonzept, das bereits mit der Version 3.1 eingeführt wurde
und einen Sicherheitsbereich mit zentraler Verwaltung der Ressourcen darstellte, konnte
nun festgelegt werden, welcher Benutzer sich mit welchem Passwort anmelden und auf
welche Dateien und Dienste dieser in welcher Form zugreifen durfte. Die Client-ServerArchitektur ermöglichte über eine Vielzahl grafischer Unterstützungswerkzeuge ein
schnelles, differenziertes Aufsetzen und Erweitern von Computernetzen. Nicht zuletzt
über die enge Verzahnung mit weiteren Microsoft Serverprodukten wurde NT ein großer
kommerzieller Erfolg.
Microsoft Windows NT kam bereits 1993 in der Version 3.1 auf den Markt. Erst im Jahr
2000 wurde mit dem Nachfolger Windows 2000 das Kürzel NT aufgegeben. Microsoft
180
http://directory.fedoraproject.org/wiki/SASL_GSSAPI_Kerberos_Design
Seite 198
hat inzwischen den Support für NT eingestellt. Das heißt, dass das System herstellerseitig nicht mehr gepflegt wird und zum Beispiel neue Sicherheitslücken nicht mehr durch
Updates geschlossen werden. Ein sicheres NT-System kann mittelfristig daher nur über
kostspielige, individuelle Anpassungen gewährleistet werden. Trotz der Sicherheitsbedenken ist heute noch eine Vielzahl NT-basierter Netze im Einsatz.
NT-Lizenzen werden zwar nicht mehr vertrieben, doch die zum Zeitpunkt des Kaufs gültigen Lizenzbedingungen sind nach wie vor gültig. Unterschiedliche Lizenzmodelle mit
unterschiedlichen Kostenmodellen führen jedoch weiterhin zur Verwirrung und zu lizenzrechtlicher Unsicherheit.
Kerntechnologie der Anmeldedienste unter Windows NT ist die Struktureinheit „Domäne―. Die Domäne ist eine Verwaltungseinheit, die Computer- und Benutzerkonten mittels
einer gemeinsam genutzten Datenbank in einem gemeinsamen Sicherheitskontext zusammenfasst. Diese Datenbank wird als SAM (Security Accounts Manager) bezeichnet.
Sie wird zur Laufzeit in der Registry spezieller Serversysteme gehalten, den Domain
Controllern (DC). Neben Benutzer- und Computerobjekten werden auch Gruppen in der
SAM administriert. Jede dieser drei Objekttypen lässt sich durch eine sogenannte SID
(Security Identifier) eindeutig kennzeichnen, die sich auch in verschiedenen Domänen
nicht wiederholen darf. Zu jeder SID (ein relativ langer Zahlenschlüssel) existiert ein
SAM-Accountname, der in der Regel maximal 15 alphanumerische Zeichen umfassen
kann. Der SAM-Accountname ist der Name, den die Anwender zur Identifikation verwenden.
Eine Domäne benötigt mindestens einen Domain Controller, den sogenannten PDC
(Primary Domain Controller). Er hält die SAM der Domäne, sodass die Inhalte der SAM
nur bei ihm verändert werden können. Zur Lastverteilung und Redundanz der SAM werden sogenannte BDC (Backup Domain Controller) eingesetzt, die eine Kopie der SAM
halten und die regelmäßig um die Änderungen auf dem PDC aktualisiert werden.
Es ist möglich, mehrere Domänen über Vertrauensstellungen miteinander zu verknüpfen. Hierdurch können Benutzer oder Gruppen anderer Domänen für den Zugriff auf
Ressourcen (zum Beispiel File Services) der eigenen Domäne autorisiert werden. Eine
Vertrauensstellung zwischen NT Domänen ist nicht zwingend beidseitig (bidirektional).
Vertrauensstellungen sind auch nicht transitiv: wenn A B vertraut und B der Domäne C,
dann vertraut A nicht implizit auch C. Jede Vertrauensstellung muss also explizit eingerichtet werden.
Folgende Umstände haben zur Etablierung mehrerer Domänen in IT-Umgebungen geführt:

Oftmals sind parallele Insellösungen innerhalb einer Infrastruktur entstanden, die
später aufgrund von gemeinsamen Arbeitsprozessen mit Hilfe von Vertrauensstellungen zusammengeführt werden mussten. Dies gilt auch, wenn zwei Infrastrukturen zusammengeführt werden.

Die Domänengrenzen sind Grenzen der Sicherheit: Administratoren der Domäne
A sind nicht automatisch Administratoren der Domäne B, der man vertraut oder
die einem vertraut. Politische Überlegungen können hier eine Rolle spielen.
Seite 199

Die Komplexität der Delegation von Aufgaben wurde durch mehrere Domänen
kompensiert.

Die Anzahl der Objekte (Computer, Benutzer, Gruppen) in der SAM ist beschränkt, da die SAM zur Laufzeit in der Registry der Domain Controller, deren
Größe ebenfalls beschränkt ist, gehalten wird. Abhilfe konnte nur die Aufteilung
der Objekte auf mehrere Domänen bringen.

Die Skalierung von einer Domäne in stark verteilten, dezentralen Umgebungen
wird durch das Single-Master-Prinzip des PDCs eingeschränkt, da sämtliche Änderungen der SAM nur über ihn realisiert werden können.
Dies hat zu verschiedenen Domänenmodellen geführt, die u.a. von Microsoft selbst vorgeschlagen wurden:

Single Domain (eine Domäne)

Master Domain (mehrere Domänen vertrauen alle einer Master Domäne, typischerweise vertrauen Ressourcendomänen der Account-Domäne)

Multiple Master Domain (mehrere Ressourcendomänen vertrauen allen (mehreren) Account-Domänen)

Complete Trust Domain (jede Domäne vertraut den anderen)
Im weitesten Sinne sind Windows NT Domänen auch Verzeichnisdienste, denn in einer
Domäne sind Benutzerobjekte verzeichnet. Microsoft bezeichnet diesen mit NTDS (Windows NT Directory Service). Die Anzahl der Attribute eines Benutzerobjektes in einer NT
Domäne ist relativ klein und konzentriert sich auf technisch relevante Attribute und Eigenschaften. Die Attribute sind daher nicht vergleichbar mit dem Verzeichnisdienst basierend auf X.500.
Die Benutzereigenschaften umfassen u.a.:

Benutzername (SAM-Accountname)

Kontoinformationen (zum Beispiel Konto deaktiviert, Kennwort läuft nie ab, Ablauf
des Kontos, Kontotyp)

Gruppenmitgliedschaften

Umgebungsparameter (Logon-Script, Home-Verzeichnis, Pfad des servergestützten Profils)

erlaubte Anmeldezeiten, erlaubte Clientcomputer

RAS- (Remote Access Service)/ Einwahlparameter: erlaubt, mit/ ohne Rückruf
Darüber hinaus werden Attribute gespeichert, die vom Betriebssystem verwaltet werden,
wie zum Beispiel:

SID,

LastLoginTime

u.a.
Seite 200
Eine Erweiterbarkeit um selbst definierte Attribute ist nicht vorgesehen. Microsoft selbst
hat mit der Einführung von „Windows NT 4 Server Terminal Edition― und Citrix Metaframe zusätzliche Eigenschaften für das Benutzerobjekt implementiert (zusätzliche Homeund Profilpfade und weitere Citrix Parameter). Das NTDS kann nicht hierarchisch strukturiert werden. Die Vergabe von Rechten auf Attributebene ist nicht möglich. Eine flexible
Vergabe von Rechten auf Benutzerobjekte ist stark eingeschränkt.
Die Delegation von administrativen Aufgaben innerhalb einer NT-Domäne reduziert sich
auf

die Nutzung der eingebauten (Built-In) Gruppen (Domänen-Administratoren, Konten-, Server-, Sicherungs- Druck- und Reproduktionsoperatoren) und

die Installation zusätzlicher Domänen.
Diese Restriktionen haben wohl dazu geführt, dass die Delegation und bestehende Rollenkonzepte auf webbasierenden Anwendungen abgebildet wurden.
Eine Windows NT Domäne kann auf den Transportprotokollen TCP/IP, NetBEUI,
SPX/IPX basieren. In jedem Fall ist die NetBIOS Schnittstelle notwendig. In TCP/IPNetzwerken ist für die fehlerfreie Kommunikation die Namensauflösung von NetBIOSNamen (Computernamen, Benutzernamen, weitere Namenstypen wie zum Beispiel Arbeitsgruppe) zwingend erforderlich. Will zum Beispiel ein Benutzer sein Domänenkennwort ändern, muss er den PDC lokalisieren beziehungsweise seine IP-Adresse kennen.
Die NetBIOS-Namensauflösung kann in Windows Netzwerken auf unterschiedliche Weisen erfolgen:

durch Broadcast

durch Befragung eines WINS Servers (Windows Internet Name Service)

durch Auswerten der Datei LMHOSTS
Die eleganteste Lösung dieser Aufgabe ist der Einsatz von WINS-Servern (Windows
Internet Name Service). Nur diese ermöglichen die Namensauflösung über IP-Subnetze
hinweg, die Generierung dynamischer Inhalte und eine Minimierung der Broadcasts.
Oftmals ist der WINS-Dienst auf den Domain Controllern realisiert.
Zur Administration von Benutzerobjekten, Gruppen und Computern werden unter Windows NT vier grafische Bordmittel wie z.B. der Benutzermanager oder der Servermanager bereitgestellt. Darüber hinaus werden mit dem „NT Resource Kit― Tools geliefert, die
überwiegend auf der Kommandozeile ausgeführt und mit deren Hilfe Skripte zur automatischen Administration erstellt werden können. Des Weiteren kann eine Domäne auch
per Web-Interface verwaltet werden. Notwendig hierfür ist der Einsatz des Internet Information Servers (IIS) von Microsoft.
Unter Windows NT wird die SAM selbst verschlüsselt. Die Kennwörter der Benutzer
(auch der Computer) werden in der SAM der Domain Controller gespeichert. Dabei wird
nicht das Kennwort im Klartext, sondern ein Hash-Wert des Kennworts gespeichert. Die
Hash-Werte der Kennwörter werden nach verschiedenen Verfahren gebildet, die sich
wie folgt weiter entwickelt haben:
Seite 201

LM (LAN Manager)

NTLM

NTLMv2
Die Authentisierung innerhalb einer NT Domänenlandschaft basiert auf dem Mechanismus NTLM (NT LAN Manager). Es wird folgendes Szenario betrachtet: Eine Ressourcendomäne vertraut einer Account-Domäne. Eine funktionsfähige WINS-Umgebung ist
vorhanden. Ein Benutzer startet eine Windows NT Workstation, die Mitglied der Ressourcendomänen ist, und meldet sich an der Account-Domäne an. Beim Starten der
Windows NT Maschine erfragt diese per WINS eine Liste der Domain Controller (DC)
der Ressourcendomäne. Zunächst wird per Broadcast ein Netlogon-Request gesendet.
Wird dieser nicht von einem DC der Ressourcendomänen beantwortet, wird der Netlogon-Request an die DCs der erfragten Liste gesendet. Über einen sogenannten „Secure
Channel― mit dem zuerst antwortenden DC erfolgt die Validierung der Anmeldeinformation. Die NT Maschine erfragt im Anschluss eine Liste der vertrauten Domänen vom DC
der Ressourcendomänen. Nachdem der Benutzer in der Anmeldemaske die AccountDomäne ausgewählt sowie seine Kennung und sein Kennwort eingegeben hat, erfolgt
der Anmeldeprozess des Benutzerkontos. Der NT Client sendet die Anmeldeinformationen zur sogenannten „pass-through validation― an den DC der Ressourcendomäne, mit
dem die Maschine über einen Secure Channel verfügt. Der DC der Ressourcendomäne
sendet diese Anfrage an einen DC der Account-Domäne (zunächst lokal, dann gerichtet
über Secure Channel). Die validierten Anmeldeinformationen werden über den DC der
Ressourcendomäne an den NT Client zurückgeliefert. Dieser öffnet nun eine direkte
Verbindung zum DC der Account-Domäne, um dort das Logon-Script, Systemrichtlinien
oder Benutzerprofil zu laden.
Auf NT Systemen, die kein Domain Controller sind, werden die Anmeldeinformationen
der zuletzt angemeldeten Benutzer zwischengespeichert, um die Anmeldung auch dann
zu ermöglichen, wenn kein Domain Controller erreichbar ist (typischerweise Notebooks).
Diese Informationen werden wiederum in einem Hash-Wert gespeichert.
Das Domänenkonzept von Windows NT ermöglicht ein begrenztes Single Sign-On innerhalb der Microsoft Produktpalette. Der Anwender meldet sich einmalig an seiner Windows NT Workstation an und kann dann, sofern die Ressourcen beziehungsweise die
Serversysteme Mitglied der eigenen oder einer vertrauenden Domäne sind, auf Dienste
wie

File- und Print Services,

Exchange,

SQL und

Intranet (Web, Internet Information Server)
zugreifen. Dritthersteller von Software können ihre Produkte so implementieren, dass die
einmalige Anmeldung erhalten bleibt. In der Regel müssen sie aber ihre Anwendungen
auf Windows NT 4 Servern bereitstellen, die Mitglied einer Domäne sind.
In Windows NT Domänen können Richtlinien erlassen werden,
Seite 202

wie mit Kennwörtern umgegangen werden soll (Laufzeit, Mindestlänge, wiederholte, falsche Kennworteingabe) und

welche Privilegien (Benutzerrechte) Benutzer oder Gruppen haben sollen (Ändern der Systemzeit, lokale Anmeldung etc.).
Weiterhin kann eine Überwachung der erfolgten Zugriffe beziehungsweise der Zugriffsversuche eingeschaltet werden. Auf diese Weise können zum Beispiel

das An- und Abmelden,

das Verwenden von Benutzerrechten,

die Benutzer- und Gruppenverwaltung und

Änderungen der Sicherheitsrichtlinien
überwacht werden. Auswertungen hierüber sind mit Windows NT4 jedoch nur sehr aufwendig zu erstellen. Hierfür bietet Microsoft zusätzliche Tools wie zum Beispiel MOM.
Allerdings war die Überwachung von NT4 Maschinen mit MOM nur sehr schwer bis gar
nicht zu realisieren.
Aufgrund des eingestellten Supports gelten die NT-Systeme als nicht mehr sicher.
Computer auf der Basis Windows NT, Windows 2000 / 2003, Windows XP und Windows
Vista können originär Mitglied einer Domäne sein, wobei auch andere Betriebssysteme
eingebunden werden können. Linux basierte Clients können beispielsweise über Samba
eingebunden werden.
Fehlender Komfort der Bordmittel zur Administration von NT-Netzen hat Dritthersteller
dazu veranlasst, weitere Werkzeuge zu entwerfen. Diese nutzen vorrangig die APIs von
Windows NT. Microsoft selbst produzierte nachträglich die Microsoft Management Console (MMC), die schließlich in Windows 2000 integriert wurde. Mit ADSI (Active Directory
Service Interface) hat Microsoft eine COM-basierende Schnittstelle geliefert, mit der
auch Windows NT Domänen verwaltet werden können.
Zusammenfassend muss festgehalten werden: NT-Systeme gelten heute als nicht mehr
(ausreichend) sicher, sodass eine Ablösung zu empfehlen ist. Auch wenn NT-Systeme
den funktionalen Anforderungen vielfach noch entsprechen, so überwiegen die Nachteile, die sich insbesondere aus Fragen zur Sicherheit ergeben. Aufgrund der noch weiten
Verbreitung finden sich zwar problemlos noch aktuelle Virenscanner, aktuelle Treiber
neuer Hardware und auch neue Anwendungen für NT 4, allerdings wurde das Auslaufen
der Unterstützung für NT 4 schon mehrfach angekündigt.
1.4
Windows 2000/2003 Server mit Active Directory und Kerberos
Der Verzeichnisdienst von Microsoft Windows Server 2000 und 2003 heißt Active Directory. Er wurde mit Windows 2000 als dem Nachfolger von NT 4 eingeführt. Der Verzeichnisdienst stellt die zentrale Ressourcen-, Benutzer- und Gruppenverwaltung in
Windowsnetzwerken dar. Er verwendet mit LDAP181 und Kerberos 5182 offene Standards.
181
182
http://www.microsoft.com/windowsserver2003/techinfo/overview/ldapcomp.mspx
http://www.microsoft.com/windowsserver2003/technologies/security/kerberos/default.mspx
Seite 203
Mit der nächsten Version von NTFS wurde neben einer erneut verbesserten Komprimierung auch die Möglichkeit der Verschlüsselung von Daten über EFS (Encrypting File
System) geboten. Die Schlüsselverwaltung findet über das Active Directory statt. In Windows 2000 verfolgt Microsoft einen modularen Aufbau. Auf der untersten Ebene HAL
(Hardware Abstraction Layer) setzt der eigentliche Betriebssystemkern auf, der die Basis
für weitere Subsysteme wie Win32 oder POSIX bildet.
Der Nachfolger von Windows 2000 Server heißt Windows Server 2003 und wurde insbesondere im Bereich der Sicherheit verbessert. Änderungen am Active Directory betreffen
zum Beispiel die Vertrauensstellungen.
Seit seiner Einführung mit Windows 2000 Server hat das Active Directory zahlreiche
neue Funktionen bekommen. Diese wurden z.T. über das neue Server-Betriebssystem
Windows Server 2003 sowie über Service Packs veröffentlicht.
Die Server-Betriebssysteme und damit auch die Verzeichnis- und Authentisierungsdienste von Microsoft sehen sich einer starken Open-Source-Konkurrenz ausgesetzt. Laut
einer IDC-Studie entfällt bei Hewlett-Packard bereits ein knappes Drittel der Umsätze auf
Systeme auf Basis von Open Source Betriebssystemen.183
Das Active Directory ist Bestandteil der Windows Server 2000/2003 Lizenz. Windows
2000 wird seit 2005 nicht mehr vertrieben. Bis 2010 werden noch Sicherheitsaktualisierungen geliefert. Diese werden sowohl für den eigentlichen Windowsserver 2003 in verschiedenen Editionen (Standard, Enterprise und Datacenter jeweils in einer 32- und einer 64-Bit Architektur) als auch clientseitig für die Anzahl der User (User Client Access
Licence) oder die Anzahl der Geräte (Device Client Access Licence) angeboten beziehungsweise verlangt. Des Weiteren werden spezielle Lizenzen für virtualisierte Server
angeboten.
Hardwareseitig unterstützt Windows 2000 Server in der Datacenter Version bis zu 8
CPUs und kann max. 64 GB Arbeitsspeicher adressieren. Windows Server 2003 unterstützt bis zu 32 Prozessoren und kann ebenfalls max. 64 GB Arbeitsspeicher adressieren.
Hinsichtlich der Anmeldedienste von Windows NT kann das Active Directory (AD) als
korrespondierender Nachfolgedienst ab Windows 2000 bezeichnet werden. Kerntechnologie der Anmeldedienste im Active Directory bleibt wie unter Windows NT die Struktureinheit Domäne. Sie bleibt die Einheit, die die Computer- und Benutzerkonten mittels
einer gemeinsam genutzten Datenbank in einem gemeinsamen Sicherheitskontext zusammenfasst. Die Domänengrenze ist die Grenze des Sicherheitskontextes und der
Replikation der Benutzerdatenbank. Computer mit folgenden Betriebssystemen können
der Domäne sein:
183

Windows NT 4.0

Windows 2000
siehe Gengler, B.: „Linux-Server verdienen richtig Geld – Analysten sehen eine sich beschleunigende Nachfrage nach dem Opensource-Betriebssystem―,
http://www.computerzeitung.de/loader?path=/articles/2007012/31018914_ha_CZ.html&art=
/articles/2007012/31018914_ha_CZ.html&thes=&pid=ee54f3c7-0de1-40f5-bb232cfdf022aee5
Seite 204

Windows 2003

Windows XP

Windows Vista
Erhalten bleibt auch der NetBIOS-Namensraum. Sollen Systeme wie Windows NT und
9x unterstützt werden, ist es weiterhin notwendig, eine fehlerfreie NetBIOS Namensauflösung (zum Beispiel durch WINS) zu gewährleisten. Ob der Einsatz einer NetBIOS Namensauflösung erforderlich ist, wird nicht allein durch das Betriebssystem bestimmt,
sondern in erster Linie durch das Gesamtsystem. So kann es zum Beispiel sein, dass
auf dem Client Windows XP eingesetzt wird, der kein NetBIOS mehr benötigt, aber Applikationen auf dem Windows XP eingesetzt werden, die diese Namensauflösung sehr
wohl noch erforderlich machen.
Neben der Implementierung eines Active Directory stellen die Nutzung des Authentisierungsmechanismus „Kerberos― sowie einige Neuerungen bezüglich der (Domänen-)
Strukturierung die Eckpunkte im Architekturwechsel dar.
Im Folgenden wird zunächst auf die Nutzung des Authentisierungsmechanismus „Kerberos― in den neuen Windows Server Systemen eingegangen. Anschließend erfolgt ein
weitgehend umfassender Überblick über die Technologie des Active Directory und abschließend werden die Neuerungen hinsichtlich der Strukturierung behandelt.
Unter Windows 2000/2003 erfolgt die Authentisierung mittels des Authentisierungsmechanismus Kerberos, wobei NTLM weiterhin unterstützt wird. Clientsysteme wie Windows 2000 oder XP nutzen standardmäßig das Kerberos Protokoll, um sich bei der AD
Domäne zu authentisieren. Der Administrator kann hierbei unterscheiden, ob nur Kerberos erlaubt ist oder ob NTLM weiterhin für ältere oder Nicht-Microsoft-Betriebssysteme
angeboten werden soll. Windows 2003 DCs kommunizieren ausschließlich über das
Kerberos Protokoll.
1.4.1
Kerberos
Active Directory unterstützt eine Reihe sicherer Protokolle und Authentisierungsmechanismen, mit denen beim Anmelden die Identität nachgewiesen wird, so zum Beispiel
Kerberos V5, X.509 v3-Zertifikate, Smartcards, Infrastruktur öffentlicher Schlüssel (Public Key Infrastructure, PKI) und LDAP (Lightweight Directory Access Protocol) mit SSL
(Secure Sockets Layer).184
In Windows 2000/2003 ist Kerberos in der Version 5 mit Erweiterungen für die Authentisierung via öffentliche Schlüssel (public key) implementiert worden. Die Implementierung folgt Spezifikationen in den RFCs 1510 und 1964. Das Kerberos Key Distribution
Center (KDC) ist auf jedem DC des Active Directory integriert und verwendet die Benutzerdatenbank des AD.
Für das Kerberos Protokoll ist es notwendig, dass die Systemzeiten der beteiligten
Computer nur geringe Abweichungen aufweisen, da die Authentisierung des Computers
über ein sogenanntes Ticket gesteuert wird, dessen Gültigkeitsdauer auf 5 Minuten be-
184
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/
62355c36-a646-4bed-b462-dc8f23227447.mspx?mfr=true
Seite 205
grenzt ist. Zu diesem Zweck ist in Windows 2003 ein automatischer hierarchischer Zeitabgleich zwischen den Computern, die Mitglied des AD sind, implementiert worden.
Kerberos ist flexibler, effizienter und sicherer als die NTLM Authentisierung. Bei NTLM
muss ein Applikationsserver immer den Domain Controller kontaktieren, um einen Client
zu authentisieren. Erst danach erfolgt der Zugriff auf die jeweiligen Ressourcen. Mit dem
Kerberos Protokoll kann der Applikationsserver die Anmeldeinformationen untersuchen,
die ihm der Client präsentiert (Ticket). Unter NTLM können Server die Identität der
Clients prüfen, mit Kerberos kann der Client auch die Identität des Servers prüfen (mutual authentication). Windows Dienste müssen den Client nachahmen (impersonate), um
den Zugriff auf Ressourcen zu realisieren. NTLM und Kerberos können dem Dienst die
Informationen liefern, um den Client lokal nachzuahmen.
Die Authentisierung zwischen Domänen erfolgt über Vertrauensstellungen. Eine Vertrauensstellung ist eine Beziehung zwischen mindestens zwei Domänen, durch die Benutzer einer Domäne von einem Domänencontroller authentisiert werden können, der
sich in einer anderen Domäne befindet. Vertrauensstellungen können transitiv oder nicht
transitiv sein, müssen aber immer vorhanden sein, damit Benutzer in einer Domäne auf
freigegebene Ressourcen einer anderen Domäne zugreifen können.
Bei verteilten Applikationen mit Front- und BackEnd auf verschiedenen Rechnern scheitert NTLM, Kerberos hingegen bietet einen Proxy Mechanismus (delegated authentication). Kerberos kann transitive, bidirektionale Vertrauensstellungen zwischen Domänen
realisieren.
Das Kerberosprotokoll setzt sich aus drei Teilprotokollen zusammen. Das Teilprotokoll,
über welches das Schlüsselverteilungscenter (Key Distribution Center, KDC) dem Client
einen Anmeldesitzungsschlüssel und ein TGT (Ticket Granting Ticket) erteilt, wird als
Authentisierungsdienst (Authentication Service Exchange, AS Exchange) bezeichnet.
Das Teilprotokoll, über welches das KDC einen Dienstsitzungsschlüssel und ein Ticket
für den Dienst erteilt, wird als Ticketdienst (Ticket Granting Service, TGS Exchange)
bezeichnet. Das Teilprotokoll, über das der Client das Ticket für den Zugang zu einem
Dienst sendet, wird als Client/Server-Dienst (CS Exchange) bezeichnet.
1.4.2
Active Directory
Active Directory ist ein Verzeichnisdienst, der sich an den X.500 Standard anlehnt und
via LDAP (Lightweight Directory Access Protocol) administriert werden kann.
Der Verzeichnisdienst verwendet einen Datenbanktyp, der ursprünglich für Microsoft
Exchange (Extensible Storage Engine) entwickelt worden ist. Die Architektur der SAM
Datenbank wird dadurch abgelöst. SAM wird jedoch für mögliche, NT basierende BDCs
weiter bereitgehalten, solange das Active Directory nicht in den sogenannten „Native
Mode― geschaltet wird.
Das Active Directory speichert Informationen zu Netzwerkobjekten und stellt diese Informationen Benutzern und Administratoren über einfache Suchfunktionen zur Verfügung. Die Objekte im Active Directory beinhalten in der Regel freigegebene Ressourcen
wie Server, Laufwerke, Drucker sowie Konten für Netzwerkbenutzer und Computer. Active Directory verwendet einen strukturierten Datenspeicher, der als Grundlage für die
logische, hierarchische Anordnung von Verzeichnisinformationen dient.
Seite 206
Active Directory enthält einen Regelsatz, das sogenannte Schema, welches im Verzeichnis enthaltene Objekt- und Attributklassen, die Einschränkungen und Begrenzungen für Instanzen dieser Objekte sowie ihr Namensformen definiert. Das Schema kann
prinzipiell erweitert werden. Auch eine Erweiterung bestehender Klassen um neue Attribute ist möglich.
Des Weiteren beinhaltet das AD einen globalen Katalog mit Informationen zu allen im
Verzeichnis enthaltenen Objekten. Der Katalog ermöglicht Benutzern und Administratoren die Suche nach Verzeichnisinformationen unabhängig von der Domäne des Verzeichnisses, in dem die Daten enthalten sind.
Mit Hilfe eines Abfrage- und Indizierungsmechanismus können Objekte und ihre Eigenschaften veröffentlicht und von Netzwerkbenutzern oder Anwendungen gesucht werden.
Die Aufteilung des Active Directory beziehungsweise der Datenbank erfolgt über die
Struktureinheit der Domäne. Eine Aufteilung innerhalb der Domäne im Sinne einer dezentralen Datenbank ist also nicht möglich.
Die Replikation des Active Directory beziehungsweise der Datenbank erfolgt zwischen
den Domain Controllern (DC) über einen Replikationsdienst. Sie erfolgt anhand sogenannter Unique Sequence Number (USN), die bis auf Attributebene herunter verwaltet
werden. Die Replikation kann somit auf Attributebene erfolgen. Ändert sich also die Eigenschaft eines Objektes, wird lediglich die Änderung der Eigenschaft und nicht das
komplette Objekt repliziert. Alle Domänencontroller verfügen über eine vollständige Kopie sämtlicher Verzeichnisinformationen für ihre Domäne.
Jeder Domain Controller im Active Directory stellt einen LDAP-Dienst bereit. Es wird die
LDAP Version 3 unterstützt. Mit Hilfe eines LDAP-Clients kann das Active Directory
durchsucht oder administriert werden. Über den Distinguished Name kann das jeweilige
Objekt gelesen und geschrieben werden. Die Angabe des LDAP-Servers ist bei einigen
LDAP-Clients optional, sofern diese ein sogenanntes „serverless binding― beherrschen.
Im Prinzip kann eine beliebige LDAP-Clientimplementierung, wie zum Beispiel OpenLDAP beziehungsweise eine Programmierschnittstelle verwendet werden, wie zum Beispiel:

ADSI (Active Directory Services Interface )

LDIF (LDAP Data Interchange Format)

u.a.
Problematisch gestaltet sich der Gebrauch dieser Schnittstellen insofern, als dass

gewisse Attribute oder Objekte vom Active Directory hoheitlich verwaltet werden
und daher nicht geändert werden können (zum Beispiel die Attribute SID oder
GUID),
Seite 207

gewisse Attribute aus Binär- oder Hash-Werten bestehen, deren Ent- und Verschlüsselungsalgorithmen nicht bekannt sind (zum Beispiel das Attribut userParameters) und nur über separate Schnittstellen außerhalb LDAP modifiziert werden können (zum Beispiel Windows Terminal Server API) und

die Verwendung der grafischen Oberfläche zusätzliche Prozesse neben dem reinen Schreiben der LDAP Attribute auslöst (zum Beispiel beim Festlegen eines
Home-Verzeichnisses wird dieses auf dem File-Server mit den entsprechenden
Rechten angelegt).
Die Server-Version von Windows 2000/2003 wird mit zahlreichen grafischen Werkzeugen zur Verwaltung der in Active Directory standardmäßig abgelegten Informationen, wie
Benutzer- und Gruppenkonten oder DNS-Konfiguration, ausgeliefert. U.a. wird hierzu die
Microsoft Management Console (MMC) verwendet. Darüber hinaus stehen die aus Windows NT bekannten Werkzeuge für die Kommandozeile zur Verfügung, mit denen Benutzer und Gruppen angelegt, gelöscht und bearbeitet werden können. Über diese
Werkzeuge lässt sich jedoch nur ein Teil der in Active Directory gespeicherten Kontoinformationen bearbeiten.
Mit ldifde steht außerdem ein kommandozeilenbasiertes Programm zur Verfügung, mit
dem sich Verzeichniseinträge aus einer LDIF- Datei (LDAP Data Interchange Format)
erzeugen lassen.
Insgesamt wenden sich die mit Windows 2000/2003 Server gelieferten Verwaltungswerkzeuge eher an erfahrene Windows-Administratoren. Sie eignen sich kaum dazu,
einfache administrative Aufgaben, wie das Anlegen oder Verändern von Benutzerkonten
an weniger ausgebildete Kräfte zu delegieren.
Mit ADSI (Active Directory Service Interface) existiert eine COM-basierende Schnittstelle, mit der eine Vielzahl von Aufgaben automatisiert werden kann.
1.4.3
Neuerungen hinsichtlich der Strukturierung
Wie bereits erwähnt, bleibt die Struktureinheit Domäne als Grenze der Sicherheitszone
auch in einem Active Directory erhalten. Im Active Directory ist die Domäne als ein Baustein einer Gesamtstruktur (forest) und der dazu gehörenden Baumstrukturen (tree) zu
betrachten, die in einem DNS Namensraum hierarchisch gegliedert sind. Die einzelnen
Domänen sind über sogenannte bidirektionale Transitive Kerberos-Trusts (Vertrauensstelllungen) miteinander verbunden. Diese müssen nicht mehr einzeln eingerichtet werden (Die aus Windows NT bekannten Vertrauensstellungen via NTLM können weiterhin
eingesetzt werden). Mit einem Anmeldevorgang können Konten mit den erforderlichen
Berechtigungen auf die Ressourcen beliebiger Domänen in der Gesamtstruktur zugreifen. Wird von einem Active Directory gesprochen, ist damit immer die Gesamtstruktur
gemeint und nicht einzelne Bäume oder Domänen.
Die folgende Abbildung zeigt eine Windows NT Domänenstruktur, in der zwei AccountDomänen und fünf Ressourcendomänen durch Vertrauensstellungen miteinander verwoben sind.
Seite 208
Abbildung 25: Beispiel NT-Domänenstruktur
Microsoft stellt Active Directory Domänen dreieckig, Windows NT Domänen mit Ellipsen
dar. Diese Konvention wird für diesen Leitfaden übernommen.
Somit ergibt sich folgendes Bild: In einem Active Directory wäre dementsprechend die
folgende Gesamtstruktur denkbar, die ebenfalls sieben Domänen umfasst: Die Gesamtstruktur umfasst zwei Bäume, in denen die Domänen hierarchisch strukturiert und über
Kerberos transitiv (A vertraut B und B vertraut C, dann vertraut A auch C) und bidirektional (A vertraut B, dann vertraut B auch A) miteinander verbunden sind.
Abbildung 26: Beispiel Windows 2000
Das Active Directory wird von Domain Controllern (DC) bereitgestellt. Die Unterscheidung zwischen PDC und BDC wird nicht weiter fortgeführt. Dies trägt der architektonischen Neuerung Rechnung, dass Windows 2000/2003 Domain Controller sich einem
Multi-Master-Prinzip der Replikation unterwerfen, das heißt sämtliche Änderungen innerhalb des Active Directory können auf einem beliebigen DC durchgeführt werden. Bei
dem Multi-Master Prinzip sind nicht alle Rollen innerhalb der Domäne auf alle DC verteilt. Zu diesem Zweck gibt es Domain Controller mit einer speziellen Rolle. Die sogenannten FSMO-Owner (Flexible Single Master Operation).
Seite 209
Es handelt sich hierbei um:

PDC-Emulator

Infrastructure Master

RID Master

Schema Master

Domain Naming Master
Die Funktionen

Schema Master (zuständig für das Schema des Verzeichnisses) und

Domain Naming Master (zuständig bei Änderungen im Namensraum)
sind einmalige Rollen innerhalb einer Gesamtstruktur (forest).
Die Funktionen

PDC-Emulator,

Infrastructure Master (zuständig für Aktualisierungen von SIDs und Distinguished
Names über Domänengrenzen hinweg) und

RID Master (zuständig für die Vergabe von RID Pools an andere DCs)
sind eindeutig in jeder Domäne.
Der PDC-Emulator übernimmt wichtige Funktionen, wie

Kennwortaktualisierungen für Down-Level Clients (NT 4) und Partner der Windows NT Backup Domain Controller,

Quelle der Netzwerk-Uhrzeit (nur PDC der Stammdomäne) und

den Domänen Hauptsuchdienst (NetBIOS).
Eine Gesamtstruktur kann zusätzlich durch Standorte (Sites) strukturiert werden. Die
Sitestruktur sollte hierbei der physischen Netzwerkstruktur folgen und diese widerspiegeln sowie mit den verfügbaren Bandbreiten zwischen den Lokationen (zum Beispiel
Hamburg, Berlin, Bonn etc.) korrespondieren. Primärer Zweck dieser Strukturierung ist
die Steuerung der Replikation zwischen den Domain Controllern. Somit können die Replikationszeiten bei Bedarf der tatsächlich vorhandenen physischen Netzwerkstruktur angepasst werden.
Die Implementierung eines Active Directory bedarf zwingend einer DNS-Infrastruktur, die
nicht nur die Wahl eines Namensraumes, sondern auch die Verwendung geeigneter
DNS Server notwendig macht. Dies impliziert natürlich eine existierende TCP/IP Netzwerkumgebung.
Windows 2003 kann eine Public Key Infrastructure (PKI) als integralen Bestandteil einbinden. Zertifikatsdienste können über Windows Server 2003 eingerichtet und auf Windows XP Clients verteilt werden. Die PKI ist ein Netzwerkdienst, der Zertifikate erstellt
und jederzeit zu deren Verifizierung genutzt werden kann. Die Validierung von Zertifikaten erfolgt über zentrale Verzeichnisdienste, in denen diese Informationen durch die Zertifikatsdienste abgelegt werden, sodass Clients diese zentrale Infrastruktur anfragen.
Seite 210
Grundsätzlich werden Zertifikate zur Authentisierung, Verschlüsselung und Signierung
verwendet.
Anwendungsgebiete einer PKI können sein:

Sichere Authentisierung für Windows Anmeldung oder VPN-Einwahl

Verschlüsselung von Dateien oder E-Mails

Signierung von Dateien oder E-Mails

Sichere Kommunikation im Netzwerk (SSL, IPSec)
Die Certification Authority (CA) kann sowohl ins Active Directory integriert als auch separat installiert werden. Wird die integrierte Variante gewählt, werden hiermit die Sicherheitstechnologien wie

EFS (Encrypted File System),

IPsec,

Smartcard,

Verschlüsselung und digitale Signaturen (Mail)

u.a.
im internen Netzwerk unterstützt beziehungsweise ermöglicht. Die Verteilung beziehungsweise Aktivierung der PKI wird durch Gruppenrichtlinien unterstützt. Dies bedeutet
aber nicht, dass ein separates Verwaltungskonzept für den Umgang mit Schlüsseln
überflüssig wird.
Active Directory nutzt PKI und Zertifizierung über Sicherheitsfunktionen wie die Authentisierung und den gesteuerten Zugriff auf Verzeichnisobjekte. Die integrierte Authentisierung für die Anmeldung und Autorisierung von Benutzern, die zentrale Funktionen der
Local Security Authority (LSA) sind, stellt eine sichere Verzeichnisumgebung bereit. Dabei ist für den Benutzer nur eine einmalige Anmeldung notwendig, um Zugriff auf freigegebene Ressourcen im Netzwerk zu erhalten. Nachdem Active Directory die Identität
des Benutzers bestätigt hat, generiert die lokale Sicherheitsautorität auf dem authentisierenden Domänencontroller ein Zugriffstoken, das die Zugriffsstufe dieses Benutzers für
Netzwerkressourcen bestimmt.
Das Windows Active Directory ist zwingend erforderlich für Exchange 2003, da dieses
eine Erweiterung des Active Directory Schemas vornimmt und seine eigene Konfiguration speichert. Folgende Microsoft Produkte nutzen das Active Directory außerdem zur
Speicherung ihrer Konfiguration:

HIS Server (Host Integration Server)

ISA Server (Internet Security and Acceleration) im Enterprise Mode
Mit der Windows PowerShell wurde 2006 eine an die Unix-Shell angelehnte Methode zur
Programmierung in Windows Server 2003 eingeführt, mit der auch Zugriffe auf das Active Directory realisiert werden können. Sie unterstützt einfache Befehle aber auch komplexe Skripte, die in der PowerShell Scripting Language verfasst sein können. Den Kern
der PowerShell bilden Cmdlets. Das sind kleine Funktionseinheiten, die als .NETSeite 211
Klassen implementiert sind. Die PowerShell ist ein flexibles Instrument, das den Zugriff
auf WMI-Klassen (Windows Management Instrumentation), COM-Objekte (Component
Object Model) und das .NET-Framework erlaubt.
Mit ADSI (Active Directory Service Interface) existiert eine COM-basierende Schnittstelle, mit der eine Vielzahl von Aufgaben automatisiert werden kann.
Mit Active-Directory-Client sind viele neue Funktionen auch mit älteren Windows Betriebssystemen, insbesondere NT 4, nutzbar und gewährleisten so in gewissem Ausmaß
eine Abwärtskompatibilität. Dies sind u. a. Active Directory Service Interface, Active Directory Windows-Adressbuch und bestimmte Suchfunktionen.
Zusammenfassend ist anzumerken: Das Active Directory ist ein leistungsfähiger LDAPbasierter Verzeichnisdienst, der Kerberos 5 unterstützt. Es bietet neben effizienten Abfragemöglichkeiten differenzierte Replikationsmöglichkeiten und ist auch in großen Netzen einsetzbar. Obwohl mit Möglichkeiten zur Anbindung microsoftfremder Betriebssysteme versehen, ist die gesamte Funktionalität nur mit Windows basierten Rechnern gegeben.
2
Migrationspfade
Die Migration des zentralen Authentisierungsdienstes ist im Wesentlichen durch die
Überführung der Benutzer- und Gruppenkonten sowie im Zusammenspiel mit Windows
auch immer der Maschinenkonten aus einer bestehenden IT-Infrastruktur in die
vorgesehene neue IT-Infrastruktur für den Authentisierungsdienst geprägt. Dabei wird
selten ein Authentisierungsdienst alleine, das heißt ohne die anderen Basisdienste einer
IT-Infrastruktur, migriert werden. Bezüglich der IT-Infrastruktur hat sich in den letzten
Jahren immer stärker die Integration von Verzeichnissen als wesentliches Element
herausgeschält. Eine zunehmend wichtigere Rolle nimmt in solchen Authentisierungsinfrastrukturen die Single Sign-On (SSO) Infrastruktur auf Basis des Kerberos 5 Protokolls
ein.
Unter diesen Aspekten werden in den nächsten Abschnitten die folgenden Pfade für die
Migration des Authentisierungsdienstes betrachtet:

Migration von Windows NT DC nach Linux mit OpenLDAP, Samba und Kerberos

Migration von Windows 2000 mit Active Directory nach Linux OpenLDAP, Samba
und Kerberos

Migration von Linux und OpenLDAP, Samba und Kerberos nach Windows 2003
mit Active Directory

Migration von Windows NT als DC auf Windows 2003 mit Active Directory
Um eine Fehler- und Ausfallminimierung bei der Migration zu erreichen, sollte in der
Vorbereitung der Migration eine Testmigration mit exemplarischen Beispielsystemen
erfolgen. Hierbei sollten Probleme und Fehler, die durch spezifische organisatorische
und technologische Bedingungen bei den manuellen Migrationsschritten entstehen können, untersucht und entsprechend dokumentiert werden.
Seite 212
2.1
Migration von Windows NT DC nach Linux mit OpenLDAP, Samba und
Kerberos
Wie bereits in den Technologiebetrachtungen in den Kapiteln II.C 1.1 und II.E 1.1
festgestellt wurde, stellt ein Linux-System in Kombination mit Samba eine gleichwertige
Alternative zum Windows NT-Server dar. Durch die Hinzunahme des LDAPVerzeichnisses „OpenLDAP― wird gegenüber der auf Windows NT 4.0 Server
basierenden Authentisierungsinfrastruktur bereits ein erheblicher Mehrwert geschaffen,
da hiermit u.a. eine deutlich bessere und umfassendere Abbildung der eigenen
Organisation und die Abbildung von zum Beispiel Zugriffsrechten auf diese möglich ist.
Dieser Pfad wird im Migrationsleitfaden auch weiterhin betrachtet, da es noch viele Behörden gibt, die IT-Infrastrukturen betreiben, die auf Windows NT 4.0 Server basieren.
2.1.1
Funktionaler Vergleich
Windows NT nutzt als Verwaltungs- und Struktureinheit den Begriff Domäne. In den Domänencontrollern werden Maschinen- und Benutzerkonten und ihre zugehörigen Attribute im Security Accounts Manager (SAM) gespeichert. Dies geschieht in Form von eingeschränkten Verwaltungsdiensten (Registries). Die festgelegte Struktur der Attribute und
die beschränkte Skalierbarkeit stellen eine Einschränkung der Nutzbarkeit dar.
Die Nutzung von Linux in Kombination mit Samba und OpenLDAP ermöglicht es, mit
quelloffener Software die Funktionalität von Domänen Controllern nachzubilden. Samba
besitzt eine LDAP-Schnittstelle und kann damit auf OpenLDAP als Datenbank für Benutzer- und Maschinenkonten zurückgreifen. Somit kann eine echte Verzeichnisdienst basierte Lösung zur Administration von Benutzer-, Gruppen- und Hostinformationen realisiert werden.
Samba unterstützt aus Sicht der Windows-Clients das Konzept von PDCs (Primary Domain Controller) und BDCs (Backup Domain Controller). Ebenso ist es möglich, mit
Samba einen WINS-Service zu realisieren. Die serverseitige Replikation der SAMDatenbank zwischen PDC und BDC wird von Samba selbst nicht unterstützt. Dies wird
jedoch durch die Replikation der LDAP-Verzeichnisse realisiert. Die Authentifizierung
erfolgt in Samba über das NTLM-Protokoll (analog zu Windows NT). Sollen Linux Clients
in die neue Infrastruktur integriert werden, so kann die Authentisierung auf diesen über
verschiedene Möglichkeiten realisiert werden, zum Beispiel mit Hilfe des PAM-Moduls
„pam_ldap―185 über das LDAPv3 Protokoll direkt gegenüber dem LDAP-Verzeichnis oder
mit einen Samba Client gegenüber dem Samba DC.
Eine Kerberos-Authentisierung von Windows Clients, wie sie gegenüber Windows 2000
Server möglich ist, ist gegenüber Samba nicht möglich. Allerdings lässt sich in einer
Umgebung mit Linux, Samba und OpenLDAP ein Kerberos basiertes SSO, zum Beispiel
mit Hilfe der MIT- oder Heimdal-Implementierung des Kerberos 5 Protokolls realisieren
(siehe Kapitel II.C 1.1), sodass eine Authentisierung auch mit Windows Clients gegenüber dieser möglich ist.
Durch die modulare Bauweise der Samba-Software gibt es verschiedene Wege, den
Samba Domänen Controller (DC) zu administrieren. Neben der Konfiguration per Kom185
http://www.kernel.org/pub/linux/libs/pam/
Seite 213
mandozeile existiert für Samba ein webbasiertes Tool namens SWAT (Samba Web Administration Tool) zur Administration. Eine weitere empfehlenswerte Option ist der Einsatz der Software Webmin. Bei Webmin handelt es sich um eine freie webbasierte Sof tware, die Schnittstellen für die Konfiguration und Überwachung einer Vielzahl von Unix
basierten Diensten bereitstellt. Es gibt Webmin-Module u.a. für die Administration von
Samba, OpenLDAP und Kerberos.
Darüber hinaus lassen sich Benutzerkonten und Server wie gewohnt mit den WindowsTools administrieren.
2.1.2
Migrationspfad
Die Migration eines Windows NT 4.0 Server DC auf ein Linux-System mit Samba und
OpenLDAP ist grundsätzlich machbar und kann für die Nutzer transparent vorgenommen
werden. Im Folgenden werden die wichtigsten Schritte beschrieben und einige Hinweise
für die Durchführung gegeben.
Zunächst einmal sollten die neuen Domänen Controller aufgebaut werden. Dazu sind
neben der gewählten Linux-Distribution auch die Komponenten Samba, OpenLDAP zu
implementieren. Bei der Einführung einer SSO Lösung, sofern eine solche Lösung aufgebaut werden soll, muss entweder die MIT- oder die Heimdal-Implementierung des
Kerberos 5 Protokolls installiert werden.
Für die spätere Benutzer-, Gruppen und Rechnerverwaltung im LDAP-Verzeichnis ist es
hilfreich, wenn die Smbldap-Tools verfügbar sind. Diese Tools werden u.a. auch von
Samba selbst verwendet, sofern Benutzerkonten mit Windows Tools verwaltet werden.
2.1.2.1
Definition und Implementierung des Verzeichnisbaumes
Der Aufbau eines Verzeichnisdienstes auf Basis von OpenLDAP ist vor allem geprägt
von der Definition und der Implementierung des Verzeichnisbaumes. Hier ist es besonders wichtig, dass insbesondere klare Vorstellungen über den prinzipiellen Aufbau der
Gesamtstruktur des Verzeichnisbaumes bestehen. Der Vorteil in einer Linux-OSSbasierten Umgebung ist, dass diese den Bedürfnissen entsprechend relativ frei definiert
werden kann. Aus Sicht der Authentisierung gegenüber Samba ist es vor allem wichtig,
dass das entsprechende zu Samba gehörende Schema integriert wird. Die nötigen Informationen über die Struktur und den Aufbau der Nutzer-, Gruppen- und Maschinenobjekte werden mit der vom Samba-Paket zur Verfügung gestellten Datei „samba.schema―
bereitgestellt.
2.1.2.2
Samba-Konfiguration
Bezüglich der Sambakonfiguration ist anzumerken, dass in der Konfigurationsdatei
/etc/smb.conf festgelegt wird, dass OpenLDAP als Backend zu verwenden ist. Darüber
hinaus werden hier auch die notwendigen Einstellungen vorgenommen, die während der
konkreten Migrationsphase vorzunehmen sind. Sie erfolgen gemäß nachfolgender Beschreibung.
2.1.2.3
Migration der SAM-Datenbank
Die Migration der SAM-Datenbank, das heißt die Überführung der Benutzer-, Gruppenund Maschinenkonten mit den Credentials (Kennung und Passwort) vom bestehenden
Seite 214
Windows DC zum neuen Samba DC, ist der wesentliche Schritt bei der Migration. Dieser
sollte in einer weitgehend gesicherten Umgebung erfolgen. Es sollte somit sichergestellt
sein, dass in dieser Phase nach Möglichkeit keine größeren Änderungen an der SAM
vorgenommen werden. Warum dies sinnvoll ist, verdeutlichen die folgenden Details:

Nachdem der zukünftige Samba PDC erfolgreich eingerichtet, wurde muss dieser
zunächst als Backup Domänen Controller (BDC) konfiguriert (/etc/smb.conf: „domain master = no―) und in die bestehende Windows NT Domäne als solcher integriert werden (net rpc join -U administrator –S %domain).

Anschließend können die Inhalte der SAM-Datenbank mit dem Befehl
„net rpc vampire –S %domain―
in das OpenLDAP-Verzeichnis überführt werden.

Nach dieser Übertragung werden weitere Änderungen im Windows NT PDC
(zum Beispiel eine Passwortänderung durch einen Benutzer) nicht mehr in den
Samba-BDC übernommen, daher sollte umgehend der Austausch vorgenommen
werden.

Abschließend wird der Samba BDC zum Samba PDC umkonfiguriert.
2.1.3
Einführung von Kerberos
Da Windows NT 4.0 Server weder SSO noch das Kerberos 5 Protokoll unterstützt, handelt es sich hierbei um keine Migration. Die Einführung einer SSO-Lösung beziehungsweise einer Authentisierung auf Basis des Kerberos 5 Protokolls entspricht einem Neuaufbau der benötigten IT-Infrastruktur. Die entsprechenden Möglichkeiten sind in den
Technologiebetrachtungen im Kapitel II.C 1.1 dargelegt.
2.1.4
Fazit / Empfehlung
Die Migration von Windows NT 4.0 Server DC auf ein Linux basiertes System unter Nutzung von Samba, OpenLDAP kann mit Hilfe der beschriebenen Tools und Verfahren auf
eine transparente Art und Weise erfolgen. Funktional bietet das neue System alle Eigenschaften des Windows NT DC und bietet mit der Einführung eines LDAPv3 basierten
Verzeichnisdienstes einen deutlichen Mehrwert sowie Verbesserungen hinsichtlich Skalierbarkeit und Performance. Eine Migration kann daher empfohlen werden. Die Möglichkeit, nunmehr auf Basis des Kerberos 5 Protokolls auch eine sicherere Authentisierung
und ein SSO zu realisieren, stellt einen weiteren Mehrwert dar.
2.2
Migration von Windows 2000 mit Active Directory nach Linux OpenLDAP,
Samba und Kerberos
Die Ablösung von Windows 2000 mit Active Directory durch ein Linux basiertes System
ist grundsätzlich möglich, jedoch funktionieren einige Teile anschließend etwas anders
als vorher. Mit der aktuell stabilen Version von Samba kann eine Windows 2000 Server /
Active Directory Architektur nicht vollständig nachgebaut werden. Wo die Unterschiede
hinsichtlich der Authentisierung liegen, wird nachfolgend im Rahmen der Betrachtung
des Migrationspfades erläutert.
Seite 215
Die Wahl von Windows 2000 Server als Ausgangssituation wurde gewählt, da eine Migration von Windows Server 2003 heute eher als eine Ausnahmeoption angesehen wird.
Behörden, die aktuell oder in jüngster Zeit auf Windows 2003 Server gewechselt haben,
werden schon aus wirtschaftlichen Gründen und aus Gründen des Investitionsschutzes
gegenwärtig kaum eine erneute Migration durchführen.
2.2.1
Im Active Directory werden Information über Nutzer, Gruppen, Maschinen, Freigaben,
Dienste und Geräte als Objekte gespeichert.
Die Authentifizierung von Benutzern und Maschinen wird über Kerberos realisiert. Dabei
wird eine Microsoft eigene Implementierung des Kerberos 5 Protokolls mit proprietären
Erweiterungen eingesetzt.
Mit Hilfe eines Linux-Systems in Kombination mit Samba 3.x, OpenLDAP 2.4.x und einer
offenen Implementierung des Kerberos 5 Protokolls (Heimdal oder MIT) lassen sich die
wesentlichen Funktionen der Windows 2000 Server / Active Directory Kombination hinsichtlich der Authentisierung abbilden.
Der kritische Punkt für eine Migrationsentscheidung sind die Lock-In Szenarien. Somit
muss die Frage geklärt werden, ob es Dienste und Anwendungen gibt, welche die proprietären Schnittstellen des Active Directory verwenden und mit welchem Aufwand und
innerhalb welchen Zeitraumes sich diese Abhängigkeiten auflösen lassen. Die ersten
Dienste und Anwendungen, die in diesem Zusammenhang regelmäßig eine Rolle spielen, sind Exchange 2003, MS SQL Server und in Zukunft auch verstärkt die verschiedenen Versionen der SharePoint Server.
Lassen sich diese Lock-In Szenarien nicht unter wirtschaftlichen Grundsätzen auflösen,
dann wird eine positive Entscheidung für den hier betrachteten Migrationspfad eher
schwierig. Dies wird, soweit heute absehbar, auch für die neueren Versionen der Windows Server Systeme so sein.
Ob eine Version 4 von Samba, die sich derzeit in Entwicklung befindet, eine Abhilfe
schaffen kann, ist heute noch nicht absehbar und soll daher hier vorerst auch nicht weiter thematisiert werden.
2.2.2
Migrationspfad
Nachfolgend wird nun die Ablösung einer Windows 2000 Server Authentisierungsinfrastruktur mit Active Directory und Kerberos betrachtet. Der wesentliche Schritt dabei ist, wie
eingangs bereits erwähnt, die Überführung der Benutzer- Gruppen- und Maschinenkonten sowie der entsprechenden Credentials. Im Gegensatz zum älteren Migrationspfad
von Windows NT 4.0 Server nach Linux in Kombination mit Samba und OpenLDAP
muss hier zusätzlich geprüft werden, inwieweit eine Überführung der KerberosAuthentisierungsinfrastruktur unter Windows 2000 Server machbar ist beziehungsweise
wie ein Migration durchgeführt werden kann.
Genau wie bei einer Ausgangslage, die auf Windows NT 4.0 Server basiert, müssen
zunächst die entsprechenden Domänencontroller mit Linux, Samba und OpenLDAP aufgebaut werden (siehe KapitelII.C 2.1.2 II.C 2.1.2).
Seite 216
Ebenso muss genau analysiert werden, wie die zukünftige Verzeichnisstruktur aussehen
soll. Sicherlich ist es dabei nicht unerheblich, dass eine Ablösung des AD vorgesehen
ist.
2.2.2.1
Migration der Benutzer- und Maschinenkonten
Nach erfolgreicher Implementierung der DCs und des LDAPv3 basierten Verzeichnisdienstes besteht die Möglichkeit, die notwendigen Benutzer-, Gruppen- und Maschineninformationen per LDAP aus dem AD zu holen. Dabei muss beachtet werden, dass es
Unterschiede, vor allem in der Bezeichnung der Attribute im AD und im OpenLDAPVerzeichnis gibt. Diese müssen durch ein entsprechendes Mapping genau zugeordnet
werden.
Das grundlegende Problem bei der Übernahme dieser Informationen ist, dass die Credentials aus dem AD nicht ohne weiteres mit übernommen werden können, da diese
durch die Kerberos-Implementierung verschlüsselt abgelegt werden. Es bestehen zwei
Möglichkeiten, diesem Problem zu begegnen. Eine der beiden Möglichkeiten kann wohl
als eine eher theoretische Möglichkeit angesehen werden, da sie einer längerfristigen
Vorbereitung bedarf und als relativ komplex angesehen werden kann. Dabei werden die
Credentials mittels einer Dynamic Link Library (DLL) auf einem AD Server immer dann
abgefangen, wenn diese durch einen Benutzer verändert werden, und in das OpenLDAP
Verzeichnis übertragen. Sollte ein Benutzer in der Zeit, in der diese Aktion durchgeführt
wird, keine Änderung vornehmen, müssten für diesen die Credentials auf einen Standardwert bei der Übertragung der Informationen aus dem AD zurückgesetzt werden.
Bei der zweiten Möglichkeit werden zur Vereinfachung des gesamten Verfahrens die
Credentials für alle Benutzer zurückgesetzt. Dann ist die Migration für die Benutzer zwar
nicht mehr transparent, mit Blick auf die Verfahrensvereinfachung und den für die Migration geringeren Zeitbedarf jedoch durchaus vertretbar.
Nach erfolgreicher Übernahme der Informationen aus dem AD können die Samba DCs
die Windows DCs entsprechend ablösen. Diese arbeiten dann wie Windows NT 4.0
DCs.
Abschließend sei noch darauf hingewiesen, dass Samba Version 3.x die Group Policy
Objects unter Windows 2000 nicht unterstützt. Der wesentliche Teil dieser GPOs kann
allerdings über System Policies und lokale Policies realisiert werden.
2.2.2.2
Migration der Kerberos-basierten Authentisierungsinfrastruktur
Eine Migration der Kerberos basierenden Authentisierungsinfrastruktur unter Windows
2000 Server mit AD ist nicht möglich. Dem steht vor allem entgegen, dass die entsprechenden Schlüssel aus dem AD nicht übernommen werden können.
Will man auch in der neuen Umgebung eine Kerberos basierte Authentisierungsinfrastruktur verwenden, dann muss eine entsprechende Infrastruktur neu aufgebaut werden.
Hinweise hierzu finden sich in Kapitel II.C 1.1.
Zu beachten ist, dass Gruppenrichtlinien mit den freien Implementierungen von Heimdal
und MIT nicht wie bei Windows 2000 mit Kerberos-Tickets übertragen werden können.
Microsoft hat hierzu eine proprietäre Erweiterung am Kerberos 5 Protokoll vorgenommen.
Seite 217
2.2.3
Fazit / Empfehlung
Bezüglich der Authentisierung wird eine Entscheidung für oder gegen den hier betrachteten Migrationspfad wohl in erster Linie davon abhängen, ob und welche Lock-In Szenarien bestehen und ob beziehungsweise wie effizient sich diese auflösen lassen. Die funktionalen Unterschiede dürften nur eine sekundäre Rolle für eine Entscheidung spielen,
da sie hinsichtlich der Authentisierung nur gering sind. Es ist allerdings nicht auszuschließen, dass sich dies im Rahmen einer Gesamtmigration auch anders darstellen
kann.
2.3
Migration von Linux und OpenLDAP, Samba und Kerberos nach Windows
2003 mit Active Directory
In diesem Abschnitt werden die Möglichkeiten und Vorgehensweise zur Migration eines
Linux basierten Systems in Kombination mit Samba, OpenLDAP und einer freien Kerberos-Implementierung auf ein Windows 2003 System mit Active Directory beschrieben.
Im Gegensatz zu den vorher betrachteten Migrationspfaden, die die Ablösung eines
Windows basierten Authentisierungsdienstes zum Ziel hatten und bei denen es darum
ging, dass auch weiterhin Windows Clients eingesetzt werden können, geht es bei der
hier betrachteten Migration auch darum, dass weiterhin Linux Clients in der Zielumgebung eingesetzt werden können.
Dazu ist es notwendig, dass auf den neu aufzubauenden Windows 2003 DCs auch die
Microsoft Services For Unix (SFU)186 bereitgestellt werden, um auch die Funktionen der
POSIX Authentifizierung verfügbar zu machen und um damit die Anbindung von Linux
Clients zu ermöglichen.
2.3.1.1
Migration der Benutzer- und Maschinenkonten
Die Übernahme der Benutzer-, Gruppen- und Maschineninformationen erfolgt genau wie
in die andere Richtung über die LDAPv3-Schnittstelle von AD. Ebenso wie bei der Migration in die andere Richtung ist es notwendig, ein entsprechendes Attributmapping vorzunehmen, um eine korrekte Abbildung der zueinander passenden Attribute sicherzustellen.
Auch hier besteht ein Problem mit der Übernahme der Credentials, da diese ebenfalls
verschlüsselt abgelegt werden. Als Lösung wird die Rücksetzung der Credentials empfohlen. Dies ist das einfachere und weniger zeitintensive Verfahren.
186
http://www.microsoft.com/germany/windowsserver2003/technologien/sfu/default.mspx
Seite 218
2.3.1.2
Migration der Kerberos basierten Authentisierungsinfrastruktur
Eine Migration der Kerberos basierten Authentisierungsinfrastruktur ist aus den gleichen
Gründen auch hier nicht möglich. Die Konfiguration der Kerberos basierten Authentisierungsinfrastruktur muss neu aufgebaut werden, wobei diese bei der Serverinstallation
automatisch mit installiert wird, anschließend jedoch noch entsprechend zu konfigurieren
ist.
2.3.2
Bekannte Probleme
Abgesehen von der Replikation des LDAP-Verzeichnisses können die Migrationsschritte
nicht automatisiert werden. Daher ist für die Migration ein entsprechend langer und flexibler Zeitrahmen einzuplanen. MS stellt für diesen Migrationsweg, anders als die OSSCommunity, bislang keinerlei Unterstützung zur Verfügung.
2.3.3
Fazit / Empfehlung
Da Microsoft im Gegensatz zur Open Source Community für die Migration von einer Linux basierenden IT-Infrastruktur hin zu einer Windows basierenden IT-Infrastruktur bislang noch keine geeigneten Migrationstools zur Verfügung stellt, ist ein Migrationspfad
hin zu einer Windows 2003 Server basierenden IT-Infrastruktur relativ aufwendig und
basiert auf vielen manuellen Migrationsschritten. Die Migration ist aber grundsätzlich
machbar.
2.4
Migration von Windows NT als DC auf Windows 2003 mit Active Directory
Mit einer Migration von Windows NT als DC auf einen Windows 2003 Server erfolgt ein
grundsätzlicher technologischer Wechsel der Authentifizierungs- und Verzeichnisdienste.
2.4.1
Während Windows NT auf NetBIOS, WINS, NTLM, SMB und einem eingeschränkten
Verzeichnis basierte, werden mit Windows 2003 LDAP, Kerberos, DNS und CIFS leistungsfähigere und erweiterbare Technologien genutzt. Durch weitergehende Änderungen in der Domänenstruktur und den Authentifizierungsmechanismen ergeben sich während der Migration Anforderungen an eventuelle Neukonzeptionen.
Grundsätzlich gibt es unterschiedliche Optionen, wie die Migration durchgeführt werden
kann. Hierzu gehören ein Upgrade des alten Systems187, Neuinstallation oder Domänenupgrade188. Empfohlen werden kann eigentlich nur eine Neuinstallation auf passender
Hardware mit einer Domänenrestrukturierung. Das heißt, dass mit der Migration prinzipiell auch eine grundlegende Anpassung der Domänenstrukturen einhergeht.
187
188
Hier muss sichergestellt sein, dass die bestehende Hardware den Anforderungen des neuen Systems gerecht wird.
Die Strukturen der NT-Domäne werden in das Active Directory umgewandelt.
Seite 219
2.4.2
2.4.2.1
Migrationspfad
Grundsätzliche Schritte
Um die Migration so transparent und minimal-invasiv wie möglich zu gestalten, wird
empfohlen, in einem ersten Schritt das Update auf Windows 2003 durchzuführen und
erst anschließend die Restrukturierung der Domänen durchzuführen.

Sicherung des IST-Zustands
Der PDC wird auf einen BDC repliziert. Dieser BDC wird vom Netz genommen
und dient als Sicherung.

Migration des PDC
Der PDC wird auf Windows 2003 migriert. Dies erfolgt je nach Szenario über ein
Betriebssystem-Update oder über eine Neuinstallation. Nach Abschluss der Migration arbeitet die Domäne im gemischten Modus (paralleler Betrieb von NT und
2003-basierten Systemen).

Migration der BDC (optional)
Im nächsten Schritt können die BDCs über ein Update oder eine Neuinstallation
auf Windows 2003 umgestellt werden. Dieser Schritt ist optional, da im gemischten Modus auch der Windows 2003 PDC auf NT4 BDCs repliziert werden kann.

Schalten in den einheitlichen oder 2003 Modus
Wurden auch die BDCs auf 2003 migriert kann die Domäne von dem gemischten
Modus in den einheitlichen Modus oder den 2003-Modus geschaltet werden.

Optimierung der Domänenstrukturen (optional)
Nach erfolgreicher Migration können die Domänenstrukturen optimiert und konsolidiert werden.
2.4.2.2
Update von Windows NT auf 2003
Das Update von Windows NT auf 2003 erfolgt über die Betriebssystem-CD. Während
des Updates müssen über die benutzerdefinierte Installation der Netzwerkdienste der
DNS- und der DHCP-Dienst installiert werden.
Nach erfolgreichem Betriebssystem-Update wird auf der Kommandozeile das Programm
„dcpromo― ausgeführt. Hierdurch erfolgt mit Hilfe eines Assistenten die Konvertierung der
Windows NT Domäne in das Active Directory.
2.4.2.3
Konsolidierung der Domänenstruktur
Mit Hilfe des Active Directory Migration Tools (ADMT) kann nach der Migration der NT
Domäne auf Active Directory eine Umstrukturierung der Domäne(n) erfolgen. Hierbei ist
es oft möglich, die Domänenstruktur durch Verringerung der genutzten Domänen zu
vereinfachen. Die Verwaltung von Benutzern, Gruppen und Gruppenrichtlinien wird vereinfacht und die unidirektionalen Vertrauensstellungen der NT-Domänen können automatisch in bidirektionale Vertrauensstellungen von Windows 2003 umgewandelt werden.
Seite 220
2.4.2.4

Zu beachtende Punkte
Service Pack 5
Für die Umstellung auf Windows 2003 ist es zwingend erforderlich, dass auf den
umzustellenden Windows NT Rechnern das Service Pack 5 installiert ist.

Änderung Rechnername
Da die Rechnernamen von Domänencontrollern nicht geändert werden können,
kann es bei der Migration zu Problemen kommen. Dies ist besonders dann der
Fall, wenn Windows 2003 auf einem komplett neuen System installiert wird. Sollte dies der Fall sein, wird empfohlen, das neue System aufzusetzen, mit Hilfe eines temporären Namens ins Netz zu integrieren und die Daten des alten NTSystems zu kopieren. Im Anschluss kann dann der Name geändert und der Domäne als Domaincontroller beigetreten werden.
2.4.3
Fazit / Empfehlung
Die Migration auf Windows 2003 stellt eine Möglichkeit dar, das veraltete NT-System
abzulösen und historisch gewachsene Strukturen zu überdenken und abzulösen.
3
3.1
Bezüge
Grundlegende Überlegungen
Viele andere Infrastrukturdienste und Anwendungen haben aus ihrer Sicht einen Bezug
zum Authentisierungsdienst und damit auch zum Verzeichnisdienst, wenn beides, wie
hier im Leitfaden, als eine Einheit betrachtet wird. Damit kann ein Authentifizierungsdienst in der Regel auch nicht isoliert betrachtet beziehungsweise migriert werden. Wenn
es um die Migration eines Authentifizierungsdienstes geht, muss der Bezug zu allen
Diensten und Anwendungen hergestellt werden, die auf den Authentifizierungsdienst in
der bestehenden Umgebung zugreifen und diesen nutzen. Im Prinzip kann dies fast alle
technisch orientierten Themen betreffen, die im Rahmen des Migrationsleitfadens behandelt werden. Eine Ausnahme stellt hierbei vielleicht das Thema Officeanwendungen
dar. Da die Migration des Authentifizierungsdienstes häufig auch mit einem Wechsel des
Betriebssystems einher geht (fortführend oder ablösend), müssen die anderen vorhandenen Infrastrukturdienste und Anwendungen mit betrachtet werden und sei es nur, um
zu prüfen, dass ein Einsatz unter dem neuen Betriebssystem problemlos möglich ist.
Dazu sollten dann die entsprechenden Abschnitte im Migrationsleitfaden zu Rate gezogen werden.
3.2
Verzeichnisdienst
Ein eigenes Thema Verzeichnisdienst ist im Moment im Migrationsleitfaden nicht vorgesehen. Daher soll an dieser Stelle darauf hingewiesen werden, dass die grundlegenden
Überlegungen, wie sie im einleitenden Kapitel zu den Migrationspfaden zu Datenbanken
beschrieben werden (siehe Kapitel II.A 2) in Teilen auf die Migration von Verzeichnisdiensten übertragen werden können. Insbesondere, wenn man bedenkt, dass im Ba-
Seite 221
ckend der meisten Verzeichnisdienste Datenbanken liegen. Die beiden folgenden
Grundsätze sollten in jedem Fall beachtet werden:

Bei der Ausgestaltung einer Verzeichnisdienstlösung eine Orientierung an herstellerunabhängigen Standards erfolgen. Die Anwendung von herstellerspezifischen Techniken und Funktionen sollte vermieden werden.

Eine Verzeichnisdienstlösung sollte sich auf die Kernfunktionalität eines Verzeichnisdienstes konzentrieren, nämlich der Speicherung und Bereitstellung von
Daten. Der Zugriff auf die Daten und deren Verarbeitung sollte losgelöst vom
verwendeten Produkt entweder über eigene Anwendungen oder mittels geeigneter LDAP-Browser.

Für die Gestaltung der Struktur der Verzeichnisbäume sollten so weit als möglich
vorhandene Standardschemata zum Einsatz kommen.
Unter Beachtung dieser minimalen Vorgaben sollte dann auch eine Migration von einem
X.500-Verzeichnis zu einem LDAP-Verzeichnis machbar sein.
Für tiefer gehende Betrachtungen müsste ein eigenes Migrationsthema Verzeichnisdienst losgelöst vom Authentisierungsdienst im Leitfaden aufgenommen werden. Sollte
sich hierfür ein entsprechender Bedarf zeigen, wird der Migrationsleitfaden dies aufgreifen.
Seite 222
D Thema Netzwerkdienste
Die infrastrukturbildenden Dienste für TCP/IP basierte Netzwerke (DNS, DHCP, NTP,
Routing, VPN, Filtering) lassen sich durchweg in Open Source Software realisieren. Die
umfassende Verfügbarkeit dieser Netzwerkdienste als OSS erklärt sich aus der Entwicklungsgeschichte des Internet. Dieses weltweite Datennetz zeichnet sich dadurch aus,
dass alle daran angeschlossenen Computer ein und dieselbe Sprache sprechen. Diese
Sprache besteht aus einer ganzen Familie von Protokollen, die unter der Bezeichnung
TCP/IP zusammengefasst werden. Damit die Kommunikation zwischen den unterschiedlichsten Systemen weltweit reibungslos funktioniert, muss das „Sprachverständnis― unbedingt übereinstimmen. Um diese Übereinstimmung zu erreichen, sind die meisten der
bei der Internet Engineering Task Force (IETF) formell verabschiedeten Standards für
Internetprotokolle durch Open Source Referenzimplementierungen unterstützt. Auf
Grundlage dieser Referenzen können alle Hersteller unabhängig voneinander vollständig
interoperable Software entwickeln. Die Internetprotokolle selbst sind herstellerunabhängig und sowohl in ihren Definitionen als auch in ihren Open Source Implementierungen
offene Standards. Dieser besondere Charakter der Internetprotokolle hat entscheidend
dazu beigetragen, dass sich TCP/IP gegenüber den gleichzeitig am Markt befindlichen
proprietären Netzwerkprotokollen durchgesetzt hat.
Auch wenn im lokalen Netz die Anforderungen bezüglich Interoperabilität aufgrund der
begrenzten Anzahl beteiligter Systeme überschaubar bleiben, ist die Bewahrung der
offenen Standards von essenzieller Bedeutung. Dies hat dazu geführt, dass die herstellerspezifischen Netzwerkdienste für lokale Netze wie zum Beispiel der Microsoft Windows Internet Name Service (WINS) und das Network Basic Input Output System (NetBIOS) immer stärker in den Hintergrund treten.
Diese Dienste werden nachfolgend auch betrachtet, da sie noch genutzt und erst sukzessive abgelöst werden. Der Fokus richtet sich aber vor allem auf die beiden wichtigsten Netzwerkdienste, den auf dem Dynamic Host Configuration Protocol (DHCP) basierenden Dienst für die Zuweisung von IP-Adressen und den Domain Name Service
(DNS).
1
Die meisten der nachfolgend beschriebenen Dienste basieren auf TCP/IPv4. Eine Betrachtung von IPv6 findet nur vereinzelt statt.
1.1
NetBIOS, WINS, DNS und DHCP unter Windows NT/2000/2003
Neben den offenen Netzwerkprotokollen werden im Folgenden auch heute noch z.T.
verwendete proprietäre Protokolle beschrieben. Betrachtet werden im Folgenden die
Netzwerkprotokolle/-dienste:

NetBIOS

WINS
Seite 223

DNS

DHCP
1.1.1
NetBIOS/NetBEUI
Entwickelt wurde NetBIOS 1983 bei der Firma Sytec, Inc. Der Auftrag hierzu wurde von
IBM für das IBM PC Netzwerk zur Vernetzung kleiner Arbeitsgruppen erteilt.
NetBIOS ist eine Schnittstelle zur Kommunikation zwischen Anwendungen in Windows
basierten Netzwerken. Das Netzwerkprotokoll NetBEUI dient NetBIOS standardmäßig
als Transportprotokoll. Um NetBIOS über TCP verwenden zu können, wurde mit den
RFCs 1001 und 1002 der Standard NetBIOS over TCP/IP (NBT) definiert.
NetBIOS/NetBEUI ist aufgrund seiner Zielsetzung für kleine Netzwerke ohne Router
ausgelegt. Das Protokoll kann auf Grund seiner Architektur nicht über Router hinaus
verbreitet werden. Zur Kommunikation nutzt das Protokoll hauptsächlich ungerichtete
Datenpakete, sogenannte Broadcasts. Dies kann zu einem hohen Datenverkehr innerhalb eines Netzwerkes führen. Durch die starke Verbreitung und Nutzung des Internets
und des dem Internet zugrunde liegenden Protokolls TCP/IP hat NetBIOS heutzutage
seine Bedeutung verloren. Viele Anbieter haben die Entwicklung für dieses Protokoll
eingestellt und bilden die Funktionen des Protokolls nunmehr über TCP/IP ab. Seit Windows 2000 setzt auch Microsoft in seinen Betriebssystemen auf TCP/IP anstatt auf NetBIOS/NetBEUI, daher wird hier nicht detaillierter auf dieses Protokoll eingegangen.
1.1.2
Windows Internet Name Service (WINS)
WINS wurde von Microsoft entwickelt, um eine Namenauflösung für NetBIOS über
TCP/IP in Microsoft Netzwerken abzubilden.
Microsoft definiert WINS wie folgt189:
WINS (Windows Internet Name Service) ist die Windows-Implementierung eines
NetBIOS-Namenservers (NBNS), der eine verteilte Datenbank für das Registrieren und Abfragen dynamischer Zuordnungen von NetBIOS-Namen zu den im
Netzwerk verwendeten IPv4-Adressen bereitstellt. WINS bietet eine NetBIOSNamensauflösung in gerouteten TCP/IP-Netzwerken mit mehreren Subnetzen.
Bevor zwei Hosts, die NetBIOS über TCP/IP (NetBT) verwenden, miteinander
kommunizieren können, muss der Ziel-NetBIOS-Name in eine IPv4-Adresse aufgelöst werden. TCP/IP kann keine Kommunikation mithilfe eines NetBIOSComputernamens herstellen.
Es besteht die Möglichkeit, einen WINS-Proxy einzusetzen. Ein WINS-Proxy hält selbst
keine Datenbank. Er nimmt lediglich Anfragen von Clients entgegen und leitet diese an
einen vollwertigen WINS Server weiter.
Sämtliche bisher erschienenen Windows Betriebssysteme (Windows 9x bis Windows XP
und sämtliche Serverbetriebssysteme) können einen WINS Client darstellen. Der WINS
Client kann anhand seines sogenannten Knotentyps dahin gehend konfiguriert werden,
ob und wie er NetBIOS-Namen auflösen soll.
189
http://www.microsoft.com/germany/technet/datenbank/articles/600987.mspx
Seite 224
Microsoft empfiehlt beim Aufbau von neuen Netzwerken, den WINS Dienst anzubieten,
da nicht auszuschließen ist, dass vorhandene alte (zum Beispiel 16 Bit Anwendungen)
Applikationen diesen Dienst noch nutzen. Dies sollte aber in jedem Fall im Vorfeld geprüft werden. Diese Prüfung ist jedoch häufig nicht problemlos möglich, da es keine
Standardmethode zur Ermittlung aller Anwendungen gibt, die WINS benötigen. Bei einer
zukünftigen Planung zum Einsatz von Applikationen innerhalb eines Netzwerkes sollte
daher der Einsatz von Applikationen vermieden werden, die den WINS Dienst nutzen.
1.1.3
Domain Name System (DNS)
DNS ist der Internetstandard, der es unter anderem ermöglicht, innerhalb eines hierarchischen Namensraums Rechnernamen in eine IP Adresse und umgekehrt (Reverse
Lookup) aufzulösen.
Paul Mockapetris entwarf 1983 den DNS Dienst und beschrieb ihn in den RFCs 882 und
883. Diese RFCs wurden inzwischen von RFC 1034 und RFC 1035 abgelöst und durch
zahlreiche weitere Standards ergänzt.
DNS kann auf den Microsoft Server Betriebssystemen installiert werden. In folgenden
RFCs ist der DNS Dienst beschrieben, wie er von Microsoft für Windows Serverbetriebssysteme implementiert wird190:
RFC
Titel
1034
Domain Names – Concepts and Facilities
1035
Domain Names – Implementation and Specification
1123
Requirements for Internet Hosts – Application and Support
1886
DNS Extensions to Support IP Version 6
1995
Incremental Zone Transfer in DNS
1996
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
2136
Dynamic Updates in the Domain Name System (DNS UPDATE)
2181
Clarifications to the DNS Specification
2308
Negative Caching of DNS Queries (DNS NCACHE)
2535
Domain Name System Security Extensions (DNSSEC)
2671
Extension Mechanisms for DNS (EDNS0)
2782
A DNS RR for Specifying the Location of Services (DNS SRV)
Tabelle 40: RFCs in denen DNS spezifiziert wird
Die Nutzung des DNS Dienst innerhalb einer abgegrenzten Netzwerkinfrastruktur setzt
den Aufbau beziehungsweise die Nutzung eines entsprechenden Servers voraus. Um
die Kommunikation zu Rechnern in anderen Netzwerken aufzubauen, können externe
190
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/
ServerHelp/60601f25-a8b3-4316-851f-8e0cc99673ec.mspx?mfr=true
Seite 225
DNS Server von den entsprechenden Providern genutzt werden. DNS Server treten in
der Regel paarweise (Primary und Secondary DNS Server) auf. Dies dient zum einen
der Verbesserung der Ausfallsicherheit des Dienstes und ermöglicht zum anderen, DNS
Einträge im laufenden Betrieb zu pflegen.
Wie bereits erwähnt, ermöglicht DNS die Auflösung eines Rechnernamens in eine IP
Adresse und umgekehrt in einen hierarchischen Namensraum. Die Hierarchie des Namensraums macht sich in der Notation der Namen durch das Trennzeichen „.― (Punkt
beziehungsweise dot) bemerkbar. Der sogenannte „vollqualifizierte― Name (Fully Qualified Domain Name, FQDN) besteht aus zwei Teilen: der erste Teil (bis zum ersten
Punkt) kennzeichnet den Hostnamen, der zweite Teil die DNS Domäne. Beispiel: computer1.organisation1.com beschreibt den Rechner namens computer1 in der DNS Domäne organisation1.com. Es ist nicht zwingend notwendig, dass der FQDN aus drei Teilen bestehen muss. Zwei Teile sind allerdings mindestens aufzuführen. Der in diesem
Beispiel aufgeführte Teil nach dem letzten Punkt beschreibt üblicher Weise den übergeordneten Bereich oder das Land in dem der Rechner beziehungsweise die Domäne
angesiedelt ist. Als zulässige Zeichen in FQDN sind die Zeichen a bis z, A bis Z und das
Minuszeichen definiert, wobei nicht zwischen Groß- und Kleinschreibung unterschieden
wird.191
Da DNS ein Internetstandard ist, ist eine freie Wahl des Domänennamens nicht möglich.
Die Domänen müssen bei den aktuellen nationalen oder internationalen Verwaltungseinrichtungen registriert werden. Ist der DNS Namensraum allerdings nur innerhalb der eigenen Organisation (Unternehmen) sichtbar, können auch nicht registrierte Namen zum
Einsatz kommen. Hiervon ist allerdings abzuraten. Es sollte immer darauf geachtet werden, dass ein Namensraum verwendet wird, der zum Internet kompatibel bleibt. Hierzu
empfiehlt es sich, einen gewünschten Namensraum (Domäne) frühzeitig reservieren zu
lassen. Dies verhindert spätere Umstellungen und vermeidet Aufwendungen für Migrationen.
DNS verfügt über Mechanismen, die es ermöglichen, die zugrunde liegende Datenbasis
zu partitionieren, also auf verteilte Umgebungen anzupassen. Zum einen kann die Namensauflösung für spezielle Domänen delegiert werden, zum anderen können über die
Erstellung von Zonen die Replikation (Zonentransfer) und die Verwaltung gesteuert werden.
Eine Besonderheit der DNS Implementierung unter Windows ab NT 4 ist die Möglichkeit,
den DNS Dienst zu veranlassen, zusätzlich einen WINS Server zur Namensauflösung
heranzuziehen.
DNS unterstützt neben den Einträgen für Rechnernamen noch weitere Eintragstypen
(resource records). Die folgende Tabelle zeigt eine Übersicht der in Windows unterstützten DNS Resource Record Typen.
191
In einigen Domänen, wie .de .at .ch sind auch erweiterte Zeichensätze mit definierten Sonderzeichen zum Beispiel Umlauten oder ß nutzbar.
Seite 226
Record Typ
Kurzbeschreibung
A
Adresseintrag (klassischer Eintrag für einen Host, der in eine IP Adresse aufgelöst werden soll)
CNAME
Alias (oder canonical name)
MX
Eintrag für das Mailrouting via SMTP (Simple Message Transfer Protocol)
NS
Eintrag für einen DNS Server (name server) einer DNS Domäne.
PTR
Reversiver Adresseintrag (pointer resource record), der über eine IP Adresse auf
einen Hostname schließen lässt
RP
Eintrag für die verantwortliche Person einer speziellen DNS Domäne
SOA
Ein SOA-Satz (Start Of Authority) markiert den Beginn einer Zone. Der Name
(@, das Origin) steht für den Namen der Zone.
TXT
Eintrag für Textinformationen
WINS
Eintrag für die IP Adresse für WINS Server, die zusätzlich zur Vorwärtsauflösung
verwendet werden sollen
WINS_R
Eintrag den Reverse Lookup via WINS Server
SRV
Eintrag für well-known service
Tabelle 41: Übersicht der unterstützten DNS Resource Record Typen
Sämtliche bisher erschienenen Windows Betriebssysteme (Windows 9x bis Windows XP
und sämtliche Serverbetriebssysteme) können einen DNS Client darstellen. Systeme mit
Windows 2000 oder höher unterstützen als Client auch dynamische DNS (DDNS).
Der DNS Dienst unter Windows 2003 ist laut den Angaben von Microsoft 192 interoperabel
mit den nachfolgend aufgeführten Versionen von BIND (Berkeley Internet Name Domain)193, der Open Source Implementierung eines DNS Dienstes, die für viele Betriebssysteme, wie zum Beispiel UNIX, FreeBSD, OpenBSD, Linux und Windows zur Verfügung steht:

BIND 4.9.7

BIND 8.1.2

BIND 8.2

BIND 9.1.0
Die Anbindung von BIND 9 an fremde Datenquellen für die Verwaltung der Zoneninformationen ist einerseits über ein umfangreiches BackEnd Database Interface möglich,
andererseits gibt es ein zusätzliches, vereinfachtes Interface, „Simple Database Ba-
192
193
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/
73c0ae36-8058-43d1-8809-046eb03b73fb.mspx?mfr=true
http://www.isc.org/index.pl?/sw/bind/
Seite 227
ckend― (SDB), mit dem beispielsweise ein nur-lesender Zugriff auf LDAP oder SQL Datenbanken realisiert werden kann. Die Anbindungen selbst sind jedoch nicht Bestandteil
des BIND Softwarepakets. So existieren beispielsweise für die LDAP-Anbindung sowohl
SDB Implementierungen als auch vordefinierte Objektklassen, mit denen eine solche
Anbindung realisiert werden kann.
Insbesondere unterstützt BIND 9 auch die dynamische Aktualisierung von ServiceRecords und kann damit entsprechende Dienste für Windows Server leisten
BIND stellt damit eine Alternative zu dem in Windows implementierten DNS dar. Aufgrund seiner großen Verbreitung ist nicht zu erwarten, dass es beim Einsatz in heterogenen Umgebungen funktionale Schwierigkeiten gibt.
1.1.4
Dynamic Host Configuration Protocol (DHCP)
DHCP wurde von der Dynamic Host Configuration Working Group of the Internet Engineering Task Force entwickelt und ist im RFC 2131 definiert.
DHCP wird dazu verwendet, Computern innerhalb eines Netzwerkes automatisch, dynamisch und temporär oder statisch und permanent eine IP Adresse zuzuweisen. Dies
geschieht, indem der Computer während der Startphase über einen DHCP Client eine
entsprechende Anfrage an den DHCP Server stellt, welcher aus einem Pool von IP Adressen eine IP Adresse für die Dauer einer festgelegten Laufzeit zur Verfügung stellt.
Zwar bietet ein DHCP-Server unter Windows Server 2003 alle Optionen aus der nachfolgenden Optionsliste (siehe Tabelle 42) an, jedoch fordern DHCP-Clients unter Windows XP und Windows Server 2003 während des DHCP-Konfigurationsvorgangs nur die
in der Spalte „Unter Windows genutzt― gekennzeichneten Optionen an.
Nr.
Optionsname
0
Pad
255
End
1
Subnet mask
2
Time offset
3
Router
4
Time server
5
Name servers
6
DNS servers
7
Log servers
8
Cookie servers
9
LPR servers
Erklärung
von Windows
genutzt
Gibt die mit der geleasten IP-Adresse verknüpften Subnetzmaske an. Die Subnetzmaske wird 
in einem Bereich konfiguriert und muss nicht
separat als Option konfiguriert werden.
Gibt die IP-Adresse des Standardgateways
eines Hosts an.

Gibt die IP-Adressen von DNS-Servern an.

Seite 228
Nr.
Optionsname
10
Impress servers
11
Resource Location
servers
12
Host name
13
Boot file size
14
Merit dump file
15
Domain name
Erklärung
Gibt den verbindungsspezifischen DNSDomänensuffix an, der vom DHCP-Client verwendet werden soll.


16
Swap server
17
Root path
18
Extensions path
19
IP layer forwarding
20
Nonlocal source
routing
21
Policy filter masks
22
Max DG reassembly size
23
Default time-to-live
24
Path MTU aging
timeout
25
Path MTU plateau
table
26
MTU option
27
All subnets are
local
28
Broadcast address
29
Perform mask discovery
30
Mask supplier
31
Perform router dis- Gibt an, ob der DHCP-Client ICMP-Routercovery
suche (Internet Control Message Protocol) als
Host verwendet, wie in RFC 1256 definiert.
32
Router solicitation
address
33
Static route
von Windows
genutzt
Gibt einen Satz von IP-Netzwerkzielen mit
Klassen an, zusammen mit den ihnen entspre- 
chenden IP-Adressen, die DHCP-Clients in ihre
IP-Routingtabellen aufnehmen.
Seite 229
Nr.
Optionsname
Erklärung
von Windows
genutzt
34
Trailer encapsulation
35
ARP cache timeout
36
Ethernet encapsulation
37
Default time-to-live
38
Keepalive interval
39
Keepalive garbage
40
NIS domain name
41
NIS servers
42
NTP servers
43
Vendor-specific
information
Gibt an, ob herstellerspezifische Optionen angefordert werden.

44
WINS/ NBNS servers
Gibt die IP-Adressen von WINS-Servern an.

45
NetBIOS over TCP/
IP NBDD
46
WINS/ NBT node
type
47
NetBIOS scope ID Gibt die NetBIOS-Bereichskennung an. NetBTHosts (NetBIOS über TCP/IP) kommunizieren 
nur mit den NetBT-Hosts, die die gleiche Bereichskennung verwenden.
48
X Window system
font
49
X Window system
display
51
Lease time
58
Renewal (T1) time Erneuerungsintervall 1
value
59
Rebinding (T2) time Erneuerungsintervall
value
64
NIS + Domain Name
65
NIS + Servers
66
Boot Server Host
Name
67
Bootfile Name
Gibt den von dem Client verwendeten Typ der
Namensauflösung bei NetBIOS (Network Basic 
Input/Output System) über TCP/IP an.
Gültigkeitsdauer der Vergabe
Seite 230
Nr.
Optionsname
68
Mobile IP Home
Agents
249
Statische Routen
ohne Klassen
Erklärung
von Windows
genutzt
Gibt einen Satz von Routen ohne Klassen an,
die der DHCP-Client in seine IP-Routingtabelle 
aufnimmt.
Tabelle 42: Übersicht der DHCP Optionen
Wie auch die anderen Netzwerkdienste ist der DHCP Dienst unter Microsoft kompatibel
zu den Standardimplementierungen unter UNIX und kann daher in heterogenen Umgebungen eingesetzt werden.
Die Funktion, dass sich Netzwerkclients automatisch konfigurieren, ist in TCP/IPv6 in die
Definition des TCP/IP Protokolls eingeflossen. Daher gibt es unter TCP/IPv6 kein DHCP
mehr.
In Netzwerken, in denen die Adressierung bereits nach der neuen Version 6 des Internetprotokolls (IPv6) stattfindet, verwendet der Microsoft Server parallele IP Stacks für
IPv4 und IPv6 (Dualstack-Strategie). Für Windows Clients wird diese Option zum Zeitpunkt der Erstellung des Leitfadens nicht angeboten. Damit besteht die Möglichkeit, dass
sowohl Rechner mit IPv6 als auch Rechner mit IPv4 mit dem Server kommunizieren
können.
Über das Internet bieten die meisten Provider jedoch noch immer keinen nativen IPv6Verbindungen an. Somit besteht die grundsätzliche Schwierigkeit, zwei IPv6-Netze über
das Internet miteinander zu verbinden. Um diese Einschränkung zu umgehen, gibt es
weltweit sogenannte „tunnel broker", mit denen alle IPv6-Verbindungen durch eine IPv4Verbindung „getunnelt" werden können. In der Regel werden diese gratis zur Verfügung
gestellt.
Zusammenfassend ist festzustellen: Netzwerkprotokolle bilden die Grundlage zur Kommunikation von Geräten innerhalb eines Netzwerkes. In der Vergangenheit waren die
Implementierungen dieser Protokolle bei Microsoft in der Praxis teilweise nur eingeschränkt nutzbar (zum Beispiel Abstürze der TCP/IP Implementierung 1.0). Inzwischen
sind die Implementierungen aller Protokolle bei Microsoft für den Praxiseinsatz geeignet.
TCP/IP hat sich als Standard durchgesetzt. Gegebenenfalls müssen aus historischen
Gründen bei Microsoftumgebungen aber auch Protokolle eingesetzt werden, die nicht
aus der TCP/IP Welt stammen, in diese jedoch eingebunden werden können (zum Beispiel WINS).
1.2
WINS, DNS und DHCP unter Linux mit Samba
Die Auswirkungen der Netzwerkdienste für die Clients unterscheiden sich nicht zwischen einem Windows Netzwerk und einem OSS Netzwerk. Daher werden nachfolgend nur die Unterschiede in Bezug auf die in Kapitel 4.2.1.1 beschriebenen Dienste
aufgeführt. Im Wesentlichen handelt es sich hierbei um architektonische Unterschiede.
Seite 231
Auf die Herkunft der Protokolle wird jeweils kurz im entsprechenden Abschnitt verwiesen, sofern diese von den bereits beschriebenen abweicht.
1.2.1
Windows Internet Name Service (WINS)
Die Namensauflösung für Windows-Dienste und -Rechner wird nach einer OSSMigration durch den Samba-Dämon nmbd übernommen. Dabei können einerseits die bei
Windows üblichen broadcastbasierten Browserdienste sowohl als Client als auch als
lokaler oder domänenweiter Master Browser geleistet werden. Andererseits kann der
nmbd aber auch als WINS Server die Koordinierung der Browser über die Grenzen von
Netzsegmenten hinweg leisten, die üblicherweise mit Routern, die keine Broadcasts
durchlassen, verbunden sind.
SAMBA kann auch in der Form konfiguriert werden, dass der SAMBA Server auf einen
bestehenden WINS Server zugreift und die dort bereitgestellten Namen dann im Netzwerk verteilt. In diesem Fall kann SAMBA aber nicht als secondary WINS Server neben
einem Microsoft WINS Server oder einem zweiten SAMBA Server verwendet werden.
1.2.2
DNS (Domain Name Service)
Die Referenzimplementierung für einen Domain Name Service ist BIND (Berkeley Internet Name Domain), die vom Internet Software Consortium (ISC) herstellerunabhängig
weiterentwickelt und gepflegt wird. Die aktuellste Version ist Bind 9.4.1-P1, die u.a. dynamisches DNS (DDNS), DNSSEC und IPv6 unterstützt. BIND ist ein Open Source
Softwarepaket, welches unter BSD-Lizenz steht und für zahlreiche Betriebssysteme wie
UNIX, NetBSD, FreeBSD, OpenBSD, Linux, Mac OS X und Windows NT/2000/2003 zur
Verfügung steht. In vielen Linux-Distributionen wird BIND standardmäßig mitgeliefert.
1.2.3
Dynamic Host Configuration Protocol (DHCP)
Die Referenzimplementierung des DHCP wird ebenfalls vom ISC weiterentwickelt und
gepflegt. Das Protokoll und die Software haben folgende Aufgaben beziehungsweise
Möglichkeiten:

Automatische Zuweisung von IP-Adresse nach IPv4 und Rechnernamen an
Clients. DHCP erlaubt sowohl die Zuweisung fester IP-Adressen (anhand der
MAC Adresse) als auch die dynamische Zuweisung einer freien Adresse aus einem festgelegten Adressbereich.

Automatische Übermittlung von Informationen über die Netzwerkinfrastruktur.
Zum Beispiel können über DHCP der Domänenname und der Nameserver, die
Default-Route und die Netzmaske zentral verwaltet an alle Clients verteilt werden.

Darüber hinaus lassen sich eine große Zahl fest definierter optionaler Felder sowie frei definierbare Informationen zur Host-Konfiguration durch den dhcpd ausliefern. Dies beinhaltet auch sämtliche vom Windows-Clients verwertbaren Optionen, die im vorherigen Kapitel aufgeführt sind.

Zusätzlich kann der dhcpd auch die Rolle eines bootpd übernehmen und so einem Client alle für das Booten über Netz erforderlichen Informationen übermitteln.
Seite 232
Der ISC dhcpd ermöglicht bezüglich aller auszuliefernden Informationen sowohl die
Verwaltung von individuellen Clients als auch die zusammenfassende Konfiguration für
Klassen und Subnetze. In der Konfiguration des ISC dhcpd ist außerdem die bedingte
Zuweisung von Host-Konfigurationsdaten durch IF-Anweisungen möglich.
Der dhcpd kann in einer Failover-Konfiguration betrieben werden, um Hochverfügbarkeit
zu realisieren. Die dynamisch verwalteten IP-Bereiche werden dann zwischen den sich
gegenseitig ersetzenden Servern koordiniert. Diese Konfiguration kann auch für LoadBalancing genutzt werden.
Die Konfiguration des ISC dhcpd geschieht im traditionellen UNIX-Stil durch eine ASCII
Konfigurationsdatei. Es existiert ein Patch, mit dem die Konfiguration des ISC-DHCPServers dynamisch aus einem LDAP-Repository bezogen werden kann. Die Implementierung folgt dem IETF Draft zum LDAP Schema für DHCP.
IPv6 wird fast in allen Linux-Distributionen unterstützt. Hier, wie in vielen anderen Hardund Softwarekomponenten, ist ein IP-Dual-Stack implementiert. Die parallele Unterstützung von IPv6 und IPv4 wird in der Regel automatisch mit jeder Standard-Installation
bereitgestellt. Je nach Distribution ist die IPv6-Unterstützung direkt aktiviert oder sie
kann optional aktiviert werden. Mit dem implementierten Dual-Stack kann ein Rechner
sowohl mit einen IPv6- als mit einem IPv4-Rechner kommunizieren. Innerhalb von homogenen IPv6- oder IPv4-Netzen ist die Kommunikation zwischen den Rechnern prinzipiell kein Problem. Will man aber zwei IPv6-Netze über ein IPv4-Netz miteinander verbinden, so erfordert dies in der Regel eine Tunnelung der IPv6-Kommunikation über
IPv4. Dies ist immer dann von Interesse, wenn das Internet als Verbindungsglied genutzt
wird. Hier ist eine native IPv6-Unterstützung eher schwach ausgeprägt. Es gibt aber sogenannte „tunnel broker―, welche die Möglichkeit bieten, in der Regel kostenneutral,
IPv6-Kommunikation über IPv4 zu tunneln.
Damit kann zusammenfassend angemerkt werden, dass die Open Source Implementierungen uneingeschränkt geeignet sind, um Netzwerke aufzubauen und zu betreiben. Sie
haben durch ihre Zuverlässigkeit den Weg für alle anderen Implementierungen gewiesen, wie ihr langjähriger, erfolgreicher Einsatz im Rahmen des Internets belegt.
Aus historischen und architektonischen Gründen waren in vielen der hier beschriebenen
Protokolle kaum Sicherheitsmechanismen vorgesehen. Einzelne Protokolle eröffneten
daher in der Vergangenheit immer Angriffsmöglichkeiten, die jedoch durch Erweiterungen der Protokolle beziehungsweise durch andere Protokolle stets schnell geschlossen
werden konnten.
Seite 233
2
Migrationspfade
Auch wenn im lokalen Netz die Anforderungen bezüglich Interoperabilität aufgrund der
begrenzten Anzahl beteiligter Systeme überschaubar bleiben, ist die Bewahrung der
offenen Standards von essenzieller Bedeutung. Insbesondere bei herstellerspezifischen
Änderungen beziehungsweise Erweiterungen von Standards ist regelmäßig die Gefahr
eines „Vendor Lock-In― gegeben. Das heißt, einerseits wird die Bindung an diesen Hersteller bis hin zur Abhängigkeit gefestigt, andererseits geht die Definitionsmacht bezüglich
der Fortentwicklung und der Interoperabilität von Fremdsystemen, jedenfalls im Wirkungsbereich der Erweiterung, auf den Hersteller über.
Vor diesem Hintergrund sollte in jedem Fall geprüft werden, ob die mit einer herstellerspezifischen Erweiterung eines Standards versprochenen Verbesserungen auch eine
langfristige Perspektive ermöglichen. Die Verwendung der seit langer Zeit existierenden
und bewährten Referenzimplementationen kann möglicherweise nicht mit jedem Feature
aufwarten. Sie bieten aber die Gewähr für eine dauerhafte Interoperabilität mit allen
netzwerkfähigen Systemen.
Eine Migration von einzelnen Netzwerkdiensten, losgelöst von anderen Migrationen wie
zum Beispiel der Dateiablage und des Authentisierungdienstes, von einer Windows
Landschaft zu einer Unix Landschaft oder umgekehrt ist in der Regel nicht sinnvoll. Gegebenenfalls kann es auf Grund bestimmter Rahmenbedingungen (zum Beispiel Infrastrukturanforderungen / technische Vorgaben) Ausnahmen geben. Typische Beispiele
hierfür sind der DNS und der DHCP Dienst.
Aber auch andere Abhängigkeiten müssen berücksichtigt werden. Zum Beispiel benötigt
Exchange 2003 zwingend einen WINS Dienst. Das heißt, wenn die Netzwerkdienste
migriert werden und Exchange 2003 eingesetzt wird, muss zwingend ein SAMBA Server
aufgebaut werden, um den WINS Dienst anzubieten.
Die Migration von Netzwerkdiensten kann normalerweise als sanfte Migration durchgeführt werden. Hierbei wird die eine Infrastruktur aufgebaut, beide Infrastrukturen werden
für einen gewissen Zeitraum parallel betrieben und anschließend wird die „alte― Infrastruktur abgeschaltet. Dabei ist wichtig zu prüfen, ob die an der Netzwerkkommunikation
beteiligten Geräte wie Switche, Router und so weiter gegebenenfalls umkonfiguriert werden müssen.
Eine Migration von Netzwerkdiensten ist aus heutiger Sicht technisch als unkritisch einzustufen. Die Netzwerkdienste sowohl in einer OSS Umgebung als auch in aktuellen
Windowsumgebungen sind ausgereift und weltweit im Einsatz. Meistens werden die
Netzwerkdienste nur dann geändert, wenn ein Wandel in der IT- Architektur durchgeführt
wird. Alle hier aufgeführten Netzwerkdienste können auf allen gängigen Netzwerkinfrastrukturkomponenten betrieben und in einem Netzwerk angeboten werden. Da bei der
Migration die funktionalen Unterschiede von besonderer Bedeutung sind, wird auf diese
im Rahmen der Migrationspfade eingegangen.
2.1
Migration Netzdienste Windows NT/2000 nach Windows 2003
In den folgenden Absätzen werden kurz die Neuerungen hinsichtlich der oben genannten Netzwerkdienste beschrieben, die mit der Einführung von Windows 2000 einhergehen.
Seite 234
Eine Migration innerhalb einer Windowsinfrastruktur ist, bezogen auf die Netzwerkdienste, inzwischen problemlos durchzuführen. In der Regel wird dies durch ein Update von
vorhandener Software (zum Beispiel durch Service Packs und Patches) oder durch die
Neuinstallation von entsprechenden Servern erreicht. Bei der Nutzung von Service
Packs oder Patches besteht jedoch die Gefahr, dass gegebenenfalls Softwareversionen
der Netzwerkdienste eingespielt werden, die evtl. nicht zu allen genutzten Applikationen
kompatibel sind. Dies ist insbesondere dann der Fall, wenn umfassende Service Packs
eingespielt werden, die nicht ausschließlich zum Update der Netzwerkdienste vorgesehen sind. Daher sollten diese (genauso wie Neuinstallationen) auch auf Ihre Kompatibilität zu der IT-Infrastruktur und den genutzten Applikationen getestet werden.
2.1.1
WINS
Hinsichtlich WINS bietet Windows 2000/2003 keine architektonischen Neuerungen. In
Windows 2000/2003 ist lediglich das Management der WINS Datenbank verbessert worden.
2.1.2
DNS
Die größten Änderungen durch die Einführung von Windows 2000/2003 hat der DNS
Dienst erfahren. Der Hauptgrund hierfür ist, dass Windows 2000/2003 Active Directory
als primäre Namensauflösung DNS benutzt beziehungsweise ohne DNS nicht funktioniert. Active Directory verwendet DNS u.a. zur Auffindung der Dienste hinsichtlich Anmeldung und Suche (LDAP Service, Global Catalog Service und Kerberos KDC). Für die
Eintragung von Diensten muss das DNS sogenannte SRV Records gem. RFC 2052 unterstützen. Da das bisherige DNS statisch funktionierte (Einträge mussten manuell vorgenommen werden), ist in Windows 2000/2003 auch im Hinblick auf den angestrebten
Wegfall von WINS eine dynamische Registrierung implementiert worden: Rechner können ihre A und SRV Records dynamisch eintragen. Die Implementierung folgt dabei dem
RFC 2136 (Dynamic Update). Computer mit Windows 2000 und höher können sich
selbst dynamisch registrieren (Realisierung im DHCP Client). Windows NT und Windows
9x können das nicht. Sie benötigen die Hilfe eines Windows 2000 DHCP Dienstes. Das
dynamische Registrieren impliziert eine architektonische Änderung der bisherigen DNS
Implementierung, in der nur ein DNS Server (der primäre) die Zoneninhalte schreiben
kann. Microsoft realisiert ein Multi-Master-Prinzip, indem es DNS ins Active Directory
integriert. Die DNS Einträge sind somit Objekte der Datenbank des Active Directory und
werden auf diese Weise repliziert. Eine dynamische Registrierung ohne Active Directory
Integration existiert nicht. Die dynamische Registrierung kann durch Sicherheitsmechanismen reglementiert werden, sodass sich nur jene Computer registrieren können, die
sich auch authentifizieren können (zum Beispiel Windows 2000 Clients der zugehörigen
Domäne). Windows 2000/2003 unterstützt das sogenannte „Secure Update― gemäß
GSS-API laut RFC 2078; die RFCs 2535 (Domain Name System Security Extensions)
oder 2137 (Secure Domain Name System Dynamic Update) sind nicht realisiert.
Seite 235
2.1.3
DHCP
Hinsichtlich DHCP bietet Windows 2000/2003 einige nennenswerte Neuerungen. Unter
Windows 2000/2003 werden die aktuellen RFCs 2131 (Dynamic Host Configuration Protocol, ehemals RFC 1541) und 2132 (DHCP Options and BOOTP Vendor Extensions)
unterstützt. Neben dem verbesserten Management werden Multicast Scopes, benutzerund herstellerspezifische DHCP Optionen sowie dynamisches BOOTP unterstützt.
Eine weitere Neuerung ist die Integration von DHCP und DNS innerhalb eines Windows
2000/2003 Netzwerkes. Clients mit Windows NT 4 oder älter unterstützen keine dynamische Registrierung ihrer DNS-Namen im Windows 2000/2003 dynamischen DNS. Sofern
diese Clients ihre IP Konfiguration von einem Windows 2000/2003 DHCP Server beziehen, kann der DHCP Server die Registrierung im DNS übernehmen.
2.2
Migration von Windows DNS (BIND 8) nach Linux BIND 9
Eine Migration des Windows DNS zu Linux mit BIND 9 ist sowohl bei einer Ausgangssituation von DNS unter Windows NT als auch unter Windows 2000/2003 problemlos
durchzuführen.
In beiden Fällen ist die prinzipielle Vorgehensweise identisch; es ändert sich nur das
Verfahren, um den neuen DNS Server mit Daten zu füllen und die BIND 9 Datenbank
aufzubauen. Dieses prinzipielle Vorgehen sieht wie folgt aus:

Aufbau / Konfiguration eines neuen Servers.

Konfiguration (Anpassung von IP Adressen der DNS Server) von DHCP Servern
(evtl. Clients bei festen IP Adressen). Eine Übernahme der Konfiguration des
Servers ist in keinem Fall möglich, da hier deutliche syntaktische Unterschiede
vorliegen.

Übernahme der Daten (Zoneneinträge) vom bestehenden Server auf den neuen
Server.

Inbetriebnahme des neuen Servers inklusive DNS Dienst und Abschaltung des
alten DNS Servers: Alle Windows Endgeräte können BIND 9 zur Namensauflösung nutzen. Daher ist der Einsatz eines Linux Servers (oder auch eines anderen
Unix Servers) mit BIND 9 als DNS Server aus Sicht eines Windows Endgerätes
unkritisch.
Bei der Übernahme der Zoneneinträge von einem Server auf den anderen können je
nach Ausgangssituation unterschiedliche Vorgehensweisen gewählt werden:

DNS unter Windows NT 4.0
Da in diesem Fall kein dynamisches DNS unterstützt wird 194, besteht nur die
Möglichkeiten, entweder einen Zonentransfer durchführen oder die Zoneneinträge manuell zu übertragen. Im zweiten Fall ist zu beachten, dass die
syntaktischen Vorgaben der neuen Umgebung einzuhalten sind. Bei der
Verwendung eines Zonentransfers sollten die syntaktischen Unterschiede, trotz
194
http://support.microsoft.com/kb/251370/de?spid=1131&sid=936
Seite 236
der Tatsache, dass BIND 9 bezüglich syntaktischer und logischer Fehler nicht so
„fehlertolerant― wie seine Vorgänger ist195, zu keinen Problemen führen, da BIND
9 hierbei auf Basis der Zoneneinträge auf dem Windows DNS-Server selbst seine
Zoneneinträge anlegt und dabei in der Regel die korrekte Syntax verwendet.

DNS unter Windows 2000/2003
Bei dieser Ausgangssituation besteht neben den zuvor genannten Vorgehensweisen noch die Möglichkeit, die Funktion des dynamischen DNS zu nutzen, die
auch von BIND 9 unterstützt wird. Dabei wird der neue BIND 9 DNS-Server im
Parallelbetrieb durch die Funktion des dynamischen DNS automatisch befüllt.
2.3
Migration von Windows DHCP nach Linux DHCP
Die Migration des DHCP Dienstes von Windows nach Linux kann ohne Unterbrechung
des Betriebs in der Organisationseinheit verwirklicht werden, da der Linux DHCP Server
parallel zum Windows DHCP Server aufgebaut werden kann. Eine parallele Nutzung von
beiden Servern während der Migration ist zwar möglich, wird aber nicht empfohlen. Sollte dies nötig sein, ist darauf zu achten, dass die IP Bereiche, in denen der alte DCHP
Server IP Adressen dynamisch vergibt, in dem neuen Server als reservierte Bereiche
voreingestellt werden. Nachdem der alte Server abgeschaltet wurde, können diese Bereiche freigegeben werden, sofern eine positive Prüfung erfolgte, dass der Client keine
IP Adresse aus diesem Bereich mehr in Anspruch nimmt. Diese Prüfung kann durch
entsprechende Tools oder mit Hilfe des ping Befehls im Vorfeld durchgeführt werden.
Bei einer Migration des DHCP Dienstes besteht prinzipiell immer die Gefahr, dass der
neue DHCP Server IP Adressen in einem Bereich vergibt, die vom alten DHCP Server
genutzt wurden. Hierdurch können doppelte IP Adressen im Netzwerk entstehen. Dieses
Risiko kann, wie beschrieben, durch die entsprechende Konfiguration des DHCP Servers vermieden werden. Darüber hinaus gibt es auch Tools, die eine solche Migration
unterstützen, indem sie zum Beispiel im Vorfeld einer IP Vergabe prüfen, ob die IP Adresse bereits im Netzwerk vorhanden ist.
Es ist aber darauf zu achten, dass verschiedene Einstellungen des Windows DHCP Servers vor der Inbetriebname des Linux DHCP Servers auf diesen übertragen werden.
Dies kann gegebenenfalls per Skript oder manuell erfolgen. Auf folgende Einstellungen
muss geachtet werden:
195

Fest vergebene und im DHCP als reserviert markierte IP Adressen (dies sind in
der Regel Drucker, Server, Netzwerkkomponenten usw.)

Gesperrte IP Bereiche (zum Beispiel für IP Segmente, die einer anderen Verwaltung unterliegen, aber Bestandteil der Infrastruktur einer Organisationseinheit
sind)

Dauer der max-lease-time

Dauer der deafult-lease time
http://www.oreillynet.com/pub/a/oreilly/networking/news/dnsandbind_0401.html
Seite 237
Insbesondere sollte die Dauer der Lease Time während der Migration einheitlich sein.
Lease Time ist die Dauer, in der der DHCP Client keine neue IP Adresse beim Server
anfragt. Je nach verwendeten Clients (Laptops oder Desktops) beträgt die Lease Time
üblicherweise 1 bis 5 Tage. Im Vorfeld einer Migration empfiehlt es sich, die Lease Time
der Clients auf 1 Stunde herabzusetzen. Dies sollte entsprechend der größten eingestellten max-lease-time geschehen. Das heißt, wenn diese zum Beispiel auf 5 Tage eingestellt wurde, sollte diese Umstellung mindestens 6 Tage vor der geplanten Migration der
DHCP Server durchgeführt werden. Dies sorgt dafür, dass Endgeräte, die beispielsweise
ständig angeschaltet (zum Beispiel Drucker) sind, nach dem Abschalten des alten DHCP
Servers innerhalb von maximal einer Stunde eine neue IP Adresse anfragen. Wird zum
Beispiel der alte Server am Abend abgeschaltet, kann davon ausgegangen werden,
dass alle Geräte, die über Nacht in Betrieb waren, am nächsten Morgen ihre IP Adresse
von dem neuen DHCP Server bezogen haben. Diese Umstellung kann dann wieder zurückgenommen werden, nachdem alle Clients vom neuen Server IP Adressen bezogen
haben.
2.4
WINS/NetBIOS(Windows) nach Samba mit WINS/NMDB
Die Namensauflösung für Windows-Dienste und -Rechner wird nach einer OSSMigration durch den nmbd vom Samba-Paket übernommen. Dabei können einerseits die
bei Windows üblichen broadcastbasierten Browserdienste sowohl als Client als auch als
lokaler oder domänenweiter Master Browser genutzt werden. Andererseits kann der
nmbd aber auch als WINS die Koordinierung der Browser über die Grenzen von Netzsegmenten hinweg leisten, die üblicherweise mit Routern, die keine Broadcasts durchlassen, verbunden sind. Der WINS Dienst wird bei einem SAMBA Server automatisch
installiert und konfiguriert und steht sofort nach der Inbetriebnahme des Samba Servers
zur Verfügung. Hierbei übernimmt ein SAMBA PDC die Rolle eines Master Browsers.
Spezielle Anpassungen oder Konfigurationen sind in der Regel nicht notwendig, können
aber individuell durchgeführt werden.
3
Bezüge
Für das Thema Netzwerkdienste sind bezüglich der Migration keine besonderen Bezüge
zu benennen. Bei der Migration eines Netzwerkdienstes sollte klar sein, welche anderen
Infrastrukturdienste und Anwendungen diesen benötigten und welche speziellen Funktionalitäten sie benötigen. Dies ist aber kein spezieller Punkt für die Bezüge sondern
sollte Bestandteil der Anforderungsanalyse eines jeden Migrationsprojektes sein. Siehe
hierzu auch Kapitel I.D 2.
Seite 238
E Thema Dateiablage
Für die physikalische Speicherung von Daten auf Plattensystemen von Servern werden
Dateisysteme wie XFS, EXT4, FAT oder NTFS benötigt. Über die physikalische Speicherung hinaus werden noch weitere Funktionen für eine Dateiablage benötigt. Hierzu gehören u.a. die Vergabe von Zugriffsberechtigungen auf Datei- und Verzeichnisebene, das
Verwalten von Quotas, Journaling-Funktionalitäten und gegebenenfalls Funktionen zur
Verschlüsselung von Dateisystemen.
1
Anmerkung: Die Bezeichnung „Windows Server― bezieht sich in diesem Kapitel stets auf
alle Versionen von Windows Servern ab Windows NT4.0 Server bis zur aktuellen
Version Windows Server 2003 R2. Wird von dieser Definition abgewichen, so wird die
genaue Versionsbezeichnung des Windows Servers aufgeführt.
1.1
Linux und Samba mit SMB/CIFS und POSIX
Erstmals im Jahre 1992 veröffentlicht, diente Samba dazu, einen Datenaustausch
zwischen SunOS und Ultrix zu gewährleisten. 1999 wurde Samba in der Version 2.0
veröffentlicht. Diese Version lief auch unter Linux und mit ihr wurden Benchmarktests
gegenüber Windows NT 4.0 Server durchgeführt. Die Erweiterung um das SMBProtokoll, das es, Windows Clients ermöglicht, auf die Daten zuzugreifen, wurde von
Microsoft, SCO, IBM und Apple implementiert.
Die aktuelle Versionsreihe von Samba ist die Versionsreihe 3. Diese wird zurzeit noch
weiterentwickelt. Gleichzeitig wird eine Samba Version 4 entwickelt. Samba 4.0 alpha 1
ist aktuell verfügbar, doch diese Version ist für den produktiven Einsatz noch nicht
freigegeben. Am 11. September 2007 wurde die zurzeit letzte Version von Samba mit
der Versionsnummer 3.0.26a veröffentlicht. Die Veränderungen zur Vorgängerversion
können unter http://de.samba.org/samba/ nachgeschlagen werden. Gemäß der unter
http://samba.sernet.de/196 veröffentlichten Erklärung des Samba-Teams werden alle
Versionen ab der Version 3.2 unter der GNU General Public License in der Version 3
veröffentlicht. Demnach sollte die aktuelle Version noch unter GPLv2 stehen.
Samba ist in mehrerer Hinsicht ein Nachbau des Windows Server Dienstes für Dateiablage, Druckdienste und Authentifizierung. Für die Anwender stellt sich Samba in größter
Näherung genau wie ein Windows Server dar. Für die Administratoren ist Samba andererseits ein UNIX-Server. W2K / Windows 2003 als Produktnachfolger von Windows NT
4.0 Server bringt für die Anwender kaum mehr Änderungen bezüglich des Windows Servers als ein Samba-Server. Für die Administratoren ergeben sich allerdings u.a. mit der
Einführung von Active Directory mit den Komponenten DNS, LDAP und Kerberos umfangreiche Änderungen.
Der Samba-Server erfüllt wie ein Windows Server die Anforderungen an eine Dateiablage. Die Benutzer von Windows-Clients können ihre Benutzerprofile und Logon-Scripts
196
Stand 01.11.2007
Seite 239
ebenso von einem Samba-Server beziehen wie ihre Heimat- oder Gruppenverzeichnisse. Die ausführbaren Programme (.exe) können auch auf einem Samba-Server abgelegt
(und von dort gestartet) werden, wie Access Datenbankdateien oder andere durch LockMechanismen für den Mehrbenutzerbetrieb vorgesehene Dateien.
Im Unterschied zu einem Windows Server verwendet Samba als Netzwerkprotokoll ausschließlich TCP / IP. Für die auf den Protokollen SPX / IPX (Novell) und Appletalk (Apple) basierenden Dienste existieren andere Open Source Server (Mars und Netatalk), die
in einer heterogenen Netzwerkumgebung das Arbeiten auf einem gemeinsamen Datenbestand ermöglichen. Eine auf dem alten NetBEUI basierende Implementierung von
SMB wird von Samba nicht angeboten. Auch NetBIOS über IPX wird nicht unterstützt.
Die clientseitig unter Windows üblichen Werkzeuge zur Bearbeitung / Verwaltung der
Dateien auf der Dateiablage stehen weiterhin zur Verfügung. Insbesondere können der
Explorer und der Datei Manager sowie die mit Windows mitgelieferten Kommandozeilenprogramme cacls.exe, zum Setzen der Access Control Lists und xcacls.exe für denselben Zweck unter Windows 2000/2003 Server und so weiter verwendet werden. Auch
der Benutzermanager kann mit Samba 3.0 weiter genutzt werden. Der Einsatz des Servermanagers ist im Prinzip möglich, eignet sich jedoch aufgrund der damit verbundenen
Abkehr von der transparenten Serverkonfiguration mittels der Konfigurationsdatei
smb.conf wenig.
Die Herstellung der Verbindungen zu den Freigaben lässt sich ohne Änderung weiterhin
durch Logon-Scripts automatisiert oder durch Browsen der Netzwerkumgebung interaktiv
durchführen.
Das Rechtesystem von Samba und Linux ermöglicht es, privilegierten Prozessen wie
zum Beispiel einem Virenscanner auf dem Server lokal Zugang zu allen Dateien in den
Heimatverzeichnissen der Benutzer zu gewähren und gleichzeitig den Zugriff über das
entsprechende Netzlaufwerk ausschließlich dem Benutzer selbst zu gestatten.
Auch in Umgebungen mit Windows Terminalservern lässt sich der Samba-Server zur
Dateiablage und zur Authentifizierung verwenden. Allerdings werden die für Terminalserver spezifischen Security-Account-Manager (SAM) - Objekterweiterungen von Samba
nicht unterstützt.
Die Behandlung von Dateisperren (Locking sowohl auf komplette Dateien als auch auf
Teilbereiche dieser) wird von Samba exakt wie vom Windows Server geleistet. Das
heißt, dass sowohl die kooperative Bearbeitung von Dateien als auch die Benutzung von
dateibasierenden Datenbanken mit Samba ebenso möglich ist wie mit einem Windows
Server.
Die Quotierung von Plattenplatz (sowie von anderen Systemressourcen) wird durch das
Linux-Betriebssystem angeboten und steht damit auch für die vom Samba-Server angebotene Dateiablage zur Verfügung.
Seite 240
Für Datensicherung und Versionierung / Archivierung stehen unter Linux verschiedene
Open Source Tools zur Verfügung. Zusätzlich lassen sich Linux-Server problemlos in die
Sicherungskonzepte der meisten marktüblichen Produkte einbinden197.
Eine Hochverfügbarkeit, wie sie unter Windows durch Clustering mit der Enterprise Edition erreicht wird, lässt sich mit Samba ebenfalls auf Basis von Distributed Block Devices
(DRBD), shared iSCSI oder Storage Area Network (SAN) mit IP Failover realisieren.
Die funktionalen Einschränkungen bezüglich der Vorgängerversionen von Samba 3.x
konnten inzwischen deutlich reduziert werden. Mit der Samba Version 3.0 ist es möglich,
zwischen Master- und Ressourcendomänen Vertrauensstellungen aufzubauen und das
Windows NT Domänenkonzept zu realisieren. Die Version 3.0 eröffnet auch die Möglichkeit, den Windows Benutzermanager zur Benutzer-Administration einzusetzen. Beispielsweise können so neue Benutzer angelegt werden.
Eine Möglichkeit zur Replikation zwischen Windows-Domänen-Controller und SambaDomänen-Controller besteht weiterhin nicht, innerhalb einer Domäne können somit nur
reine Windows beziehungsweise Samba-Domänen-Controller eingesetzt werden. Falls
die Integration von Windows-Serverdiensten in einer Samba-Domäne notwendig ist,
können diese als Mitgliedserver integriert werden. Die SAM-Replikation in einer reinen
Samba-Domänen-Controller Umgebung ist problemlos durch die Kombination von Samba und OpenLDAP möglich. Für die Funktionalität der SAM-Replikation ist die Kombination von Samba und OpenLDAP198 unverzichtbar. OpenLDAP dient Samba zur Verwaltung der Gruppen und Benutzern und bietet auch die notwendigen Replikationsmechanismen.
1.1.1
Zugriffssteuerung: Abbildung der Rechteprofile von Windows auf POSIX
Access Control Lists (ACL)
Die Regelung der Zugriffsrechte auf Verzeichnisse und Dateien durch einen SambaServer entspricht im Wesentlichen den von Windows Server bekannten Prinzipien. Auch
unter Samba werden einzelne Verzeichnisse aus dem Dateisystem des Servers als Shares im Netzwerk zur Verfügung gestellt. Die Details der Zugriffsregelung werden auf
Grundlage der im serverseitig verwendeten Dateisystem festgelegten Rechte für einen
jeweils individuell beim Samba-Server authentifizierten Benutzer ermittelt. Die Autorisierung ist also ein Zusammenspiel zwischen dem Samba-Server und dem Betriebsbeziehungsweise dem Dateisystem.
Shares (Freigaben) und ihre serverseitigen Eigenschaften wie Verzeichnispfad, Gewährung von anonymem Zugriff und allgemeiner Schreibschutz sind unter Samba typischerweise in einer für jede Serverinstanz eindeutigen Konfigurationsdatei geregelt und ausgewiesen. Die Bearbeitung dieser Konfigurationsdatei kann auch über ein Web-Fontend
durchgeführt werden. Es ist zu empfehlen, im Vorfeld eine entsprechende Authentifizierung / Autorisierung mit verschlüsseltem Protokoll HTTPS durchzuführen.
197
198
Im Vorfeld ist jedoch eine genaue Evaluierung der Produkte vorzunehmen, da es auch Produkte gibt die Probleme mit der Sicherung von ACLs aufweisen. Dieses Problem gilt zum
Beispiel beim Einsatz von NetBackup (Veritas) beim Sichern XFS ACLs. Ext3 ACLs werden
in diesem Produkt allerdings unterstützt.
Es können auch andere LDAP Verzeichnisdienste genutzt werden.
Seite 241
Zugriffsrechte auf Verzeichnisse und Dateien werden bei allen Betriebssystemen in der
funktionalen Betriebssystemkomponente des Dateisystems abgehandelt. Während es
beim FAT Dateisystem von DOS und älteren Windows-Versionen noch kein Eigentümerkonzept für Dateien gab, werden unter UNIX seit jeher und unter Windows mit dem Dateisystem NTFS Eigentümer und Benutzergruppen für Dateien unterschieden. Welche
Benutzer mit welchen Verzeichnissen und Dateien auf welche Art umgehen dürfen, wird
vom Dateisystem über eine Liste von Zugriffsrechten, sogenannte Access Control Lists
gesteuert.
Unter UNIX sind für alle Dateien mindestens die Zugriffsrechte zum Lesen, Schreiben
und Ausführen für den Eigentümer, eine Eigentümergruppe und alle übrigen Systembenutzer definiert. Zusätzliche Einschränkungen oder die Gewährung von Rechten für andere Benutzer oder Benutzergruppen können bei einigen UNIX / Linux Dateisystemen
über erweiterte Attribute und POSIX Access Control Lists realisiert werden.
Samba als Fileserver hält seine Daten in einem UNIX Dateisystem und greift mit den
effektiven Rechten des jeweils für einen Zugriff authentifizierten Benutzers auf die Daten
zu. Der Samba-Server kann theoretisch zusätzliche Beschränkungen für den Zugriff
auflegen, über die im Dateisystem festgelegten Beschränkungen kann sich der Server
aber in keinem Fall hinwegsetzen. Sowohl bei der Übermittlung der bestehenden
Zugriffs-rechte vom Server an den Client als auch bei der Manifestierung von clientseitig
initiierten Änderungen verwendet der Samba-Server den Rechtekanon des Dateisystems, in dem er die Benutzerdaten ablegt und verwaltet. Deshalb muss bei einer
Migration das Rechtemodell von Windows in die UNIX-Welt überführt werden. Im
Folgenden wird beschrieben, wie diese Abbildung vor sich geht und welche Besonderheiten und Einschränkungen dabei zu beachten sind. Die Autoren des Leitfadens gehen
dabei davon aus, dass unter Linux ein Dateisystem mit Unterstützung für POSIX-ACL
verwendet wird. Zurzeit sind das die Dateisysteme XFS, JFS sowie mit entsprechenden
Mount-Optionen reiserfs, EXT2 und EXT3.
1.1.2
Abbildung der NTFS-ACL in das Rechtesystem von Linux
Bei der Abbildung der Windows ACL auf die POSIX ACL von Linux wird das Rechtesystem so weit reduziert, dass das Bild im Wesentlichen der einfachen Darstellung in den
Sicherheitseinstellungen entspricht.
POSIX ACLs kennen nur Rechte zum Lesen, Schreiben und Ausführen. Verschiedene
Arten zu unterscheiden wie Daten schreiben, Daten anhängen, Attribute schreiben und
Erweiterte Attribute schreiben gibt es bei den POSIX ACL nicht. Bei der Abbildung des
Rechtesystems von Windows über Samba nach UNIX können deshalb immer nur
komplette Aggregationen der Windows Rechte im UNIX Dateisystem abgebildet werden.
Umgekehrt kann der Samba-Server auch nur solche Rechte-Aggregationen an den
Windows-Client melden.
Seite 242
Lesen
POSIX Berechtigungen
Schreiben
Ausführen
Ordner durchsuchen /
Datei ausführen
W
I
N
D
O
W
S
Ordner auflisten / Daten
lesen
X
Attribute lesen
X
Erweiterte Attribute lesen
X
(X)
Dateien erstellen / Daten
schreiben
X
Ordner erstellen / Daten
anhängen
X
Attribute schreiben
X
Erweiterte Attribute
schreiben
X
199
Unterordner/
Dateien löschen
Löschen
Berechtigungen lesen
X
X
X
Berechtigungen ändern
Besitz übernehmen
Tabelle 43: POSIX-Berechtigungen und Windows-Aggregationen
Auf der Anwenderseite können mit den Windows-Dialogen durch Kombination der
passenden NTFS-Berechtigungen die entsprechenden Kombinationen der POSIXBerechtigungen erzeugt werden. Dabei ist zu beachten, dass das Setzen einer
zusätzlichen NTFS-Berechtigung aus der Windows-Liste zum Setzen aller Berechtigungen des POSIX-Aggregats führt, zu dem auch das so gesetzte NTFS-Recht gehört.
Wenn also beispielsweise für eine Datei, auf die bisher nur lesender Zugriff möglich war,
in dem Dialog Berechtigungseintrag die Berechtigung Attribute schreiben gesetzt wird,
so erweitert der Samba-Server automatisch die Rechte für Erweiterte Attribute schreiben, Daten schreiben und Daten anhängen. Nachdem also der Dialog mit OK beendet
wurde, erscheint sofort beim nächsten Öffnen des Dialogfensters die neue, wesentlich
erweiterte Rechteausstattung. Das Vorteilhafte daran ist, dass dieses Verhalten des
Samba-Servers Fehlinterpretationen der einfachen Rechtedarstellung nicht zulässt.
In der vereinfachten Darstellung der Sicherheitseinstellungen ist das Bild konsistent. Hier
können die Berechtigungen Lesen und Schreiben einzeln und gemeinsam gesetzt
werden sowie jeweils in Kombination mit Lesen/Ausführen. Letztere Sammelberechtigung kann nicht alleine gesetzt werden.
199
Wird angezeigt, darf aber nicht gesetzt werden, sonst wird das gesamte Aggregat Lesen
aktiviert.
Seite 243
Die NTFS-Berechtigungen Unterordner/Dateien Löschen, Berechtigungen ändern und
Besitzrechte übernehmen sind unter POSIX ACLs nicht abbildbar und führen beim Setzen daher zu keinerlei Resultat auf dem Samba-Server (in der Tabelle 43 abgegraut
dargestellt). Bei Vollzugriff, also den kompletten Lese-, Schreib- und Ausführberechtigungen sind sie allerdings auch als gesetzt markiert.
Lesen
W
I
N
D
O
W
S
POSIX Berechtigungen
Schreiben Lesen und Lesen und
Ausführen Schreiben
Lesen,
Schreiben
und Ausführen
Vollzugriff
X
Ändern
X
Lesen/ Ausführen
X
X
Ordnerinhalt
auflisten
(nur für Ordner)
X
X
(nur für
Ordner)
(nur für
Ordner)
Lesen
X
X
Schreiben
X
X
X
Tabelle 44: POSIX- und Windowsberechtigungen
1.1.3
Abbildung der Vererbungsfunktion
Die POSIX-ACL Implementation verfügt lediglich über passive Vererbung. Eine aktive
Vererbung wie im NTFS ist nicht abbildbar. Samba bietet jedoch die Möglichkeit, auf
einzelnen Shares die Vererbung von ACLs zu aktivieren. Hierbei werden allerdings nur
die Default-ACLs vererbt, nicht die „normalen― Datei ACLs, wobei die Vererbung nur für
neu erstellte Dateien gilt. In der Praxis führt dies aber fast nie zu Problemen, da das
bestehende Rechtemodell mit einem Umstieg in der Regel evaluiert wird und diese
anschließend genauso regelmäßig zu einer Restrukturierung und gern gesehenen
Vereinfachung führen. Sollte trotzdem der Wunsch bestehen, das bestehende
Rechtemodell zu übernehmen, dann kann es durch die „eingeschränkte― Vererbung
vorkommen, dass entsprechende Attribute nach einer Migration von Hand durch den
Administrator ersetzt werden müssen.
1.1.4
Abbildung des Attributsystems
Die Attribute, die unter Unix nicht vorhanden sind, können auf verschiedene Weise
abgebildet werden. Dabei wird das Flag Schreibgeschützt nicht wirklich benötigt, weil es
im normalen Berechtigungssystem bereits enthalten ist. Es wird daher für Dateien und
Verzeichnisse ohne Schreibberechtigung automatisch angezeigt. Die Flags Archiv,
Versteckt und System können durch das nicht verwendete Execute Bit des Unix-Dateisystems abgebildet werden und sind daher vorhanden. Die Attribute Komprimiert und
Verschlüsselt sind nicht abbildbar. Sie können allerdings über spezielle Dienste unter
Unix zur Verfügung gestellt werden.
Seite 244
1.1.5
Abbildung der Überwachungsfunktionen
Das Auditing-System ist fest in Windows integriert. Es ist unter Unix mit anderen Mechanismen nachbildbar. Für den Samba-Server lässt sich das Auditing über ein VFS-Modul
realisieren. Damit werden dann die Zugriffe auf Dateien und Verzeichnisse durch den
Samba-Server protokolliert. Auf der Ebene des Dateisystems hat ein Auditing in dieser
Form bislang nicht Einzug in den Linux-Kernel gefunden, obwohl mehrere Anläufe für
eine Implementierung versucht wurden und in den vorhandenen Strukturen entsprechende Voraussetzungen für erweiterte Attribute bei den Linux-Dateisystemen vorhanden sind. In der Praxis scheint diese Funktionalität jedoch so wenig Bedeutung zu haben, dass alle Versuche bisher aus Mangel an Interesse nicht weiter aktiv verfolgt worden sind. Allerdings ist es über Security-Erweiterungen wie zum Beispiel SE-Linux
durchaus möglich, zumindest ein teilweises Auditing auch für die unterhalb von Samba
stattfindenden Dateisystemzugriffe zu realisieren.
1.1.6
Zusammenfassung der wichtigsten Folgen bei Verwendung von Samba
mit POSIX ACLs
Für Schreiben als abstraktes Recht gilt:

zwischen Daten schreiben und anhängen wird nicht unterschieden

bei Ordnern wird ebenso nicht zwischen dem Erstellen von Ordnern und dem
Erstellen von Dateien unterschieden

das Schreiben von Ordnern beziehungsweise Dateien und Attributen wird nicht
unterschieden.
Für das Lesen als abstraktes Recht gilt:

das Lesen von Ordnern beziehungsweise Dateien und von Attributen wird nicht
unterschieden.

Prinzipiell gilt, dass das Lesen von Berechtigungen immer erlaubt ist. Generell
sind weder Überwachung noch aktive Vererbung implementiert. Bei der Vererbungen gelten die Einschränkungen wie oben beschrieben.
1.1.7
Benutzergruppen und Zugriffsrechte
Insbesondere bei den von Arbeitsgruppen gemeinsam genutzten Freigaben spielt die
Vergabe von Zugriffsrechten an Gruppen eine herausragende Rolle. Unter NT werden
(Server-)lokale und globale Gruppen unterschieden. Lokale Gruppen können als AliasDefinitionen verstanden werden, die auf eine oder mehr globale Gruppen verweisen. Auf
diese Weise können lokale Gruppen mehrere globale Gruppen enthalten. Unter Samba
(wie unter UNIX / Linux allgemein) ist eine Verschachtelung von Gruppen nicht möglich.
Mit Samba lassen sich lediglich alle UNIX-Gruppen 1:1 als globale Gruppen für Windows
Clients und Member-Server darstellen.
Diese globalen Gruppen können auf Windows-Member-Servern natürlich wieder in lokale Gruppen eingehen. Damit stehen auf solchen Servern weiterhin die Modelle B-G-L-R
und B-G-R zur Verfügung, wie sie im Abschnitt II.E 1.4 beschrieben werden.
Seite 245
Die Einführung eines Konzepts von lokalen Gruppen auch für Linux-Server ist bislang
nicht geplant, sodass hier typischerweise nur das Modell B-G-R zum Einsatz kommt.
Eine äquivalente Funktionalität lässt sich mit entsprechender Business-Logik in einer
LDAP-basierten Gruppenverwaltung realisieren.
1.1.8
Abschätzung der Auswirkungen für die Benutzer
Bei der Abbildung der Windows-ACL auf die POSIX-ACL geht die feine Granularität
verloren, in der die Rechte unter Windows modifiziert werden können. Allerdings werden
in der Praxis überwiegend nur die wesentlich einfacheren Sammelberechtigungen der
einfachen Sicherheitseinstellungen verwendet.
Die weiteren, abgestuften Berechtigungen kommen nur in Einzelfällen zur Anwendung.
Besonders die Unterscheidung zwischen den Attribut- und den Dateirechten wird
äußerst selten verwendet.
Auch die Berechtigung Daten anhängen wird nur in wenigen Fällen sinnvoll nutzbar sein.
Diese Berechtigung kann bei Verwendung eines Extended 2/3 Dateisystems unter Linux
auch als erweitertes Attribut auf der Kommandozeile für ausgewählte Dateien gesetzt
werden.
Durch die konsistente Abbildung des einfacheren Rechtemodells der POSIX ACLs wird
das Bild der einfachen Sicherheitseinstellungen für den durchschnittlichen Benutzer zuverlässiger und für die Administratoren erheblich vereinfacht, ohne dabei wesentliche
Funktionalität zu verlieren.
Bestimmte Funktionen, wie die aktive Vererbung und Auditing des Dateisystems können
nur teilweise, wie im obigen Text beschrieben, nachgebildet werden und bedürfen zur
Abbildung gegebenenfalls zusätzliche Software.
Die Sicherheit der Dateiablage unter Samba ist nur bedingt abhängig von den Funktionen, die Samba bietet. Dies liegt daran, dass Samba mit unterschiedlichen Unix Distributionen verbunden werden kann. Wenn diese „unsicher― eingestellt sind, so wirkt sich dies
natürlich auch auf die Dateiablage aus. Mit Samba unter Linux ist der Zugriff auf Dateisysteme mit Festplattenverschlüsselung möglich.
Zusammenfassen lässt sich sagen, mit Samba unter Linux ist es möglich, für heterogene
Systemlandschaften eine zentrale Datenablage zu realisieren. Dabei müssen jedoch die
unterschiedlichen Umsetzungen von Zugriffsrechten auf Dateien bei Windows und Linux
mit Samba beachtet werden. Im Zusammenspiel mit den entsprechenden Verzeichnisdiensten ist auch eine Benutzerverwaltung und Verteilung von Zugriffsrechten in großen
Netzwerken unproblematisch.
Inwieweit die Änderung oder Entwicklung in der einen oder anderen Richtung als
einfacher oder vorteilhafter bewertet oder empfunden wird, hängt nicht zuletzt von den
beteiligten Personen selbst ab. Eine Migration zu Samba, Linux und Open Source
eröffnet neue Freiheitsgrade. Ein solcher Schritt zur Emanzipation von den Vorgaben
und Best Practices eines Herstellers bringt dem einzelnen Administrator neben mehr
Freiheit auch mehr Eigenverantwortung.
Seite 246
1.2
Linux-Server mit NFS
NFS (Network File Service) ist ein Netzwerkprotokoll, das von SUN Microssystems entwickelt wurde, um im UNIX Umfeld Verzeichnisse und Dateien freizugeben. Seitdem
SUN keine Weiterentwicklung des Protokolls betreibt, übernahm die IETF die Verantwortung zur Weiterentwicklung. NFS ist in den drei RFC 1094, RFC 1813 und RFC 3530
beschrieben. Der RFC 1094 wurde im März 1989 von Sun Microsystems veröffentlicht.
Bisher wurden folgende Versionen veröffentlicht:

NFS 2

NFS 3

NFS 4
NFS heißt zwar Filesystem (FS), ist aber eher ein Protokoll. NFS geht davon aus, dass
es auf ein bestehendes Filesystem zurückgreifen kann. Dies können Filesysteme wie
ReiserFS, EXT4 (Nachfolgeversion von EXT3) oder XFS sein. Über NFS lassen sich so
auch verteilte File Systeme (Distributed File Systems) realisieren. Theoretisch könnten
diese dann auch heterogen sein. In der Version 3 ist NFS noch zustandslos, was aus
Sicherheitsaspekten jedoch nicht wünschenswert ist. Daher ist ein Einsatz von NFS ohne zusätzliche Schutzmechanismen nur in geschlossenen Netzen zu empfehlen. Clients
benötigen zum Zugriff auf diese Freigaben immer einen NFS Client. Dieser ist bei allen
Unix Clients implementiert. Für Microsoft Betriebssysteme ist ein NFS Client über das
Microsoft Windows Services für UNIX (SFU) 3.5 Erweiterungspaket erhältlich. Dieses
Paket kann unter Windows2000, Windows XP und Windows2003 R2 genutzt werden.
NFS bietet die Möglichkeit des Zugriffs auf ein Dateisystem sowohl für Windows als auch
für Unix Clients. Darüber hinaus besteht durch NFS die Möglichkeit, verteilte Filesysteme
in einem Netzwerk anzubieten. Das heißt, der Anwender muss nicht wissen, auf welchen
physikalischen Festplatten sich zum Beispiel ein Verzeichnis befindet. Der Anwender
greift auf die Daten in dem Verzeichnis zu und das System übermittelt die Daten dann
zum Anwenderrechner, nachdem die Daten von NFS logisch zusammengeführt wurden.
Um auf ein NFS Laufwerk zugreifen zu können, muss der Anwender sich mit diesem
verbinden. Diese Herstellung einer Verbindung wird „mounten― genannt. Wenn ein Laufwerk oder Verzeichnis gemountet ist, stehen dem Anwender alle dort befindlichen Daten
zur Verfügung. Allerdings bietet NFS sehr unzureichende Zugriffsteuerungen auf die
freigegeben Verzeichnisse, da NFS die Unix „mode bits― zur Zugriffssteuerung nutzt.
Man kann zwar unter Linux mit NFS den Zugriff auf die einzelnen Dateien mit Hilfe der
implementierten ACLs steuern, aber damit ist keine Steuerung der Freigabe möglich.
Seit der Version NFSV4 ist das Protokoll nicht mehr zustandslos. Dadurch wird die Programmierung von Netzwerksicherungen insofern erheblich vereinfacht, indem sich das
Protokoll den Zustand einer vorangegangenen Transaktion „merkt―. So lässt sich zum
Beispiel festzustellen, ob ein bestimmter, nicht autorisierter Zugriff immer wieder versucht wird, der dann nach einer definierten Anzahl von Versuchen abgeblockt wird.
Unter Windows und OS/2 wurde die Funktionalität von NFS über das sogenannte Server
Message Block Protokoll (SMB) realisiert. Mit diesem Protokoll ist eine Benutzerauthentisierung möglich. NFS V3 authentifiziert nur den Client Rechner. Dies wurde mit
Seite 247
der Version NFS V4 geändert, sodass unter NFS4 auch eine Benutzerauthentifizierung
möglich ist.
Linux Server mit NFSV3 sollten nur in geschlossenen Netzwerken, das heißt in Netzwerken ohne Verbindung zu öffentlichen Netzen, eingesetzt werden. Mit NFS4 ist jedoch
auch eine Nutzung des Protokolls in offenen Netzen möglich.
Um eine Zugriffssteuerung auf die freigegebenen Verzeichnisse zu gestatten, empfiehlt
sich der Einsatz eines Linux Servers mit NFS in Kombination mit SAMBA beziehungsweise LDAP. Über die Sicherheitsmechanismen der Server wird die Schwachstelle im
NFS geschlossen.
Im Ergebnis ist es mit dem NFS Protokoll möglich, Datenfreigaben und verteilte DateiSysteme in einer heterogenen Landschaft anzubieten. Allerdings müssen die vorhandenen sicherheitsrelevanten Schwächen des Protokolls berücksichtigt werden. Für
geschlossene Systeme, zum Beispiel Testumgebungen kann der Einsatz von NFS
sinnvoll sein, um den administrativen Aufwand gering zu halten.
Für die Dateiservices innerhalb einer rein linuxbasierten Systemlandschaft wird das
bewährte Network File System (NFS) empfohlen. NFS wird traditionell für die netzwerkgestützte Dateiablage in UNIX-Netzwerken eingesetzt. NFS ist das Standardprotokoll, wenn Verzeichnisse von verschiedenen Unix-Systemen gemeinsam genutzt
werden sollen. Den Nutzern können mittels zentraler oder dezentraler Server die
benötigten Verzeichnisbereiche zur Verfügung gestellt werden. Die exportierten
Verzeichnisbäume werden auf den entsprechenden Arbeitsplatzrechner der Mitarbeiter
automatisch eingebunden.
Für eine physikalische Speicherung der Daten auf den Plattensystemen der eigentlichen
Server werden die Dateisysteme XFS und EXT4 empfohlen. Beide Systeme unterstützen Journaling-Funktionalitäten, Quotas und die Vergabe von Zugriffberechtigungen auf
Datei- und Verzeichnisebene.
1.3
Linux-Server mit OpenAFS
Entstanden ist OpenAFS aus dem von der Carnegie Mellon Universität entwickelten und
von IBM weitergeführten AFS (Andrew File System). Da AFS zunächst keine weite Verbreitung fand, entschloss sich IBM zur Entwicklung und Freigabe einer Version für die
Open Source Gemeinde. Zurzeit besitzt keine legale Einheit die Rechte am Source Code
von AFS. Trotzdem findet es immer mehr Verbreitung. OpenAFS ist für alle gängigen
Unix Distributionen sowie für Windows und Apple MAC OS X verfügbar.
Die bei NFSv3 aus der Protokolldefinition stammenden und bekannten Schwachstellen
wurden bei der Entwicklung von AFS berücksichtigt. Von Anfang an wurde bei der Entwicklung von AFS Wert darauf gelegt, diese oder ähnliche Schwachstellen nicht erneut
zu implementieren. Die derzeit aktuelle Version ist die Version 1.5.25200.
OpenAFS unterscheidet sich in seiner Architektur nicht von NFS. Das heißt, OpenAFS
ist ebenfalls nach dem Client Server Prinzip aufgebaut und kann zum Aufbau von verteilten Datenablagesystemen genutzt werden.
200
seit 20.09.2007; siehe http://www.openafs.org/).
Seite 248
Das ganzheitliche Konzept von OpenAFS beinhaltet nicht nur die einfache Freigabe von
Daten, sondern auch eine Kerberos basierte Authentifizierung, ferner die Datensicherung und eine für kryptografischen Komponenten nötige Synchronisation der Uhrzeit
zwischen Clients und Servern. Das AFS-Netzwerkprokoll greift nicht auf das Format von
Datenvolumen durch, auf dem die Daten abgelegt werden. Hierdurch kann die Dateistruktur des AFS Namensraums nicht über das Betriebssystem eingesehen werden und
die gleichzeitige Freigabe von Daten über SMB oder NFS für bestimmte Daten ist nicht
möglich.
Der Zugriff auf eine OpenAFS Freigabe erfolgt immer über einen entsprechenden OpenAFS Client, der auf der entsprechenden Workstation / Client installiert sein muss.
OpenAFS bietet die Möglichkeit einer differenzierten Benutzerverwaltung. So können
nicht nur Berechtigungen für die Freigabe der Verzeichnisse vergeben werden, sondern
auch für die Ausführung von Befehlen zur Dateibearbeitung. Das heißt, es ist möglich,
einem Benutzer Leserechte und einem anderen Benutzer Änderungsrechte auf einem
Verzeichnis einzuräumen. Diese Zugriffsteuerung erfolgt über ACLs und ignoriert die
unter Unix über „mode bits― eingestellten Berechtigungen. Die Berechtigungen können
auch zu Benutzergruppen zusammengefasst werden.
Rückblickend lässt sich zusammenfassen, dass OpenAFS die Sicherheitslücken von
NFS schließt, und damit der Einsatz von OpenAFS in offenen Netzen gegenüber dem
des NFS Protokolls zu bevorzugen ist. Auch wenn der Source Code zur Zeit keiner
rechtlichen Einheit zugeordnet ist, gibt es einen sogenannten Ältestenrat, der über den
Code wacht. Diesem Rat gehören sowohl Vertreter mehrere Universitäten als auch
Vertreter aus der Wirtschaft an.
Je nach Umfang einer clientseitigen Linux-Migration, rücken auch NFS und AFS in den
Fokus der Alternativbetrachtungen. NFS und AFS sind in UNIX-Netzen verbreitet, für die
Einbindung von Windows-Clients ist jedoch die Installation von spezieller Software auf
allen Clients erforderlich. Ein NFS-Client ist unter anderem in Microsoft Windows Services for UNIX (SFU 3.0) enthalten. Ein AFS-Client ist kostenlos und als Open Source von
OpenAFS.org erhältlich. Für den Einsatz von NFS oder AFS in einer Umgebung mit
Windows-Clients sind in jedem Fall tief greifende konzeptuelle Änderungen im Vergleich
zur Dateiablage mit Windows NT erforderlich.
1.4
Windows NT 4.0/2000/2003 mit NTFS
Das NTFS (New Technology File System) System wurde von Microsoft entwickelt, um
architektonische Schwächen, die das FAT System hatte, zu beheben. Inzwischen hat
das NTFS System in der Microsoft Welt FAT und seine Nachfolger so gut wie abgelöst.
Auf älteren Clients wird FAT gegebenenfalls noch verwendet. Auf neu installierten
Clients sollte immer NTFS in einer aktuellen Version installiert sein.
Das Filesystem NTFS wurde von Microsoft bisher in folgenden Versionen herausgebracht:

NTFS 1.x mit Windows NT 3.x

NTFS 2.x mit Windows NT 4
Seite 249

NTFS 3.0 mit Windows 2000 (NT 5)

NTFS 3.1 ist aktuelle Version unter Windows XP und 2003.
Mit Windows Vista hat Microsoft keine neue Version von NTFS eingeführt.
Häufig finden sich auch Bezeichnungen wie NTFS 4 und NTFS 5, dies sind aber keine
offiziellen Versionsnummern. Diese Bezeichnungen beziehen sich auf die jeweilige Version des Betriebssystem NT4 (Windows NT 4.0 Server / Workstation) beziehungsweise
NT5 (Windows 2000 Server / Workstation), mit der die jeweilige Version des NTFS ausgeliefert wurde. Um die Vergleichbarkeit zum Migrationsleitfaden Version 2.1 zu gewährleisten, werden in diesem Kapitel die Bezeichnung NTF4 und NTF5 beibehalten.
NTFS ist Bestandteil der jeweiligen Betriebssysteme und unterliegt damit den Lizenzbedingungen für diese.
In NTFS werden alle abgelegten Daten als eine Datei behandelt. Diese wird MFT
(Master File Table) genannt. Hier werden die Informationen hinterlegt, welche Datenblöcke der Festplatte zu welcher Datei gehören. Auch die Zugriffinformationen und die
Datei-attribute sind hier abgelegt (weiterhin wird auch der Inhalt einer Datei als Attribut
angesehen).
Im Folgenden wird auf den Nachfolger von Windows NT4.0 Server, Windows 2000
Server und Windows Server 2003 R2 hinsichtlich des Themas „File Service― eingegangen. Zunächst erfolgt eine Beschreibung des NTFS 4 Filesystems, welches die
Grundlage für die heutige Dateiablage und -Verwaltung unter Windows bildet. Im
Weiteren werden dann die Neuerungen durch NTFS 5 dargestellt.
1.4.1
Eigenschaften
NTFS 4 besitzt u.a. folgenden Eigenschaften:
Jeder Ordner und jede Datei verfügt über eine sogenannte Access Control List (ACL),
die an der Datei oder dem Ordner gespeichert wird. In der ACL stehen sogenannte
Access Control Entries (ACE), in dem die SID des Gruppen- oder des Benutzerkontos
und die Berechtigung stehen. Über die ACL erfolgt somit die Zugriffssteuerung, die
insgesamt granular aufgebaut werden kann. Die ACL ist in die Bereiche SACL (System
Access Control List) und DACL (Discretionary Access Control List) zu unterscheiden: In
der DACL sind die SIDs der Gruppen und Benutzer abgelegt, die auf das Objekt
zuzugreifen dürfen beziehungsweise daran gehindert werden. In der SACL ist festlegt,
wie das Sicherheitssubsystem die Zugriffe auf das Objekt überwacht.
NTFS 4 unterstützt im Prinzip keine Vererbung; lediglich beim Neuerstellen einer Datei
werden die Rechte des Ordners in die ACL der Datei kopiert. Ändern sich die Rechte
des Ordners, muss explizit das Durchschreiben in die ACLs der beinhalteten Dateien
angeordnet werden. Eine Besonderheit ist zu beachten: Eine Datei, die sich im UNCPfad \\server\freigabe\ordner\subordner befindet, kann von einem Anwender gelesen
werden, obwohl der Ordner „ordner― das Lesen verbietet, der Ordner „subordner― es
aber zulässt.
Bezüglich der Länge der Pfadnamen gibt es kein Limit. Unterstützt werden Dateinamen
mit bis zu 255 Zeichen. Die verwendeten Zeichen dürfen theoretisch dem UnicodeZeichensatz (16bit) bis auf wenige Ausnahmen (zum Beispiel *, \) entnommen werden.
Seite 250
Zu jedem Ordner und jeder Datei wird ein Kurzname gespeichert, welcher der 8.3-Konvention entspricht und automatisch vom Betriebsystem generiert wird. Während bei der
Speicherung dabei zwischen Groß- und Kleinschreibung unterschieden wird, ist dies
beim Zugriff auf die Datei in der Regel nicht der Fall.
Jeder Ordner und jede Datei verfügt über Attribute in Form von Flags (schreibgeschützt,
Archiv, System, versteckt und komprimiert) und über Angaben zu den Zeiten der ersten
Erstellung, der letzten Änderung und des letzten Zugriffs. Der Komprimierungsgrad ist
stark abhängig vom Inhalt.
NTFS unterstützt die Technologie von Multiple Streams. Die Einsatzhäufigkeit ist relativ
gering. Alternative Daten Streams werden z.T. auch von Schadprogrammen genutzt, da
viele Virenscanner diese Streams nicht untersuchen und die Schadprogramme daher
unentdeckt bleiben. Multiple Streams müssen von der jeweiligen Anwendung unterstützt
werden beziehungsweise in dieser programmiert sein. Multiple Streams ermöglichen
unter anderem die Speicherung der Ressource Folk von Macintosh-Dateien.
Seit dem Service Pack 4 für Windows NT 4.0 Server werden innerhalb von NTFS Quotas unterstützt. Die Vergabe und Kontrolle der Quoten basiert auf der BesitzerEigenschaft und umfasst das gesamte Volumen (logisches Laufwerk des File Servers).
Durch diese technischen Beschränkungen ist der Einsatz eher als ein Sonderfall und
weniger als die Regel in bestehenden Umgebungen einzustufen.
Die maximale Dateigröße ist unter NTFS 4 auf 2 TB (Terabyte) und die Größe des logischen Laufwerkes beschränkt. Das logische Laufwerk kann maximal 2 TB (theoretisch
16 Exabyte) umfassen. Die tatsächliche Netto-Datenmenge hängt von der Clustergröße
ab, die bei der Formatierung verwendet wurde. Die Anzahl der Dateien ist auf 2 32-1 beschränkt.
NTFS ermöglicht ein Auditing (Überwachen) der erfolgten Zugriffe beziehungsweise der
Zugriffs-versuche. Auf diese Weise können zum Beispiel wiederholte, ungewünschte
Löschungen von Dateien diagnostiziert werden.
NTFS formatierte Datenträger werden im laufenden Betrieb defragmentiert. Eine automatische Korrektur (Selbstheilung) unter Windows NT 4.0 erfolgt nicht. Zu diesem Zweck
müssen Produkte von Drittherstellern eingesetzt werden.
1.4.2
Rechtesystem des NTFS
Windows kennt insgesamt 13 Berechtigungen, die einem Objekt im Dateisystem (Datei
oder Verzeichnis) pro Benutzer oder Gruppe zugeordnet beziehungsweise entzogen
werden können.
Diese sind:

Ordner durchsuchen / Datei ausführen

Ordner auflisten / Datei lesen

Attribute lesen

Erweiterte Attribute lesen

Dateien erstellen / Daten schreiben
Seite 251

Ordner erstellen / Daten anhängen

Attribute schreiben

Erweiterte Attribute schreiben

Unterordner und Dateien löschen

Löschen

Berechtigungen lesen

Berechtigungen ändern

Besitzrechte übernehmen.
Änderungen an Zugriffsrechten werden über den Dialog Eigenschaften und dort auf der
Karteikarte Sicherheitseinstellungen vorgenommen. In der Absicht, die Komplexität des
Systems aus 13 eng verwandten Einzelberechtigungen vor dem Durchschnittsbenutzer
zu verbergen, werden in dieser Karteikarte vordefinierte Aggregate, sogenannte Sammelberechtigungen, aus sinnvollen Kombinationen der Einzelberechtigungen zur Auswahl angeboten. Für Dateien gibt es fünf, für Verzeichnisse sechs solcher Sammelberechtigungen, die jeweils zugelassen oder verweigert werden können. Erst im Dialog
Berechtigungseintrag der über die Buttons Erweitert/Anzeigen/Bearbeiten in den Sicherheitseinstellungen erreichbar ist, werden die 13 einzelnen Berechtigungen komplett dargestellt.
Dabei ist die bei den Sicherheitseinstellungen gebotene Sicht auf die Sammelberechtigungen äußerst problematisch, weil die Darstellung sehr schnell das Fehlen von Rechten suggerieren kann, obwohl sie in Wirklichkeit vorhanden sind. So entsteht beispielsweise aus einem Vollzugriff, bei dem allein die Berechtigung zum Schreiben der erweiterten Attribute nicht zugelassen ist, in der einfachen Darstellung bei den Sicherheitseinstellungen das Bild eines Rechteprofils, das nur das Lesen und Ausführen erlaubt. Die
folgende Tabelle zeigt, welche Kombinationen von Berechtigungen zu welcher Darstellung als Sammelberechtigung führen. Wohlgemerkt, wenn nur ein einziges Recht in diesen Aggregationen nicht gesetzt ist, enthält die entsprechende Checkbox für die Sammelberechtigung kein Häkchen mehr.
Windows Sammelberechtigungen
VollzuÄndern
Lesen &
Ordnergriff
Ausfühinhalt
ren
auflisten
Lesen
Ordner durchsuchen
/ Datei ausführen
Ordner auflisten /
Daten lesen
Attribute lesen
X
X
X
X
X
X
X
X
X
X
X
X
X
X
lesen
Dateien erstellen /
Daten schreiben
X
X
X
X
X
X
X
Schreiben
X
Seite 252
Windows Sammelberechtigungen
VollzuÄndern
Lesen &
Ordnergriff
Ausfühinhalt
ren
auflisten
Lesen
Schreiben
Ordner erstellen /
Daten anhängen
Attribute schreiben
X
X
X
X
X
X
schreiben
Unterordner/Dateien
löschen
Löschen
X
X
X
X
X
Berechtigungen
lesen
Berechtigungen
ändern
X
X
X
X
X
X
X
X
Tabelle 45: Eigenschaften der Windows Sammelberechtigungen
Aufgrund der beschriebenen Inkonsistenzen wird im Folgenden ausschließlich die
erweiterte Ansicht im Dialog Berechtigungseintrag betrachtet.
1.4.3
Attributsystem
Zusätzlich zu den Berechtigungen wird für Datei- und Verzeichnisobjekte noch eine Anzahl von sogenannten Attributen und erweiterten Attributen verwaltet.
Name
Archiv
Bit
Bedeutung
A
Datei wurde seit dem letzten Zurücksetzen des Attributes verändert
Schreibgeschützt
Versteckt
R
Datei ist schreibgeschützt
H
Datei wird nicht angezeigt
System
S
Datei ist für das System reserviert
Komprimiert
C
Datei/ Ordner wird auf dem Medium komprimiert gespeichert
Verschlüsselt
E
Datei/ Ordner wird auf dem Medium verschlüsselt gespeichert
Tabelle 46: Windows Attribute
1.4.4
Überwachung
Windows verfügt über weitreichende Überwachungsmöglichkeiten auf der Datei- und
Verzeichnisebene. So können alle Berechtigungen einzeln pro Benutzer oder Gruppe
überwacht werden. Die daraus resultierenden Informationen werden im Sicherheitsprotokoll des Domänen-Controllers beziehungsweise des jeweiligen Windows 2000
Rechners gespeichert, sofern in der Systemrichtlinie die Überwachungsrichtlinie freigegeben wird.
Seite 253
1.4.5
Zugriffssteuerung
Die Zugriffssteuerung über das Netzwerk auf Dateien oder Ordner erfolgt in Windows NT
Umgebungen über zwei Mechanismen:

Ordnerfreigabe (Share) und

NTFS-Rechte.
Um über das Netzwerk auf eine Datei zugreifen zu können, muss einer der darüber liegenden Ordner freigegeben werden. Diese Freigabe wird ebenfalls mit einer ACL versehen, die in der Registry gespeichert wird. Die Rechte auf diese Freigabe beschränken
sich auf die Stufen

Lesen

Ändern

und Vollzugriff.
Diese Rechte gelten absolut, das heißt, dass darunter liegende NTFS-Rechte effektiv
durch die Freigaberechte beschnitten werden. Beispiel: Das Leserecht auf Freigabeebene verhindert das Schreiben auch dann, wenn die NTFS-Rechte dies zulassen würden.
Besonderes Augenmerk in Windows NT Umgebungen ist auf die Privilegien (Richtlinien
für Benutzerrechte) zu richten, denn sie können hinsichtlich der File Services zum Beispiel durch „Besitz übernehmen von Dateien und Objekten― und „Sichern von Dateien
und Ordnern― von Bedeutung sein.
1.4.6
Benutzer und Gruppenkonzept
Jeder Ordner und jede Datei ist einem Besitzer zugeordnet, der sowohl eine Gruppe als
auch ein Benutzerkonto sein kann. Im Normalfall wird der erzeugende Benutzer der
Besitzer. Ist der Benutzer Mitglied der Administratorengruppe, wird diese Gruppe der
Besitzer.
Eine systematische Zugriffssteuerung in der Windows NT Umgebung bevorzugt die Vergabe von Rechten an Gruppen. Die Vergabe von Rechten an einzelne Benutzerkonten
sollte den benutzerspezifischen Dateiablagen vorbehalten bleiben.
Innerhalb einer Windows NT Umgebung sind folgende Gruppentypen zu unterscheiden:

globale Gruppen

lokale Gruppen auf Member Servern

lokale Gruppen auf Domain Controllern
Lokale Gruppen auf Domain Controllern unterscheiden sich insofern von denen auf
Member Servern, als sie auf allen Domain Controllern der Domäne mit der gleichen SID
vorhanden sind.
Seite 254
Lokale Gruppen auf Member Servern dürfen mit den folgenden Gruppen (Group Nesting) verschachtelt sein:

den globalen Gruppen der eigenen Domäne

oder den globalen Gruppen der Domänen, denen die eigene vertraut.
Globale Gruppen haben nur Benutzerkonten als Mitglieder.
In einer Windows NT Domänenlandschaft sind zwei verschiedene „klassische― Zugriffsteuerungen bekannt:

B-G-L-R Methode:
Der Benutzer ist Mitglied einer globalen Gruppe. Die ist wiederum Mitglied einer
lokalen Gruppe eines File Server. Nur für diese lokale Gruppe sind NTFS Berechtigungen an einer Datei-Ressource gesetzt.

B-G-R Methode:
Der Benutzer ist Mitglied einer globalen Gruppe. Nur für diese globale Gruppe
sind NTFS Berechtigungen einer Datei-Ressource vergeben.
Abbildung 27: B-G-L-R Methode
Seite 255
Abbildung 28: B-G-R Methode
Beide Methoden funktionieren nur dann ohne Sicherheitsrisiken, wenn die Zuordnung
von Ressource und lokaler Gruppe (beziehungsweise globaler Gruppe) eindeutig ist.
Das heißt, dass die Gruppe ausschließlich für diese Ressource verwendet wird.
Werden die File Services durch einen Cluster realisiert, hat die Methode B-G-L-R den
Nachteil, dass die lokalen Gruppen auf den Knotenservern nicht die identischen SIDs
besitzen können. Abhilfe schafft hier nur die Konfiguration der Knoten als Domain Controller oder die Verwendung der Methode B-G-R.
1.4.7
Funktionszuwachs
Mit Windows 2000 Server und Windows Server 2003 R2 gehen hinsichtlich der File
Services einige Neuerungen einher. Hierzu gehören u.a.:

Dateisystem NTFS 5

HSM-API

Vererbung

Verschlüsselung (EFS)

SMB over Native IP

Dynamische Datenträgerverwaltung

Defragmentierung

Gruppenverschachtelung

Remote Storage

Indexing Service
Seite 256

Distributed Link Tracking

DFS

Offline Folder

Folder Redirection.
1.4.8
Dateisystem NTFS 5
Das Dateisystem NTFS 5 bietet insgesamt folgende Verbesserungen:
Erstmals ist es möglich, die Zugriffsrechte durch Vererbung zu verwalten. Das bedeutet,
dass durch das Setzen von Rechten auf übergeordneten Ordnern diese auf untergeordneten Ordnern und Dateien wirksam werden, ohne das Durchschreiben (Einbrennen)
durchführen zu müssen. Die Nachteile des Durchschreibens (Lastproblem, Löschen von
speziellen Rechten in Unterordnern) entfallen somit.
NTFS 5 verfügt über ein Change Journal, in dem die Änderungen protokolliert werden.
NTFS 5 formatierte Datenträger verfügen über einen versteckten Ordner namens „System Volume Information―, auf den nur das Betriebssystem Zugriff hat und in dem die
zusätzlichen Funktionen verwaltet werden.
NTFS 5 bietet die Möglichkeit, Daten zu verschlüsseln. Das Encrypting File System
(EFS) ermöglicht es Benutzern, Daten vor dem Lesen des Inhalts durch Dritte (auch der
Administratoren) zu schützen. In Unternehmensnetzwerken ist hierzu eine PKI (Public
Key Infrastructure) notwendig.
Die Integration von Quotas im Dateisystem bleibt vorhanden, unterliegt aber weiterhin
den Beschränkungen von NTFS 4.
1.4.9
Protokolle
Windows 2000 Server und Windows Server 2003 R2 unterstützen nach wie vor die oben
genannten Protokolle. Seit Windows 2000 Server / Workstation ist es möglich, die Kommunikation über NetBIOS abzuschalten. Für die File Services bedeutet dies, dass das
„Direct Hosting of SMB Over TCP/ IP― bei der Kommunikation über den Port 445 erfolgt.
1.4.10
Datenträgerverwaltung
Windows 2000 / 2003 (alle Versionen) bieten ferner die Möglichkeit, physische Festplatten in das System einzubinden, ohne Laufwerksbuchstaben vergeben zu müssen.
Diese dynamischen Datenträger können als Ordner in traditionellen Datenträgern eingebunden und bereitgestellt werden201. Windows 2000 / 2003 (alle Versionen) liefern erstmals ein Werkzeug zum Defragmentieren von Datenträgern, wobei dies bei Nutzung des
NTFS 5 File Systems nicht notwendig sein sollte.
201
Eine detaillierte Beschreibung der Datenträgerverwaltung und ihrer verschiedenen Möglichkeiten findet sich unter: http://www.microsoft.com/de/de/default.aspx. Wird auf dieser Seite
als Suchbegriff „Datenträgerverwaltung― eingegeben, führt dies direkt in das entsprechende
Kapitel beim Microsoft TechNet.
Seite 257
1.4.11
Änderungen bzgl. Zugriffsteuerung (Gruppenverwaltung)
Seit Windows 2000 Server gibt es zwei unterschiedliche Gruppentypen:

Sicherheitsgruppen:
Sicherheitsgruppen sind in DACLs (Discretionary Access Control Lists) aufgeführt, die Berechtigungen für Ressourcen und Objekte definieren. Eine Sicherheitsgruppe kann auch als E-Mail-Gruppe verwendet werden. Eine an die Gruppe
gesendete E-Mail-Nachricht wird automatisch an alle Gruppenmitglieder verteilt.

Verteilergruppen:
Für Verteilergruppen werden keine Sicherheitsfunktionen aktiviert. Sie können
nicht in DACLs aufgelistet werden. Verteilergruppen können nur mit Unterstützung von E-Mail-Anwendungen, z. B. Microsoft Exchange, eine E-Mail an eine
Gruppe von Benutzern senden. Wenn eine Gruppe nicht aus Sicherheitsgründen
erforderlich ist, können sie anstelle einer Sicherheitsgruppe eine Verteilergruppe
erstellen.
Auch wenn Kontakte sowohl einer Sicherheitsgruppe als auch einer Verteilergruppe
hinzugefügt werden können, ist es nicht möglich, diesen Kontakten Rechte und
Berechtigungen zuzuweisen. Es können E-Mail-Nachrichten an die in einer Gruppe
enthaltenen Kontakte gesendet werden.
1.4.12
Konvertieren von Sicherheits- und Verteilergruppen
Eine Gruppe kann von einer Sicherheitsgruppe in eine Verteilergruppe konvertiert
werden und umgekehrt. Dies kann jederzeit erfolgen, solange die Domäne im
einheitlichen Modus ausgeführt wird. Befindet sich eine Domäne im gemischten Modus,
können keine Gruppen konvertiert werden.
1.4.13
Verschachteln von Gruppen
Durch die Verschachtelung können Gruppen zu Mitgliedern anderer Gruppen werden.
Durch verschachtelte Gruppen lässt sich die Gruppenverwaltung vereinheitlichen, da
sich die Anzahl der Mitgliedskonten erhöht, für die die jeweiligen Verwaltungsaufgaben
ausgeführt werden. Zusätzlich wird der Replikationsdatenverkehr verringert, der durch
die Replikation veränderter Gruppenmitgliedschaften entsteht.
Die Verschachtelungsoptionen richten sich danach, ob die Domäne im einheitlichen oder
im gemischten Modus ausgeführt wird. Bei Gruppen in Domänen im einheitlichen Modus
oder bei Verteilergruppen in Domänen im gemischten Modus wird die Mitgliedschaft auf
folgende Weise bestimmt:

Gruppen mit dem Bereich „Universal" können folgende Mitglieder enthalten: Konten, Computerkonten, andere Gruppen mit dem Bereich „Universal" und Gruppen
mit dem Bereich „Global" einer beliebigen Domäne.

Gruppen mit dem Bereich „Global" können folgende Mitglieder enthalten: Konten
derselben Domäne und andere Gruppen mit dem Bereich „Global" aus derselben
Domäne.
Seite 258

Gruppen mit dem Bereich „Lokale Domäne" können folgende Mitglieder enthalten: Konten, Gruppen mit dem Bereich „Universal" und Gruppen mit dem Bereich
„Global" einer beliebigen Domäne. Diesen Gruppen können innerhalb derselben
Domäne auch andere Gruppen mit dem Bereich „Lokale Domäne" angehören.
Sicherheitsgruppen in einer Domäne im gemischten Modus sind auf die folgenden Mitgliedstypen beschränkt:

Gruppen mit dem Bereich „Global" können ausschließlich Konten enthalten.

Zu den Mitgliedern von Gruppen mit dem Bereich „Lokale Domäne" können andere Gruppen mit dem Bereich „Global" sowie Konten zählen.
Da der Gruppenbereich „Universal" ausschließlich in Windows 2000-Domänen im einheitlichen Modus unterstützt wird, können in Domänen im gemischten Modus keine Sicherheitsgruppen mit dem Bereich „Universal" erstellt werden.
1.4.14
Remote Storage
Remote Storage ist ein neuer Dienst der seit Windows 2000 Server angeboten wird und
ermöglicht die Auslagerung von lange nicht genutzten Dateien auf Bandlaufwerke im
Sinne eines HSM (Hierarchical Storage Management).
1.4.15
Indexing Service
Der Indexing Service kann optional für Dateiordner eingeschaltet werden, um die dort
gespeicherten Dateien zu indizieren. Der erstellte Index ermöglicht eine schnellere Suche nach bestimmten Inhalten. Mit dem Indexdienst können folgende Typen von Dokumenten in verschiedenen Sprachen indiziert werden:

HTML

Text (Plain Text)

Microsoft Office 95 oder höher

MIME (Multipurpose Internet Mail Extension).
1.4.16
Distributed Link Tracking
Windows 2003 R2 File Server ermöglichen es, dass Anwendungen, die das Verknüpfen
und Einbetten von Objekten unterstützen, so programmiert werden können, dass beim
Verschieben der verknüpften Objekte Informationen über den aktuellen Speicherort vom
Dateisystem abgerufen werden können.
1.4.17
Distributed File System
Das Distributed File System (DFS) konnte bereits unter Windows NT 4 durch zusätzliche
Installationen auf Server und Client bereitgestellt werden. Bei Windows 2000 / 2003 sind
diese Funktionalitäten sowohl auf Client- als auch auf Serverseite standardmäßig integriert und zusätzlich erweitert worden. DFS ermöglicht, dass Freigaben von Ordnern, die
auf verschiedenen Servern verteilt sind, dem Client als Unterordner einer einzelnen
Freigabe dargestellt werden. Damit wird eine Einsparung von Laufwerksbuchstaben hinsichtlich der Netzlaufwerke, die dem Anwender zugeordnet werden sollen, erzielt. DarüSeite 259
ber hinaus muss der Benutzer nicht wissen, wo seine Daten sich physikalisch befinden.
In Windows 2000 / 2003 wurde DFS um die Integration von FRS (File Replication Service) dahingehend erweitert, dass die verknüpften Freigaben und deren Inhalte auf weitere
Freigaben und anderen File Servern repliziert werden. Fällt ein Server und somit dessen
Freigabe aus, dann stehen dem Client die Repliken zur Verfügung, ohne neue Netzwerkverbindungen aufbauen zu müssen. In Windows 2000 / 2003 können die Informationen über den DFS-Baum im Active Directory gespeichert und repliziert werden. Dadurch verfügt der Client nahezu jederzeit über die benötigten Verbindungsinformationen.
1.4.18
Verbindungsherstellung
Dem Anwender kann die Suche nach Freigaben erleichtert werden, indem die Freigaben
im Active Directory veröffentlicht werden.
1.4.19
Offline Folder und Folder Redirection
Die Funktionalitäten „Offline Folder― und „Folder Redirection― sind primär keine Eigenschaften der File Services von Windows 2000 Server beziehungsweise Windows Server
2003 R2, sondern Funktionalitäten des Client (zum Beispiel Windows 2000/Professional,
Windows XP, Vista). Sie seien an dieser Stelle dennoch erwähnt, weil sie hinsichtlich der
Datenhaltung prinzipiell relevant sind und mit dem File Server zusammenarbeiten müssen. Offline Folder stellen quasi den Nachfolger des „Aktenkoffers― von früheren Windows Versionen dar. Anwender, die zum Beispiel über ein Notebook verfügen, können
Ordner und Dateien, die normalerweise auf File Servern gespeichert werden, ohne
Netzwerk-verbindung bearbeiten. Sobald eine Verbindung zum File Server besteht, werden diese Daten wieder abgeglichen (repliziert). Aufgrund dieser Replikation sind auf
beiden Seiten (Client und Server) die jeweiligen Dateieigenschaften von großer Bedeutung, um einen fehlerfreien Abgleich zu ermöglichen.
Mit der Funktionalität Folder Redirection trägt Windows 2000 / 2003 (alle Versionen)
dem Umstand Rechnung, dass die Größe von Benutzerprofilen auf Arbeitsplatzsystemen
im laufenden Betrieb stark anwachsen kann. Dies geschieht zum Beispiel dann, wenn
der Anwender dort unter „Eigene Dateien― seine Dateien speichert, die eigentlich auf File
Servern abgelegt werden sollen. Seit Windows 2000 (alle Versionen) ist es möglich, die
Systemordner des Benutzerprofils („Eigene Dateien―, „Anwendungsdaten―) auf einen
Netzwerkpfad zu „verbiegen―. Diese Ordner erscheinen dem Anwender transparent als
lokale Ordner. Durch das Verschieben der Ordner auf File Server muss beachtet werden, dass die Zugriffsrechte gewahrt bleiben.
1.4.20
Sicherheit
NTFS bietet die Möglichkeit, Daten zu verschlüsseln. Um an Daten auf einer NTFS Datenpartition zu kommen, muss diese von einem Gerät gelesen werden, die das NTFS
System unterstützt. Die Verwaltung der Zugriffskontrolle erfolgt über die Benutzerverwaltung des Betriebssystems.
Seite 260
1.4.21
Fazit
NTFS bietet alle Voraussetzungen, um eine sichere und benutzerbezogene Dateiblage
zu realisieren. Einzig die Längenbeschränkung der Dateinamen inklusive ihrer Pfadangaben auf 255Zeichen kann in Spezialfällen zu Problemen führen, da dies dem Anwender nicht transparent ist und er bei der Datenablage keinen Warnhinweis erhält, falls er
diese überschreitet. Dieser Umstand kann aber durch organisatorische Maßnahmen
entsprechend berücksichtig werden.
2
Migrationspfade
Bevor auf die einzelnen Migrationspfade eingegangen wird, sollen vorab die Funktionen
der einzelnen, im Kapitel II.E 1 beschriebenen Dateiablagesysteme gegenübergestellt
werden.
Bei der funktionalen Übersicht der alternativen Netzdateisysteme kommen indirekt auch
Eigenschaften des darunter liegenden Serverdateisystems zum Tragen (zum Beispiel
maximale Dateigröße oder Dateirechte). Für die linuxbasierten Server werden für diesen
Vergleich das XFS und das EXT3 Dateisystem zugrunde gelegt.
Funktion
WinNT
NTFS 5
Samba 3.0
NFS 4
AFS
1.5.25
X
X
X
256
256
256
256
256
Zeichensatz für Dateinamen
Unicode
Unicode
Unicode
ISO-Latin
ISO-Latin
Darstellung von Groß/ Kleinschreibung
X
X
X
X
X
einstellbar
X
X
X
X
X
X
EFS
dateiweise
clientseitig
X
X
202
Maximale Dateigröße
2 TB
2 TB
2 TB
Maximale Pfadlänge
Unbegr.
Unbegr.
Unbegr.
X
(Eine Form
von Auditing
gibt es als
SambaVFS-Plugin
Windows-Client ohne Zusatzsoftware
Länge der Dateinamen
(Zeichen)
Unterscheidung von Groß/ Kleinschreibung
Disk Quotas
Verschlüsselung
Kompression
204
Änderungsjournal
202
203
204
205
203
205
9 EB
Unbegr.
Als Erweiterung (Patch) zum Beispiel für Ext2/3 Dateisysteme erhältlich
Als Erweiterung (Patch) zum Beispiel für Ext2/3 Dateisysteme erhältlich
TB Terabyte 1012, PB Petabyte 1015, EB Exabyte 1018
NFSv3 mit XFS Dateisystem, je nach Architektur bis zu 9EB, für i386 max. 16TB
Seite 261
2 GB
Unbegr.
Funktion
WinNT
NTFS 5
Samba 3.0
NFS 4
AFS
1.5.25
vfs_full_
audit)
Propagierung der
Freigaben im ActiveDirectory
X
Verteiltes Dateisystem
DFS
DFS
Standard
Standard
Dateireplikationsdienst
FRS
rsync
rsync
rsync
X
X
X
X
DACL
NTFS
POSIX
POSIX
AFS
SACL
NTFS
Samba Modul
Journaling
Typische Autorisierung über
NT/ LM
PDC
AD / KerbeNT/LM
NIS/ LDAP
ros
LDAP, wenn
AD-Mitglied
dann Kerberos
Kerberos
Version 4
Tabelle 47: Vergleich der Dateiserver
Eine Migration der Dateiablage findet in der Regel durch das Kopieren von Daten von
dem alten auf das neue System statt. Hierbei sind die oben beschriebenen Unterschiede
bei den einzelnen Systemen zu beachten. Weiter ist bei allen Migrationspfaden zu beachten, dass gegebenenfalls wichtige Dateiinformationen, zum Beispiel das Erstellungsdatum einer Datei, verloren gehen können (unter Erstellungsdatum ist hier das Datum
der ersten Erstellung der Datei zu verstehen). Es muss daher im Vorfeld einer Migration
geklärt werden, ob und welche Dateieigenschaften, zum Beispiel aus rechtlichen Gründen, bei einer Migration unverändert bleiben müssen.
Unverändert müssen zum Beispiel folgende Eigenschaften bleiben:

Datum der Ersterstellung der Datei

Pfadangabe der Ersterstellung

Name der Ersterstellung

Benutzername des Ersterstellers

Dateigröße

Übernahme der Änderungsverfolgung
Dies kann zu einer Erhöhung der Komplexität führen, da das einfache Kopieren der
Dateien in diesem Fall nicht möglich ist.
Um eine Migration durchzuführen, empfiehlt sich statt des einfachen Kopierens der
Daten (zum Beispiel mittels Browser) die Nutzung des rsync Befehls. Mit Samba 4 wird
es künftig auch möglich sein, über diesen Befehl zum Beispiel das Attribut der
Seite 262
Dateiersterstellung zu übertragen. Dieses vereinfachte Vorgehen ist zurzeit noch nicht
möglich, doch der rsync Befehl wird stetig weiter entwickelt206.
Im Rahmen der Betrachtungen zur Migration der Dateiablage wird davon ausgegangen,
dass auf den Clients keine Nutzdaten lokal gespeichert werden. Bei einer eventuellen
Migration von Clients wird ein neues System mit identischer Funktionalität aufgesetzt,
ohne dass Daten vom alten Client übernommen werden.
Wenn eine große Zahl identisch ausgestatteter Clients zu migrieren ist, kommt ein festplattenloser Betrieb auf einem reinen Netzdateisystem in Frage. Dieser Spezialfall von
netzwerkzentraler Dateiablage bietet insbesondere bei der Administration große Vorteile:
Änderungen an der Client-Konfiguration werden nur ein einziges Mal auf dem Server
ausgeführt und sind automatisch auf allen damit arbeitenden Clients wirksam. Für die
Auswahl des Serverdienstes, auf dem ein „diskless Client― aufsetzt, müssen prinzipiell
die gleichen Überlegungen angestellt werden wie bei der Auswahl des Serversystems
für die zentrale Dateiablage allgemein.
Eine Migration der Dateiablage kann stets als Chance genutzt werden, die Ablagestruktur, das Rechtesystem und die Daten auf ihre Funktionalität und Aktualität zu prüfen. Gegebenenfalls kann es sinnvoll sein, bei einer solchen Migration Daten zu archivieren beziehungsweise zu löschen.
2.1
Migration von Windows Server NT 4 mit NTFS 4 nach Linux mit Samba
(SMB/CIFS) und POSIX
Bei der direkten Ablösung eines Windows NT Servers als Dateiablage unter Beibehaltung der Windows Clients bietet sich im Open Source Bereich Samba als erste Wahl an.
Wie bereits im Abschnitt II.E 1.1 dargelegt, erfüllt ein Samba Server wie ein NT Server
die Anforderungen an eine Dateiablage und im Zusammenspiel mit POSIX (siehe auch
Abschnitt II.E 1.1) lassen sich die Rechtestrukturen wie unter Windows NT abbilden.
Dies gilt auch für die erweiterten Rechte unter Windows, obwohl diese in der Praxis nur
selten zur Anwendung kommen.
Wenn hier von Abbildung die Rede ist, stellt sich auch die Frage, gehören die
Betrachtungen zu Samba und POSIX nicht eigentlich in den vorliegenden Abschnitt? Die
Autoren des Migrationsleitfadens haben sich aus zwei Gründen für die vorliegende
Strukturierung entschieden. Zum einen werden unter den Produkt- und Technologiebetrachtungen die Eigenschaften, Funktionen und Möglichkeiten der Produkte, der
Technologien beschrieben. Zum zweiten werden diese Eigenschaften, Funktionen und
Möglichkeiten im Falle von Samba im Zusammenspiel mit POSIX nicht nur bei der
Migration einer NT-basierten Umgebung in eine gemischte Windows/Linux-Umgebung
benötigt, sondern diese werden grundsätzlich benötigt, wenn eine solche Umgebung
aufgebaut werden soll.
An dieser Stelle sollen nun noch die Aspekte der reinen Migration betrachtet werden.
Dies bedeutet dann aber wiederum nur, dass die Dateien von der einen AblageUmgebung in die neue Ablage-Umgebung gebracht werden müssen.
206
http://rsync.samba.org/
Seite 263
Bevor diese Überführung der Dateien erfolgt, sollte in jedem Migrationsprojekt, welche
die Migration der Dateiablage zum Ziel hat, vor allem die bestehenden Rechtestrukturen
der Dateiablage dahingehend geprüft werden, ob sie noch zeitgemäß und den Anforderungen entsprechend gestaltet sind. Eine Migration sollte, wie bereits in der Einleitung
zu den Migrationspfaden der Dateiablage erwähnt, auch als Chance für eine Bereinigung
beziehungsweise für einen Neuanfang gesehen werden.
Solch eine Prüfung kann am Ende zu zwei unterschiedlichen Ergebnissen kommen:
1. Die Rechtestruktur bedarf einer Änderung
2. Die Rechtestruktur bedarf keiner Änderung und soll für die neue Dateiablage
übernommen werden.
Im ersten Fall sollte dann so vorgegangen werden, dass zunächst die neue Dateiablage
aufgebaut und die neue Rechtestruktur implementiert werden. Anschließend können die
Dateien der abzulösenden Dateiablage selektiv durch kopieren übernommen werden.
Hierfür stehen Werkzeuge, wie zum Beispiel das Windowsprogramm „robocopy―207 zur
Verfügung.
Im zweiten Fall kann die alte Dateiablage auf den neu aufgebauten Fileserver zum
Beispiel auch mit robocopy vollständig übernommen werden.
2.2
Von Windows Server 2000/2003 nach Linux Server (unter Beibehaltung von
Active Directory)
Bei einer Migration von Windows Server 2000/2003 nach Linux unter der Beibehaltung
von Active Directory gelten für die Migration der Daten die gleichen Anmerkungen, die in
den vorherigen Kapiteln beschrieben worden sind. Anwendungsgebiete einer solchen
Migration sind zum Beispiel die Migration von Daten von Windows File Servern auf NAS
(Network Attached Storage) oder SAN (Storage Area Network) Systeme. Diese Systeme
stellen sich nach außen als Windows File Server dar, werden aber intern oft durch
Unix/Linux Systeme verwaltet. Durch die Beibehaltung von Active Directory wird das
Netzdateisystem weiter unter Windows verwaltet, jedoch per Samba unter Linux
abgebildet beziehungsweise gespeichert. Diese Kombination von Verwaltung unter
Windows und Dateiablage unter Linux kann in bestimmten Fällen zu nicht gewünschten
Effekten führen. Einige Beispiele für diese negativen Effekte seien hier aufgeführt:

Länge von Dateinamen
In der Praxis hat sich gezeigt, dass Windows Systeme Probleme haben, Dateinamen inklusive Pfadangabe von mehr als 256 Zeichen zu interpretieren, auch
wenn laut Herstellerangaben die Pfadnamen unter NTFS unbegrenzt lang sein
können. Die Ursachen hierfür können in Programmteilen von DLLs beziehungsweise Programmteilen von Drittherstellern liegen, da dort unter Umständen eine
feste Pfadlänge programmiert wurde. Daher wird empfohlen, keine Dateinamen
inklusive Pfadlänge von mehr als 240 Zeichen zu verwenden. Linux hingegen
lässt auch längere Dateinamen zu. Wird nun vom Anwender eine Datei zum Beispiel über den NT-Explorer verschoben, so kann es dazu führen, dass die Ge-
207
robocopy ist Teil der Windows Server 2003 Resource Kit Tools
Seite 264
samtlänge der Datei incl. Pfadangabe länger als 256 Zeichen wird. Da das Filesystem unter Linux verwaltet wird, legt Linux diese Datei entsprechend ab. Es erfolgt keine Rückmeldung an den Anwender, dass die Dateilänge größer als 256
Zeichen ist. Wird nun zu einem späteren Zeitpunkt zum Beispiel bei einer Datensicherung über Windows auf diese Datei zugegriffen, kann Windows diese nicht
mehr finden. Hier muss dann die Datei vom Administrator verschoben oder kopiert werden, sodass der Dateiname incl. Pfadangabe kleiner als 256 Zeichen
wird.

Unterschiedliche Sichten für Administratoren
Dateiattribute werden unter Windows über den Explorer gesetzt und entsprechend angezeigt. Unter Linux werden diese Einstellungen nach den in
Kapitel II.E 1.1 beschriebenen Verfahren umgesetzt. Betrachtet der Administrator
die Attribute von Dateien unter Windows und unter Linux, so wird er die entsprechenden Unterschiede feststellen. Eine Überprüfung der Einstellungen, das
heißt ob die Abbildung von Windows Attributen auf Linux Attribute korrekt
durchgeführt wurde, bedarf der Interpretationsleistung des Administrators.

Vererbung von Attributen
Bei der Vererbung von Attributen und Zugriffsrechten kann es unter Umständen
zu ungewollten Vererbungen kommen. Dies ist insbesondere dann der Fall, wenn
über mehrere Unterverzeichnisse Attribute beziehungsweise Zugriffsrechte vererbt werden sollen. Speziell bei der Vererbung von Zugriffsrechten ist es immer
zu empfehlen, die korrekte Vererbung auch in tiefer liegende Unterverzeichnisse
zu überprüfen.
2.3
Von Linux NFS/OpenAFS nach Windows 2003 NTFS 5
Wird eine Migration von Linux NFS/OpenAFS nach NTFS 5 durchgeführt, dann stellen
die Abbildungen von Attributen und Zugriffsrechten keine Herausforderung für das NTFS
5 System dar. Da das NTFS 5 System über komplexere Möglichkeiten zum Anlegen von
Zugriffsrechten und Dateiattributen verfügt, können im ersten Ansatz alle Attribute und
Zugriffsrechte 1:1 übernommen werden. (Siehe hierzu die Vergleichstabellen in Kapitel
II.E 1.1) Eine Erweiterung oder der Aufbau von neuen Strukturen, z. B. der Zugriff über
verschachtelte Benutzergruppen können nach der eigentlichen Datenmigration unter
Windows durchgeführt beziehungsweise aufgebaut werden.
Die im Kapitel II.E 1.1 beschriebene Thematik der langen Dateinamen inklusive
Pfadangabe tritt bei einer Migration von Linux NFS/OpenAFS nach NTFS 5 noch stärker
auf, da hier die Datei tatsächlich im NTFS 5 System physikalisch abgelegt wird. Das
heißt, dass es hier beim Kopieren der Datei zur Verkürzung der Pfadangabe kommen
kann. Dies kann dazu führen, dass die Datei im schlimmsten Fall nicht mehr zu öffnen
ist. Auch die Empfehlung, dass der Dateiname inklusive Pfadangabe 240 Zeichen nicht
überschreiten sollte, sollte bei einer Migration berücksichtigt werden. Gegebenenfalls
müssen die Pfadnamen verkürzt werden. Eine weitere Problematik stellt die gegebenenfalls unterschiedliche Codierung von Zeichen im Dateiablagesystem dar. Linux Systeme können Dateinamen in von UTF-8 unterschiedlichen Zeichenkodierungen ablegen.
Dies ist unter Windows nicht möglich. Windows verarbeitet Dateinamen immer in UTF-8.
Seite 265
Dies kann zu unerwünschten Veränderungen bei einer Migration führen, denen durch
vorherige Dateinamenkonvertierung auf der Linux-Seite zum Beispiel mittels convmv
oder iconv entgegnet werden sollte. Außerdem ist darauf zu achten, dass die jeweilige
Dateigröße 2 TB nicht überschreitet. In engem Zusammenhang mit der Dateiablage
steht auch immer die Verbindung zur Benutzerverwaltung und zur Vergabe von
Zugriffsrechten über Benutzer und Benutzergruppen. Die Übernahme der Benutzer und
Benutzergruppen, zum Beispiel aus einem LDAP-Verzeichnis muss noch vor der Übernahme der Dateien und der Zugriffrechte geklärt und gegebenenfalls dann auch
durchgeführt werden (siehe hierzu Abschnitt Authentifizierung und Verzeichnisdienste).
Unter NFS und OpenAFS ist es durchaus üblich, dass verteilte Dateiablagen realisiert
werden. Dies kann bei einer Migration dazu führen, dass die Daten innerhalb der Netzwerkinfrastruktur von verschiedenen Systemen zusammengeführt werden müssen. Hierbei ist darauf zu achten, dass keine Daten bei der Migration verloren gehen. Gegebenenfalls ist ein Rechner, der Bestandteil dieser verteilten Infrastruktur ist, während der
Migration ausgeschaltet. Das heißt, dass nach der Migration in jedem Fall die Vollständigkeit der Daten zu überprüfen ist und sich die Verantwortlichen keinesfalls auf automatische Reports verlassen sollten. Zwar bietet Windows auch die Möglichkeit, verteilte
Dateiablagesysteme aufzubauen, diese basieren aber immer auf einem NTFS System.
Wird also eine komplette Migration von NFS /OpenAFS nach NTFS 5 durchgeführt,
müssen alle Daten auf NTFS 5 Systeme transferiert werden. Hierbei ist es unerheblich,
ob das Dateisystem unter NTFS ein verteiltes oder ein zentrales Ablagesystem ist.
2.4
Von Windows Server NT4 nach Windows Server2000/2003
Eine Datenmigration von NT4 Servern nach Windows2000/2003 Server stellt sich
einfach dar, wenn sich die entsprechenden Server in derselben Infrastruktur befinden
und sich auf den Servern NTFS Systeme mit dem gleichen Versionstand befinden.
Empfehlenswert ist, dass sich sowohl das Quellsystem als auch das Zielsystem auf dem
gleichen Versionsstand von NTFS befindet. Sollte dies nicht der Fall sein, empfiehlt sich
vorab die Hebung der Versionsstände der NTFS Systeme auf ein einheitliches Niveau.
Dies gilt auch, wenn das Windows Filesystem ein FAT System ist. In jedem Fall sollte
immer auf die aktuellste Version des NTFS Systems gewechselt werden. Wenn diese
Voraussetzungen geschaffen sind, fallen im Prinzip außer dem Kopieren von Daten
keine weiteren Tätigkeiten für die Migration an.
Befinden sich die Server nicht in der gleichen Infrastruktur, das heißt der NT4 Server
befindet sich zum Beispiel in einer Windows Domänenstruktur und der Windows 2003
Server in einer Active Directory Struktur, so kann die Migration aufwändiger werden, weil
die Zugriffsrechte nicht 1:1 übernommen werden können. In diesem Fall ergeben sich
zwei Migrationszenarien:
Seite 266

Einbindung NT Server in eine vorhandene Active Directory Infrastruktur
Bei diesem Szenario ist beziehungsweise wird der NT Server erst in die vorhandene Infrastruktur des Active Directory eingebunden, bevor die Migration der Dateiablage durchgeführt wird. Da hierbei die Zugriffsrechte entsprechend des Zielsystems angepasst werden können, kann im Anschluss die Migration durchgeführt werden.

Keine Einbindung des NT Servers in die Active Directory Infrastruktur
Soll der NT Server nicht in eine Active Directory Struktur eingebunden werden,
können die Daten zwar auch ohne Probleme übernommen werden, allerdings ist
beim Datentransfer darauf zu achten, dass sich die Zugriffsrechte nicht ungewollt
verändern.
3
Bezüge
3.1
Authentifizierungsdienst
Wenn es um die Dateiablage geht, dann geht es auch immer um die Regelung der
Zugriffsberechtigung. Es muss sichergestellt werden, dass jeder Benutzer und auch
Anwendungen und Dienste nur dort Zugriff erhalten, wo dieser für sie vorgesehen ist.
Interessant sind in diesem Zusammenhang sind die Möglichkeiten, die in Kombination
mit Samba und OpenLDAP oder einem anderen LDAP-Verzeichnisdienst innerhalb
heterogener Umgebungen (Linux- und Windows-basierte Umgebungen) bestehen.
Daher sollte bei Überlegungen zur Migration von Dateiablagediensten auch immer das
(Kapitel II.C ) berücksichtigt werden. Zunächst sind es die Technologiebetrachtungen mit
den Abschnitten

„Linux und Samba mit OpenLDAP und Kerberos (MIT/Heimdal)―, II.C 1.1

„Fedora Directory Server (OSS-Lösung mit Multimasterfähigkeit)―, II.C 1.2

„Windows NT 4 Server als sogenannter Domänencontroller (DC)―, II.C 1.3

„Windows 2000/2003 Server mit Active Directory und Kerberos―, II.C 1.4
die je nach Ausgangs- und Zielumgebung betrachtet werden sollten. Ergibt sich auch die
Notwendigkeit der Migration des Authentisierungsdienstes, dann sind die passenden
Abschnitte der Migrationspfade in Kapitel II.C 2 heranzuziehen.
Seite 267
F Thema Druckdienste
Das Thema „Drucken― wird in der IT-Welt oft vernachlässigt. Das betrifft alle Betriebssystem-Umgebungen gleichermaßen, sei es die Windows- oder die Unix-/ Linux-Welt.
Doch Druckprobleme verursachen häufig die höchsten Reibungsverluste. So wird ein
großer Teil der Administrationsaufwendungen für die Lösung alltäglicher Druckprobleme
verwendet. Darüber hinaus ist Drucken in vielen Fällen eine „mission critical―-Anwendung, deren Ausfall zu finanziellen Verlusten führen und von den Verantwortlichen
kreative Problemlösungen erfordern kann.
Ein gewisser „Wildwuchs in der Infrastruktur― hinsichtlich der Druckdienste ist weit verbreitet. „Gewachsene Strukturen― haben an vielen Stellen zu zahlreichen Unverträglichkeiten geführt: Oft herrscht ein Durcheinander von Seitenbeschreibungssprachen
(wie PostScript, PCL, PreScribe, ESC/P, PDF) vor. Die häufig „unfriedliche― Koexistenz
von Druck- und Netzwerkprotokollen (wie LPR/ LPD, HP JetDirect, SMB/ MS-RPC) sorgt
für vielerlei Probleme.
Eine Migration von Druckdiensten auf eine neue Plattform wird nicht unbedingt ein möglichst genaues 1:1-Abbild der bestehenden Verhältnisse wiedergeben können. Es sollte
jedoch als Chance wahrgenommen werden, bestehende Schwachstellen zu beheben.
In den nachfolgenden Abschnitten wird auf die Druckdienste unter Linux und Windows
näher eingegangen.
1
1.1
Allgemeine Betrachtungen
In den nachfolgenden Abschnitten erfolgt zunächst die Betrachtung von wichtigen Punkten, die für alle dann anschließend betrachteten Produkte und Technologien gleichermaßen von Bedeutung sind. Hierzu gehören die Themen Drucker- und Seitenbeschreibungssprachen, die Druckprotokolle sowie die Funktionalitäten, die von einer professionellen Druckumgebung erwartet werden dürfen.
1.1.1
Wichtige und sinnvolle Funktionalitäten und Anforderungen von und an
Druckumgebungen
Die nachfolgende Liste soll einen Eindruck darüber vermitteln, welche Anforderungen an
eine Druckerumgebung gestellt werden können, die alle in enger Verbindung zu den
benötigten Management- und Überwachungswerkzeugen stehen:
1.1.1.1
Accounting
Kostenkontrolle durch detaillierte Protokollierungsmöglichkeiten ist eine Funktion, die
insbesondere mit Blick auf eine wirtschaftliche Nutzung besonders in großen Organisationen von Bedeutung ist.
Seite 268
1.1.1.2
Quotas
Die Funktion Quotas, also der Festsetzung von quantitativen Obergrenzen für Ausdrucke, kann sinnvoll und hilfreich für die Gewährleistung der Wirtschaftlichkeit der
Druckdienste und zur Kostenkontrolle beziehungsweise –begrenzung eingesetzt werden.
1.1.1.3
Job History
Hiermit steht ein Überblick über die gesamten Druckvorgänge zur Verfügung. Am
Jahresende liegen aussagekräftige Zahlen über Gesamtmenge (Budgetplanung),
Verteilung auf Modelle und Orte (Optimierung der Ressourcenverteilung) Spitzenbelastungen (sinnvolle Neuinvestitionen) vor.
1.1.1.4
Zuverlässigkeit
Ein Mindestmaß an Ausfallsicherheit ist in der Regel eine wichtige Anforderung mit Blick
auf die Zufriedenheit der Benutzer. Ausweichmöglichkeiten sollten leicht integrierbar sein
– die Dienstbereitschaft der Printservices sollte auch ohne Anwesenheit von IT-Experten
gewährleistet sein.
1.1.1.5
Umleitung von Druckjobs
Ein Ersatzdrucker sollte problemlos angesprochen werden können, ohne den Auftrag
erneut vom Client abschicken zu müssen. (wichtig: falls der Ersatzdrucker ein anderer
Typ ist, sollte er die vorliegende Druckdatei dennoch verarbeiten können).
1.1.1.6
Erneutes Drucken
In einer Umgebung mit zentraler Vervielfältigung sind häufig Nachdrucke abgeschlossener Druckaufträge erforderlich. Um „Printing on Demand― umzusetzen und die Auflage
nachträglich zu erhöhen, oder um technische Probleme (zum Beispiel Papierstau/
Stromausfall) und Bedienerfehler (zum Beispiel falsche Papierfarbe verwendet) auszugleichen, ist eine Funktion zum erneuten Nachdrucken sinnvoll.
1.1.1.7
Drucken „auf Halten“
Zeitversetztes oder „nächtliches― Drucken (automatisch gesteuerte Batch-Jobs), ist dann
hilfreich, wenn es darum geht die Verfügbarkeit für höher priorisierte Druckaufträge zu
verbessern und die Wartezeiten für die Anwender zu reduzieren. Die ist insbesondere für
zentrale Druckdienstangebote in großen Organisationen eine wichtige Funktion.
1.1.1.8
Verschlüsselung
„Abhören― vertraulicher Daten sollte nicht möglich sein (auch nicht durch Abfangen von
Druckdateien). Dies gilt nicht nur bei der Übertragung über Organisationsgrenzen hinweg sondern auch innerhalb von Organisationen, denn nicht jeder Mitarbeiter soll auf
alle Daten Zugriff haben.
1.1.1.9
Authentisierung
Bestimmte Drucker und begrenzte „teure― Druckfunktionen (z.B. 1200 dpi im VollbildModus auf Fotopapier) sollen oft nur für bestimmte Benutzergruppen zugänglich sein,
dann ist die Möglichkeit der Authentisierung hilfreich.
Seite 269
1.1.1.10
Ohne Spezialsoftware administrieren und zur Übersicht
Idealerweise sollte die Druckinfrastruktur die Konfiguration und Kontrolle, wie zum
Beispiel den schnellen Einblick in die Warteschlangen, über Webbrowser durchgängig
unterstützen, um den schnellen und einheitlichen Zugriff, Flexibilität und Unabhängigkeit
zu schaffen.
In Abhängigkeit von den verwendeten Druckern lässt sich diese Möglichkeit umsetzen,
dies gilt vor allem für die meisten PostScript-Drucker im professionellen Umfeld. Der
Funktionsumfang dieser Browser-basierten Administrationsschnittstellen ist abhängig
von dem, welche Funktionen die einzelnen Druckertypen unterstützen. Hierbei werden
keine weiteren Werkzeuge benötigt. Es handelt sich um eine sehr flexible und portable
Methode des Druckermanagements.
Ein zusätzlicher Kommandozeilenzugang garantiert den Zugriff „von überall her― für
Administratoren.
Bezüglich der Überwachung bieten verschiedene PostScript-Drucker unter anderem die
Möglichkeit Störungs-Emails zu konfigurieren, wobei die Meldungen auch als XML-Datei
angehängt werden können und damit die Chance einer automatisierten Weiterverarbeitung bieten, um sie zum Beispiel mittels Skript auszuwerten und darauf hin bei Bedarf
weitere Maßnahmen automatisch zu initiieren (zum Beispiel bei Papierstau den Hausmeister benachrichtigen). Diese Lösungen gibt es aber auch nicht „out of the box―, sie
müssen erst definiert und dann implementiert werden. Weiterhin kann man sich mit vielen PostScript-Druckern im professionellen Bereich auch die Möglichkeiten von SNMP
zunutze machen.
Generell sollte angestrebt werden, möglichst wenige, plattformunabhägige flexible Werkzeuge in einer Gesamtlösung einzusetzen. Hierdurch werden insbesondere das Risiko
von irrtümlichen Fehlbedienungen und Schulungsaufwand und -Kosten reduziert.
Wesentlich ist, dass vor der Beschaffung von Druckern die Anforderungen hinsichtlich
der Managementmöglichkeiten genau untersucht und definiert werden sollten, um darauf
aufbauend geeignete Drucker zu beschaffen.
1.1.1.11
Integration in heterogene Welten
Eine Drucksoftware sollte multiprotokollfähig sein, denn in der Praxis kommt noch kein
allgemein verwendeter Standard zum Einsatz – Multiprotokoll-Fähigkeit muss sowohl in
Richtung Clients gegeben sein (die frei in der Wahl des Protokolls sein sollten, über das
sie ihre Druckdaten schicken wollen) als auch Richtung Zieldrucker beziehungsweise
second-level Print-Server (die oft zu „altmodisch― sind und deshalb bestimmte Konventionen verlangen). Zugleich muss eine umfassende Unterstützung des künftigen Standards IPP vorhanden sein.
Seite 270
Unterstützung etablierter 208 Standards bei Druckdaten-Übertragung
1.1.2
F
F
Die genannten funktionalen Anforderungen müssen durch die vorgeschlagenen technischen Lösungen erfüllt werden. Dabei ist vor allem eine entsprechende Offenheit durch
die Konsolidierung auf bestehenden anerkannten offenen Standards anzustreben. Zu
diesen Standards zählen zum einen die Druckprotokolle und zum anderen die Druckerund Seitenbeschreibungssprachen.
1.1.2.1
Druckprotokolle
Die für einen Übergangszeitraum noch erforderliche Unterstützung althergebrachter oder
proprietärer Protokolle (und Geräte, die darauf beruhen) sollte weiterhin gewährleistet
sein. Nachfolgend werden die wichtigsten Protokolle vorgestellt:
LPR/LPD
Das LPR/LPD Protokoll wurde im August 1990 im RFC 1179 von L. McLaughlin III im
Namen der Network Printing Working Group beschrieben. Früher wurde der Druckservice oft als zentraler Dienst eines Rechenzentrums erbracht. Bislang war es nicht
üblich, dass Netzwerkdrucker (zum Beispiel als Etagendrucker oder Abteilungsdrucker)
oder lokale Drucker in einer Organisationseinheit weit verbreitet waren. Durch die Entwicklung und des Einsatzes des LPR/LPD Protokolls war es den Systemadministratoren
möglich, Ausdrucke in betriebsschwachen Zeiten durchzuführen. Der Anwender konnte
so einen Druckjob anstoßen, ohne sich um den eigentlichen Ausdruck kümmern zu
müssen. Die im Rechenzentrum erstellten Ausdrucke wurden dann entweder verteilt
oder vom Anwender im Rechenzentrum abgeholt. In heutiger Zeit hat die Bedeutung des
zentralen Drucks in einem Rechenzentrum jedoch an Bedeutung verloren. Trotzdem ist
der Einsatz des Protokolls auf Grund der sich bietenden Möglichkeiten auch heute noch
sinnvoll, da es zum Beispiel den Administratoren Transparenz über alle Druckaufträge
innerhalb einer Organisation verschaffen kann.
Der Protokollname LPR/LPD setzt sich aus den folgenden Abkürzungen zusammen:

LPR ist die Abkürzung für Line Printer Redirector und ist unter Unix der Befehl,
um eine zu druckende Datei an einen Drucker zu senden.

LPD steht für Line Printer Daemon. Dieser Daemon nimmt über eine TCP Verbindung Befehle entgegen, um einen lokal angeschlossenen Drucker zu
steuern.
H
H
H
H
LPR/LPD, das traditionelle Protokoll zur Druckdaten-Übertragung (vom Client zum PrintServer, von Server zu Server und vom Server zum Ziel(-netzwerk)-drucker, oder auch
vom Client direkt zum Drucker), hat aber auch viele Nachteile. Es ist unverschlüsselt,
unautorisiert, wenig zuverlässig und nicht bidirektional (zum Beispiel keine Rückmeldungen vom Drucker). Ferner ist es kein „richtiger― Standard, wodurch verschiedene Implementierungen möglich sind, die aufgrund von Inkompatibilitäten mitunter zu Schwierigkeiten führen.
208
Sowohl offener als auch nicht offener Standard.
Seite 271
IPP
Internet Printing Protocol ist der Internetstandard für das Drucken sowohl im lokalen
Netz (LAN) als auch im großräumigen Netz (WAN, Internet). Das Protokoll deckt alle
denkbaren Kommunikationsmöglichkeiten ab (vom Client zum Server, vom Server zum
Server, vom Server zum Zieldrucker und auch den direkten Weg vom Client zum Zieldrucker). Die letzte und einzig verbindliche Spezifikation ist IPP-1.1. Das IPP wurde von
einer Arbeitsgruppe (der PWG 209 ), bestehend aus Vertretern von Drucker-, Betriebssystem- und Software-Herstellern aus Europa, USA und Japan entworfen und von der IETF
standardisiert. Es ist bereits in allen aktuellen Netzwerk-Druckern eingebaut. So lange
allerdings noch „alte― LPR/LPD-Modelle im Einsatz sind (die auch noch auf Jahre hin
funktionsfähig bleiben werden), wird die entsprechende Umstellung nur dort erfolgen, wo
es unmittelbar sinnvoll ist. Die Nutzung von IPP ermöglicht sowohl die Nutzung von Verschlüsselungs- als auch Authentisierungsfunktionen, zum Beispiel bei der Verwendung
unter CUPS, wie dies im Kapitel ‎II.A 1.2 dargestellt wird. IPP wird von den meisten
netzwerkfähigen Druckern unterstützt.
F
F
X
X
Socket/ AppSocket
AppSocket (oft besser bekannt als „HP JetDirect―) ist ein performantes Übertragungsprotokoll für Druckdaten. Es ist leistungsfähiger und zuverlässiger als LPR/LPD: es
beinhaltet ein gewisses Maß an bidirektionaler Kommunikation und es ist schneller.
Allerdings bietet es weder Verschlüsselung von Druckdaten noch Authentisierung von
Nutzern. Die Status-Rückmeldungen vom Drucker erfolgen in der Praxis nur vom Server
zum Drucker oder bei direktem Weg vom Client zum Drucker. Inzwischen wird das
AppSocket Protokoll auch von anderen Herstellern als HP unterstützt.
SMB/ CIFS
Windows-Clients benutzen dieses Protokoll, um an Print-Server (oder andere WindowsRechner, sofern diese „freigegebene― Drucker anbieten) Druckdaten zu übertragen. Der
Weg vom nächsten Windows-Rechner zum Ziel(-netzwerk-)drucker muss dann häufig
wieder über ein anderes Protokoll geregelt werden, es sei denn dieser ist lokal angeschlossen, zum Beispiel über Parallel-, USB-, FireWire- oder serielle Schnittstelle.
MS-RPC
Windows-Clients ab NT4 können dieses Protokoll verwenden, um Druckdaten an einen
Windows-Print-Server (ab NT4) zu übertragen. Ebenso kann eine automatische Treiberinstallation auf den Clients über RPC-Methoden erfolgen, sofern der Print-Server die
entsprechenden Dateien vorhält. (Das „Hochladen― der Treiber auf den Print-Server
durch einen Administrator von einem Client-Rechner aus, basiert ebenfalls auf RPC). Da
Samba SMB/CIFS beherrscht, kann dieses Protokoll auch für CUPS nutzbar gemacht
werden.
209
http://www.pwg.org/ipp/
Seite 272
1.1.2.2
Die Druckerbeschreibungssprache PostScript Printer Description
PostScript Printer Descriptions (PPD) sind Dateien, in welchen die speziellen Eigenschaften (Bildauflösungen, Papiergrößen und -fächer, Schriften, usw.) eines bestimmten
PostScript Druckermodells beschrieben werden können. Diese PPD-Dateien sind keine
Druckertreiber und sie werden in der Regel von den Druckerherstellern bereitgestellt. Mit
ihrer Hilfe lassen sich bei Verwendung eines einheitlichen Treibers für alle PostScriptDrucker die in der Datei beschriebenen speziellen Eigenschaften eines Druckers
ansteuern.
Die Spezifikation der Druckerbeschreibungssprache PPD wurde ursprünglich von der
Firma Adobe definiert und wird heute von nahezu jedem modernen Drucksystem unterstützt, welches PostScript-Drucker ansteuert kann.
1.1.2.3
Die Seitenbeschreibungssprachen (PostScript)
Die Seitenbeschreibungssprache PostScript (PS) ist eine Programmiersprache, die auf
eine langjährige Entwicklung zurückblickt. Entwickelt wird PostScript durch die Firma
Adobe seit ihrer Gründung im Jahre 1982 210 als Ergebnis der Erfahrungen mit den
Quasi-Vorgängern, Design System (1976) und JaM (1978). 211 Mit PostScript besteht die
Möglichkeit in normierter Form und geräteunabhängig Grafiken, Schriften, geometrische
Objekte und Rasterbilder innerhalb eines Dokuments anzuordnen. Die Beschreibung
erfolgt dabei im PostScript-Format innerhalb sogenannten PostScript-Dateien, die an
den jeweiligen PostScript-Drucker oder andere PostScript-fähige Ausgabegeräte, wie
zum Beispiel Plotter, gesendet werden. PostScript-fähige Ausgabegeräte zeichnen sich
vor allem dadurch aus, dass sie in der Lage sind diese Dateien, das heißt das PostScript-Format zu interpretieren und in Rastergrafiken umzusetzen. Dafür sind diese
Geräte mit einem entsprechenden Interpreter ausgestattet. Es gibt solche Interpreter
auch reine Software-Implementierung, eine der wohl bekanntesten ist die Open Source
Software Ghostscript 212 .
F
F
F
F
1.2
F
F
Common Unix Printing System (CUPS)
Das Common Unix Printing System (CUPS) wurde von Easy Software Products entwickelt. Es wurde als Nachfolger von älteren Drucksystemen, zum Beispiel LPD entworfen. Am 11. Juli 2007 gab Apple bekannt, die Rechte an CUPS gekauft zu haben.
Seit MAC OS 10.2 (Tiger) hat Apple CUPS integriert. Die aktuelle Version von MAC OS
ist die Version 10.5 (Leopard). Aktuell 213 ist CUPS in der Version 1.3.6 verfügbar. Und
die Version 1.4 befindet sich in der Entwicklung.
F
F
CUPS ist ein modulares, auf einer Client/Server-Architektur aufbauendes Drucksystem
für Unix-artige Betriebssysteme. Es besteht aus einem Printspooler, einem Scheduler
und einem Filtersystem, welches die Druckdaten in ein für den Drucker verständliches
Format konvertiert, sowie einem Backendsystem, welches diese Daten zum Drucker
sendet. Damit erlaubt es CUPS einem Computer als Druckserver zu agieren.
210
211
212
Manche Quellen erwähnen auch 1983 oder 1984 als Beginn der Entwicklung.
http://www.mathematik.uni-ulm.de/help/pstut/01_inh.html
http://www.cs.wisc.edu/~ghost
10. März 2008
H
213
Seite 273
Der wesentliche Vorteil von CUPS ist, dass es ein standardisiertes und modularisiertes
Drucksystem ist. Darüber hinaus ist CUPS eine Open Source Software und steht sowohl
unter der GNU General Public License als auch der GNU Lesser General Public License
(Version 2) zur Verfügung.
In der aktuellen Version bietet CUPS auch die Unterstützung des IPv6 Standards und
die Freigabe von Druckern über LDAP in der Version 3.
In der folgenden Auflistung werden die potentiellen Architekturmöglichkeiten beim Einsatz von CUPS skizziert, wobei die Erhöhung der Ausfallsicherheit für viele Einsatzszenarien von entscheidender Bedeutung ist:
1.2.1
Server
Jeder CUPS-Rechner, der direkt mit einem Drucker kommuniziert, kann die Druckfunktion anderen Rechnern als Dienst anbieten und fungiert somit als CUPS-Server. Voraussetzung dafür sind die entsprechenden PPDs und Filter für die druckgerechte Aufbereitung der Druckdateien.
1.2.2
Client
Jeder Rechner, der Druckdateien an einen Server weiterschickt, ist ein CUPS-Client. Ein
Client benötigt lokal keine Filter oder PPDs. Wenn jedoch auf dem Client festgelegt werden soll, welche Druckmöglichkeiten beim Drucken bestehen, werden die PPDs vom
Server automatisch auf den Client übertragen.
1.2.3
Zero-Administration für native CUPS Clients
CUPS-Server verbreiten innerhalb des Netzwerkes Informationen über die installierten
Drucker an die Clients. Damit wissen die Clients, welche Drucker im Netzwerk
verwendet werden können. Die Informationen werden mittels UDP-Broadcasting
publiziert. Alternativ kann der Client gezielt die Informationen bei den Servern
nachfragen (Polling). Das Polling kann auch gezielt bei Servern eingesetzt werden, die
durch Router getrennt sind. Server, die in unterschiedlichen Netzen stehen, können als
BrowseRelay konfiguriert werden und die Daten über die verfügbaren Drucker abholen
und an die Clients der eigenen Broadcast-Domäne weiterleiten.
1.2.4
Clustering für Ausfallsicherheit und Failover
Zwei oder mehrere CUPS-Server können so konfiguriert werden, dass Ausfallsicherheit
bezüglich der Druckdienste implementiert werden kann. Dieses Ziel kann erreicht
werden, wenn die Server mit denselben Druckern und Druckernamen konfiguriert
werden. Auf den CUPS-Servern werden automatisch implizite Klassen gebildet, die aus
den Druckern mit demselben Namen bestehen. Der Server, der zuerst bereit ist,
übernimmt dann den Druckauftrag des Clients und schickt ihn an den Drucker. Diese
Konfiguration kann auch durch die manuelle Bildung von Klassen hergestellt werden,
wobei diese Klassen auch aus Druckern mit unterschiedlichen Namen bestehen können.
Seite 274
1.2.5
Druck und Druckeransteuerung
Die Funktionalität von CUPS ist durch die Implementierung von IPP plattformübergreifend angelegt. Das IPP wird als Protokoll zwischen den CUPS-Servern, -Clients und
modernen Druckern mit direkter IPP-Unterstützung als Medium der Kommunikation- und
Datenübertragung verwendet.
Unter Verwendung von IPP kann unter CUPS die Kommunikation zwischen Client- und
dem Serversystem in verschlüsselter Form erfolgen. Für die Übertragung der Daten
kann SSL 3 oder TLS genutzt werden. Dies kann in Firmen und Behörden, wo vertrauliche Dokumente ausgedruckt werden, von besonderer Bedeutung sein. Durch diese
Maßnahmen ist die eigentliche Kommunikation verschlüsselt. Bisher kann CUPS Zertifikate nicht validieren oder Certification Revocation Lists (Zertifikatssperrlisten) prüfen.
Nach einer erfolgreichen „Man in the middle― Attacke und dem Vorzeigen eines beliebigen Zertifikats bietet TLS keinen Schutz mehr. Die Fähigkeit Zertifikate zu prüfen ist aber
einfach nachzurüsten.
Bei der Kommunikation mit herkömmlichen Druckern oder Print-Servern können CUPSModule, sogenannte „BackEnds―, eingesetzt werden Diese Module ermöglichen die
Kommunikation mittels anderer Protokolle. In Abbildung 29 wird die Verwendung der
Protokolle an den jeweiligen Übergängen dargestellt.
X
Abbildung 29: Drucken unter CUPS
214
F
Für die Druckeransteuerung verwendet CUPS die in Abschnitt II.F 1.1.2.2 beschriebene
PostScript Printer Descriptions (PPD) und dies nicht nur für PostScript-fähige Drucker.
X
214
H
http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/
Seite 275
H
CUPS ist in der Lage diese auch für Drucker ohne eigenen eigenen PostScriptInterpreter einzusetzen, um damit die entsprechenden Konfigurationseinstellungen über
das Web-Frontend oder über die Konfigurationsmasken der Clients zu ermöglichen.
Für Drucker, die nicht PostScript-fähig sind, konvertiert der CUPS-Server dann die vom
Client gelieferten Daten über entsprechende Filter in die jeweilige hersteller- und gerätespezifische Seitenbeschreibungssprache.
Solche Filter zur Konvertierung von PostScript werden unter Linux u.a. auch mit
Ghostscript umfangreich zur Verfügung gestellt. CUPS selbst integriert eine angepasste
Version von Ghostscript.
Für die Verwendung in CUPS können die PPD-Dateien benutzerund anwendungsspezifisch angepasst werden. Informationen über eigene CUPS Erweiterungen zu
Adobes PPD können im Internet nachgeschlagen werden 215 .
F
1.2.5.1
F
Direkter Druck vom Arbeitsplatzsystem
Ein direkter Druck von einem Client auf einen Drucker ist unter CUPS auf Grund der
Architektur nicht vorgesehen. Es besteht aber die Möglichkeit einen CUPS-Server und
einen Client gleichzeitig auf einem Unix-basierten (z.B. Linux oder Mac OS X) Arbeitsplatzrechner zu nutzen. Damit können dann Dateien vom Client aus auf einem direkt
angeschlossenen Drucker ausgedruckt werden.
1.2.5.2
Druck via Print-Server
Der Druckauftrag eines Client wird an einen Scheduler 216 gesendet, der die zu druckenden Daten mittels Filter in das PostScript -Format konvertiert. Anschließend werden
diese Daten zum einem „Backend― gesendet, welches die Daten entweder auf dem
entsprechenden Drucker druckt (und die PostScript-Daten dafür umwandelt, wenn der
Drucker kein PostScript-Drucker ist) oder übermittelt sie an einen anderen CUPS-Server.
H
H
HF
F
H
Solange CUPS ohne Samba eingesetzt wird bestehen für Windows-basierte Clients nur
eingeschränkte Möglichkeiten über CUPS alleine drucken zu können, da sie nicht auf die
Druckerfreigabe zugreifen können. Da über eine entsprechende CUPS SoftwareBibliothek eine optimale Integration von CUPS in Samba verfügbar ist (siehe auch
Abschnitt ‎II.A 1.3 ), kann ein Samba-Print-Server seine ankommenden Druckaufträge
(von Windows-basierten Clients) per IPP an einen CUPS-Print-Server weiterleiten. Das
Ganze erfolgt für die Anwender völlig transparent.
X
X
Bei einem Einsatz von Windows 2000 (Workstation und Server) oder höheren Versionen
von Windows ist ein Drucken über CUPS ohne Samba möglich, wenn das IPP Protokoll
genutzt wird. IPP wird, wie bereits weiter oben erwähnt, von den meisten netzwerkfähigen Druckern unterstützt.
Um die volle Funktionalität von CUPS nutzen zu können kann es notwendig sein einen
Hotfix von Microsoft einzuspielen 217 .
F
215
F
http://www.cups.org/documentation.php/spec-ppd.html
Ein Steuerungsprogramm welches die zeitliche Ausführung mehrerer (Druck)Prozesse
regelt.
http://support.microsoft.com/kb/884897/de
H
216
217
H
Seite 276
1.2.6
Technische Umsetzung der Treiberfunktion
Der folgende Abschnitt bezieht sich auf die Kommunikation mit Druckern, die kein PostScript unterstützen. Bei Druckern, die PostScript unterstützen, werden die Daten im
PostScript-Format direkt an den Drucker gesendet, der dann die Aufbereitung der Daten
mittels integriertem Interpreter zum Ausdruck selbst vornimmt.
Die Umsetzung der Druckdatei in druckergerechte Bitmaps kann bei Druckern, die keine
PostScript-Drucker sind, über zwei unterschiedliche Modelle realisiert werden:

Die komplett clientseitige Ausführung der Treiberfunktionen
Hierbei wird die Druckdatei auf dem Client druckfertig aufbereitet. Der PrintServer hat reine Spooling-Funktionen für „raw― Druckdaten. Treiber können dem
Client zum Download und zur automatischen Installation angeboten werden.

Die Druckdaten-Aufbereitung erfolgt auf dem Print-Server
Hierbei werden die Druckdaten von den Clients im PostScript-Format an den
Print-Server gesendet. Auf den Clients wird hierzu ein entsprechender PostScript-Treiber benötigt, der vom Server zur automatischen Installation angeboten
werden kann. Die aufbereiteten Druck-Daten werden vom Server an den gewünschten Drucker weitergeleitet. Sofern es sich um einen Nicht-PostScriptDrucker handelt, erfolgt die Druckaufbereitung mittels spezieller Software (siehe.
Abschnitt II.F 1.1.2.3).
Das zweite Modell, das heißt die Aufbereitung der Druckdaten auf dem Printserver, bietet gegenüber dem ersten Modell mehrere Vorteile:

Es unterstützt zusätzlich die meisten gängigen Nicht-PostScript-Drucker (abhängig von der Unterstützung durch Ghostscript oder andere Treiberpakete).

Automatisches Accounting
Über jede Seite werden Druckzeit, Auflage, Zieldrucker, Druck-ID, Anwendername, und Absender-IP automatisch mitgeloggt und stehen für spätere Auswertungen (Kostenkontrolle, Statistiken) zur Verfügung.

Quotierungsoption
Druck-Quotas (nach Anzahl der Seiten und/oder Größe der Druckdaten-Menge)
können den Nutzern pro Drucker zugeordnet werden.

Reprint-Funktion
Aufträge können über einen gewissen Zeitraum aufbewahrt und zur Verfügung
gestellt werden, wenn ein Neu- oder Nachdruck erforderlich sein sollte (ohne
dass der Client die Datei nochmals suchen, öffnen und abschicken muss).

Redirect-Funktion
Druckdateien können jederzeit auf einen anderen Zieldrucker umgeleitet werden,
selbst dann, wenn der ursprüngliche Drucker ein PostScript-Modell war und der
neue Drucker ein nicht-PostScript-Gerät ist. Druckoptionen können modellgerecht auf das neue Zielgerät angepasst werden.

Treiber-Konsolidierung
Bei nicht PostScript Druckern nutzen alle Clients im Endeffekt denselben CorePostScript-Treiber, der nur durch eine ASCII-Datei, die „PPD―, modifiziert wird.
Seite 277
Demgegenüber stehen jedoch folgende Einschränkungen:

Erhöhter Ressourcenbedarf
Die zentrale Druckdatenaufbereitung auf dem Server erfordert mehr RAM, CPU
und HD-Platz. Dieser kann jedoch zuverlässig im Voraus ermittelt werden, wenn
das erwartete Druckaufkommen bekannt ist. Bei Druckern die PostScript-Daten
verwenden können, wird die PostScript-Datei einmalig erzeugt und dann weitergeleitet.

Eventuell leichte Einschränkungen bei älteren Druckermodellen
Zwar wird die Mehrzahl der gängigen Druckermodelle unterstützt – allerdings gibt
es, einige wenige ältere Geräte, vor allem im Heimanwenderbereich, bei welchen
dies nicht der Fall ist. Eine Liste der unterstützten Hersteller und Modelle kann
der „Linuxpriniting.org―-Datenbank 218 entnommen werden. Gegebenenfalls kann
man für PostScript-fähige Drucker beim Hersteller einen Treiber für Mac OS 9
oder Mac OS X laden und dann die PPD extrahieren.
F
1.2.7
F
Filter
CUPS verwendet intern ein modular aufgebautes Filtersystem. Es setzt auf offenen
Schnittstellen auf und kann jederzeit erweitert werden. Dabei können beliebige
Scriptsprachen (Shell, Perl, Python) oder Programmiersprachen (C, C++, Java etc.) zum
Einsatz kommen. Die Einbindung proprietärer Binär-Programme ist über WrapperSkripte auf einfache Weise möglich.
1.2.8
BackEnds
Neue BackEnds sind leicht „andockbar―; sei es zur umgebungsspezifischen Anpassung
an spezielle Anforderungen (zum Beispiel automatische Replikation bestimmter Druckaufträge in einer woanders lokalisierten Abteilung, zum Beispiel zwecks Ablage von
Geschäftsbriefen im Archiv) oder weil technologische Neuerungen dieses Vorgehen
attraktiv machen (Wireless LAN, Bluetooth, FireWire).
1.2.9
Zugriffssteuerung
Die Zugriffssteuerung für die von Print-Servern betriebenen Netzwerkdrucker wird vom
CUPS Print-Server geregelt, sofern diese nicht über einen Verzeichnisdienst gesteuert
wird. Dabei unterstützt CUPS auch die Authentifizierung auf Basis des KerberosProtokolls 219 .
F
218
219
F
http://www.linuxprinting.org/show_driver.cgi?driver=hpijs
http://www.cups.org/documentation.php/kerberos.html
Seite 278
1.2.10
Werkzeuge
CUPS hat ein „eingebautes― Web-Interface, das über die URL „http://CUPSDRUCKSERVER:631/― erreichbar ist. Es ermöglicht den informativen Zugang aller
Nutzer zu den Funktionen des Print-Servers. Benutzer können in Abhängigkeit von der
Konfiguration den Status von Druckaufträgen überwachen sowie Druckaufträge
abbrechen, neu starten oder alte Aufträge nachdrucken und so weiter.
Über das Web-Interface kann man Drucker(-Warteschlangen) neu anlegen, löschen,
umkonfigurieren, starten, stoppen, schließen oder öffnen sowie Druckaufträge stornieren, diese auf Halde legen oder neu starten. Die Möglichkeiten zur Verwendung des
Web-Interface können durch Konfiguration des CUPS-Servers eingeschränkt beziehungsweise erweitert werden. Das Web-Interface unterliegt denselben Zugangskontrollen wie die allgemeinen CUPS-Ressourcen. Jedes Objekt des Print-Servers (Zugriff auf eigene Jobs oder einzelne Drucker, Zugriff auf alle Drucker oder alle Jobs usw.)
lässt sich mit differenzierten Zugriffsrechten versehen: zum Beispiel „User Müller darf
administrieren, aber nur wenn er von Rechner A oder B zugreift―, oder „Alle User dürfen
eigene Druckjobs löschen, aber keine fremden―.
In Abhängigkeit der vom Drucker unterstützten Protokolle und den auf dem CUPS Server installierten Druckertreibern ist eine Überwachung der Drucker möglich. Hierunter
wird verstanden, dass das CUPS System u.a. folgende Warnungen der Drucker erkennt
und meldet:

Füllstandsanzeige der Papierschächte

Füllstandsanzeige von Toner / Tintenpatronen

Fehlermeldungen der Drucker (zum Beispiel Papierstau)

Status des Druckers (zum Beispiel Online, Offline)
Die Ursachen für die oben genannten Warnmeldungen lassen sich in den meisten Fällen
nur direkt am Drucker beheben.
Darüber hinaus stehen unabhängig davon die „eingebauten― Werkzeuge professioneller
Drucker zur Verfügung, wie sie im Abschnitt II.F 1.1.1.10 angesprochen werden.
X
1.2.11
X
Schnittstellen
Sobald ein System TCP/IP unterstützt, bildet CUPS eine vielseitige Schnittstelle für
Druckdienste zu allen gängigen Druckern und Clientsystemen. Dadurch lassen sich heterogene und sehr flexible Drucknetzwerke aufbauen, die auch eine gewisse Zukunftssicherheit bieten, solange das TCP/IP Protokoll genutzt wird. Drucker, die kein TCP/IP
unterstützen können mit CUPS nicht direkt angesprochen werden. Bei Bedarf kann dies
jedoch über entsprechende Druckerboxen realisiert werden. Beim Einsatz von CUPS
kann auch nach Druckern „gebrowst― werden. Diese Kommunikation findet über das
UDP Protokoll (Port631) statt.
Es ist darauf zu achten, dass die Kommunikation mit dem CUPS Server entweder über
die IP Adresse oder den vollqualifizierten Domainnamen des Servers erfolgt. Windows
Clients können in einer reinen CUPS Umgebung nicht über Druckerfreigaben kommunizieren.
Seite 279
1.2.12
Fazit
Unter Linux ist CUPS der de-facto Standard aller großen Distributionen (Suse, Debian,
RedHat, usw.). CUPS ist das System der Wahl, sowohl in homogenen LinuxSystemlandschaften als auch in heterogenen Systemlandschaften mit windowsbasierten
Clientsystemen.
Die Funktionalität von CUPS ist durch die Implementierung von IPP (Internet Printing
Protocol) plattformübergreifend angelegt. CUPS unterstützt aber auch alle weiteren relevanten Druckprotokolle wie LPR/LPD, Socket/AppSocket, SMB/CIFS und MS-RPC (in
Kombination mit Samba).
Darüber hinaus bietet CUPS verschiedene Möglichkeiten, Datensicherheit auch beim
Drucken zu gewährleisten. Hierzu gehören die SSL-verschlüsselte Übertragung bei IPPVerwendung oder auch die Benutzer-Authentifizierung im Zusammenspiel mit Samba
oder Kerberos. Dies hat auch im Hinblick auf das Accounting von Druckerzugängen
große Vorteile.
Im Vorfeld einer Migration sollte in jedem Fall die Unterstützung der eingesetzten
Druckermodelle überprüft werden. Dies gilt insbesondere, wenn die Druckaufbereitung
komplett auf den Print-Servern erfolgen soll, da in wenigen, vereinzelten Fällen eine
Unterstützung nicht gegeben sein könnte.
1.3
Common Unix Printing System (CUPS) mit Samba
CUPS lässt sich aufgrund der Tatsache, dass seine Funktionen in einer Library (Software-Bibliothek) implementiert wurden, sehr gut integrieren. Dadurch können andere
Programme seine Funktionen nutzen, indem sie gegen diese Bibliothek „linken―. Samba
macht davon Gebrauch. Per Default ist Samba gegen libcups.so gelinkt. Ein SambaPrint-Server kann dadurch seine ankommenden Druckaufträge per IPP an CUPS-PrintServer weiterleiten. Diese CUPS Print-Server können auf anderen, für den Druckdienst
dezidierten Hosts installiert sein oder auf demselben wie Samba. Die Verwendung von
IPP geschieht hierbei transparent für den Administrator oder Nutzer und erfordert keine
weitere Konfiguration.
1.3.1
1.3.1.1
Möglichkeiten des Zusammenspiels von SAMBA und CUPS
Treiber-Download & -Installation durch Clients mit „Point & Print“
Die CUPS/Samba-Kombination unterstützt den automatisierten Treiber-Download zu
Windows-Clients mittels „Point and Print―. Samba muss hierfür so konfiguriert sein, dass
es einen NT-Print-Server nachbildet. Die Konfiguration ist in der Samba HOWTO Collection detailliert beschrieben und kann leicht realisiert werden. Auch das Hochladen von
Treibern durch einen Administrator von einer Client-Maschine aus wird unterstützt.
Die Druckertreiber liegen hierbei auf dem Samba-Server. Sie werden automatisch im
Hintergrund auf den Windows Client-Systemen installiert, sobald der Nutzer erstmals
den Drucker in der Netzwerkumgebung sucht oder erkennt und (per „Rechts-Mausklick―)
im Kontext-Menü „Verbinden...― auswählt.
Seite 280
1.3.1.2
Automatische Treiberinstallation per Logon-Scripts
Noch komfortabler wird es für Benutzer und Administratoren innerhalb einer Domäne,
wenn „Logon-Scripts― eingesetzt werden. In diesem Logon-Script muss nur die Zeile
„rundll32 printui.dll,PrintUIEntry /in /n„\\SAMBASERVERNAME\druckerfreigabename―
vorkommen. Hierdurch wird der entsprechende Drucker automatisch für den sich einloggenden Benutzer installiert (weitere diesbezügliche Möglichkeiten sind die Installation
mehrerer Drucker, die Setzung eines Standard-Druckers, die Löschung hinfällig gewordener Druckerwarteschlangen usw.). Die vorgenannte Möglichkeit offeriert eine komfortable Administration der Druckertreiber und eine Verringerung der Aufwände für die Administratoren. Verschiedene Benutzer-Gruppen können über verschiedene LogonScripts verschieden angepasste Umgebungen erhalten.
1.3.2
Sicherheit und Authentisierung
Die Kommunikation zwischen dem Client- und Serversystem kann auch hier in verschlüsselter Form erfolgen, sofern IPP verwendet wird.
Windows-Clients authentisieren sich typischerweise nicht bei CUPS, sondern bei Samba. Diese Authentisierung wird automatisch genutzt, wenn über Samba gedruckt wird.
Die Rechteverwaltung wird dabei von Samba übernommen. Es ist dann lediglich auf
geeignete Weise sicherzustellen, dass der Samba-Server zur Benutzung des CUPSPrint-Servers autorisiert ist. Hierbei ist zu beachten, dass ohne den Einsatz von IPP
keine Verschlüsselung auf dem gesamten Kommunikationsweg vom Client zum Drucker
gewährleistet wird. Dies ist in Bereichen mit einem hohen Sicherheitsbedürfnis nicht
akzeptabel. Daher ist in solchen Bereichen vom Einsatz vom SMB/RPC Protokoll abzusehen, da diese keine Verschlüsselung gewährleisten.
1.3.3
Publikation von CUPS-Druckern in LDAP und Active Directory
Samba kann seine Dienste in einem LDAP- oder Active Directory-Verzeichnis eintragen.
Davon profitieren selbstverständlich auch CUPS-Drucker und CUPS-Print-Server.
Weitere Ausbaustufen der Integration in eine AD- (oder in eine diese weitgehend nachbildende LDAP-) Umgebung sind möglich.
1.3.4
Fazit
Die Kombination von CUPS und SAMBA stellt für Windows Clients eine leistungsfähige
Printserverarchitektur zur Verfügung. Durch die Nutzung von sogenannten PPD-Dateien
(PostScript Printer Discription Datei), die auch von Windows verwendet werden können,
ist es möglich, dass alle Druckclients unabhängig von Ihrer Einstellung gleiche Ausdrucke erzeugen.
Auch unterschiedliche Druckertreiber auf den Clients spielen keine Rolle, da unter CUPS
der Ausdruck erst auf dem Server aufbereitet und dadurch immer der gleiche Druckertreiber genutzt wird. Dies ist so unter Windows nicht möglich, da immer ein Teil der
Druckaufbereitung auf dem Windows Client stattfindet und somit von dem auf dem Client
installierten Drucktreiber abhängig ist.
Seite 281
CUPS ohne Samba kann zwar auch mit Windows Clients kommunizieren, doch die
Clients können das SMB Protokoll nicht nutzen und die Druckerfreigaben sind nicht im
Windows Explorer sichtbar.
1.4
Windows Print Services
Die in Kapitel II.F 1.1.2.1 beschriebene und aus dem Unix-und Mainframebereich bekannte und allgemeingültige LPR/LPD Protokoll hat mit Windows NT und den Nachfolgeversionen Einzug in die Windows Welt gefunden. Es wird auf Windows Print-Servern
als Standard zur Kommunikation zwischen Server und Druckergerät verwendet.
X
X
Eigenschaften des LPR/LPD Protokolls treffen auch bei der Verwendung unter Windows
zu und stellen daher keinen Unterschied zu den im Unix-Bereich vorhandenen Umsetzungen des Protokolls dar.
Die Kommunikation zwischen einem Windows Rechner und einem Drucker wird über
einen sogenannten LPR-Port realisiert, der unter Windows eingerichtet wird und der über
das LPD Protokoll angesprochen wird. Die Kommunikation erfolgt dabei ausschließlich
über TCP/IP.
Über das LPD/LPR Protokoll können dann von einem Client aus sowohl Print-Server, als
auch Drucker direkt angesprochen werden, sofern diese mit dem Netzwerk verbunden
oder direkt an dem Client angeschlossen sind.
Darüber hinaus können auch andere Protokolle, wie zum Beispiel JetDirect/Appsocket
genutzt werden, um Drucker anzusteuern.
Seit Windows 2000 besteht auch die Möglichkeit über IPP (siehe Abschnitt II.F 1.1.2.1 )
zu drucken, sofern der jeweilige Drucker das Protokoll unterstützt. Damit besteht auch
die Möglichkeit quasi „ganz natürlich― über CUPS-Server drucken. Allerdings wird derzeit
durch Microsoft nur eine Implementierung der IPP-Version 1.0 angeboten, die bei der
IETF nie „recommended standard― wurde, sondern nur einen Diskussions-Zwischenstand widerspiegelte und zum Beispiel den wichtigen Aspekt der Verschlüsselung von
Druckdaten und der Authentisierung von Benutzern noch nicht definiert hatte. Somit
muss ein CUPS-Server auf Authentisierung verzichten, will man ihn direkt vom Windows-Client aus nutzen.
X
Die Verbindung zwischen einem Windows-Client und einem Print-Server wird typischerweise über SMB (Server Message Block) oder RPC (Remote Procedure Call) unter Windows hergestellt. RPC-Verbindungen werden dabei bevorzugt, da sie die Funktionen der
Point & Print-Methode (siehe Abschnitt II.F 1.4.3 ) unterstützen. SMB wird dagegen eher
für die Verbindung von Clients mit älteren Windows Betriebssystemen (Windows 98 und
früher) verwendet 220 . Die Kommunikation zwischen Clients und Print-Server kann dabei
auf verschiedenen Transportprotokollen basieren, wie zum Beispiel:
X
F
220
F
siehe auch „Microsoft Windows 2003, Printer Connectivity Technical Overview―, Microsoft
Corporation, Published: March 2003,
http://www.microsoft.com/windowsserver2003/techinfo/overview/connectivity.mspx
Seite 282

TCP/IP

NetBEUI

SPX/IPX
Mit Windows Server 2000/2003 werden folgende weitere Funktionalitäten der Windows
Druckdienste bereitgestellt:

Standard TCP/IP Port Monitor (SPM)
SPM ist kompatibel mit SNMP und liefert im Vergleich zu LPR die Möglichkeit,
detaillierte Statusinformationen abzurufen.
SPM kann sowohl das Druckerserverprotokoll RAW als auch LPR verwenden.
Standard für die meisten Druckgeräte ist RAW.

Internet Printing
Wie bereits erwähnt besteht seit Windows Server 2000 die Option, Drucker im
Web zu veröffentlichen und die Installation zu ermöglichen sowie über IPP zu
drucken 221 .
F

F
Veröffentlichung im Active Directory (AD)
Mit Hilfe des AD kann die Druckerfreigabe auf Windows Servern (NT/2000/2003)
veröffentlicht werden, ohne dass der Anwender wissen muss, auf welchem Server sich die Druckerfreigabe befindet.

Gemischte Umgebungen
Auf Windows 2000/2003 Servern können Treiber für Windows NT Clients hinterlegt werden. Die Übertragung der gerätespezifischen Einstellungen kann allerdings scheitern, wenn herstellerspezifische Treiber eingesetzt werden (müssen).
Ursache hierfür ist die Verlagerung der Druckertreiber vom Kernel Mode unter NT
in den User Mode unter Windows 2000/2003.
1.4.1
Direkter Druck vom Arbeitsplatzsystem
Der direkte Druck (siehe Abbildung 30 , Pfeil 1) erfolgt über LPR/LPD. Zu diesem Zweck
muss auf dem Arbeitsplatzsystem unter Windows der TCP/IP Print-Server installiert
sein 222 . Auf dem Arbeitsplatzsystem wird ein sogenannter LPR-Port als Anschluss konfiguriert. Zu diesem Zweck muss die IP-Adresse oder ein entsprechender vollqualifizierter
Hostname des Zieldruckers eingetragen werden. Zudem erfolgt die Aufforderung, ein
Druckermodell und somit den entsprechenden Druckertreiber auszuwählen. Hierbei wird
dann der ausgewählte Druckertreiber auf dem Client installiert. Diese Methode wird häufig verwendet, wenn die Benutzer zwischen vielen Standorten einer Organisation wechseln und keine Verwaltung der Netzwerkressourcen zum Beispiel über einen Verzeichnisdienst genutzt wird.
X
F
221
222
F
siehe auch „Microsoft Windows 2003, Printer Connectivity Technical Overview―, Microsoft
Corporation, Published: March 2003,
http://www.microsoft.com/windowsserver2003/techinfo/overview/connectivity.mspx
Windows 9x Systeme müssen hierfür eine Software von Drittherstellern verwenden.
Seite 283
Voraussetzung für diese Methode ist, dass der entsprechende Drucker entweder mit
einer Netzwerkkarte und IP Adresse oder über einen Print-Server an das Netzwerk angebunden ist. Beim Einsatz eines Print-Servers wird am Client die IP Adresse oder der
vollqualifizierte Name des Servers eingetragen. Die Kommunikation zwischen dem PrintServer und dem Drucker erfolgt in der Regel über einen parallelen, seriellen oder USB
Port. Ist ein Drucker direkt an einen Client oder über eine Printbox angebunden, kann
der Client die Funktion eines Print-Servers, der die Druckaufträge dann direkt an den
Drucker versendet, übernehmen. Eine Anbindung an einen Standort-Print-Server kann
somit entfallen.
1.4.2
Druck via Print-Server
Unter Print-Server wird in diesem Abschnitt ein Windows Server (NT und folgende) verstanden, auf dem die Druckertreiber installiert sind. Dieser Server nimmt Druckaufträge
entgegen und verteilt diese an die entsprechenden Drucker. Der Drucker kann sowohl
über das Netzwerk mit dem Server kommunizieren oder auch als lokaler Drucker direkt
mit dem Server verbunden sein.
Der Druck vom Arbeitsplatzsystem über einen Print-Server erfordert zwei Datenströme:

die Übertragung der Daten vom Arbeitsplatzsystem zum Print-Server
(siehe Abbildung 30 , Pfeil 2a)
X

die Übertragung der Daten vom Server zum Druckgerät
(siehe Abbildung 30 , Pfeil 2b)
X
Die Übertragung der Daten vom Server zum Druckgerät basiert in der Regel auf
LPR/LPD (siehe Abschnitt II.F 1.4.1).
Die Übertragung der Daten zwischen Arbeitsplatzsystem und Print-Server kann auf unterschiedliche Weise erfolgen. Serverseitig müssen hierfür zwei grundlegende Voraussetzungen erfüllt sein, damit ein Client einen bestimmten Drucker über den Server ansprechen kann:
1.
Der Drucker ist auf dem Print-Server eingerichtet (LPR-Port oder lokaler Anschluss, Druckertreiber).
2.
Der Drucker ist freigegeben.
Die Freigabe ermöglicht in Windows Netzwerken unter anderem, dass der Drucker über
die Suchfunktion des Windows Explorers oder über die Suchfunktion des Active
Directory gefunden werden kann.
Die Kommunikation zwischen Windows-Client und Print-Server (Druckerfreigabe) kann
auf drei verschiedenen Wegen erfolgen:

Mittels des Befehls NET USE kann ein bestehender lokaler LPT-Port auf die
Druckerfreigabe umgeleitet werden (Beispiel: net use LPT3 \\servername\
druckerfreigabename).
H
H
Diese Methode erfordert, dass der Anwender einen Drucker (Druckertreiber) auf
dem LPT-Port installiert und lokal konfiguriert. Dies ist erforderlich, wenn aus
DOS-Anwendungen heraus gedruckt werden muss. Die Druckdaten werden im
RAW-Format gesendet. Das heißt, dass die gesendeten Daten unmittelbar vom
Seite 284
Druckgerät verwertet werden können. Diese Methode wird häufig von Windows
9x Systemen verwendet, wenn diese nicht über andere Funktionalitäten (zum
Beispiel Novell Netware) auf die Netzwerkdrucker zugreifen können.

Es kann ein neuer LPR-Port eingerichtet werden, der als Zieladresse den PrintServer und den Namen der Druckerfreigabe beinhaltet. Die Druckdaten werden
ebenfalls im RAW-Format gesendet.

Mittels der sogenannten „Point & Print―-Methode kann auf dem Arbeitsplatzsystem ein Netzwerkdrucker eingerichtet werden. Vorteil dieser Methode ist, dass
eine manuelle Konfiguration oder Druckertreiberinstallation für den Anwender
entfällt. Die Druckdaten werden im EMF-Format (Enhanced Meta Format) gesendet. Sie können vom Druckgerät nicht verwertet werden, sondern müssen auf
dem Windows-Print-Server aufbereitet werden. Die „Point & Print―-Methode wird
im folgenden Abschnitt genauer beschrieben.
Abbildung 30: Allgemein: Drucken unter Windows
Bei den bisher vorgestellten Methoden wird immer davon ausgegangen, dass es sich bei
den Clients auch um Windows-basierte Clients handelt. Grundsätzlich besteht auch die
Möglichkeit von Linux oder anderen Unix-basierten Clients aus auf Drucker, die über
einen Windows Print-Server bereitgestellt werden zuzugreifen. Dabei kann man verschiedene Methoden verwenden. Zum einen besteht die Möglichkeit über einen installierten SMB-Client (Samba-Client) auf die Windowsdrucker zuzugreifen. Die meisten
Desktop-Systeme (z.B. KDE, Gnome) beziehungsweise Linux-Distributionen (z.B. RedHat) bieten hierfür auch entsprechende Benutzer-/Administratorschnittstellen, über welche die Drucker ausgewählt werden können. Unter Verwendung der Windows Print Services for Unix (Unterstützung von LPD) auf einem Print-Server besteht auch die Möglichkeit über eine LPD-fähige Software auf den Linux-Clients Druckaufträge an Windows
zu versenden. Wenn man auf dem Linux-Client einen CUPS-Server installiert hat man
letztendlich die Wahl zwischen den zuvor gewählten Möglichkeiten (LPD und SMB) sowie mit Einschränkung auch der Nutzung von IPP (siehe auch Abbildung 1 ), sofern der
Print-Server auf Windows Server 2000 oder höher basiert. Mit der Verwendung von
CUPS stehen dann auch weitere Managementfunktionen zur Verfügung, wie zum BeiX
Seite 285
X
spiel das Löschen von Druckaufträgen. Demgegenüber steht allerdings, dass ein CUPSServer die Leistung des Clients gegebenenfalls negativ beeinflusst. Handelt es sich bei
dem anzusteuernden Drucker um einen professionellen netzwerkfähigen Drucker, muss
man erst gar nicht den Umweg über den Windows Print-Server gehen, sondern kann
diesen über CUPS direkt ansteuern.
1.4.3
„Point & Print“-Methode
Microsoft setzt bei der Kommunikation von Print Client und Server auf das Protokoll RPC
(Remote Procedure Call) und verwirklicht damit die sogenannte Point & PrintTechnologie. Diese ermöglicht es zum einen, die Druckertreiber vom Server auf den
Client zu übertragen und die gerätespezifischen Einstellungen (Papierschächte, Standard-Papierformate) an den Client zu übermitteln. Zum anderen wird dadurch ein Teil
des Rendering-Prozesses auf den Server verlagert, sodass der Client bei der Druckaufbereitung entlastet wird. Einerseits macht sich diese Entlastung insbesondere beim Einsatz von Terminal Servern positiv auf dem Client bemerkbar. Andererseits wirkt sich die
Verlagerung des Renderingprozesses auf den Server auf dessen Leistungsverhalten
bemerkbar negativ aus.
Zu beachten ist, dass bei dieser Methode ein Teil des Druckvorgangs auf dem Client und
ein weiterer Teil auf dem Server ausgeführt werden. Daher müssen die „Teil-Treiber― auf
dem Server und dem Client identische Versionen besitzen, da andernfalls Probleme bis
hin zur Unbenutzbarkeit des gesamten Netzwerks auftreten können. Stellt ein Client fest,
dass der Treiber auf dem Server neuer ist als der lokale, so wird er automatisch auch auf
dem Client aktualisiert. Wenn auf dem Server jedoch ein älterer Treiber als auf dem
Client installiert ist, kann es zu Fehlermeldungen oder einem Systemabsturz kommen,
wenn auf dem Client versucht wird zu drucken oder den „Eigenschaften―-Dialog zu
öffnen. Dieser Zustand kann zum Beispiel dann entstehen, wenn der Treiber auf dem
Server erst aktualisiert wird und danach die Treiber der Clients, wenn sie Verbindung mit
dem Server aufnehmen. Wird nun der Treiber auf dem Server aus irgendwelchen
Gründen, zum Beispiel wegen eines versteckten Fehlers, auf eine ältere Version gesetzt,
kommt es zu diesem Problem. Das gleiche Problem tritt auf, wenn auf einem Client
manuell eine neuere Treiberversion installiert wurde.
Dieses Problem kann eventuell über entsprechende Softwareverteilungsmechanismen
gelöst werden.
1.4.4
Zusätzliche proprietäre Druckerports
Um einige Lücken des LPR/LPD Protokolls zu schließen, sind von namhaften Druckerherstellern zusätzliche Ports für Windows Systeme ab Windows NT implementiert worden, zum Beispiel:

Hewlett Packard Network Port print monitor (Hpmon.dll),

Macintosh print monitor (Sfmmon.dll),

Digital Network Port print monitor (Decpsmon.dll),

LexMark Mark Vision print monitor (Lexmon.dll) und

NetWare Print Monitor (Nwmon.dll).
Seite 286
Diese Ports ermöglichen im Gegensatz zu LPD/LPR in der Regel eine bidirektionale
Kommunikation mit den Druckern oder Druckerboxen und damit unter anderem die Möglichkeit die Druckerwartung vom Endgeräte beziehungsweise vom Server aus vorzunehmen. Hierzu werden Programme von einem Server oder Endgerät ausgeführt, mit
deren Hilfe Druckerstörungen, für die keine Vor-Ort-Tätigkeit erforderlich ist, zu beheben.
Zu solchen durchführbaren Wartungsfunktionen zählen unter anderem:

Reinigung von Druckdüsen bei Tintenstrahldruckern

Reinigung der Papierführung

Ausrichtung von Druckköpfen

Rücksetzung von Fehlermeldungen

Auslesen von Verbrauchsdaten, zum Beispiel Anzahl gedruckter Seiten

Update der Systemsoftware im Drucker
Weiterhin sind diese Ports sind gegenüber dem LPR-Port in der Lage, auch noch andere
Transportprotokolle zu nutzen, wie:

DLC (Data Link Control),

IPX (Internetwork Packet eXchange) und

AppleTalk.
Diese von den Herstellern zur Verfügung gestellten, proprietären Softwareprodukte beseitigen jedoch nicht das Problem der fehlenden Verschlüsselung beim Drucken unter
Windows.
1.4.5
Werkzeuge
Die Administrationswerkzeuge von Print-Servern unter Windows beschränken sich auf
die Verwaltung der Druckerfreigaben und der Druckertreiber.
Darüber hinaus bestehen aber auch die Möglichkeit der Nutzung der unter II.F 1.1.1.10
aufgeführten unabhängigen und flexiblen Möglichkeiten, sofern die verwendeten Drucker
diese unterstützen.
X
X
Weiterhin werden von vielen Druckerherstellern oder Anbietern von Systemmanagementsoftware proprietäre Softwarelösungen zum Management der Geräte angeboten.
Die folgende Auflistung liefert einige Beispiele an Software von Druckerherstellern und
anderen Verwaltungs- und Überwachungsmöglichkeiten:

MarkVision von LexMark.

JetAdmin von HP - HP Laserdrucker können auch per telnet administriert werden, was aber wegen der fehlenden Verschlüsselungsmöglichkeit nur im Notfall
benutzt werden sollte.

Viele Hersteller bieten auch ein Web-Interface über http oder https für die
Administration an.

SMTP zum Versand von Störmeldungen an eine zentrale Managementkonsole
wird auch von den meisten Herstellern unterstützt.
Seite 287
Ähnlich wie bei Netzlaufwerken ist die automatische Verbindung zu Druckern beim Login
des Anwenders gewünscht. Dies kann bei Windows 9x Clients entweder via VB-Script
oder Tools wie con2prt.exe realisiert werden. Das Setzen von Berechtigungen auf Druckerfreigaben per logon Skript oder Benutzerprofile ist nicht möglich.
Hinsichtlich der Vergabe von Berechtigungen auf Druckerfreigaben sind Skriptprogramme (Perl) denkbar.
Ab Windows NT4 WS oder höher können die Druckfreigaben entweder per Logonscript
oder über (servergestützte) Benutzerprofile beim Starten von Windows zur Verfügung
gestellt werden.
1.4.6
Zugriffssteuerung
Die Zugriffssteuerung auf die von Print-Servern bereitgestellten Netzwerkdrucker (Freigaben) wird von diesen geregelt, sofern dies nicht über einen Verzeichnisdienst gesteuert wird. Die Rechte auf die Freigabe sind begrenzt auf die Stufen:

Drucken,

Drucker verwalten und

Dokumente verwalten.
Eine Authentifizierung von Windows Clients beziehungsweise Anwendern ist unter
Windows Server 2003 R2 möglich. Hierzu muss das SMB/CIFS Protokoll deaktiviert
sein. 223 Hierdurch wird jedoch die Verwaltung der Print-Server durch die Administratoren
erschwert, da dann nicht mehr alle Zugriffsmöglichkeiten über das Netzwerk auf den
Printserver gegeben sind.
F
F
Für Druckdienste sieht Microsoft im Standard keine Verschlüsselungsmechanismen vor.
Allerdings bietet die .NET Umgebung Verschlüsselungsmechanismen an, die auch zur
Verschlüsselung im Bereich von Netzwerkdruckern angewendet werden können. Hierzu
ist es notwendig eine .NET Umgebung aufzubauen, das heißt, diese entsprechend auf
den Microsoft Servern und den Clients zu installieren. 224
F
1.4.7
F
Schnittstellen
Bei der Anbindung von Druckern sind die logischen und die physikalischen Schnittstellen
zu betrachten. Die logischen Schnittstellen bilden die Druckertreiber. Physikalische
Schnittstellen werden genutzt, um Drucker mit anderen Geräten zu verbinden. Dies sind
zum einen Schnittstellen für die direkte Verbindungen zwischen Drucker und PC, zum
Beispiel serielle, parallele Schnittstelle oder USB, und zum anderen Schnittstellen für die
Verbindung zu einem Netzwerk, zum Beispiel Ethernet oder WLAN.
Die Methoden, die Microsoft Windows zum Drucken anbietet, sind in einer homogenen
Microsoftlandschaft gut auf einander abgestimmt.
223
224
http://www.microsoft.com/germany/technet/sicherheit/prodtech/windowsserver2003/
w2003hg/s3sgch08.mspx
http://www.microsoft.com/germany/msdn/library/security/
SymmetrischeUndAsymmetrischeVerschluesselung.mspx?mfr=true
Seite 288
Setzt man die Microsoft Printserver in einer heterogenen Landschaft zur Verwaltung von
zentralen Druckdiensten ein, benötigt man weitere Systeme, wie zum Beispiel einen
Samba Server.
1.4.8
Fazit
Die unter Windows implementierten Methoden zum Drucken funktionieren zuverlässig
mit allen gängigen Druckern. Alle namhaften Druckerhersteller stellen Werkzeuge und
Druckertreiber für Windows zur Verfügung, mit denen sich die Drucker administrieren
lassen. Allerdings gibt es kein allgemein gültiges Administrationswerkzeug unter Windows, sodass die Anzahl der zu installierenden Software für Druckeradministration mit
der Anzahl der unterschiedlichen Drucker beziehungsweise Druckerhersteller und damit
der Administrationsaufwand zunimmt. Dem gegenüber stehen professionelle Drucker
(überwiegend PostScript-Drucker), welche das Management und die Überwachung über
Standardbrowser (HTTPS) und andere Standardprotokolle, wie SMTP oder SNMP, unterstützen und damit eine einfache und kosteneffiziente Administration komplexer Netze
ermöglichen.
Bezüglich der „Point & Print―-Methode, wie sie im Abschnitt II.F 1.4.3 dargestellt wird ist
anzumerken, dass beim Einsatz von PostScript-Druckern, wie im professionellen Umfeld
üblich, diese Vorgehensweise doch problematisch zu sein scheint. Die Komplexität der
„Point & Print―-Methode bringt zum einen keinen Mehrwert, schafft es aber, den Clients
die volle Funktionalität des Druckers vorzuenthalten, wenn der Server mit Samba läuft.
Durch die „Verteilung― der Treiberfunktionen erreicht es Microsoft, dass die volle Funktionalität auch an die eigene Plattform gebunden bleibt. Bei der Verwendung von „Point
& Print― in Verbindung mit Samba sind die Zusatzfunktionen je nach Druckerhersteller
stark (z.B. HP) bis nur minimal (z.B. Konica-Minolta) eingeschränkt. Hierauf sollte bei der
Auswahl der Drucker geachtet werden. Es treten vergleichbare Effekte auf, wie sie im
folgenden Knowledgebase-Artikel beschrieben werden: http://support.microsoft.com/kb/884897/de.
X
2
Migrationspfade
Einleitend sollen einige allgemein gültige Punkte erwähnt werden, die bei einer Migration
der Druckdienste zu beachten sind beziehungsweise Gültigkeit besitzen.
Die Ablösung einer Druckumgebung kann in der Regel ohne große Beeinträchtigungen
des Betriebs erfolgen, da die neue Druckumgebung parallel zu der bestehenden Druckumgebung aufgebaut und in Betrieb genommen werden kann. In der Regel beschränkt
sich dieser Neuaufbau auf die Implementierung des Druckservers. Clients und Drucker
können im Normalfall übernommen werden. Es kann jedoch vorkommen, dass insbesondere für ältere Drucker keine Druckertreiber für die neue Druckumgebung zur Verfügung stehen. In einem solchen Fall muss entweder auf allgemeingültige Druckertreiber
zurückgegriffen werden, wobei evtl. bestimmte druckerspezifische Funktionen nicht mehr
nutzbar sind, oder aber die älteren Geräte müssen ausgetauscht werden. Weiterhin
müssen gegebenenfalls die Druckwarteschlangen auf den Clients neu eingerichtet werden. Dies kann automatisiert über Login Scripte oder Benutzerprofile erfolgen.
In Bezug auf die möglicherweise notwendige Anpassung der Warteschlangen auf LinuxArbeitsplatzrechnern muss auf jeden Fall deutlich zwischen Linux und Windows differenSeite 289
ziert werden: Bei Linux sind der Regel keine Anpassungen erforderlich. Unter Windows
geht das über logon-Skripte bei der nächsten Anmeldung.
Insgesamt wird eine Migration von Druckdiensten auf eine neue Plattform nicht unbedingt ein genaues 1:1-Abbild der bestehenden Verhältnisse wiedergeben können. Eine
Migration sollte jedoch als Chance wahrgenommen werden, bestehende Schwachstellen
zu beheben.
Eine Migration von einer in die andere Systemlandschaft ist deutlich einfacher, wenn die
im Einsatz befindlichen Drucker folgende Merkmale haben:
2.1

PostScript-fähig

Administration über Standardbrowser per HTTPS

Versand von Störungsmeldungen per E-Mail, vorzugsweise in einem automatisiert verarbeitbaren Format (zum Beispiel XML)

Die Treiber für Windows müssen so aufgebaut sein, dass alle Optionen auch
über Samba verfügbar sind (wie zum Beispiel bei Konica/Minolta, nicht bei HP)

Sie sollen IPP mit SSL/TLS-Verschlüsselung unterstützen
Migration von Windows Print Services nach CUPS in Kombination mit
Samba unter Linux
Eine mögliche Motivation zur Migration der Windows Druckdienste nach CUPS kann
darin bestehen, dass ältere Geräte, die auf Grund ihrer spezifischen Druckeigenschaften
benötigt werden, von neueren Windows-Betriebssystemen nicht mehr beziehungsweise
nur unzureichend unterstützt werden, weil die Hersteller keine Druckertreiber mehr zur
Verfügung stellen. In diesem Fall kann über CUPS und den Einsatz von PostScriptDateien auch auf Druckern gedruckt werden, die kein PostScript unterstützen, da hier
der CUPS Server diese PostScript-Datei entsprechend umwandelt. Weiterhin können die
sogenannten PPD-Dateien verwendet werden, so wie dies im Kapitel II.F 1.1.2.2 beschrieben ist. Diese werden von fast allen Herstellern angeboten.
X
X
Da CUPS auf TCP/IP aufsetzt, kann mit einer Migration zu CUPS auch die Schaffung
einer homogenen, rein TCP/IP basierten IT-Infrastruktur unterstützt werden. Dazu sollte
jedoch sicherstellt werden, dass keine Endgeräte das WINS Protokoll nutzen, um mit
Druckservern zu kommunizieren. Gegebenenfalls ist es sinnvoll, solche Endgeräte
auszutauschen beziehungsweise umzukonfigurieren, sofern dies möglich ist. In einigen
Fällen wie zum Beispiel bei Windows 95 und 98 lässt sich dies nicht vermeiden. In
diesen Fällen ist zu überlegen, ob ein Austausch dieser Geräte beziehungsweise ein
Wechsel des Betriebssystems sinnvoll und machbar ist. Kann aufgrund von anderen
Abhängigkeiten nicht auf den WINS Dienst verzichtet werden, erfordert die Umstellung
der Druckdienste von Windows nach CUPS den Aufbau und die Nutzung eines Samba
Servers. Mit dessen Hilfe kann dann die Kommunikation mit dem CUPS Server
sichergestellt werden.
Wird WINS jedoch nicht benötigt, kann die Verbindung direkt über TCP/IP hergestellt
werden, wobei die IP-Adresse bei der Einrichtung eines entsprechenden Ports auf Win-
Seite 290
dowsrechnern benötigt wird. Um eine Auflösung der Druckernamen zu ermöglichen, wird
für die Windowsrechner dann doch wieder der Einsatz von Samba benötigt.
Die Einführung von CUPS selbst erfordert die Implementierung mindestens eines Rechners im Netzwerk, der als CUPS Server fungiert. In Abhängigkeit von der Größe der
Druckumgebung sollte dieses Gerät ein eigenständiger Server sein, also keine weiteren
Funktionen übernehmen. Darüber hinaus kann, je nach Verfügbarkeitsanforderung, auch
eine ausfallsichere Lösung mit mehreren Servern aufgebaut werden.
2.2
Migration von CUPS in Kombination mit Samba unter Linux nach Windows
Print Services
Die in der Einleitung beschriebenen Sachverhalte haben auch bei der Migration einer
Druckumgebung von CUPS nach Windows ihre Gültigkeit. Allerdings muss bei einem
Migrationspfad, wie er hier betrachtet wird, besonders genau darauf geachtet werden,
dass alle Geräte, die in die neue Drucklandschaft eingebunden werden, auch mit den
Microsoft-Druckservern kommunizieren können. Dies gilt sowohl für die Drucker als auch
für die im Netzwerk vorhanden Clients. Insbesondere bei älteren Druckern, die nicht
mehr vom Hersteller unterstützt werden, kann eine Migration zu Problemen führen. Dies
ist zum Beispiel der Fall, wenn kein Gerätetreiber für Windows für das entsprechende
Gerät verfügbar ist.
2.3
Migration von Windows NT4/2000 Print Services nach Windows 2003 Print
Services
Für eine Migration von NT4 auf Server2000 / Server 2003 wird von MS ein Migrationstool PrintMig angeboten. Dieses unterstützt die Portierung aller Druckwarteschlangen,
Druckernamen und sofern vorhanden, auch Treiber. Dabei ist darauf zu achten, dass ein
zukunftsfähiges Konzept entwickelt wird, das die Verwendung von NT4 Treibern in der
neuen Umgebung ausschließt.
Die aktuelle Version des Migrationstools ist PrintMig Version 3.1.
3
3.1
Bezüge
Systemmanagement und -überwachung
Der wichtigste Bezug besteht zum Themenblock des Systemmanagements und der Systemüberwachung (Kapitel II.G „Thema System-Überwachungs- und -ManagementDienste―). Hier sind es vor allem die Bordmittel, die mit den Betriebssystemen zur Verfügung gestellt werden (siehe Einleitung der Technologiebetrachtung zum Kapitel II.G
„Thema System-Überwachungs- und -Management-Dienste―).
Weiterhin sind es die großen integrierten Lösungen der Anbieter wie HP und IBM, die
auch für die Überwachung und das Management der Druckerinfrastruktur entsprechende
Lösungen liefern (siehe Kapitel II.G.1.3 „HP OpenView― und II.G.1.4 „IBM Tivoli―)
Als Open Source Werkzeug für das Systemmonitoring spielen auch die Möglichkeiten
und Funktionen von Nagios eine wichtige Rolle (siehe Kapitel II.G.1.1.1 „SystemMonitoring mit Nagios―)
Seite 291
3.2
Authentifizierung und Verzeichnisdienste
Ein ebenso wichtiger Bezug besteht mit Blick auf das Thema Sicherheit zu den Authentisierungs- und Verzeichnisdiensten. Hier sind es vor allem die Möglichkeiten im Zusammenhang mit Samba in gemischten Umgebungen (siehe Kapitel II.C.1.1 „Linux und
Samba mit OpenLDAP und Kerberos (MIT/Heimdal)―) und Kerberos (siehe Kapitel II.C
1.1 und insbesondere II.C.1.1.3 „Heimdal-Kerberos /MIT Kerberos 5― sowie II.C.1.4.1
„Kerberos―) sowohl unter Windows als auch unter Linux und vor allem wenn es darum
geht Single Sign-On Lösungen zu schaffen.
3.3
Netzwerkdienste
Der Bezug zu den Netzwerkdiensten (siehe Abschnitt II.D „Thema Netzwerkdienste―)
ergibt sich aus den Sicherheitsanforderungen bezüglich der Kommunikation mit den
Druckern über das Netz. Hier sind es vor allem die verschiedenen Möglichkeiten der
Verschlüsselung von Kommunikationsverbindungen.
Seite 292
G Thema System-Überwachungs- und -Management-Dienste
1
Systemüberwachungs- und Systemmanagementdienstprogramme stellen Funktionen
zur Verfügung, die das Administrieren, Pflegen und Entstören von Endgeräten vereinfachen. Unter einem Endgerät wird jedes Gerät verstanden, das mit einem Netzwerk verbunden ist. Zum Systemmanagement gehören im Wesentlichen folgende Funktionen:

Bereitstellung von Applikationssoftware (Softwareverteilung)

Bereitstellung von Betriebssystemen und Betriebssystempatches

Überwachung von Systemen und deren Status (auch agentenlos)

Berichte erstellen

Fernsteuerung von Systemen
Die meisten Unixbetriebssysteme bieten schon als Bordmittel eine Reihe von einfachen
Werkzeugen, mit denen man, wenn man sie geschickt einsetzt, sehr komplexe Aufgaben
erledigen kann. Die meisten der nachfolgend aufgeführten Werkzeuge gibt es als Bordmittel auch unter Windows oder es gibt entsprechende frei verfügbare Tools, wie zum
Beispiel die SSH-Implementierung „PuTTY― oder andere, die auf der folgenden Webseite
vorgestellt werden (http://www.openssh.org/de/windows.html).

cron
sss Cronist ein sogenannter Dämon und wird über den crontab Befehl gesteuert.
Dieser Dämon dient dazu, zeitlich immer wiederkehrende Aufgaben vom System
automatisch ausführen zu lassen. Diese Aufgabe können Batchjobs, ausführbare
Programme, ausführbare Skriptdateien und so weiter sein. Crontab ist nicht nur
der Befehl, mit dem der cron Dämon gesteuert werden kann, sondern bezeichnet
auch gleichzeitig die Liste von Aufgaben, die durch den cron Dämon gestartet
werden sollen. In dieser Liste sind sowohl die Aufgaben als auch der Ausführungszeitpunkt hinterlegt. Der cron Dämon prüft diese Liste alle 60 Sekunden ab,
ob es eine auszuführende Aufgabe gibt und führt diese dann entsprechend aus.
In den unterschiedlichen Linux Distributionen ist der cron Dämon auch unterschiedlich implementiert. Die Unterschiede liegen vor allem in den Möglichkeiten,
den Aufgaben Parameter zuzuweisen. Die meisten Linux-Distributionen enthalten
gegenwärtig Vixie-cron.

at
Der at Befehl dient ähnlich wie der cron Dämon zur zeitlichen Steuerung von
Aufgaben. Der at Befehl wird verwendet um eine Aufgabe, die genau einmal ausgeführt wird, mit einem Zeitstempel zu versehen. Diese Aufgabe wird anhand
dieses Zeitstempels vom System zu diesem Zeitpunkt ausgeführt. Jede Aufgabe
muss jeweils mit einem neuen at Befehl dem System bekannt gemacht werden.
Im Umfeld des at Befehls sind noch zwei weitere Befehle definiert, die zur zeitlichen Steuerung von Aufgaben dienen. Der atq-Befehl zeigt alle mit dem at-Befehl
Seite 293
eingerichteten Aufgaben und sortiert diese nach dem Benutzer, der sie eingestellt
hat. Der atrm-Befehl löscht die Aufgaben anhand ihrer vom System eindeutig
vergebenen Nummer.

Ssh
ssh (secure shell) steht sowohl für den Namen des Protokolls als auch für die
Implementation eines secure shell Clients. Bei Linux ist dieser fest im Linux
implementiert. ssh dient dazu, eine sichere Verbindung zwischen zwei Rechnern
beziehungsweise Benutzern herzustellen. So wird zum Beispiel eine Konsole an
einem Linux Rechner auch als Benutzer angesehen und alle Befehle, die an
dieser Konsole abgesetzt werden, werden in dem ssh Client abgesetzt, der den
Befehl entsprechend ans System weiterleitet. Über eine ssh Verbindung kann
jeder Linux Rechner administriert, verwalten und überwacht werden, sofern die
entsprechenden Berechtigungen vorliegen. Da SSH1 auch weiterhin anfällig für
„man-in-the-middle― Angriffe ist, sollte immer SSH2 verwendet werden. Die SSH2
Shell steht auch übergreifend anderen auf Unix basierenden Betriebssystemen
zur Verfügung.

SNMP
Das Netzwerkprotokoll Simple Network Management Protocol (SNMP) wurde von
der IETF entwickelt, um aktive Netzwerkkomponenten (zum Beispiel Router, Server, Switches, Drucker, Computer usw.) überwachen und steuern zu können.
Durch das Protokoll wird die Kommunikation zwischen den überwachten Geräten
und einer Überwachungsstation geregelt. SNMP wurde so ausgelegt, dass jedes
netzwerkfähige Gerät, bei dem das TCP/IP Protokoll aktiviert ist, überwacht werden kann.
Die aktuelle Version ist SNMPv3. Diese ist in den RFCs 3410 ff. beschrieben und
bietet im Gegensatz zu seinen Vorgängern auch Sicherheitsmechanismen an.
Diese sind Verschlüsselung und eine verbesserte Authentifizierung. Eine ausführliche Beschreibung kann man auf der Web Seite des BSI225 finden.
Viele Systemhersteller haben in ihren Produkten zur Unterstützung der Systemüberwachung die Übermittlung sogenannter „snmp-Traps― implementiert. In der
Regel sind diese Traps auch dokumentiert, sodass sie mit Hilfe der Systemüberwachung ausgewertet werden können.
Auf das Monitoring und die Analyse von Netzwerktraffic ist MRTG/RRD spezialisiert. MRTG nutzt SNMP, um Verkehrsdaten von den verschiedensten Netzwerkkomponenten zu sammeln und zu speichern. Die Auswertung und grafische Aufbereitung kann entweder intern durch MRTG oder extern durch RRD erfolgen.
Für MRTG stehen über 350 Templates zur direkten Anbindung verschiedenster
SNMP-fähiger Netzwerkkomponenten und -dienste zur Verfügung.
Ein weiteres Tool zur Trafficanalyse und -visualisierung ist NeTraMet das ebenfalls mit SNMP arbeitet.
225
http://www.bsi.de/gshb/deutsch/m/m02144.htm
Seite 294
Scotty ist ein weiteres Tool für Visualisierung und Management von lokalen Netzen, das ebenfalls mit SNMP arbeitet und auch die Änderung von SNMPzugänglichen Parametern auf den entfernten Netzkomponenten erlaubt.

Ping
Der Ping-Befehl ist Standard bei allen Unix Distributionen und bei Windows.
Dieser Befehl schickt ein Datenpaket an eine Zieladresse. Dies kann eine IPAdresse oder ein DNS Name sein. Ist das Zielgerät eingeschaltet und mit dem
Netzwerk verbunden, schickt dieses System ein Datenpaket an den Absender
zurück, der dies registriert. Hierbei wird auch die Zeit des Datentransfers
gemessen. Mit dem Ping-Befehl können somit auf einfache Weise der Verbindungsstatus eines an einem Netzwerk angeschlossenen Gerät festgestellt und in
geringem Maße auch Netzwerkleistungsmessungen durchgeführt werden. In
vielen Fällen wird Ping zur agentenlosen Überwachung von Systemen genutzt.

syslog
syslog ist ein De-facto-Standard zur Übermittlung von Log-Meldungen. Der Begriff wird in mehreren Varianten genutzt, zum einen als Bezeichnung des syslogNetzwerkprotokoll, zum anderen für die Anwendungen oder Bibliotheken, die syslog-Meldungen senden oder empfangen.
syslog ist ein einfaches Client Server Protokoll, bei dem der Client kleine Datenpakete an den Server verschickt.
Typischerweise wird syslog für Computersystem-Management und SicherheitsÜberwachung eingesetzt.
1.1
Systemmanagement mit OSS – Nagios, u.a., Linux
In der OSS Welt gibt es keine hoch integrierte Systemmanagementsoftware vergleichbar
mit HPOpenView oder Tivoli Konfiguration Manager, die alle Belange des Systemmanagements über ein großes Paket entsprechender Module abdeckt. Es gibt jedoch zahlreiche Tools, die im Wettbewerb mit vergleichbaren Modulen integrierter Systeme bestehen
und die entsprechenden Aufgaben des Systemmanagements gut abdecken. Diese
Tools, sogenannte Bordmittel, können mit einander kombiniert werden, sodass auch in
der OSS Welt ein leistungsstarkes und vor allem kostengünstiges Systemmanagement
aufgebaut werden kann. Einzelne Linux Distributionen bieten unterschiedliche Funktionen für Systemmanagement. Zum Beispiel liefert Debian seine Softwareverteilung gleich
mit, in welche allerdings nur Debian basierte Rechner integriert werden können.
1.1.1
System-Monitoring mit Nagios
Nagios wurde für den Betrieb unter Linux entwickelt, kann jedoch auch unter fast allen
anderen Unix Distributionen angewandt werden. Die aktuelle Version von Nagios ist die
Version 2.9226. Die Version 3.0 liegt derzeit als Beta-Version 3.0b1 vor. Der frühere Name von Nagios war NetSaint. Nagios und das Nagios-Logo sind eingetragene Warenzeichen von Ethan Galstad. Ethan Galstad ist der führende Entwickler für Nagios. Ausführ-
226
Stand 01.11.2007
Seite 295
liche Information sowie aktuelle Entwicklungen finden sich auf der Nagios Homepage227.
Nagios wird unter der „GNU General Public License Version 2― von der „Free Software
Foundation― veröffentlicht.
Aktuell wird Nagios von ca. 2000 registrierten Benutzern verwendet, die ca. 350.000
Clients damit überwachen228.
Nagios ist ein Rechner- und Servicemonitor, der zur Erkennung von Störungen
(unerwartetes Ereignis im Betrieb) und Problemen (häufig auftretende Störungen ohne
bekannte Fehlerbehebung) entwickelt wurde. Darüber hinaus überwacht Nagios auch
Drucker und aktive Netzwerkkomponenten. Der Überwachungsdämon führt in definierten
zeitlichen Abständen Abfragen und Kontrollen an Rechnern und Diensten durch, die
über externe „Plugins" eine Statusrückmeldung an Nagios geben. Beim Entdecken einer
Störung kann der Dämon eine Meldung an definierte Stellen, zum Beispiel einen
Administratoraccount über verschiedene Wege (email, instant message, SMS, etc.),
schicken. Aktuelle Statusmeldungen, Logfiles und Berichte können über ein WEB
Interface abgefragt werden. Nagios lässt sich auch in der Form konfigurieren, dass das
System einen Versuch unternehmen kann, um einen aufgetretenen Fehler selbständig
zu beheben, zum Beispiel durch einen Neustart eines Dienstes.
Nagios ist auch auf die Visualisierung der Netztopologie und die Überwachung von
Diensten auf Servern mit anderen Betriebssystemen spezialisiert. Anhand von definierbaren Schwellenwerten reagiert Nagios zum Beispiel auf gefundene Fehler oder eintretende Ereignisse.
Nagios benutzt Plug-Ins zur aktiven oder passiven Überwachung verschiedenster
Dienste und Systemparameter. So können zum Beispiel typische Netzwerkdienste wie
Web, Mail, LDAP, verschiedene RDBMS oder Samba überwacht werden. Außerdem gibt
es Plug-Ins für die Überwachung von Systemparametern wie CPU-Last, Festplattenplatz
aber auch für die Daten der Hardwaresensoren (Temperatur, Stromversorgung und
Lüfterdrehzahl). Einfache Schnittstellen und Templates erlauben die schnelle Entwicklung eigener Plug-Ins.
Nagios bietet zahlreiche Funktionen und Eigenschaften zum Überwachen der ITInfrastruktur, den IT-Diensten und zur Administration von Nagios selbst. Die wichtigsten
Funktionen sind nachfolgend aufgelistet:
227
228

Überwachung von Netzwerkdiensten (SMTP, POP3, HTTP, NNTP, PING, etc.)

Überwachung von Rechnerkomponenten (Prozessorlast, Festplatten- und Speicherauslastung, laufende Prozesse, Logfiles, etc.) über smnp

Überwachung von physikalischen Eigenschaften, wie zum Beispiel Temperatur

Hinterlegung von Kontaktinformationen zur Meldung von Störungen und deren
Behebung (via email, pager, oder über andere benutzerdefinierte Wege)
http://www.nagios.org/
http://www.nagios.org/userprofiles/quickstats.php
Seite 296

Benachrichtigung unterschiedlicher definierter Benutzergruppen im Eskalationsfall

Möglichkeit zur Definition von automatisierten Ereignismanagern, die auf ein
Ereignis reagieren können, zum Beispiel Neustart eines Servers, wenn ein
Serverdienst als gestört gemeldet wird

Nagios unterstützt den Aufbau mehrerer Nagioskonsolen, die die gleichen Überwachungsfunktionen haben. Damit lassen sich eine erhöhte Ausfallsicherheit und
die Lastverteilung realisieren

Kommandozeilen Interface für schnelle Änderungen an den Überwachungsparametern und den Ereignismanagern

Beibehaltung von Statusmeldungen bei Neustarts des Programms

Hinterlegung von geplanten Betriebsunterbrechungen zum Beispiel für
Wartungsarbeiten

Möglichkeit der Störungsmeldung auch per WEB Interface

WEB Interface zum Anzeigen von aktuellem Netzwerkstatus, von Meldungs- und
Störungshistorie, Logfiles, etc.

Einfache Benutzerverwaltung
Beispiele für die Benutzeroberfläche und eine Installationsanleitung finden sich auf der
Website von Nagios229.
Der Installations- und Einrichtungsaufwand für eine Standardinstallation kann als vergleichsweise gering angesehen werden230.
Nagios ist zwar für Linux entwickelt worden, doch mit Nagios können auch heterogene
Netzwerke überwacht werden, in denen zum Beispiel eine Mischung von Linux, Unix und
Windows Systemen zum Einsatz kommt. Nagios bietet eine einfache Plug-In Architektur,
die es erlaubt, auch eigene Plug-Ins zu entwickeln und in Nagios einzubinden
1.1.2
Open Source Softwareverteilungssysteme
1.1.2.1
Opsi
Opsi ist ein Produkt der Firma uib 231 in Mainz und steht unter der GPL und ist somit frei
verfügbar. Opsi unterstützt die Softwareverteilung auf Windows 2000, Windows XP und
Linux Systemen. Seit über 9 Jahren wird opsi eingesetzt und weiterentwickelt. Opsi ist
seit dem 06.09.2007 in der Version 3.1 freigegeben.
229
230
231
http://www.nagios.org/about/screenshots.php,
http://nagios.sourceforge.net/docs/3_0/quickstart.html
Die Installationsanleitung kann unter folgendem Link im Internet eingesehen werden:
http://nagios.sourceforge.net/docs/3_0/quickstart.html.
http://www.uib.de/www/home/index.html
Seite 297
Die Funktionalitäten von opsi umfassen die Softwareverteilung mit

Standard-Softwarepaketen,

Software-Updates,

Microsoft-Servicepacks,

Microsoft Security-Patches und

Inventarisierung.
1.1.2.2
m23
m23232 ist ein Softwareverteilungssystem für Debian Gnu Linux Systeme, das genau wie
Opsi unter der GPL steht. m23 ist nicht für heterogene Systemumgebungen geeignet,
was aber in einer homogenen Debian-Umgebung kein Nachteil sein muss. m23 ist wie
die meisten Softwareverteilungssysteme ein Client/Server basiertes System und beinhaltet Funktionalitäten wie

Erstinstallationen, inklusive Partitionierung und Hardwareerkennung,

Verteilung von System- und Anwendungssoftware,

Wiederherstellung von Clients,

Softwareupdates und

Inventarisierung (Hardwareerkennung).
Damit deckt m23 die wesentlichen Funktionalitäten ab, die auch von den meisten proprietären Systemen bereitgestellt werden.
1.1.3
Fazit
Zusammenfassend gilt, dass es mit den in der OSS Welt kostenfreien Softwareprodukten möglich ist, eine komplexe und gut funktionierende System-Management-Umgebung
aufzubauen. Die Kombination von unterschiedlichen Produkten führt zu einer weitgehenden Herstellerunabhängigkeit und gestaltet einen Wechsel von einer Software zur
anderen kostenneutral in Bezug auf die Lizenzkosten. Auch die Kombination von einzelnen Funktionen aus dem Bereich kostenpflichtiger Software mit OSS Software erscheint
durchaus sinnvoll. Zum Beispiel wird in vielen Organisationen HP OpenView als Netzwerkmanagementsystem verwendet. Dies kann weiter genutzt werden, um parallel eine
Softwareverteilung mit einem OSS Werkzeug aufzubauen. Nagios als Monotoringwerkzeug und opsi als Werkzeug zur Softwareverteilung haben im Einsatz bewiesen, dass
sie im Speziellen auch für große IT-Infrastruktur-Umgebungen gut einsetzbar sind.
Für kleinere und mittlere Behörden sind die anderen OSS Werkzeuge und insbesondere
die Bordwerkzeuge, die einleitend aufgeführt wurden, prinzipiell gut geeignet.
Die OSS Werkzeuge bieten vor allem einen hohen Grad an Flexibilität und sind gut individuell anpassbar. Dies führt in der Regel zu einer hohen Akzeptanz der Lösung und zu
232
http://m23.sourceforge.net/PostNuke-0.726/html/index.php
Seite 298
einer höheren Motivation bei den Mitarbeitern, sich mit den Thema des Systemmanagements auseinander zu setzten.
1.2
Microsoft Systems Management Server (SMS) 2.0/2003 und Microsoft
Operations Manager (MOM)
Nachfolgend werden die beiden Management Tools betrachtet:

Systems Management Server (SMS), für die Softwareverteilung

Microsoft Operations Manager (MOM), für Systemüberwachung und –
management
Der System Management Server (SMS) wurde zeitnah mit dem Erscheinen von Windows NT 4 auf den Markt gebracht. Als Endversion dieser Generation ist SMS in der
Version 1.2 anzusehen. Im Jahr 1999 erschien die Version 2.0. Die aktuelle Version ist
der SMS 2003 R2. Diese Version wird im Folgenden näher betrachtet. Seit Neuestem
liegt SMS in der Version Microsoft System Center Configuration Manager (SCCM) 2007
vor.
Microsoft Operations Manager 2005 liegt seit kurzem in der Version System Centre
Operations Manager (SCOM) 2007 vor. Zu SCCM 2007 und SCOM 2007 liegen bisher
keine Erfahrungswerte vor, sodass diese Versionen hier nicht weiter betrachtet werden.
SMS und MOM sind kostenpflichtige Produkte der Firma Microsoft. Lizenziert wird die
Server Software. Darüber hinaus wird für jeden Client, der eine Komponente des SMS
oder MOM benötigt, eine Clientlizenz benötigt. Im Detail stellt sich dies wie folgt dar:
Produkt
Lizenzierung
Microsoft Systems Management
Server 2003
Für jede erworbene Lizenz kann eine Kopie der Serversoftware auf einem einzigen Server installiert und
genutzt werden.
Server 2003 Device CML (Configuration Management License)1
Erlaubt es einem Gerät (einem einzelnen Server,
einem einzelnen Personal Computer, einer Workstation, einem Terminal, einem Handheld Computer,
Pager, Telefon, Personal Digital Assistant oder anderem elektronischen Gerät), von Microsoft Systems
Management Server 2003 verwaltet zu werden.
Server 2003 mit SQL Server 2000Technologie
Erlaubt es, eine Kopie von Microsoft Systems Management Server 2003 Software auf einem einzigen
Server zu installieren, und erlaubt, eine Kopie der
Serversoftware von Microsoft SQL Server 2000 auf
einem einzigen Server zu installieren und zu verwenden.
Die SQL Server-Software darf nur verwendet werden,
um ihre Systems Management Server Primary Site
Server und/oder Operations Manager als Teil Ihrer
Systemverwaltungssoftware zu unterstützen.
Tabelle 48: Lizensierung der Microsoft System-Management-Komponenten
Seite 299
SMS und MOM sind eigenständige Softwareprodukte der Firma Microsoft. Sie sind in die
Microsoft Landschaft integriert und benötigen zusätzliche Komponenten (zum Beispiel
SQL Server und MS Server), um lauffähig zu sein. SMS und MOM können nicht als
eigenständige Applikationen für andere Betriebssysteme, zum Beispiel Linux, erworben
werden.
SMS 2003 R2 kann in Großumgebungen mit über 250.000 Clients eingesetzt werden,
wobei ein einzelner Server bis zu 25.000 Clients verwalten kann.
Die in der Einleitung beschriebenen Grundfunktionen von System-Management-Systemen werden mit SMS und MOM vollständig abgedeckt. Die Funktionen werden nicht
als eigenständige Module vertrieben, das heißt, die Funktionen sind in die SMS und
MOM Software eingebunden.
Der SMS / MOM Client kann auf folgenden Betriebssystemen installiert werden:

Microsoft Windows 98

Windows NT® Workstation 4.0

Windows NT Server 4.0

Windows NT Server 4.0 Enterprise Edition mit Service Pack 6 oder höher

Windows 2000 Professional

Windows 2000 Server

Windows 2000 Advanced Server

Windows 2000 Datacenter Server

Windows XP Professional

Windows XP Embedded mit Service Pack 1 oder höher

Windows Server 2003 Standard Edition

Windows Server 2003 Enterprise Edition

Windows Server 2003 Datacenter Edition
Das im Migrationsleitfaden V2.1 beschriebene Add-On namens Vintela Management
Extensions (VMX), mit dessen Hilfe auch Linux-, Unix- und Mac-Systeme (OS X) unterstützt werden können, wird in dieser Art nicht mehr angeboten. Für SMS 2003 gibt es ein
lizenzpflichtiges Add-On mit dem Namen Quest233 Management Xtensions for SMS 2003
der Firma Quest Software, das die oben genannte Unterstützung anbietet.
Das Add-On unterstützt im Standard folgende Funktionen:
233

Softwarepatchverteilung

Softwareverteilung

Inventarisierung (Hardware und Software)

Softwaremessungen
http://www.quest.com/
Seite 300

Entdecken von Systemen

Remote Werkzeuge

Reporting
Damit eignet sich SMS in der Kombination mit Quest Management Xtensions für SMS
2003 durchaus auch für den Einsatz in heterogenen Systemlandschaften.
Für den Betrieb einer MOM 2005 Umgebung müssen folgende Komponenten auf einem
oder mehreren Servern installiert werden:

Microsoft Operations Manager 2005-Managementserver

Microsoft Operations Manager 2005-Datenbank

Microsoft Operations Manager 2005-Administratorkonsole und die
Operatorkonsole

Microsoft Operations Manager 2005-Reportingserver
Die minimalen Hardwareanforderungen und weiteren Empfehlungen zur Installation
dieser Umgebung können auf der Microsoft-Homepage nachgeschlagen werden.234
Mit MOM 2005 können zahlreiche Systeme überwacht werden. Welche Konfigurationen
unterstützt werden, kann auf der Webseite235 „Unterstützte Konfigurationen für Microsoft
Operations Manager 2005― von Microsoft nachgeschlagen werden236:
Über weitere Management Packs, die von Microsoft und Drittherstellern erhältlich sind,
kann die Überwachung auf viele andere Systeme (nicht nur Betriebssysteme, sondern
zum Beispiel auch Storagesysteme oder aktive Netzwerkkomponenten) ausgeweitet
werden. Eine Liste mit über 200 Management Packs von Microsoft und Drittherstellern
mit Beschreibung des Management Packs und Quellenangabe des Herstellers ist bei
Microsoft aufgelistet.237
Einige sind hier aufgeführt:
234
235
236
237

Exchange 5.5/2000/2003

SQL Server 2000 / 2005

Windows DHCP Server Service 200 / 2003I

Commerce Server 2007

Windows Print Server 2000 / 2003

Windows Terminal Services 2000 / 2003

Proxy Server 2.0

Windows DNS Server Service 2000 / 2003

Windows Internet Information Server 2000/ 2003
http://www.microsoft.com/germany/mom/uebersicht/systemanforderungen.mspx
http://www.microsoft.com/germany/technet/datenbank/articles/600585.mspx#EEC
http://www.microsoft.com/germany/technet/datenbank/articles/600585.mspx#EEC
http://www.microsoft.com/technet/prodtechnol/mom/catalog/catalog.aspx?vs=2005
Seite 301

Windows Active Directory 2000 / 2003

SMP for Linux Server

Virtual Agent for: Mandrake Linux, Open BSD, Red Hat Linux, Sun Solaris, SuSe
Linux

SMP – Cisco für: Switches, Router und Concentrators
Wie auch für SMS 2003 R2 gibt es für MOM 2005 ein lizenzpflichtiges Add On mit dem
Namen Quest Management Xtensions for MOM der Firma Quest Software, das die
Funktionen von MOM zur Überwachung der Betriebssysteme AIX, Solaris, HP-UX, RED
HAT und Suse erweitert.
Das Add-On unterstützt folgende Funktionen:

Reporting

Ereignis- und Leistungsmanagement

Applikation Monitoring
SMS und MOM bieten, wie beschrieben, umfangreiche Möglichkeiten, um Schnittstellen
von Drittanbietern einzubinden. Weiter sind die Produkte komplett in die Microsoft Welt
eingebunden und arbeiten mit allen Microsoft Produkten zusammen.
Somit lässt sich zusammenfassend festhalten, dass die Kombination von SMS und MOM
in einer homogenen Microsoftlandschaft durch die Integration in die MS Landschaft eine
gute Lösung für die Verwaltung von Computerressourcen ist. Darüber hinaus besteht die
Möglichkeit, Geräte wie zum Beispiel PDAs in SMS oder MOM einzubinden und diese
mit Software zu versorgen oder zu überwachen. Dies ist in der Regel leicht realisierbar.
1.3
HP OpenView
HP bietet unter dem Namen OpenView eine Produktfamilie an, die in ihrer Funktionalität
weit umfangreicher ist, als die Funktionen des System-Management(systems). Entstanden ist HP OpenView aus dem HP OpenView Node Manager238. Dieses Programm wurde früher nur zur Überwachung und Administration von Netzwerken genutzt.
HP OpenView ist kostenpflichtig und kann über HP oder seine Vertriebspartner bezogen
werden.
OpenView wird in zwei Versionen angeboten. Die eine Version ist der Management Server, die zweite ist eine Java Implementation der Management Server genannten Java
Konsole.
Der Management Server kann auf folgenden Betriebssystemen installiert werden:
238

HP-UX (PA-RISC, Itanium)

Solaris (SPARC)
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-1115-119^1155_4000_100_
Seite 302
Bei beiden Installationen ist der Einsatz einer Oracle Datenbank notwendig.
Die Java Konsole kann laut Herstellerangaben auf nachfolgend genannten Betriebssystemen installiert werden, wobei hier immer eine Java Runtime Umgebung installiert werden muss:

HP-UX

Sun Solaris

Microsoft Windows

Red Hat Linux
Auch HP OpenView enthält Module für Storage- und Prozess-Management. Die HP
OpenView Module können einzeln verwendet und entsprechend kombiniert werden.
Somit können mit HP OpenView alle Anforderungen an eine System-Managementsoftware abgedeckt werden.
Folgende Client Betriebssysteme werden u.a. durch OpenView unterstützt:

HP-UX, Sun Solaris

Microsoft Windows

IBM AIX

Tru64 UNIX

Red Hat Linux

SuSE Linux

Turbo Linux

Debian Linux

Novell Netware

OpenVMS

HTTPS-based agents

HP NonStop Servers

IBM OS/390

z/OS

IBM OS/400
HP OpenView bietet für alle gängigen Systeme Module und Erweiterungen für SystemManagement-Funktionen an. Auf Grund der Historie von HP OpenView als verbreitetes
Werkzeug für Netzwerkmanagement wird HP-OpenView in vielen Organisationen inzwischen auch als System-Management-System eingesetzt.
Damit bietet HP-OpenView eine erprobte System-Management-Umgebung, mit der die
Belange des System-Managements in heterogenen Landschaften gut abgedeckt werden
können.
Seite 303
1.4
IBM Tivoli System-Management
Tivoli239 wurde von der gleichnamigen Firma als System-Management und Storagemanagement System entwickelt. In den 90er Jahren kaufte IBM die Firma Tivoli auf, die
inzwischen eine 100%ige Tochter von IBM ist. IBM hat die Tivoli Produktpalette erheblich erweitert. Inzwischen besteht die Tivoli Produktfamilie aus über 70 einzelnen Modulen. Diese umfassen auch Storagelösungen und Module für Prozessmanagement. In
diesem Kapitel werden nur diejenigen Funktionen betrachtet, die notwendig sind, um die
in der Einleitung dieses Kapitels beschriebenen Funktionalitäten abzubilden. Für IBM
Tivoli gibt es eine umfangreiche Online Dokumentation.
Tivoli ist ein kostenpflichtiges Produkt. Hierbei werden pro eingesetztes Modul und je
Client Lizenzgebühren erhoben.
Tivoli ist kein monolithisches Programm. Es besteht aus vielen einzelnen Modulen, die
entsprechend ihrer Funktion kombiniert werden können. Mit seinen über 70 Modulen
bietet es alle Funktionen, die für die Durchführung von System-Management benötigt
werden. In welchen Kombinationen die Module für die einzelnen Einsatzgebiete erforderlich sind, sollte mit Hilfe des Herstellers erarbeitet werden. Dies gilt insbesondere bei der
Einführung eines entsprechenden Systems.
Alle Tivoli Module unterstützen die Überwachung und Administration folgender Betriebssysteme:

AIX

HP-UX

Linux

SUN Solaris

Windows NT

Windows 2000

Windows 2003
Tivoli bietet für alle gängigen Systeme Module und Erweiterungen für SystemManagementfunktionen an.
Damit ist festzuhalten, dass Tivoli in einer heterogenen Landschaft ein bewährtes System-Management-Programmpaket ist, welches sich seit Jahren im Einsatz befindet. Aufgrund der Lizenzbedingungen kann bei großen Netzwerken die Ermittlung der Kosten
jedoch schwierig sein, da bei einer Vielzahl von Modulen diese gegebenenfalls separat
für jeden Client und jedes Modul lizenziert werden müssen.
2
Migrationspfade
Eine Migration von System-Management-Software kann je nach Umfang der eingesetzten Funktionen und der Größe der Netzwerkinfrastruktur ein sehr umfangreiches und
komplexes Vorhaben sein. Gerade dann, wenn nicht nur Anwendungen zur Überwa-
239
http://www-306.ibm.com/software/de/tivoli/
Seite 304
chung, sondern auch Anwendungen für SW-Verteilung, Fernsteuerung und so weiter
eingesetzt werden, ist eine Migration sehr zeitaufwendig und Bedarf einer sorgfältigen
Planung. Zum Beispiel ist es nur sehr schwer möglich, von einem Softwareverteilungssystem auf ein anderes zu wechseln, ohne dass die einzelnen Pakete zur Softwareverteilung neu erstellt werden müssen. Am Unkritischsten ist die Migration der Anwendungen für Überwachungsfunktionen. Für die im Kapitel Technologie beschriebenen Softwaregruppen sind dies:

Nagios

IBM Tivoli Monitoring

HP OpenView Node Manager

Microsoft SMS
Eine Migration von Systemmanagementsoftware sollte stets auch unter einem gesamtwirtschaftlichen Aspekt betrachtete werden. Konkret: Es sind nicht nur die Aufwendungen für die Migration zu betrachten, sondern auch die positiven oder negativen Auswirkungen auf die Betriebskosten nach einer Migration. Sicherlich stellt sich zunächst die
grundlegende Frage, ob beziehungsweise warum von einer proprietären Lösung zu einer
anderen proprietären gewechselt werden sollte, zum Beispiel von IBM nach HP oder von
HP nach Microsoft. Die Argumente für und wider eine solche Migration sind im Vorfeld
eindeutig herauszuarbeiten. Hingegen ist eine Migration hin zu OSS Software unter rein
finanziellen Aspekten sicherlich immer reizvoll.
2.1
Migration von Tivoli System-Management nach HP Open View
Die Migration von Tivoli System-Management nach HP OpenView stellt eine Migration
von einem proprietären System in ein anderes proprietäres System dar. Hierbei bietet
HP auch Unterstützung für eine solche Migration an. Aufgrund der Komplexität der beiden Produktfamilien ist aber genau darauf zu achten, welche Unterstützungsleistung
tatsächlich benötigt wird. So bietet HP u.a. ein Migrationstool an, welches die Migration
von IBM Tivoli Service Desk nach HP OpenView Service Desk unterstützt. Beide Programme dienen nicht zur Unterstützung des System-Managements, sondern zur Unterstützung von Service Desk Funktionalitäten. Sie gehören dennoch zur gleichen Produktfamilie des System-Managements. Eine Migration von IBM Tivoli nach HP OpenView
stellt sich in der Regel als Neuaufbau eines HP OpenView Systems und der späteren
Abschaltung des IBM Tivoli Systems dar. Dies hat mehrere, nachfolgend kurz aufgeführte Gründe:

Geringe Unterbrechungen des Systemmanagements während der Migrationszeit

Chance zur Neukonzeption der Überwachungsfunktionen und Regeln

Überprüfung der neuen Überwachungslandschaft durch Vergleich mit bestehenden Daten

Möglichkeit zur Abschaltung des alten Überwachungssystems, wenn das neue
System voll funktional und abgenommen ist

Möglichkeit, die IBM Tivoli Clients nacheinander gegen die HP OpenView Clients
auszutauschen.
Seite 305
Diese Vorgehensweise birgt allerdings das finanzielle Risiko, dass während der gesamten Migrationszeit, die gegebenenfalls auch länger als geplant sein kann, evtl. anfallende
Lizenzkosten, SW-Wartungskosten und Supportkosten für beide Systeme entrichten
werden müssen.
2.2
Migration von proprietärer Systemüberwachungssoftware nach Nagios
Obwohl in diesem Kapitel nur auf die eingangs erwähnte Migration von Systemüberwachungssoftware fokussiert wird, seien vorab einige allgemeine Anmerkungen zur Migration von System-Managementsoftware nach OSS aufgeführt.
Beim System-Management folgen die meisten OSS-Betriebssysteme entsprechend ihrer
Herkunft dem UNIX-Weg. Als Mehrbenutzer- und Netzwerksysteme sind die Funktionen
für das zentrale System-Management bei den OSS-Systemen sehr vielfältig und in
einigen Bereichen das Vorbild und nicht die ersetzende Alternative zu einer WindowsLösung. Für Administratoren und Betriebsorganisation sind bei einer Migration auch
konzeptionelle Änderungen zu erwarten, die insbesondere bezüglich der Sicherheit
große Fortschritte ermöglichen. Die Sicherheit und Zuverlässigkeit, die den LinuxSystemen allgemein zugeschrieben wird, ist nicht zuletzt das Resultat des SystemManagements.
Für diejenigen Personen, die mit dem System-Management betraut sind, bedeutet ein
Migrationsprojekt deutliche Veränderungen. Sowohl die Möglichkeiten zur Analyse als
auch die Optionen zur Anpassung und Korrektur der OSS-Systeme erlauben den Systemadministratoren höhere Freiheitsgrade, als vergleichsweise bei einem geschlossenen
Windows-System gegeben sind. Diese Freiheit kann dazu genutzt werden, sich von
Herstellern und externen Dienstleistern zu emanzipieren und gleichzeitig die Qualifikation der eigenen Mitarbeiter zu erhöhen. Die Transparenz der offenen OSS-Systeme erleichtert das grundsätzliche und tiefgreifende Verständnis von Funktion und Abhängigkeiten der verschiedenen Komponenten in einer modernen IT-Infrastruktur.
Bei der Migration von Systemüberwachungssoftware nach Nagios sollte man die Möglichkeit nutzen, zuerst das Nagios System aufzubauen und erst danach das proprietäre
System abzuschalten. Zumal sich hierbei das finanzielle Risiko auf die Bereitstellung
einer Hardware-Plattform beschränkt, die während des Migrationszeitraums parallel zur
Verfügung gestellt werden muss.
2.3
Migration von SMS 2.0 nach SMS 2003
Der System Management Server 2003 (SMS) ist die Nachfolgeversion des System Management Server 2.0. SMS 2003 beinhaltet im Wesentlichen die gleichen Funktionalitäten wie der SMS 2.0, die aber auf fast allen Ebenen verbessert wurden. Zur Migration
bietet Microsoft umfangreiche Unterstützung auf seinen Webseiten an 240.
Eine Migration kann über mehrere Wege erfolgen, zum einen über „Bordmittel―, durch
Kopieren, und durch generierte Reports und zum anderen durch das SMS Migration Tool
240
http://www.microsoft.com/germany/aktionen/partnerfinden/solutionfinder/ default.mspx?solutionid=9ae215677c5d4379ab02f86a817c0523
Seite 306
(CCSMT) das von Microsoft zur Verfügung gestellt wird. Dieses Tool wird von Computacenter im Rahmen des Solution Finder Programms von Microsoft angeboten 241.
Die Komplexität einer Migration von SMS2.0 zu SMS 2003 ist sicherlich als gering anzusehen. Dennoch ist ein erheblicher zeitlicher Aufwand notwendig, der bei der Planung
nicht unterschätzt werden darf.
3
3.1
Bezüge
Netzwerkdienste
System-Überwachungs- und Management-Dienste sind komplexe Werkzeuge, die mit
den Anwendungen und Protokollen, die von ihnen überwacht werden, in Verbindung
stehen müssen. Diese Interaktion geschieht in der Regel über eigene Protokolle, die in
Netzwerken weitergeleitet werden. Je nach Technologie entstehen hierdurch Bezüge zu
dem Thema Netzwerkdienste (Kapitel II.C 3.1). Die darin beschriebenen Netzwerkdienste können in vielen LANs grundlegende Verantwortung für die Identifikation von Rechnern in Netzwerken tragen und sind somit auch für Systemüberwachungsdienste von
Bedeutung.
3.2
Webserver
Systemüberwachungsdienste stellen ihre gewonnenen Überwachungsdaten gelegentlich
im HTML oder XML Format auf Massenspeichern ab (z.B. MRTG). Diese Daten werden
häufig von einem Webserver an einer bestimmten Webadresse passwortgeschützt veröffentlicht. Da dieser Art von Anwendungen auch sicherheitsrelevante Überwachung zur
Aufgabe hat, werden die Überwachungsdaten gelegentlich auf externe Geräte oder
Computer übertragen, um diese im Falle eines Dateneinbruchs vor Manipulation zu
schützen. Es entstehen hierdurch je nach Anwendung und Installation Bezüge zu den
Themen Webserver (siehe II.A ).
241
http://www.microsoft.com/germany/mittelstand/partner/ partnerfinder.mspx?solutionid=9ae215677c5d4379ab02f86a817c0523
Seite 307
III. Modul Anwendungen
A Thema Messaging und Groupware
Eine Software, welche die Zusammenarbeit in einer Gruppe über räumliche und zeitliche
Distanzen hinweg ermöglicht, wird als Groupware bezeichnet. Groupware-Systeme vereinen eine Reihe von Funktionalitäten und Diensten unter einem Dach. Klassisch sind
dies

E-Mail-Austausch,

Adressbuch,

Kalender mit Terminplanungsfunktionalitäten für persönliche Termine und innerhalb von Gruppen (Gruppen-Kalender),

Notiz- und Aufgabenverwaltung

Öffentliche/Gruppen-Ordner
Einige der hier betrachteten Groupware-Systeme stellen darüber hinaus auch Funktionen wie Ressourcenverwaltung oder Foren zur Verfügung.
In den folgenden Abschnitten werden verschiedene dieser Systeme betrachtet.
1
1.1
OpenGroupware.org
OpenGroupware.org (OGo)242 ist eine der ältesten Groupware-Lösungen auf dem Markt
und – ähnlich wie andere Open Source Software Lösungen – aus einem ehemals proprietärem Produkt, „Skyrix― der Skyrix Software AG243 ,entstanden. Im Sommer 2003 hat
die SKYRIX Software AG244 das gleichnamige Produkt unter den Lizenzbedingungen der
GNU GPL/LGPL freigegeben. Seit diesem Zeitpunkt wird die Software unter dem Namen
OpenGroupware.org als Community-Projekt weiterentwickelt.
Neben Opengroupware.org mit seiner eigenen webbasierte Benutzeroberfläche gibt es
von Skyrix noch den ZideLook Connector, mit dem Outlook Clients angebunden werden
können. Weiterhin kann auf den OpenGroupware-Server durch sogenannte „native
Clients― wie z. B. Microsoft Outlook, Mozilla Calendar oder Apple iCal.app zugegriffen
werden.
Als „instantOGo― gibt es auch eine vollständige Linux-Distribution mit Betriebssystem,
Groupwarekomponenten und Hilfsprogrammen.
242
243
244
http://www.opengroupware.org
http://www.skyrix.de
Skyrix ist ein kleines Unternehmen mit Sitz in Magdeburg (ca. 15 Mitarbeiter).
Seite 308
Der ZideLook Connector sowie instantOGo245 werden von Skyrix genau wie der Support
und die Wartung zu OpenGroupware.org kostenpflichtig angeboten.
OpenGroupware.org wird am häufigsten in der Dienstleistungsbranche und in der öffentlichen Verwaltung eingesetzt. Über die Zahl der Installationen liegt keine Information vor,
da die Software frei heruntergeladen und ohne Registrierung installiert werden kann.
Derzeit liegt OpenGroupware.org in der Version 1.0.0 vom Januar 2007 vor, ZideLook,
der Outlook-Konnektor von Skyrix, in der Version 2.1 vom Juni 2007 und InstantOGo in
der Version 2.0 vom Mai 2007.
Die folgende Abbildung zeigt die grundlegende Architektur des Groupwaresystems im
Zusammenspiel mit anderen OSS Komponenten.
Abbildung 31: OpenGroupware-Architektur246
OpenGroupware.org ist eine Server-Anwendung, die von Anwendern über Web-Browser
bedient wird. Es stehen zusätzlich Schnittstellen für die Mehrzahl der am weitesten
verbreiteten Groupwareclients zur Verfügung (s.o.).
Derzeit stehen Pakete für die Installation auf x86-Linux Distributionen von Debian, Suse,
RedHat und Mandrake sowie für FreeBSD zur Verfügung. Neben der Kernanwendung,
die in Objective-C geschrieben wurde, setzt OpenGroupware.org auf bewährte Standardkomponenten wie PostgreSQL, Apache oder Cyrus IMAP.
245
246
Weitere Information unter http://instantogo.com.
Quelle: http://www.opengroupware.org/en/devs/docs/OGoArchitecture.html
Seite 309
Der Server bietet folgende Funktionen:

Gruppenterminplanung,

Kontakte (Personen, Unternehmen),

Ressourcen-Management,

Aufgabenverwaltung (Task-Management),

Projektcontainer zur Verwaltung von Dokumenten (inklusive Versionierung),
Notizen und Aufgaben,

E-Mail (mit zusätzlichem Mailserver, beispielsweise dem Cyrus IMAP),

umfassendes Rechte-Management für Kontakte, Termine, Aufgaben und
Projekte,

Palm-Synchronisation,

CTI API zur Integration von TK-Anlagen.
Das Backend zeichnet sich durch eine modulare Architektur und vor allem durch das
Vorhandensein einer umfangreichen XML-RPC API aus. Mit dieser API können nahezu
alle Funktionalitäten, die über die webbasierte Nutzerschnittstelle oder andere Clients
genutzt werden können, ausgeführt werden.
Zur Unterstützung einer großen Anzahl von parallel arbeitenden Nutzern besteht die
Möglichkeit der horizontalen Skalierung, zum Beispiel durch die Verwendung der Software Loadbalancer247. Diese Software verteilt die einzelnen OGo Prozesse je nach Lastsituation auf verschiedene Knoten im Clusterverbund. Dieses Verfahren kann auch zur
Gewährleistung von Ausfallsicherheit genutzt werden.
Die Webschnittstelle ist die primäre Benutzerschnittstelle des OpenGroupware.orgServers. Der Anwender verfügt über die Möglichkeit, die Ansichten der Weboberfläche
seinen persönlichen Bedürfnissen anzupassen. Zentrale Komponenten zur Organisation
von Gruppen- und Einzelterminen, Ressourcen und Kontakten sind ebenso integriert wie
Projektcontainer, die sowohl Aufgaben, Notizen und Dokumente aufnehmen und entsprechend der vergebenen Zugriffsrechte den Teammitgliedern zur Verfügung stehen. In
jedem Projektcontainer lassen sich beliebige Ordnerstrukturen erzeugen, in denen
Dokumente mittels eines Check-In/Check-Out-Verfahrens versioniert gespeichert und ab
OGo 1.0 zusätzlich über WebDAV zur Verfügung gestellt werden. Über den eingebauten
WebMailClient wird der Zugriff auf IMAP4-Postfächer ermöglicht, wobei auch serverseitige Filter, Abwesenheitsnotizen und Mailquotas über den Webbrowser verwaltet
werden können, sofern diese Funktionen vom IMAP Server unterstützt werden 248.
Outlook-Anwender benötigen einen proprietären und kostenpflichtigen Konnektor, der
von der SKYRIX Software AG unter dem Produktnamen „ZideLook― angeboten wird. Die
Lösung besteht aus einem „MAPI Storage Provider"-Plugin für Outlook und einem
zusätzlichen Servermodul für OpenGroupware.org. Zwischen Server und Client erfolgt
keine Synchronisation der Daten sondern ein Direktzugriff auf die „live" Daten des
247
248
Der Loadbalancer steht im Rahmen des Wartungsvertrages zur Verfügung.
Es empfiehlt sich beispielsweise die Verwendung des Cyrus IMAP Servers.
Seite 310
Groupware-Servers. Das ZideLook-Plugin übersetzt dabei die MAPI Aufrufe von Outlook
in Aufrufe gemäß dem standardisierten WebDAV Protokoll und sendet sie an den
ZideStore Server. Dieser liefert die OGo-Groupware-Daten im XML-Format aus. Der
noch fehlende Replikationsmechanismus schränkt jedoch die Nutzung für mobile
Anwender ein. ZideLook ermöglicht den Zugriff auf den privaten Kalender, auf die private
Aufgabenliste, auf Gruppenkalender und Gruppen-Aufgabenlisten sowie auf öffentliche
(globale) und private Kontakte. Aktuell werden die Outlook Versionen 2000, XP und
2003 offiziell unterstützt.
PalmOS-basierte PDAs und Smartphones können direkt über den in OGo enthaltenen
NetworkHotSync Daemon serverseitig angebunden werden. Alle Einstellungen zur
Übernahme von Kontakten, Terminen und Aufgaben kann der Anwender dabei über die
Webschnittstelle vornehmen. Neben dem Abgleich über die klassische USB-Dockingstation ist auch die Datenübermittlung im mobilen Betrieb über Handys mittels IrDA,
Bluetooth und WLAN möglich. Anwendern von PocketPC beziehungsweise WindowsCE
Endgeräten oder aktuellen Smartphones steht derzeit nur die Anbindung über den
MS Outlook Client zur Verfügung.
Je nach Einsatzszenario erfolgt die Administration über die Webschnittstelle oder direkt
mittels der Kommandozeile auf den Servern. So sind die Verwaltung von Nutzern,
Teams, Ressourcen für die Terminplanung oder die Verwaltung von Kategorien für das
Kontaktmanagement einfach und auch von Anwendern ohne Linuxerfahrung über den
Browser realisierbar. Durch die Verwendung von Nutzer-Vorlagen lassen sich einmal
definierte Benutzerprofile auf neu einzurichtende Nutzer vererben. Alternativ bietet sich
bei der Integration großer Nutzerzahlen die Verwendung eines LDAP-basierten
Verzeichnisdienstes an, der über das XML-RPC API integriert werden kann. Diese
Schnittstelle ermöglicht darüber hinaus den skriptgesteuerten Zugriff auf nahezu alle
Funktionalitäten des OGo Applicationservers und stellt somit eine Möglichkeit zur Automatisierung komplexer Initialisierungsprozesse dar.
Das Design der Weboberfläche ist vollständig in Templates beschrieben, wobei beliebig
viele dieser Template-Sets angelegt werden können und dem Nutzer dann wahlweise
zur Verfügung stehen. Auf diesem Weg kann der Administrator auch sehr einfach
gewünschte Anpassungen an existierende Corporate Design Festlegungen vornehmen.
Diese einfache Möglichkeit wird außerdem zur Lokalisierung der Weboberfläche benutzt,
die bereits heute in 13 Sprachen zur Verfügung steht.
OpenGroupware.org unterstützt die Verschlüsselung des Datentransfers zwischen
Server und dem jeweils verwendeten Clientsystem über SSL. Für die Anbindung von
Outlook und PalmOS Endgeräten ist der Einsatz eines geeigneten SSL-Tunnels zu
empfehlen. Dies gilt auch für die Kommunikation zwischen den einzelnen Servern,
sofern einzelne Komponenten wie beispielsweise der IMAP-, LDAP- oder SQL-Server
zwecks Lastverteilung auf separaten Servern betrieben werden sollen und diese über ein
als unsicher einzuschätzendes Netz miteinander verbunden sind.
OpenGroupware.org unterstützt derzeit keine S/MIME beziehungsweise PGP Mailverschlüsselung im webbasierten Mailclient. Eine entsprechende Erweiterung ist geplant.
OpenGroupware.org besitzt keinen eigenen Spam- oder Virenschutz, jedoch können alle
zum jeweiligen MTA kompatiblen Spam- und Antivirenprogramme verwendet werden.
Seite 311
Neben der Webschnittstelle und dem proprietären Outlook-Konnektor ZideLook steht
eine XML-RPC-Schnittstelle mit umfangreichen Möglichkeiten zur Verfügung. Es existieren dazu auch Werkzeuge, die allerdings bisher nur im Projektgeschäft verwendet
wurden.
Da OGo einen Standard-Mailserver wie Cyrus-IMAP und Postfix-SMTP einbindet,
werden alle gängigen Protokolle unterstützt. OpenLDAP ist über XML-RPC integriert,
somit steht auch eine LDAP-Schnittstelle zur Anbindung von Active Directory und LDAPDirectories bereit.
Über die MAPI-Schnittstelle von ZideLook kann auf Termine, Kontakte und Aufgaben
zugegriffen werden. Da die MAPI-Nachrichten aus Outlook dekodiert und im SQLBackend abgelegt werden, stehen sie auch anderen Clients sowie der Weboberfläche
zur Verfügung.
Der Datenaustausch findet über die Clients statt; damit werden alle in den Clients integrierten Formaten unterstützt, zum Beispiel die von Outlook (ab Version 2000).
Zusammenfassend ist festzuhalten: OpenGroupware.org verfügt über GroupwareFunktionen mit einer mächtigen Weboberfläche, die über die Funktionalität von Outlook
hinausgeht. Es werden Anbindungsmöglichkeiten an gängige Clients wie Outlook unter
Windows und Evolution unter Linux angeboten. Die Synchronisation mit mobilen Endgeräten ist dann schwierig, wenn nicht mit Outlook als Client synchronisiert wird.
Über die XML-RPC-Schnittstelle und über direkten Zugriff auf die SQL-Datenbank ist ein
Datenaustausch mit anderen Systemen möglich; gängige Protokolle wie SSL, LDAP,
MAPI, IMAP, SMTP werden unterstützt.
1.2
OpenXchange
Open-Xchange Server 5 unterstützt Teamarbeit mit Basisdiensten wie E-Mail, Terminund Kontaktverwaltung. Darüber hinaus liefert Open-Xchange integrierte Module zum
Dokumentenaustausch, zur Aufgaben- und Projektsteuerung, zum Aufbau einer
Wissensdatenbank und eines Forums.
Mit Open-Xchange OXtender werden Offline-Clients wie Microsoft Outlook angebunden
und die Synchronisierung mit Smartphones und Palm Pocket PCs realisiert.
Im August 2004 wurde die ursprünglich proprietäre Groupware-Komponente Comfire
unter dem Namen Open-Xchange als freie Software unter GPL zur Verfügung249 gestellt
und nach dem OpenSource-Modell weiterentwickelt. Open-Xchange wird in Deutschland
an den Standorten Olpe und Nürnberg entwickelt und ist darüber hinaus in den USA in
Tarrytown, New York, vertreten.
Ein weltweites Partnernetzwerk250 bietet neben integrierten Open-Xchange-Lösungen
auch die Kompetenz zur Unterstützung bei der Planung, Implementierung und dem
Support von komplexen Integrationsprojekten.
249
250
http://www.open-xchange.com/header/community_area.html
http://www.open-xchange.com/DE/header/partner/partner_suchen.html
Seite 312
Für das Jahr 2006 nennt Open-Xchange mehr als 2000 registrierte Installationen des
Open-Xchange Server 5 im deutschsprachigen Raum. Zum Kundenkreis 251 von OpenXchange gehören Unternehmen, Bildungseinrichtungen und Behörden mit z.T. mehreren
Tausend Endbenutzern pro Organisation.
Seit Februar 2007 bietet der Webhoster 1&1252 den webbasierten Groupware-Dienst
MailXchange auf Basis von Open-Xchange an. Mit dieser Lösung werden Zielgruppen
wie Freiberufler und kleine Unternehmen angesprochen.
Im April 2005 wurde Open-Xchange Server 0.8.0 fertiggestellt. Seitdem folgten mehrere
Versionen253 und Service Packs. Im März 2007 erfolgte die Veröffentlichung der Version
Open-Xchange Server 0.8.6 und im Juni 2007 stellte Open-Xchange das Service Pack 3
seinen Anwendern zu Verfügung. Open-Xchange Server 0.8.x läuft unter der kostenlosen GNU General Public License, Version 2 der Free Software Foundation. Zusätzlich
stellt Open-Xchange für die Anbindung von MS Outlook an Open-Xchange Server 0.8.x
eine kostenlose GPL-Version des OXtender zur Verfügung.
Mit Open-Xchange Community Edition wird Open-Xchange als kostenlose GPL-Version
angeboten, die zusätzlich die Creative Commons Attribution-NonCommercialShareAlike 2.5254 vereinbart. Diese Edition von Open-Xchange bietet gegenüber OpenXchange Server 0.8.x eine optimierte Server-Architektur und einen AJAX-basierten
Webclient, jedoch zurzeit nicht die Funktionen Forum, Projekte and Pinnwand. Außerdem ist die Anbindung von Offline-Clients über OXtender nicht möglich. Installationsund Konfigurationshinweise findet man im Wiki255 von Open-Xchange. Falls weiterreichende Unterstützung erforderlich ist, steht das Open-Xchange Forum zur Verfügung.
Zusätzlich werden die Produkte Open-Xchange Server 5, Open-Xchange Express Edition und Open-Xchange Hosting Edition angeboten. Der propietäre Open-Xchange Server
5 bietet über den Umfang der kostenlosen GPL-Version und hinaus Werkzeuge für die
Installation und Administration sowie eine Dokumentation für Benutzer den Zugang für
ein Jahr zu den Leistungen des Open-Xchange Maintenance Portals. Das Maintenance
Portal stellt kontinuierlich weitergehende Funktionalitäten in Form von regelmäßigen
Updates zur Verfügung sowie Dokumentationen für Endanwender und Administratoren.
Darüber hinaus bietet Open-Xchange seinen Kunden Installations-Support per E-Mail
ohne sowie mit garantierten Antwortzeiten.
Das Produkt Open-Xchange Express Edition256 ist eine Komplettlösung und enthält neben dem Betriebssystem (optimiertes Ubuntu), auch E-Mailserver (Cyrus IMAP & Postfix), Collaborationserver, Webserver (Apache), Datenbank (MySQL), Dokumentenverwaltung, Installationswerkzeug, Administratormodul, Backup, automatischen UpdateDienst, Anti-Virenschutz (ClamAv) und Anti-Spam (SpamAssassin).
251
252
253
254
255
256
http://www.open-xchange.com/DE/header/unternehmen/news_presse/referenzen.html
http://www.1und1.de/
http://www.open-xchange.com/wiki/index.php?title=Versioning_and_Numbering
http://www.open-xchange.com/header/community_area/faqs_ox_community_project.html
http://www.open-xchange.com/main_entry/community_area/wiki.html
http://www.open-xchange.com/fileadmin/downloads/oxee/Tech_Fact_Sheet_DE.pdf
Seite 313
Für Internet Service Provider und Webhosting-Anbieter bietet Open-Xchange mit der
Open-Xchange Hosting Edition Werkzeuge zur Systemüberwachung und für optimierte
Lastverteilung, Geschwindigkeit, Clustering und Skalierbarkeit.
Open-Xchange Server 5 unterstützt die beiden Linux-Betriebssysteme Red Hat Enterprise Linux 4 und Suse Linux Enterprise Server 9. Da Novell eine geeignete Version
seines Enterprise-Linux Betriebssystems kostenlos per Download zur Verfügung stellt,
wird an dieser Stelle auch die dazu abgestimmte Version des Open-Xchange Servers
angeboten.
Die aktuelle Preisliste257 mit Behördentarifen kann auf den Unternehmensseiten von
Open-Xchange eingesehen werden.
Die Architektur von Open-Xchange Server 5 basiert vollständig auf offenen Standards
und Protokollen. Die gesamte Lösung besteht aus unterschiedlichen modularen Software-Einheiten, die im Zusammenspiel die Mail- und Groupware-Funktionalitäten realisieren. Die Basis der Groupware-Lösung bildet der Java-basierte Open-Xchange Application-Server.
Abbildung 32: Open-Xchange Architektur258
Aufgrund der modularen und offenen Architektur kann Open-Xchange Server in
bestehende IT-Umgebungen integriert werden und ermöglicht somit eine Erweiterung
bestehender Systeme. Über standardisierte Schnittstellen kann die Server-Funktionalität
an unterschiedliche Bedürfnisse angepasst werden. Über die sogenannten OXtender
lassen sich bei Bedarf zusätzliche Funktionen und Programme von Drittanbietern
anbinden. Beispiele hierfür sind OXtender für MS Outlook, Palm OS, Samba Services
und SynchML.
257
258
http://www.open-xchange.com/fileadmin/downloads/pricelist.pdf
Quelle: OPENXCHANGE Server™ 5.0, Architecture, Integration and Interfaces, High Level
Overview V 0.92, Stephan Martin, Senior System Architect
http://www.proite.de/fileadmin/user_upload/produkt-bilder/ox/Open-Xchange-OXArchitecture.pdf (Stand 27.10.2007)
Seite 314
Besonders vorteilhaft ist die Skalierbarkeit aufgrund der Möglichkeit, Komponenten auf
verschiedene Server-Systeme zu verteilen. Zusätzlich können Komponenten auf
mehrere Server repliziert werden.
Nachfolgend sollen nur jene Softwarepakete betrachtet werden, die im unmittelbaren
Zusammenhang mit der Groupware-Funktionalität stehen. Die gesamte Lösung besteht
aus unterschiedlichen modularen Software-Einheiten, die im Zusammenspiel die Mailund Groupware-Funktionen realisieren. Die Basis der Groupware-Lösung bildet der
Java-basierte Open-Xchange Application Server.
Komponenten
Aufgaben
Postfix
Mail-Transfer-Agent (MTA)
Cyrus IMAP
Realisiert die IMAP-Funktionalität
OpenLDAP
Zentraler Verzeichnisdienst für die Nutzerverwaltung
Postgres SQL
Datenbank zur Verwaltung der Groupware-Daten
Apache – Tomcat
Realisierung des Webfrontends (Mail, Groupware)
Tabelle 49: Mögliche Komponenten der Open-Xchange-Lösung
Die Serverkomponenten bieten umfangreiche Mail- und Groupware-Funktionalitäten.
Den Benutzern stehen unterschiedliche Funktionen zur Verfügung:

E-Mails empfangen und versenden,

Terminverwaltung,

Adressenverwaltung,

Aufgabenverwaltung,

Notizfunktionen,

Dokumentenmanagement (Versionskontrolle und Ordnerstruktur),

Projekt-Management,

Konfigurierbare Wissensdatenbank mit Volltextsuche,

Gruppenbasiertes Diskussionsforum.
In Hinblick auf die Unterstützung unterschiedlicher Client-Systeme muss zwischen der
Mail- und der Groupware-Funktionalität unterschieden werden. Der Zugriff auf die Mailfunktionalitäten kann mittels aller POP3- und IMAP-fähigen Clients erfolgen. Zusätzlich
können die Benutzer über eine speziell integrierte Webmail-Lösung auf ihre Mails zugreifen.
Die Nutzung der oben aufgeführten Mail- und Groupware-Funktionalitäten kann vollständig über den browserbasierter Zugriff per Web-Portal erfolgen. Den Benutzern stehen in
allen Funktions-Modulen die LDAP-basierten Adressbücher, die Möglichkeit der Rechtevergabe und Suchfunktionalitäten zur Verfügung. Bei der Nutzung der Terminvereinbarungsfunktion erfolgt eine automatische serverseitige Analyse der bereitstehenden
Seite 315
Ressourcen für den jeweiligen Zeitraum. Die webbasierten Angebote erlauben den Anwendern die Nutzung umfassender Gruppen-Funktionalitäten.
Weiterhin können Clientanwendungen von Drittanbietern mit dem Groupwareserver
kommunizieren, sofern sie Protokolle wie IMAP, LDAP und WebDAV oder das iCalFormat unterstützen.
Für die verschlüsselte Übertragung kann auf OpenSSL zurückgegriffen werden.
OpenSSL realisiert die Datenverschlüsselung zwischen den Applikationen und Komponenten. IMAP und POP3 können mittels SSL-Tunnel und SMTP mittels TLS sicher übertragen werden.
Die Komplettlösung Open-Xchange Express Edition bietet einen integrierten Anti-Virus
und Anti-Spam Schutz.
Der Open-XChange Server ist auf offenen Standards wie XML-RPC, WebDAV (XML),
LDAP, Tirgger, iCal und HTTP/S gebaut259. Zum Zugriff und zur Erweiterung des OpenXchange Servers stehen die Programmierschnittstellen HTTP API, WebDAV API,
Oxmapi und Open-Xchange Hyperion CLT zur Verfügung260:

HTTP API261 wird von dem neuen AJAX-basierten Webclient genutzt. Der Datenaustausch erfolgt in JavaScript Object Notation (JSON) über HTTP GET, POST
und PUT requests.

WebDAV API262 wird von externen Client-Anwendungen zur Modifikation von
Objekten auf dem Open-Xchange Server verwendet. Es basiert auf WebDAVStandard mit Erweiterungen für den Open-Xchange Server.

Oxmapi263 ist eine Windows Library zur Kommunikation von WindowsAnwendungen mit dem Server.

Open-Xchange Hyperion CLT264 sind Shell-Scripts, die Administration des
Servers erlauben.
Zusammenfassend heißt das, dass die Groupware-Lösung Open-Xchange ein modular
aufgebautes Groupware-System anbietet, bei dem die einzelnen Module auf bewährten
Open Source Komponenten basieren. Als Groupware-Komponente wird der Javabasierte Applikationsserver integriert, der im Zusammenspiel mit den anderen Komponenten den Benutzern umfangreiche Groupware-Funktionalitäten bietet. Die einzelnen
Server-Komponenten können auf verschiedene Systeme verteilt werden, wodurch die
Skalierbarkeit von Open-Xchange gewährleistet ist. Offene Standards und die Bereitstellung von diversen Schnittstellen erlauben die Erweiterung des Open-Xchange Servers
durch Drittanbieter und die Integration in bestehende IT-Landschaften. Der Benutzerzugriff auf die entsprechenden Groupware-Informationen kann entweder webbasiert oder
mittels sogenannter Fat-Clients erfolgen (Kontact, usw.). Die Open-Xchange Express
259
260
261
262
263
264
http://www.osedge.com/?q=node/22
http://www.open-xchange.com/wiki/index.php?title=Interfaces
http://typo3.open-xchange.com/wiki/index.php?title=HTTP_API
http://www.open-xchange.com/wiki/index.php?title=Oxwebdavapi
http://www.open-xchange.com/wiki/index.php?title=Oxmapi
http://www.open-xchange.com/wiki/index.php?title=Open-Xchange_Hyperion_CLT
Seite 316
Edition ist eine umfassende Komplettlösung, die neben einem AJAX-basierten Webclient
auch die MS Outlook Anbindung sowie ein Administratormodul beinhaltet.
1.3
eGroupWare
Basierend auf einer Abspaltung des unter der GPL stehenden Groupwaresystems
phpGroupware entstand im Jahre 2003 das eigenständige Projekt eGroupWare 265. Die
Abspaltung hatte zum Ziel, den Entwicklungsprozess offener zu gestalten und insbesondere für eine breite Community zu öffnen; dieses Bestreben zeigt auch die 2005 aufgestellte Satzung über die Organisation des gesamten Projektes. Die aufgestellten Regeln
beschreiben hier u.a. die genaue Vorgehensweise, wie Änderungen in der Entwicklung
der Software bestimmt und bekanntgemacht werden müssen.
Auf Basis einer Auswertung freiwilliger Angaben266 von Unternehmen und Organisationen, welche auf der Webpräsenz des eGroupWare-Projekts einzusehen sind, ergibt
sich folgendes Bild: Insgesamt sind mind. 45 Organisationen und Unternehmen aufgelistet, die eGroupWare nutzen. In Summe beläuft sich die Anzahl der Nutzer auf insgesamt
ca. 8000, wobei die Mehrzahl der Organisationen und Unternehmen eine Nutzerzahl von
weniger als 50 Personen angibt. Aus den Angaben ebenfalls ersichtlich ist der internationale Einsatz der Groupware-Lösung. Eine deutliche Mehrheit entfällt auf europäische
Länder, aber auch einige Staaten aus Nord-, Süd-, und Mittelamerika sowie China beziehungsweise Südostasien werden als Standorte angegeben.
Ab Mitte 2007 lautet die aktuelle Versionsnummer der Software: 1.4.
Diese Version zeichnet sich gegenüber der Vorgängerversion (1.2.) u.a. durch folgende
relevante Änderungen aus:

Neuimplementierung des Adressbuchs (Gruppen, Organisations-Ansicht, LDAPSupport)

Neue Nachverfolgungskomponente (Trackersoftware)

Neues Backend für IMAP, Verbesserungen der Mailkomponente.
Nach Angaben der Projektseite ist mit der nächsten Version (1.6) im 1.Halbjahr 2008 zu
rechnen.
Die Software steht unter der GNU General Public License (GPL2267). Kostenfreien
Support bietet die Community via Handbuch, Mailinglist oder IRC-Chat an. Kostenpflichtigen Support und Unterstützung bieten die in Deutschland ansässigen Unternehmen
Outdoor Unlimited Training GmbH (Kaiserslautern), Metaways Infosystems GmbH
(Tremsbüttel) und CWTech Freie Netzwerk Systeme (Haiger).
Als Vertreter einer webbasierten Groupware-Lösung ist die Hauptschnittstelle zu
eGroupWare ein Standard-Webbrowser (Internet-Explorer, Firefox). Die Generierung der
dynamisch erzeugten Inhalte geschieht auf Basis der Skriptsprache PHP. Die Inhalte
werden mittels eines Webservers (Apache, IIS oder Roxen) zur Verfügung gestellt, die
265
266
267
Weiterführende Informationen zu eGroupware: http://www.egroupware.org/
http://www.egroupware.org/references
http://opensource.org/licenses/gpl-license.php
Seite 317
Datenverwaltung und -haltung kann in einer MySQL-Datenbank erfolgen. Als Datenbanksysteme können aber auch PostgreSQL, Oracle und Sybase gewählt und für die
Adressverwaltung ein LDAP-Directory eingesetzt werden (siehe Abbildung 8).
Abbildung 33: eGroupWare-Architektur268
Für die E-Mail-Funktionalität lassen sich beliebige Mailserver einsetzen, diese müssen
die Protokolle SMTP und POP3/ IMAP unterstützen.
eGroupWare ist ein betriebssystemunabhängiges und modular aufgebautes System. Bei
der Integration kann zwischen zahlreichen Modulen ausgewählt werden. So stehen neben denen zur Realisierung klassischer Groupware-Funktionalitäten (Email, Kalender,
Adressbuch etc.) noch weitere Module bereit. Die Module können konfiguriert werden.
Module
268
Funktion
Addressbook
Kontakt-Manager
FelaMiMail
E-Mail-Client, unterstütz u.a. Filterregeln, Abwesenheitsprofile und Freigaben von Email-Ordnern
Kalender
Kalender, der auch Terminierung von Gruppen, Ressourcen und Kontakten unterstützt
InfoLog
ToDo-Listen, Notizen und Telefonnotizen, CRM
Projektmanager
Integrierte Projektverwaltung
SiteMgr
Webseiten Bearbeitungssystem mit Zugriffskontrolle
Dateiverwaltung
Dateiverwaltung, basierend auf files, sql-db oder webdav
Quelle: http://www.egroupware.org/?category_id=90
Seite 318
Module
Funktion
Stundenzettel
Zeiterfassung
Verfolgungssystem
Trouble Ticket System
Wiki
Integriertes Wiki
Wissensdatenbank
Forum
Workflow Engines
Ablauforganisation
Umfragen
Erstellen und Auswerten von Umfrage
Chatte
Synchrone-Kommunikation
Tabelle 50: Auswahl an eGroupWare-Modulen
Die Weboberfläche von eGroupWare basiert auf einem Template-System, es kann zwischen drei Typen für die Layout-Beschreibungen (XML, eTemplates, HTML) unterschieden werden. Diese Flexibilität erlaubt es das vorhandene Standardsystem an die jeweiligen Einsatzumgebungen anzupassen, so ist zum Beispiel eine Anpassung an das CD
möglich.
Das Groupware-System bietet eine sichere Übertragung von Inhalten und sichere
Authentifizierung von Nutzern. Dabei unterstützen die Einzelkomponenten des
Groupware-Sytems wie Webserver (zum Beispiel Apache, IIS und Roxen) das HTTPSProtokoll. Ferner bieten IMAP-Server wie Cyrus IMAP, Courier IMAP etc. auch
Verschlüsselungsmöglichkeiten (TLS, SSL) für die Authentifizierung und den Datenaustausch an. Das System selbst bietet auch ein eigenes Benutzersystem an, das den
browserbasierten Zugriff auf den persönlichen Arbeitsbereich reglementiert.
Zur Integration verschiedener PIM-Clients (Personal Information Manager) werden zusätzlich die folgenden Schnittstellen angeboten:

XML-RPC-API
bietet Remote-Zugriff auf Funktionen des Groupwaresystems

SOAP
ermöglicht den Aufbau von Serviceorientierten Anwendungen

SyncML
als Beschreibungssprache, die genutzt werden kann, um Daten zwischen
verschiedenen Clients auszutauschen

GroupDAV
umfasst die vereinfachte Version des WebDAV-Protokolls und dient zum Beispiel
dem Austausch von Kalendern, Aufgabenlisten und Kontaktlisten

IMAP
als ein Protokoll zum Abruf von Emails, etc.

iCalendar
als ein gängiges Format zur Beschreibung von Kalender-Daten.
Seite 319
Laut Projektseite269 ist eine Synchronisierung von Kalender, Adressbuch und InfoLogDaten mit verschiedenen PIM-Clients möglich. Zurzeit werden die folgenden Clientapplikationen unterstützt:

Kontact

Evolution

Outlook

Mozilla Sunbird

Apple iCal

PDA (via Synthesis und Funambol).
Am Beispiel von MS-Outlook ist laut Dokumentation der eGroupWare-Projektseite eine
Synchronisation mit eGroupWare unter Zuhilfenahme der Schnittstellen XML-RPC-API
(nur via Plugin270), SyncML und iCalendar möglich.
Zusammenfassend ist festzuhalten: eGroupWare ist ein modular aufgebautes System,
das standardmäßige Groupware-Funktionalitäten wie Email, Kalender und Adressbuch
bereitstellt sowie weitere Funktionalität wie ToDo-Listen, Stundenzettel, Umfragen etc. in
zusätzlichen Modulen anbietet. Ein Zugriff auf die komplette Funktionalität des Groupware-Systems ist nur im Onlinebetrieb und aus autorisierten Netzen heraus möglich. Der
Einsatz dieser auf den Webbrowser fokussierten Groupware Lösung bietet jedoch viele
Vorteile:
1.4

Ein Zugriff über Webbrowser ist möglich, ebenso der gesicherte Zugriff über
HTTPS von außen.

Die Installation eines speziellen Clients ist nicht notwendig.

Die Betriebssystemunabhängigkeit bietet insbesondere in heterogenen ClientLandschaften Vorteile.

Die Softwareaktualisierung erfolgt nur auf dem Server.
Zarafa
Die niederländische Firma ConecTUX entwickelt und vertreibt das Groupware-Produkt
Zarafa271. Vor fünf Jahren wurde mit der Entwicklung begonnen. Der Sitz der ZarafaTochtergesellschaft (Zarafa Deutschland GmbH) für den deutschsprachigen Raum ist
Hannover.
Das Groupware-Produkt Zarafa wird derzeit von mehr als 1000 Unternehmen genutzt272.
In den vergangenen 12 Monaten wurden 1200 Server verkauft. Die von der Benutzerzahl
her derzeit größte Installation bedient rund 1500 Benutzer, die die gesamte GroupwareFunktionalität inklusive Outlook nutzen.
269
270
271
272
Überblick Synchronisation - http://www.egroupware.org/sync
eGWOsync - http://www.egroupware.org/wiki?wikipage=synchronisation%20outlook
http://www.zarafaserver.de/
http://www.zarafaserver.de
Seite 320
Zarafa wird in Deutschland, Österreich, der Schweiz, den Benelux-Ländern sowie Großbritannien und Frankreich vertrieben. Demnächst soll Skandinavien als Markt hinzukommen.273
Aktuell liegt das Groupware-Produkt Zarafa in der Version 5.10 vor, die Mitte 2007 freigegeben wurde. Die Version 5.0 wurde Ende 2006 freigegeben, davor stand ab Mitte
2006 die Version 4.2 zur Verfügung.
Zarafa ist für zwei verschiedene Linux-Versionen erhältlich: EasyLinux und OpenLinux.
Für alle vorhandenen Versionen von Zarafa sind die Preise gleich. Die Basis-Lizenz
umfasst fünf Benutzer und kann in Schritten zu je fünf Benutzern erweitert werden.
Rabatte werden für Lizenzen ab 100 Benutzern gewährt. Angaben zu Preisen und
Lizenzen finden sich auf der entsprechenden Webseite274.
Eine kostenlose Testversion kann aus dem Web bezogen und für 30 Tage genutzt werden, eine Online-Demo steht im Web zur Verfügung275. Zarafa steht für verschiedene
Linux-Distributionen wie Debian, Fedora, RedHat, SuSE, OpenSUSE oder Ubuntu zur
Verfügung276.
Zarafa hat eine Client-Server-Architektur. Der Server ist eine Eigenentwicklung, wurde in
C++ implementiert und läuft unter allen gängigen Linux-Distributionen. Mit WebAccess
steht ein eigenentwickelter Client zum webbasierten Zugriff auf die GroupwareFunktionen zur Verfügung.
277
Abbildung 34: Technische Zusammenhänge in Zarafa
273
274
275
276
277
Firmenauskunft
http://www.zarafaserver.de/prices.html
http://www.zarafaserver.de
http://download.zarafa.com/zarafa/en/zarafa_technical.pdf
Quelle: http://www.zarafaserver.de/technical-explanation.html (Stand 27.10.2007)
Seite 321
Zarafa basiert auf Open Source-Komponenten und Offenen Standards: gSOAP, MAPI,
PHP, MySQL und Apache. Die Gesamtfunktionalität von Zarafa wird durch das
Zusammenspiel mehrerer Komponenten erreicht, die Basisfunktionalität ist ohne die
optionalen Komponenten verfügbar. Die Abbildung 34 zeigt die technischen Zusammenhänge in Zarafa.
Der Zarafa-Server speichert alle Daten in einer SQL-Datenbank und verwaltet die Verbindungen der Clients wie Outlook oder WebAccess. Die Verbindung der Clients erfolgt
über SOAP und der Zugang zu den angeforderten Daten wird auf seine Berechtigung
geprüft. Für Outlook-Verbindungen ist immer mindestens eine Verbindung geöffnet, um
Benachrichtigungen über Ereignisse zu versenden.
Die Server-Einstellungen sind in einer Konfigurationsdatei einstellbar. So kann zum Beispiel festgelegt werden, wie die Authentifizierung mit dem Datenbankserver erfolgt oder
wie detailliert Systemnachrichten aufzuzeichnen sind (message logs). Der Server benötigt mindestens 512 MB RAM, für hohe Lasten mehr. Es wird wenigstens eine moderne
CPU empfohlen. Benötigte Software ist glibc 2.3.x, MySQL 4.1 und ein Web-Server mit
PHP-Support. Die folgende Tabelle zeigt die Komponenten von Zarafa:
Komponenten
Aufgaben
Zarafa Server
Verbindet Clients über SOAP und speichert Daten in SQLDatenbank
Zarafa Client
Nutzung von Outlook über MAPI-Konnektor; Verbindung zum Server
erfolgt über SOAP
Zarafa Dagent & Spooler
Senden und empfangen von Emails mit der „externen Welt―
Zarafa Admin
Administrator-Werkzeug zur Verwaltung von Benutzern, Benutzerinformationen und Gruppen
Zarafa Gateway
Optionale Komponente für POP3 und IMAP
Zarafa Monitor
Überwacht Benutzer-Speicher und Quota-Überschreitungen
Zarafa Caldav
Optionale Komponente für iCal-Unterstützung
Zarafa Backup
Erzeugen von Backups
Zarafa Migrate
Migrations-Werkzeug zum migrieren von existierenden Exchangeund pst-Umgebungen
Apache / PHP
Webserver für das Webfrontend
PHP MAPI Erweiterung
Plug-in das MAPI-Funktionen für PHP-Entwickler zugreifbar macht
Tabelle 51: Zarafa Komponenten
Zur Verwaltung von Benutzern, Benutzerinformationen und Gruppen steht ein eigenes,
zeilenorientiertes Administrator-Werkzeug (Shell) zur Verfügung. Für die RedHat- und
Centos-Distributionen gibt es einen LDAP-basierten grafischen Benutzer-Editor, siehe
die nachfolgende Abbildung.
Seite 322
Abbildung 35: LDAP-basierter grafischer Benutzer-Editor
Unter Windows 2000/XP werden die Clients Outlook 2000, 2003 oder XP benötigt. Sie
verbinden sich über das Netzwerk mit dem Server. Da SOAP benutzt wird, sind die Verbindungen für Webserver und Proxy transparent. Es werden die folgenden Grundfunktionen unterstützt, die Outlook anbietet, ohne dass ein MS Exchange-Server benötigt wird:

Gemeinsames Verwenden von Email und Kalender

WebAccess: Zugriff auf Outlook-Daten über Web-Interface

Outlook-Nutzung von außerhalb des Firmen-Netzwerkes

Gemeinsames Verwalten von Geschäftskontakten

Verteilerlisten

Persönliche und gemeinsam genutzte Aufgabenlisten

Synchronisation für Handheld (PDA) und Laptop

Konfiguration von Zugriffsrechten über WebAccess.
Zudem existiert eine iCal-Unterstützung zur Synchronisation des Kalenders (Sunbird,
Mac OSX iCal).
Mit Z-Push278 hat Zarafa eine Implementierung des Active-Sync Protokolls als Open
Source Software unter GPL freigegeben. Damit soll die Software ähnliche Funktionen
bieten wie die proprietären Lösungen von Blackberry mit BES und Microsoft mit
Exchange. Bislang scheint es noch keine SSL-Variante zu geben, sodass die Entwickler
von einer Verwendung außerhalb des lokalen Netzes abraten.
278
http://z-push.sourceforge.net/ (Stand 27.10.2007)
Seite 323
Die Datenübertragung von Clients zum Server kann über eine verschlüsselte SSLVerbindung und HTTPS erfolgen. Dies erfordert serverseitig eine entsprechende Konfiguration. Zugriffsrechte schützen vor unberechtigtem Zugriff auf Daten.
Alle Anwendungen, die sich mit dem Zarafa-Server verbinden, nutzen den MAPI-Layer,
der im MAPI-provider implementiert ist (siehe Abschnitt Architektur). Aufgrund dieser
Tatsache ist davon auszugehen, dass alle MAPI-fähigen Anwendungen mit dem Zarafa
interoperabel sein.
Daneben steht mit der PHP-MAPI-Extension ein sehr umfangreicher Satz von Befehlen
und Schnittstellen aus Microsofts MAPI-Welt unter PHP zur Verfügung. Diese Schnittstelle erfordert vom PHP-Entwickler, dass er auch über Grundwissen zu MAPI verfügt.
Zusammenfassend kann festgehalten werden: Zarafa ist eine Alternative zur Nutzung
von Microsoft Exchange, das heißt eine Lösung, die die Kommunikation zwischen
Outlook und einem Server anbietet. Der Server läuft unter allen gängigen LinuxDistributionen. Zarafa bietet im Rahmen von MAPI eine funktionale OutlookUnterstützung und einen entsprechenden Webclient (WebAccess). Eine PHP-MAPIExtension stellt wichtige Funktionen für Entwickler zur Verfügung.
1.5
Kolab
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) beauftragte 2002 ein Firmenkonsortium, eine freie Groupware-Lösung für den Einsatz im BSI zu erstellen. Darauf aufbauend entwickelte sich zunächst das Kolab-Projekt279, das Ende 2004 die zweite
Generation der Software fertiggestellt hat.
Als maximale Nutzerzahlen werden vom Kolab-Projekt einige Tausend Nutzer für einen
einfachen, voll integrierten Server empfohlen. Auf der Projektwebseite finden sich keine
direkten Referenzen zur Verbreitung von Kolab. Recherchen ergaben allerdings, dass
zum Beispiel der Brandenburgische Landesbetrieb BLB280 das Kolab-Groupwaresystem
für mehr als 600 Bildschirmarbeitsplätze einsetzt.
Im Jahre 2002 wurde Kolab konzipiert und im Juli 2003 die stabile Version 1 des Systems veröffentlicht. Nach einer Generalüberholung wurde Kolab 2.0 im Juni 2005 unter
anderem mit der Neuerung des Kolab XML Format eingeführt. Aktuell ist die Version 2.1
seit Mitte 2007 verfügbar, die Veröffentlichung Version 2.2 ist für Anfang 2008 geplant.
Eine Nutzung der Kolab Groupware-Lösung ist aufgrund der bestehenden OSS-Lizenz
(GPL) ohne Zahlung von Lizenzgebühren möglich; zur Unterstützung der Nutzer werden
auch kostenpflichtige Dienstleistungen angeboten. Support, Planung und Service für das
Kolab-System sind kostenpflichtig über das Kolab-Konsortium281 verfügbar. Desweiteren
erlaubt es die freie Lizenz (GPL) jedem, Erweiterungen, Verbesserungen und Veränderungen an Kolab vorzunehmen.
279
280
281
http://www.kolab.org/
http://www.kbst.bund.de/cln_028/nn_837410/SharedDocs/Projekte/OSS/ kolab__einsatz__im__land__brandenburg.html
http://www.kolab-konsortium.de/
Seite 324
Die zentrale Komponente ist der Kolab-Server, die wiederum auf eine Reihe weiterer
freier Komponenten zurückgreift. Die einzelnen Komponenten werden in den folgenden
Tabellen aufgeführt.
Komponenten
Aufgaben
Cyrus IMAP
IMAP / POP3 Mailserver
Cyrus SASL2
Authentifizierung
OpenLDAP2
Verzeichnisdienst, zum Beispiel für die Nutzerverwaltung
Postfix
Mail-Transfer-Agent
Apache / PHP
Webserver für das Webfrontend
Horde282
Framework
Webclient (ab Kolab 2.2 integriert)
Tabelle 52: Zentrale Kolab-Server-Komponenten
Komponente
Aufgabe
Amavisd-New
Ansteuerung von Spamfilter und Virenscanner
zum Beispiel ClamAV
Virenscanner
zum Beispiel SpamAssassin
Spamfilter
Tabelle 53: Optionale Kolab Server-Komponenten
Das Softwarepaket des Kolab-Servers wird als sog. OpenPKG283-Paket angeboten und
ist somit auf verschiedenen UNIX-basierten Betriebssystemen wie z. B. Solaris, BSD
und auch Linux ohne weiteres lauffähig.
Zurzeit existieren verschiedene integrierte Server, die Kolab als Server-Komponente für
E-Mail-, Groupware- und PIM-Funktionen anbieten. ClarkConnect284 z. B. kombiniert den
Kolab-Server mit verschiedenen anderen Funktionen und Diensten (u. a. Firewall, VPN,
Backuplösungen) zu einem vollständigen Intranetserver, das als eigenständiges System
(inklusive Linux-Betriebssystem) vertrieben wird. Weitere integrierte Lösungen auf Basis
von Kolab sind z. B.: Univention Groupware Server (UGS)285, Intranator Business Server286, Pardalays287.
282
283
284
285
286
287
http://www.horde.org/
http://www.openpkg.org/
http://www.clarkconnect.com/
http://www.univention.com/ugs.html
http://www.intra2net.com/de/produkte/business_server.php
http://www.pardus.de/products.html
Seite 325
Die Kolab-Lösung baut auf einem Client-Server-Ansatz auf, der eine asynchrone
Nutzung der Groupware-Funktionalitäten durch die Benutzer gewährleistet. Diese haben
zum Beispiel die Möglichkeit, E-Mails, Termine, Kontakte und persönliche Aufgaben mit
der entsprechenden Client-Software offline zu nutzen, das heißt ohne dass eine
Verbindung zum Kolab-Server besteht. Die Änderungen werden durch eine spätere
Daten-Synchronisation mit dem Server abgeglichen.
Kolab ist eine plattformübergreifende Groupware-Lösung, die sowohl mit Linux-Clients
als auch mit Windows-Clients nutzbar ist. Die Funktionalitäten sind mit der Outlook / Exchange-Kombination von Microsoft vergleichbar. Das Clientsystem Outlook wird mit Hilfe
eines Plugins zum vollwertigen Kolab-Client und bietet so die gleiche Funktionalität wie
der Linux-Client Kontact.
Die hohe Skalierbarkeit der Kolab-Lösung beruht im Wesentlichen auf den folgenden
Eigenschaften:

Möglichkeit, die einzelnen Kolab-Serverkomponenten (siehe Tabellen 4 und 5)
auf einzelnen Servern zu betreiben: Ein Verbund aus Servern bildet somit einen
einzigen geclusterten Kolab-Server.

Clusterfähigkeiten von Cyrus IMAP, OpenLDAP und Postfix: Ein Verbund von
Servern bildet eine einzelne geclusterte Kolab-Serverkomponente.

Multilokationsfähigkeit: Mehrere Kolab-Server bilden einen Verbund; jeder
einzelne Kolab-Server bedient eine feste Teilmenge aller Groupware-Nutzer des
Verbundes.
Eigentlich wurde aber die Multilokationsfähigfahigkeit (Möglichkeit von Mehrfachstandorten) eines Kolab-Server Verbundes primär nicht zur Erhöhung der Skalierbarkeit
geschaffen, sondern um einen Kolab-Server Verbund räumlich über mehrere entfernte
Standorte verteilt betreiben zu können.
Für den produktiven Einsatz ist auch die Möglichkeit der einfachen Sicherung und
Wiederherstellung von Daten entscheidend. Die Architektur des gesamten KolabSystems vereinfacht die Backup- und Recoverymöglichkeiten stark: Die Mailboxen
werden als gewöhnliche Verzeichnisse im Dateisystem des Kolab-Servers abgebildet
und sind somit mit üblichen dateisystembasierten Backupwerkzeugen handhabbar.
Neben kompletten Mailboxen können mit denselben Backupwerkzeugen auch einzelne
E-Mails, Termine etc. gesichert und wiederhergestellt werden, da sie als einzelne
gewöhnliche Dateien abgelegt werden.
Neuerungen bei Kolab 2 sind u. a.:

die Möglichkeit für Mehrfachstandorte (Multilokationsfähigkeit)

die explizite Vergabe von Zugriffsrechten

die gemeinsame Bearbeitungsmöglichkeit für Verzeichnisse

die volle Mehrkontenfähigkeit

die automatische Annahme von Terminen

einfachere Integration externer Verzeichnisdienste (LDAP)
Seite 326

Verwaltung mehrerer Maildomänen (ab 2.1)

Horde-Framework als Standard Webclient (optional ab 2.1, fest integriert ab 2.2)
Der Zugriff auf Kolabs Mail- und Groupware-Funktionalitäten kann sowohl unter
Windows- als auch unter Linux erfolgen: unter Linux ist die Referenz-Clientsoftware
Kontact, unter Windows wurde bei Kolab 1 Outlook 2000 mit Kolab-Plugin als ReferenzClient verwendet, bei Kolab 2 ist es Outlook 2003. Zudem werden andere ClientApplikationen, wie z. B. Mozilla Thunderbird, zunehmend zu vollwertigen Kolab-Clients
ausgebaut.
Für Kolab-Installationen hat sich der seit Oktober 2003 am Markt befindliche Toltec
Connector der Firma Radley Network Technologies CCs288 bewährt. Der Toltec
Connector ist ein kostenpflichtiges proprietäres Produkt und muss zusätzlich zu Outlook
installiert werden. Der Connector ermöglicht einem Outlook-Client289, seine Daten auf
einem Kolab-Server zu speichern. Es stehen auf dem Markt auch noch andere
Connectoren290 zur Verfügung, diese wurden jedoch im Rahmen der Evaluierung nicht
gesondert betrachtet. Ebenfalls von der Firma Toltec angeboten wird ein LDAPAdressbuch für Outlook, das z. B. auf den jeweiligen OpenLDAP-Server von Kolab zugreifen kann.
Für den Zugriff auf die Groupware-Funktionalitäten steht den Nutzern von linuxbasierten
Arbeitsplätzen der Kontact Client zur Verfügung. Dieser Linux-Client ist eine verbesserte
und erweiterte Version von KDEs Kontact, der die Möglichkeiten von KMail, KOrganizer,
KAddressbook und weiteren Komponenten des KDE-PIM-Projektes unter einer einheitlichen grafischen Oberfläche zusammenfasst. Der Client fügt sich sehr gut in die KDEOberfläche ein und ist von Nutzern intuitiv zu bedienen. Kontact unterstützt u.a. die Protokolle POP3 und disconnected IMAP4. Unterstützt wird auch das Filtern eingehender EMails (Spam, Viren usw.) auf der Clientseite. Darüber hinaus wird seit März 2007 verstärkt an einer browserbasierten Clientanwendung gearbeitet, die auf das HordeFramework291 aufsetzt und zukünftig (ab Version 2.2) als Standard Kolab Webclient eingesetzt werden soll.
Neben dem Kolab-Webclient existiert auch eine webbasierte Administrations-Oberfläche,
die folgende Aktionen bereitstellt:
288
289
290
291

Nutzer- und globale Adressbuchverwaltung

Verwaltung der öffentlicher Ordner

Verwaltung der Ressourcen- und Gruppenkonten
http://www.toltec.co.za/
Laut Hersteller Outlook 2000,, XP, 2003 und 2007
KONSEC Konnektor (http://www.konsec.com/),
Bynari Insight Connector (http://www.bynari.net/)
http://www.horde.org/
Seite 327

Teilweise Administration der Serverdienste

Abwesenheitsbenachrichtigungen und Weiterleitungen
Die webbasierte Administrations-Oberfläche stellt in erster Linie Funktion für den Zugriff
auf wiederkehrende Aufgaben (z. B. Nutzer anlegen) bereit, weitergehende Anpassungen müssen direkt an den entsprechenden Server-Komponenten vorgenommen werden.
Hier verfolgt die Kolab-Architektur einen zweischichtigen Ansatz, der zum einen einzelne
Funktion zu einer Aktivität vereint, aber gleichzeitig die Mächtigkeit jedes einzelnen Systems darüber hinaus bereitstellt.
Der einzelne Benutzer hat überdies auch die Möglichkeit, bestimmte Änderungen direkt
über die webbasierte Administrations-Oberfläche vorzunehmen. So können die Benutzer
ihre persönlichen Daten modifizieren und beispielsweise zusätzliche Mail-Adressen (sog.
Mail-Aliases) hinzufügen.
Die folgende Auflistung benennt die wichtigsten Funktionalitäten der Groupware-Lösung:

E-Mails empfangen und senden

Kontaktverwaltung

Rechtevergabe auf IMAP-Ordnern (IMAP-ACLs)

Gemeinsame Bearbeitung von freigegebenen Ordnern mit z. B. E-Mails,
Terminen, Kontakten, Aufgaben etc.

Globale Adressbücher

Gruppenkalender und –termine

Gruppenordner („Shared Folders―)

Ressourcenverwaltung (Buchung von Räumen, Beamer, Fahrzeugen etc.)

Persönliche Notizen und Aufgaben (die auch gemeinsam nutzbar sind)

Frei- / Belegt-Listen (FreeBusy-Lists)

Erweiterte Frei- / Belegt-Listen (XFB)

Weiterleitungen in andere Postfächer

Abwesenheitsbenachrichtigungen

Funktionspostfächer mit mehreren unterschiedlich Zugriffsberechtigten

Lesebestätigungen

PDA-Synchronisation via PIM-Client

Volle Offlinefähigkeit der Clients durch Kolab-Design gegeben
Mit dem Kolab Format existiert für das Groupwaresystem ein offenes Austauschformat,
das es erlaubt, verschiedene sog. Kolab-Objekte (Notizen, Adressen etc.) zu beschreiben und diese im Kolab-IMAP-Server abzulegen. Die oben genannten Konnektoren nutzen dieses Format zur Kommunikation mit dem Server.
Seite 328
Auf die Integration von Sicherheitsstandards wurde bei der Entwicklung besonderer Wert
gelegt. Die Kommunikation zwischen den Client-Systemen und dem Server kann vollständig verschlüsselt (SSL/ TLS) geschehen. Die verschlüsselte Kommunikation kann
u.a. mittels der Protokolle

IMAPS

SMTP über TLS und

HTTPS
realisiert werden. Der Linux-Client unterstützt die Ende-zu-Ende-Sicherheit sowie elektronische Signaturen auf Basis internationaler Standards (S/MIME, X.509v3), die Implementierung Ägypten292 ist vom BSI erfolgreich auf Interoperabilität293 getestet worden.
Für die administrativen Belange sind drei spezielle Nutzergruppen mit besonderen Rechten vorgesehen. Es wird zwischen folgenden Gruppen unterschieden:

Administratoren

Maintainer

User (Benutzer)
Die Administration kann - entsprechend der unterschiedlichen Berechtigungen - über die
Verwendung der webbasierten Administrationsoberfläche erfolgen. Einfache administrative Aufgaben können mittels des Web-Frontends realisiert werden, bei komplexen
Tätigkeiten sind die entsprechenden Konfigurationsdateien auf dem Kolab-Server
anzupassen.
Damit kann zusammenfassend festgestellt werden, dass Kolab eine plattformübergreifende Groupware-Lösung ist, die mit der Outlook/Exchange-Kombination von Microsoft
vergleichbar ist. Der Aufbau der Kolab-Architektur basiert auf ausgereiften Einzelkomponenten wie zum Beispiel Cyrus-IMAP oder Apache-Webserver, was auf eine hohe Skalierbarkeit des Gesamtsystems schließen lässt. Für den Austausch zwischen Client und
Server existiert neben Standardprotokollen wie HTTP, LDAP, IMAP auch ein offenes
Austauschformat, das es erlaubt, verschiedene PIM-Clientapplikationen (u. U. per Konnektor) mit dem Kolab-Groupwaresystem zu verbinden.
1.6
Scalix
Scalix ist eine Groupware- und Messaging-Plattform, die ursprünglich von der Scalix
Corporation in Kalifornien entwickelt wurde. Im Juli 2007 kaufte XANDROS, ein kanadisches Unternehmen, Scalix. XANDROS gehört zu den größten Unternehmen für linuxbasierte Email-, Kalender- und Messaging-Software.
Das System wird derzeit von mehr als 670 Unternehmen in mehr als 55 Ländern genutzt294. Aktuell liegt Scalix in der Version 11.0.4 vom 3.5.2007 vor. Die Release Notes
zur aktuellen Version sind im Web abrufbar295.
292
293
294
Ägypten: http://www.gnupg.org/aegypten/index.de.html
Sphinx-Interoperabilitätstests:
http://www.bsi.bund.de/fachthem/verwpki/interoptests/testberichte.htm
http://www.scalix.com/about/
Seite 329
Scalix liegt in drei Editionen vor:

Enterprise Edition,

Small Business Edition,

Community Edition.
Die Enterprise Edition wird pro Benutzer mit einem Mindestvolumen von 25 Benutzern
lizenziert. Die Small Business Edition umfasst standardmäßig 50 Benutzer, kann aber in
25er Schritten erweitert werden. Die Community Edition kann mit max. 25 Benutzern zu
Eignungstests genutzt werden. Die Funktionsunterschiede zwischen den einzelnen
Editionen werden unten in einer Tabelle verglichen.
Scalix steht auch innerhalb von integrierten Server-Lösungen zur Verfügung.
Mit „Scalix für UCS" bietet Univention das Groupwaresystem Scalix als optional installierbare Komponente für die Linux Komplettlösung Univention Corporate Server an.
Der auf Open-Source-Komponenten aufgebaute „open-sbs― Small Business Server ist
eine softwarebasierte Out-of-the-Box-Server-Lösung. Er ist speziell auf kleine Firmen
und Büros mit wenigen Arbeitsplätzen ausgerichtet und wendet sich an dort tätige Netzwerk-Administratoren oder den betreuenden IT-Dienstleister. Mit open-sbs steht durch
die Kombination mit Scalix eine preisgünstige Alternative zu einem Microsoft Exchange
Server mit mehr Funktionalität zur Verfügung. Der open-sbs bietet unter anderem eine
integrierte Firewall, Viren-Sicherheit, lernenden Spam-Schutz, VPN, Fernzugriff und automatisierte Sicherheits-Updates. Die Installation ist automatisiert - in wenigen Minuten
soll der Server startbereit aufgesetzt sein.
Scalix verwendet einen selbstentwickelten Server-Kern, der aus den Elementen
Message Store, Directory und Routing besteht. Der Message Store basiert auf einer
Standard-Linux-Filesystemstruktur, skaliert bis in den Terabyte-Bereich und kann auf
Basis jedes Linux-Filesystems sowie auf Raids oder logischen Volumes angelegt
werden. Dabei wird jede Nachricht ungeachtet der Zahl der Empfänger nur einmal
gespeichert. Große Attachments, die an mehrere User verschickt werden, nehmen somit
nur einfachen Speicherplatz in Anspruch. Der Verzeichnisdienst ist ebenfalls eine
Eigenentwicklung, der nach außen über eine LDAP-Schnittstelle verfügbar gemacht
wird. Der Router basiert auf dem X.400-Standard, verarbeitet aber auch andere
Adressformate. Das Internet-Gateway lässt eine Konvertierung der Nachrichten in
MIME- und TNEF-Format zu, letzteres spielt vor allem bei der Querverbindung mit MSExchange eine Rolle, da hier Nachrichten mit allen Sondermerkmalen ausgetauscht
werden können.
295
http://downloads.scalix.com/.community/11.0.4/RELEASE_NOTES.html
Seite 330
Abbildung 36: Scalix-Plattform
Eine laufende Scalix-Instanz nimmt ohne angemeldete Benutzer etwa 30 MB RAM in
Anspruch. Die Grundanforderungen an die Hardware sind moderat, ein 2-CPU-IntelSystem mit 2 GB RAM ist im Regelfall für 5000 Benutzer ausreichend.
Als Betriebssystemplattform wird ausschließlich Linux verwendet, dabei werden die
Distributionen von RedHat und Suse auf i386- und zSeries-Plattformen unterstützt:

Red Hat Enterprise Linux ES

SUSE Linux Enterprise Server

Fedora Core

SUSE Linux
Scalix unterstützt auf der Windows-Plattform den Outlook-Client von Microsoft (2000,
XP, 2003) in deutscher und englischer Sprache. Die MAPI-Anbindung ist dabei eine im
„Workgroup―-Modus laufende Online-MAPI; eine lokale Datenspeicherung auf dem
Client findet nicht statt. Die Funktionalität der Offline-Arbeiten kann jedoch eingerichtet
werden. Regeln und Abwesenheitsbenachrichtigungen werden auf dem Client eingerichtet und serverseitig ausgeführt. Besprechungsplanungen mit Frei/Belegt-Funktion, automatisches Buchen von Ressourcen, Zugriff auf fremde Mailboxen über Delegation sowie
die Rechtevergabe auf private und öffentliche Ordner werden analog zu Microsoft Exchange gehandhabt, lediglich serverbasierte Formulare werden nicht unterstützt. Das
„Look & Feel― von Outlook im Zusammenspiel mit Exchange wird dabei weitestgehend
beibehalten.
Scalix bietet weiterhin einen eigenen Webclient an. Dieser verfügt über Drop-DownMenüs, Drag-und-Drop-Funktionalität und eine Darstellung, die an eine echte WindowsApplikation erinnert. Dabei kommen in „Scalix Web Access― (SWA) lediglich JavaScript
und dynamisches HTML (DHTML) zum Einsatz. Technologien wie Java-Applets oder
ActiveX-Elemente werden nicht eingesetzt, sodass der Webclient auch in sicheren
Netzwerkumgebungen und im Zusammenhang mit Firewalls eingesetzt werden kann.
Als Browser werden Internet Explorer und Mozilla beziehungsweise Firefox auf den
Client-Plattformen Windows, Linux und Apple Mac OS/X unterstützt.
Seite 331
Standard POP/IMAP-Clients wie Mozilla Thunderbird, Outlook Express oder Ximian
Evolution können ebenfalls angebunden werden, das Adressbuch wird dabei über LDAP
angesprochen.
Scalix Enterprise Edition unterstützt alle führenden Anbieter von drahtlosen Endgeräten
über optionale Lösungen von Drittanbietern. Die Software NotifyLink der Firma Notify
Technology Corporation ermöglicht Nutzern den Zugriff auf alle Scalix Email und PIM
Funktionen (Kalender, Kontakte, Aufgaben und Notizen) über drahtlose Technologie an,
zum Beispiel Palm OS, Windows Mobile Geräte und Blackberrys296.
Abbildung 37: Scalix-Clientsysteme297
PDAs und Handhelds können derzeit über den Outlook-Client angebunden werden. Für
die Blackberry-Plattform steht in Zusammenarbeit mit Drittherstellern eine serverbasierte
Anbindung zur Verfügung. Die nachfolgende Abbildung zeigt einen Funktionsüberblick
über die drei verfügbaren Editionen:
296
297
http://www.scalix.com/documents/Scalix_DS_Enterprise_v3.pdf
http://www.scalix.com/enterprise/products/architecture.php
Seite 332
298
Abbildung 38: Scalix – Versionen/Funktionsüberblick
Eine rollenbasierte Administration ermöglicht das sichere Delegieren von Verwaltungsaufgaben an andere Benutzer mit vordefinierten Administrationsrechten. Diese erfolgt
über die Scalix Management Console, die eine Benutzeroberfläche für die System- und
Benutzerverwaltung anbietet. Sie verbindet die Möglichkeiten einer intuitiven grafischen
Oberfläche mit dem Komfort eines Webbrowsers, der jederzeit und überall verfügbar ist.
Die AJAX-basierte Management Console ermöglicht Mailadministratoren die Verwaltung
von Serverprozessen, Nachrichtenwarteschlangen und Standardeinstellungen bis hin zur
Überwachung des Message Store, der Konfiguration von Postfächern und Kennwortrichtlinien. Ebenfalls integriert sind die Überwachung des Systemstatus' sowie die Erstellung
von Aktivitäts- und Fehlerprotokollen.
Neben der Benutzeroberfläche stehen bei Bedarf alle Verwaltungsaufgaben über eine
Befehlszeilenschnittstelle zur Verfügung. Hierfür werden 250 Befehlszeilen-Skripte angeboten.
Die Kommunikation zwischen den Clients und dem Server kann vollständig verschlüsselt
(SSL/TSL) erfolgen. Die verschlüsselte Kommunikation kann mittels der Protokolle
IMAPS, LDAPS und POP3S realisiert werden.
Der Scalix Mail Server lässt sich mit jedem LDAP-basierten Verzeichnis integrieren, zum
Beispiel mit Microsoft Active Directory, Novell eDirectory, RedHat/Fedora Directory
Server, OpenLDAP und anderen. Eine Integration mit anderen Systemen ist über
Management Services - SOAP-basierte APIs möglich, über die andere Anwendungen
Funktionen im Scalix-Produkt aufrufen können.
298
http://de.scalix.com/enterprise/editions/compare.php
Seite 333
Abbildung 39: Scalix- Integration
Zusammenfassend ist festzuhalten: Durch die in der Enterprise Edition verfügbare Möglichkeit, das System auf mehreren Servern zu betreiben, zeichnet sich Scalix durch eine
große Skalierbarkeit (mehr als 10000 User pro Server möglich) aus. Das Konzept
„Clients of Choice― ermöglicht die gleichzeitige Anbindung verschiedener Arbeitsplatztypen. Die SOAP-basierten APIs bieten zusätzliche Möglichkeiten, das Produkt mit bestehenden Infrastrukturen zu integrieren. Vorteilhaft ist ebenfalls die mögliche Koexistenz mit Exchange durch die Konvertierungsmöglichkeiten des Internet-Gateways.
1.7
Microsoft Exchange Server 2007
Der Microsoft Exchange Server 2007 blickt auf eine Reihe von Entwicklungsschritten in
der Vergangenheit zurück. Die erste Version, Exchange Server 4.0, erschien 1996 als
Nachfolger von Microsoft Mail (Version 3.5). In der Folge erschienen Exchange Server
5.0 (1997), Exchange Server 5.5 (1998), Exchange Server 2000 und Exchange Server
2003. Dieser ist die Vorgängerversion der aktuellen Version, Exchange Server 2007.
Der Microsoft Exchange Server besitzt in seinem Marktsegment einen Marktanteil von
ca. 34 %299. Ein Exchange Server kann entweder direkt über Microsoft lizensiert und
eigenständig eingerichtet oder aber als Dienst über einen Drittanbieter lizenziert und
bereitgestellt werden.
Von Microsoft wird Exchange nach dem Server / Client Access License (CAL) Modell
vertrieben. Danach wird für jedes Betriebssystem mit installiertem Exchange Server eine
eigene Serverlizenz benötigt. Zusätzlich wird für jeden Benutzer des Exchange Servers
eine eigene CAL benötigt.
299
The Radicati Group, Inc.'s latest study, ―Microsoft Exchange Server and Outlook Analysis,
2007-2011"
Seite 334
Serverlizenzen für Exchange Server 2007 gibt es in zwei verschiedenen Varianten:

Standard Edition
Diese unterstützt einen Exchange Cluster mit bis zu fünf Knoten

Enterprise Edition.
Diese unterstützt bis zu 50 Knoten
Ebenso gibt es auch die CAL in zwei Versionen:

Standard CAL
Hierin sind die Standfunktionen Email, Kalender, Kontaktverwaltung, Aufgabenverwaltung, Journalführung, Notizen, Outlook Web Access und Exchange ActiveSync enthalten.

Enterprise CAL.
Diese enthält neben den Standardfeatures noch zusätzliche Dienste wie etwa
das Unified Messaging zum Empfangen und Versenden von Sprachnachrichten
oder Faxnachrichten.
Alternativ kann Exchange auch in Form des Windows Small Business Server (SBS)
Paketes erworben werden. Dieses beinhaltet sämtliche für den Betrieb von Exchange
2007 notwendigen Microsoft Technologien.
Rückblickend hat mit der Version 2000 ein grundlegender Wechsel in der Architektur des
Exchange Servers stattgefunden. Seit der Version Exchange Server 2000 ist Active
Directory ein fester Bestandteil jeder Installation. Gleichzeitig wurde in Version 2000
erstmals die optionale Einrichtung von reinen Front-end Exchange Servern eingeführt,
die verschiedene Aufgaben zur Reduktion der Last auf den Mailbox Servern übernehmen.
In Exchange Server 2007 wurde diese Unterteilung des Servers in verschiedene Aufgaben auf nun insgesamt fünf modulare Serverrollen erweitert. Von dieser Aufteilung verspricht sich Microsoft eine Verbesserung in den Bereichen Installation, Management,
Sicherheit und Skalierbarkeit einer Exchange Server Installation.
In Exchange Server 2007 wurde ein Rollenkonzept mit fünf verschiedenen Rollen eingeführt, deren Zusammenspiel in Abbildung 40 gezeigt wird. Mit Ausnahme der Edge
Transport Rolle können dabei alle Rollen auf dem gleichen Server installiert werden. Der
Edge Transport Server überwacht als eine Art Türsteher den externen Datenverkehr und
muss aus Sicherheitsgründen außerhalb des lokalen Netzwerkes installiert werden.
Jeder Exchange Server in einem Cluster von Exchange Server erhält während der Installation eine oder mehrere der folgenden Rollen zugewiesen:

Client Access Rolle:
Seine Aufgabe ist es, den Internet Traffic zu analysieren und an den korrekten
Mailbox Server weiterzuleiten.

Mailbox Rolle:
Server in dieser Rolle verwalten die Postfächer der Benutzer. Postfächer sind in
Datenbanken gespeichert, die jederzeit repliziert oder geclustert werden können.
Seite 335

Hub Transport Rolle:
Leistet das interne Routing aller Nachrichten, die von Edge- oder Unifed Messaging Servern innerhalb des gleichen Mailbox Servers gesendet werden.

Unified Messaging Rolle:
Diese Rolle erlaubt die Integration von PBX300 und damit den Versand von Fax
und Sprachnachrichten an Exchange Postfächer.

Edge Transport Rolle:
Server in dieser Rolle müssen außerhalb des Intranets eingerichtet werden. Ihre
Aufgabe ist die Überwachung und Filterung des externen Datenverkehrs.
Abbildung 40: Zusammenspiel der Server Rollen301
Exchange unterstützt die standardisierten Protokolle SMTP, POP3, IMAP und NNTP.
Das Mail Application Programming Interface (MAPI) stellt eine umfangreiche Schnittstelle für Clients dar, um mit dem Exchange Server 2007 zu kommunizieren. Nur Clients,
die die MAPI-Schnittstelle unterstützen, können den vollen Funktionsumfang von Exchange nutzen. Da diese Schnittstelle nicht vollständig offen gelegt ist, sind die einzigen
voll kompatiblen Clients Microsoft-Produkte.
Durch die Integration von HTTP können Dokumente in öffentlichen Ordnern über das
Internet zugänglich gemacht werden. Komplexere Dokumenten-ManagementFunktionen werden jedoch erst nach Anbindung einer Sharepoint Installation ermöglicht.
Durch die Verwendung des Microsoft Internet Information Server (IIS) und des Exchange
Servers 2007 können die Benutzer durch Outlook Web Access (OWA) auf Funktionalitäten zurückgreifen, die sonst nur mit dem Outlook-Client möglich wären. Die Nutzer können beispielsweise private und öffentliche Ordner einsehen, Emails versenden und empfangen und ihre Aufgaben verwalten. Der vollständige Funktionsumfang ist jedoch nur im
Zusammenspiel mit dem Microsoft Internet Explorer nutzbar.
300
301
Private Branch Exchanger
Quelle: An Overview of Microsoft Exchange Server 2007, Microsoft White Paper,
http://www.microsoft.com/exchange/evaluation/ex2007intro.mspx, letzter Zugriff:
04.09.2007
Seite 336
Aus Sicht des Nutzers stellt Exchange die folgenden Funktionalitäten zur Verfügung:

Empfang und Versand von Email-, Sprach- und Faxnachrichten

Aufgabenverwaltung

Terminverwaltung

Adresslisten (allgemeine Adressbücher und persönliche Kontakte)

Journalführung

Notizen.
Der Zugriff wird ermöglicht durch:

Email Clients (z. B. Outlook, Thunderbird, Netscape, etc.)

Webzugriff per OWA

Mobiler Zugriff per Active Sync.
Exchange Server 2007 nutzt das SMTP Protokoll zum Übermitteln von Nachrichten
innerhalb einer Organisation. Der Nachrichtenaustausch zwischen den Servern wird
standardmäßig per Transport Layer Security (TLS) verschlüsselt. Standardmäßig
werden auch verschlüsselte Remote Procedure Calls (RPC) für Outlook Verbindungen
verwendet. Die Kommunikation mit anderen Clients wird per Secure Sockets Layer
(SSL) verschlüsselt. Als Authentifizierungsmechanismus kommt Kerberos zum Einsatz.
Zum Schutz vor Viren, Phishing und Spam-Mails übernimmt der Edge Server eine
wichtige Funktion, er kann Nachrichten schon vor Eintreten in das Organisationsnetz auf
Spam oder Viren prüfen302. Hierfür setzt Microsoft das eigene Produkt ForeFront303
Security for Exchange Server (ForeFront) ein. Dieses kann auch auf Hub Transport
Servern installiert und genutzt werden. ForeFront sieht die simultane Nutzung von bis zu
fünf Scan-Engines vor. Zur Auswahl stehen hier Scan-Engines mehrerer Hersteller, die
jedoch zusätzlich lizensiert werden müssen. Dies sind zum Beispiel für die Virenabwehr
u.a. die Scan-Engines CA InoculateIT, CA Vet, Norman und Sophos304
Mit Hilfe eines Software Developer Kits können eigene Lösungen auf Exchange Server
2007 Basis entwickelt werden. Microsoft bietet dazu einen Exchange-Namespace für
das .NET Framework an, mit dessen Hilfe Exchange Funktionen in einer .NET Programmiersprache genutzt werden können. Mit Hilfe des SDKs ist auch die Anbindung
externer Software an Microsoft Exchange möglich.
Weiterhin bietet der Exchange Server 2007 eine Reihe von Standard-Webservices an,
mit denen die Funktionalitäten von Exchange von einer beliebigen Applikation aus aufgerufen werden können.
302
303
304
http://technet.microsoft.com/en-us/library/aa996551.aspx (Stand 01.11.2007)
http://www.microsoft.com/technet/forefront/serversecurity/exchange/scanning/e25af7f68f6a-420a-8a8a-2360eec4c75a.mspx?mfr=true (Stand 01.11.2007)
http://www.microsoft.com/antigen/prodinfo/antigen-faq.mspx (Stand 01.11.2007)
Seite 337
Standardmäßig können Exchange und Outlook mit anderen Microsoft Produkten
zusammenarbeiten. Beispiele dafür sind:

Die Windows Sharepoint Services (WSS 3.0) bieten als kostenfreier Bestandteil
des Windows Server 2003 Dokumenten-Management-Funktionalitäten auf Basis
des IIS Servers an. Die Integration mit Sharepoint ermöglicht den Check-in und
Check-out von Dokumenten in Sharepoint-Bibliotheken mit Versionskontrolle.

In Form des Microsoft Office Sharepoint Server (MOSS) bietet Microsoft eine
Lösung zur Erstellung umfangreicher Unternehmensportale an. Den Benutzern
können hier Informationen des Exchange Servers auf personalisierten Webseiten
zur Verfügung gestellt werden.

Seit der Exchange Server 2000 Version ist die Instant-Messaging-Komponente in
ein eigenes Produkt ausgegliedert worden. Echtzeit-Kooperationsfunktionalität
wird nun durch separate Installation des Office Live Communication Servers integriert.
Zusammengefasst heißt das: Der Exchange Server 2007 ist einer der Marktführer in
seinem Sektor. Er verfügt über wichtige Funktionen und besitzt in Form von Outlook
einen leistungsfähigen Clienten. Per OWA präsentiert Exchange dem Nutzer auch ohne
installierten Client seine persönlichen Daten komfortabel in einer Outlook-ähnlichen
Oberfläche, die über einen Webbrowser erreicht und dargestellt wird. Zusammen mit der
Möglichkeit des Zugriffs von mobilen Endgeräten aus, kommt Microsoft damit seinem
Ziel des Anywhere Access sehr nah.
Das Festhalten an geschlossenen eigenen Microsoft-Protokollen verhindert jedoch eine
reibungslose Integration von Exchange mit Produkten außerhalb der Microsoft Welt. Die
ausschließliche und enge Verflechtung mit anderen Microsoft Produkten macht im
Gegenteil sogar oft von anderer Software des Herstellers abhängig. So ist zum Beispiel
für den Einsatz von Exchange die Anschaffung eines Windows Server Betriebssystem
unumgänglich.
1.8
Lotus Notes
Lotus Notes ist ein dokumentenorientiertes, verteiltes Datenbanksystem mit sehr enger
E-Mail-Anbindung. Es wurde seit 1984 von Iris Associates entwickelt, einer späteren
Tochterfirma der Lotus Development Corporation resp. von IBM. Das ursprünglich Lotus
Notes genannte Produkt wurde auf Serverseite mit Version 4.5 umbenannt in Lotus
Domino.
Lediglich die Client-Software für Endnutzer (nicht jedoch jene für Entwickler und Administratoren) trägt noch den Namen Lotus Notes. Bei den Datenbanken findet sich sowohl
die Bezeichnung Notes-Datenbank als auch Domino-Datenbank. In Kombination mit der
Notes-Datenbank beziehungsweise dem neu veröffentlichten Produkt Quickr präsentiert
es eine Kooperationsumgebung im Sinne der Teaming/Workgroup-Software Kategorie.
Da der Notes Client im engeren Sinne aber ein Groupware/Messaging Produkt ist, wird
es hier erwähnt. Etwa Mitte 2007 veröffentlichte IBM Notes in der Version 8, die nun auf
der Eclipse Technology basiert.
Seite 338
Die Funktionalität des Notes-Clients umfasst folgende Groupwareanwendungen:

Mail

Kalender

Kontakte

ToDo Listen

Instant Messaging/Presence (Sametime)
Zusätzlich stehen Büroanwendungen (Präsentationen, Kalkulationen und Dokumente)
zur Verfügung.
Der Client wurde mit der neuen Version vollständig überarbeitet und steht sowohl als
eigener Client als auch als Web-Client zur Verfügung. Neben der Interfaceüberarbeitung
bietet die neue Version zwei Besonderheiten, auf die im Folgenden kurz eingegangen
wird.
Eine Besonderheit der neuen Version ist die Aktivitätsorientierung. Dazu stellt der Client
eine Activity-Sidebar zur Verfügung, mit deren Hilfe der Benutzer Aktivitäten einrichten
kann. Diesen Aktivitäten können dann andere Objekte der Notes Umgebung (Mails,
Termine, Todos, Dokumente etc.) zugewiesen werden. Damit soll das persönliche Informationsmanagement vereinfacht werden.
Abbildung 41: Notes Architektur
Zur Integration mit anderen Anwendungen setzt IBM auf den offenen Standard des Eclipse Application Development Frameworks sowie einer komponentenbasierten Serviceorientierten Architektur. Damit können sogenannte Composite Applications entwickelt
werden, die die Einbindung externer Anwendungsdaten in den Notes Client ermöglichen.
Die vorhergehende Abbildung 41 aus dem Beta Reviewer‘s Guide illustriert das entsprechende Zusammenspiel des Notes Client mit dem WebSphere Portal und dem Domino
Server.
Seite 339
Mit der neuen Version 8 hat IBM der schon seit Jahren auf dem Markt befindlichen Notes
Groupware ein neues Gesicht gegeben. Dabei wurde mit der Aktivitätsorientierung ein
besonderes Merkmal eingeführt. Der mit dem Web 2.0 verbundene Trend zur Unterstützung von Mashups305 wird mit dem Konzept der Composite Applications unterstützt. Seine volle Stärke zeigt Notes in Kombination mit Domino, da damit über das Messaging
hinaus Kooperationsprozesse und Workflows unterstützt und automatisiert werden können.
2
Migrationspfade
Die im folgenden Kapitel untersuchten Migrationspfade beschränken sich auf ausgewählte Systeme und berücksichtigen verschiedene Aspekte einer Migration. Die untersuchten Migrationspfade sollen Möglichkeiten aufzeigen, wie zwischen verschiedenen
Systemen (z. B. proprietären und OpenSource-Systemen), verschiedenen Versionen
eines einzelnen Systems und zwischen Systemen mit unterschiedlichen Benutzungsschnittstellen beziehungsweise -konzepten migriert werden kann.
Jeder der folgenden Abschnitte beschreibt, wie zwischen verschiedenen GroupwareSystemen Daten ausgetauscht werden können und welche Hilfsmittel hierzu nötig sind.
Der Fokus eines jeden Migrationspfades richtet sich auf das Aufzeigen möglicher
Schnittstellen, die es erlauben, essentielle Informationseinheiten wie

E-Mails

Adressdaten

Kalenderinformationen
effizient zwischen Systemen zu transferieren. Die aufgezeigten Migrationspfade zielen
sowohl auf eine direkte Server- zu Servermigration als auch auf eine indirekte Migration
mit Hilfe eines Clients wie zum Beispiel Outlook oder Kontact ab. Die indirekte Migration
nutzt primär die vorhanden Clientanwendung für den Abgleich von Daten und wird insbesondere dann notwendig, sobald Informationseinheiten wie die oben aufgelisteten
(z. B. Email oder Kontakte) lokal in der jeweiligen Anwendung gespeichert wurden. Die
Frage, wann eine direkte beziehungsweise indirekte Migration gewählt werden sollte,
hängt sowohl von der Anzahl an Nutzern als auch von der Verfügbarkeit an Zusatzsoftware ab. Ist die indirekte Migration für den einzelnen Nutzer leicht zu bewerkstelligen,
sollte zwischen dem Aufwand einer direkten Migration, welche den Einsatz eines Experten mit sich zieht, und einer indirekten Migration, welche jeden Nutzer mit einbezieht,
sorgfältig abgewogen werden. Ferner sollte bei einer Migration auch berücksichtigt werden, ob gewisse Daten weiterhin auf der Clientseite verbleiben oder in die neue Groupware überführt werden.
2.1
Migration von MS Exchange 5.5/2003 nach Kolab 2
Dieses Kapitel beschreibt die Migration von Microsoft-Exchange 5.5/2003 zu Kolab2.
Aufgrund der teilweise großen Unterschiede der Exchange-Versionen 5.5 und 2003 werden generelle Unterschiede in der Handhabung im Text angesprochen.
305
Die Einbindung externer dynamischer Elemente in eine Webseite.
Seite 340
Eine indirekte Migration via Client ist in diesem Migrationspfad möglich. Mit Hilfe von
Konnektoren (siehe hierzu Kapitel III.A 1.5), die eine Verbindung zum Kolab-Server
aufbauen, ist es möglich direkt aus der Clientanwendung wie zum Beispiel Outlook die
Email-, Kontakt- und Kalenderdaten von Exchange 5.5/2003 nach Kolab 2 zu überführen. Dies schließt auch die optionale Migration lokaler Daten ein und ermöglicht
darüber hinaus auch die Migration von Client zu Client (zum Beispiel von Outlook zu
Kontact). Darüberhinaus eignet sich die OpenSource basierte und plattformunabhängige
Anwendung „kdepimpi―306 für den Transfer von einem System zum anderen.
2.1.1
Migration der Adress- und Verzeichnisdaten
Im Falle eines Windows Exchange Servers 2003 werden die Adress- und Verzeichnisdaten im Active Directory des Windows Server Betriebssystems verwaltet. Active Directory hat einen ähnlichen Aufbau wie LDAP. Microsoft bietet verschiedene Tools an, mit
deren Hilfe Daten aus dem Active Directory exportiert und in den Kolab LDAP-Server
integriert werden können. Das Kommandozeilen Tool LDIFDE ist hierbei hilfreich und
exportiert die Daten aus dem Active Directory Server in das LDAP Data Interchange
Format (LDIF), welches wiederum vom LDAP-Server importiert werden kann.
Eine Extraktion der Daten aus Exchange kann alternativ mit Hilfe des Exchange Migration Wizards durchgeführt werden. Der Exchange Migration Wizard existiert seit Exchange 2000 als separates Tool und erlaubt es, Daten einer alten Exchange Installation in
einer Ordnerstruktur zu speichern. In der Version Exchange 5.5 ist es möglich, den
LDAP-Dienst direkt zu aktivieren, sodass per LDAP Adress- und Verzeichnisdaten ausgelesen werden können307.
Auf Basis des LDIF-Formates können die Adress- und Verzeichnisdaten in die Systemkomponente OpenLDAP des Kolab-Servers übernommen werden. Das offene Format
der LDIF-Spezifikation erlaubt es zudem, die Daten vor der Migration in das Zielsystem
zu bearbeiten. Aufgrund der nachvollziehbaren Struktur des Formates ist sowohl eine
manuelle als auch automatische Modifikation der Daten möglich.
Die Migration hin zum Kolab LDAP-Server kann mit verschiedenen Anwendungen und
Benutzungsschnittstellen erfolgen. Neben den Standardtools des OpenLDAP-Servers
existieren Desktop-Anwendungen wie zum Beispiel der javabasierte JXPlorer308 und
auch webbasierte Lösungen wie zum Beispiel „phpLDAPadmin―309, die neben Im- und
Export des LDIF-Formates auch eine Administration des OpenLDAP-Servers erlauben.
Hierbei ist anzumerken, dass für die webbasierte Lösungen meist ein eigens eingerichteter Webserver betrieben werden muss. Die Struktur eines LDAP-Verzeichnisses ist individuell anpassbar und kann durch den Einsatz von Schemata auf organisationsspezifische Bedürfnisse zugeschnitten werden. Aufgrund der flexiblen Struktur eines
LDAP-Verzeichnisses sollte im Vorfeld einer Migration im Einzelfall analysiert werden,
welche Attribute und Eigenschaften des Verzeichnisses angepasst werden müssen, um
die semantischen Zusammenhänge des Verzeichnisses beizubehalten.
306
307
308
309
http://sourceforge.net/project/showfiles.php?group_id=104103
http://www.selfadsi.de/att55mbx.htm
http://www.jxplorer.org/
http://phpldapadmin.sourceforge.net/
Seite 341
Für die Migration von Kontaktdaten, die direkt in der Client-Anwendung gespeichert werden, bestehen für Adressdaten ebenfalls Standardformate (zum Beispiel vCard-Format),
die zwischen verschiedenen Anwendungen ausgetauscht werden können. Darüberhinaus sei hier auf die o.g. Möglichkeit des Einsatzes von Konnektoren verwiesen.
2.1.2
Migration von E-Mail
Die Synchronisation der E-Mail-Daten kann sowohl auf der Client- als auch auf der
Serverseite erfolgen. Besonders bei der vorherigen Benutzung des POP3-Protokolls
bietet sich eine clientseitige Nutzung des eigenen E-Mail-Programms (zum Beispiel
Outlook) an, um gegebenenfalls alle Nachrichten auf den IMAP-Server zu migrieren. Für
eine server-seitige Synchronisierung via IMAP bietet sich das Kommandozeilenprogramm „imapsync―310 an, welches zwei verschiedene IMAP-Konten miteinander
synchronisieren kann. Lösungen für die serverseitige Synchronisierung wie zum Beispiel
imapsync setzen allerdings voraus, dass die jeweiligen Nutzerdaten für die Migrationsmaßnahme bereitgestellt werden. Überdies kann es auch vorkommen, dass der MailStatus (z. B. gelesen, ungelesen) nicht immer mitgesichert wird.
Zur Extraktion der E-Mail Postfächer kann ebenfalls der o. g. Migration Wizard genutzt
werden. Eine weitere Alternative besteht in der Nutzung des Microsoft Werkzeuges
ExMerge zusammen mit dem Tool Readpst311. Mit Hilfe von ExMerge können serverseitig komplette Postfächer in PST Dateien gespeichert werden. Readpst konvertiert
diese in das mbox-Format, die IMAP-Komponente von Kolab kann dieses Format
nutzen, um die Daten in die einzelnen Postfächer zu überführen.
Neben den hier beschriebenen Ansätzen zur Migration zwischen MS-Exchange und Kolab2 bietet die Firma Toltec ein Migrations-Tool312 an, welches E-Mail, Kalender, Kontakte und andere Daten zwischen MS-Exchange und Kolab2 migrieren kann.
2.1.3
Migration der Kalender
Die Webschnittstelle des Kolab-Servers (Horde/Kronolith) bietet über eine Export/Import
Funktion die Möglichkeit, Kalenderinformationen direkt in das System zu überführen.
Hierfür kann das verbreitete Datenformat iCalendar benutzt werden, welches von vielen
Clientanwendungen (zum Beispiel Outlook) als Exportformat angeboten wird. Ebenfalls
bietet Outlook in der Kombination mit den erwähnten Konnektoren (siehe Kapitel III.A
1.5) die Möglichkeit, Kalenderdaten manuell zwischen zwei Servern auszutauschen und
so ein explizites im- beziehungsweise exportieren zu umgehen.
2.1.4
Fazit
Zusammenfassend lässt sich festhalten: Das Kommandozeilenprogramm „imapsync― ist
relativ einfach in eigenentwickelte Skripte zu integrieren, was einen hohen Grad an Automatisierung zulässt.
Ähnliches gilt für die Synchronisation von Adress- und Verzeichnisdaten. Hier ist es
möglich, mit Hilfe eines grafischen Webclients die Daten zentral in das jeweilige Aus-
310
311
312
http://www.linux-france.org/prj/imapsync/README
http://alioth.debian.org/projects/libpst/
http://www.toltec.co.za/migration.html
Seite 342
tauschformat zu übertragen. Bei der hier beschriebenen Migration ist die Referenz für
beide Systeme der Outlook-Client. Hierbei sollte jedoch beachtet werden, dass sich der
Einsatz von Outlook ohne Verwendung von Zusatzsoftware lediglich auf den Abruf von
E-Mail-Daten via IMAP-Protokoll beschränkt. Eine volle Ausschöpfung der bereitgestellten Funktion des Kolab-Servers ist erst unter Verwendung der in Kapitel III.A 1.5
erwähnten Konnektoren möglich. Ferner ist der Einsatz eigener Formulare innerhalb des
Outlook-Clients nicht mehr möglich. Bezüglich der Zusatzsoftware kann im Leitfaden
keine generelle Aussage getroffen werden, dies ist im Einzelfall zu prüfen.
2.2
Migration von Kolab 2 nach MS Exchange 2007
Dieser Abschnitt beschreibt die Migration von Kolab2 zu Exchange 2007. Äquivalent zu
der oben beschriebenen indirekten Migration besteht auch hier die Möglichkeit, mit Hilfe
von Konnektoren (siehe hierzu Kapitel III.A 1.5), Email, Kontakt- und Kalender-Daten
relativ einfach von Kolab 2 nach MS Exchange 2007 zu überführen.
2.2.1
Migration der Adress- und Verzeichnisdaten
Vergleichbar der Migration von MS-Exchange 5.5/2003 zu Kolab 2 kann für die Migration
auf MS-Exchange 2007 ebenfalls auf das LDIF-Format zurückgegriffen werden. Die
Standardtools des OpenLDAP-Servers und insbesondere die bereits erwähnte Desktopbeziehungsweise Webanwendungen „JXplorer― beziehungsweise „phpLDAPadmin― (siehe oben) können für den Export der Adress- und Verzeichnisdaten genutzt werden. Die
Struktur des LDAP-Verzeichnisses des Kolab-Servers muss durch eine Transformation
der Verzeichnis-zusammenhänge auf das Schema des Exchange Servers angepasst
werden.
Darüber hinaus besteht die Möglichkeit, lokal gespeicherte Adressdaten via Konnektor
oder mit Hilfe des vCard-Formats auf der Clientseite zu exportieren. Mit Hilfe des Werkzeuges LDIFDE können diese Daten in das Active Directory des Windows Servers geschrieben und damit von Exchange 2007 genutzt werden.
2.2.2
Die Migration der E-Mail-Daten kann sowohl auf der Client- als auch auf der Serverseite
erfolgen. Neben der Möglichkeit einer indirekten Migration mit Hilfe eins Clients (zum
Beispiel Outlook oder Kontact) ist es auch möglich, eine serverseitige Synchronisierung
via IMAP durchzuführen. Hierfür bietet sich ebenfalls das (siehe Abschnitt III.A 2.1.2)
Kommandozeilenprogramm „imapsync―313 an, welches zwei verschiedene IMAP-Konten
miteinander synchronisieren kann. Für diese Art der Synchronisierung muss der MSExchange-Server gewährleisten, dass auf die E-Mailaccounts mittels IMAP-Protokoll
zugegriffen werden kann.
Eine andere Methode besteht darin, die im MBOX Format vorliegenden Postfächer des
Kolab Servers in PST (Personal Storage Table) Dateien zu konvertieren. Diese können
mit Hilfe von ExMerge oder des Exchange Migration Wizards in Exchange 2007 verfügbar gemacht werden. Für diesen Arbeitsschritt existieren verschiedene kostenfreie oder
313
Seite 343
kostenpflichtige Werkzeuge314, von denen jedoch einige zunächst in das Zwischenformat
EML (Outlook Express Electronic Mail) zu konvertieren sind. Diese Methode ist insbesondere dann interessant, wenn eine große Anzahl an Postfächern migriert werden
muss.
2.2.3
Migration der Kalender
Über die Webschnittstelle des Kolab-Servers (Horde/Kronolith) können Nutzer- und
Gruppenspezifische Kalender über eine Export Funktion mit Hilfe des iCalendar-Formats
direkt in andere Anwendungen überführt werden. Ebenso eignet sich der Einsatz von
Konnektoren (zum Beispiel der Toltec-Connector) zum Transferieren der Kalenderdaten
zum Beispiel via Outlook von Kolab nach MS-Exchange 2007.
2.2.4
Fazit
Zusammenfassend ist zu bemerken: Der Aufwand der Migration hängt stark von der Art
der zu migrierenden Daten ab. So lässt sich beispielsweise das Kommandozeilenprogramm „imapsync― relativ einfach in eigenentwickelte Skripte integrieren, die einen
höheren Grad an Automatisierung zulassen. Der Aufwand für die Synchronisation von
Adress- und Verzeichnisdaten ist abhängig vom Grad der Anpassung des LDAPVerzeichnisses und der damit verbundenen Transformation. Mit Hilfe diverser Clientanwendungen ist es möglich, die Daten zentral in das jeweilige System zu übertragen
und somit den Prozess vor und nach der Transformation zu vereinfachen. Manueller
Aufwand ist auch bei der Migration der Kalenderdaten zu bedenken. Dieser ist aber von
der Anzahl der Kalender abhängig, die im Kolab-Server verwaltet werden. Alternativ
können auch hier Client- beziehungsweise nutzerbasierte Migrationsszenarien (zum Beispiel via Outlook und integriertem Konnektor) den Aufwand minimieren.
2.3
Migration von MS Exchange 5.5 nach MS Exchange 2007
Da die Versionen Exchange 5.5, Exchange 2000, Exchange 2003 und Exchange 2007
jeweils auf Basis der vorherigen Version entwickelt wurden, besteht neben der Möglichkeit einer Migration auch die Möglichkeit der Transition. Eine Transition entspricht dabei
einem Upgrade einer existierenden Exchange Organisation auf eine neuere Version.
Eine Migration liegt vor, wenn von einer existierenden auf eine neue Exchange Organisation gewechselt wird, ohne die bisherigen Konfigurationsdaten der existierenden Exchange Installation zu verwenden. Dieses Szenario tritt häufig bei der Zusammenführung zweier bislang getrennt agierender Installationen auf.
Allgemein ist es nicht möglich, eine direkte Transition oder Migration von Exchange 5.5
auf Exchange 2007 vorzunehmen. Der gängige Weg besteht hier darin, zuerst zu
Exchange 2003 zu migrieren und anschließend eine Transition von Exchange 2003 auf
Exchange 2007 durchzuführen. Mehr Informationen hierzu sind im Microsoft TechNet315
zu finden.
314
315
http://www.aid4mail.com/
http://technet.microsoft.com/en-us/library/aa997461.aspx
Seite 344
2.3.1
Durchführung einer Transition
Eine Transition von Exchange 2003 nach Exchange 2007 kann nicht in Form eines
reinen Updates auf Basis der existierenden Installation erfolgen. Stattdessen muss
zunächst immer innerhalb der gleichen Organisation Exchange 2007 parallel installiert
werden. Dies führt dazu, dass es bei einer Transition immer zu einer zwischenzeitlichen
Koexistenz der alten und neuen Exchange Installationen kommt.
Sobald Exchange 2007 innerhalb der gleichen Organisation installiert ist, können die
Daten der veralteten Exchange Version in die neue Installation von Exchange 2007 kopiert werden. Als Werkzeuge werden dabei im Wesentlichen die Exchange Management
Console und der Exchange System Manager genutzt. Es existieren zahlreiche Anleitungen316, die diesen Prozess im Detail beschreiben.
2.3.2
Durchführung einer Migration
Der Migrationsprozess auf ein neues Exchange 2007 System beinhaltet die Installation
einer komplett neuen Exchange 2007 Organisation. Anschließend müssen sämtliche
Inhalte (Postfächer, Kalender, Öffentliche Ordner, Benutzer etc.) des alten System nach
Exchange 2007 migriert werden. Zur Automatisierung der Migration der Postfächer bietet
Microsoft kostenfrei den Exchange Migration Wizard317 an. Zur Migration der Inhalte des
Active Directory stellt Microsoft die Tools LDIFDE und CSVDE zur Verfügung.
Alternativ zu diesen relativ einfachen Werkzeugen, die Microsoft selber zur Verfügung
stellt, existieren mehrere komplexe Werkzeuge von Drittanbietern, die diesen Prozess
noch weiter vereinfachen und automatisieren.
2.3.3
Fazit
Zusammengefasst bedeutet dies: Da es sich bei einer Migration einer alten Exchange
Version auf das neue Exchange 2007 um eine Migration innerhalb der gleichen Produktfamilie handelt, ist eine weitestgehend verlustfreie Migration der bestehenden Daten
möglich. Microsoft bietet im Internet zahlreiche Anleitungen, wie diese Migration in verschiedenen Ausgangssituationen im Detail durchzuführen ist318.
Eine direkte Migration von Exchange 5.5 auf Exchange 2007 ist jedoch nicht möglich. In
diesem Fall sind zwei Migrationen hintereinander durchzuführen. Dieses Vorgehen ist
entsprechend mit dem doppelten Aufwand verbunden, vergleichbar einer Migration von
Exchange 2003 auf Exchange 2007.
316
317
318
http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server2007-Part1.html
http://support.microsoft.com/kb/328871
http://technet.microsoft.com/en-us/library/bb124008.aspx
Seite 345
Die folgende Tabelle fasst die möglichen Migrations- und Transitionspfade zusammen:
Altes System
Transition zu
einer Exchange 2007 Organisation
Migration auf Exchange 2007
Exchange Server 5.5
Nicht unterstützt
Unterstützt, es muss jedoch erst von Exchange
5.5 nach Exchange 2003 oder Exchange 2000
migriert werden. Anschließend muss eine Transition von Exchange 2003 oder Exchange 2000 nach Exchange 2007 durchgeführt werden.
Exchange 2003
Unterstützt
Unterstützt
Exchange 2000
Unterstützt
Unterstützt
Tabelle 54: Mögliche Migrations- und Transitionspfade
2.4
Migration von eGroupware nach Lotus Notes 8
Nachfolgend werden die Möglichkeiten zur Migration von eGroupware nach Lotus
Notes 8/Lotus Domino 6 vorgestellt. Hierbei wird neben den Möglichkeiten zum Export
und Import der Daten auch die Integration von externen Verzeichnisdiensten und Mailservern betrachtet.
2.4.1
Export der Daten aus eGroupware
Auf der Benutzerseite unterstützt eGroupware lediglich den Export der Kalenderdaten im
iCal-Format. Serverseitig existieren zurzeit keine Exportwerkzeuge, da dies lt. Aussage
der Firma Outdoor Unlimited Training GmbH319 bisher von Kunden nicht anfordert wurde.
Aufgrund der offenen Architektur und der Verwendung von Standards wird jedoch eine
Vielzahl der Daten außerhalb von eGroupware verwaltet und damit in anderen Systemlösungen wie Lotus Notes 8/Lotus Domino nutzbar.
2.4.2
Datenverwaltung in externen Verzeichnisdiensten
Zur Datenverwaltung ist die Integration von externen Verzeichnisdiensten in eGroupware
möglich. Dies betrifft zunächst die Benutzerverwaltung. Die Speicherung und Administration der Benutzerdaten und die Authentisierung von Benutzern kann vollständig über
LDAP erfolgen. Zur externen Dateiverwaltung steht die Speicherung entweder im FileSystem oder auf einem Webserver mit WebDAV-Unterstützung zur Verfügung. Mit der
Integration von GroupDAV320 erlaubt eGroupware die externe Bereitstellung und den
Austausch von Kalendern, Aufgabenlisten, Kontaktlisten und Notizen.
319
320
http://www.outdoor-training.de/
http://www.egroupware.org/index.php?page_name=sync&wikipage=GroupDAV
Seite 346
2.4.3
Datenexport per XML-RPC
Für den externen Zugriff auf Funktionen und Daten des Adressbuchs und des Kalenders,
der Aufgabenlisten, Kontaktlisten sowie Notizen bietet eGroupware eine XML-RPCAPI321. Somit ist es möglich, eine Anwendung zu implementieren, die über HTTP die
Daten im XML-Format extrahiert und für den Import in Lotus Domino aufbereitet.
2.4.4
Die E-Mail-Funktionalität wird in eGroupware nicht über eine eigene MailserverKomponente, sondern über die Einbindung beliebiger SMTP und POP3/IMAP fähiger
Mailserver bereit gestellt. Die in Lotus Domino integrierte Email-Server-Komponente
bietet das POP3 und IMAP-Protokoll für die Übermittlung von E-Mail-Daten an. Für eine
Synchronisation der Email-Postfächer sei auf die bereits oben erwähnte Möglichkeiten
(zum Beispiel via Kommandozeilenprogramm „imapsync―) hingewiesen.
2.4.5
Import der Daten in Lotus Notes 8/Lotus Domino 6
Für die Migration von existierenden Groupware-Systemen auf Lotus Notes 8/Lotus
Domino bietet Lotus Werkzeuge, die sowohl auf der Benutzerseite als auch auf der
Server-Seite für die Migration von eGroupware nach Lotus Notes/Domino verwendet
werden können.
2.4.6
Datenimport auf Benutzerseite
Auf Benutzerseite ist in Lotus Notes 8 der Import von Kalenderdaten im iCal-Format aus
eGroupware problemlos. Ebenso besteht die Möglichkeit, Adressbuchdaten im VCardFormat in Lotus Notes 8 zu importieren. Bei der Evaluierung der Export-Werkzeuge von
eGroupware konnte allerdings nicht sicher geklärt werden, ob eGroupware das Exportieren von Adressbuchdaten im vCard-Format auf Benutzerseite anbietet. Grundsätzlich
ist jedoch festzuhalten, dass der Import durch den einzelnen Benutzer nur bei kleineren
Datenvolumina sinnvoll ist.
2.4.7
Integration von externen Verzeichnisdiensten in Lotus Domino 6
Die Migration der Benutzerkonten von eGroupware nach Lotus Domino ist möglich, sofern die Benutzerverwaltung in eGroupware durch die Integration eines LDAPVerzeichnisses realisiert ist. Mit Lotus Domino 6 stehen Funktionen zur Migration von
existierenden LDAP-konformen Benutzerverzeichnissen auf Lotus Domino zur Verfügung. Der LDAP Domino Upgrade Service322 bietet diverse Migrationsoptionen, u.a. die
Erweiterung des LDAP-Schemas. Es ist anzumerken, dass für die Nutzung der Lotus
Notes E-Mail-Funktionalität jeder migrierte Benutzer auch mit einer Notes ID in Lotus
Domino registriert sein muss. Zusätzlich können mit IBM Tivoli Directory Integrator 323
externe LDAP-Verzeichnisse integriert und synchronisiert werden. Auch hier sind die
321
322
323
http://www.egroupware.org/index.php?page_name=sync&wikipage=xmlrpc
http://www-12.lotus.com/ldd/doc/domino_notes/6.5/help65_admin.nsf/
b3266a3c17f9bb7085256b870069c0a9/bfd815f921a50c8d85256d9b004b022b?OpenDocu
ment
http://www.ibm.com/developerworks/lotus/library/lwp-msad/
Seite 347
bereits erwähnten Einschränkungen bezüglich variierender Schemata des LDAP-Verzeichnisses zu beachten (siehe Kapitel III.A 2.1 und III.A 2.2).
Lotus Domino 6 bietet einen integrierten Web-Server, der auch die Integration von WebDAV324 erlaubt. Somit kann zur Migration der in eGroupware verwalteten Dokumente die
WebDAV Integration auf beiden Seiten genutzt werden. Mit Hilfe des Domino Designers
kann das Design der in WebDAV verwalteten Dokumente gestaltet werden.
2.4.8
Datenimport auf Server-Seite
Beginnend mit Lotus Domino 6 liefert IBM mit Lotus XML Toolkit 325 eine Sammlung von
integrierten Klassen für Lotus Script, Java und C++, die den Datenimport und -export der
Datenbankinhalte erlauben. Mittels dieser Programmierschnittstelle können Daten und
Design aus existierenden Domino-Datenbanken auf der Basis von DXL (Domino XML)
extrahiert, modifiziert (via DOM und XSLT-Prozessor) und wieder importiert werden.
Hinsichtlich der Migration der in eGroupware verwalteten Kalender, Aufgabenlisten, Kontaktlisten und Notizen können die Daten unter Verwendung der XML-RPC-Schnittstelle
aus eGroupware im XML-Format ausgelesen, nach DXL transformiert und anschließend
in Lotus Domino importiert werden. DXL verfügt über detaillierte Gestaltungselemente.
2.4.9
Fazit
Zusammengefasst heißt das: Aufgrund der Verwaltung der Benutzer, E-Mails, Dokumente, Kalender, Adressbücher und Aufgabenlisten außerhalb von eGroupware und
ihren Austausch über standardisierte Protokolle wie iCal, LDAP, WebDAV und XML-RPC
ist der Export der Daten grundsätzlich möglich.
Auf Benutzerseite wird der Import der Kalenderdaten in Lotus Notes 8 im iCal-Format
unterstützt. Der LDAP Domino Upgrade Service und der IBM Tivoli Directory Integrator
ermöglichen die Migration der LDAP-konformen Benutzerkonten beziehungsweise die
Integration des in eGroupware integrierten LDAP-Systems. Mit der Aktivierung von
WebDAV in Lotus Domino ist der Austausch von Dokumenten möglich, falls die Dokumentenverwaltung einer eGroupware-Installation über WebDAV realisiert ist. Ebenso
kann der SMTP-fähige Mailserver einer eGroupware-Installation in Lotus Domino eingebunden werden. Unter Verwendung der Programmierschnittstellen in eGroupware und
Lotus Domino können Anwendungen entwickelt werden, die den Datenexport aus eGroupware und den Import in Lotus Domino serverseitig realisieren.
Allerdings ist anzumerken, dass eGroupware neben den aufgeführten Daten auch Informationen wie Projektdaten, Umfragen, Diskussionen etc. verwaltet, welche intern in Datenbanksystemen gehalten werden und daher nicht problemlos exportierbar und für externe Anwendungen zugänglich sind.
IBM Business-Partner326 bieten eine Vielzahl von Dienstleistungen zur Migration nach
Lotus Notes/Domino.
324
325
326
http://www-12.lotus.com/ldd/doc/domino_notes/Rnext/help6_admin.nsf/f4b82fbb75e942
a6852566ac0037f284/9ba6f9d0158ccf7c85256c1d00397996?OpenDocument
http://www.ibm.com/developerworks/lotus/downloads/toolkits.html#notesdomino
http://www-304.ibm.com/jct03004c/businesscenter/smb/de/de/partnerfinder
Seite 348
2.5
Scalix nach eGroupware
Dieses Kapitel beschreibt die Migration von Scalix 11.2 nach eGroupWare 1.4. Hierbei
wird neben der Möglichkeit zum Export und Import der Daten auch die Integration von
externen Verzeichnisdiensten und Mailservern betrachtet.
Aufgrund der Systemkomplexität beider Systeme bei der Datenhaltung ist zu beachten,
dass globale Migrationsstrategien, das heißt „von Datenbank zu Datenbank auf Knopfdruck― schwer realisierbar sind und in jedem Fall eine Einzelfallbetrachtung erfordern.
2.5.1
Datenmigration
eGroupWare327 trägt dem Thema Datenmigration insofern Rechnung, indem auf Modulebene (Modul = eine Softwarefunktion wie zum Beispiel Kalender, Adressbuch, Aufgaben- und Projektmanager) standardisierte Datenaustauschverfahren unterstützt werden:
iCal: Kalenderinformationen, vCard: Adressinformationen; CSV: Kalender-, Adress-,
Aufgabenverwaltung, SyncML, GroupDAV; iCalServer: Kalender-, Adress-, Aufgabenverwaltung328; WebDAV: File- und Foldermanagement.
Im Ergebnis bedeutet das, dass eine Migrationsstrategie sowohl am Benutzer als auch
an der Dateninstanz ansetzen kann. Das heißt der einzelne Benutzer kann seine Daten
mit Hilfe der o.g. Werkzeuge eigenverantwortlich migrieren oder das Ausgangssystem
wird durch die Systemadministration insgesamt migriert wird.
2.5.2
Adress- und Verzeichnisdaten
Die Migration von Adressdaten aus Scalix kann über die Extraktion der individuellen
Benutzerkontakte per Benutzer im LDIF-Format (LDAP Data Interchange Format)
erfolgen. Die erzeugten LDIF-Dateien können vor dem Import nach eGroupWare mit
Shellskripten nach eigenen Vorgaben modifiziert werden. Das offene Format der LDIFSpezifikation erlaubt es, Daten vor der Migration in das Zielsystem zu bearbeiten.
Aufgrund der nachvollziehbaren Struktur des Formates ist sowohl eine manuelle als
auch eine automatische Modifikation der Daten möglich. Die zentrale Migration der
Daten kann mit verschiedenen Anwendungen und Benutzungsschnittstellen erfolgen.
eGroupWare-Anwender werden in der Datenbank verwaltet und können sich konfigurierbar sowohl an der Datenbank als auch an existierenden Authentisierungs-Systemen
anmelden. Durch die von eGroupWare verwendeten Technologien (zum Beispiel PHP,
Apache-Webserver, MySQL-Datenbank u.a.) ist das System plattformunabhängig und
sowohl auf Linux- wie auch auf Microsoft-Systemen lauffähig. Das bedeutet für die
Authentisierung, dass sowohl LDAP als auch zum Beispiel MS-ADS unterstützt werden.
Ein wichtiges Begleitfeature einer LDAP-Strategie dabei ist, dass zum Beispiel eGroupWare-Adressdaten im LDAP gespeichert werden und auf diese Weise weiteren
Anwendungen zugänglich gemacht werden können.
Eine LDAP-Anbindung kann rein zur Authentifizierung (wie auch IMAP, ADS, HTTP,
PAM etc.) oder als „Accountstorage" genutzt werden. Bei letzterem werden die
Benutzerdaten einschl. Gruppenzugehörigkeiten in LDAP verwaltet und stehen damit
327
328
www.egroupware.org
www.egroupware.org/sync
Seite 349
auch anderen Servern (IMAP, SMTP, Samba etc.) zur Verfügung. Mit Cyrus oder DBMail als IMAP Server und einem SMTP-Server der LDAP (zum Beispiel Postfix) können
die Benutzerdaten des Mailservers komplett aus der eGroupWare heraus verwaltet
werden (Alias, Weiterleitung, Quota, Folder ACL, Sieve-Filter und Urlaubsbenachrichtigungen).
2.5.3
E-Mail
eGroupWare beinhaltet einen eigenen E-Mail-Client. Durch die Abbildung der Software
als Webanwendung im Browser arbeitet der E-Mail-Client als Webmailer. Dieser Webmailer ist ein reiner IMAP-Client, POP3 wird nicht unterstützt. Hinsichtlich der originären
E-Mail-Funktion werden zahlreiche bekannte Mailserver unterstützt. Für die Nutzung in
eGroupWare verwaltbarer Funktionen wie zum Beispiel Filter- und Abwesenheitsregeln
sowie Zugriffsberechtigungen für die Zusammenarbeit von Benutzern in gemeinsamen
Mailordnern ist die Auswahl unterstützter Mailserver geringer. Volle Funktionalität steht
derzeit u.a. für DBMail und Cyrus-Mailserver zur Verfügung. eGroupWare nutzt zum
Versenden von Mails (u.a. auch für Aufgaben- und Termin-Notificationmessages) das
SMTP des mit der Groupware verbundenen Mailservers.
Für eine serverseitige Synchronisierung via IMAP von Scalix nach eGroupware bietet
sich das Kommandozeilenprogramm „imapsync―329 an, welches zwei verschiedene
IMAP-Konten miteinander synchronisieren kann. Bei der Migration von IMAP-Postfächern kann es jedoch vorkommen, dass der Mail-Status nicht immer mitgesichert wird.
2.5.4
Kalender
Die Migration von Kalenderdaten erfolgt pro Benutzer via API im iCal-Format, das heißt
sowohl die Extraktion aus Scalix als auch der Import nach eGroupware basieren auf der
Basis von iCal-Files. Eine Aufbereitung dieser Daten kann mittels der API erfolgen.
2.5.5
Fazit
Zusammenfassend ist festzuhalten: Der Aufwand der Migration hängt stark von der Art
der zu migrierenden Daten ab. So lässt sich beispielsweise das Kommandozeilenprogramms „imapsync― relativ einfach in eigenentwickelte Skripte integrieren, die einen höheren Grad an Automatisierung zulassen. Ähnliches gilt für die Synchronisation von Adress- und Verzeichnisdaten.
Bei der Datenmigration nach eGroupWare sind keine Überlegungen hinsichtlich der
Clientseite erforderlich. Wichtig ist jedoch, dass bei der Migration die bisherigen individuellen Rechte des Benutzers an seinem Altverfahren nach eGroupWare überführt werden müssen.
329
Seite 350
3
Bezüge
3.1
Webserver und Netzwerkdienste
Es können je nach Groupwareanwendung Bezüge zu verschiedenen Systemkomponenten vorhanden sein. Besonders die Produkte von Microsoft sind in der Regel hoch integriert und verwenden unter Anderem in manchen Installationen Funktionalitäten der Microsoft Internet Information Services. Hierzu ist das Kapitel zum Thema Webserver (Kapitel II.B 1.2) zu berücksichtigen.
Die Anwendung Kolab ist eine modulare Integration von verschiedenen Open Source
Anwendungen. Unter anderem handelt es sich um den Webserver Apache und verschiedene Mailserver. Hierdurch entstehen Bezüge zu den folgenden Kapiteln:

B Thema Webserver, Apache HTTP Server (Kapitel II.B 1.1)

D 1.2 Thema Netzwerkdienste (Kapitel II.D )
3.2
Authentisierungs- und Verzeichnisdienste

3.3
Häufig ist es von hohem Nutzen, die Verwaltung von Benutzern und Benutzergruppen sowie die Rechteverwaltung in Groupware mit vorhandenen Authentisierungs- und Verzeichnisdiensten zu koppeln. Hieraus entstehen Bezüge zum
Thema Authentisierungs- und Verzeichnisdienste, Kapitel II.C.
Backend-Integration
Es werden Groupwarelösungen gelegentlich über vorhandene Schnittstellen durch selbst
erstellte Programme oder Plugins erweitert, um die Funktionalitäten besonderen Anforderungen anzupassen. Hieraus entstehen Bezüge zu dem Thema Backend-Integration,
Kapitel III.D .
Seite 351
B Thema Teaming-/Workgroup Software
1
Teamingsoftware oder Kollaborationsplattformen, wie sie auch gerne bezeichnet
werden, stehen hoch im Kurs, sowohl bei den Softwareherstellern als auch bei den ITVerantwortlichen in den Organisationen. Macht es doch den Anschein, dass man mit
dem Kauf eines Softwarepaketes alle oder einen großen Teil seiner Sorgen los wird.
Denn man bekommt ja nicht nur ein einzelnes Produkt, sondern viele in einem. Meist
enthalten die angebotenen Systeme Content Management, eine Portallösung, ein
Dokumenten Management, Wissensmanagement, Suchmaschine und auch noch
Collaboration.
Dass dem nicht so ist, dürfte eigentlich jedem Leser klar sein. Warum sollte ein
Hersteller eins für fünf verkaufen, wenn er fünf verkaufen könnte. Bei den Kollaborationsplattformen geht es ist erster Linie um die Unterstützung der Zusammenarbeit in Teams,
sei es in internen oder übergreifenden Projekten oder innerhalb von Organisationseinheiten oder anderen Teamkonstellationen. Für diese Zusammenarbeit benötigt man
kein klassisches Content oder Web Content System und auch kein klassisches
Dokumenten Management System. Daher wird man mit einem Microsoft Office Share
Point Server oder einem Lotus Quickr oder einem Novell Teaming + Meeting nicht die
vollständige Funktionalität solch klassischer Systeme bekommen. Beispielhaft soll dies
an Dokumentenmanagementfunktionen (DMS) verdeutlicht werden. Klassische Funktionen eines DMS sind:

Visualisierung von Ordnungsstrukturen (Umsetzung von Aktenplänen)

Eingangskorb / Ausgangskorb

Gemeinsame Dokumentenbearbeitung (Check in / Check out)330

Versionierung

Metadatenverwaltung

Abbildung von Aktenlaufplänen
Was davon übrig bleibt in Kollaborationsplattformen sind in der Regel:

Gemeinsame Dokumentenbearbeitung (Check in / Check out)

Versionierung

Metadatenverwaltung
Dies scheint auch logisch zu sein, wenn man sich verdeutlicht, welche Aufgaben und
Aktivitäten bei der Zusammenarbeit in Teams unterstützt werden müssen. Die nachfolgende Auflistung erhebt dabei keinen Anspruch auf Vollständigkeit:
330
Über die Funktion „Check out― wird sichergestellt, dass nicht zur selben Zeit mehrere Personen ein und das gleiche Dokument bearbeiten. Über „Check in― wird ein Dokument wieder für die weitere gemeinsame Bearbeitung freigegeben.
Seite 352

Teams bilden

Teammitglieder Funktionen zuordnen

Aufgaben verteilen und deren Erfüllung überwachen

Zeitpläne definieren und überwachen

Ergebnisse entwerfen, bearbeiten, prüfen, freigeben, veröffentlichen und wiederfinden

Prozesse für die Erfüllung von Aufgaben und der Erarbeitung von Ergebnissen (Dokumenten, Daten und Informationen) definieren und umsetzen

Nachvollziehbarkeit sicherstellen

o
Versionierung/Archivierung
o
Protokollierung
o
Projekttagebuch führen
usw.
Gerade für die gemeinsame Arbeit an Dokumenten innerhalb eines Teams werden
Funktionen wie Check in und Check out benötigt, um sicherzustellen, dass es nicht zu
überschneidenden Bearbeitung und dadurch zu Informationsverlust kommt. Für die
Nachvollziehbarkeit der Arbeit benötigt man eine Versionierung und einfache Archivierung von alten Versionen sowie die Zuordnung und Verwaltung von Metadaten für die
Klassifizierung und das Wiederfinden von Dokumenten. In einem Team benötigt man in
der Regel aber keinen Eingangs- und Ausgangskorb und auch keine Aktenpläne.
Die Konsequenz aus dieser Erkenntnis sollte also sein: Wer ein klassisches DMS benötigt, sollte hierfür keine Kollaborationsplattform erwerben und einsetzen. Diese Erkenntnis gilt in gleichem Maße auch für die anderen Systeme. Eine Kollaborationsplattform
sollte eine Organisation für die Unterstützung der Zusammenarbeit in Teams beschaffen
und einsetzen.
Der zweite Punkt, der im Zusammenhang mit Teamingsoftware angesprochen werden
muss, ist die Empfehlung, den Einsatz einer solchen Software sehr gut vorzubereiten.
Dies beinhaltet auch die detaillierte Definition der Anforderungen und die genaue Prüfung im Rahmen der Beschaffung, dass diese Anforderungen erfüllt sind. Denn wie sich
in den nachfolgenden Betrachtungen gezeigt hat, lassen sich die Unterschiede nicht
immer so deutlich herausschälen, da sie sich am Detail festmachen.
Die Empfehlung der guten Vorbereitung muss ausgesprochen werden, da ansonsten die
getätigte Investition zur Fehlinvestion wird oder die Plattform im Chaos der Arbeitsbereiche versinkt.
Die Hersteller solcher Teaminglösungen versprechen durchweg schnelle und einfache
Lösungen für die Einrichtung eines Teamarbeitsbereiches. Mit zwei, drei Klicks hat man
alles, was man braucht, zusammengeklickt. Die Standardstrukturen sind dabei in fast
allen Lösungen ähnlich aufgebaut: ein Wiki, ein Blog, eine Bibliothek, ein Kalender und
fertig ist der Arbeitsbereich. Gegebenenfalls noch drei Standardworkflows dazu gepackt.
Seite 353
Schön ist, dass in ebenfalls fast allen Lösungen diese Standardstrukturen mehr oder
weniger einfach und mit Toolunterstützung, die zwar nochmal kostet, auch angepasst
und erweitert werden können. Diese Möglichkeiten sollten unbedingt genutzt werden und
umso besser dies vorbereitet und umso umfassender die Anpassungen im Vorfeld
durchgeführt werden, umso einfacher ist es später, die für die eigene Organisation passenden Arbeitsbereiche bereitzustellen. Hierzu gehört im Vorfeld unter anderem:

die benötigten Dokumententypen331, -formate und -standards festzulegen

die unterschiedlichen Strukturen der Arbeitsbereiche mit den benötigten
Funktionen zu definieren

die richtigen Attribute für Metadaten zu definieren

die benötigten Prozesse aufzunehmen und in eigene Standardworkflows zu
überführen
Ein weiterer wichtiger Punkt in diesem Zusammenhang ist es, dafür Sorge zu tragen,
dass im Nachgang bei der Nutzung der definierten Strukturen diese nicht mehr wahllos
zu ändern. Dies sollte nur bei Bedarf und durch dafür verantwortliche Mitglieder eines
Teams vorgenommen werden. Dazu müssen die Rollen klar verteilt und die Zugriffsrechte entsprechend gesetzt sein. Daher sollten auch die notwendigen Rechtestrukturen vorher überprüft und festgelegt werden. Individuelle Änderungen für einzelne Teambereiche
sind immer machbar.
Weiterhin sollten insbesondere die für die Arbeitsbereichsstrukturen verantwortlichen
Mitarbeiter aber auch die anderen Benutzer zuvor entsprechend gut geschult werden.
Abschließend soll an dieser Stelle noch eine Frage in den Raum gestellt werden, die von
den Lesern selbst beantwortet und vor allem bei der Vorbereitung und Beschaffung berücksichtigt werden muss. Die Arbeit von Teams ist in den meisten Fällen nicht auf
Dauer ausgelegt, daher stellt sich die Frage: Was soll nach der Auflösung eines Teams
mit den Inhalten des Arbeitsbereiches dieses Teams passieren?
1.1
Mindquarry
Die Teaming und Workgroupsoftware Mindquarry entstand 2006 auf studentische Initiative am Hasso Plattner Institut der Universität Potsdam. Deren Intention lag darin, ein
Werkzeug für Arbeitsgruppen anzufertigen, das die für Gruppenarbeit zeitintensive und
unpraktische Kommunikation allein per E-Mail ergänzt, ohne die Komplexität in der
Handhabung, Konfiguration und Wartung der meisten Lösungen aus diesem Bereich zu
kopieren. Das Ergebnis dieser Bemühungen ist eine einfach zu installierende Software,
die verschiedene Dienste für Gruppenarbeit in einer aufgeräumten Oberfläche zusammenfasst. Zu diesen Diensten gehören Werkzeuge für Filesharing, Nachrichten- und
Diskussionsdienste, Benutzerverwaltung und einfache Projektverwaltungsinstrumente.
Mindquarry entstand als freie Software unter der Mozilla Public License (MPL). Kostenpflichtige Supportangebote und das Hosting eines kostenpflichtigen Serverdienstes für
Arbeitsgruppen waren durch eine GmbH der Entwickler geplant, wurden aus Mangel an
331
Hier kann man zum Beispiel unterscheiden zwischen Dateien, Blogeinträgen, E-Mails usw.
Seite 354
Risikokapital Ende 2007 jedoch eingestellt. Die Entwicklung von Mindquarry wird seitdem als klassisches Open Source Projekt durch eine Community fortgesetzt.
1.1.1
Technologie/Architektur
Architektur
Mindquarry besteht hauptsächlich aus modular zusammengesetzten Serveranwendungen, die sämtliche Daten und Informationen zentral verwalten, ein Webinterface zur
Verfügung stellen und verschiedene Standardschnittstellen anbieten sowie aus einer
Clientanwendung und Plugins, mit deren Hilfe Arbeitsgruppen auf diese Daten zugreifen
und kommunizieren können.
Die Serversoftware wurde als klassische Middleware konzipiert. Sie greift auf eine Reihe
von vorhandenen Technologien (Bibliotheken) und Produkten zurück und verbindet
diese unter einer einfachen Benutzeroberfläche zu dem Gesamtprodukt. Die zentrale
Serveranwendung wurde in der plattformunabhängigen Programmiersprache Java
(Version 5, SDK) implementiert. Zusätzlich wurde bei der Programmierung auf eine
Reihe von frei verfügbaren Bibliotheken und Technologien zurückgegriffen: Das Toolkit
„Apache Jackrabbit" wurde für die Programmierung der integrierten Dokumentenverwaltung genutzt, „Apache Cocoon" wurde als Framework für die Entwicklung der
Webfunktionalitäten verwendet und das „Dojo Toolkit" für die Entwicklung der
Weboberfläche. SWT (Eclipse) wurde für die Programmierung der Clientprogramme
eingesetzt, mit deren Hilfe die Funktionen Dateimanagement und Taskmanagement
unterstützt werden.
Auf der Abbildung 42 sind alle Bestandteile einer vollständigen Installation dargestellt,
inklusive eines für Document-Management-Funktionalität benötigten Apache Webservers mit dem Erweiterungsmodul mod_perl.
Der Mindquarry Desktop Client kommuniziert mit der Serverapplikation über HTTP und
synchronisiert sich mit dem Collaboration Server über einfache PUT Requests (HTTP).
Zusätzlich werden lokal gespeicherte Dateien im Workspace des Dateisystems mit den
Inhalten der verteilten Dokumente auf dem Server über Subversion WebDAV Protokoll
aktualisiert. Zu diesem Zweck verwendet der Client die Subversion Client Library, die mit
dem mod_dav_svn Modul des Apache Webservers kommuniziert. Um also diese Funktion nutzen zu können, muss der Apache Webserver installiert werden. Wie sich dies in
die Gesamtarchitektur einfügt, wird nachfolgend beschrieben.
SSL und Document Management werden durch entsprechende Apache Module ermöglicht: mod_dav_svn für Subversion und mod_proxy für die Verschlüsselung. Für die interne Synchronisierung der Benutzerrechte von Subversion, für die WebDAV Funktion,
mit deren Hilfe ein Webbrowser wie ein Dateimanager auf Dateien zugreifen kann, und
der in Mindquarry realisierten Rechtevergabe wird auf das mod_perl Modul zurückgegriffen, welches die Skriptsprache Perl beinhaltet, in der diese Funktionen programmiert
worden sind.
Seite 355
Abbildung 42: Architektur Mindquarry
Die zentrale Webapplikation von Mindquarry wird als Java-Servlet durch das spring basierte Cocoon Framework unterstützt. Um Mindquarry laufen lassen zu können, wird ein
entsprechender Servlet-Container beziehungsweise Applicationserver benötigt. Dieser
muss kompatibel sein zur Java-Servlet-API 2.4 beziehungsweise diese unterstützen. In
der Windows-Variante wird bei der Installation der Jetty Servlet-Container mit installiert.
Für eine Linuxinstallation muss ein entsprechender Container, zum Beispiel Tomcat,
separat installiert werden. Laut den Entwicklern von Mindquarry ist es sinnvoll dieser
Architektur noch den Apache Webserver davor zu setzen, sodass die die Zugriffe auf
Mindquarry über den Webserver erfolgen, dies hat den Vorteil, dass sowohl die Funktion
der Dateisynchronisation (siehe weiter oben) mit den Clients als auch alle anderen FunkSeite 356
tionen des Webservers genutzt werden können, Mindquarry mit den nativen Clients und
Webbrowsern über HTTP sowie über das Apache JServ Protocol.(AJP).
Die verschiedenen Bestandteile der Webapplikation sind innerhalb des Cocoon Frameworks in sitemaps servlets aufgeteilt. Diese sind jeweils über URLs durch HTTPRequests ansteuerbar und verhalten sich wie selbstständige kleine Webapplikationen.
Der HTTP-Response dieser Sitemaps enthält entweder HTML, inklusive Javascript,
Bilddaten und CSS, oder in XML verpackte Informationen für Mindquarry-Clients oder
RSS-Feeds.
Die Funktionalität zur Volltextsuche wurde mit Apache Solr implementiert, einem Open
Source Search Server, welcher auf der Lucene Java Search Library basiert. Mindquarry
sendet alle in Mindquarry anfallenden Informationen an Solr, das aus diesen Daten
einen jederzeit aktuellen Lucene Index bereitstellt. Suchanfragen von Benutzern über
das Webinterface werden direkt an das Solr Servlet weitergeleitet. Die Volltextsuche
erstreckt sich über die Inhalte des Wikis und alle Tasks. Zusätzlich wird das Repository
indiziert und kann durchsucht werden. Es werden dabei alle herkömmlichen offenen und
proprietären Formate berücksichtigt, inklusive PDF, Microsoft Powerpoint und Microsoft
Word.
Die Speicherung sämtlicher Benutzerdaten und Dokumente geschieht durch Programmteile, die auf Apache Jackrabbit zurückgreifen, einer vollständigen Implementation eines
Content Repositorys als Java API (JCR). Diese fungiert in Mindquarry als Datenbank,
die Daten in einer Baumstruktur hierarchisch ablegt. Dieses Java Content Repository ist
ein relationales DBMS und wird in Mindquarry als Backend für die Datenspeicherung
verwendet. Mindquarry erweiterte die JCR Library durch einen Suchalgorithmus, der
XPath-konforme Anfragen (XML Path Language) vollständig bedienen kann.
Für die Versionierung und Revision von Dokumentenänderungen greift Mindquarry auf
Subversion zurück, einer Open Source Lösung für derartige Aufgaben, die ein versioniertes Filesystem abbildet. Subversion überprüft Änderungen an Datenbeständen auf
Clientbasis und funktioniert entsprechend auch offline durch zeitlich verschobene Synchronisation. Bei Verwendung des Webinterfaces kommuniziert Mindquarry selbst über
Subversion Clients mit den Revisionsdaten von Subversion, während die Synchronisierung lokaler Arbeitsplätze durch Mindquarry Clients über das Apache mod_dav_svn Modul erfolgt.
Es ist geplant, Mindquarry zu einem vollwertigen Collaborationserver zu erweitern, indem der Apache James Mail Server als eigenständiger MTU integriert wird, sodass
Maildienste (Mailinglisten usw.) in den Mindquarry Funktionen (Subversion, Volltextsuche, usw.) integriert werden können.
Für eine Installation des Mindquarry Servers müssen zusätzlich eine Java SDK ab
Version 5 und ein Apache 2 mit mod_perl sowie Subversion installiert sein. Alle anderen
Bestandteile werden mit dem Mindquarry-Softwarepaket geliefert. Für Installationen
unter Windows ist ein Installationspaket (XAMPP) verfügbar, das alle Voraussetzungen
für Mindquarry beinhaltet.
Als Hardwarevoraussetzung werden lediglich 256 MB RAM und 100 MB freier Speicher
für die reine Software, exklusive anfallender Daten auf einer Festplatte genannt.
Seite 357
1.1.1.1
Protokolle und Schnittstellen
Sämtliche Programmierschnittstellen (API) und Protokolle, die in Mindquarry Verwendung finden, sind vollständig offengelegt und dokumentiert. Die Kommunikation zwischen einzelnen Bestandteilen und zwischen Clients und Servern geschieht vorwiegend
per HTTP, über das XML und HTML Daten versendet werden.
Als Protokoll zwischen Apache Webserver und Cocoon Servlet wird AJP verwendet. Per
JCR wird Apache Jackrabbit adressiert und die Anbindung der relationalen Datenbank
geschieht über JDBC. Der Lucene Index für alle relevanten Information Retrieval Funktionen wird über die JSON API angesprochen. Der geplante MTU kommuniziert standardgemäß per SMTP und kann durch Mailclients über Pop3 und IMAP abgefragt werden.
Die Verwendung von Mindquarry kann problemlos über dessen Webinterface stattfinden.
Dazu werden lediglich herkömmliche Webbrowser benötigt. Zusätzlich existieren Clientprogramme zu Mindquarry, die lokal installiert werden können. Mit Hilfe dieser Clients
können definierte Bereiche auf der lokalen Festplatte automatisch mit den Daten auf
dem zentralen Server synchronisiert werden. Derartige Clients existieren sowohl für MS
Windows als auch für Linux und Mac OS. Aufgrund ihrer Implementierung als JavaAnwendungen ist eine Portierung zu weiteren Plattformen problemlos möglich.
Mindquarry bietet die Möglichkeit, Benutzer über einen RSS Feed über aktuelle Änderungen und Meldungen auf dem Laufenden zu sein. Entsprechende RSS Feed Reader
gibt es in großer Anzahl ebenfalls als Open Source Lösung, und sie sind in den meisten
aktuellen Webbrowsern integriert.
Die Architektur kann daher in jeder Hinsicht als modular und offen angesehen werden,
sodass deren Erweiterung und Anpassung über die genannten Schnittstellen potentiell
kein Problem darstellt.
1.1.1.2
Sicherheitsaspekte
Sämtliche Zugriff auf den Mindquarry Server können per SSL, optional durch Verwendung des mod_proxy Moduls im Apache Webserver verschlüsselt werden.
Innerhalb des Mindquarry Interfaces können Benutzerrechte definiert werden, sodass die
Zugriffe und Funktionen für Benutzergruppen und einzelne Benutzer nach Bedarf definiert werden können.
Der Server an sich bietet keine besonderen Sicherheitsmechanismen. Die Daten liegen
unverschlüsselt auf dem Server und Zugriffe auf Repositories, Indizes usw. können über
die wohlbekannten Schnittstellen aufgrund der modularen Architektur stattfinden. Daher
sollten beim Aufbau einer solchen Architektur die folgenden Dokumente des Bundesamtes für Sicherheit in der Informationstechnik zu Rate gezogen werden:

„Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers―,
Bundesamt für Sicherheit in der Informationstechnik, Bonn 2006,
http://www.bsi.de/literat/studien/tomcat/index.htm

„Web 2.0 – Sicherheitsaspekte neuer Anwendungen und Nutzungsformen des
Mediums World Wide Web und ihrer Implementierung―,
Seite 358
Bundesamt für Sicherheit in der Informationstechnik, Bonn 2007,
http://www.bsi.bund.de/literat/studien/web20/index.htm

Baustein 5.11 Apache-Webserver der IT-Grundschutzkataloge,
http://www.bsi.bund.de/gshb/deutsch/baust/b05011.htm
Die Verwendung innerhalb geschlossener LANs ist ohne großen Aufwand möglich, jedoch der gesicherte Zugriff aus dem Internet sollte aus den genannten Gründen nur über
Firewalls und Proxies stattfinden, um neben dem prinzipiellen Sicherheitsgewinn einer
solchen Lösung auch eine empfehlenswerte Verschlüsselung über SSL gewährleisten zu
können. Organisationsübergreifende Zusammenarbeit ist über verschlüsselten Zugriff
möglich und kann aufgrund der verwendeten Standardprotokolle für die Webanwendung
und die Desktopclients eingesetzt werden. Eine höhere Sicherheit bei der Zusammenarbeit über verschiedene LANs hinweg kann über VPNs oder allgemein verschlüsselte
Netzwerkverbindungen (z.B. Stunnel) realisiert werden, die ebenfalls über die gesamte
Anwendung hinweg transparent einsetzbar sind.
Aus Sicht der IT-Sicherheit sollte auch noch mal darauf hingewiesen werden, dass im
Rahmen der Volltextsuche das Dokumentenrepository indiziert wird, wobei alle herkömmlichen offenen und proprietären Formate berücksichtigt werden, inklusive PDF,
Microsoft Powerpoint und Microsoft Word.
1.1.2
Funktionalitäten
Das Ziel der Programmierer von Mindquarry war es, ein einfach zu benutzendes Werkzeug zu erstellen, das Arbeitsgruppen hilft, sich zu koordinieren, Arbeitsergebnisse auszutauschen, diese zu verwalten und zu überprüfen. Zu diesem Zweck wurden einige
modulare Funktionen erstellt, die gemeinsam die Teamingsoftware Mindquarry bilden.
Eine Arbeitsgruppe wird in Mindquarry als Team bezeichnet. Teams bestehen aus
Gruppen von einzelnen Usern und können von Benutzern mit entsprechenden Rechten
zusammengestellt werden. Teams und User sind umfangreich definierbar. Innerhalb der
Teamübersichten können Aktivitäten und Aufgaben personenbezogen angezeigt werden. Es können für ein Projekt auch verschiedene Teams zusammengestellt und verwaltet werden. Innerhalb eines Teams haben alle Benutzer gleichberechtigte Zugriffsrechte.
Eine Rechteverwaltung auf Benutzerebene ist in Planung.
Mindquarry beinhaltet eine Aufgabenverwaltung. Gruppen und einzelnen Teammitgliedern können Aufgaben zugewiesen werden, die Eigenschaften wie Status (new, runnning, done, usw.) oder Priorität (high, low, usw.) besitzen. In einer Aufgabenübersicht
können Aufgaben nach verschiedenen Kriterien sortiert werden und als iCal oder PDF
exportiert werden. Es können mehrere Teammitglieder einer Aufgabe zugeordnet werden. Aufgaben können untereinander verknüpft werden, sodass auch komplexe Projektplanung möglich ist. Erledigte Aufgaben werden in einem Archiv zur späteren Sichtung
abgelegt. Diverse Ansichten können über den Fortschritt eines gesamten Projektes Auskunft geben, indem zum Beispiel alle laufenden oder noch nicht zugewiesenen Aufgaben
aufgelistet werden. Aufgabenänderungen werden versioniert und können entsprechend
abgefragt werden. Der Fortschritt und Änderungen werden allen Projektmitgliedern über
RSS/Atom Feeds mitgeteilt.
Seite 359
Als offenes Forum für Teams dient ein Wiki. Benutzer können Rich-Text Einträge vornehmen und verändern sowie Grafiken und Tabellen einfügen, die von allen Projektmitgliedern gelesen und wiederum verändert werden können. Über verschiedene Filteransichten können Veränderungen und Teams zugewiesene Wikis verfolgt werden. Einträge
und Änderungen im Wiki werden protokolliert und den Projektmitgliedern über RSS/Atom
Feeds in Echtzeit mitgeteilt. Eine Exportfunktion ermöglicht die Ausgabe des Inhalts als
OPML (Open Processor Markup Language) Datei.
Für den Austausch und die gemeinsame Nutzung von Dateien existiert ein zentraler Dateiserver, der über das Webfrontend und die Desktop Clientanwendungen synchronisiert
wird. Die Art und das Format von Dateien (Textdaten, Bilddaten, Officedateien, usw.)
haben keinen Einfluss auf die Funktionen des Servers. Dateien werden automatisch bei
einer Synchronisierung auf die neueste Version aktualisiert und dafür zu löschende Dateien werden mit Versionsinformationen archiviert. Zu den Versionsinformationen gehören Zeitstempel der Änderung, Benutzerangaben und automatische Versionsnummern.
Informationen über aktuelle Änderungen werden ebenfalls per RSS/Atom Feeds veröffentlicht. Verschiedene Ansichten können über Webbrowser dargestellt werden und
funktionieren über aktuelle Webbrowser auch als WebDAV Anwendung.
Insgesamt werden sämtliche Änderungen innerhalb der verschiedenen Funktionalitäten
von Mindquarry protokolliert und archiviert. Mindquarry verfügt derzeit nicht über eine
klassische Kalenderfunktion, aber über eine Zeitleistendarstellung können sämtliche
Änderungen terminlich nachvollzogen werden. Über einen RSS Feed können Angaben
zu diesen Änderungen durch die Arbeitsgruppen zeitnah verfolgt werden.
Durch den Aufbau der verwendeten Technologien ist eine Offline-Verwendung und nachträgliche Synchronisation von Dateien problemlos möglich.
Der Umfang der Funktionalitäten bleibt durch den Ansatz der einfachen Benutzbarkeit
hinter den Möglichkeiten vergleichbarer Anwendungen zurück, insbesondere was die
Verwendung von Workflow und Dokumenten Management Funktionen betrifft. Mindquarry deckt aber die häufigsten Anwendungsanforderungen für kleinere bis mittlere Projekte
effizient ab, ohne die Notwendigkeit, Benutzer in komplexe Bedienkonzepte einführen zu
müssen.
Hauptfunktion
Details
Benutzerverwaltung
Benutzer und Teams umfangreich definierbar. Das Rechtesystem kennt in der aktuellen Implementierung lediglich
Rechte auf Teamebene.
Dateiverwaltung mit Versionierung und Metadaten
Dokumente werden über Clients synchronisiert.
Automatische Archivierung mit Metainformationen.
Versionierung über Zeitstempel und Bearbeiterinfo.
Termin- und Aufgabenplanung
Aufgaben mit grundlegenden Metainformationen (Status,
Bearbeiter, Priorität und Termine) können festgelegt, untereinander verknüpft und verfolgt werden.
Besonderheiten
Projektbezogene Wiki-Funktion für unkomplizierte Diskussionen
Seite 360
Hauptfunktion
Details
Aktuelle Projektinformationen über RSS /Atom Feeds
Suchfunktion
Die Suche über ein gesamtes Projekt wird über das Webinterface bereitgestellt. Es handelt sich hierbei um eine
Volltextsuche über die Bereiche Wiki, Aufgabenplanung
und über das zentrale Repository mit Dateien.
Tabelle 55: Funktionen von Mindquarry
1.1.3
Fazit
Mindquarry verbindet einige Open Source Produkte zu einer Teamingsoftware, die vor
allem durch praktische Funktionen und einfache Handhabung positive Akzente setzen
kann. Es bietet sich für einfache Projektorganisation in kleinen und mittleren Arbeitsgruppen an. Durch die einfache Installation und Bedienbarkeit im Zusammenhang mit
der freien Lizenz bietet sich Mindquarry auch als ad-hoc Lösung ohne besondere Vorkenntnisse und Voraussetzungen an.
Sämtliche gespeicherte Daten liegen sowohl im Originalformat und als XML kodierte
Informationen vor und können somit auch manuell oder über andere Programme (ohne
Mindquarry) genutzt werden. Dies ist ebenfalls von Vorteil mit Blick auf mögliche zukünftige Migrationen, insbesondere, wenn es um ablösende Migrationen und die Übernahme
der Daten in neue Umgebungen geht. Durch den Einsatz von offenen Protokollen und
Programmierschnittstellen ist es zudem möglich, die Funktionalität von Mindquarry an
besondere Behördenbedürfnisse, für DMS oder andere spezielle Gegebenheiten zu erweitern.
Nachteilig ist, dass Mindquarry keine besonderen Schutzmechanismen gegen unberechtigte Zugriffe und ein sehr grobes Autorisierungsmodell bietet. Aus diesem Grund ist eine
besondere organisatorische und administrative Sorgfalt bei der Serverinstallation und
-benutzung notwendig. Hilfreich sind hier die Hinweise des Bundesamt für Sicherheit in
der Informationstechnik zur „Sicherheit im Internet―332 und zu Web 2.0333.
Lobenswert zu erwähnen ist, dass die volle Funktionalität auch ohne eine Freigabe von
aktiven Inhalten genutzt werden kann.
1.2
Microsoft SharePoint Server und –Services
Microsoft bietet unter der Bezeichnung SharePoint schon seit 2001 verschiedene Produkte an, die durch stetige Konsolidierung zum aktuellen Produkt überführt wurden 334.
Die nachfolgende Tabelle zeigt die Entwicklung seit der erstmaligen Veröffentlichung von
SharePoint Produkten im Jahre 2001.
332
333
334
http://www.bsi.de/fachthem/sinet/allgemeines/sinetstd.htm
http://www.bsi.de/literat/studien/web20/index.htm
SharePoint Historie http://www.it-innovations.de/is/sharepoint+competencecenter/office+sharepoint+server+2007.htm
Seite 361
Jahr
Entwicklung/Veröffentlichung
Services-Linie
Server-Linie
2001
SharePoint Team Services v1
SharePoint Portal Server 2001
2003
Windows SharePoint Services v2
Office SharePoint Portal Server 2003
2006
Windows SharePoint Services v3
Microsoft Office SharePoint Server
2007335
Tabelle 56: SharePoint-Historie
Microsoft bietet aktuell unter der Bezeichnung SharePoint die Produkte Windows SharePoint Services 3.0 und den Microsoft Office SharePoint Server 2007 an.
Die Windows SharePoint Services (WSS) in der Version 3.0 sind Bestandteil des Windows Server 2003 Betriebssystems und müssen nicht zusätzlich lizenziert und vergütet
werden336. Hiermit bietet Microsoft eine Sammlung von Werkzeugen und Funktionen zur
Unterstützung der Zusammenarbeit (Kollaboration) verteilter Teams sowie den Einsatz
von individuell programmierten Workflows an. Die WSS eignen sich dabei vor allem für
kleine Gruppen bis hin zu kleinen Unternehmen.
Den Kern dieser Funktionalitäten der WSS sind anpassbare Listen. Dies sind z.B. Aufgabenlisten im Team, Kalender, Dokumentenbibliotheken (Dateiablage mit erweiterten
Eigenschaften), Adresslisten. Weitere Listen können selbst als sogenannte benutzerdefinierte Listen erstellt werden oder aus Drittsystemen eingebunden werden337.
Für Unternehmen mit weitergehenden Anforderungen, die durch die WSS nicht erfüllt
werden, stehen weitere Ausbaustufen zur Verfügung, die unter der Bezeichnung Microsoft Office SharePoint Server 2007 (MOSS 2007) bekannt sind.
Der MOSS 2007 wird in folgenden Editionen angeboten:

MOSS 2007, Standard Edition (MOSS SE)

MOSS 2007, Enterprise Edition (MOSS EE)

MOSS 2007 for Search, Standard Edition

MOSS 2007 for Search, Enterprise Edition
Da die WSS die Basis für den MOSS 2007 bilden, sind alle Funktionen des WSS bereits
integraler Bestandteil des MOSS 2007.
335
336
337
Microsoft Office SharePoint Server 2007 entsteht aus der Zusammenführung und
Weiterentwicklung des Office SharePoint Portal Server 2003 und dem Content
Management Server 2002.
WSS setzt mindestens Windows Server 2003 mit den zugehörigen Client Access License
(CAL) voraus.
Microsoft Windows SharePoint Services
http://de.wikipedia.org/wiki/Windows_SharePoint_Services
Seite 362
WSS
MOSS
Abbildung 43: Beziehung zwischen MSS 3.0 und MOSS 2007
Die MOSS 2007 Standard Edition unterscheidet sich im Wesentlichen zur Enterprise
Edition dadurch, dass ihr die Forms Services, Excel Services und der Business Data
Catalog (BDC) fehlen, der die Integration von externen Daten in den SharePoint ermöglicht.
Die MOSS 2007 for Search Editionen sind für Firmen gedacht, die vorwiegend eine Enterprise Suche einsetzen wollen und nicht ein Kollaborations-Portal, daher werden diese
Editionen im Weiteren nicht betrachtet.
1.2.1
Technologie / Architektur
Die unabdingbaren Voraussetzungen für eine MOSS-Installation sind die nachfolgend
aufgeführten anderen Microsoft Produkte:

Windows Server 2003 (2008) als Betriebssystem

Internet Information Services (IIS) als Web Server

.NET Framework 2.0 für den SharePoint und .NET 3.0 für die Windows Workflow
Foundation [WF]

SQL Server 2005 (2008) als SharePoint Repository
Eine detaillierte Darstellung der vollständigen Systemanforderungen liefert Microsoft auf
seinen Webseiten338.
1.2.1.1
Architektur
Die nachfolgende Abbildung verdeutlicht die logische SharePoint-Architektur. Dabei liefern auf der Infrastrukturebene die Datenbank-, Such und Workflowdienste zusammen
mit dem ASP.NET Framework die Grundlage für alle weiteren Dienste. In der Regel gehören hier dann auch das Betriebssystem selbst und Active Directory dazu. Aus der Abbildung wird dann auch deutlich, dass MOSS 2007 auf den WSS 3.0 aufsetzt.
338
http://office.microsoft.com/de-de/help/HA101945391031.aspx
Seite 363
APPLIKATIONEN & DIENSTE (MOSS 2007)
Kollaboration
Portal
Content
Management
Suche
Business
Intelligence
Workflows
Shared Services
(Site Model, Indexierung/Suche, Geschäftsdatenkatalog, Profil Dienste, Zielgruppen gerechte Ansprache,
Nutzungsanalysen, Single Sign-on Service)
PLATFORM DIENSTE (WSS V3)
Archivierung
Sicherheit
Management
Entwicklung
Site Model
Erweiterbarkeit
OPERATING SYSTEM DIENSTE
ASP.Net: Web Parts, Personalisierung, Master Seiten, Anbieter Framework (Sicherheit, etc.)
Datenbanken Dienste
Such Dienste
Windows Worklfow Foundation
Abbildung 44: logische Architektur – SharePoint
Server-Topologien
MOSS 2007 unterstützt verschiedene Architekturmodelle bezüglich der ServerTopologie, abhängig von der Größe der Instanz und deren Durchsatz und den Anforderungen an die Ausfallsicherheit. Der Standard für SharePoint Instanzen heißt Farm, diese gibt es als sogenannte „Small―, „Medium― und „Large― Farm. Ein „single― Server wird
nur zu Entwicklungs- oder Testzwecken installiert, da ein weiterer Ausbau nur bedingt
machbar ist.
Die nachfolgende Abbildung zeigt die verschiedenen Varianten, die Microsoft als BasisTopologien vorsieht.
Small Farm
Medium Farm
Jeder
(load-balanced)
Server
beinhaltet
- Web front end
- Anwendungen
Dedizierter
SQL Server
Large Farm
Server mit
- Web front
ends
- Anwendungen
Web front end
Server
(load balanced)
Anwendungsserver
Anwendungsserver
SQL Server
Cluster
Index
Suche
Excel
SQL Server
Cluster
Abbildung 45: Topologien von Sharepoint Server Farmen
Seite 364
Project
1.2.1.2
Clients
Der Zugriff auf SharePoint Umgebungen kann je nach Bedarf mittels unterschiedlicher
Clients, Protokolle und Schnittstellen vorgenommen werden.
Zu den verfügbaren Clients gehören vor allem alle Anwendungen aus der MS Office
2007 Suite. Hierzu gehören u.a.:

Microsoft Office 2007 (Word, Excel, PowerPoint, Access, Outlook, InfoPath,
OneNote)

Project 2007

Visio 2007

Publisher 2007

Office Communicator 2007 (Client für Office Communications Server 2007
[OCS])
Hier können generell auch andere, nicht Microsoft Anwendungen, wie zum Beispiel
OpenOffice.org, verwendet werden. Bei diesen Anwendungen ist aber in der Regel der
Grad der Integration nicht in dem Maße gegeben wie er für die Microsoft Produkte verfügbar ist. So steht in OpenOffice.org (OOo) zum Beispiel keine Workflowintegration zur
Verfügung, das bedeutet, es gibt keinen Menüpunkt oder Button in OOo über welchen
ein Workflow ausgewählt und gestartet werden kann. Die Funktion der gemeinsamen
Dokumentenbearbeitung steht aber auch bei Verwendung anderer Anwendungen zur
Verfügung, da beim Öffnen eines Dokumentes automatisch die Funktion „Check out―
angewendet wird. Das ―einchecken‖ geht dann über das erneute Hochladen des geänderten Dokumentes.
Weitere Microsoft Clients, die verwendet werden können, sind zum Beispiel:

SharePoint Designer 2007

Internet Explorer 7 oder andere Web-Browser

Alle WebDAV339-fähigen Clients, sofern WebDAV entsprechend eingerichtet
wurde
Anmerkung:
Bezüglich der Browserunterstützung unterscheidet Microsoft zwischen zwei Ebenen (Level 1 und 2). Zu den Level 1 Browsern gehören gemäß Microsoft die Browser, welche
die Vorteile der erweiterten Funktionen von ActiveX-Steuerelementen nutzen und unterstützen. Sie eröffnen die volle Funktionalität von SharePoint Umgebungen einschließlich
der Administrationsumgebung. Level 2 Browser bieten laut Microsoft grundlegende
Funktionalität, sodass die Benutzer Lese- und Schreibzugriff auf SharePoint Umgebungen und Administrationsumgebung durchführen können. Dies und Näheres zu den un-
339
Web-based Distributed Authoring and Versioning
Seite 365
terstützten Funktionen von verschiedenen Browsern erfährt man im Dokument „Microsoft
Office SharePoint Server 2007 - Getting Started with Office SharePoint Server―340.
Schnittstellen und Protokolle für den direkten Zugriff
Als Schnittstellen und Protokolle für den direkten Zugriff stehen zur Verfügung:

HTTP oder HTTPS

FTP, sofern dies im Server eingerichtet beziehungsweise erlaubt wird

WebDAV, die SharePoint Bereiche können dabei z.B. durch eintragen der entsprechenden URL im Windows Explorer geöffnet werden oder in den Verzeichnisbaum wie ein lokales Verzeichnis eingebunden werden.
Schnittstellen und Protokolle für die Anbindung anderer Systeme
Für die Anbindung anderer Systeme stehen folgende Schnittstellen zur Verfügung:

SharePoint API über Visual Studio mit den Entwicklungserweiterungen für
SharePoint

Web Services (SharePoint Web Services, die mit den Erweiterung von Visual
Studio für SharePoint zur Verfügung gestellt werden, aber auch selbst programmierte Web Services)

WebDAV zur Anbindung von WebDAV-fähigen Clients, wie z.B. MS Word oder
der Windows Explorer
Bezüglich der Web Service Schnittstelle ist anzumerken, dass auf Seiten SharePoint
diese Web Services auf .NET basieren müssen. Auf der anderen Seite können beliebige
Technologien (J2EE, .NET) verwendet werden.
Dateiformate
Grundsätzlich können alle Dateiformate in einer SharePoint Umgebung verwendet
werden, die auch sonst unter Windows verwendet werden können. Dateien beliebiger
Formate können entweder über die Web-basierte Benutzerschnittstelle in die SharePoint
Umgebung hochgeladen werden oder über eingebundene WebDAV-Ordner mit Hilfe
eines Dateimanagers übertragen werden. Die Zuordnung zu Anwendungen, mit denen
man die Dateien betrachten und bearbeiten kann, erfolgt über die entsprechenden
MIME-Typen. Unterschiede bestehen im Wesentlichen bezüglich des Grades der
Integration und gegebenenfalls auch bezüglich der Nutzbarkeit von damit verbundenen
Funktionen.
1.2.1.3
Sicherheitsaspekte
Zur Gewährleistung der IT-Sicherheit für eine SharePoint Umgebung werden unterschiedliche Maßnahmen und Möglichkeiten von Microsoft zur Verfügung gestellt, die je
nach Ausprägung und Nutzung (z.B. nur im Intranet oder auch über das Internet) von
SharePoint und den damit verbundenen unterschiedlichen Sicherheitsanforderungen
genutzt werden können. Im Rahmen des Migrationsleitfadens ist es nicht möglich und es
340
Microsoft Corporation, Published: May 2007, Author: Windows SharePoint Services IT User
Assistance (o12ITdx@microsoft.com) (siehe http://go.microsoft.com/fwlink/?LinkID=91741)
Seite 366
ist auch nicht die Aufgabe des Leitfadens diese alle im Detail zu betrachten. Eine umfangreiche Darstellung liefert Microsoft auf den TechNet-Seiten des folgenden Links:
http://technet.microsoft.com/en-us/library/cc263518.aspx
Hier gibt es auch ein ca. 300 seitiges Werk zum herunterladen, das viele Aspekte beschreibt.
Die wesentlichen Sicherheitsmaßnahmen lassen sich in drei Gruppen einteilen:

Autorisierungsmodelle

Authentisierungsmöglichkeiten

Verschlüsselung und Netzwerktopologie
Überdies hinaus gibt es zusätzliche Möglichkeiten, deren Bedarf im Einzelfall geprüft
werden muss. Die folgenden Darstellungen zeigen nur einen Ausschnitt.
Autorisierungsmodelle
Hierzu besteht entsprechend der Inhaltsstrukturen und Benutzerstrukturen einer SharePoint Umgebung die Möglichkeit unterschiedliche Zugriffsberechtigungen zu vergeben.
Das bedeutet, dass für jedes Inhaltsstrukturelement (Site, Liste, Bibliothek, Ordner, Dokument usw. (siehe auch Abschnitt III.B 1.2.2.1)) und für jeden Benutzer und jede Benutzergruppe detaillierte Zugriffsberechtigungen vergeben werden können. Die Berechtigungen vererben sich dabei von oben nach unten, zum Beispiel erben die Inhalte einer
Site die Berechtigung zu dieser, wenn neue Inhalte angelegt werden. Diese können
dann individuell wieder angepasst werden, sofern dies sinnvoll ist.
Benutzergruppen sind Autorisierungsgruppen und werden dazu verwendet, um Benutzer
unterschiedlichen Umfang an Zugriffsberechtigungen zuzuweisen. Die folgende Tabelle
zeigt einige Beispiel für Autorisierungsgruppen:
Gruppen
Standard-Autorisierung
Restricted Readers
Nur Leserecht auf eine Site und eingeschränkte
Zugriffsrechte auf spezifische Listen
Home Visitors
Leserecht
Home Members
Beiträge erstellen
Approvers
Freigaben und eingeschränkten Zugriff
Home Owners
Vollen Zugriff
Site collection administrators
Administration einer Site Collection
(siehe Abschnitt III.B 1.2.2.1)
Farm administrators
Legen fest, welche Administratoren welche Server und
Server Framen administrieren dürfen
Administrators
Server- und Farmadministrationsrechte
Tabelle 57: Beispiele für Autorisierungsgruppen in SharePoint
Seite 367
Darüber hinaus besteht die Möglichkeit selbst weitere Gruppen zu definieren, zum Beispiel für externe Benutzer.
Authentisierung / Benutzerverwaltung
MOSS bietet die Möglichkeit vorhandene Benutzerverzeichnisse, wie zum Beispiel Active Directory (AD), aber auch andere Standard LDAP-Verzeichnisse, wie z.B. Novell eDirectory341 oder OpenLDAP für die Benutzerverwaltung zu integrieren. Alternativ oder
parallel können Benutzer auch direkt auf einem SharePoint Server verwaltet werden.
Dies kann von Interesse sein, wenn es darum geht, externe Benutzer in einem Team zu
integrieren, ohne diese in der internen zentralen Benutzerverwaltung führen zu müssen.
Dementsprechend bietet SharePoint außer der Authentisierung via Active Directory (AD)
oder direkt am SharePoint Server auch die Möglichkeit der Authentisierung gegenüber
einem anderen integrierten LDAP-Verzeichnis.
Weiterhin besteht auch die Möglichkeit sogenannte Authentication Provider, basierend
auf dem „ASP.NET Authentication Providermodel―342 zu integrieren.
Die gängigsten Provider im SharePoint Umfeld sind

SQL membership provider

AD membership provider

LDAP membership provider

Web Single Sign On (SSO) mit den Active Directory Federation Services (AD FS)
Über das .Net Framework lassen sich für weitere Anwendungen und Dienste dem Provider Modell entsprechend programmieren.
MOSS 2007 unterstützt auch die Authentisierung mittels Kerberos, sofern die Authentisierung gegenüber AD erfolgt.
Die Nutzung dieser unterschiedlichen Möglichkeiten bringt für den Anwender, der sich
korrekt authentisiert hat, keine funktionalen Einschränkungen innerhalb der SharePoint
Umgebung, sofern diese nicht aufgrund der gesetzten Zugriffsrechte beabsichtigt sind.
Allerdings bieten die verschiedenen Authentisierungsmethoden für die Authentisierung
selbst unterschiedliche Funktionalitäten. So stehen zum Beispiel bei Nutzung eines
OpenLDAP-Verzeichnisses nicht die Funktionalitäten eines Active Directory zur Verfügung. Welches Verfahren unter welchen Voraussetzungen das am besten geeignete ist,
muss jede Organisation für sich entscheiden343. Bei der Entscheidung sollte sicherlich
auch noch der folgende Abschnitt berücksichtigt werden.
Verschlüsselung und Netzwerktopologie
Mit Blick auf die Authentisierungsmethoden ist es möglich eine SharePoint Umgebung
über die Netz- und Farmtopologie in verschiedene Sicherheitszonen (z.B. Intranet, Inter-
341
342
343
http://www.setfocus.com/technicalarticles/nickkellett/MOSS2007-and-Novell-LDAPAuthentication_pg1.aspx
http://msdn2.microsoft.com/en-us/library/aa479030.aspx
Microsoft bietet auf den Webseiten zu folgendem Link Hilfestellungen an:
http://technet.microsoft.com/en-us/library/cc263434.aspx
Seite 368
netauftritt, Partner Web) aufzuteilen und für die verschiedenen Zonen z.B. unterschiedliche Authentisierungsmethoden mit unterschiedlichem Grad an Sicherheit zu verwenden.
Die Idee dabei ist auch, Inhalte entsprechend in den unterschiedlichen Zonen mit unterschiedlichen Zugriffsrechten bereitzustellen. Weiterhin kann für jede Zone auch ein unterschiedlicher Umfang an Funktionalität zur Verfügung gestellt werden (z.B. für die Zone
Internetauftritt nur eine eingeschränkte Suchfunktion).
Zur Verschlüsselung der Datenübertragung zwischen den SharePoint Servern, den Servern und den Client-Geräten können IPSec und SSL verwendet werden.
Sonstiges
Problematisch ist, dass die volle Funktionalität nur genutzt werden kann, wenn aktive
Inhalte zugelassen werden. Dies ist aus Sicht der IT-Sicherheit bedenklich. Hier sollten
in jedem Fall die Hinweise des Bundesamt für Sicherheit in der Informationstechnik zur
„Sicherheit im Internet―344, zum Umgang mit aktiven Inhalten345 und zu Web 2.0346 berücksichtigt werden.
1.2.2
Funktionalitäten
Den Funktionsumfang, den die Microsoft SharePoint Technologie bietet, wird von Microsoft347 im Allgemeinen wie folgt dargestellt (siehe Abbildung 46):
Abbildung 46: Funktionalität von MOSS 2007
344
345
346
347
http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/index.htm
7TN25 Tech@Night Office 2007 und Office SharePoint Server 2007 Zusammenarbeit
leicht gemacht http://live.sharepointcommunity.de/wiki/Wiki-Seiten/7TN25.aspx
Seite 369
Die oben genannten Funktionen werden durch die verschiedenen SharePoint Editionen
zum Teil oder komplett unterstützt. Die nachfolgende Abbildung stellt im Überblick dar,
welche Funktionen durch welche Edition zur Verfügung gestellt werden. 348
Search
• Business
Data
Catalog
Office SharePoint
Server Enterprise CAL
Datenintegration
•Business
Data
Catalog
•Webpart
Integration
Workflow
Office SharePoint
Server CAL
Projektmgmt
•Issue
Tracking
•Projekt
Arbeitsbereiche
Team
Zusammenarbeit
•Arbeitsbereiche
und Tools
•Blogs
Dokument &
Web Content
Management
•5 Workflows
mitgeliefert
•Reporting
für ECM
•Policy
•Verwaltung
•Auditing
•Records
Management
•Web CM
•Windows
Workflow
Foundation
•Admin und
Deployment
•Status und
Historie
•Framework:
Repository,
Versionierung,
Metadaten
•Basis
Dokumentenmanagement
Site-Modell,
Sicherheit
und
Verwaltung
•Personalisierung
•Deployment
•Site Manager
•Site und
Rollenmanagement
Infrastruktur
E-Forms
Datenmanagement&
Reporting
•Verwaltung,
Publishing,
ProzessErzeugung
und
Abschluss
•Spreadsheet
Publishing &
Berechnung
•Report
Center
•Erweiterbare
und
anpassbare
Suche nach
Unternehmens
-daten und
Personen
• Textsuche
in
Teamsites
Windows SharePoint
Services**
**Included with Windows Server and CAL licenses
Abbildung 47: Funktionalitäten der verschiedenen SharePoint Editionen
Zum besseren Verständnis, der nachfolgenden Tabelle soll noch einmal auf Abbildung
43 verwiesen werden, die deutlich macht, dass WSS 3.0 Bestandteil von MOSS ist und
damit alle Funktionen, die durch WSS bereitgestellt werden auch durch MOSS bereitgestellt werden.
Funktionsbereiche
WSS
MOSS Standard
MOSS Enterprise
Details
Services
 Zentrale Administration
 Site Administration
 Eingehende Emails
incl.
incl.
 WSS Suche
 WSS WebApplikation
 EXCEL Service
-
-
 InfoPath Forms Service
 Business Data Catalog
Web
Content
Services
348
 Publizieren
-
 Content Verteilung
 Variations
(Mehrsprachigkeit)
Die Abbildung 47 hat keinen Anspruch auf Vollständigkeit
Seite 370
incl.
Funktionsbereiche
WSS
MOSS Standard
MOSS Enterprise
Details
 Profile
Portal
Services
 Personalisierung
 Zielgruppen
 Dokumenten und
Record Verwaltung
-
incl.
 Office Suche
 Dokument konvertierungen
Features
 Mobility Shortcut URL
 Team-Zusammenarbeitslisten
 Standard Inhaltstyp
Definitionen
 Dokumenten Center
Erweiterungen
 Übersetzungsbibliotheken
 Publizieren
 Standard Feld definitionen
 „Out of the box―
Workflows
 Issue Tracking
 Reporting
 Workflows
incl.
 Ereignismeldungen
(Alerts)
 Diskussionen
 RSS Feeds
 Daten Verbindung
Bibliothek
Office Enterprise:
 Business Data
Catalog
 Forms services
-
-
 Excel services
 Key Performance
Indikator und einige
Business
Intelligence Web Parts
Website
vorlagen
Site
Templates
 Leere Website
 Team Website
 Berichts und
Auswertungscenter
 Dokument
Arbeitsbereich
 Dokumentencenter
 Persönliche Site
 Wiki Website
 Suchportal
 Blog
 Kollaborationsportal
 Besprechung
Arbeitsbereich
 Websiteverzeichnis
incl.
 Content Management
 Publizieren mit
Workflow
Tabelle 58: Produktfunktionsmatrix349
349
MS Press „Microsoft Office SharePoint Server 2007 Administrator's Companion‖
Seite 371
1.2.2.1
Informationsstrukturen
SharePoint Site Struktur
Kern der Bereitstellung und Bearbeitung von Informationen in einer SharePoint Umgebung sind die sogenannten Site Collections. Eine Site Collection350 ist eine Menge von
logisch zusammenhängenden und hierarchisch angeordneten Sites mit gemeinsamer
Administration. Jede Site Collection beinhaltet mindestens eine Site, die Site „auf höchster Ebene―, die sogenannte „top-level Web Site―. Darunter hängen die dazugehörigen
Subsites. Für jede Site Collection gibt es eine eigene Administration, wodurch sie sich
auch gut für eine verteilte Administration eignen und Mandantenfähigkeit unterstützen.
Abbildung 48 veranschaulicht den grundlegenden Aufbau einer Site Collection.
Ausschnitt
Site
Collection
Top-level
Web Site
Subsites
Subsites
Ausschnitt
Listen
Ausschnitt
Eintrag 1
Eintrag 2
Eintrag 3
Eintrag 4
Feld 1
-----------------
Feld 2
-----------------
Feld 3
-----------------
Feld 4
-----------------
Felder
Listeneinträge
Abbildung 48: Grundlegende SharePoint Site-Struktur
Für jede Site Collection werden eigene Vorlagenkataloge bereitgestellt. Site Templates
beziehungsweise Site Vorlagen definieren Webparts, Listen, Bibliotheken (Dokumentenbibliotheken, Bildbibliotheken usw.) Content Types (Inhaltstypen), Metadata, Workflow
und so weiter. Eine Site beinhaltet dementsprechend eine Menge von Instanzen von
Webparts, Listen, Bibliotheken und so weiter sowie einer administrativen Ebene, auf der
man Berechtigung über Berechtigungsgruppen vergeben oder von der übergeordneten
Site erben kann, sofern es sich um eine SubSite handelt.
350
Könnte man frei übersetzen als Sammlung von Webangeboten im Sinne von Site = Website. Eine Übersetzung von Microsoft wurde nicht gefunden.
Seite 372
1.2.2.2
Metadaten
Bevor Listen, Bibliotheken und so weiter zur Verwaltung, der gemeinsamen Bearbeitung
oder dem Austausch von Dokumenten angelegt werden, steht die Definition der einzusetzenden Dokumenttypen, wie zum Beispiel Angebote, Verträge, Dokumentation. Das
heißt, es sollten weitestgehend alle möglichen Dokumenttypen, die genutzt werden, vor
der Inbetriebnahme einer SharePoint Umgebung (Collaboration Platform) definiert werden, um einen „Wildwuchs― von unkategorisierten Dokumenten, erzeugt oder importiert,
zu verhindern. Hierzu werden in SharePoint, wie in vielen anderen Collaboration Plattformen Metadaten eingesetzt. Sie dienen zum einen als einheitliches Schlagwortsystem
für das Filtern und die Suche und zum anderen fördern sie die Übersichtlichkeit über alle
Dokumente und der darin enthaltenen Informationen.
Metadaten werden im SharePoint entweder mittels sogenannter Content Types351
und/oder Site Columns definiert.
Ein Content-Type definiert die Attribute eines Eintrags einer Liste, eines Dokument oder
eines Ordners. Mit einem Content-Type können unter anderem folgende Spezifikationen
vorgenommen werden:

Eigenschaften, die mit den Instanzen eines Typs verbunden werden

Workflows, die von Instanzen eines Typs ausgeführt werden können

Management Policies, die mit den Instanzen eines Typs verbunden werden

Dokumentenvorlagen für Dokument-Content-Typen

Benutzerdefinierte Funktionen.
Content-Typen kann man mit einer Liste oder einer Bibliothek verbinden. In diesem Fall
können diese Listen und Bibliotheken Instanzen dieses Typs aufnehmen und innerhalb
der Liste oder der Bibliothek können entsprechende Instanzen erzeugt werden. Damit
sind Content Types auch nur für jeweils die Informationsobjekte gültig, mit denen sie
verbunden wurden. Bibliotheken können auch mehr als ein Content Type zugewiesen
werden.
Eine Site Column definiert die Attribute auf Ebene der Sites und ermöglicht damit zum
einen, dass diese für die Definition von Content-Types verwendet werden können und
zum anderen mehr Konsistenz in die Bezeichnung von Attributen zu bringen. Site Columns können auch einzelnen Dokumenten zugewiesen und sind dann nur in diesem
wirksam.
Werte definierter Attribute für Metadaten können über SharePoint Webseiten mittels
Browser gelesen und bearbeitet werden, ohne gleichzeitig das Dokument öffnen zu
müssen (siehe Abbildung 49) oder über einen der anderen Clients, wie zum Beispiel in
Word (siehe Abbildung 50).
351
Erst seit MOSS 2007 beziehungsweise WSS 3.0 verfügbar.
Seite 373
Abbildung 49: Metadaten eines Dokumentes im Browser
Die Metadaten werden, soweit es Microsoft Office Dokumente betrifft, in den einzelnen
Dokumenten abgelegt, wie z.B. in Word-Dokumenten als Dokumenteneigenschaften. Zu
anderen Dokumenten werden die Metadaten auf dem SharePoint abgelegt.
Abbildung 50: Word 2007 (Datei --> Eigenschaften)
Bestandsdokumente können nachträglich in eine SharePoint Umgebung, zum Beispiel in
eine entsprechende Bibliothek hochgeladen werden. Zunächst besitzen sie dann den
Standard Content Type „Document―. Anschließend kann man sie dann einem definierten
Content Type zuordnen und die entsprechenden Metadaten eingeben. Eine automatisierte Übernahme von Bestandsdokumenten, die gegebenenfalls auch entsprechende
Metadaten generiert oder übernimmt, wird nicht angeboten. Es bestehen die beiden
Möglichkeiten, die weiter oben schon beschrieben wurden:

Hochladen der Dokumente über das Web-Interface

Verschieben oder Kopieren der Dokumente, z.B. mit Hilfe des Dateimanagers in
die entsprechenden WebDAV-Ordner
In beiden Fällen erfolgt kein Mapping beziehungsweise eine automatische Übernahme
von Metadaten, diese müssen anschließend manuell eingegeben werden. Ob es hierfür
Werkzeuge von Drittherstellern gibt, ist nicht bekannt.
Seite 374
Zusammenfassend lässt sich festhalten, dass Content Types in nachfolgenden Bereichen Einfluss haben:

Dokument Vorlagen
Beim Erstellen eines Content Type wird definiert, von welcher Dokumenten Vorlage er erbt. Ein Content Typ muss nicht von einer Dokumenten Vorlage erben,
sondern er kann auch von Listen oder Bibliotheken erben.

Metadaten
Attribute für Metadaten können über Content Types definiert und Listen und Bibliotheken zugeordnet werden.

Workflow
Einem Content Typen kann ein Workflow zugeordnet werden.

Custom Forms
Die voreingestellten „Edit―, „View― und „New― Masken können durch eigene ausgetauscht werden

Information Policy
Einem Content Type können Regeln zugewiesen werden wie zum Beispiel
Drucklabel, zu protokollierende Ereignisse, Ablaufdatum und ein Dokumentbarcode.
1.2.2.3
Workflows mit SharePoint
„Out of the box― Workflows
Mit MOSS 2007 (nicht in den WSS) werden bereits einige vorgefertigte Workflows mitgeliefert352, die bereits einige Basisanforderungen abbilden:
352
353

Genehmigung (Approval)353
Mit diesem Workflow soll für ein Dokument oder einen Listeneintrag die
Genehmigung zur Freigabe eingeholt werden. In diesem Prozess kann der
Freigabe zugestimmt, sie kann abgelehnt oder es kann eine Änderung des
Dokumentes oder des Listeneintrages gefordert werden.

Feedback sammeln (Collect Feedback)
Mit diesem Workflow soll für ein Dokument ein Feedback von anderen Teammitgliedern eingeholt werden. Der Workflow ist dann abgeschlossen, wenn von jedem
aufgeforderten Teammitglied ein Feedback zu dem Dokument eingegangen ist.
Integrierte Workflows in MOSS 2007
http://blogs.msdn.com/sharepoint/archive/2006/06/07/introduction-to-sharepointworkflow.aspx
http://weblogs.mysharepoint.de/fabianm/archive/2006/08/21/Workflows-in-SharePoint2007-_2800_Teil-2_3A00_-Integrierte-SharePoint-Server-Workflows_2900_.aspx
Bei den Begriffen in Klammern handelt es sich um die Originalbezeichnungen der englischen Version.
Seite 375

Signaturen sammeln (Collect Signatures)
Diesen Workflow kann man auch als Mitzeichnungsprozess beschreiben. Hiermit
kann man für ein Dokument digitale Unterschriften (Signaturen) einholen. Der
Workflow erstellt dazu entsprechende Tasks für jede Person, die unterzeichnen
soll. Wenn die E-Mail-Funktionalität des SharePoint aktiviert ist kann der
Workflow auch eine Mail zu jedem Betroffenen senden mit einem entsprechenden Hinweis. Dieser Workflow kann laut Microsoft354 nur aus einer MS Office
2007 Anwendung (Word oder Excel) heraus gestartet und nur mit einem solchen
Client auch unterzeichnet werden355.

Dispositionsgenehmigung (Disposition Approval)
Dieser Workflow kann eingesetzt werden, um Dokumente einer Bibliothek, die
nicht mehr gültig sind, nach Einholung einer Genehmigung zu entfernen. Wenn
ein Dokument nicht mehr gültig ist, wird eine Genehmigung zum Löschen
angefordert. Wird diese abgelehnt, verbleibt das Dokument in der Bibliothek.

Gruppengenehmigung (Group Approval)
Dieser Workflow realisiert der Genehmigung einer Freigabe durch eine Gruppe
von Personen. Der Workflow ist im Wesentlichen identisch zu der oben beschriebenen einfachen Freigabe. Die Unterschiede liegen zum einen darin, dass die
Freigabe durch mehrere Personen erfolgen muss und weiterhin, dass er nur von
einer speziellen Dokumentenbibliothek bereitgestellt wird. Diese Bibliothek
integriert zusätzliche Sichten für den Status des Workflows und liefert zudem ein
Organisationsdiagramm, über das Personen für die Genehmigung ausgewählt
werden können.

Übersetzungsverwaltung (Translation Management)
Mit diesem Workflow kann die Übersetzungsaufgabe eines Dokuments gesteuert
werden. Hierbei werden von dem zu übersetzenden Dokument Kopien erzeugt
und an die für die Übersetzung zuständigen Personen verteilt, die für die Übersetzung von einzelnen Teilen zuständig sind. Dieser Workflow kann nur in einer
sogenannten „Translation Management Library― verwendet werden.

Problemverfolgung (Three State)
Das Tracking von Problemen und Anfragen wird über diesen Workflow unterstützt. Der Workflow erstellt eine Aufgabe für aktuelle Probleme und Anfragen, die
einem bestimmten Benutzer zur Bearbeitung zugewiesen sind.
Einfache sequenzielle Workflows, die auf Basis schon definierter Aktivitäten aufgebaut
werden, können mit Hilfe des kostenpflichtigen SharePoint Designers erstellt werden.
Wie auf Abbildung 51 zu sehen ist, kann man mit dem SharePoint Designer die einzelnen Schritte (Steps) eines Workflows festlegen. Diese Schritte bestehen aus Aktionen
(Actions) und dazugehörige Bedingungen (Conditions). Die einzelnen Schritte werden
dann in der definierten Reihenfolge ausgeführt. Ein definierter Workflow wird in einfacher
Weise, wie sie in Abbildung 51 zu sehen ist, dargestellt. In der rechten Spalte sind die
354
355
http://office.microsoft.com/en-us/sharepointserver/HA101544281033.aspx
Der Workflow wird auf der folgenden Webseite im Detail beschrieben:
http://office.microsoft.com/en-us/sharepointserver/HA101544281033.aspx
Seite 376
einzelnen Schritte des Workflows zu sehen, die von oben nach unten durchgeführt werden. Im linken Teilfenster sind die einzelnen Aktionen eines einzelnen Schrittes zu sehen. Hier können sie auch definiert und verändert werden. Es besteht keine Möglichkeit
einzelne Aktionen oder Bedingungen selbst zu programmieren, hierfür werden andere
Entwicklungsprodukte benötigt.
Abbildung 51: Workflow Tool - SharePoint Designer
Für die Entwicklung eigener und komplexerer Workflows werden folgende weitere Softwarepakete benötigt:

Visual Studio 2005/2008 als Entwicklungsumgebung (siehe Abbildung 52)

Visual Studio Erweiterungen für Windows SharePoint Services 3.0 (z.B. zum
Entwickeln von Web Parts)

Visual Studio Erweiterungen für das .NET Framework 3.0 (z.B. für Workflows)

Visual Studio Tools für Office Second Edition [VSTO 2005 SE]
(z.B. InfoPath Formular basierte Workflows)
Alle vorgenannten Softwarepakete sind kostenpflichtig.
Seite 377
Abbildung 52: Workflow Entwicklung mit Visual Studio
1.2.2.4
Integration von Microsoft Office 2007 Anwendungen
Die SharePoint Produkte zählen bei Microsoft zur Office 2007 Familie, daher fügen sich
alle Office 2007 Produkte nahezu nahtlos in die SharePoint Umgebung ein.
Nachfolgend wird für eine Reihe von diesen Office 2007 Anwendungen aufgezeigt, welche Funktionszusammenhänge sowohl in die eine wie auch die andere Richtung gegeben sind:
Word 2007 / Excel 2007 / PowerPoint 2007

Die Bearbeitung der Metadaten ist über den Dokument-Eigenschaften-Dialog
möglich, die Dateneingabe kann auf Wunsch auch erzwungen werden (siehe Abbildung 50).

Office Dokumente in einer SharePoint Bibliothek können direkt in Office geöffnet
werden, dies gilt auch für Office 2003. Dies wird über die Zuordnung von Dateitypen sichergestellt.

Die Nutzung von Workflows ist in der Benutzerschnittstelle als Menüpunkt eingebettet. Das heißt, es gibt einen Menüpunkt über welchen ein Workflow ausgewählt und gestartet werden kann.

Die Anzeige des Dokumentenzustand, ob z.B. ein Dokument „ein- oder ausgecheckt― ist, ist ebenfalls in die Benutzerschnittstelle integriert. Ebenso die Möglichkeit der Nutzung der entsprechenden Funktionen Check-In und Check-Out
über einen Menüpunkt.
Seite 378

Das Anzeigen aller verfügbaren Versionen eines Dokumentes, sofern die Versionsverwaltung aktiviert wurde sowie das Wiederherstellen älterer Versionen werden unterstützt.
Word 2007

Word hat zusätzlich die Möglichkeit, die aktuelle Version mit einer anderen Version zu vergleichen, ähnlich wie beim Zusammenführen zweier Dokumente.

Blogeinträge können direkt aus Word im SharePoint angelegt werden. Dabei wird
auf der Blog-Webseite unter den „Administratorenhyperlinks" auf „Blogprogramm
für Beitrag starten" geklickt. Anschließend wird Word gestartet und ein eigenes
Ribbon356 zum Erstellen von Blog-Einträgen angeboten.

Inhalte für Webseiten können erstellt und veröffentlicht werden (Funktion wie
vor).
Excel 2007
Mit der MOSS EE Edition werden auch so genannte Excel Services angeboten.
Hierbei handelt es sich um eine serverseitige Bereitstellung von Excel als eigener
Dienst, mit welchem Exceltabellen erstellt werden können. Die Excel Services:
o
verfügen über den gleichen Funktionsumfang wie die Office-Anwendung
Excel 2007 mit Formeln, Makros und so weiter und
o
sie dienen vor allem der serverseitigen Erstellung von Exceltabellen und
deren Aufbereitung (Rendern) für die Darstellung im Browser.
Access 2007

Erstellen von umfangreichen Auswertungen von SharePoint Listen in PDF/XPS
und anderen Formaten.

Zentralisierung der Datenspeicherung in SharePoint Listen, das heißt die Darstellung von Access-Dateien (.mdb) in Listen. Das bedeutet, dass auch AccessDateien (.mdb) in SharePoint verwaltet und versioniert werden können.
Outlook 2007
356

SharePoint Kalender (persönliche und Gruppenkalender) können in Outlook integriert werden, dabei können sie dann auch mit jedem Ausführen von Senden/Empfangen Events synchronisiert werden.

SharePoint Kalender lassen sich als HTML-Email an beliebige Empfänger versenden.

SharePoint Dokumente, Dokumentenbibliotheken und Ordner, die mit Outlook
verknüpft sind, werden wie die Aufgaben synchronisiert und stehen somit auch
offline zur Verfügung (auch zum Bearbeiten).

Aufgaben und Workflows können direkt aus Outlook heraus genehmigt werden.
Mit dem Schlagwort „Ribbon― bezeichnet Microsoft die neuen Symbolleisten, die zwar immer noch viele Einzelfunktionen umfassen, jetzt aber übersichtlich in thematischen Gruppen angeordnet sind.
Seite 379

Der Einsatz des Records Management für Emails357 (Voraussetzung: Exchange
2007) mit der Integration in das SharePoint Records Management
Ein „Record‖ ist im Sinne von SharePoint eine elektronisch verfügbare
Information (z.B. ein Dokument), die als Beweis einer Aktivität oder Transaktion
der Organisation gilt und die über einen gewissen Zeitraum aufbewahrt werden
muss. Mit Hilfe des Records Management (frei übersetzt: „Aktenführung― oder
„Schriftgutverwaltung―) kann eine Organisation vor allem:
o
o

Festlegen,

welche Informationen als „Record― in Betracht kommen,

wie aktive noch in Arbeit befindliche zukünftige „Records― behandelt und gesammelt werden, sobald sie „Record― sind und

wie und für wie lange jeder einzelne „Record―-Typ aufgehoben
werden soll.
Records-bezogene Aufgaben erledigen, wie das Löschen abgelaufener
„Records― sowie das Auffinden und Sichern von „Records―.
SharePoint Inhalte stehen auch als RSS Feeds zur Verfügung und können mit
dem Outlook- RSS Reader abonniert werden
OneNote 2007
Es ist möglich, OneNote Notizbücher zur gemeinsamen Bearbeitung in SharePoint Bibliotheken bereitzustellen.
InfoPath 2007

InfoPath Formulare können mit den SharePoint Forms Services (MOSS EE) veröffentlicht werden, wodurch sie Browser-fähig und dadurch auch mit mobilen
Endgeräten nutzbar werden.

InfoPath Formulare können als Email an Outlook 2007 Postfächer versendet
werden, wobei die Formular Ergebnisse in SharePoint Bibliotheken gespeichert
werden können
Office Communicator 2007 (Client für Office Communications Server 2007 [OCS])
Sobald der Anwender im Communicator aktiv ist, wird seine Verfügbarkeit auch
im SharePoint angezeigt (z.B. an Dokumenten, die durch den Anwender verändert wurden).
1.2.2.5
Entwicklungswerkzeuge
Es stehen im Wesentlichen drei Varianten bereit, um den SharePoint für bestimmte Aufgaben anzupassen oder ein Erscheinungsbild zu verändern: Die Weboberfläche im SharePoint selbst, der SharePoint Designer 2007, der eine Weiterentwicklung von Frontpage
darstellt und Visual Studio 2005/2008 (VS) mit den SharePoint 3.0 Erweiterungen.
357
http://download.microsoft.com/download/c/c/1/cc12d85c-4043-41a0-9528eb553785d5d8/Launch%20MOSS%20Dokumentenmanagement,%20Enterprise%20Conte
nt%20Management%20und%20Records%20Management.pdf
Seite 380
Der SharePoint Designer bietet Möglichkeiten zum Erstellen und Verwalten von Workflows sowie das Bearbeiten von Webseiten. Kompatibilitätsprüfungen zu Standards wie
Barrierefreiheit, CSS und (X)HTML werden ebenfalls unterstützt. Der SharePoint Designer kann auch ohne SharePoint, nur für die Webseiten Entwicklung eingesetzt werden.
Der SharePoint Designer ist für einfache Aufgaben, die Gestaltung des SharePoints und
einfache Workflows ausreichend. Sobald jedoch umfangreichere und komplexere Entwicklungen, wie zum Beispiel im Bereich Workflows, anstehen, ist es notwendig, die
Entwicklungsumgebung Microsoft Visual Studio 2005/2008 einzusetzen.
Erweiterungen für VS im SharePoint Umfeld:

VS Erweiterungen für Windows SharePoint Services 3.0 (z.B. zum Entwickeln
von Web Parts)

VS Erweiterungen für das .NET Framework 3.0 (z.B. für Workflows)

VS Tools für Office Second Edition [VSTO 2005 SE] (z.B. InfoPath Formular basierte Workflows)

Voraussetzung für den Einsatz der Erweiterungen ist die Installation der erforderlichen Frameworks.

.NET Framework 2.0 ( die aktuelle Version für den SharePoint)

.NET Framework 3.0 (enthält unter anderem die Windows Workflow Foundation
und die Windows Communication Foundation)
Da SharePoint selbst auf ASP.NET 2.0 basiert, ist es erforderlich, sich in diesem Umfeld
gut auszukennen. XML Schemata bilden die Konfigurationsgrundlage für viele Objekte
im SharePoint, wie zum Beispiel Sites, Content Types, Bibliotheken. Eine besondere
XML Ausprägung stellt die von Microsoft für SharePoint ab Version 3 definierte „Collaborative Application Markup Language (CAML) dar, die in vielen der genannten Objekt
Schemata zum Tragen kommt.
Hier sei anzumerken das sowohl für den SharePoint Designer als auch für Visual
Studio und abhängig von der VS Lizenz auch für die Erweiterungen Lizenzkosten anfallen!
1.2.3
Fazit
SharePoint hat ein großes Potential, mit maßgeschneiderten Lösungen Prozesse zu
unterstützen. Die Plattform ist ein Baukasten, aus dem man gut individuelle Lösungen
zusammenstellen kann. Viele Funktionalitäten werden bereits mitgeliefert, fehlende können relativ leicht programmiert und implementiert werden. Aber auch nicht benötigte
Funktionalitäten können deaktiviert werden.
Die Kehrseite von Vielseitigkeit und Flexibilität: ein relativ hoher Aufwand bei der
Implementierung. SharePoint ist keine Applikation, die man als fertiges Programm
installiert und dann sofort in Betrieb gehen kann. Eine umfangreiche Planung im Vorfeld
der Implementierung ist auf jeden Fall anzuraten, um die technischen Möglichkeiten
auch effektiv nutzen zu können.
Seite 381
Für den Einstieg in die Welt der Kollaborations-Portale und Workflows gibt es mit WSS
eine günstige Variante für die aktuelle Windows Server Plattform, sofern man diese auch
losgelöst vom Kollaborationsthema einsetzt und damit WSS gleich mit lizenziert hat. Sobald jedoch Enterprise Funktionen benötigt werden, fallen weitere erhebliche Lizenzkosten an, die vor dem Einsatz auf ihre Notwendigkeit überprüft werden sollten. Weitere
Kosten fallen an, wenn man auch noch Funktionalitäten der Echtzeitkollaboration (z.B.
Instant Messaging, Web-Meetings usw.) nutzen möchte. Hierzu wird der Office Communicator 2007 benötigt.
Ein Vor- sowie Nachteil dieses Produktes liegt jedoch in seiner starken Integration anderer Microsoft Office Produkte und der damit verbundenen Plattformabhängigkeit.
Zu bemängeln ist vor allem die Tatsache, dass die volle Funktionsfähigkeit nur durch die
Zulassung und den Einsatz von aktiven Inhalten genutzt werden kann. Hierdurch muss
man gegebenenfalls auch Einschränkungen bezüglich der Sicherheit hinnehmen. Die
Verantwortlichen in den Organisationen werden also vor die Entscheidung gestellt: volle
Funktionalität oder volle Sicherheit.
1.3
O3Spaces Workplace 2
Die junge Firma O3 Spaces B.V. entstand 2005 in den Niederlanden im Umfeld der Innovationen um die Ideen, die um das Marketingschlagwort Web 2.0 geboren wurden. Es
war zunächst das Ziel, eine webbasierte Ergänzung zu verschiedenen Officeplattformen
zu implementieren. Aufgrund der guten Dokumentation und lizenzfreien Verwendbarkeit
von OpenOffice.org und dem offenen ODF Dokumentenformat konzentrierte sich die
Entwicklung bald auf ebendiese Themen. Kundenreaktionen bekräftigten die Gründer in
ihrer Entscheidung, sodass die junge Firma ihre Bemühungen auf die Entwicklung einer
Collaboration-Software konzentrierte, die eng mit OpenOffice.org verknüpft ist. Das Ergebnis ist O3Spaces Workplace, welches 2007 in der Version 2.2 veröffentlich worden
ist. Es handelt sich dabei um eine Collaboration Anwendung mit direkter Integration in
OpenOffice.org und der Möglichkeit, über verschiedene Plattformen hinweg auch unter
Berücksichtigung von Microsoft Office, in Teams zusammenzuarbeiten.
O3Spaces Workplace steht in drei Lizenzversionen / Editionen zur Verfügung:

O3Spaces Workplace Professional Edition
Diese Version ist für Organisationen entwickelt worden, die OpenOffice.org oder
StarOffice verwenden. Auf Subscriptionsbasis werden Lizenz, Support und Updates in einem Paket verkauft. Für Testzwecke ist die Professional Edition kostenlos verfügbar.

O3Spaces Workplace On Demand Edition
Die On Demand Edition ist als SAAS (Software As A Service) Lösung ad hoc
verwendbar. Die Serveranwendung und die darauf gespeicherten Daten werden
in diesem Fall vom Anbieter auf dessen Server gehostet und nur die Clientsoftware muss vom Kunden installiert werden. Diese Lösung bietet sich als verwaltungsarme Möglichkeit an, kurzfristig und über das Internet gut erreichbare Gruppenarbeit über Workplace 2.2 zu organisieren. Hierbei werden die Daten jedoch
beim Anbieter gespeichert, wodurch die Datensicherheit in dessen Händen liegt.
Seite 382

O3Spaces Workplace Community Edition
Die Community Edition ist eine kostenlose Edition, die allerdings auf zehn Benutzer beschränkt ist.
Hierbei handelt es sich um proprietäre Software. Der Hersteller plant in naher Zukunft
eine quelloffene Variante von Workplace unter GPL bereit zu stellen.
Für das dritte Quartal 2008 wird vom Hersteller eine Programmierschnittstelle (API) angekündigt, mit der es auch für Dritte möglich sein soll Erweiterungen für Workplace zu
erstellen.
1.3.1
1.3.1.1
Technologie / Architektur
Architektur
Workplace 2.2 ist eine Serveranwendung mit verschiedenen Clients. Der Server speichert sämtliche zentral benötigten Informationen, Metadaten sowie Dokumente und stellt
diese über verschiedene Schnittstellen durch ein Webinterface oder über verschiedene
Plugins lokalen Officeanwendungen und auf einem lokalen Desktop zur Verfügung.
Der Server wurde als Javaanwendung in Servlets auf einem J2EE Application Server
(Apache Tomcat) implementiert. Sämtliche Metadaten und Versionsinformationen werden in einer PostgreSQL Datenbank gespeichert und verwaltet. Dokumente werden unkompliziert in einem Dateisystem abgelegt, während der Document Store die Versionierung und eine grundlegende Dokumentenverwaltung und Volltextsuche ermöglicht. Die
Benutzerverwaltung und der Verzeichniszugriff stehen über LDAP-ServerSynchronization zur Verfügung.
Das Repository für die Dokument Management Funktionalität ist sowohl als WebDAV
erreichbar, sodass mit Webbrowsern einfach darauf zugegriffen werden kann, als auch
über eine eigenständige Workplace API, die Programmierern in naher Zukunft zur einfachen Erweiterung des Funktionsumfangs zur Verfügung stehen wird und bereits von den
optionalen Plugins verwendet wird.
Plugins existieren für OpenOffice.org, StarOffice und MS Office. Die Plugins ermöglichen
den Zugriff auf die Repositories und auf grundlegende Document Management Funktionen direkt aus den Officeanwendungen heraus. Die Plugins greifen auf die Workplace
API zurück und wurden mit Hilfe von UNO beziehungsweise im Fall des MS Office Plugins als .NET Anwendung programmiert.
Über das OSGi-Framework ist es möglich, Module und Erweiterungen zu programmieren, die die Funktionalität von Workplace erweitern. Das OSGi ist ein Befehlsinterpreter, über den Systemaufrufe direkt an die Anwendung übergeben werden
können. Eine Kommandozeile erlaubt zusätzlich direkte Aufrufe während der Laufzeit.
Über dieses bereits vorhandene OSGi Studio command interface können einfache
Funktionen wie zum Beispiel die Deaktivierung von Systemmeldungen an einen
bestimmten Benutzer schnell realisiert werden. Eine Beschreibung des OSGi Command
Line interfaces ist in der Basis der Admin Dokumentation verfügbar.
Das Repository ist zudem über den Workplace Assistant erreichbar. Der Workplace
Assistent ist eine Java Applikation, die verschiedene Funktionen von O3Spaces
Seite 383
Workplace direkt in den Desktop integriert, sodass Echtzeitinformationen und zentrale
Dateien ohne offene Webbrowser oder Officeanwendungen einsehbar sind. Der Workplace Assistent erscheint dabei als Symbol in der Taskleiste und bietet über ein Pop-Up
Menü die Möglichkeit, gesperrte Dateien zu verwalten, sich an verschiedene Workspaces anzumelden und RSS Feeds über Änderungen in Workspaces zu lesen.
Das Standardwerkzeug für den Zugriff auf die Funktionen von Workplace 2.2 ist jedoch
ein aktueller Webbrowser wie Firefox 2 oder Internet Explorer 7 mit Unterstützung von
Ajax.
Somit stehen drei Clientkomponenten für Workplace 2.2 zur Wahl:

Workplace, das zentrale, graphische Webfrontend, über das sämtliche Funktionen und die Administration stattfinden,

Workplace Assistant, eine javabasierte Desktopintegration sowie

Office Suite Plugging für OpenOffice.org und Microsoft Office.
1.3.1.2
Die verschiedenen Komponenten und Dienste von Workplace 2.2 kommunizieren überwiegend durch dokumentierte Standardschnittstellen. Benutzer und Benutzergruppen
können über LDAP importiert werden. Es werden hierzu diverse Dienste unterstützt,
darunter OpenLDAP, Active Directory, Sun Directory Server und Novell Directory Server.
Für die Installation stehen Installer für Microsoft Windows und Debian Linux bereit. Weitere Installationspakete stehen als RPM (RedHat, Suse, Mandriva) und ein VMware Image zur Verfügung.
Auf Clientseite wird lediglich eine Java Laufzeitumgebung ab Version 1.5 und ein Webbrowser (z.B. Internet Explorer 7, Firefox 2 oder Mozilla) vorausgesetzt.
Office Suite Plugins existieren für OpenOffice.org ab Version 2.0.4, für StarOffice ab
Version 8 / Update 5 und für MS Office XP/2003/2007. Bei einer Installation unter Microsoft Windows wird das .NET Framework ab Version 2.0 benötigt.
Für die Installation des Servers wird eine Java Laufzeitumgebung ab Version 1.5 benötigt und der Port 8095 darf nicht belegt sein.
O3Spaces Workplace lässt sich unter Microsoft Windows, verschiedenen Linuxderivaten
und Solaris installieren. Plugins stehen für OpenOffice.org, StarOffice und Microsoft
Office bereit. Die Desktopintegration wird ebenfalls für Microsoft Windows, Solaris und
Linux angeboten. Die Integration in die Taskleiste wird hierbei jedoch ausschließlich
unter Microsoft Windows unterstützt. Der Assistent kann in OpenOffice.org und
StarOffice über einen Pull-Down Menüeintrag „Workplace" gestartet werden.
1.3.1.3
Sicherheitsaspekte
Die Verbindungen zwischen Client und Server lassen sich per SSL verschlüsseln, wobei
der Zugriff über unverschlüsseltes HTTP durch verschiedene Mittel begrenzt oder ausgeschlossen werden kann. Zusätzlich ist die Integration des gesamten Dienstes in ein
VPN problemlos möglich.
Seite 384
Das Repository liegt unverschlüsselt auf dem Server und ist lediglich durch Zugriffsrechte auf Anwendungs- und Systemebene geschützt.
Die Zugriffskontrolle innerhalb der Anwendung erfolgt auf Benutzerebene und kann auf
der Stufe einzelner Workplaces oder einzelner Ordner für jeden Benutzer definiert werden.
Die IP-Adresse von Clientsystemen wird als Metainformation gespeichert und kann bei
nicht dynamisch vergebenen IP-Adressen als zusätzliches Zugriffs- und Sicherheitskriterium genutzt werden, indem der Zugriff auf bestimmte Netzbereiche und IPs beschränkt
wird.
Ein Großteil der Funktionalität von O3Spaces Workplace 2.2 wird über das Webfrontend
bereitgestellt. Bezüglich der dort verwendeten aktiven, dynamischen Inhalte wird technologisch auf Ajax zurückgegriffen. In diesem Kontext sollten bei der Installation, Konfiguration und im Betrieb besondere Sicherheitshinweise des BSI zu Web 2.0 Berücksichtigung finden. Diese sind in Form einer Studie auf den Webseiten des BSI zu finden und
können von dort heruntergeladen werden358.
1.3.2
Funktionalitäten
O3Spaces Workplace 2.2 bietet verschiedene Werkzeuge zur Koordination von kleinen
und größeren Arbeitsgruppen mit einer Dokumentenverwaltung und -versionierung.
Sämtliche Funktionen der Applikationen werden auf der Weboberfläche Workplace abgebildet. Benutzer authentifizieren sich über eine sichere Verbindung gegenüber der
Applikation und erhalten so Zugang. Hierbei handelt es sich um kein Standardverfahren,
sondern um eine proprietäre Lösung.
Projekte werden innerhalb der Anwendung als sogenannte Workspaces angelegt. Jedes
Workspace verfügt über eine eigene Aufgabenstruktur und ein Dateiarchiv. Zur Definition
eines Workspaces können zusätzlich projektspezifische Templates festgelegt werden,
die als Spacelets bezeichnet werden. Spacelets können bestimmte Dateien beinhalten,
Terminlisten, Verweise auf Forendiskussionen oder einen besonderen Projektkalender.
Dies erleichtert die Verwaltung komplexer Projekte, an denen verschiedene Teams gemeinsam arbeiten.
Innerhalb eines Workspaces erhält ein Benutzer Zugang zu projektbezogenen Diskussionsforen und Dateiablagen. Benutzer können auch verschiedene Workspaces parallel
öffnen und über eine Tabdarstellung zwischen ihnen wechseln. Diese Flexibilität macht
Workplace auch für umfangreichere Projekte mit verschiedenen Arbeitsgruppen, in denen Mitarbeiter verschiedene Aufgaben übernehmen, interessant.
Die Ansicht innerhalb eines Workspaces wird über frei definierbare oder vorgegebene
Spacelets festgelegt. Ein Spacelet kann zum Beispiel eine Kalenderdarstellung repräsentieren, während ein weiteres Spacelet die Dateiverwaltung anzeigt. Spacelets werden
innerhalb des Webinterfaces als Fenster erstellt und mit entsprechenden Funktionen
konfiguriert.
358
http://www.bsi.de/literat/studien/web20/
Seite 385
Der Workplace Assistant auf dem Desktop bietet eine zu den Office-Plugins separate
Möglichkeit, Dokumente zu sperren, falls lokal an ihnen gearbeitet wird. Nach der Anmeldung können auch darin Workspaces ausgewählt werden, wonach zusätzlich Meldungen in Echtzeit auf dem Desktop erscheinen, die Änderungen und Sperrungen an
Dokumenten durch andere Gruppenmitglieder melden.
Die Office-Plugins für OpenOffice und StarOffice greifen zusätzlich auf ein Template
Management Module zu, das ein projektspezifisches Templatearchiv darstellt. Somit
können neue Officedokumente direkt aus angepassten Templates erstellt werden (siehe
Abbildung 53).
Abbildung 53: Template Management Module
Workplace bietet für jeden Workspace eine separate Dokument Management Funktionalität. Dateien, die über das Webinterface oder die Plugins geöffnet, erstellt oder modifiziert werden, werden automatisch versioniert und archiviert. Dies betrifft alle möglichen
Dateiformate und beinhaltet Zeitstempel und Angaben über Benutzer und optionale
Kommentare. Herkömmliche Officeformate aus dem Microsoft Office, StarOffice und aus
OpenOffice.org werden zusätzlich indexiert, sodass sie mit der Volltextsuche von Workplace auffindbar sind.
Eine Besonderheit von O3Spaces Workplace sind die Office Suite Plugins für OpenOffice.org und Microsoft Office. Sie realisieren eine starke Integration der Workplace
Funktionen und erscheinen innerhalb der Officeanwendung als eigene Symbole.
Hierüber ist es möglich, Dokumente direkt aus den Repositories heraus zu laden und
wieder auf dem Server zu speichern, ohne eine lokale Zwischenspeicherung, manuelle
Sperrung und nachträgliche Veröffentlichung über Clients oder die Weboberfläche
durchführen zu müssen. Die so gespeicherten Dokumente werden ebenfalls automatisch
versioniert oder gesperrt und entsprechende Meldungen werden auf angemeldeten
Clients verteilt.
Seite 386
Das Repository eines Workspaces kann nach diversen Kriterien (Datum, Benutzer, usw.)
und durch Volltextsuche (ODF, PDF und MS Dokumentenformate) durchsucht werden.
Alle Clients sind in der Lage, offline zu arbeiten und eine zeitversetzte Synchronisation
von Informationen und Dokumenten durchzuführen.
Weitere Spacelets können so konfiguriert werden, dass sie eine Kalenderansicht zeigen,
in der Termine und Aufgabeninformationen angezeigt und bearbeitet werden können.
Ein klassisches Diskussionsforum kann angelegt werden, in dem alle Benutzer eines
Workspaces nach Themen sortierte Onlinediskussionen führen. Entsprechende Spacelets informieren über aktuelle Einträge.
Funktion
Beschreibung
Benutzerverwaltung
Neue Benutzer werden durch existierende Benutzer, welche die Rolle Administrator innehaben, den Workspaces
zugeordnet, die für sich als Projektinstanzen angelegt werden können.
Dateiverwaltung
Dokumente werden über Clients und Plugins direkt aus der
Officeanwendung synchronisiert. Automatische Archivierung mit Metainformationen sowie Volltextindizierung werden unterstützt.
Terminplanung
Terminplanung für Gruppen und einzelne Benutzer ist über
ein Kalender-Spacelet möglich.
Besonderheiten
Frei definierbare Ansichten im Webclient und einfache
Arbeit in verschiedenen Projekten zur gleichen Zeit.
Besonders hohe Integration in OpenOffice.org, StarOffice
und Microsoft Office.
Tabelle 59: Funktionen O3Spaces Workplace
Der Schwerpunkt der Anwendung liegt eindeutig auf der Zusammenarbeit in verschiedenen Officedokumenten. Es fehlt die Möglichkeit, Mitarbeitern Aufgaben zuzuweisen, die
Erledigung von Aufgaben zu verfolgen sowie die Steuerung und Kontrolle von Prozessen. Für die Projektarbeit ist Workplace 2.2 somit kein universelles Werkzeug, sondern
empfiehlt sich als Ergänzung zu einem Werkzeug zur Projektplanung und -verfolgung für
die Zusammenarbeit in heterogenen Umgebungen.
Die Administration von Workplace 2.2 erfolgt über ein separates Webinterface. Diese
„Studio" getaufte Oberfläche ermöglicht die Verwaltung von Benutzern und Dateien und
erleichtert die Kontrolle über Hardwareressourcen und Metadaten. Verschiedene nützliche Werkzeuge erleichtern diese Arbeit, so zum Beispiel die Möglichkeit, ganze Verzeichnishierarchien aus lokalen Verzeichnissen zu übernehmen, indem sie aus ZIP
Archiven importiert werden.
Die nachfolgende Tabelle stellt dar, welche Funktionen durch die verschiedenen Editionen bereitgestellt werden.
Seite 387
Funktion
On Demand
Community
Professional



-
-
-
-
-
-




-


extern
extern




Integrierte Hilfefunktion





Support zum Clustering
-
-
Server basierte Installation mit unlimitierter
Benutzerzahl
-
limitiert auf
10 Benutzer




















-













-
-







Einfaches Roaming
Keine Serverinstallation
Kleine lokale Installation, Sicherheit durch
den Hersteller
Automatische Updates
Upgrade und Update Services
Backup und Recovery
Sicherheit und User Management über
User, Gruppen Rollen und Rechte
Management
Online Community Support
LDAP
Online Professional Support
Bugs & Patch Support
Automatische Versionierung, checkin/check-out Funktion
Mehrsprachliche Versionen
Office Integration
Zeitnahe Berichte über Änderungen innerhalb eines Workspaces
O3Spaces Workplace Assistant
Template Management für OpenOffice.org /
StarOffice
Management von gelockten Dateien über
den O3Spaces Workplace Assistant
Suche nach offenen Dokumenten
Verweise auf Dokumente im Wiki, Portal
oder der Website
OpenSearch kompatibles Repository
Spacelets für Online Diskussionsforen
Spacelets für Kalenderfunktion
-
Tabelle 60: O3Space – Funktionen in den verschiedenen Editionen
Seite 388
1.3.3
Fazit
In heterogenen Umgebungen mit verschiedenen Plattformen und Officeanwendungen
bietet sich O3Spaces Workplace 2.2 als übergreifende Kollaborationsumgebung mit
elementaren DMS Funktionen an. Die Verwaltung der Gruppen und Benutzer lässt sich
mit bereits vorhandenen Benutzerdaten über LDAP synchronisieren. Prozesssteuerung
und Projektwerkzeuge sind derzeit nicht vorgesehen, wodurch sich die Anwendung vor
allem für kleine bis mittlere Projektgrößen und Arbeitsgruppen in heterogenen Umgebungen anbietet.
1.4
Novell Teaming + Conferencing
Novell hat das Produkt Teaming + Conferencing359 erstmalig im Oktober 2007 auf den
Markt gebracht. Die Technologie, auf der dieses Produkt basiert, ist allerdings schon seit
etwa 13 Jahren am Markt und kommt von der Firma Sitescape, die inzwischen von Novell gekauft wurde360.
Die Kollaborationslösung ICEcore ist die Basis für das Produkt von Novell und kann als
Open Source Software von der Webseite www.icecore.org heruntergeladen werden.
ICEcore steht unter der Common Public Access License (CPAL)361.
Teaming + Conferencing resultiert aus der gemeinsame Weiterentwicklung von ICEcore
durch die Firmen Sitescape und Novell. Die nachfolgende Abbildung veranschaulicht die
Unterschiede zwischen dem Open Source Produkt und der Novell Lösung und zeigt die
kostenpflichtigen Add-On Module.
ICEcore
Portal
Personal, team & global workspaces
Blogs, wikis and discussion forums
Document management
Surveys and polls
Team calendars and tasks
Expertise locator
Search
File transfer through WebDAV
LDAP import
MySQL database support
Web conferencing
Instant messaging/chat
Presence engine
Open source
ICEcore
add-on
modules
ICEcore Enterprise
adds:
Advanced document conversion & viewing
 More document types converted
 Scalability – higher performance indexing
 Higher quality conversions
Higher performance search
Basic Workflow
Oracle & MS SQL database support
Support for regulatory compliance processes,
such as Sarbanes-Oxley, HIPAA, etc.
Compliance with 508 accessibility standards
LDAP synchronization
Voice conferencing
Novell Teaming+
Conferencing
First release:
Advanced Workflow
Telephony Interface
Subsequent release:
Advanced Search
Offline Capability
SiteScape
modules
Abbildung 54: Funktionen von ICEcore OSS, Novell Teaming + Conferencing und ICEcore
Add-On Modulen
359
360
361
gesprochen Teaming plus Conferencing
http://www.sitescape.com/
http://en.wikipedia.org/wiki/Common_Public_Atvontribution_License
Seite 389
Novell Teaming + Conferencing ist eine Collaboration Plattform für Linux-Systeme.
Teaming + Conferencing sind zwei Softwarepakete, die auch jede für sich allein genutzt
und erworben werden können. Der Hersteller bietet die beiden Pakete sowohl einzeln als
auch als gemeinsames Paket an.
Die beiden Pakete stellen unterschiedliche Funktionalitäten für eine Collaboration Plattform zur Verfügung (siehe Abschnitt III.B 1.4.2). Daher erfolgt sowohl bei der Betrachtung der verwendeten Technik als auch den verfügbaren Funktionen eine weitgehend
getrennte Betrachtung362.
1.4.1
1.4.1.1
Novell Teaming
Architektur
Für eine Installation der Teamingsoftware sind nachfolgend aufgelistet die Hard- und
Software Voraussetzung363, (alle weiteren Komponenten liefert das Installationspaket):


Hardware
o
2 GHz Prozessor (Multi-CPU Systeme werden empfohlen)
o
2 GB RAM
o
250 MB Plattenplatz
Dies ist der Speicherbedarf allein für die Installation der Software.
Weiterer Plattenplatz wird natürlich für die Teamarbeitsbereiche in die
darin abgelegten Daten, Dokumente und so weiter benötigt.
Software
o
Sun JDK 1.5.0_011364 oder höher oder IBM JDK 1.5
(JDK 1.6 wird derzeit nicht unterstützt)
o
Datenbankmanagementsystem

MySQL 5.0.37 (oder höher) Server und Client für Linux

MySQL 5.0.26 (oder höher) Server und Client für Windows
(MySQL 5.1 wird derzeit nicht unterstützt)

SQL Server für Windows Server 2000 oder 2005

Oracle 9, 10
Die folgenden Betriebssysteme werden unterstützt 365:
362
363
364
365
Um Novell Conferencing in Novell Teaming nutzen zu können müssen die Installations- und
Konfigurationshinweise im Server Installation Guide beachtet werden.
http://www.novell.com/documentation/team_plus_conf/index.html
Eine genaue Beschreibung findet man im Installation and Configuration Guide,
http://www.novell.com/documentation/team_plus_conf/team102_instconfig/ data/bookinfo.html
Entspricht der von neu verwendeten Versionsnummerierung JDK 5 (siehe
http://java.sun.com/javase/downloads/index_jdk5.jsp)
http://www.novell.com/products/teaming/tech_specs.html
Seite 390

Novell Open Enterprise Server 2.0 (Linux Kernel)

SUSE® Linux Enterprise Server 10 sp1

RedHat Enterprise Linux 3 or 4

Windows 2003 Server
Die nachfolgende Abbildung 55 beschreibt die für das Teamingsoftwarepaket verwendete Architektur. Novell Teaming ist eine reine Java/J2EE Web-Anwendung. Als Servlet/Applicationserver kommt Apache Tomcat366 zum Einsatz. Als Portallösung wird die
Open Source Software „LifeRay Portal Enterprise and Professional Version 4.0― der
gleichnamigen Firma LifeRay verwendet.
Abbildung 55: Architektur des Novell Teamingsoftwarepakets
367
Für die Suche wird in Novell Teaming das Open Source Projekt Apache Lucene 368
eingesetzt.
Der Zugriff auf das Filesystem wird über WebDAV (Server und Client) realisiert.
Weitere wichtige Schnittstellen sind:
366
367
368

JDBC für den Zugriff auf die Datenbank

LDAP für die Integration von Verzeichnissen, z.B. für die Benutzerverwaltung
http://tomcat.apache.org/
Aus dem Installation and Configuration Guide der Firma Novell (siehe
http://www.novell.com/documentation/team_plus_conf/)
http://lucene.apache.org/
Seite 391
Es besteht die Möglichkeit, eine auf einem LDAP-Verzeichnis basierende
Benutzerverwaltung zu integrieren. Alternativ oder parallel können die
Benutzer auch direkt auf dem Teamingsserver verwaltet werden. Dies bietet
den Vorteil, dass externe Teammitglieder nicht in der internen zentralen
Benutzerverwaltung aufgenommen werden müssen.

SMTP, POP3 und IMAP für die E-Mail-Integration

WebServices für die Anbindung weiterer Anwendungen und Dienste

iCal für die Einbindung und Verwaltung von Kalender, die wiederum mit
WebDAV veröffentlicht werden können.

HTTP und HTTPS für den Zugriffs zum Beispiel über Browser
Daten und Dokumente der Teamarbeit werden mit Hilfe von Novell Teaming in der Datenbank oder auf dem Dateisystem abgelegt.
Sicherheitsaspekte
Authentisierung und Benutzerverwaltung
Die Authentisierung erfolgt über die browserbasierte Benutzerschnittstelle. Dabei kann
die Authentifizierung sowohl gegen ein LDAP-Verzeichnis als auch gegenüber der Benutzerdatenbank der Teamingsoftware erfolgen. Das bedeutet, dass Benutzer parallel
sowohl in einem LDAP-Verzeichnis (z.B. das zentrale interne Benutzerverzeichnis) oder
lokal auf der Teamingplattform verwaltet werden können. Dies hat Vorteile, wenn es darum geht auch externe Teammitglieder zu integrieren, die aber nicht in der internen Benutzerverwaltung geführt werden sollen.
Für die Implementierung einer Single Sign On Lösung unterstützt Novell Teaming die
hauseigene Novell Access Manager Lösung369. Hierbei handelt sich um ein proprietäres
kostenpflichtiges Produkt, das nicht Bestandteil von Teaming + Conferencing ist.
Weiterhin werden für die Nutzung von WebServices und WebDAV auch Authentisierung
über diese Schnittstellen unterstützt.
Autorisierung
Die Vergabe von Zugriffsrechten erfolgt rollenbasiert für jeden Arbeitsbereich und Ordner. Dafür stellt Novell Teaming einen Satz von Basisrollen zur Verfügung 370. Durch eine
hierarchische Anordnung der verschiedenen Arbeitsbereiche (siehe Abschnitt III.B
1.4.2.1 – Verwendete Strukturen) kann eine verteilte Administration genutzt werden.
Gleichzeitig wird Mandantenfähigkeit unterstützt.
Zur Sicherstellung ausreichender Verfügbarkeit und Performanz unterstützt Novell Teaming auch Load-Balancing und den Aufbau von Clustern.
369
370
http://www.novell.com/products/accessmanager/overview.html
Näheres findet man dazu im „Installation and Configuration Guide―
http://www.novell.com/documentation/team_plus_conf/team102_instconfig/ data/bookinfo.html
Seite 392
Werkzeuge
Für die Konfiguration und Administration von Novell Teaming stehen verschiedene webbasierte Schnittstellen, sogenannte Portlets, für unterschiedliche Aufgaben und Komponenten zur Verfügung. Nachfolgende Abbildung 56 zeigt das sogenannte „Enterprise
Admin Portlet― mit einem Ausschnitt der Benutzerverwaltung.
Abbildung 56: Enterprise Admin Portlet
1.4.1.2
Conferencing Server
Systemvoraussetzungen371
Die folgenden Voraussetzungen müssen für eine Installation von Novell Teaming erfüllt
sein:

Betriebssystem: SUSE Linux Enterprise Server 10 (SLES 10) oder Red Hat
Enterprise Server 4

Die Bibliotheken libneon and libpq
Diese werden z.B. bei einer Standardinstallation des SLES 10 nicht installiert.

PostgreSQL372
Muss auf einem der Conferencing Hosts installiert sein.
Architektur / Systemkomponenten
Die nachfolgende Abbildung 57 zeigt die Systemkomponenten und ihre Verbindungen
untereinander.
Der Conferencing Server kann durch seinen sehr modularen Aufbau für einen Betrieb
sowohl auf einen einzelnen Rechner als auch auf mehreren Rechnern konfiguriert werden. Die Kommunikation zwischen den Komponenten erfolgt über XML-basierte Schnittstellen. Die Kommunikation zwischen den einzelnen Instanzen dieser Schnittstellen ba-
371
372
Details werden im „Server Installation Guide― von Novell beschrieben
http://www.novell.com/documentation/team_plus_conf/conf10_svrinst/data/bookinfo.html
Angaben zur Version werden im „Server Installation Guide― zu Novell Conferencing nicht
gemacht.
Seite 393
siert auf wohldefinierten Protokollen, welche das Format (XML), die Struktur, den Inhalt,
die Bedeutung und die Reihenfolge gesendeter Nachrichten zwischen diesen Instanzen
festlegen.
Abbildung 57: Architektur Novell Conferencing373
Die Komponenten sind im Einzelnen:
373

XML Router
Routet die XML-basierte Kommunikation zwischen den Komponenten

Client Connector
Steuert die ankommenden Verbindungsanfragen der Clients und stellt Benutzersitzungen zusammen mit dem Sitzungsmanager (Session Manager) her.

Session Manager
Verwaltet die Benutzersitzungen und erlaubt Benutzern „Instant Messages―
auszutauschen.

Meeting Controller
Verwaltet laufende Meetings und verteilt Ereignisse eines Meetings an die
Teilnehmer der Meetings.

Notification Server
Sendet „Hinweis/Ankündigungs-Mails― und „Instant Messages― im Auftrag des
„Meeting Controller― und des „Schedule Server―
Aus „Server Installation Guide― zu Novell Conferencing
http://www.novell.com/documentation/team_plus_conf/conf10_svrinst/data/bookinfo.html
Seite 394

Address Book
Speichern von Adressbüchern von einzelne Personen und von Gruppen

Schedule Server
Speichert für Meetings Terminplanung, Optionen und Teilnehmer und ruft
diese bei Bedarf ab.

Voice Bridge
Kontrolle der Telefonieressourcen, herstellen von Verbindungen zu Konferenzen und einiges mehr.

Meeting Archiver Server
Erstellt Macromedia Flash-basierte Archive von Meetings in einem Repository, auf welches über das Web zugegriffen werden kann.

App Share Server
Überträgt gemeinsame Anwendungsdaten vom vortragenden Meetingteilnehmer zu den anderen Teilnehmern

Invitation Web Service
Verbindet Meetingsteilnehmer per „Invitation URL―374

External Web Service
Bereitstellung von WebServices für die Anbindungen externer Anwendungen..
Aus der Liste von Komponenten mit der groben Beschreibung ihrer Aufgaben werden
auch schon im Wesentlichen die Funktionen des Conferencing Servers beschrieben.
Werkzeuge
Für die Administration von Novell Conferencing steht eine webbasierte Schnittstelle zur
Verfügung, die sogenannte „Conferencing Administration Console―. Die folgende Abbildung zeigt die Oberfläche dieser Administrationsschnittstelle 375.
374
375
Frei Übersetzt „Einladungs-URL―. Hierbei handelt es sich um eine spezielle URL, die an die
Teilnehmer eines Meetings versendet werden und die einen bestimmten Code enthalten,
der das Meeting identifiziert.
Siehe hierzu auch die Inhalte des „Operations Guide― zu Novell Conferecing
http://www.novell.com/documentation/team_plus_conf/conf10_op/data/bookinfo.html
Seite 395
Abbildung 58: Oberfläche der Administrationsschnittstelle zu Novell Conferencing376
1.4.2
Funktionalitäten
Teaming + Conferencing ist eine Plattform für die Zusammenarbeit von Arbeitsgruppen,
deren Mitgliedern sich aus Mitarbeitern einer Organisation zusammensetzen. Bei Bedarf
können auch externe Teilnehmer eingeladen werden. Das Teamingpaket liefert die
Werkzeuge für eine gemeinsame Bearbeitung und den Austausch von Informationen
und Dokumenten sowie für die Abstimmung und Planung der gemeinsamen Arbeit. Das
Conferencingpaket liefert dann noch die Werkzeuge für die Echtzeitkommunikation, also
Telefon- und Webkonferenzen, Chats und ähnlichem. Dabei können alle Aktivitäten und
Prozesse durch automatische Workflows unterstützt werden. Abbildung 59 zeigt im
Überblick, welche Hauptfunktionen bereitgestellt werden.
376
Aus dem „Operations Guide― zu Novell Conferecing
http://www.novell.com/documentation/team_plus_conf/conf10_op/data/bookinfo.html
Seite 396
Kommunikation
Bearbeiten
Telefonkonferenzen
Blogs
IM & Chat
Wikis
Presänz
Integrierte
Diskussion
Suite
Gemeinsame
Dokumente
Verwaltung
Workflow
Foren
Aufgabenverwaltung
Web Konferenzen
Termin- & Kalender
Verwaltung
Abbildung 59: Workflow gesteuerte Collaboration
1.4.2.1
Teaming Funktionen
Funktionen
Die Funktionen der Teamingsoftware orientieren sich an der Bereitstellung von Teamarbeitsplätzen mit all den Werkzeugen, die ein Team für seine Arbeit benötigt. Die nachfolgende Tabelle zeigt die verschiedenen Bereiche/Werkzeuge, die auf einem Arbeitsplatz
zur Verfügung gestellt werden können.
Innerhalb eines Arbeitsplatzes besteht die Möglichkeit folgende Funktionsbereiche anzulegen:
Funktionen
Team/globale Arbeitsplätze
Details
 Erstellen und verwalten von Teamzugehörigkeit
 Verbinden mit eDirectory über LDAP
 Teammitgliedschaft kann abhäbgig sein von folgenden
Eigenschaften:


Benutzer
Gruppen
 Organisationen
 Teams können auch aus externen Benutzern bestehen
 Adressbücher der Teams
 Veröffentlichen der Team Mailadressen über eDirectory
zu GroupWise
Team Diskussionsforum
 ―threaded‖ Diskussionen für die Teams
 Neue Einträge können Mails an Groupwise versenden
 Benutzer können direkt über Groupwise antworten
Seite 397
Funktionen
Team Calendars & Tasks
Details
 Teamevents und Aufgaben können im Teaming-Portal erstellt
werden
 Teammitglieder können wählen, ob Sie diese Events und
Aufgaben an Group-Wise geschickt bekommen wollen
 Events und Aufgaben erscheinen als Aufgaben und Termine
im Groupwise System, nicht als Mail
 Benutzer können Dokumente (Dateien) in den Ordner hochladen. Bezüglich der Verwendung von unterschiedlichen Datei377
formaten gibt es keine Einschränkungen. Einschränkungen
gibt es höchstens in der weiteren Verwendung (siehe nächsten Punkt)
 Dokumente können im HTML-Format im Browser dargestellt
werden, sofern sie lesbar sind. Verschlüsselte Dokumente
lassen sich also nicht darstellen. Ob sich ein Dokument im
HTML-Format anzeigen lässt, wird in der Benutzerschnittstelle
angezeigt (siehe Abbildung 63). Mit einem Mausklick auf den
HTML-Eintrag erfolgt dann auch die Darstellung der Inhalte im
Browser.
 Dokumente können in Office direkt geöffnet und bearbeitet
werden – das ganze über WebDAV
 Dokumente können ―ausgecheckt‖ werden.
 Vorherige Version werden automatisch archiviert; die Versionierung erfolgt über Zeitstempel
 OES/Netware Filesystem kann als Spiegel verwendet werden
– ein sogenannter „virtual import‖
Workflow
 Einfacher Workflow

Manuelles ändern des Status


Zugriffskontrolle
Benachrichtigung
 Erweiterter Workflow


Sonstige Teamfunktionen
 Befragungen / Surveys




Suche
Komplexe Übergänge
Gleichzeitiger Workflow
Wikis
Blogs
RSS
Dashboard
Es wird eine einfache / schnelle Suche bereitgestellt.
Für eine gezielte Suche bietet die erweiterte Suche erheblich
Vorteile.
Die nachfolgende Abbildung 60 zeigt einen Ausschnitt dieser
erweiterten Suche.
Tabelle 61: Novell Teaming Funktionen
377
siehe auch Formatliste im Anhang
Seite 398
Abbildung 60: Erweiterte Suche Novell Teaming
Seite 399
Verwendete Strukturen
Novell Teaming unterscheidet bei den Arbeitsbereiche (Workspace) zwischen drei
Typen:

Unternehmensweiter globaler Arbeitsbereich

Arbeitsgruppenweiter Arbeitsbereich

Persönlicher Arbeitsbereich
Innerhalb jedes dieser Arbeitsbereiche können nach der Einrichtung Unterarbeitsbereiche und Ordner angelegt werden. Dabei werden die übergeordneten Zugriffsrechte
standardmäßig nach unten vererbt. Diese Zugriffsrechte können durch den jeweiligen
Administrator eines Arbeitsbereiches oder Ordners nachträglich angepasst werden, sofern dies notwendig ist.
Darüber hinaus gibt es noch die Möglichkeit Projektarbeitsbereiche anzulegen, die speziell auf die Anforderungen für ein Projektmanagement ausgerichtet sind.
Für jeden Arbeitsbereich können folgende Standardordner angelegt werden:

Diskussion

Blog

Wiki

Kalender

Gästebuch

Datei

Fotoalbum

Umfrage

Aufgaben

Meilenstein
Neben der Nutzung dieser Standardstrukturen lassen sich auch für spezielle Bedürfnisse
sogenannte benutzerdefinierte Einträge entwerfen und einfügen 378. Diese sogenannten
Custom Entries können mit Hilfe des „Teaming Administration Portlet― erstellt werden. Es
handelt sich hierbei um Formulare (Forms) und Ansichten (Views) für spezifische Inhaltseinträge. Diese können genau wie die Standardforms und –views mit Workflows
verbunden werden, wodurch eine weitgehende Anpassung die speziellen Bedürfnisse
einer Behörde möglich ist.
378
Siehe Administration Guide
http://www.novell.com/documentation/team_plus_conf/team10_admin/data/bookinfo.html
Seite 400
Workflows
Novell Teaming beinhaltet die Möglichkeit mit Hilfe des Teaming Administration Portlet
und innerhalb dessen mit dem Workflow Designer einfache Workflows zu definieren.
Hierfür werden die einzelnen Zustände ausgewählt und mit den entsprechenden Zustandsübergängen miteinander verbunden.
Jeder Zustand ist mit einem Arbeitsschritt verbunden und identifiziert das Ergebnis der
vollständigen Umsetzung dieses Schrittes. Weiterhin zeigt ein Zustand an, wer innerhalb
des Prozesses (Gesamt-Workflow) für den nächsten Schritt verantwortlich ist.
Die Zustandsübergänge definieren die Reihenfolge der Arbeitsschritte und geben an,
wann, wie und/oder unter welchen Bedingungen ein Übergang erfolgen kann. Die nachfolgende Abbildung zeigt, welche Arten von Übergängen möglich sind.
Abbildung 61: Zustandsübergänge im Novell Teaming Workflow379
Das Ergebnis der definierten Zustände und Übergänge eines Workflows können dann
grafisch angezeigt werden.
Abbildung 62: Grafische Darstellung eines Workflows in Novell Teaming380
379
380
Aus Administration Guide
Aus Administration Guide
Seite 401
Den Workflow kann man dann mit einem Ordner verbinden, in welchem man den Workflow nutzen möchte381.
Für die Erstellung von komplexeren Workflows wird das zusätzliche und kostenpflichtige
Modul „Advanced Workflow add-on module― 382 benötigt. Hiermit können sogenannte
„Workflow-Fragen― definiert und in Workflows integriert werden. Dies sind Fragen, auf
die ein Benutzer reagieren muss, bevor der nächste Übergang erfolgen kann und der
jeweilige Übergang entsprechend der Antwort reagiert.
Dokumentenunterstützung
In Novell Teaming kann man prinzipiell beliebige Dateien und Dateiformate in einen
Arbeitsbereich oder Ordner hochladen383. Dabei kann der Inhalt, sofern er erkennbar ist,
zusätzlich in HTML umgewandelt werden und kann damit Benutzern zur Verfügung
gestellt werden, die nicht über eine entsprechende Anwendung zum Öffnen der Datei
verfügen. Bei einigen Dateien, wie zum Beispiel Bilddateien, ist dies meist nicht möglich,
da der Inhalt nicht ausgelesen werden kann. Dort wo eine Darstellung in HTML möglich
ist, wird dies auch in der Benutzerschnittstelle entsprechend dargestellt (siehe Abbildung
63).
Abbildung 63 Dokumente im HTML-Format darstellen
Um Dokumente zu bearbeiten, stehen in Novell Teaming zwei Möglichkeiten zur
Verfügung:

Das Dokument auf den Desktop herunterladen, dann bearbeiten und anschließend wieder hochladen.

Für einige Dateitypen wird ein Edit-Schalter zur Verfügung gestellt, über den mit
Hilfe eines kleinen Java Applets die mit dem Dateityp verbundene Anwendung
gestartet wird. Der Zugriff erfolgt dabei über die WebDAV-Funktionalität. Beim
Speichern wird dann eine neue Version des Dokuments im jeweiligen Arbeitsbereich erstellt. Im Browser müssen keine weiteren Aktionen vorgenommen werden.
Um die zweite Funktionalität nutzen zu können, muss die Anwendung, mit der das Dokument bearbeitet werden soll, WebDAV unterstützen. Novell Teaming muss über die
Administration mitgeteilt werden, welche Anwendung dies unterstützt.
381
382
Details werden im Administration Guide zu Novell Teaming beschrieben
Siehe Administration Guide zu Novell Teaming
Seite 402
1.4.2.2
Conferencing Funktionen
Die nachfolgende Tabelle gibt noch mal einen Überblick über die Funktionen von Novell
Conferencing. Ein Teil der Funktionalität wurde schon im Rahmen der Beschreibung der
verschiedenen Komponenten von Novell Conferencing vorgestellt (siehe Kapitel III.B
1.4.1.2).
Hauptfunktion
Telefon- (Sprach)konferenzen
Details
 Unterstützt VOIP
 Full Duplex (mehrere können zur selben
Zeit sprechen)‫‏‬
 Sprachintegration in einer Webkonferenz
Web-Konferenzen
 Verschiedene Rollen (Moderator, Teilnehmer, Zuhörer, etc.)‫‏‬
 Konferenzen können aufgezeichnet werden
 Wiederverwendbare Konferenzeinstellungen
 Applikations sharing
 Whiteboard
 Desktop sharing
 Co-browsing
 Gemeinsames Bearbeiten
 Abfragesystem
 Breakout sessions
 Teilnehmer Audit
Instant Messaging (IM)‫‏‬
 Konversationen


Bidirektional
Gruppen
 Dateitransfer
 Emoticons
 Aufzeichnen von Gesprächen
 Persönliche Historie zu Personen
 Virusschutz
 Systemmonitoring
Tabelle 62: Novell Conferencing Funktionen
1.4.3
Fazit
Die Kollaborationsplattform von Novell ist eine zwar noch nicht ganz ausgereifte, aber
schon sehr umfassende Lösung für die gemeinsame Arbeit in Teams, Arbeitsgruppen
und Projekten. Insbesondere die funktionalen Angebote im Bereich der EchtzeitZusammenarbeit stellen in einzelnen Bereichen eine Besonderheit dar. Leichte Schwächen zeigen sich im Zusammenhang mit der Versionierung von Dokumenten und der
flexiblen Vergabe von Metadaten, was sich wiederum auf die Suchfunktion auswirkt.
Trotz allem muss sich Novell Teaming + Conferencing nicht hinter anderen Lösungen
verstecken. Positiv ist weiterhin zu erwähnen, dass zum einen mit ICEcore eine Open
Seite 403
Source Version zur Verfügung steht, die schon wesentliche Funktionen von Novell Teaming liefert und zum anderen das Produkt zum großen Teil auf Open Source Komponenten aufbaut und überwiegend auf offene Standards setzt.
1.5
Lotus Quickr 8.0
Lotus Quickr wurde von IBM im Juni 2007 erstmalig veröffentlicht384. Lotus Quickr lag
zum Zeitpunkt der Erstellung dieses Kapitels385 in Version 8 vor.
Von Lotus Qickr wird in einer Standardausgabe mit zwei Installationsvarianten, als Services für Lotus Domino oder als Services für WebSphere Portal, vom Hersteller auch als
Java Enterprise Variante bezeichnet, bereitgestellt.
Die Entscheidung, welche der beiden Installationsvarianten zum Einsatz kommen kann
hängt zum einen von den gewünschten Funktionen und zum anderen auch von den vorhandenen Erfahrung und/oder bestehender Infrastruktur ab. Folgende Gründe können
hier ausschlaggebend sein:

Es wird schon Technologie eingesetzt beziehungsweise es gibt schon Erfahrungen mit bestimmten Technologien, wie zum Beispiel Lotus Domino oder
IBM WebSphere).

Es bestehen Präferenzen oder Anforderungen für eines der unterstützten Betriebssysteme.

Es werden bestimmte Funktionalitäten gewünscht oder benötigt, die nur von
einer der beiden Variante bereitgestellt werden.

Das Know-how der IT-Mitarbeiter und/oder der Benutzer präferiert eine der
beiden Varianten.
Hintergrund für das Angebot von zwei Produktvarianten ist laut IBM die Weiterentwicklung beziehungsweise Fortführung bereits bestehender Produktangebote:

Lotus Quickr Services für Domino ist das Nachfolgeprodukt von Lotus Quickplace. Lotus Quickplace Nutzer können im Rahmen ihrer Wartungsverlängerung auf
Quickr migrieren.

Die Java Enterprise Umgebung von WebSphere Portal beinhaltet seit einiger Zeit
unter anderem auch Dokumentenmanagementfunktionen. Die Quickr Services
der Java Variante bauen auf diesen Funktionen auf und erweitern sie um weitere
Teamfunktionen.
Ziel ist es laut Hersteller, beide Varianten dauerhaft mit den gleichen Funktionalitäten nur
für unterschiedliche Plattformen bereitzustellen. Mit Quickr 8.1, welches für das erste
Halbjahr 2008 angekündigt wird, soll ein erster Schritt in diese Richtung unternommen
werden. So soll in Quickr 8.1 unter anderem die heute noch in der Java Variante fehlende Teamkalenderfunktionalität verfügbar sein.
384
385
http://www-03.ibm.com/press/us/en/pressrelease/21756.wss
Stand Februar 2008
Seite 404
Welche der beiden Varianten in Frage kommt, muss jede Organisation für sich beantworten.
Neben der oben erwähnten Standardausgabe soll mit Quickr 8.1 eine „Quickr Entry Edition― zur Verfügung gestellt werden. Diese soll grundlegende Funktionalitäten für den
persönlichen Datei-/Dokumentenaustausch bereitstellen. Zum Beispiel soll es möglich
sein Dokumente in Quickr Bibliotheken hoch- und aus diesen wieder herunterzuladen.
Konnektoren zur Anbindung von Standardanwendungen (siehe auch III.B 1.5.1.2), wie
zum Beispiel Microsoft Office, sollen ebenfalls mitgeliefert werden. Die Quickr Entry Edition soll für Lotus Notes Nutzer im Rahmen der Wartung ohne zusätzliche Lizenzkosten
bereitstehen.
Lotus Quickr ist eine rein proprietäre Lösung, die in vielen Bereichen auf bewährter
Technologie beruht, wie später noch deutlich werden wird.
1.5.1
1.5.1.1
Architektur
Wie bereits erwähnt stehen für Installation von Quickr zwei Varianten zur Verfügung.
Diese basieren in Teilen auch auf sehr unterschiedlicher Technologie, was auch schon
durch die Bezeichnungen der Varianten deutlich wird. Diese technologischen Unterschiede wirken sich ebenso auf die bereitgestellten Funktionalitäten sowie auf die Administration und Konfiguration aus.
Einen Hinweis auf die verwendete Technologie liefern die Vorgaben und Hinweise zu
den Systemvoraussetzungen.
IBM Lotus Quickr 8.x steht je nachdem, ob man die „Services für IBM WebSphere Portal‖ oder die „Services für IBM Lotus Domino‖ verwenden möchte, für verschiedene Betriebssysteme zur Verfügung:


Services für IBM WebSphere® Portal®
o
HP-UX on HP Integrity
o
Linux on x86
o
Windows
Services für IBM Lotus Domino®
o
AIX
o
i5/OS
o
Solaris
o
Windows
Seite 405
Je nach Betriebssystem und Installationsvariante gestalten sich die Systemanforderungen entsprechend unterschiedlich. Diese werden auf den Webseiten von IBM sehr
ausführlich beschrieben386. Nachfolgend wird versucht, an zwei Beispielen die Unterschiede zu verdeutlichen.
Services für IBM WebSphere
Portal
Services für IBM Lotus Domino
Windows
Linux x86
Betriebssystem
Hardwareanforderungen
Red Hat Enterprise Linux (RHEL)
Enterprise Server (ES),
Advanced Server (AS),
Workstation (WS) and Desktop
for x86-32 V4.0 Update 4
 Microsoft Windows 2003
Standard Edition Server Service
Pack 1 and 2 (Microsoft product
site)
 Minimum 4 GB free disk space
for installation for IBM Lotus
Quickr
 RAM - 512 MB or more is
recommended
 CD-ROM drive
 Microsoft Windows 2003
Enterprise Server
 Disk space - 1.5 GB or more is
recommended
 Processor: CPU speeds of late-  Disk swap space - 2 times
model, mid-range to high-end
physical RAM installed
servers are re-commended.
 CD-ROM drive
Pentium 1 GHz or equivalent at
 Processor: CPU speeds of latea minimum.
model, mid-range to high-end
Production environments should
servers are recommended.
consider the Pentium 4
Pentium 1 GHz or equivalent at
processor at 2.5 GHz or higher.
a minimum. Production
environments should consider
the Pentium 4 processor at 2.5
GHz or higher
Lotus Domino Server
-
Lotus Domino 7.0.2 Fix Pack 1
Application Server
WebSphere Application Server
V6.0.2.17 Network Deployment
-
Web Server
 Apache Server 2.0.49, 2.0.52, &
2.0.54
HTTP server included with Lotus
Domino
 IBM HTTP Server 2.0.47.1
 IBM HTTP Server 6.0, 6.0.1, &
6.0.2
 Microsoft Internet Information
Services 6.0
 IBM Lotus Domino (as Web
server 7.0.2, 7.0.1, 6.5.5 & 6.5.4
 Sun Java System Web Server
6.1 SP3
 Sun Java System Web Server
6.0 SP9
386
Diese können auf den Webseiten von IBM eingesehen werden
http://www-1.ibm.com/support/docview.wss?rs=3264&uid=swg27009740
Seite 406
Portal
Windows
Linux x86
Web Browser
 Microsoft Internet Explorer 7.0
for Windows XP
for Windows
SP2 for Windows XP
SP2 (and patches) (Microsoft
product site)
 FireFox V2.0
 Mozilla FireFox V1.7
 Apple Safari 1.2.2 and 1.2.4 on
Mac OS X version 10.4
LDAP-Verzeichnisserver
 IBM Tivoli Directory Server 6.0
 IBM Lotus Domino 7.0.2, 7.0.1,
6.5.5, & 6.5.4
 •Novell eDirectory 8.7.3
 Sun Java System Directory
Server 5.2
 Windows Active Directory 2000
or 2003
and 6.0
 IBM Lotus Domino 7.x & 6.5.x
 Sun ONE System Directory
Server 5.2
 Sun ONE Web Server (was
iPlanet) Enterprize 6.0 SP 4
 Windows Active Directory 2003
 Windows Active Directory
Applilcation Mode (ADAM) 2003
Unterstützte Java Runtime
Environments
Für die Web Content
Management Komponente in
Lotus Quickr (wikis, blogs, lists,
authoring portlet, rich text editor,
list viewer, and html viewer)
Software for collaboration Domino and Extended Products
(optional)
Java Runtime Environments
6.0_01, 5.0_11, 5.0_09, 5.0_06,
1.4.2_12, 1.4.2_10, 1.4.2_08,
1.41_07
Java Runtime Environment
Version 5.0
 IBM Lotus Domino 7.0.2, 7.0.1,
6.5.5, & 6.5.4
IBM Lotus Sametime 7.5 or 7.5.1
 IBM Lotus Sametime 7.5
(WebSphere Portal 6.0.1+) &
7.0
 IBM Lotus Instant Messaging
and Web Conferencing 6.5.1
 IBM Lotus QuickPlace 7.0
 IBM Lotus Team Workplace
6.5.1
External Security Software
 Netegrity SiteMinder 5.5 and 6.0
-
 Multi-Server/LTPA
Software for license
management
IBM Tivoli License Compliance
Manager
Seite 407
-
Portal
Windows
Linux x86
Feeds Support
 Documents component:
supported levels for publish:

Atom: 1.0

RSS: not supported
 Documents component:
supported levels for import:

Atom: 0.3, 1.0

RSS: 0.90, 0.91 Netscape,
0.91 Userland, 0.92, 0.93,
0.94, 1.0, 2.0
 Feed reader component:
supported levels for import:

Atom: 0.3, 1.0

RSS: 0.91, 0.92, 2.0
 Wiki and blog components:
supported levels
Konnektoren

Atom: 1.0

RSS: not supported
 Lotus Quickr connector for
Lotus Notes
-
Sametime
Microsoft Windows Explorer
Microsoft Office
Tabelle 63: Systemkomponenten und –voraussetzungen Lotus Quickr 8
Nach Angaben des Herstellers sind in beiden Installationsvarianten mit Ausnahmen der
Betriebssysteme alle zum Betrieb benötigten Komponenten enthalten. Das heißt, dass
weder WebSphere Portal noch Lotus Domino Server installiert sein müssen und auch
nicht zusätzlich lizenziert werden müssen.
1.5.1.2
Lotus Quickr ist in beiden Installationsvarianten als eine Reihe von Webanwendungen
implementiert und die Benutzer können über Standardbrowser darauf zugreifen und
diese nutzen. Darüber hinaus gibt es einige Zusatztools (z.B. Konnektoren), mit denen
Desktopanwendungen, vorrangig unter Windows, als Clients genutzt werden können.
Die zuvor erwähnten Konnektoren basieren auf Webservice-Technologie. Sie dienen
nicht nur zur Einbindung von Desktopanwendungen, sondern auch als Schnittstelle zu
Anwendungen wie Lotus Sametime, um deren Funktionalitäten in Lotus Quickr zu integrieren.
Derzeit bietet IBM Konnektoren für IBM Lotus Notes, IBM Lotus Sametime, Microsoft
Windows Explorer und Microsoft Office als Bestandteil von Lotus Quickr an. Diese
müssen separat auf den Clients installiert werden. Dieses kann eventuell auch durch die
Benutzer selbst vorgenommen werden, sofern sie die notwendigen Rechte dafür auf
Seite 408
ihren Clients besitzen. Die Konnektoren können dann den Benutzern über den Server
zum herunterladen bereitgestellt werden. Diese Konnektoren sind derzeit nur auf
Windows-Clients einsetzbar. IBM plant die Verfügbarkeit der Konnektoren zu erweitern.
Mit Quickr 8.1 sollen unter anderem Konnektoren für Microsoft Outlook und Lotus
Symphony bereitgestellt werden.
Im Fall der Services für Lotus Domino werden die Webanwendungen über einen Domino
Server zur Verfügung gestellt beziehungsweise auf diesem ausgeführt. Dadurch können
eine ganze Reihe der Dominokomponenten und –dienste durch Quickr genutzt werden.
Hierzu zählen u.a.:

E-Mail

Authentisierung und Zugriffssteuerung

Lotus Domino Off-Line Services

Lotus Domino-Domänensuche (Suche über verschiedene Bereiche und mehrere Server)

Lotus Domino-Verzeichnisservice
Dieser kann optional für die Benutzerverwaltung verwendet werden. Es können aber auch andere LDAP-Verzeichnisdienste hierfür genutzt werden.

(Lotus Notes) Schablonen als Basis für die Erstellung und Bereitstellung von
Webseiten für die unterschiedlichen Arbeitsbereiche.
Entsprechend werden im Fall der Services für WebSphere Portal Komponenten und
Funktionalitäten der Portalsoftware verwendet.
1.5.1.3
Sicherheitsaspekte
Autorisierung
Die Autorisierung erfolgt über die Zuweisung von Rollen, die mit unterschiedlichen Zugriffsrechten ausgestattet sind. Standardrollen sind:

Leser
Darf nur die Inhalte lesen für die er autorisiert wurde.

Autor
Darf in den Teambereichen auf die er Zugriff hat (autorisiert wurde), neue Inhalte
erstellen, verändern und löschen.

Manager
Darf ergänzend zu den Autorenrechten auch neue Benutzer für seine Teambereiche anlegen, ändern und löschen.
Seite 409

Super Administrator
Hat volle Zugriffsrechte.

Entwickler
Darf neue Komponenten hinzufügen, die dann durch andere Benutzer verwendet
werden dürfen.
Weitere Rollen können nach Bedarf definiert und zugewiesen werden. Die Rollenzuweisung kann für einzelne Benutzer und für Benutzergruppen vorgenommen werden. Zugriffsrechte können hiermit für alle Inhaltsstrukturelemente erteilt werden.
Authentisierung und Zugriffssteuerung
Services für Lotus Domino
Die Authentisierung erfolgt standardmäßig über Benutzerkennung und Passwort. Weiterhin kann die Lotus Domino-Einzelanmeldung genutzt werden, um Benutzern die Anmeldung an einem Server zu ermöglichen, ohne dass sie während der Sitzung zur erneuten Anmeldung aufgefordert werden.
Die Zuteilung von Zugriffsrechten erfolgt rollenbasiert und über Benutzergruppen. Die
Zuweisung der Rechte erfolgt bereichsweise, wobei sich die Rechte in der hierarchischen Anordnung der Bereich von Oben nach Unten vererben. Ein Bereichsadministrator kann jedoch die Rechtezuteilung für einen Bereich anpassen.
Sinnvoll ist es, für die Benutzerverwaltung ein LDAP-Verzeichnis zu integrieren. Erst
dadurch können den Benutzern folgende Funktionen zur Verfügung gestellt werden387:

Authentisierung über die Einzelanmeldung

Superuser-Zugriff auf den/die Server

Benutzernamen in Doppelbytezeichensätzen

„Meine Bereiche‖ für die Auflistung persönlicher Bereiche

Integration von Lotus Sametime Funktionen
Weitere Vorteile sind:

Zentrale Haltung der Benutzerdaten

Externe Mitglieder von Arbeitsgruppen erhalten bei zentraler Haltung einen
einheitlichen Namen und ein Kennwort. Bei lokaler Haltung in den Bereichen
können unterschiedliche Namen und Kennworte verwendet werden.

Die lokale Zugehörigkeit zu Bereichen wird weiterhin unterstützt. Das bedeutet, dass ein Benutzer einem oder mehreren Bereichen als Mitglied zugeordnet werden kann.
Die Steuerung des Verzeichnisdienstes kann entweder von Lotus Quickr oder vom Lotus
Domino Server übernommen werden. Dies kann über die Administrationsumgebung kon-
387
Siehe auch im Administratorhandbuch zu Lotus Quickr
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
Seite 410
figuriert werden. Wenn die Steuerung durch den Domino Server übernommen wird, kann
Quickr ein beliebiges Verzeichnis aus der Liste aller vom Domino Server verwendeten
Verzeichnisse nutzen388.
Services für WebSphere Portal389
Standardmäßig erfolgt die Authentisierung über Benutzerkennung und Passwort über
Mechanismen des Portals beziehungsweise des Application Servers. Darüber hinaus
unterstützt Quickr die Authentisierung über SSL-Clientzertifikate sowie die automatische
Anmeldung über eine sogenannte „Anmelde-URL‖. In einer solchen Anmelde-URL sind
Benutzerkennung und Passwort enthalten. Ein solches Anmeldeverfahren ist aus Sicht
der IT-Sicherheit nicht zu empfehlen.
Auch hier besteht die Möglichkeit der Nutzung von Einzelanmeldungen, diesmal aber
nicht unter Zuhilfenahme von Domino-Technologie, sondern mit Hilfe von WebSphere
Technologie.
Genau wie bei der Verwendung der Services für Lotus Domino besteht auch die Möglichkeit der Integration eines Verzeichnisdienstes als Benutzerverzeichnis für eine zentrale Haltung der Benutzerdaten. Andererseits können auch durch Realm-Unterstützung
Benutzer aus verschiedenen Verzeichnisstrukturen zusammengeführt werden und
Quickr als einheitliche Benutzergruppe präsentiert werden.
Alternativ besteht die Möglichkeit, die Benutzer in der Lotus Quickr-Datenbank zu verwalten.
Hinsichtlich der Zugriffssteuerung werden bei der Verwendung der Services für WebSphere Portal vergleichbare Strukturen verwendet, wie bei der Verwendung der Services
für Lotus Domino. Die Zuteilung von Rechten erfolgt rollenbasiert und Ressourcenbezogen. Alle Ressourcen, wie zum Beispiel Web Module und Portlet Anwendungen,
sind hierarchisch angeordnet und die Zugriffrechte werden immer von Oben nach Unten
vererbt. Für jede Ressource können die Zugriffsrechte dann individuell verändert werden. Mit dieser kurzen Darstellung wird lediglich versucht, das grundlegende Prinzip aufzuzeigen. Insgesamt handelt es sich hierbei aber um detailreiche Mechanismen, deren
Darstellung im Administratorhandbuch mehrere Seiten einnimmt390.
Clustering und Replikation
Zur Sicherstellung einer bedarfsgerechten Verfügbarkeit und Performanz bei den Zugriffen auf Lotus Quickr besteht die Möglichkeit, die Funktionen entweder von Lotus Domino-Clustering und –Replikation oder der WebSphere Funktionen für den Aufbau eines
Clusters und die Synchronisierung der Bereichsinhalte zwischen den Servern zu nutzen.
388
389
390
Laut Administratorhandbuch sogar mehr als einen, siehe
Siehe Administratorhandbuch für Lotus Quickr
Siehe Administratorhandbuch für Lotus Quickr
Seite 411
Sonstiges
Problematisch ist, dass wesentliche Funktionalitäten nur genutzt werden können, wenn
aktive Inhalte zugelassen werden. Dies ist aus Sicht der IT-Sicherheit bedenklich. Hier
sollten in jedem Fall die Hinweise des Bundesamt für Sicherheit in der Informationstechnik zur „Sicherheit im Internet―391, zum Umgang mit aktiven Inhalten392 und zu Web 2.0393
berücksichtigt werden.
1.5.2
Funktionalitäten
1.5.2.1
Lotus Quickr Services für Lotus Domino
Die Unterstützung der Zusammenarbeit in Arbeitsgruppen mit Hilfe von Lotus Quickr
erfolgt in definierten Arbeitsbereichen, die sich in unterschiedliche funktionale Bereiche
gliedern.
In diesen Arbeitsbereichen können Arbeitsgruppen mit Hilfe der verschiedenen Funktionen, wie Blogs, Wikis, Tasks sowie Chats und Online-Besprechungen (nur zusammen
mit Lotus Sametime) oder der gemeinsamen Bearbeitung und Nutzung von Dokumenten
zusammenarbeiten. Daneben gibt es eine Reihe weiterer Funktionen, die in der nachfolgenden Tabelle zusammengefasst aufgeführt werden.
In den Arbeitsbereichen können mit Hilfe von Vorlagen, Schablonen und Schemas, sowie bereitgestellten Funktionen und Oberflächen auf relativ einfache Weise neue Bereiche und Schablonen erstellt werden.
Innerhalb der angelegten Arbeitsbereiche können je nach Funktion folgende Aktivitäten
durchgeführt werden:
391
392
393

Erstellen von Dokumenten

Bearbeiten, kopieren, verschieben und löschen von Dokumente

Hinzufügen von Anhängen

Erstellen und Bearbeiten von Einträgen in Kalendern

Verwaltung von Zugriffrechten

Über neue und geänderte Inhalte informieren

Hochladen von Dateien mit den folgenden Formaten, sofern Windows Internet Explorer als Browser eingesetzt wird:
o
HTML- oder HTM-Dateien
o
XML-Dateiformate von MS Office 2007 (*.docx , *.pptx und *.xlsx)
http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/index.htm
Seite 412
o
.doc/.xls/.ppt-Dateien von MS Word 2000/XP/2003, sofern die jeweiligen MS Office Anwendungen installiert sind
o
Bilddateien vom Typ .Gift, .jpg oder .jpeg
Funktionen
Details
Dokumente/Inhalte ein- oder auschecken
Versionierung von Dokumenten
Kategorisierung von Dokumenten (Metadaten)
Verwaltung von Aufgaben (Tasks)
Mit Hilfe von speziellen Aufgabenordnern können Aufgaben verwaltet werden.
Tasks können mit Hilfe von PlaceBot bei Verwendung
der Services für Lotus Domino automatisiert überwacht
werden.
―Meine Bereiche"
Der Ordner "Meine Bereiche" besitzt die Funktion, eine
Liste aller Bereiche eines Benutzers, in denen er Mitglied
ist, zusammenzustellen.
Die einzelnen Bereiche können sich dabei durchaus auf
unterschiedlichen Servern eines Lotus Quickr Verbundes
befinden.
E-Mail
Mit Hilfe der E-Mailfunktion können eingehende E-Mails
bearbeitet werden und es können neue Mitglieder einige
laden werden.
Die E-Mailfunktion kann für jeden Arbeitsbereich eingerichtet werden.
Abonnements
Es können verschiedene Informationsquellen abonniert
werden, wie z.B. RSS-Feeds oder Infobriefe
Portalfunktionen
 Wikis
 Blogs
 Personalisierungsfunktion
Automation/Workflow
 Mit Hilfe von sogenannten Masken können Workflows
realisiert werden
Lotus Quicker stellt einige Standard-Workflows zur
Verfügung394.
 PlaceBots ermöglichen die automatisierte Verfolgung
und Überwachung von Tasks
RSS-Feeds
394
Können in verschiedenen Arbeitsbereichen, wie zum
Beispiel Blogs oder Wikis eingerichtet werden.
Siehe Benutzerhandbuch und Administrationshandbuch
Seite 413
Funktionen
Echtzeit-Kolaboration
Details
Chatfunktion und Präsenzanzeige können durch die
Integration von IBM Lotus Sametime mittels des verfüg395
baren Konnektors und entsprechender Konfiguration
Es besteht dann weiterhin die Möglichkeit
 Online-Besprechungen (Telefonkonferenzen
und e-Meetings) zu planen
 dazu einzuladen
 daran teilzunehmen
hierzu stehen ein Kalender und ein Zeitplanungssystem
zur Verfügung
Suche
Erwähnenswert ist vor allem die Erweiterte Suche, sie
ermöglicht die gezielte Suche nach:
 Ordnern
 Chats
 Räumen
 Inhalten
Bezüglich Inhalten kann wiederum gezielt gesucht werden nach:
 Autoren
 einem bestimmten Erstellungsdatum
 konkreten Textstücken
Die Suche kann auf einen Bereiche begrenzt oder auf
alle Bereiche (auch über mehrere Server) ausgeweitet
werden.
Offline-Bereiche
Ein Bereich kann als Kopie auf dem Client (z.B. Notebook) abgelegt werden und dann offline genutzt werden.
Dieser Bereiche kann mit dem Online-Bereich synchronisert werden.
Tabelle 64: Funktionen von Lotus Quickr Services für Domino
Struktur der Arbeitsbereiche
Für die Zusammenarbeit in Arbeitsgruppen werden in Lotus Quickr Bereiche bereitgestellt. Bereich werden dabei durch Lotus Notes-Datenbanken (NSF-Dateien) realisiert396.
Die Struktur einer Datenbank wird durch entsprechende Schablonen, welche die Formulare und Felder beinhalten, definiert. Für die Anlage von einem Bereich stellt Quickr drei
verschiedene Arten von Schablonen zur Verfügung397:
395
396
397
Mehr zu Schablonen finden Sie unter
http://www.ibm.com/developerworks/lotus/documentation/dominodesigner/
Siehe Benutzerhandbuch, Services für Lotus Domino, Abschnitt: „Einen Bereich erstellen―
Seite 414

Standard
Diese Schablone stellt Funktionen wie beispielsweise Inhaltsverzeichnis, Diskussion, Aufgaben, Kooperation, Mitgliederordner zur Verfügung.

Blog
Diese Schablone ermöglicht die Anzeige von Informationen im Stil eines Tagebuches, sie beinhaltet u.a.:

o
Inline-Kommentare,
o
einen Kalender,
o
eine Suchfunktion,
o
das Einrichten eines RSS-Feeds vor
Wiki
Diese Schablone liefert die Vorlage für einen Bereich, der vor allem auf Kooperation setzt und Interaktion unterstützt. Sie beinhaltet unter anderem auch
das Einrichten eines RSS-Feeds.
Schablonen können verändert werden und es können weitere Schablonen mit dem kostenpflichtigen Lotus Domino Designer erstellt werden 398. Weiterhin gibt es Schablonen,
die von Drittanbietern kostenfrei zur Verfügung gestellt werden399.
Innerhalb eines Bereichs wird zwischen logischen Räumen unterschieden. Jeder Raum
wiederum kann weitere Räume enthalten. Daneben enthält jeder Raum Ordner und
Masken sowie einen Mitgliedsordner.
Ordner werden nach Typen für unterschiedliche Funktionen unterschieden:

Einfache Liste

Diskussion

Sortierte Liste

Präsentation

Ordner mit Kopfzeile
Zu den Listen gehören beispielsweise Mitteilungslisten, Kontaktlisten und Projekttasklisten.
Masken sind Eingabemasken mit hinterlegten Funktionalitäten, wie z.B. die Überprüfung
einer Eingabe oder ein Workflow, der ausgeführt wird. Masken können selbst erstellt
oder als HTML- oder MS Office-Datei importiert werden.
Automation
In Lotus Quickr Services für Lotus Domino werden Workflows mittels Masken realisiert.
Allerdings handelt es sich hierbei um relativ einfache Workflows400. Zu den mitgelieferten
398
399
400
http://www-306.ibm.com/software/lotus/products/dominodesigner/
http://templates.snapps.com/
Zu der Frage, ob und wenn ja, wie Workflows geändert oder selbst erstellt und integriert
werden können, war bisher nicht in Erfahrung zu bringen.
Seite 415
Workflows, die bei der Erstellung oder Änderung einer Maske ausgewählt werden können, sind:

Nur einreichen
Dem Autor wird lediglich eine Möglichkeit zu Veröffentlichung eingeräumt.

Chefredakteur
Das Dokument soll durch ein bestimmtes Mitgliede geprüft und freigegeben
werden.

Freigabe
Das Dokument soll durch mehrere Mitglieder geprüft und freigegeben werden.

Mehrere Bearbeiter
Alle Mitglieder mit Autorzugriffrechten im aktuellen Bereich dürfen jedes mit
der Maske erstellte Element bearbeiten.
Für die automatisierte Verfolgung und Überwachung der Aufgabenerledigung können
sogenannte PlaceBots verwendet werden. Hierbei handelt es sich um Agenten, die Daten innerhalb eines Bereichs verwalten und bearbeiten können. Diese Agenten können
sowohl zeit- als auch eventgesteuert arbeiten. Erstellt werden diese entweder auf Basis
von Java oder mit Lotus-Script.
1.5.2.2
Lotus Quickr Services für Webspere Portal
Genau wie bei der Verwendung der Services für Lotus Domino stehen den Arbeitsgruppen Blogs, Wikis, Tasks sowie Chats und Online-Besprechungen (nur zusammen mit
Lotus Sametime) oder die gemeinsame Bearbeitung und Nutzung von Dokumenten für
die Zusammenarbeit zur Verfügung.
Daneben gibt es eine Reihe weiterer Funktionen, die in der nachfolgenden Tabelle zusammengefasst aufgeführt werden.
Funktionen
Details
 Dokumente/Inhalte ein- oder auschecken
 Versionierung von Dokumenten
 Kategorisierung von Dokumenten (Metadaten)
Verwaltung von Aufgaben (Tasks)
Mit Hilfe von speziellen Aufgabenordnern können Aufgaben verwaltet werden.
"Meine Bereiche"
Der Ordner "Meine Bereiche" besitzt die Funktion, eine
Liste aller Bereiche eines Benutzers, in denen er Mitglied
ist, zusammenzustellen.
Die einzelnen Bereiche können sich dabei durchaus auf
unterschiedlichen Servern eines Lotus Quickr Verbundes
befinden.
Seite 416
Funktionen
E-Mail
Details
Mit Hilfe der E-Mailfunktion können eingehende E-Mails
bearbeitet werden und es können neue Mitglieder einige
laden werden.
Die E-Mailfunktion kann für jeden Arbeitsbereich eingerichtet werden.
Abonnements
Es können verschiedene Informationsquellen abonniert
werden, wie z.B. RSS-Feeds oder Infobriefe
Portalfunktionen
 Wikis
 Blogs
 Personalisierungsfunktion
Automation/Workflow
Workflows werden bei Verwendung der Services für
WebSphere Portal durch die sogenannten Verbundanweisungen realisiert401.
RSS-Feeds
Können in verschiedenen Arbeitsbereichen, wie zum
Beispiel Blogs oder Wikis eingerichtet werden.
Echtzeit-Kolaboration
Chatfunktion und Präsenzanzeige können durch die
Integration von IBM Lotus Sametime mittels des verfügbaren Konnektors und entsprechender Konfiguration402
Es besteht dann weiterhin die Möglichkeit
 Online-Besprechungen (Telefonkonferenzen
und e-Meetings) zu planen
 dazu einzuladen
 daran teilzunehmen
hierzu stehen ein Kalender und ein Zeitplanungssystem
zur Verfügung
Dokumentenbearbeitung
Der Standardeditor für Lotus Quickr ist der ―Richt TextEditor‖.
Um Desktopanwendungen, wie zum Beispiel OfficeAnwendungen, für die Arbeit mit Dokumenten nutzen zu
können, muss das ―Bibliotheks-Browser-Plug-in‖ im
Browser installiert und aktiviert werden. Laut Hersteller
muss dafür ActiveX und das Erstellen von Scripts konfiguriert sein. Als unterstützte Browser werden
 Microsoft Internet Explorer und
 FireFox
angegeben403.
401
402
403
Es werden allerdings keine Angaben zu Versionen gemacht (siehe
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp)
Seite 417
Funktionen
Suche
Details
In Lotus Quickr Services für Portal stellt eine Portalsuchfunktion zur Verfügung. Damit wird die Indexierung von
Informationsquellen erleichtert und die Suche verbessert.
Die Suche wird über das Suchzentrum bereitgestellt. Die
folgenden wichtigen Suchfunktionen können genutzt
werden:
 Filterung der Suchergebnisse auf Basis verschiedener
Attribute
 Verwendung eines oder mehrerer Suchservices
 Verwendung von Suchbereichen zur Eingrenzung der
Suche
 Erstellen von Suchgruppen
 Crawlersuche in mehreren Webseiten, Portalseiten
und Unterdomänen
 Suchfunktionen wie im Internet
 Durchsuchen von Dokumenten
 Sprachunterstützung
 Kategorisierung in einer Taxonomie
 Bearbeitung von Dokumentmetadaten
Tabelle 65: Funktionen von Lotus Quickr Services für WebSphere Portal
Bereichsstrukturen404
Auch hier erfolgt die Strukturierung nach Bereichen, dabei werden beim Anlegen eines
neuen Bereichs folgende Bereichstypen angeboten:
404

Angepasst
Hier werden nur einige Standardkomponenten installiert. Anschließend kann
der Benutzer den Bereich Stück für Stück weiter ausgestalten und die benötigten Komponenten hinzufügen.

Bibliothek
Bibliotheksbereiche sind Sammelstellen für Dokumente und Mediendateien.

Besprechungsbereich
Dieser Typ ist speziell auf Organisations- und Verwaltungsfunktionen für Arbeitsgruppenbesprechungen ausgerichtet. Bestandteil dieses Bereichs ist
auch eine Bibliothek (Unterbereich) für die besprechungsrelevanten Dokumente.

Projektbibliotheksbereich
Dieser Bereich ist speziell auf die Arbeit in Projekten ausgerichtet.
Seite 418

Team-Blog
Dieser Bereichstyp ermöglicht die Darstellung von Informationen in Form eines Tagebuches.

Team-Bereich
Dieser Typ stellt einen Bereich bereit, wo verschiedene Teaminhalte verwaltet
werden können. Bestandteil eines solchen Bereichs sind die weiteren Bereiche Blog und Bibliothek, um einen große Funktionsvielfalt abzubilden.

Team-Wiki
Dieser Typ ist insbesondere auf die Unterstützung von Interaktionen ausgerichtet.
Die Vorlagen für die verschiedenen Bereichstypen basieren auf Schablonen und können
bei Bedarf angepasst oder durch benutzerdefinierte Schablonen ergänzt werden.
Automation
Zur Realisierung von Workflows wird in Lotus Quickr Services für WebSphere Portal das
Konstrukt der Verbundanwendung verwendet. Für die Erstellung von Verbundanwendungen werden Anwendungsschablonen verwendet405. Sie bieten die Möglichkeiten auf
einfache Weise neue Verbundanwendungen zusammenzustellen. Hierfür steht eine Reihe von Schablonen in einer Anwendungsschablonenbibliothek zur Verfügung. Auf Basis
dieser Schablonen können auch neue Schablonen erstellt und in die Bibliothek integriert
werden. Mit Hilfe der Schablonen werden für die Verbundanwendungen diverse Elemente definiert, beispielsweise die Eigenschaften, die Rollen und ihre Parameter. Für einige
der Schablonen können auch Workflows definiert werden. Als Standardworkflow wird der
Freigabeprozess von Dokumenten mitgeliefert, sowohl für eine parallele als auch eine
serielle Freigabe..
1.5.2.3
Verwaltungs- und Administrationswerkzeuge
Für die Administration und Verwaltung einer Quickr-Umgebung bei Verwendung der
Services für Lotus Domino stehen bei einer Installationsvariante als Services für Lotus
Domino zum einen die Werkzeuge von Lotus Quickr und zum anderen die Werkzeuge
von Lotus Domino in Kombination zur Verfügung. Hierzu gehören:

405
Lotus Quickr
o
Das „QPTool‖
Dieses wird über die Serverkonsole mit Befehlen und zugeordneten
Parametern ausgeführt.
o
Die Konfigurationsdatei ―qpconfig.xml‖
o
Die „Site-Verwaltung‖ auf der Homepage des Servers
Hierbei handelt es sich um eine Web-basierte Administrationsschnittstelle, über welche die Verbindung zum Benutzerverzeichnis herges-
Siehe Lotus Quickr Benutzerhandbuch, Services für WebSphere Portal, Verbundanwendungen, http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
Seite 419
tellt, der Zugriff auf den/die Server gesteuert und andere Konfigurationen verwaltet werden können.

Lotus Domino
o
Der Domino Administrator-Client
o
Die Konfiguration über das Domino-Verzeichnis „names.nsf‖
o
Die Konfigurationsdatei notes.ini
Bei der Verwendung der Services für WebSphere Portal werden die Verwaltungswerkzeuge mit dem zu Grunde liegenden WebSphere Portal bereitgestellt beziehungsweise
es können die Werkzeuge verwendet werden, die mit Portal bereitgestellt werden. Hierzu
zählen:
1.5.3

Eine Reihe von Verwaltungsportlets für die Verwaltung der Portalressourcen

Eine XML-Konfigurationsschnittstelle für Stapelverarbeitung von Verwaltungsaufgaben

Eine Skript-basierte Schnittstelle zur Erstellung eigener Verwaltungsskripts,
zum Beispiel für die Automatisierung von Verwaltungsaufgaben.
Fazit
Positiv festzuhalten bleibt, dass mit Lotus Quickr eine Kollaborationssoftware verfügbar
ist, die einen umfangreichen Korb an Funktionen für die Unterstützung der Zusammenarbeit in Teams mitbringt, die weiterhin serverseitig mehr als nur eine Betriebssystemplattform unterstützt und auf bewehrter Technologie des Herstellers aufbaut.
Ob die Tatsache, dass die Software mit ihren beiden Installationsvarianten, einmal als
Services für Lotus Domino und das andere mal als Services für WebSphere Portal, auf
zwei unterschiedlichen (Application)Server-Plattformen aufbaut und genutzt werden
kann, positiv oder negativ zu bewerten ist, muss vorläufig noch unbeantwortet bleiben.
Ungünstig ist, dass der Hersteller hierzu keine prägnanten Hinweise liefern kann, welches die ausschlaggebenden Kriterien für die eine oder die andere Wahl sein sollten. Es
wird auch nicht deutlich, ob und wo es vielleicht wesentliche Unterschiede in den Funktionen gibt. Im Rahmen der hier durchgeführten Betrachtungen konnten nur Indizien aufgedeckt werden, die funktionelle Gründe gegebenenfalls bei den Möglichkeiten der Offline-Nutzung und der Workflowgestaltungs- und –nutzungsmöglichkeiten sehen.
Abschließend bleibt festzuhalten, dass für die Nutzung weiterer Funktionalitäten, wie
zum Beispiel „Echtzeitkommunikation― zusätzliche kostenpflichtige Software des Herstellers, wie Lotus Sametime, beschafft werden muss.
Ungeünstig stellt sich die heute noch bestehende einseitige Ausrichtung und Abhängigkeit auf Windows und Microsoftprodukte sowie -dateiformate im Clientbereich dar. Trotz
der Tatsache, dass es sich bei Lotus Qickr eigentlich um eine Webanwendung handelt,
wird für eine optimierte Nutzung aller Funktionen zusätzliche Software auf Clientseite
benötigt, die heute nur für Windows, Microsoftprodukte, -dateiformate und eigene Produkte verfügbar ist.
Seite 420
C Thema Office / Desktop
1
Im Fokus der nachfolgenden Betrachtung zu den Office-Suiten stehen die StandardAnwendungen von Microsoft Office (kurz MS Office) und OpenOffice.org/StarOffice (kurz
OOo/SO). Eine erneute Betrachtung der Migrationsoptionen mit Blick auf diese
Anwendungsgattung erscheint aufgrund der Veröffentlichung von MS Office 2007 sowie
der neuen Versionen von OpenOffice.org (OpenOffice 2) und Sun (StarOffice 8)
erforderlich.
Alle Office-Produkte haben seit der Veröffentlichung des letzten Migrationsleitfadens
(Version 2.1) insbesondere hinsichtlich der Dateiformate einen erheblichen Wandel vollzogen. So verwendet die aktuelle Office Version von Microsoft ein neues, nun gänzlich
auf XML basierendes (Standard-)Dateiformat. Das von OpenOffice.org beziehungsweise
StarOffice genutzte Standarddateiformat ist nach kleinen Veränderungen nun ein international normierter Standard. Dieser Wandel soll in einer neuen aktualisierten Fassung
betrachtet werden um u.a. zu prüfen, welche Änderungen es gab, wie diese sich auf die
Arbeit mit den Office-Suiten auswirken und welche neuen Erkenntnisse sich für die Migrationsentscheidungen ergeben.
Im nachfolgenden Abschnitt werden die beiden Office-Suiten OpenOffice.org 2 und
StarOffice 8 und Microsoft Office 2007 einander gegenübergestellt. Die Zusammenfassung von OOo und SO ist darin begründet, dass sich beide Suiten funktional nur gering
voneinander unterscheiden. Der Vollständigkeit halber werden die Vorgängerprodukte
(MS Office 11; SO 7/OOo 1) und deren wesentliche Unterschiede zum Nachfolger dargestellt.
1.1
OpenOffice.org 2 und 1 / StarOffice8 und 7
Die Entwicklung der Basistechnologie der beiden Office-Suiten erfolgt auf OpenOffice.org. Im Jahre 2000 hat Sun Microsystems den Quelltext des damaligen OfficePakets StarOffice 5.2 in das Open Source Projekt OpenOffice.org überführt. Das OpenOffice.org Projekt steht unter der Lizenz LGPL406 (Lesser GNU Public License), welche
es ermöglicht, kostenpflichtige Produkte aus OpenOffice.org abzuleiten. Andererseits
garantiert sie durch die Wiederverwendung der relevanten Komponenten von OpenOffice.org, dass die Spezifikationen des API und des ODF-Dateiformates für alle Derivate
einheitlich sind.
Für StarOffice entwickelt die Firma Sun zusätzliche Komponenten und schnürt ein Produktpaket aus professioneller Qualitätssicherung, umfangreicher Dokumentation, Support und Schulungsangeboten.
406
Alle OpenOffice.org-Versionen vor 2.0 wurden parallel dazu unter der Sun Industry Standard Source License (SISSL) veröffentlicht. Weitere Details dazu finden sich unter
http://www.openoffice.org/FAQs/license-change.html, sowie in Abschnitt 3.13.5.1 der Version 2.1 des Migrationsleitfadens.
Seite 421
Einige der Sun-Komponenten sind:

Migrations-Tools,

Zusätzliche Vorlagen und Grafiken,

TrueType Fonts, welche an die Fonts von Microsoft angelehnt sind,

Eine eigene Rechtschreibprüfung und Thesauri, wobei OpenOffice.org als Standard-Spellchecker MySpell (LGPL) beziehungsweise die verbesserte Variante
Hunspell seit der Version 2.02. verwendet,

Die Datenbank Adabas-D der Firma Software AG.
Des Weiteren liefert Sun Bug-Patches oder Servicepacks für die jeweiligen Produktversionen. So gibt es derzeit alle drei Monate ein StarOffice Servicepack für jede Version 407,
das verbesserte Sicherheitsaspekte, Korrekturen für Programmfehler oder Verbesserungen der Importfilter beinhaltet. OpenOffice.org hingegen enthält diese Komponenten
nur in der jeweils allerneuesten Version und man muss sich das gesamte Produktpaket
herunterladen.
Die StarOffice Suite ist im Gegensatz zu der freien OpenOffice.org Suite kostenpflichtig,
wobei Sun Microsystems erstere kostenfrei an Schüler, Studenten und akademische
Einrichtungen abgibt. Darüber hinaus ist StarOffice 8 seit August 2007 als Bestandteil
des kostenlosen Google Packs408 erhältlich.
1.1.1
OpenOffice.org 2.x / StarOffice 8
Die Versionsfamilie 2.x ist die aktuelle Version der freien OpenOffice,org Office-Suite,
welche nach ca. zweijähriger Entwicklung erstmals im Oktober 2005 veröffentlicht wurde
und die Vorgängerversionsfamilie 1.1.x ablöst. Fast zeitgleich mit dem Release der
neuen Version wurde noch eine Version 1.1.5 veröffentlicht, welche einen Importfilter für
das neue Dokumentenformat ODF der Nachfolgerversionsfamilie beinhaltete.
OpenOffice.org ist unter Microsoft Windows, Linux, Mac OSX, Solaris, FreeBSD und
anderen Unix-Derivaten lauffähig und wird unentgeltlich unter der LGPL-Lizenz vertrieben.
StarOffice 8 basiert auf den Quellen von OpenOffice.org 2.x und enthält, wie erwähnt,
diverse Erweiterungen, die Sun Microsystems beisteuert. Es existieren Installationspakete für Microsoft Windows, Linux und Solaris.
Zentrale Neuerungen gegenüber den älteren Versionen OpenOffice.org 1.1.x beziehungsweise StarOffice 7 sind ein eigenes Datenbankmodul (Base), ferner die Verwendung des OpenDocument Formates (ODF) als Standard-Dateiformat, welches von OASIS auf Grundlage des alten OpenOffice.org-Dateiformats spezifiziert und im Jahr 2006
als internationale Norm veröffentlicht wurde (siehe dazu ISO/IEC 26300) sowie eine verbesserte Unterstützung von MS-Office-Dokumenten.
407
408
Die aktuellen Service Packs sind seit Oktober 2007 für StarOffice 6 (Service Pack 8), StarOffice 7 (Service Pack 11) und StarOffice 8 (Service Pack 8) erhältlich.
Siehe dazu http://pack.google.com/.
Seite 422
Weitere Neuerungen finden sich im Bereich der Benutzersteuerung, den weiterentwickelten Import- und Exportfiltern sowie der Unterstützung digitaler Signaturen, die erstmal in
OOo integriert wurde. Die Benutzeroberfläche wurde teilweise geändert, um der von MS
Office 2003 näher zu kommen und dadurch den Benutzern anderer Office Suiten den
Umstieg zu erleichtern.
1.1.1.1
Bestandteile und Funktionalitäten
Die Office-Suiten beinhalten alle wesentlichen Einzelanwendungen, die von anderen
Office-Paketen bekannt sind. Auf eine Auflistung aller Funktionalitäten der nachfolgend
angeführten Office Komponenten wird an dieser Stelle verzichtet. Vor allem sollen im
Wesentlichen nur die Kernanwendungen Textverarbeitung, Tabellenkalkulation und
Präsentationswerkzeug genauer betrachtet werden. Dies sind die Anwendungen, die in
fast allen Office-Suiten verfügbar sind. Alle anderen Anwendungen variieren zum Teil,
müssen anderen Themen, wie zum Beispiel den Datenbanken zugeordnet werden oder
können auch als Einzelanwendung gesehen werden. Bei den Office Anwendungen
handelt es sich im Einzelnen um:
Writer (Textverarbeitung)
Bei Writer handelt es sich um die Textverarbeitungskomponente der Office-Suiten. Das
Programm unterstützt alle Funktionen einer modernen Textverarbeitung und orientiert
sich dabei an den von Microsoft Word angeboten Funktionalitäten. Zur besseren Bearbeitung umfangreicher Schriften können einzelne Textdokumente (.odt) nachträglich zu
einem gemeinsamen Globaldokument (.odm) zusammengefügt werden. Besonders hilfreich ist in diesem Zusammenhang der sogenannte Navigator, der verschiedene Überblicksansichten und Gliederungen bietet und somit das Auffinden bestimmter Informationen und die Orientierung in langen Dokumenten erleichtert.
Formatvorlagen können für einzelne Zeichen, Absätze, Rahmen, Listen, Kapitel und
Seiten eingerichtet werden. Innerhalb der Texte können verschiedene Verzeichnisse,
wie Inhalts-, Stichwort-, Abbildungs-, Literatur-, Tabellen-, Objekt- und Literaturverzeichnisse erzeugt und angepasst werden. Über Live-Hyperlinks und Textmarken
kann direkt zu Textstellen gesprungen werden. Für das Schreiben wissenschaftlicher
Arbeiten kann der Anwender zudem auf einen Formeleditor und eine Literaturdatenbank
zurückgreifen. Der Formeleditor besitzt eine Vielzahl von kategorisierten Symbolen zur
Darstellung von Mengenoperationen, Relationen, Funktionen, Operatoren und Attributen.
Die Literaturdatenbank kann für die automatische Generierung eines Literaturverzeichnisses genutzt werden. Dazu trägt der Anwender seine Quellen mittels einer Maske
in eine Tabelle ein und kann sie später als Literaturverzeichniseinträge in das Dokument
einfügen.
Seite 423
Abbildung 64: Der Navigator in OpenOffice.org Writer
Calc (Tabellenkalkulation)
Calc ist eine Tabellenkalkulation, mit der sich Daten in Tabellenform darstellen und
bearbeiten lassen. Diese können manuell oder unter Verwendung einer Datenquelle
eingefügt werden. In OpenOffice.org angemeldete Datenquellen lassen sich im zuletzt
betrachteten Fall mittels einer Funktionstaste einblenden und die darin enthalten Daten
per Drag and Drop in die Tabellenblätter übernehmen. Die Rohdaten verschiedener
Datenquellen können so gesammelt und weiter verarbeitet werden, wobei die Möglichkeit besteht, „natürlichsprachige Formeln― wie zum Beispiel =´Stückzahl´*´Preis´ zu
verwenden. Bestimmte Datenbereiche können ein- oder ausgeblendet werden. Ein
„Datenpilot" hilft bei der Analyse von Zahlenmaterial. Es besteht die Möglichkeit, in
Berechnungen, die aus mehreren Faktoren bestehen, die Auswirkungen von Änderungen einzelner Faktoren zu beobachten. Außerdem existieren zur Verwaltung umfangreicher Tabellen verschiedene vordefinierte Szenarien, bei denen der Anwender auf die
Hilfe diverser Assistenten zurückgreifen kann
Zellenformatierungen und Tabellendarstellung können den Bedürfnissen angepasst oder
mittels integrierten Vorlagen formatiert werden. Rechenfunktionen und individuelle Formeln lassen sich vom Anwender direkt erstellen oder anpassen. Im Gegensatz zur Vorgängerversion können Tabellenblätter nun 65536 statt bisher 32000 Zeilen enthalten,
wodurch insbesondere die Kompatibilität zu Microsoft Excel verbessert wird.
Abbildung 65: Natürlichsprachige Formeln in OpenOffice.org Calc
Seite 424
Impress (Präsentation)
Impress ist das Präsentationswerkzeug der OpenOffice.org Office Suite und kann als
Pendant zu Microsoft PowerPoint verstanden werden. Mit diesem Tool können grafische
Darstellungen, Animationen und Foliensätze erstellt und bearbeitet werden. Die Präsentationen lassen sich dabei mit Diagrammen, Zeichenobjekten, Text, Multimedia- und
anderen Elementen versehen. Außerdem stehen Vorlagen zur Erstellung professioneller
Dias zur Verfügung, denen dynamische Effekte, einschließlich Animationen und Übergangseffekte zugeordnet werden können. Die Anpassung der Gestaltung ganzer Präsentationen wird durch Masterfolien vereinfacht. Hier lassen sich wiederkehrende Elemente wie Grafiken, Hintergrundfarben, Kopf- und Fußzeile oder einfacher Text einfügen, die dann für alle Folien zur Verfügung stehen. Das Speichern der Dokumente ist in
verschiedenen OpenOffice.org- und StarOffice-Formaten sowie als Microsoft PowerPoint
Präsentation oder Vorlage möglich. Es besteht darüber hinaus die Möglichkeit des Exports nach Flash, HTML oder XHTML sowie in unterschiedliche Grafikformate, beispielsweise PNG, JPG, GIF und dem Format für skalierbare Vektorgraphiken SVG.
Gleich nach dem Start der Anwendung wird dem Nutzer ein Assistent für die Präsentationserstellung zur Seite gestellt, der auch während des Arbeitens aufgerufen werden
kann. Die Ansicht kann während des Bearbeitens geändert und mittels einer Vorschaufunktion können Effekte und Animationen angepasst werden. Insgesamt hat Impress seit
der Version 2.0 eine neue Anwendungsoberfläche erhalten, die sich stärker an Microsoft
PowerPoint anlehnt und damit gerade für Umsteiger die Arbeit erleichtert
Weiter Anwendungen

Draw (Grafik)
Draw ist ein vektorbasiertes Grafikprogramm, in dem sich 2D- sow

Migrationsleitfaden - IT-Beauftragter der Bundesregierung

Transcription

Similar documents

Migrationsleitfaden Version 2.1

Migrationsleitfaden - Uni

cad/pdm migration

Single-Sign-On und weiter

Migrationsleitfaden - Uni

Migrationsleitfaden 4.0 - IT-Beauftragter der Bundesregierung

National Oilwell Varco

Evolution webbasierter Groupware – eine

Migrationspfade für OWB-Projekte