Migrationsleitfaden Version 3.0

Leitfaden für die
Migration von Software
Publikation des Bundesministerium des Innern
April 2008
Migrationsleitfaden
Version 3.0

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 IT-
Systemlandschaften 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
• In welchem
Umfeld habe
ich ein
Problem?
• Zu welchem
Thema gehört
mein Problem?
• Welche
Produkte sind
betroffen?
• Welcher
Migrationspfad
hilft mir?
• Was muss ich
sonst noch
beachten?
Modul
Themen
Produkte /
Technologien
Migrationspfade
Bezüge
Abbildung 1: Struktur des Migrationsleitfaden
Seite 6
Beispiel:
Migration DBMS
• Infrastruktur
• Datenbanken
• MySQL
• PostgreSQL
• SQL-Server
• z.B. SQL-Server
nach
PostgreSQL
• z.B. Datenquellen
in
Office-Anwendungen
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

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 Star-
Office 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 IT-
Landschaft 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 IT-
Landschaft 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 Informationsbereiche 1 :
� DOMEA- Konzept 2 in der Version 2.1
� E-Gouvernement 2.0 – Das Programm des Bundes
� EVB-IT 3 Vertragstypen
� Migrationsleitfaden 2.1
� Leitfaden plattformunabhängige Fachanwendungen 1.0
� SAGA 4 4.0
� IT-Architekturkonzept für die Bundesverwaltung 1.0
� UfAB 5 IV Version 1.0
� V-Modell XT 6 Release 1.2.1
� WiBe 7 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
www.kbst.bund.de
2
DOMEA - Dokumenten-Management und elektronische Archivierung (in der öffentlichen
Verwaltung)
3
EVB-IT - Ergänzenden Vertragsbedingungen für die Beschaffung von IT-Leistungen
4
SAGA - Standards und Architekturen für E-Government-Anwendungen
5
UfAB - Unterlage für die Ausschreibung und Bewertung von IT-Leistungen
6
V-Modell XT - Vorgehensmodell zum Planen und Durchführen von Projekten - XT steht für
„extreme tailoring―
7
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
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
B 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 Vergleich der Migration zu proprietärer Software und zu OSS ..........................55
6 Patentrecht .............................................................................................................57
6.1 Einleitung .........................................................................................................57
6.2 Entgegenstehende Patentrechte Dritter bei Nutzung von OSS .........................58
6.3 Vergleich der Migration zu proprietärer Software und zu OSS ..........................59
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 Vergleich der Migration zu proprietärer Software und zu OSS ..........................66
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 Vergleich der Migration zu proprietärer Software und zu OSS ..........................71
9 Fazit ........................................................................................................................72
C 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 Fazit ...................................................................................................................... 135
D 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 Migrationspfade .................................................................................................... 169
2.1 Die ablösende Migration proprietärer und offener Datenbank-Systeme .......... 172
2.2 Fortführende Migration von Datenbank-Systemen .......................................... 175
B Thema Webserver ......................................................................................... 176
1 Produkte / Technologien ....................................................................................... 176
1.1 Apache HTTP Server ..................................................................................... 176
1.2 Microsoft Internet Information Services (IIS) ................................................... 180
2 Migrationspfade .................................................................................................... 183
2.1 Die ablösende Migration proprietärer und offener Webserver ......................... 184
2.2 Fortführung der Produktlinie von Webservern................................................. 186
3 Bezüge ................................................................................................................. 186
3.1 Dateiablage .................................................................................................... 186
3.2 Netzwerkdienste ............................................................................................. 187
3.3 Authentifizierung ............................................................................................. 187
3.4 Anwendungen ................................................................................................ 187
C Thema Authentisierungs- und Verzeichnisdienste .................................... 189
1 Produkte / Technologien ....................................................................................... 190
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 Migrationspfade .................................................................................................... 214
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 Bezüge ................................................................................................................. 223
3.1 Grundlegende Überlegungen ......................................................................... 223
3.2 Verzeichnisdienst ........................................................................................... 223
D Thema Netzwerkdienste ............................................................................... 225
1 Produkte / Technologien ....................................................................................... 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 Migrationspfade .................................................................................................... 236
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 Bezüge ................................................................................................................. 240
E Thema Dateiablage ....................................................................................... 241
1 Produkte / Technologien ....................................................................................... 241
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 Migrationspfade .................................................................................................... 263
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 Authentifizierungsdienst ................................................................................. 269
F Thema Druckdienste ..................................................................................... 270
1 Produkte / Technologien ....................................................................................... 270
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 Migrationspfade .................................................................................................... 291
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 Migration von Windows NT4/2000 Print Services nach Windows 2003 Print
Services ......................................................................................................... 293
3 Bezüge ................................................................................................................. 293
3.1 Systemmanagement und -überwachung ........................................................ 293
3.2 Authentifizierung und Verzeichnisdienste ....................................................... 294
3.3 Netzwerkdienste ............................................................................................. 294
G Thema System-Überwachungs- und -Management-Dienste ..................... 295
1 Produkte / Technologien ....................................................................................... 295
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 Migrationspfade .................................................................................................... 306
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 Netzwerkdienste ............................................................................................. 309
3.2 Webserver ...................................................................................................... 309
III. Modul Anwendungen ................................................................... 310
A Thema Messaging und Groupware .............................................................. 310
1 Produkte / Technologien ....................................................................................... 310
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 Migrationspfade .................................................................................................... 342
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 Bezüge ................................................................................................................. 353
3.1 Webserver und Netzwerkdienste .................................................................... 353
3.2 Authentisierungs- und Verzeichnisdienste ...................................................... 353
3.3 Backend-Integration ....................................................................................... 353
B Thema Teaming-/Workgroup Software........................................................ 354
1 Produkte / Technologien ....................................................................................... 354
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
C Thema Office / Desktop ................................................................................ 423
1 Produkte / Technologien ....................................................................................... 423
1.1 OpenOffice.org 2 und 1 / StarOffice8 und 7 .................................................... 423
1.2 Microsoft Office 2007/2003/2002/97 ............................................................... 435
2 Migrationspfade .................................................................................................... 451
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 Teaming-/Workgroup Software ....................................................................... 472
D 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 Migrationspfade .................................................................................................... 483
2.1 Migration einer Anwendung auf Basis .NET nach J2EE ................................. 483
E Thema Terminal-Dienste und Client-Konzepte ........................................... 489
1 Produkte / Technologien ....................................................................................... 493
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 Migrationspfade .................................................................................................... 500
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 Netzwerkdienste ............................................................................................. 509
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 OSS-
Entwickler 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 SAGA 10 definiert sind. Diese Mindest-
8 siehe http://ec.europa.eu/idabc/en/document/3761/5583
9 siehe http://www.kbst.bund.de
10 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 Optimierungs- und
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" zusammenge-
fasst.
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 Softwareverteilungs-
oder 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 Identity-
und 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.
� Schließlich verwenden die einzelnen Komponenten die gleichen Installations-
und Konfigurationsmethoden (wie zum Beispiel die Windows Registry und darauf
aufbauende Werkzeuge), sodass während der Installation eine aufeinander abgestimmte
Konfiguration sichergestellt werden kann.
3.2 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 Vor-
und 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 Kom-
Seite 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 betreib-
oder 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 Administratoren-
als 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 IT-
Infrastruktur 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
Aufeinander abgestimmte Komponenten
(„Baukastenprinzip―)
Ein zentraler Lieferant / Hersteller /
Ansprechpartner für alle Komponenten
Geringerer Aufwand bei Konzeption
und Implementierung
Gute Unterstützung für die Aktualisierung
aller Komponenten als Gesamtsystem
Seite 32
Integration Standardisierung
direkter Vorteil begünstigend
direkter Vorteil begünstigend
direkter Vorteil begünstigend
direkter Vorteil begünstigend
Einfach supportbar direkter Vorteil begünstigend
Geringerer Testaufwand direkter Vorteil begünstigend
Know-how am Markt potenziell leichter
verfügbar
Vereinfachung der Arbeitsprozesse
von Anwendern und Administratoren
Flexibilität beim Tausch von Komponenten
gegen Komponenten anderer
Hersteller
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
begünstigend direkter Vorteil
direkter Vorteil begünstigend
nachteilig
(mit zunehmender Integrationstiefe)
nachteilig
(mit zunehmender Integrationstiefe)
nachteilig
(mit zunehmender Integrationstiefe)
Tabelle 1: Auswirkungen von Integration und Standardisierung
auf ausgewählte Ziele einer Behörde
direkter Vorteil
direkter Vorteil
direkter Vorteil
Die Tabelle zeigt, dass es eine Reihe positiver, kostensenkender Eigenschaften von IT-
Infrastrukturkomponenten gibt, die durch Integration direkt gefördert werden, interessanterweise
werden alle diese Eigenschaften gleichzeitig durch Standardisierung gefördert.

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-of-
Administration― 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 Manager 12 und Systems Management Server
13 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 Office-
Paket 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 System Center Operations Manager 2007 ist die aktuelle Version
13 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, IP-
Managementdienste (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 Linux-
Serverdistributionen 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 Instant-
Messaging-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. Zen-
Works 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 Linux-
Distribution 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 UCS-
Managementsystem 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 Identity-
und 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-Listener-
Mechanismus. 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
Seite 37
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.
Dateidienste CIFS, NFS NCP, NFS, CIFS
(Samba)
Druckdienste Windows Druckdienste
E-Mail- und Kalenderdienste
Kerberos, NTLMv2
(Samba), PAM, u.a.
NFS, CIFS (Samba)
iPrint CUPS (Common Unix
Print System)
Exchange 2007 Groupwise 7 Kolab 2 für UCS
IP-Management Active Directory ZenWorks OpenLDAP, Univention
Directory Manager,
ISC DHCPD,
ISC DNS

Komponente Microsoft Novell Univention
Software- und Update-
Management
Client-Betriebssystem Windows XP / Windows
Vista
Active Directory / MSI ZenWorks OpenLDAP, Univention
Directory Manager
APT, OPSI für
UCS
Seite 38
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:

Kriterium Microsoft Novell Univention
Welcher Integrationsgrad
besteht?
Ist die technische Realisierung
der Integration öffentlich
dokumentiert?
Ist der Einsatz alternativer
Komponenten technisch
möglich?
Verwendet die Lösung
ausschließlich Standardprotokolle
und Schnittstellen?
Handelt es sich bei den
Integrationskomponenten
um Open Source Software,
deren Quellcode
einsehbar und veränderbar
ist?
Werden proprietäre, nicht
offengelegte oder lizenzpflichtige
Protokolle verwendet?
Sind die verwendeten Protokolle
offen und frei zugänglich
dokumentiert?
3.8 Fazit
hoch mittel bis hoch leicht bis mittel
teilweise teilweise teilweise / durch
Quellcode vollständig
teilweise teilweise vollständig
nein nein ja
nein teilweise ja
teilweise teilweise nein
teilweise teilweise ja
Tabelle 3: Beurteilung des Integrationsgrades der Beispiellösungen
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ätigt 14 . Auch hat der Gesetzgeber mittlerweile vier Sondervorschriften
zugunsten des OSS-Lizenzmodells in das Urheberrechtsgesetz aufgenommen
15 , 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 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).
15 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:
� Vertragsrecht
� Urheber- und Patentrecht
� Haftung und Gewährleistung
� Vergaberecht
2 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ührt 16 . 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 Vertragsrecht
4.1 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; OSS-
Lizenzen 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 2 17 , GPL Version 3 18 und Lesser GPL
Version 3 19 ) 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 Lizenzen 20 . 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
18 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
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. BVB 22 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 Standard-
Open 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
Eine aktuelle Übersicht über den Meinungsstand findet sich bei Redeker, IT-Recht (4. Aufl.
2007), S. 91 f.
22
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üssten 23 .
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
Seite 47
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.

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 verzichtet 24 . 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.2004 25 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 Rechte 26 . 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
Vgl. § 151 BGB.
Vgl. Landgericht München, Urteil vom 19.05.2004, siehe oben Fn. ■
26
Vgl. § 69b UrhG.
27
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 OSS-
Lizenzen 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
Vertrag mit
Zwischenhändler
Vertrag mit
Rechtsinhabern
Rechtsfrage Anwendbares Recht
Zustandekommen des
Vertrags
Auslegung
Rechtsfolgen bei Nichtleistung
Vertragliche Haftung und
Gewährleistung
Zustandekommen des
Vertrags
Auslegung
Rechtsfolgen bei entgegenstehenden
Rechten Dritter
Schutzfähigkeit des Werks
bzw. der Erfindung
Bestehen von Urheber- und
Patentrechten
Rechtsinhaberschaft
Übertragbarkeit
Lizenzierbarkeit
Tabelle 6: Anwendbares Recht
Seite 49
Recht des Landes, in dem
Zwischenhändler seinen Sitz
hat
Recht des Landes, in dem der
Rechtsinhaber seinen Sitz hat
Recht des Landes, für das
Schutz beansprucht wird (= in
dem urheber- bzw. patentrechtlich
relevante Handlungen
stattgefunden haben)
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.

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
Vgl. z.B. die hierauf zugeschnittenen EVB-IT Überlassung Typ A, abrufbar unter
http//www.kbst.bund.de/.
30
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.
31
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 Urheberrecht
5.1 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 Definitionen 36 und
der Free Software Definition 37 , 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 Vgl. etwa Spindler, Rechtsfragen bei Open Source (2004), S. 75 ff.
34 Vgl. Spindler, Rechtsfragen bei Open Source (2004), S. 91 ff.
35 Vgl. hierzu exemplarisch Teupen, "Copyleft" im deutschen Urheberrecht (2007), S. 192.
36 Abrufbar unter http://opensource.org/docs/osd.
37 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
Vgl. insbesondere Spindler, a.a.O., 82.
39
Vgl. insbesondere Spindler, a.a.O., 82.
40
Vgl. Metzger, in: Hilty/Peukert, Interessenausgleich im Urheberrecht (2004), 253, 260 mit
weiteren Nachweisen.
41
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 IBM 42 . 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
Siehe den Text der 06.03.2003 in Salt Lake City erhobenen Klage unter
http://www.sco.com/scoip/lawsuits/ibm/
43
Siehe zum Prozessverlauf die zahlreichen unter http://www.groklaw.net abrufbaren Prozessdokumente.
44
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 Vergleich der Migration zu proprietärer Software und zu OSS
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.
Urheberrechtliche Zulässigkeit
einzelner Lizenzklauseln
Migration zu OSS Migration zu proprietärer
Software
Aus der Sicht der Nutzer keine
praktisch relevanten Rechtsprobleme
Seite 56
Bei entsprechender Vertragsgestaltung
keine praktisch
relevanten Rechtsprobleme
45 Siehe hierzu Bundesgerichtshof, Urteil vom 24.10.2002, Neue Juristische Wochenschrift
2003, 2014.

Umfang der Rechtseinräumungen
Risiko entgegenstehender
Rechte Dritter
6 Patentrecht
6.1 Einleitung
Migration zu OSS Migration zu proprietärer
Software
Sehr weitgehend Oft restriktiv
Erhöht bei unklarer Herkunft,
geringer bei seriösen Projekten
Tabelle 7 Urheberrechtliche Fragen:
Seite 57
Erhöht bei unklarer Herkunft,
geringer bei seriösen Anbietern
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 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.
47 Siehe http://www.muenchen.de/limux.

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 Hard-
und 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 Vgl. das Kurzgutachten von Sedlmaier/Gigerich vom 10.09.2004, abrufbar unter
http://www.jurpc.de/aufsatz/20050010.htm
49 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 Vergleich der Migration zu proprietärer Software und zu OSS
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 Haftung und Gewährleistung
7.1 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/Linux-
Standarddistribution 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 Haftung 50 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
Unentgeltlicher
Erwerb
Rechtsmangel
Schäden an sonstigen Rechtsgütern
Sachmangel
Rechtsmangel
Schäden an sonstigen Rechtsgütern
Seite 62
Nacherfüllung
Bei Fehlschlag der Nacherfüllung:
� Minderung
� Rücktritt
Bei Verschulden Schadensersatz
Bei Verschulden Schadensersatz
Bei Arglist Schadensersatz
Bei grober Fahrlässigkeit / Vorsatz
Schadensersatz
Tabelle 8: Vertragliche Ansprüche auf Haftung und Gewährleistung gegen den Zwischenhändler

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 Vgl. z.B. Ziffern 11 und 12 GPL Version 2, Ziffern 15 und 16 GPL Version 3.
52 Dazu ausführlich Jaeger/Metzger, Open Source Software: Rechtliche Rahmenbedingungen
der Freien Software (2. Aufl. 2006), Rz. 219 ff.
53 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 Vgl. § 1 Abs. 1 ProdHaftG.
55 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 Vergleich der Migration zu proprietärer Software und zu OSS
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 Vergaberecht
8.1 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 erfolgen 56 .
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 Vergabeverordnung 57 , 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 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.
57 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 "Linux-
Server" 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
restriktiv 61 . 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 So insb. Heckmann, a.a.O., 402.
60 Vgl. § 99 GWB: "Öffentliche Aufträge sind entgeltliche Verträge [...].
61 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 hat 62 , 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 Preis-
Leistungs-Vergleichs berücksichtigt werden. Die technische und rechtliche
62 Vgl. den dem Beschluss zugrunde liegenden Antrag der Regierungsfraktionen, Bundes-
tags-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 Vergleich der Migration zu proprietärer Software und zu OSS
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 OSS-
Programme 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.1 65 , der IT-Updates 66 sowie des Migrationsleitfadens
1.0 67 .
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 Im Einzelnen sind darunter folgende Komponenten zu verstehen: Serverdienste, Standardsoftware,
Bürokommunikation, Dokumente und Makros; siehe auch Kapitel I.C 4.
65 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.
66 Siehe hierzu Hinweise und Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen
bei IT-Update- beziehungsweise Umstellungsvorhaben auf Grundlage der IT-WiBe-
97, Schriftenreihe der KBSt, ISSN 0179-7263´, Brief 04/2000, November 2000.
67 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äferiert 69 .
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:
� 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,
68 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.
69 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 (siehe
Nr. 2.2, VV zu § 7 BHO)."
Diese Anforderungen stellen prinzipiell den Rahmen und die Struktur für die Wirtschaftlichkeitsbetrachtungen
dar.
Wirtschaftlichkeit
(Kosten/ Nutzen)
ermitteln
Personaleinsatz
planen
Projektplan mit
Maßnahmen
erstellen
Alternativen
vergleichen
Kostenansätze
für Lösungen
erheben
Seite 76
Ziele / Rahmen-
Bedingungen
identifizieren
Technische
Lösungsmöglichkeiten
eruieren
Vorgaben /
Annahmen
definieren
Modell der
Wirtschaftlichkeitsbetrachtung
abstimmen
Ausgangssituation
erheben
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.

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 IT-
Maß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:
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)
70 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 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)
71 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)
Einsatzphase
(Einführung und Betrieb, Funktionen im
Netzwerk bereitstellen, Installationen in
der Fläche)
3.3.2 Personalbedarf für die Migration
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
Tabelle 9: Migrationsphasen
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 Tabellen 72 geben beispielhaft einen Überblick
über die prozentuale Verteilung der Personentage- und der Personalkosten-Planung 73 .
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
Da die Tabellen keine Nachkommastellen enthalten, können sich in Einzelfällen Rundungsdifferenzen
ergeben.
73
Die hier abgebildeten Daten stehen beispielhaft für eine größere Behörde.
Seite 80

Phase Nr Beschreibung
Seite 81
Variante 1 Variante 2 Variante 3
intern extern intern extern intern extern
Su Kosten Gesamt € 391.972 329.944 385.552
Su Kosten intern/extern € 84.972 307.000 72.944 257.000 98.552 287.000
Su Personentage (PT) Gesamt 526,0 445,0 541,0
Su Personentage (PT) intern/extern 219,0 307,0 188,0 257,0 254,0 287,0
Planungsphase
(Workshops,
Lösungsansätze,
Grob- und Feinkonzepte)
Realisierungsphase
(Konzepte, Verfahren,
Installationen)
(Erprobung von Verfahren,
Funktionstest von
Installationen)
Einsatzphase (Funktionen im
Netzwerk bereitstellen,
Installationen in der Fläche)
Migr.phasen
62,0 122,0 62,0 107,0 62,0 122,0
1 Feinkonzept / Pflichtenheft
30,0 30,0 30,0 30,0 30,0 30,0
2 Migrationsplan Infrastruktur
10,0 30,0 10,0 25,0 10,0 30,0
3 Migrationsplan Systemmanagement 10,0 30,0 10,0 25,0 10,0 30,0
4 Migrationsplan Client
10,0 30,0 10,0 25,0 10,0 30,0
5 Verabschiedung konsoliderter Migr.plan 2,0 2,0 2,0 2,0 2,0 2,0
137,0 155,0 111,0 130,0 132,0 135,0
6 Implementierung Basis Infrastruktur
72,0 98,0 51,0 77,0 65,0 77,0
7 Infrastrukturdienste
15,0 17,0 8,0 10,0 15,0 10,0
8 Systemmanagement
20,0 25,0 10,0 15,0 20,0 25,0
9 GroupWare - Messaging
12,0 16,0 8,0 12,0 12,0 12,0
10 Terminalserver
20,0 35,0 20,0 35,0 15,0 30,0
11 Design Desktop
5,0 5,0 5,0 5,0 3,0
Paketierung für APC-Implementierung 25,0 27,0 20,0 23,0 27,0 23,0
12 Installationsverfahren Desktop 5,0 7,0 5,0 7,0 4,0 7,0
13 Migration Funktionen Systemmgmt. 15,0 15,0 10,0 11,0 18,0 11,0
14 Paketierung: 1-2 Applikationen / 1MT 5,0 5,0 5,0 5,0 5,0 5,0
Pilot und Test 40,0 30,0 40,0 30,0 40,0 35,0
15 Pilotbetrieb 1 Monat / 20 - 50 Benutzer 25,0 15,0 25,0 15,0 25,0 20,0
16 Testlauf Migrationsverfahren
10,0 5,0 10,0 5,0 10,0 5,0
17 Dokumentation Migrationshandbuch
5,0 10,0 5,0 10,0 5,0 10,0
20,0 30,0 15,0 20,0 60,0 30,0
18 Migration der Daten-/Rechte Strukturen 10,0 20,0 5,0 10,0 10,0 20,0
19 Migration der Client Strukturen
10,0 10,0 10,0 10,0 50,0 10,0
Abbildung 4: Beispiel: Personalaufwendungen in den Migrationsphasen
Szenarien Variante 1 Variante 2 Variante 3 Variante 4
Personentage Faktor intern extern intern extern intern extern
Su Kosten Gesamt € 765.795 703.411 709.044
Su Kosten intern/extern € 234.938 530.857 218.982 484.429 230.717 478.327
Su PT Gesamt 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 Anwenderbetreuung 1) absolut 250,0 100,0 250,0 100,0 250,0 100,0
3.3.3 Preisstrukturen der Anbieter
Abbildung 5: Beispiel: Gesamtpersonalaufwand
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

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
Hardware
Betriebssystem Betriebssystem
Infrastrukturdienste Directory
Seite 82
Anmeldedienst
File
Druck
DNS/ DHCP/ BOOTP
Systemmanagement Softwareverteilung
Inventarisierung
Helpdesk
Systemüberwachung
Netzwerküberwachung
Datenbanken DBMS (Datenbanken-
Managementsysteme)
Groupware & Messaging Groupware
Terminalserver
Mail
Tabelle 10: Erhebungsstruktur Preisinformationen Hard-/ Software - Server

3.3.3.2 APC
Auch auf der Seite der Arbeitsplatzrechner hat sich nachfolgende Strukturierung als hilfreich
erwiesen:
Arbeitsplatzcomputer
Software
Hardware
Betriebssystem Betriebssystem
Standardsoftware Dokumentenaustauschformat,
PDF-Betrachter/-Erstellung
Terminalserver (Client Zugriff)
Seite 83
Webbrowser und Mailclient
Textverarbeitung
Tabellenkalkulation
Präsentation
Komprimierung
Werkzeuge (Bildbearbeitung, etc.)
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.0 74 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 siehe WiBe 4.0, Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der
Bundesverwaltung, insbesondere beim Einsatz der IT, Version 4.0 – 2004, S. 80 ff.

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 Methodik 75 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
haushaltswirksamen 76 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 Migrationsobjekte 77 (Teilmigration), bei klar
abgrenzbaren Produkten oder Produktgruppen 78
� 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 siehe die Kapitel zur WiBe 4.0
76 Haushaltswirksame Kosten und Nutzen entstehen erst aufgrund der betrachteten Maßnahme
und führen im kommenden Haushaltsplan zu Mehr- oder Minderbeantragungen.
77 Siehe hierzu im Kapitel Vorgehensweise die Abgrenzung der Objekte.
78 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,
MS Access 79 Mittler bis hoher Schwierigkeitsgrad
möglich; vornehmliche Risikobereiche:
hohe Anzahl, keine Dokumentation,
kein Hersteller, kaum Akzeptanz
Sonstiges (Vorlagen,
Makros,
Formulare)
Alle Schwierigkeitsgrade möglich,
abhängig von Situation, vornehmliche
Risikobereiche: Anzahl und Komplexität
der Makros
C/S Migration i. d. R. schwierig
Portierung nur durch Hersteller möglich
Seite 86
Terminalserver und
Ablösung
z. B.: Neuentwicklung durch Entwickler
(gegebenenfalls Web, Access2WEB),
Emulation (WINE), Terminalserver,
Ablösung
z. B.: Beibehaltung der Office-
Anwendungen durch Emulation, Portierung
nach OpenOffice.org, Ablösung
Portierung durch Hersteller, Möglichkeiten:
Web, Emulation,
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.

terstützung der Geschäftsprozesse. Zur Erhebung 80 hat sich folgende Struktur in verschiedenen
Projekten bewährt:
� Infrastruktur Server
� Infrastruktur APC
� Infrastruktur Netz
� Infrastruktur Druck
� Serverdienste
� Standardsoftware
� Office
� IT-Fachverfahren
� Dokumentvorlagen
4.1 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 Invest/ Kosten Anmerkungen
Summen
4.2 Infrastruktur APC
Seite 87
< 1 1 - 3 > 3
Abbildung 6: Beispiel Erhebungsbogen - Infrastruktur der Server
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

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] … davon …
Erhebungsbereich [3] Betriebs- Anzahl Alter 8 Jahre 5 Jahre 3 Jahre 2 Jahre zentrale zentrale Eingabe- Anmerkungen
System APCs Prozessor < 100 MHz 100 - 400 MHz 400 - 700 MHz, > 700 MHz Installation Administration Hilfen
im Netz Memory < 32 MB < 64MB 64 - 128 MB > 128 MB
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 Betriebs- eingesetztes Hersteller Anzahl Anzahl Schnittstellen Anmerkungen
eingesetzte System Produkt Lizenzen Clients zu Office-
Systeme Anwendungen
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
Seite 89
Alter in Jahren Kosten für
Erhebungsbereich < 1 1 - 3 > 3 Gesamt Kauf Leasing Wartung Anmerkungen
Gesamt Kosten
Anzahl
Netzwerkdrucker
Faxgeräte
Netzwerkarten
Grafikkarten
Beschleunigung
Scanner
Arbeitsplatzdrucker
Aufstellung der Treiber für Arbeitsplatzdrucker
4.5 Serverdienste
Summen
Abbildung 9: Beispiel Erhebungsbogen - Drucker-Infrastruktur
In diesem Bereich werden die zentralen auf Servern im Rechenzentrum verfügbaren
Dienste erhoben – z. B.:
� Infrastrukturdienste
o Dateiablage (File-Server)
o Druckdienste (Print-Server)

o Netzwerkdienste
� DNS
� DHCP
� WINS
� RAS
� VPN
� BOOTP
o 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 Hersteller Anzahl Anzahl Schnittstellen Anmerkungen
eingesetzte System Produkt Lizenzen Clients zu Office-
Systeme Anwendungen
Infrastrukturdienste
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
Lizenzen Kosten heute Kosten künftig
Name Version Hersteller Verwend.Zweck Anz.heute künftig Lizenzen Insurance 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 ser-
Seite 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
Office
- Dokumentvorlagen und Makros
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
Erhebungsbereich Dokumentvorlagen Makroanwendungen
Komplexität der Erstellung Komplexität der Erstellung
gering mittel hoch sehr hoch gering mittel hoch sehr hoch
Programm
Verzeichnis Anzahl
Su
Tage
< 0,5 0,5 - 2 2 - 4 > 4 < 0,5 0,5 - 2 2 - 4 > 4 Anmerkungen
Word
Excel
PowerPoint
Access
. . Sonstige . .
Unverzichtbare, produktive …
Abbildung 12: Beispiel Erhebungsbogen - Office
Seite 92

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 Nutzer
Produkt- 1 2-/ n-schichtig Gesamt- Einsatz in Abteilungen Fachbereiche
Name Schicht C/S Term. Host Web Anzahl Abteilung 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1 2 3 4 5 6 7 8 9 10
Summen
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 Client-Betriebssystem(e) Server-Betriebssystem(e)
Produkt- eingesetzt verfügbar eingesetzt verfügbar
Name Windows Linux Unix Windows Linux Unix Windows Linux Unix Netware Windows Linux Unix Netware
NT XP NT XP NT XP NT XP
Summen
Abbildung 14: Beispiel Erhebungsbogen - IT-Fachverfahren – Client-/Serverbetriebssysteme
Seite 94

IT-Fachverfahren22
- Datenbanksysteme, Applikationsserver
Bezeichnung Datenbanksysteme Applikationsserver
Produkt- eingesetzt verfügbar eingesetzt verfügbar
Name Windows Linux Unix Windows Linux Unix Windows Linux Unix Windows Linux Unix
NT XP NT XP 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 Verwaltung Schnittstellen
Produkt- Benutzer Rechte zu anderen zu Stand. zu Dokumentvorlagen zu Makros
Name innerhalb über sonstiges innerhalb über sonstiges IT-Verfahren, Software, Komplex- gering mittel hoch sehr gering mittel hoch sehr
der Verzeichn.- der Verzeichn.- Name de Name de ität hoch hoch
Anwendg. Dienst Anwendg. Dienst Verfahrens Verfahrens Erstellgs.- < 0,5 0,5 - 2 2-4 > 4 < 0,5 0,5 - 2 2-4 > 4
Dauer [1]
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 IT-
Abteilung) 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 Verfahrens Hosting Verfahrens-Entwicklung Ausprägungen
Produkt- Verantwortung Verfahrens- Art Aufwand Entwicklg.-Umgebng Komplexität Anforderung Betreuungs-
Name Betreiber [1] Kosten Tage Tage Produkt Support Verfügbarkeit Aufwand
A B C selbst
intern extern
Version durch: Hoch Mittel Gering Hoch Mittel Gering Hoch Mittel Gering
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 Ausblick Kosten
Produkt- Kurz- Fort- Ablö- Ein- Linux Platt- Gesamt Betreuung Lizenzen Anmerkungen
Name Beschreibung schrei- sung stel- Ver- form- Kosten Intern Extern interne externe Miete Wartung Schulung Sonstiges
bung lung füg- Unab- in Euro in Euro Umlagen Lizenzen
bar- hängig- /Jahr /Jahr
keit keit
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.0 81 sowie des IT-Updates 82 der KBSt, die inhaltlich und
methodisch an die spezifischen Gegebenheiten und Besonderheiten von Migrationsmaßnahmen
angepasst beziehungsweise weiterentwickelt wurden 83 .
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 Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der Bundesverwaltung,
insbesondere beim Einsatz der IT, WiBe 4.0, August 2004.
82 Hinweisen und Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen bei
IT-Update- beziehungsweise Umstellungsvorhaben auf Grundlage der IT-WiBe-97, November
2000.
83 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 Ist-
Zustandes 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 Ist-
Zustand 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:
� 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.
84 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 IT-
WiBe 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ßnahme
85 . 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 siehe WiBe 4.0, Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der
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 werden
86 .
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
� Sind notwendige Ausbau- und/oder Erweiterungen nicht möglich?
86 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 100

ae) Flexibilität Altsystem - Interoperabilität, Schnittstellenprobleme aktuell/zukünftig
� 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
� Gibt es Sicherheitsmängel, die zu einer Beeinträchtigung im Betrieb führen?
5.1.3 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 ein-
Seite 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-Katalogen 87 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

g) 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
� Sind in ausreichender Form Dokumentationen und Handbücher verfügbar?
5.2 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 1
Einfluss-
größen
festlegen
�� �� Abgestimmte
Abgestimmte
Kriterien
Kriterien
Daten
erheben
Schritt 2
Risiken
schätzen
Kriterien bewerten
Kriterien bewerten
�� �� Konsistentes
Konsistentes
Datengerüst
Datengerüst
Seite 104
Wirtschaftlichkeit
berechnen1) Wirtschaftlichkeit
berechnen
KN
Kosten/ Nutzen
1)
KN
Kosten/ Nutzen
Schritt 3
Wirtschaftlichkeit
berechnen1) Wirtschaftlichkeit
berechnen
KN/R
Kosten/ Nutzen/
Risko
1)
KN/R
Kosten/ Nutzen/
Risko
Dringlichkeit ermitteln2) Dringlichkeit ermitteln D 2) D
Qualitativ/ strategische .
Bedeutung ermitteln2) Qualitativ/ strategische .
Bedeutung ermitteln Q 2) Q
Abbildung 19: Methodik WiBe Migrationen
5.2.1.1 Spezifischer Kriterienkatalog für Migrationen
�� �� Kennzahlen
Kennzahlen
monetär monetär
nicht-monetär
nicht-monetär
1) Kapitalwertmethode, 2) Nutzwertanalyse
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.

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 IT-
Maß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ätze 88 (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
Darstellung von Kosten 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
Darstellung von Kosten haushaltswirksam
Unter diesem Kriterium sind alle Kosten auszuweisen, die bei der Beschaffung von Hard-
und 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.
Der ermittelte Betrag ist regelmäßig in voller Höhe als „haushaltswirksam― zu erfassen.
Seite 107

Kriterium 1.1.1.4 Sonstige Kosten für Sach-/Hilfsmittel
Darstellung von Kosten 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.
Der ermittelte Betrag ist regelmäßig in voller Höhe als „haushaltswirksam― zu erfassen.
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)
Darstellung von Kosten haushaltswirksam
Das Kriterium Reisekosten (eigenes Personal) beinhaltet alle Kosten für Reisen, Unterbringung,
Tagegelder der Projektmitarbeiter 89 (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.
Kriteriengruppe 1.1.2 Systemkosten
Unter diese Position fallen alle haushaltswirksamen und auch nicht unmittelbar haushaltswirksamen
Kosten, die mit der Erstellung (Bereitstellung) der erforderlichen Hard-
und 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
Darstellung von Kosten 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
Darstellung von Kosten 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
Darstellung von Kosten 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
Darstellung von Kosten 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
Darstellung von Kosten 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.)
Kriteriengruppe 1.1.3 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 IT-
Maß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)
Darstellung von Kosten 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
Darstellung von Kosten 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
Darstellung von Kosten haushaltswirksam/ nicht haushaltswirksam
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
Darstellung von Kosten haushaltswirksam/ nicht haushaltswirksam
Die Kosten für die Erstschulung von Anwendern und IT-Fachpersonal lassen sich je
Teilnehmer bei externen Schulungen exakt quantifizieren. Sofern für das IT-
Fachpersonal besondere Kosten der Zertifizierung (beispielsweise durch den Software-
Hersteller) 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
Darstellung von Kosten haushaltswirksam/ nicht haushaltswirksam
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
Darstellung von Kosten haushaltswirksam/ nicht haushaltswirksam
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 haushaltswirksam/ nicht haushaltswirksam
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

eispielsweise 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 Wi-
Be 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 werden 92 .
� Es ist unbedingt darauf zu achten, alle monetären Angaben aufzuteilen in den haushaltswirksamen
und in den nicht haushaltswirksamen Anteil.
Grundüberlegungen zur Datenermittlung:
� 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.
92 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 IT-
WiBe 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 IT-
Maß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
Darstellung von Kosten/ Nutzen 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
Darstellung von Kosten/ Nutzen haushaltswirksam/ nicht haushaltswirksam
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
Darstellung von Kosten/ Nutzen haushaltswirksam/ nicht haushaltswirksam
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 Kosten-
Leistungsrechnung 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 IT-
Maß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
Darstellung von Kosten/ Nutzen 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 Anwender-
Organisationseinheiten 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
Darstellung von Kosten/ Nutzen haushaltswirksam/ nicht haushaltswirksam
Laufende Personalkosten für die Systembetreuung und -administration des neuen IT-
Systems 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
Darstellung von Kosten/ Nutzen haushaltswirksam/ nicht haushaltswirksam
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
Darstellung von Kosten/ Nutzen haushaltswirksam/ nicht haushaltswirksam
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 Wartungsarbei-
Seite 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
Darstellung von Kosten/ Nutzen haushaltswirksam/ nicht haushaltswirksam
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
Darstellung von Kosten/ Nutzen haushaltswirksam/ nicht haushaltswirksam
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
Nominal Gesamt, 8 Jahre Barwerte Gesamt, 8 Jahre
WiBe
Hinweis: Startjahr = 2005, Laufzeit = 8 Jahre,
Diskontierungs-Zins = 3,8%,
Break even gesamt im 5. Jahr, 2009
gesamt hh.wirks. n.hh.wirks. gesamt hh.wirks. n.hh. wirks.
KN Kosten + Nutzen - Entwicklung/ Einführung und Betrieb 3.077.501 29.819 3.047.682 2.307.062 -127.577 2.434.639
…davon Kosten -3.802.487 -2.437.901 -1.364.586 -3.630.750 -2.325.694 -1.305.056
… davon Nutzen 6.879.987 2.467.720 4.412.267 5.937.812 2.198.118 3.739.695
KN Kumuliert 3.077.501 29.819 3.047.682 2.307.062 -127.577 2.434.639
1 Entwicklungs-/Einführungskosten und Entwicklungsnutzen -2.349.509 -1.422.031 -927.478 -2.349.509 -1.422.031 -927.478
…davon Kosten -1.627.351 -927.478 -2.554.829 -1.627.351 -927.478
… davon Nutzen 205.320 0 205.320 205.320 0
1.1 Entwicklungs-/Einführungskosten für das neue IT-Verfahren -2.554.829 -1.627.351 -927.478 -2.554.829 -1.627.351 -927.478
1.1.1 Planungs- und Einführungskosten -1.165.910 -641.235 -524.675 -1.165.910 -641.235 -524.675
1.1.1.1 Personalkosten (eigenes Personal) -568.175 -43.500 -524.675 -568.175 -43.500 -524.675
1.1.1.2 Kosten externer Beratung -452.632 -452.632 0 -452.632 -452.632 0
1.1.1.3 Kosten der Entwicklungsumgebung 0 0 0 0 0 0
1.1.1.4 Sonstige Kosten für Sach-/Hilfsmittel -139.303 -139.303 0 -139.303 -139.303 0
1.1.1.5 Reisekosten (eigenes Personal) -5.800 -5.800 0 -5.800 -5.800 0
1.1.2 Systemkosten -786.596 -786.596 -786.596 -786.596
1.1.2.1 Hardwarekosten -165.880 -165.880 -165.880 -165.880
1.1.2.2 Softwarekosten -620.716 -620.716 -620.716 -620.716
1.1.3 Kosten der Systemeinführung -602.322 -199.520 -402.802 -602.322 -199.520 -402.802
1.2 Entwicklungs-/Einführungsnutzen aus Ablösung des alten Verfahrens 205.320 205.320 205.320 205.320
1.2.1 Einmalige Kosteneinsparungen (Vermeidung von Erhaltungs-
205.320 205.320 0 205.320 205.320 0
1.2.2 /Erweiterungskosten Einmalige Erlöse (aus Altsystem) Verwertung Altsystem) 0 0 0 0 0 0
Abbildung 20: WiBe - Beispielhafte WiBe Kalkulation 1, Einführungskosten/ -nutzen
Seite 120

IT-Vorhaben: Migration von Server- und Clientarchitekturen
Pos. Kriterium, Erläuterung zur Selektion
Nominal Gesamt, 8 Jahre Barwerte Gesamt, 8 Jahre
WiBe
Hinweis: Startjahr = 2005, Laufzeit = 8 Jahre,
Diskontierungs-Zins = 3,8%,
Break even gesamt im 5. Jahr, 2009
gesamt hh.wirks. n.hh.wirks. gesamt hh.wirks. n.hh. wirks.
KN Kosten + Nutzen - Entwicklung/ Einführung und Betrieb 3.077.501 29.819 3.047.682 2.307.062 -127.577 2.434.639
…davon Kosten -3.802.487 -2.437.901 -1.364.586 -3.630.750 -2.325.694 -1.305.056
… davon Nutzen 6.879.987 2.467.720 4.412.267 5.937.812 2.198.118 3.739.695
KN Kumuliert 3.077.501 29.819 3.047.682 2.307.062 -127.577 2.434.639
1 Entwicklungs-/Einführungskosten und Entwicklungsnutzen -2.349.509 -1.422.031 -927.478 -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
…davon Kosten -810.550 -437.108 -1.075.921 -698.343 -377.578
… davon Nutzen 2.262.400 4.412.267 5.732.492 1.992.798 3.739.695
2.1 Laufende Sachkosten/ Sachkosteneinsparungen
2.1.1 (Anteilige) Host-, Server- und Netzkosten
2.1.1.1 Lfd. Kosten aus IT-Verfahren NEU 0 0 0 0 0 0
2.1.1.2 Lfd. Nutzen aus Wegfall IT-Verfahren ALT 0 0 0 0 0 0
2.1.2 (Anteilige) Kosten für Arbeitsplatzrechner
2.1.2.1 Lfd. Kosten aus IT-Verfahren NEU 0 0 0 0 0 0
2.1.2.2 Lfd. Nutzen aus Wegfall Verfahren ALT 0 0 0 0 0 0
2.1.3 Energie- und Raumkosten
2.1.3.1 Lfd. Kosten aus IT-Verfahren NEU 0 0 0 0 0 0
2.1.3.2 Lfd. Nutzen aus Wegfall IT-Verfahren ALT 0 0 0 0 0 0
2.2 Laufende Personalkosten/-einsparungen 3.882.359 -92.800 3.975.159 3.280.375 -81.741 3.362.117
2.2.1 Personalkosten aus Systembenutzung 4.412.267 4.412.267 3.739.695 3.739.695
2.2.1.1 Lfd. Kosten aus IT-Verfahren NEU 0 0 0 0 0 0
2.2.1.2 Lfd. Nutzen aus Wegfall Verfahren ALT 4.412.267 0 4.412.267 3.739.695 0 3.739.695
2.2.2 Systembetreuung und -administration -437.108 -437.108 -377.578 -377.578
2.2.2.1 Lfd. Kosten aus IT-Verfahren NEU -437.108 0 -437.108 -377.578 0 -377.578
2.2.2.2 Lfd. Nutzen aus Wegfall Verfahren ALT 0 0 0 0 0 0
2.2.3 Laufende Schulung/Fortbildung -92.800 -92.800 -81.741 -81.741
2.2.3.1 Lfd. Kosten aus IT-Verfahren NEU -92.800 -92.800 0 -81.741 -81.741 0
2.2.3.2 Lfd. Nutzen aus Wegfall Verfahren ALT 0 0 0 0 0 0
2.3 Laufende Kosten/Einsparungen bei Wartung /Systempflege 1.544.650 1.544.650 1.376.196 1.376.196
2.3.1 Wartung/Update der Hardware 303.850 303.850 274.964 274.964
2.3.1.1 Lfd. Kosten aus IT-Verfahren NEU -230.550 -230.550 0 -195.754 -195.754 0
2.3.1.2 Lfd. Nutzen aus Wegfall IT-Verfahren ALT 534.400 534.400 0 470.717 470.717 0
2.3.2 Wartung/Update der Software 1.240.800 1.240.800 1.101.232 1.101.232
2.3.2.1 Lfd. Kosten aus IT-Verfahren NEU -487.200 -487.200 0 -420.848 -420.848 0
2.3.2.2 Lfd. Nutzen aus Wegfall IT-Verfahren ALT 1.728.000 1.728.000 0 1.522.080 1.522.080 0
2.3.3 Ersatz-/Ergänzungskosten
2.3.3.1 Lfd. Kosten aus IT-Verfahren NEU 0 0 0 0 0 0
2.3.3.2 Lfd. Nutzen aus Wegfall IT-Verfahren ALT 0 0 0 0 0 0
2.4 Sonstige Laufende Kosten und Einsparungen
2.4.1.1 Lfd. Kosten aus IT-Verfahren NEU 0 0 0 0 0 0
2.4.1.2 Lfd. Nutzen aus Wegfall Verfahren ALT 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 vorgenommen 93
wird. Jedes Kriterium ist in seiner Gruppe (Dringlichkeit; Qualität) mit einer Gewichtung 94
versehen, deren Summe sich in der Gruppe auf 100 addiert.
93 Es handelt sich dabei um eine Ordinalskala mit aufsteigender Wertigkeit der vorgefundenen
Umstände, wobei 0 die Minimalbewertung und 10 die Maximalbewertung darstellt.
94 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 Ablösedringlichkeit Altsystem
Kriterium 3.1.1 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 4 6 8 10
nicht
gefährdet
soweit absehbar
besteht kein
Engpass
Unterstützung
läuft aus, Ersatz
derzeit nicht
erforderlich
Seite 122
Unterstützung
läuft aus, kurzfristig
keine
Probleme
Unterstützung
läuft aus, Ersatz
dringend
Tabelle 15: Punktbewertungsskala Unterstützungskontinuität Altsystem
Kriterium 3.1.2 Stabilität Altsystem
Unterstützung
entfällt, Neulösung
zwingend
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).

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
Seite 123
durchschnittlich
beeinträchtigt,
störend
überdurchschnittlichbeeinträchtigt,
belastend
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
sehr stark beeinträchtigt,
intolerabel
0 2 4 6 8 10
nicht von Bedeutung
selten, gering gering, noch
tolerabel
gering, aber
absehbar zunehmend
mittel,
zunehmend
Tabelle 17: Punktbewertungsskala Wartungsprobleme, Personalengpässe
Kriterium 3.1.3 Flexibilität Altsystem
anhaltend
gravierend
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 Anforderungenkönnen
nur aufwendig
erfüllt
werden
stark eingeschränkt,
viele
Anforderungen
können nicht
realisiert werden
Tabelle 18: Punktbewertungsskala Ausbau-/Erweiterungsgrenzen
Ausbau beziehungsweise
Erweiterung
nicht möglich,
aber erforderlich

Kriterium 3.1.3.2 Interoperabilität, Schnittstellenprobleme aktuell/zukünftig
3.1.3.2 Flexibilität des Altsystems: Interoperabilität, Schnittstellenprobleme aktuell/zukünftig
0 2 4 6 8 10
nicht eingeschränkt
Probleme derzeit
nicht wahrscheinlich
Probleme
absehbar,
Anpassungen
problemlos
Seite 124
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 ansatzweiseberücksichtigt
anstehende
Rechtsänderungen
sind nicht
berücksichtigt
geltende
Rechtsnormen
sind mangelhaft
eingehalten
Tabelle 21: Punktbewertungsskala Einhaltung gesetzlicher Vorgaben
geltende
Rechtsnormen
sind nicht eingehalten

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 4 6 8 10
nicht
beeinträchtigt
kleine unbedeutende
Mängel
geringe Mängel,
aber
anderweitig
abzustellen
Seite 125
geringe Mängel,
mittelfristiger
Änderungsbedarf
Datenschutz
und Datensicherheitmangelhafteingehalten
Tabelle 22: Punktbewertungsskala Erfüllung von Datenschutz/ -sicherheit
gravierende
Verstöße, Anpassungen
dringlich

Kriterium 3.2.3 Ordnungsmäßigkeit Arbeitsabläufe
Arbeitsabläufe beziehungsweise Geschäftsprozesse und die eingebundenen IT-
Maß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 IT-
System 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äßigkeitgegeben,
aber aufwendigesVerfahren
Seite 126
Ordnungsmäßigkeitzeitweisebeeinträchtigt
und aufwendigesVerfahren
Ordnungsmäßigkeitdauerhaftbeeinträchtigt
und aufwendigesVerfahren
Tabelle 23: Punktbewertungsskala Ordnungsmäßigkeit der Arbeitsabläufe
Kriterium 3.2.3 Erfüllung von Auflagen und Empfehlungen
Ordnungsmäßigkeit
nicht
gegeben
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 8 10
keine Abweichungen
geringe, nicht
substanziellen
Abweichungen
geringe Abweichungen,
sind
aber auch ohne
Neusystem zu
beheben
zahlreiche Abweichungen
Verfahren insgesamtverbesserungsbedürftig,
da substanzielleAbweichungen
vorhanden
Tabelle 24: Punktbewertungsskala Erfüllung von Auflagen und Empfehlungen
Verfahren widersprichtkonkreten
Auflagen
oder Empfehlungen

5.3.2 Qualitativ-strategische Kriterien
In dieser Gruppe des Kriterienkataloges sind die qualitativ-strategischen Kriterien von IT-
Maß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 Priorität der IT-Maßnahme
Kriterium 4.1.1 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 IT-
Rahmenkonzeptes 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 IT-
Maßnahme,
zeitlich nicht
dringend
Seite 127
Realisation ist
Vorbedingung
für weitere
wichtige IT-
Maßnahmen
bedeutendes
zeitkritische IT-
Maßnahme
Tabelle 25: Punktbewertungsskala Bedeutung innerhalb IT- Rahmenkonzept
Schlüsselstellung
im IT-
Rahmenkonzept
Kriterium 4.1.2 Einpassung in den IT-Ausbau der Bundesverwaltung insgesamt
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.

4.1.2 Einpassung in den IT-Ausbau
0 2 4 6 8 10
nicht von Bedeutungbeziehungsweise
keine positive
Auswirkung
geringfügige
Förderung des
IT-Ausbaus
weitergehende
Förderung des
IT-Ausbaus
Seite 128
IT-Maßnahme
ist wichtig, aber
nicht zeitkritisch
IT-Maßnahme
ist wichtig und
zeitkritisch
IT-Maßnahme
ist zwingend für
die IT-
Integration 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 4 6 8 10
keine positiven
Wirkungen
behördenübergreifend
keine für den
Anwender
merkbaren
Verbesserungen
im
Informationsaustausch
zu erwarten
punktuelle Verbesserungen
im
behördenübergreifendenInformationsaustausch
zu
erwarten
erhebliche
Verbesserung
bezogen auf
einen Vorgangstypus
sind
erreichbar
erhebliche
Verbesserung
bezogen auf
mehrere Vorgangstypen
sind
erreichbar
Tabelle 27: Punktbewertungsskala Folgewirkung für Kommunikationspartner
erhebliche
Verbesserung
durch behördenübergreifendeVereinheitlichung
von
Datenstrukturen
und Verfahrensroutinen

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 WiBe 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 4 6 8 10
nicht von Bedeutung
Ersteinsatz
einer Standardlösung
Ersteinsatz
einer Eigenentwicklung,weitereAusbaustufen
geplant
Seite 129
behördeninternes
Pilotprojekt,
keine Standardlösung,Folgeinvestitionen
Pilotprojekt mit
weiteren Einsatzfeldernbehördenübergreifend
Pilotprojekt mit
flächendeckenderEinsatzabsichtbehö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).

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
Seite 130
Ü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-Architektur 96 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.

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 8 10
Nicht von Bedeutung
bzw.
keine ersichtlichen
Wirkungen
zu erwarten
Geringfügige
qualitative Verbesserungen
ohne strategisches
Gewicht
(z.B. Lösung
steht in mehreren
Versionen
für unterschiedlichePlattformen
zur Verfügung(Pseudounabhängigkeit))
Software kann
mit geringfügigem
Aufwand
auf andere
Plattformen
portiert werden.
Vorhandene
Hardware/ Peripherie
kann
auch weiterhin
in den geplanten
Fristen
eingesetzt werden.
Seite 131
Plattform-/
Herstellerunabhängigkeit
ist
gewährleistet
und die angestrebte
Lösung
trägt zur Erweiterung
der Aus-
und Umbauoptionen
bei.
Plattform-/
Herstellerunabhängigkeit
und
Investitionsschutz
sind
gewährleistet,
Vorgaben aus
der IT-Architektur
97 werden
eingehalten.
Tabelle 30: Punktbewertungsskala Plattform-/Herstellerunabhängigkeit
Kriteriengruppe 4.2
Qualitätszuwachs bei Erledigung von Fachaufgaben
Weitgehende
Gestaltungsautonomieverbunden
mit der
Weiternutzung
vorhandener
Hard- und Software.
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.

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
nicht von Bedeutungbeziehungsweise
keine positiven
Wirkungen
geringe Verbesserung
des
formalen Arbeitsablaufs
mittlere
Verbesserung
hinsichtlich
des formalen
Arbeitsablaufs
Seite 132
erhebliche
Verbesserungen
des formalenArbeitsablaufs
erhebliche
Verbesserung
des materiellen
Arbeitsergebnisses
erhebliche
Verbesserung
des formalen
Arbeitsablaufs
und des materiellenArbeitsergebnisses
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
nicht von Bedeutungbeziehungsweise
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 einheit-

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 8 10
nicht von Bedeutungbeziehungsweise
keine positiven
Wirkungen
keine spürbare
Reduzierung
von Sonderfällen
zu erwarten
punktuelle Verbesserung
behördenintern
Seite 133
erhebliche
Verbesserung
bezogen auf
einen Vorgangstypus
erhebliche
Verbesserung
durch behördeninterneVereinheitlichung
von
Datenstrukturen
und Verfahrensroutinen
Tabelle 33: Punktbewertungsskala Einheitliches Verwaltungshandeln
erhebliche
Verbesserung
durch behördenübergreifendeVereinheitlichung
von
Datenstrukturen
und Verfahren
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 4 6 8 10
nicht von Bedeutungbeziehungsweise
keine positiven
Wirkungen
nur geringfügige
Änderung zum
derzeitigen Ist-
Zustand
verschiedene,
kleinere Mängel
behoben
wesentliche
bisherige Mängel
abgestellt
qualitativ unmittelbarersichtliche
Erhöhung
für einzelne
Adressaten
Tabelle 34: Punktbewertungsskala Verständlichkeit und Nachvollziehbarkeit
Kriterium 4.2.5 Imageverbesserung
qualitativ unmittelbarersichtliche,bedeutsame
Erhöhung
für zahlreiche
Adressaten
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.

4.2.5 Imageverbesserung
0 2 4 6 8 10
nicht von Bedeutungbeziehungsweise
keine positiven
Wirkungen
Kurzfristig keine
wahrnehmbare
Änderung
positive Wirkung
bei einzelnen
Adressaten
zu erwarten
Seite 134
positive Wirkung
mittelfristig
bei vielen Adressaten
nachhaltig positive
Wirkung bei
einigen Adressaten
Tabelle 35: Punktbewertungsskala Imageverbesserung
Kriteriengruppe 4.3 Mitarbeiterbezogene Effekte
Kriterium 4.3.1 Attraktivität der Arbeitsbedingungen
nachhaltig positive
Wirkung bei
vielen Adressaten
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 4 6 8 10
nicht verbessert/
ist nicht
von Bedeutung
leichte Verbesserung
mittlere Verbesserung
in wenigen
Bereichen
mittlere Verbesserung
in mehreren
Bereichen
erhebliche
Verbesserung
in wenigen
Bereichen
Tabelle 36: Punktbewertungsskala Attraktivität der Arbeitsbedingungen
Kriterium 4.3.2 Qualifikationssicherung/ -erweiterung
erhebliche
Verbesserung
in mehreren
Bereichen
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

Aufgabenbereiche verbunden sein. Zusammen mit der Anwenderschulung resultiert daraus
eine Qualifikationserweiterung im direkten fachlichen Aufgabenbereich.
4.3.2 Qualifikationssicherung/-erweiterung
0 2 4 6 8 10
nicht beeinflusst
beziehungsweise
keine
positiven
Wirkungen
6 Fazit
Geringe
Effekte hinsichtlich
IT-
Handhabung zu
erwarten
Erhebliche
Effekte bei IT-
Handhabung zu
erwarten
Seite 135
erhebliche
Effekte bei IT-
Handhabung
und aufgabenbezogeneWeiterentwicklung
deutliche Erweiterung
der aufgabenbezogenenQualifikation
Tabelle 37: Punktbewertungsskala Qualifikationssicherung/ -erweiterung
Erhebliche
fachbezogene
Höherqualifikation
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?―).

� 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 Ist-
Situation 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 IT-
Unternehmen 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 IT-
Einsatz 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
PHASE 3
PHASE 4
Entscheidung
Projekt-
Planung
Realisierung
Einf.-Schulung
Administratoren
Anwender-
Information
Tests
Seite 139
Ist-
Analyse
Systemintegration
Einf.-Schulung
Anwender
Feinkonzept
Einführung
Betrieb Wartung Support Schulungen
Abbildung 22: Phasen eines Migrationsprozesses

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
IT-Strategie
E-Government 2.0
WiBe
IT-Architekturkonzept
Plattformunabhängigkeit
von Fachanwendungen
Migrationsleitfaden
SAGA
Seite 141
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 IT-
Infrastruktur 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.

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 definierten
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

ereitzustellen 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 IT-
Mitarbeiter 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.
Die nachfolgende Abbildung skizziert beispielhaft, wie eine möglichst sanfte Migration
aussehen könnte.
Know-How-Aufbau
DBMS-
Server
Web-Server
Verzeichnis -
Server
Mail- &
Kalender-
Server
SERVERMIGRATION
Seite 144
File- & Print-
Server
DNS- &
DHCP-
Server
Migration der Fach- und Office-Anwendungen
EVTL.
OFFICE-
MIGRATION
Office/Desktop
DESKTOP-
MIGRATION
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

enö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 IT-
Landschaft 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 Mögliche Auswirkungen der Migrationspfade
2.2.1 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 offensich-
Seite 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 Produkt-
und 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 Zeit-
und 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 Datenbank-
Managementsysteme 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
atomare 98 , 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 Produkte / Technologien
1.1 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 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.
99 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
Millionen 100 . 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 Windows 101 .
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 License 102 zur Verfügung gestellt.
� MySQL Enterprise
Diese Edition wird unter einer kostenpflichtigen Lizenz 103 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:
� 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.
100 http://www.mysql.de/why-mysql/marketshare/
101 http://dev.mysql.com/downloads/mysql/5.0.html#downloads
102 http://www.mysql.com/company/legal/licensing/opensource-license.html
103 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 kann 105 .
� 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 verbunden 106 .
Stored Procedures stehen unter MySQL derzeit nur mit einem eingeschränkten
Funktionsumfang zur Verfügung, da deren Implementation noch nicht vollständig abgeschlossen
ist 107 .
104 http://www.onlamp.com/pub/a/onlamp/2005/06/16/MySQLian.html
105 http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html
106 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
107 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 C-
Bibliothek, 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 OSS-
Projekt 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 http://www.postgresql.org/developer/
109 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, Solaris 110 , Tru64 UNIX und
Windows 111 .
Die Nutzung von PostgreSQL unterliegt der BSD-Lizenz 112 . Aufgrund der großen Community
und des hohen Bekanntheitsgrades wird kostenpflichtiger Support für PostgreSQL
von vielen Firmen angeboten 113 .
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 Live-
Backup realisiert werden.
Für PostgreSQL gibt es eine Reihe von Erweiterungen durch unterschiedliche Organisationen
oder Firmen sowohl in Form von Open-Source-Projekten 114 als auch in Form
proprietärer Produkte 115 . Beispielsweise kann PostgreSQL mit der Erweiterung Post-
GIS 116 als Datenbank für Geoinformationssysteme dienen. Projekte wie pgpool 117 und
PGCluster 118 stellen Replikationsfunktionalität für PostgreSQL-Datenbanksysteme zur
Verfügung. Darüber hinaus sind proprietäre Datenbanksysteme verfügbar, die auf PostgreSQL
basieren.
110
Solaris 10 wird standardmäßig mit PostgreSQL ausgeliefert. Siehe auch:
http://www.sun.com/software/products/postgresql/
111
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
112
http://www.postgresql.org/about/licence
113
http://www.postgresql.org/support/professional_support
114
115
http://www.postgresql.org/download/
http://www.postgresql.org/download/commercial
116
http://postgis.refractions.net/
117
118
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 PostgreSQL-
Datenbanken.
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 erfolgt 119 .
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 Open-
Source-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) engagieren 120 . Firebird ist sowohl für unterschiedliche 32-Bit-Windowsversionen
als auch für Linux verfügbar 121 .
119 http://www.postgresql.org/docs/8.2/static/auth-methods.html#KERBEROS-AUTH
120 Stand: August 2007
121 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 License 123 .
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 hat 124 .
Firebird besitzt keine eigenen Mechanismen zur Verschlüsselung von Daten 125 , verfügt
jedoch über verschiedene Schnittstellen. Darunter sind neben Anbindungen für .NET,
122 http://www.firebirdsql.org/index.php?op=doc&id=ipl
123 http://www.firebirdsql.org/index.php?op=doc&id=idpl
124 http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_admin_tools
125 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ärt 126 , 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 Kunden 127 MaxDB als
Datenbanksystem ein.
MaxDB wird heute von SAP mit einem dualen Lizenzmodell vermarktet. Es ist sowohl
unter der MaxDB Community License 128 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 Delphi ist eine von Borland aus Object Pascal entwickelte Programmiersprache, die im
Windows-Umfeld unter anderem aufgrund ihrer nahtlosen COM-Integration und guter GUI-
Entwicklungsmöglichkeiten eine recht große Verbreitung hat.
127 Darunter finden sich allerdings auch Großkunden wie Toyota, Intel, DaimlerChrysler,
Braun-Gillette, Bayer, Colgate, Yamaha und die Deutsche Post.
128 http://maxdb.sap.com/license/MaxDB_Community_License_2007.pdf
129 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 SQL-
Anweisungen. 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 Datenbank-
Performance. 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 Master-
Datenbank-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 WebDAV-
Schnittstelle 130 , ü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ügbar 131 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 Wettbewerber 133 .
Für den Einsatz von Microsoft SQL Server 2005 existieren drei Lizenzmodelle 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.
130 http://de.wikipedia.org/wiki/WebDAV
131 http://www.microsoft.com/germany/sql/uebersicht/systemanforderungen.mspx
132 Inzwischen (seit der Version 7) wurden die letzten Sybase-Relikte entfernt.
133 http://www.gartner.com/it/page.jsp?id=507466
134 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-Clustern 135 , 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:
� 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.
135 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 Windows-
Betriebssystemdienst 136 . Weitere Ebenen stellen die jeweilige SQL-Server-Instanz, die
zu verschlüsselnde Datenbank und die in ihr enthaltenen Daten dar 137 .
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ützt 138 .
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 Dieser Dienst implementiert die Data Protection API (DPAPI). Siehe auch:
http://msdn2.microsoft.com/en-us/library/ms995355.aspx
137 Eine ausführlichere Beschreibung findet sich in dieser Präsentation:
http://download.microsoft.com/download/4/1/6/416bdb4a-67e9-4269-bcdc-
33dedb7f64fe/encryptionatmstwpppt.ppt.
weitere Informationen unter: http://msdn2.microsoft.com/en-us/library/ms189586.aspx
138 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:
� 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-
139 http://www.gartner.com/it/page.jsp?id=507466
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 DB 141
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:
� Oracle Enterprise Manager
Dieses Werkzeug dient der allgemeinen Verwaltung und Administration von
Datenbanken. Einzelne sogenannte Management Packs decken dabei unterschiedliche
Aspekte ab.
140 Nähere Informationen zum insgesamt recht komplexen Lizenzmodell von Oracle finden sich
hier: http://www.oracle.com/corporate/pricing/sig.pdf
141 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 darf 142 . 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ügung 143 .
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 Entwicklungsumgebung
144 „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 darstellte 145 .
IBM DB2 ist für zahlreiche Betriebssysteme verfügbar, darunter Linux, UNIX und Windows
146 . In Großrechnerumgebungen ist IBM DB2 traditionell marktführend, hat aber
auch in den anderen Bereichen signifikante Marktanteile 147 .
142 http://www.oracle.com/database/label-security.html
143 http://www.oracle.com/database/advanced-security.html
144 http://download.oracle.com/docs/cd/B28359_01/appdev.111/b32258/toc.htm
145 http://www-128.ibm.com/developerworks/db2/library/techarticle/0301jones/0301jones.html
146 http://www-306.ibm.com/software/data/db2/9/sysreqs.html
147 http://www.gartner.com/it/page.jsp?id=507466
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 Express-
C-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:
� 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.
148 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
darf 149 .
IBM DB2 lässt sich wie andere Datenbanksysteme auch aus selbst entwickelten
Anwendungen über entsprechende Schnittstellen ansprechen. Es existieren diverse
APIs 150 , 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 http://www-306.ibm.com/software/data/db2/9/editions_features_advaccess.html
150 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 Recovery-
Funktionalitä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 Daten-
Seite 170

anken 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 SAGA 151 .
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:
� 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 Client-
Anwendungen
� Einbeziehung der Hersteller der Client-Anwendungen
� Konsolidierung von Software- und Datenstrukturen
2.1 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 Quell-
Datenbank 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 Produkte / Technologien
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 Umfrage 152 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 Postgres-
Datenbanken
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 Application-
Server 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-GUI 153 .
Für die Integration einer Suchfunktionalität innerhalb einer Website kann der Apache-
Webserver durch ein entsprechendes Programm ergänzt werden. Es stehen unterschiedliche
Softwareeinheiten zur Auswahl, zum Beispiel das Suchsystem HTDig 154 .
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-WWW-
Authentication― 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 http://gui.apache.org/
154 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 IP-
Adresse) 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 Tomcat 155 , 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
Mono 156 - 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 betrieben 157 . 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 http://tomcat.apache.org/
156 http://www.mono-project.com/
157 http://de.wikipedia.org/wiki/LAMP#_note-online-artikel
158 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 Web-
Server und stehen unmittelbar im Zusammenhang mit der WebDAV-
Funktionalitä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 IP-
Adresse.
� HTTP 1.1-Kompression:
Ermöglicht die HTTP-Kompression bei der Kommunikation zwischen dem Web-
Server 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:
� 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.
159 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 Unicode-
Standard 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 Webserver-
Produkte 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:
� „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
3.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 ge-
Seite 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 Produkte / Technologien
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
werden 160 . 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 Software 162 .
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 http://www.samba.org
161 Stand 01.11.2007
162 http://www.openldap.org
163 http://www.kerberos.org/
Seite 188

Kerberosprotokolls ist die Heimdal-Implementierung 164 . 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
ein 166 . Die nachfolgende Tabelle zeigt die Funktionen, die von OpenLDAP unter Linux
unterstützt werden.
Client ohne Zusatzsoftware
Funktion
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 Samba 168
Authentifizierung von Linux Clients
Möglichkeit zur Integration von Kerberos
Möglichkeit zur Verwendung eines unabhängigen / übergeordneten Kerberos-Dienstes
164 http://www.pdc.kth.se/heimdal/
165 http://web.mit.edu/kerberos/www/
166 http://www.oracle.com/technology/software/products/berkeley-db/index.html
167 Bei der Verwendung von Samba zur Authentifizierung von Windows Clients gegen OpenL-
DAP wird zwischen Windows-Client und Samba-Server das NT-LAN-Manager Protokoll
verwendet.
168 Bei der Verwendung von Samba zur Authentifizierung von Windows Clients gegen OpenL-
DAP 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
Multi-Master-Replikation 169
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 GQ 170 -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 Web-
Browser 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 Webmin 171 .
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 Die Multi-Master-Replikation in OpenLDAP gilt als experimentell und ist standardmäßig
nicht eingeschaltet.
170 http://gq-project.org/
171 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
2830 172 beschrieben.
172 http://www.faqs.org/rfcs/rfc2830.html
Seite 191

Auch bei Login-Prozessen in Betriebssystemen kann auf zentrale, durch einen LDAP-
Server 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 LDAP-
Benutzerverwaltung verwendet werden können 173 .
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 Host-
Informationen 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 LDAP-
Verzeichnis 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%20LDAP-
Authentifizierung.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 NTLM-
Protokoll 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 UNIX-
Programme ü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
Directory 174 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 System-
Policies 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 Single-
Point-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 be-
trachtet.
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 MIT-
Implementierung 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 http://www.dfn-cert.de/infoserv/dib/dib-2002-02-Kerberos5/doc-single.html.
177 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 Für nähere Informationen siehe http://directory.fedoraproject.org/wiki/Licensing.
179 http://directory.fedoraproject.org/wiki/FAQ
Seite 197

anken (>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-Server-
Architektur 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 Home-
und 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/IP-
Netzwerken ist für die fehlerfreie Kommunikation die Namensauflösung von NetBIOS-
Namen (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 Account-
Domä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 LDAP 181 und Kerberos 5 182 offene Standards.
181 http://www.microsoft.com/windowsserver2003/techinfo/overview/ldapcomp.mspx
182 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:
� Windows NT 4.0
� Windows 2000
183 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-bb23-
2cfdf022aee5
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 OpenL-
DAP 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 Account-
Domä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 .NET-
Seite 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 LDAP-
Verzeichnisses „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 SAM-
Datenbank 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 Kom-
185 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 Software,
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 Windows-
Tools 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-, Gruppen-
und 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 Funktionaler Vergleich
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 Kerberos-
Authentisierungsinfrastruktur 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 OpenLDAP-
Verzeichnis 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 OSS-
Community, 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 Funktionaler Vergleich
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 Systems 187 , Neuinstallation oder Domänenupgrade
188 . 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
Hier muss sichergestellt sein, dass die bestehende Hardware den Anforderungen des neuen
Systems gerecht wird.
188
Die Strukturen der NT-Domäne werden in das Active Directory umgewandelt.
Seite 219

2.4.2 Migrationspfad
2.4.2.1 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 NT-
Systems 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 Bezüge
3.1 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 (Net-
BIOS) 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 Produkte / Technologien
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 Net-
BIOS/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 folgt 189 :
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 NetBIOS-
Namensauflö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 NetBIOS-
Computernamens 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 wird 190 :
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 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/
73c0ae36-8058-43d1-8809-046eb03b73fb.mspx?mfr=true
193 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 Service-
Records 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 Erklärung von Windows
genutzt
0 Pad
255 End
1 Subnet mask 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.
2 Time offset
3 Router Gibt die IP-Adresse des Standardgateways
eines Hosts an.
4 Time server
5 Name servers
6 DNS servers Gibt die IP-Adressen von DNS-Servern an. �
7 Log servers
8 Cookie servers
9 LPR servers
Seite 228
�
�

Nr. Optionsname Erklärung von Windows
genutzt
10 Impress servers
11 Resource Location
servers
12 Host name
13 Boot file size
14 Merit dump file
15 Domain name Gibt den verbindungsspezifischen DNS-
Domä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 discovery
32 Router solicitation
address
Gibt an, ob der DHCP-Client ICMP-Routersuche
(Internet Control Message Protocol) als
Host verwendet, wie in RFC 1256 definiert.
33 Static route Gibt einen Satz von IP-Netzwerkzielen mit
Klassen an, zusammen mit den ihnen entsprechenden
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
44 WINS/ NBNS servers
45 NetBIOS over TCP/
IP NBDD
46 WINS/ NBT node
type
Gibt an, ob herstellerspezifische Optionen angefordert
werden.
Gibt die IP-Adressen von WINS-Servern an. �
Gibt den von dem Client verwendeten Typ der
Namensauflösung bei NetBIOS (Network Basic
Input/Output System) über TCP/IP an.
47 NetBIOS scope ID Gibt die NetBIOS-Bereichskennung an. NetBT-
Hosts (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 Gültigkeitsdauer der Vergabe
58 Renewal (T1) time
value
59 Rebinding (T2) time
value
64 NIS + Domain Name
65 NIS + Servers
66 Boot Server Host
Name
67 Bootfile Name
Erneuerungsintervall 1
Erneuerungsintervall
Seite 230
�
�
�

Nr. Optionsname Erklärung von Windows
genutzt
68 Mobile IP Home
Agents
249 Statische Routen
ohne Klassen
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 IPv6-
Verbindungen 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 IPv4-
Verbindung „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 OSS-
Migration 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 Load-
Balancing 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-DHCP-
Servers 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 Hard-
und 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, benutzer-
und 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 ist 195 , 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 Vorgehens-
weisen 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:
� 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
195 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 OSS-
Migration 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 Produkte / Technologien
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 SMB-
Protokoll, 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 Lock-
Mechanismen 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 einbinden 197 .
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 Samba-
Domä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 OpenLDAP 198 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 Samba-
Server 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 Betriebs-
beziehungsweise 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 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.
198 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

W
I
N
D
O
W
S
Ordner durchsuchen /
Datei ausführen
Ordner auflisten / Daten
lesen
Seite 243
POSIX Berechtigungen
Lesen Schreiben Ausführen
X
Attribute lesen X (X) 199
Erweiterte Attribute lesen X
Dateien erstellen / Daten
schreiben
Ordner erstellen / Daten
anhängen
Attribute schreiben X
Erweiterte Attribute
schreiben
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 POSIX-
Berechtigungen 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.
X
X
X

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.
W
I
N
D
O
W
S
Seite 244
POSIX Berechtigungen
Lesen Schreiben Lesen und
Ausführen
Lesen und
Schreiben
Lesen,
Schreiben
und Ausführen
Vollzugriff X
Ändern X
Lesen/ Ausführen X X
Ordnerinhalt
auflisten
(nur für Ordner)
X
(nur für
Ordner)
X
(nur für
Ordner)
Lesen X X X X
Schreiben 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.

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 Alias-
Definitionen 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 Datei-
Systeme 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.25 200 .
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 Open-
AFS 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 UNC-
Pfad \\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 Unicode-
Zeichensatz (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 Besitzer-
Eigenschaft 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.
Ordner durchsuchen
/ Datei ausführen
Ordner auflisten /
Daten lesen
Vollzugriff
Windows Sammelberechtigungen
Ändern Lesen &
Ausführen
Seite 252
Ordnerinhalt
auflisten
X X X X
X X X X X
Attribute lesen X X X X X
Erweiterte Attribute
lesen
Dateien erstellen /
Daten schreiben
X X X X X
Lesen Schreiben
X X X

Ordner erstellen /
Daten anhängen
Vollzugriff
Windows Sammelberechtigungen
Ändern Lesen &
Ausführen
Seite 253
Ordnerinhalt
auflisten
Lesen Schreiben
X X X
Attribute schreiben X X X
Erweiterte Attribute
schreiben
Unterordner/Dateien
löschen
Löschen X X
Berechtigungen
lesen
Berechtigungen
ändern
X X X
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 Bit Bedeutung
Archiv A Datei wurde seit dem letzten Zurücksetzen des Attributes verändert
Schreibgeschützt
R Datei ist schreibgeschützt
Versteckt 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
1.4.4 Überwachung
Tabelle 46: Windows Attribute
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.

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 werden 201 . 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

er 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
Windows-Client ohne Zusatzsoftware
X X X
Länge der Dateinamen
(Zeichen) 256 256 256 256 256
Zeichensatz für Dateinamen Unicode Unicode Unicode ISO-Latin ISO-Latin
Darstellung von Groß/ Kleinschreibung
Unterscheidung von Groß/ Kleinschreibung
X X X X X
Seite 261
einstellbar X X
Disk Quotas X X X X
Verschlüsselung EFS dateiweise
clientseitig
Kompression X X
Maximale Dateigröße 204 2 TB 2 TB 2 TB 9 EB 205 2 GB
Maximale Pfadlänge Unbegr. Unbegr. Unbegr. Unbegr. Unbegr.
Änderungsjournal X (Eine Form
von Auditing
gibt es als
Samba-
VFS-Plugin
202 Als Erweiterung (Patch) zum Beispiel für Ext2/3 Dateisysteme erhältlich
203 Als Erweiterung (Patch) zum Beispiel für Ext2/3 Dateisysteme erhältlich
204 TB Terabyte 1012, PB Petabyte 1015, EB Exabyte 1018
205 NFSv3 mit XFS Dateisystem, je nach Architektur bis zu 9EB, für i386 max. 16TB
202
203

Funktion WinNT NTFS 5 Samba 3.0 NFS 4 AFS
1.5.25
vfs_full_
audit)
Propagierung der
Freigaben im ActiveDirectory
Verteiltes Dateisystem DFS DFS Standard Standard
Dateireplikationsdienst FRS rsync rsync rsync
Journaling
X
Seite 262
X X
DACL NTFS POSIX POSIX AFS
SACL NTFS Samba Modul
Typische Autorisierung über NT/ LM
PDC
AD / Kerberos
NT/LM
LDAP, wenn
AD-Mitglied
dann Kerberos
Tabelle 47: Vergleich der Dateiserver
X
X
NIS/ LDAP Kerberos
Version 4
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

Dateiersterstellung zu übertragen. Dieses vereinfachte Vorgehen ist zurzeit noch nicht
möglich, doch der rsync Befehl wird stetig weiter entwickelt 206 .
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 Ablage-
Umgebung 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 Produkte / Technologien
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 Vollbild-
Modus 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

1.1.2 Unterstützung etablierter F
208
F Standards
bei Druckdaten-Übertragung
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 Drucker-
und 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 HTCPH-
Verbindung Befehle entgegen, um einen lokal angeschlossenen HDruckerH zu
steuern.
LPR/LPD, das traditionelle Protokoll zur Druckdaten-Übertragung (vom Client zum Print-
Server, 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
209
einer Arbeitsgruppe (der PWGF
F), 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 X‎II.A 1.2 X dargestellt
netzwerkfähigen Druckern unterstützt.
Socket/ AppSocket
wird. IPP wird von den meisten
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 Windows-
Rechner, 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 PostScript-
Drucker 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
210
Adobe seit ihrer Gründung im Jahre 1982 F
F als Ergebnis der Erfahrungen mit den
211
Quasi-Vorgängern, Design System (1976) und JaM (1978). F
F 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 Post-
Script-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
212
Software Ghostscript F
F.
1.2 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
213
ist die Version 10.5 (Leopard). Aktuell F
F ist CUPS in der Version 1.3.6 verfügbar. Und
die Version 1.4 befindet sich in der Entwicklung.
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 Manche Quellen erwähnen auch 1983 oder 1984 als Beginn der Entwicklung.
211 http://www.mathematik.uni-ulm.de/help/pstut/01_inh.html
212 Hhttp://www.cs.wisc.edu/~ghost
213 10. März 2008
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 CUPS-
Module, sogenannte „BackEnds―, eingesetzt werden Diese Module ermöglichen die
Kommunikation mittels anderer Protokolle. In XAbbildung 29 wird die Verwendung der
Protokolle an den jeweiligen Übergängen dargestellt.
Abbildung 29: Drucken unter CUPSF
Für die Druckeransteuerung verwendet CUPS die in Abschnitt II.F 1.1.2.2 X beschriebene
PostScript Printer Descriptions (PPD) und dies nicht nur für PostScript-fähige Drucker.
214
Hhttp://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/ H
Seite 275
214

CUPS ist in der Lage diese auch für Drucker ohne eigenen eigenen PostScript-
Interpreter 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 benutzer- und anwendungsspezifisch
angepasst werden. Informationen über eigene CUPS Erweiterungen zu
215
Adobes PPD können im Internet nachgeschlagen werden F
F.
1.2.5.1 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
216
Der Druckauftrag eines Client wird an einen HSchedulerHF
F gesendet, der die zu druckenden
Daten mittels Filter in das HPostScriptH-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.
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 Software-
Bibliothek eine optimale Integration von CUPS in Samba verfügbar ist (siehe auch
Abschnitt X‎II.A 1.3 X), 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.
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
217
Hotfix von Microsoft einzuspielenF
F.
215
Hhttp://www.cups.org/documentation.php/spec-ppd.html
216
Ein Steuerungsprogramm welches die zeitliche Ausführung mehrerer (Druck)Prozesse
regelt.
217
Hhttp://support.microsoft.com/kb/884897/de
Seite 276

1.2.6 Technische Umsetzung der Treiberfunktion
Der folgende Abschnitt bezieht sich auf die Kommunikation mit Druckern, die kein Post-
Script 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 Print-
Server 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 Post-
Script-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-PostScript-
Drucker 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 Core-
PostScript-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
218
der „Linuxpriniting.org―-DatenbankF
F 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.
1.2.7 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 Wrapper-
Skripte 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 Kerberos-
219
ProtokollsF
F.
218 http://www.linuxprinting.org/show_driver.cgi?driver=hpijs
219 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://CUPS-
DRUCKSERVER: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 XII.F 1.1.1.10 X angesprochen werden.
1.2.11 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 Linux-
Systemlandschaften 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 IPP-
Verwendung 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 Samba-
Print-Server kann dadurch seine ankommenden Druckaufträge per IPP an CUPS-Print-
Server 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 Möglichkeiten des Zusammenspiels von SAMBA und CUPS
1.3.1.1 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 Logon-
Scripts 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 CUPS-
Print-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 XII.F 1.1.2.1 X 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.
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 X)
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.
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 X) unterstützen. SMB wird dagegen eher
für die Verbindung von Clients mit älteren Windows Betriebssystemen (Windows 98 und
220
früher) verwendet F
F. Die Kommunikation zwischen Clients und Print-Server kann dabei
auf verschiedenen Transportprotokollen basieren, wie zum Beispiel:
220
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
221
drucken 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 X, Pfeil 1) erfolgt über LPR/LPD. Zu diesem Zweck
muss auf dem Arbeitsplatzsystem unter Windows der TCP/IP Print-Server installiert
222
seinF
F. 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.
221
siehe auch „Microsoft Windows 2003, Printer Connectivity Technical Overview―, Microsoft
Corporation, Published: March 2003,
http://www.microsoft.com/windowsserver2003/techinfo/overview/connectivity.mspx
222
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 Print-
Server 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 X, Pfeil 2a)
� die Übertragung der Daten vom Server zum Druckgerät
(siehe Abbildung 30 X, Pfeil 2b)
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 H\\servername\H
druckerfreigabename).
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 Print-
Server 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. Red-
Hat) 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 XAbbildung 1X), 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 Bei-
Seite 285

spiel das Löschen von Druckaufträgen. Demgegenüber steht allerdings, dass ein CUPS-
Server 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 & Print-
Technologie. 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 XII.F 1.1.1.10 X
aufgeführten unabhängigen und flexiblen Möglichkeiten, sofern die verwendeten Drucker
diese unterstützen.
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
223
sein.F
F 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ü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
224
den Microsoft Servern und den Clients zu installieren. F
F
1.4.7 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 http://www.microsoft.com/germany/technet/sicherheit/prodtech/windowsserver2003/
w2003hg/s3sgch08.mspx
224 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 XII.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.
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 Linux-
Arbeitsplatzrechnern muss auf jeden Fall deutlich zwischen Linux und Windows differen-
Seite 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:
� 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
2.1 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 PostScript-
Dateien 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 XII.F 1.1.2.2 X beschrieben
ist. Diese werden von fast allen Herstellern angeboten.
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 Bezüge
3.1 Systemmanagement und -überwachung
Der wichtigste Bezug besteht zum Themenblock des Systemmanagements und der Systemüberwachung
(Kapitel II.G „Thema System-Überwachungs- und -Management-
Dienste―). 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 „System-
Monitoring 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 Produkte / Technologien
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
� at
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.
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 BSI 225 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 IP-
Adresse 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 syslog-
Netzwerkprotokoll, 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.9 226 . 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 Homepage 227 .
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 überwachen 228 .
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 IT-
Infrastruktur, den IT-Diensten und zur Administration von Nagios selbst. Die wichtigsten
Funktionen sind nachfolgend aufgelistet:
� Ü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)
227 http://www.nagios.org/
228 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 Nagios 229 .
Der Installations- und Einrichtungsaufwand für eine Standardinstallation kann als vergleichsweise
gering angesehen werden 230 .
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 http://www.nagios.org/about/screenshots.php,
http://nagios.sourceforge.net/docs/3_0/quickstart.html
230 Die Installationsanleitung kann unter folgendem Link im Internet eingesehen werden:
http://nagios.sourceforge.net/docs/3_0/quickstart.html.
231 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
m23 232 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
Microsoft Systems Management
Server 2003 Device CML (Configuration
Management License) 1
Microsoft Systems Management
Server 2003 mit SQL Server 2000-
Technologie
Für jede erworbene Lizenz kann eine Kopie der Serversoftware
auf einem einzigen Server installiert und
genutzt werden.
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.
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 Quest 233 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:
� Softwarepatchverteilung
� Softwareverteilung
� Inventarisierung (Hardware und Software)
� Softwaremessungen
233 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 Webseite 235 „Unterstützte Konfigurationen für Microsoft
Operations Manager 2005― von Microsoft nachgeschlagen werden 236 :
Ü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:
� 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
234 http://www.microsoft.com/germany/mom/uebersicht/systemanforderungen.mspx
235 http://www.microsoft.com/germany/technet/datenbank/articles/600585.mspx#EEC
236 http://www.microsoft.com/germany/technet/datenbank/articles/600585.mspx#EEC
237 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 Manager 238 . 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:
� HP-UX (PA-RISC, Itanium)
� Solaris (SPARC)
238 https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-
15-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 System-
Management-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
Tivoli 239 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 System-
Managementfunktionen 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 Windows-
Lö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 Linux-
Systemen allgemein zugeschrieben wird, ist nicht zuletzt das Resultat des System-
Managements.
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 Bezüge
3.1 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 Produkte / Technologien
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 AG 243 ,entstanden. Im Sommer 2003 hat
die SKYRIX Software AG 244 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 http://www.opengroupware.org
243 http://www.skyrix.de
244 Skyrix ist ein kleines Unternehmen mit Sitz in Magdeburg (ca. 15 Mitarbeiter).
Seite 308

Der ZideLook Connector sowie instantOGo 245 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-Architektur 246
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 Weitere Information unter http://instantogo.com.
246 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
Loadbalancer 247 . 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.org-
Servers. 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 Der Loadbalancer steht im Rahmen des Wartungsvertrages zur Verfügung.
248 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 LDAP-
Directories bereit.
Über die MAPI-Schnittstelle von ZideLook kann auf Termine, Kontakte und Aufgaben
zugegriffen werden. Da die MAPI-Nachrichten aus Outlook dekodiert und im SQL-
Backend 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 Groupware-
Funktionen 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, Termin-
und 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ügung 249 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 Partnernetzwerk 250 bietet neben integrierten Open-Xchange-Lösungen
auch die Kompetenz zur Unterstützung bei der Planung, Implementierung und dem
Support von komplexen Integrationsprojekten.
249 http://www.open-xchange.com/header/community_area.html
250 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 Open-
Xchange gehören Unternehmen, Bildungseinrichtungen und Behörden mit z.T. mehreren
Tausend Endbenutzern pro Organisation.
Seit Februar 2007 bietet der Webhoster 1&1 252 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
Versionen 253 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-NonCommercial-
ShareAlike 2.5 254 vereinbart. Diese Edition von Open-Xchange bietet gegenüber Open-
Xchange 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. Installations-
und Konfigurationshinweise findet man im Wiki 255 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 Edition 256 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 Update-
Dienst, Anti-Virenschutz (ClamAv) und Anti-Spam (SpamAssassin).
251 http://www.open-xchange.com/DE/header/unternehmen/news_presse/referenzen.html
252 http://www.1und1.de/
253 http://www.open-xchange.com/wiki/index.php?title=Versioning_and_Numbering
254 http://www.open-xchange.com/header/community_area/faqs_ox_community_project.html
255 http://www.open-xchange.com/main_entry/community_area/wiki.html
256 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 Preisliste 257 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 Architektur 258
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 http://www.open-xchange.com/fileadmin/downloads/pricelist.pdf
258 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-OX-
Architecture.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 Mail-
und 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 iCal-
Format 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 gebaut 259 . Zum Zugriff und zur Erweiterung des Open-
Xchange Servers stehen die Programmierschnittstellen HTTP API, WebDAV API,
Oxmapi und Open-Xchange Hyperion CLT zur Verfügung 260 :
� HTTP API 261 wird von dem neuen AJAX-basierten Webclient genutzt. Der Daten-
austausch erfolgt in JavaScript Object Notation (JSON) über HTTP GET, POST
und PUT requests.
� WebDAV API 262 wird von externen Client-Anwendungen zur Modifikation von
Objekten auf dem Open-Xchange Server verwendet. Es basiert auf WebDAV-
Standard mit Erweiterungen für den Open-Xchange Server.
� Oxmapi 263 ist eine Windows Library zur Kommunikation von Windows-
Anwendungen mit dem Server.
� Open-Xchange Hyperion CLT 264 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 http://www.osedge.com/?q=node/22
260 http://www.open-xchange.com/wiki/index.php?title=Interfaces
261 http://typo3.open-xchange.com/wiki/index.php?title=HTTP_API
262 http://www.open-xchange.com/wiki/index.php?title=Oxwebdavapi
263 http://www.open-xchange.com/wiki/index.php?title=Oxmapi
264 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 aufges-
tellte 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 Angaben 266 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, LDAP-
Support)
� 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 (GPL2 267 ). 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 Weiterführende Informationen zu eGroupware: http://www.egroupware.org/
266 http://www.egroupware.org/references
267 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-Architektur 268
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 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
268 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 HTTPS-
Protokoll. 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 Projektseite 269 ist eine Synchronisierung von Kalender, Adressbuch und InfoLog-
Daten 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 Plugin 270 ), 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:
� 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 Client-
Landschaften Vorteile.
� Die Softwareaktualisierung erfolgt nur auf dem Server.
1.4 Zarafa
Die niederländische Firma ConecTUX entwickelt und vertreibt das Groupware-Produkt
Zarafa 271 . Vor fünf Jahren wurde mit der Entwicklung begonnen. Der Sitz der Zarafa-
Tochtergesellschaft (Zarafa Deutschland GmbH) für den deutschsprachigen Raum ist
Hannover.
Das Groupware-Produkt Zarafa wird derzeit von mehr als 1000 Unternehmen genutzt 272 .
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 Groupware-
Funktionalität inklusive Outlook nutzen.
269 Überblick Synchronisation - http://www.egroupware.org/sync
270 eGWOsync - http://www.egroupware.org/wiki?wikipage=synchronisation%20outlook
271 http://www.zarafaserver.de/
272 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 Webseite 274 .
Eine kostenlose Testversion kann aus dem Web bezogen und für 30 Tage genutzt werden,
eine Online-Demo steht im Web zur Verfügung 275 . Zarafa steht für verschiedene
Linux-Distributionen wie Debian, Fedora, RedHat, SuSE, OpenSUSE oder Ubuntu zur
Verfügung 276 .
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 Groupware-
Funktionen zur Verfügung.
Abbildung 34: Technische Zusammenhänge in Zarafa 277
273 Firmenauskunft
274 http://www.zarafaserver.de/prices.html
275 http://www.zarafaserver.de
276 http://download.zarafa.com/zarafa/en/zarafa_technical.pdf
277 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 SQL-
Datenbank
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 Exchange-
und 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-Push 278 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 SSL-
Verbindung 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 Linux-
Distributionen. Zarafa bietet im Rahmen von MAPI eine funktionale Outlook-
Unterstützung und einen entsprechenden Webclient (WebAccess). Eine PHP-MAPI-
Extension 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-Projekt 279 , 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 BLB 280 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-Konsortium 281 verfügbar. Desweiteren
erlaubt es die freie Lizenz (GPL) jedem, Erweiterungen, Verbesserungen und Veränderungen
an Kolab vorzunehmen.
279 http://www.kolab.org/
280 http://www.kbst.bund.de/cln_028/nn_837410/SharedDocs/Projekte/OSS/ kolab__einsatz__im__land__brandenburg.html
281 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
Horde-
Framework 282
Webclient (ab Kolab 2.2 integriert)
Tabelle 52: Zentrale Kolab-Server-Komponenten
Komponente Aufgabe
Amavisd-New Ansteuerung von Spamfilter und Virenscanner
zum Beispiel ClamAV
zum Beispiel SpamAssassin
Virenscanner
Spamfilter
Tabelle 53: Optionale Kolab Server-Komponenten
Das Softwarepaket des Kolab-Servers wird als sog. OpenPKG 283 -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. ClarkConnect 284 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 Server
286 , Pardalays 287 .
282 http://www.horde.org/
283 http://www.openpkg.org/
284 http://www.clarkconnect.com/
285 http://www.univention.com/ugs.html
286 http://www.intra2net.com/de/produkte/business_server.php
287 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 Kolab-
Systems 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 Referenz-
Client verwendet, bei Kolab 2 ist es Outlook 2003. Zudem werden andere Client-
Applikationen, 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 CCs 288 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-Client 289 , seine Daten auf
einem Kolab-Server zu speichern. Es stehen auf dem Markt auch noch andere
Connectoren 290 zur Verfügung, diese wurden jedoch im Rahmen der Evaluierung nicht
gesondert betrachtet. Ebenfalls von der Firma Toltec angeboten wird ein LDAP-
Adressbuch 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 KDE-
Oberflä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 E-
Mails (Spam, Viren usw.) auf der Clientseite. Darüber hinaus wird seit März 2007 verstärkt
an einer browserbasierten Clientanwendung gearbeitet, die auf das Horde-
Framework 291 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:
� Nutzer- und globale Adressbuchverwaltung
� Verwaltung der öffentlicher Ordner
� Verwaltung der Ressourcen- und Gruppenkonten
288 http://www.toltec.co.za/
289 Laut Hersteller Outlook 2000,, XP, 2003 und 2007
290 KONSEC Konnektor (http://www.konsec.com/),
Bynari Insight Connector (http://www.bynari.net/)
291 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
Ägypten 292 ist vom BSI erfolgreich auf Interoperabilität 293 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 genutzt
294 . Aktuell liegt Scalix in der Version 11.0.4 vom 3.5.2007 vor. Die Release Notes
zur aktuellen Version sind im Web abrufbar 295 .
292 Ägypten: http://www.gnupg.org/aegypten/index.de.html
293 Sphinx-Interoperabilitätstests:
http://www.bsi.bund.de/fachthem/verwpki/interoptests/testberichte.htm
294 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 MS-
Exchange 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-Intel-
System 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-Down-
Menüs, Drag-und-Drop-Funktionalität und eine Darstellung, die an eine echte Windows-
Applikation 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 Blackberrys 296 .
Abbildung 37: Scalix-Clientsysteme 297
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 http://www.scalix.com/documents/Scalix_DS_Enterprise_v3.pdf
297 http://www.scalix.com/enterprise/products/architecture.php
Seite 332

Abbildung 38: Scalix – Versionen/Funktionsüberblick 298
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 PBX 300 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 Rollen 301
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-Management-
Funktionen 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 Private Branch Exchanger
301 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üfen 302 . Hierfür setzt Microsoft das eigene Produkt ForeFront 303
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 Sophos 304
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 http://technet.microsoft.com/en-us/library/aa996551.aspx (Stand 01.11.2007)
303 http://www.microsoft.com/technet/forefront/serversecurity/exchange/scanning/e25af7f6-
8f6a-420a-8a8a-2360eec4c75a.mspx?mfr=true (Stand 01.11.2007)
304 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 Mashups 305 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 Groupware-
Systemen 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önnen 307 .
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 JXPlorer 308 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
http://sourceforge.net/project/showfiles.php?group_id=104103
307
http://www.selfadsi.de/att55mbx.htm
308
309
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 Mail-
Status (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 Readpst 311 . 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-Tool 312 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 http://www.linux-france.org/prj/imapsync/README
311 http://alioth.debian.org/projects/libpst/
312 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 Desktop-
beziehungsweise 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 Migration von E-Mail
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 MS-
Exchange-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 http://www.linux-france.org/prj/imapsync/README
Seite 343

kostenpflichtige Werkzeuge 314 , 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 LDAP-
Verzeichnisses 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 TechNet 315
zu finden.
314 http://www.aid4mail.com/
315 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 Anleitungen
316 , 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 Wizard 317 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 ist 318 .
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 http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-
2007-Part1.html
317 http://support.microsoft.com/kb/328871
318 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
Exchange Server 5.5 Nicht unterstützt
Exchange 2003 Unterstützt Unterstützt
Exchange 2000 Unterstützt Unterstützt
Seite 346
Migration auf Exchange 2007
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.
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 GmbH 319 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 File-
System oder auf einem Webserver mit WebDAV-Unterstützung zur Verfügung. Mit der
Integration von GroupDAV 320 erlaubt eGroupware die externe Bereitstellung und den
Austausch von Kalendern, Aufgabenlisten, Kontaktlisten und Notizen.
319 http://www.outdoor-training.de/
320 http://www.egroupware.org/index.php?page_name=sync&wikipage=GroupDAV

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-RPC-
API 321 . 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 Migration von E-Mail
Die E-Mail-Funktionalität wird in eGroupware nicht über eine eigene Mailserver-
Komponente, 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 VCard-
Format 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 LDAP-
Verzeichnisses 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 Service 322 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 http://www.egroupware.org/index.php?page_name=sync&wikipage=xmlrpc
322 http://www-12.lotus.com/ldd/doc/domino_notes/6.5/help65_admin.nsf/
b3266a3c17f9bb7085256b870069c0a9/bfd815f921a50c8d85256d9b004b022b?OpenDocu
ment
323 http://www.ibm.com/developerworks/lotus/library/lwp-msad/
Seite 347

ereits 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 Web-
DAV 324 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-Partner 326 bieten eine Vielzahl von Dienstleistungen zur Migration nach
Lotus Notes/Domino.
324 http://www-12.lotus.com/ldd/doc/domino_notes/Rnext/help6_admin.nsf/f4b82fbb75e942
a6852566ac0037f284/9ba6f9d0158ccf7c85256c1d00397996?OpenDocument
325 http://www.ibm.com/developerworks/lotus/downloads/toolkits.html#notesdomino
326 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
eGroupWare 327 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-, Aufgabenverwaltung
328 ; 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 LDIF-
Spezifikation 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 eGroup-
Ware-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 www.egroupware.org
328 www.egroupware.org/sync
Seite 349

auch anderen Servern (IMAP, SMTP, Samba etc.) zur Verfügung. Mit Cyrus oder DB-
Mail 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 http://www.linux-france.org/prj/imapsync/README
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
� 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.
3.3 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 Produkte / Technologien
Teamingsoftware oder Kollaborationsplattformen, wie sie auch gerne bezeichnet
werden, stehen hoch im Kurs, sowohl bei den Softwareherstellern als auch bei den IT-
Verantwortlichen 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
� usw.
o Versionierung/Archivierung
o Protokollierung
o Projekttagebuch führen
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 Dokumententypen 331 , -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 Funk-
Seite 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 HTTP-
Requests 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 Java-
Anwendungen 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.
1.1.3 Fazit
Tabelle 55: Funktionen von Mindquarry
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.0 333 .
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 http://www.bsi.de/fachthem/sinet/allgemeines/sinetstd.htm
333 http://www.bsi.de/literat/studien/web20/index.htm
334 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
Tabelle 56: SharePoint-Historie
Seite 362
Microsoft Office SharePoint Server
2007 335
Microsoft bietet aktuell unter der Bezeichnung SharePoint die Produkte Windows Share-
Point 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
werden 336 . 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 werden 337 .
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
Microsoft Office SharePoint Server 2007 entsteht aus der Zusammenführung und
Weiterentwicklung des Office SharePoint Portal Server 2003 und dem Content
Management Server 2002.
336
WSS setzt mindestens Windows Server 2003 mit den zugehörigen Client Access License
(CAL) voraus.
337
Microsoft Windows SharePoint Services
http://de.wikipedia.org/wiki/Windows_SharePoint_Services

WSS
Seite 363
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 Webseiten 338 .
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

Kollaboration Portal Suche
APPLIKATIONEN & DIENSTE (MOSS 2007)
Seite 364
Content
Management
Workflows
Business
Intelligence
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
Server-Topologien
Such Dienste
Abbildung 44: logische Architektur – SharePoint
Windows Worklfow Foundation
MOSS 2007 unterstützt verschiedene Architekturmodelle bezüglich der Server-
Topologie, 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 Basis-
Topologien vorsieht.
Small Farm
Jeder
(load-balanced)
Server
beinhaltet
- Web front end
- Anwendungen
Dedizierter
SQL Server
Medium Farm
Server mit
- Web front
ends
- Anwendungen
Anwendungsserver
SQL Server
Cluster
Large Farm
Index Suche Excel Project
SQL Server
Cluster
Abbildung 45: Topologien von Sharepoint Server Farmen
Web front end
Server
(load balanced)
Anwendungsserver

1.2.1.2 Protokolle und Schnittstellen
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 WebDAV 339 -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 Share-
Point 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 eDirectory
341 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 entscheiden 343 . 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 http://www.setfocus.com/technicalarticles/nickkellett/MOSS2007-and-Novell-LDAP-
Authentication_pg1.aspx
342 http://msdn2.microsoft.com/en-us/library/aa479030.aspx
343 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 Inhalten 345 und zu Web 2.0 346 berücksichtigt
werden.
1.2.2 Funktionalitäten
Den Funktionsumfang, den die Microsoft SharePoint Technologie bietet, wird von Microsoft
347 im Allgemeinen wie folgt dargestellt (siehe Abbildung 46):
Abbildung 46: Funktionalität von MOSS 2007
344 http://www.bsi.de/fachthem/sinet/allgemeines/sinetstd.htm
345 http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/index.htm
346 http://www.bsi.de/literat/studien/web20/index.htm
347 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
Office SharePoint
Server Enterprise CAL
Office SharePoint
Server CAL
Projektmgmt Team
Zusammen-
•Issue
Tracking
•Projekt
Arbeitsbereichearbeit•Arbeitsbereiche
und Tools
•Blogs
Workflow Dokument &
Web Content
Management
•5 Workflows
mitgeliefert
•Reporting
für ECM
•Windows
Workflow
Foundation
•Admin und
Deployment
•Status und
Historie
•Policy
•Verwaltung
•Auditing
•Records
Management
•Web CM
•Framework:
Repository,
Versionierung,
Metadaten
•Basis
Dokumentenmanagement
Site-Modell,
Sicherheit
und
Verwaltung
•Personalisierung
•Deployment
•Site Manager
•Site und
Rollenmanagement
Infrastruktur
Seite 370
Search
• Business
Data
Catalog
•Erweiterbare
und
anpassbare
Suche nach
Unternehmens
-daten und
Personen
•Textsuche
in
Teamsites
Datenintegration
•Business
Data
Catalog
•Webpart
Integration
Abbildung 47: Funktionalitäten der verschiedenen SharePoint Editionen
E-Forms Datenmanagement&
•Verwaltung,
Publishing,
Prozess-
Erzeugung
und
Abschluss
Reporting
Windows SharePoint
Services**
•Spreadsheet
Publishing &
Berechnung
•Report
Center
**Included with Windows Server and CAL licenses
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
Services
Web
Content
Services
WSS MOSS Standard MOSS Enterprise
� Zentrale Administration
� Site Administration
� Eingehende Emails
� WSS Suche
� WSS WebApplikation
- -
-
Details
� Publizieren
� Content Verteilung
� Variations
(Mehrsprachigkeit)
348 Die Abbildung 47 hat keinen Anspruch auf Vollständigkeit
incl. incl.
� EXCEL Service
� InfoPath Forms Service
� Business Data Catalog
incl.

Funktionsbereiche
Portal
Services
Features
Website
vorlagen
Site
Templates
WSS MOSS Standard MOSS Enterprise
� Mobility Shortcut URL
� Team-Zusammenarbeitslisten
� Standard Inhaltstyp
Definitionen
� Standard Feld -
definitionen
� Issue Tracking
� Workflows
� Ereignismeldungen
(Alerts)
� Diskussionen
-
� RSS Feeds
� Daten Verbindung
Bibliothek
� Leere Website
� Team Website
� Dokument
Arbeitsbereich
� Wiki Website
� Blog
� Besprechung
Arbeitsbereich
� Profile
Seite 371
Details
� Personalisierung
� Zielgruppen
� Dokumenten und
Record Verwaltung
� Office Suche
� Dokument -
konvertierungen
� Dokumenten Center
Erweiterungen
� Übersetzungs-
bibliotheken
� Publizieren
� „Out of the box―
Workflows
� Reporting
- -
� Berichts und
Auswertungscenter
� Dokumentencenter
� Persönliche Site
� Suchportal
� Kollaborationsportal
� Websiteverzeichnis
� Content Management
� Publizieren mit
Workflow
Tabelle 58: Produktfunktionsmatrix 349
incl.
incl.
Office Enterprise:
� Business Data
Catalog
� Forms services
� Excel services
� Key Performance
Indikator und einige
Business
Intelligence Web Parts
349 MS Press „Microsoft Office SharePoint Server 2007 Administrator's Companion‖
incl.

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 Collection 350 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.
Site
Collection
Ausschnitt
Ausschnitt
Ausschnitt
Feld 1 Feld 2 Feld 3 Feld 4
Eintrag 1 ----- ----- ----- -----
Eintrag 2 ----- ----- ----- -----
Eintrag 3 ----- ----- ----- -----
Eintrag 4 ----- ----- ----- -----
Seite 372
Felder
Top-level
Web Site
Subsites
Subsites
Listeneinträge
Listen
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.

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 Types 351
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 mitgeliefert
352 , die bereits einige Basisanforderungen abbilden:
� 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.
352 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-SharePoint-
2007-_2800_Teil-2_3A00_-Integrierte-SharePoint-Server-Workflows_2900_.aspx
353 Bei den Begriffen in Klammern handelt es sich um die Originalbezeichnungen der engli-
schen 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 Microsoft 354 nur aus einer MS Office
2007 Anwendung (Word oder Excel) heraus gestartet und nur mit einem solchen
Client auch unterzeichnet werden 355 .
� 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 http://office.microsoft.com/en-us/sharepointserver/HA101544281033.aspx
355 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
Ribbon 356 zum Erstellen von Blog-Einträgen angeboten.
� Inhalte für Webseiten können erstellt und veröffentlicht werden (Funktion wie
vor).
Excel 2007
Access 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.
� 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 Access-
Dateien (.mdb) in SharePoint verwaltet und versioniert werden können.
Outlook 2007
� 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.
356 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 Emails 357 (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 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.
o 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 Share-
Point 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 Technologie / Architektur
1.3.1.1 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-Server-
Synchronization 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 Protokolle und Schnittstellen
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 werden 358 .
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 Open-
Office.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
Einfaches Roaming � - -
Keine Serverinstallation � - -
Kleine lokale Installation, Sicherheit durch
den Hersteller
Seite 388
� - -
Automatische Updates � - �
Upgrade und Update Services � - �
Backup und Recovery � extern extern
Sicherheit und User Management über
User, Gruppen Rollen und Rechte
Management
� � �
Online Community Support � � �
LDAP � � �
Online Professional Support � - �
Bugs & Patch Support � - �
Integrierte Hilfefunktion � - �
Support zum Clustering - - �
Server basierte Installation mit unlimitierter
Benutzerzahl
Automatische Versionierung, checkin/check-out
Funktion
-
limitiert auf
10 Benutzer
�
� � �
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

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 + Conferencing 359 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 wurde 360 .
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 ICEcore Enterprise
adds:
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
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
Open source Novell Teaming+
Conferencing
Seite 389
ICEcore
add-on
modules
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 gesprochen Teaming plus Conferencing
360 http://www.sitescape.com/
361 http://en.wikipedia.org/wiki/Common_Public_Atvontribution_License

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 Betrachtung 362 .
1.4.1 Technologie/Architektur
1.4.1.1 Novell Teaming
Architektur
Für eine Installation der Teamingsoftware sind nachfolgend aufgelistet die Hard- und
Software Voraussetzung 363 , (alle weiteren Komponenten liefert das Installationspaket):
� Hardware
� Software
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.
o Sun JDK 1.5.0_011 364 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 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
363 Eine genaue Beschreibung findet man im Installation and Configuration Guide,
http://www.novell.com/documentation/team_plus_conf/team102_instconfig/ data/bookinfo.html
364 Entspricht der von neu verwendeten Versionsnummerierung JDK 5 (siehe
http://java.sun.com/javase/downloads/index_jdk5.jsp)
365 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 Tomcat 366 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
Protokolle und Schnittstellen
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:
� JDBC für den Zugriff auf die Datenbank
� LDAP für die Integration von Verzeichnissen, z.B. für die Benutzerverwaltung
366 http://tomcat.apache.org/
367 Aus dem Installation and Configuration Guide der Firma Novell (siehe
http://www.novell.com/documentation/team_plus_conf/)
368 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ösung 369 . 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 http://www.novell.com/products/accessmanager/overview.html
370 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.
1.4.1.2 Conferencing Server
Systemvoraussetzungen 371
Abbildung 56: Enterprise Admin Portlet
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 Details werden im „Server Installation Guide― von Novell beschrieben
http://www.novell.com/documentation/team_plus_conf/conf10_svrinst/data/bookinfo.html
372 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.
Die Komponenten sind im Einzelnen:
Abbildung 57: Architektur Novell Conferencing 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―
373 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 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.
375 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 Conferencing 376
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
IM & Chat
Presänz
Diskussion
Integrierte
Suite
Verwaltung
Foren
Web Konferenzen
1.4.2.1 Teaming Funktionen
Funktionen
Seite 397
Blogs
Wikis
Gemeinsame
Dokumente
Workflow
Aufgabenverwaltung
Termin- & Kalender
Verwaltung
Abbildung 59: Workflow gesteuerte Collaboration
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 Details
Team/globale Arbeitsplätze � 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

Funktionen Details
Team Calendars & Tasks � 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
Dokumentenmanagement � Benutzer können Dokumente (Dateien) in den Ordner hochladen.
Bezüglich der Verwendung von unterschiedlichen Dateiformaten
377 gibt es keine Einschränkungen. Einschränkungen
gibt es höchstens in der weiteren Verwendung (siehe nächsten
Punkt)
Workflow � Einfacher Workflow
� 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‖
� Manuelles ändern des Status
� Zugriffskontrolle
� Benachrichtigung
� Erweiterter Workflow
� Komplexe Übergänge
� Gleichzeitiger Workflow
Sonstige Teamfunktionen � Befragungen / Surveys
� Wikis
� Blogs
� RSS
� Dashboard
Suche Es wird eine einfache / schnelle Suche bereitgestellt.
377 siehe auch Formatliste im Anhang
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
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 Workflow 379
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 Teaming 380
379 Aus Administration Guide
http://www.novell.com/documentation/team_plus_conf/team10_admin/data/bookinfo.html
380 Aus Administration Guide
http://www.novell.com/documentation/team_plus_conf/team10_admin/data/bookinfo.html
Seite 401

Den Workflow kann man dann mit einem Ordner verbinden, in welchem man den Workflow
nutzen möchte 381 .
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 hochladen 383 . 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 Details werden im Administration Guide zu Novell Teaming beschrieben
http://www.novell.com/documentation/team_plus_conf/team10_admin/data/bookinfo.html
382 Siehe Administration Guide zu Novell Teaming
http://www.novell.com/documentation/team_plus_conf/team10_admin/data/bookinfo.html
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 Details
Telefon- (Sprach)konferenzen � Unterstützt VOIP
Web-Konferenzen
Seite 403
� Full Duplex (mehrere können zur selben
Zeit sprechen)‏
� Sprachintegration in einer Webkonferenz
� 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
1.4.3 Fazit
� Bidirektional
� Gruppen
� Dateitransfer
� Emoticons
� Aufzeichnen von Gesprächen
� Persönliche Historie zu Personen
� Virusschutz
� Systemmonitoring
Tabelle 62: Novell Conferencing Funktionen
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 Echtzeit-
Zusammenarbeit 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

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öffentlicht 384 . Lotus Quickr lag
zum Zeitpunkt der Erstellung dieses Kapitels 385 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 http://www-03.ibm.com/press/us/en/pressrelease/21756.wss
385 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 Technologie/Architektur
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 beschrieben 386 . Nachfolgend wird versucht, an zwei Beispielen die Unterschiede
zu verdeutlichen.
Services für IBM WebSphere
Portal
Linux x86
Betriebssystem Red Hat Enterprise Linux (RHEL)
Enterprise Server (ES),
Advanced Server (AS),
Workstation (WS) and Desktop
for x86-32 V4.0 Update 4
Hardwareanforderungen
� Minimum 4 GB free disk space
for installation for IBM Lotus
Quickr
� CD-ROM drive
� Processor: CPU speeds of latemodel,
mid-range to high-end
servers are re-commended.
Pentium 1 GHz or equivalent at
a minimum.
Production environments should
consider the Pentium 4
processor at 2.5 GHz or higher.
Seite 406
Services für IBM Lotus Domino
Windows
� Microsoft Windows 2003
Standard Edition Server Service
Pack 1 and 2 (Microsoft product
site)
� Microsoft Windows 2003
Enterprise Server
� RAM - 512 MB or more is
recommended
� Disk space - 1.5 GB or more is
recommended
� Disk swap space - 2 times
physical RAM installed
� CD-ROM drive
� Processor: CPU speeds of latemodel,
mid-range to high-end
servers are recommended.
Pentium 1 GHz or equivalent at
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
� 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
-
HTTP server included with Lotus
Domino

Web Browser
LDAP-Verzeichnisserver
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)
Services für IBM WebSphere
Portal
Linux x86
� Microsoft Internet Explorer 7.0
for Windows XP
� Microsoft Internet Explorer 6.0
SP2 for Windows XP
� FireFox V2.0
� IBM Tivoli Directory Server 6.0
� IBM Tivoli Directory Server 5.2
� 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
� Windows Active Directory
Applilcation Mode (ADAM) 2003
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
� IBM Lotus Domino 7.0.2, 7.0.1,
6.5.5, & 6.5.4
� 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
Seite 407
Services für IBM Lotus Domino
Windows
� Microsoft Internet Explorer 7.0
for Windows
� Microsoft Internet Explorer 6.0
SP2 (and patches) (Microsoft
product site)
� Mozilla FireFox V1.7
� Apple Safari 1.2.2 and 1.2.4 on
Mac OS X version 10.4
� IBM Tivoli Directory Server 5.2
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
Java Runtime Environment
Version 5.0
IBM Lotus Sametime 7.5 or 7.5.1
External Security Software - � Netegrity SiteMinder 5.5 and 6.0
Software for license
management
IBM Tivoli License Compliance
Manager
� Multi-Server/LTPA
-

Feeds Support
Services für IBM WebSphere
Portal
Linux x86
� 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
� Atom: 1.0
� RSS: not supported
Seite 408
Services für IBM Lotus Domino
Windows
Konnektoren - � Lotus Quickr connector for
Lotus Notes
� Lotus Quickr connector for
Sametime
� Lotus Quickr connector for
Microsoft Windows Explorer
� Lotus Quickr connector for
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 Protokolle und Schnittstellen
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

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 werden 387 :
� 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 nutzen 388 .
Services für WebSphere Portal 389
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 einnimmt 390 .
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 Laut Administratorhandbuch sogar mehr als einen, siehe
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
389 Siehe Administratorhandbuch für Lotus Quickr
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
390 Siehe Administratorhandbuch für Lotus Quickr
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
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 Inhalten 392 und zu Web 2.0 393
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:
� 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)
391 http://www.bsi.de/fachthem/sinet/allgemeines/sinetstd.htm
392 http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/index.htm
393 http://www.bsi.de/literat/studien/web20/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
Dokumentenmanagement 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ügung 394 .
� PlaceBots ermöglichen die automatisierte Verfolgung
und Überwachung von Tasks
RSS-Feeds Können in verschiedenen Arbeitsbereichen, wie zum
Beispiel Blogs oder Wikis eingerichtet werden.
394 Siehe Benutzerhandbuch und Administrationshandbuch
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
Seite 413

Funktionen Details
Echtzeit-Kolaboration Chatfunktion und Präsenzanzeige können durch die
Integration von IBM Lotus Sametime mittels des verfügbaren
Konnektors und entsprechender Konfiguration 395
bereitgestellt werden.
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.
Struktur der Arbeitsbereiche
Tabelle 64: Funktionen von Lotus Quickr Services für Domino
Für die Zusammenarbeit in Arbeitsgruppen werden in Lotus Quickr Bereiche bereitgestellt.
Bereich werden dabei durch Lotus Notes-Datenbanken (NSF-Dateien) realisiert 396 .
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ügung 397 :
395 Siehe Benutzerhandbuch und Administrationshandbuch
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
396 Mehr zu Schablonen finden Sie unter
http://www.ibm.com/developerworks/lotus/documentation/dominodesigner/
397 Siehe Benutzerhandbuch, Services für Lotus Domino, Abschnitt: „Einen Bereich erstellen―
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
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 werden 399 .
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 Workflows 400 . Zu den mitgelieferten
398 http://www-306.ibm.com/software/lotus/products/dominodesigner/
399 http://templates.snapps.com/
400 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
Dokumentenmanagement � 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 Details
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 Workflows werden bei Verwendung der Services für
WebSphere Portal durch die sogenannten Verbundanweisungen
realisiert 401 .
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
bereitgestellt werden.
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 Text-
Editor‖.
Um Desktopanwendungen, wie zum Beispiel Office-
Anwendungen, 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
angegeben 403 .
401 Siehe Benutzerhandbuch und Administrationshandbuch
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
402 Siehe Benutzerhandbuch und Administrationshandbuch
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
403 Es werden allerdings keine Angaben zu Versionen gemacht (siehe
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp)
Seite 417

Funktionen Details
Suche In Lotus Quickr Services für Portal stellt eine Portalsuchfunktion
zur Verfügung. Damit wird die Indexierung von
Informationsquellen erleichtert und die Suche verbessert.
Bereichsstrukturen 404
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
Auch hier erfolgt die Strukturierung nach Bereichen, dabei werden beim Anlegen eines
neuen Bereichs folgende Bereichstypen angeboten:
� 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.
404 Siehe Benutzerhandbuch und Administrationshandbuch
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
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 verwendet 405 . 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:
� 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-
405 Siehe Lotus Quickr Benutzerhandbuch, Services für WebSphere Portal, Verbundanwendungen,
http://publib.boulder.ibm.com/infocenter/lqkrhelp/v8r0/index.jsp
Seite 419

� Lotus Domino
tellt, der Zugriff auf den/die Server gesteuert und andere Konfigurationen
verwaltet werden können.
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 Fazit
� 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.
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 Produkte / Technologien
Im Fokus der nachfolgenden Betrachtung zu den Office-Suiten stehen die Standard-
Anwendungen 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 Open-
Office.org. Im Jahre 2000 hat Sun Microsystems den Quelltext des damaligen Office-
Pakets StarOffice 5.2 in das Open Source Projekt OpenOffice.org überführt. Das OpenOffice.org
Projekt steht unter der Lizenz LGPL 406 (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 Packs 408 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 OA-
SIS 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 Die aktuellen Service Packs sind seit Oktober 2007 für StarOffice 6 (Service Pack 8), Star-
Office 7 (Service Pack 11) und StarOffice 8 (Service Pack 8) erhältlich.
408 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

Calc (Tabellenkalkulation)
Abbildung 64: Der Navigator in OpenOffice.org Writer
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- sowie 3D-Grafiken
erstellen und bearbeiten lassen. Es sind Vorlagen für Zeichnungselemente und
eine Auswahl an anpassbaren Formen enthalten. Dazu zählen Standardformen,
Symbolformen, Blockpfeile, Flussdiagramme und Legenden für das Einfügen von
Kommentaren. Tabellen, Diagramme, Formeln und andere in OpenOffice.org erzeugte
Elemente können in Zeichnungen einfügt werden.
� Math (Formeleditor)
Bei Math handelt es sich um ein Tool, mit dem sich grafisch mathematische Gleichungen
und komplexere Formelstrukturen darstellen lassen. Dieser Formeleditor
darf jedoch nicht mit einem mathematischen Rechenprogramm verwechselt
werden. Die Funktionen beschränken sich ausschließlich auf die grafische Erstellung
und Bearbeitung mathematischer Formeln.
� Base (Datenbank)
Mit Base enthält OpenOffice.org erstmals ab der Version 2 ein eigenes Modul für
die Verwaltung, Erstellung und Bearbeitung von Datenbanken und bringt mit
HSQLDB zugleich ein JAVA-basiertes, plattformunabhängiges und relationales
SQL-Datenbank-Management-System mit, das seine Daten in HSQL-
Datenbanken im XML-Format speichert.
Sun Microsystems stellt seit Oktober 2007 einen Report Builder zur Verfügung,
der die Erstellung von Datenbank-Reports deutlich vereinfacht und verbessert.
Seite 425

Neben den hier genannten Funktionsbausteinen existieren viele freie und proprietäre
Lösungen, die OpenOffice.org ergänzen und Bereiche (zum Beispiel Calendaring-
und Groupware-Funktionen) abdecken, die von den Microsoft Office Anwendungen
adressiert werden 409 .
1.1.1.2 Programmierung, Makros und Automatisierungsmöglichkeiten
Die teilweise sehr intensive Nutzung der Office-Programmierung muss sowohl im Hinblick
auf die Schwierigkeiten, die diese immer wieder mehr oder weniger für jede Form
der Migration mit sich bringen und die Interoperabilität mit anderen Office-Anwendungen
behindern, als auch im Hinblick auf eine geordnete Wartung und zielgerichteten Support
für solche Softwarestücke, die z.T. sehr versteckt an vielen Stellen in der Office-
Software-Landschaft auftauchen, als zweifelhaft angesehen werden. Grundsätzlich ist
festzuhalten, dass es, wenn es darum geht komplexe Anwendungen zu entwickeln, bessere
und professionellere Lösungsalternativen gibt, die insbesondere mit Blick auf
durchzuführende Migrationen und die Wartung und den Support für solche Anwendungen
deutlich besser eigenen.
Trotz allem sollen die verfügbaren Konzepte hier kurz vorgestellt werden, auch um an
verschiedenen Punkten die Problemstellungen deutlich zu machen,
OpenOffice.org und StarOffice unterstützen das Konzept der Einbettung von Programmcode
in Dokumente und Vorlagen in Form von Makros. Dafür ist in die Office-Suite eine
Entwicklungsumgebung (IDE) integriert, die es dem Anwender ermöglicht, Makros aufzuzeichnen,
zu bearbeiten und zu testen. Neben StarOffice Basic 410 (auch bekannt als
StarBasic und OOoBasic), einem Basic-Dialekt, der der in MS Office verwendeten Sprache
VBA ähnelt, zu diesem aber nicht kompatibel ist, lassen sich Makros auch in den
populären Skriptsprachen Python und JavaScript entwickeln.
Die Nutzung von Makros sollte aus Sicht der IT-Sicherheit grundsätzlich zurückhaltend
erfolgen, da mit diesen Mechanismen auch die Ausführung von bösartigen Makros erfolgen
kann. Dies hat in der Vergangenheit immer wieder zu kleineren und größeren negativen
Auswirkungen geführt.
Für komplexere Erweiterungen der Office-Suiten sowie die Integration mit elektronischen
Geschäftsprozessen und externen Anwendungen bieten OpenOffice.org und StarOffice
die Möglichkeit, sogenannte Extensions 411 hinzuzufügen. Diese sprechen die Office-
Suiten über eine dokumentierte Programmierschnittstelle 412 (API, Application Programming
Interface) an, welche auf der Komponententechnologie UNO 413 (Universal Network
Objects) basiert. Diese ist programmiersprachenunabhängig realisiert und ermöglicht
derzeit, Erweiterungen in C++, Java, Python, CLI (C#, VB.NET und andere Sprachen der
409
http://wiki.services.openoffice.org/wiki/OpenOffice.org_Solutions.
410
Eine Einführung in StarBasic ist unter http://docs.sun.com/app/docs/doc/819-0439?a=load
erhältlich.
411
Ein ähnliches Konzept verfolgen auch der Browser Firefox und der Mail-Client Thunderbird.
412 Siehe http://api.openoffice.org/.
413 Siehe http://udk.openoffice.org/.
Seite 426

.NET-Familie, (vorausgesetzt, es ist eine „.NET-Anbindung― für die jeweilige Plattform
vorhanden), StarBasic, JavaScript und OLE Automation zu schreiben.
Für StarOffice und OpenOffice.org sind jeweils eigene Software Development Kits 414
(SDKs) erhältlich, die Dokumentation und Entwicklungstools zu den Programmierschnittstellen
enthalten. Darüber hinaus gibt es ein Plugin 415 für die Entwicklungsumgebung
NetBeans, welches verschiedene Programmiertasks deutlich erleichtert.
Wizards vereinfachen die initialen Schritte, um Projekte neu aufzusetzen. IDE Support
wie Code-Vervollständigung und kontextsensitive Hilfe vereinfachen das Arbeiten mit
dem API der Office-Suiten. Das Plugin ist kostenlos über das integrierte Plugin Update
Center von NetBeans verfügbar. Die Verfügbarkeit des Quellcodes von OpenOffice.org
sowie die LGPL-Lizenz ermöglichen es außerdem, dass Lösungen, die für einen
Anwender beziehungsweise eine Behörde entwickelt wurden, sehr leicht auch mit
anderen Anwendern beziehungsweise Behörden geteilt werden können; das heißt,
Lösungen müssen nicht mehrfach gekauft und bezahlt werden.
1.1.1.3 Dateiformate
Eine der zentralen Neuerungen von OpenOffice.org 2 und StarOffice 8 ist die Einführung
von ODF (OpenDocument-Format) als Ersatz für das bislang verwendete proprietäre
StarOffice-Format. Ersteres basiert zwar auf letzterem, wurde aber in einem offenen
Standardisierungsverfahren bei OASIS und später bei der ISO weiterentwickelt und erfreut
sich zunehmender Verbreitung und Unterstützung in den Produkten vieler namhafter
Hersteller. Sofern nicht explizit angegeben, werden Dokumente in OpenDocument
Format gespeichert.
Dokumentenart Datei-Endung
Textverarbeitung odt
Textverarbeitung (Vorlage) ott
Zeichnung odg
Zeichnung (Vorlage) otg
Präsentation odp
Präsentation (Vorlage) otp
Tabellenkalkulation ods
Tabellenkalkulation (Vorlage) ots
Diagramm odc
Diagramm (Vorlage) otc
Grafik odi
Grafik (Vorlage) oti
414 Das OpenOffice.org SDK findet sich unter http://api.openoffice.org/SDK/index.html, das
StarOffice SDK unter http://www.sun.com/software/star/staroffice/sdk/index.jsp.
415 Siehe http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration.
Seite 427

Dokumentenart Datei-Endung
Formel odf
Formel (Vorlage) otf
Textverarbeitung (Master-Dokument) odm
Textverarbeitung (HTML-Vorlage) oth
Tabelle 66: Datei-Endungen von ODF-Dokumenten
Eng damit verknüpft sind die zahlreichen integrierten Import- und Exportmöglichkeiten in
Datei–Formate anderer Applikationen. Eine komplette Liste aller unterstützten Dateiformate
würde den Rahmen dieses Dokumentes sprengen. Daher folgt eine Auswahl der
wichtigsten unterstützten Dateiformate anderer Hersteller:
Dateiformat Import Export
OpenOffice.org 1.x Dokumente Ja Ja
Microsoft Office 6.0, 95 und 97/2000/XP
(.doc)
Seite 428
Ja Ja
Microsoft Word 2003 XML (.xml) Ja Ja
Rich Text Format (.rtf) Ja Ja
StarOffice 3.0, 4.0 und 5.0 Ja Ja
Text (.txt, .csv) Ja Ja
(X)HTML (.xhtml, .html, .htm) Ja Ja
DocBook (.xml) Ja Ja
AportisDoc (Palm) (.pdb) Ja Ja
Pocket Word (.psw) Ja Ja
PDF Nein Ja
Adobe Flash Nein Ja 416
1.1.1.4 XML-Technologie
Tabelle 67: Import- und Exportmöglichkeiten in OOo /SO
Durch zahlreiche frei zugängliche Schnittstellen (zum Beispiel Simple API for XML -
SAX, Document Object Model - DOM) und das offene XML-basierte Dateiformat ermöglicht
OpenOffice.org einen flexiblen Zugriff auf alle Funktionen und Daten zum Erzeugen,
Durchsuchen, Zugreifen, Ändern und Löschen von Dokumentinhalten. Neben Open-
Office.org existieren weitere Anwendungen wie z. B. KOffice 417 , Suns StarOffice und
416 Nur Präsentationen
417 http:/www.koffice.org

Google Docs and Spreadsheets, die ebenfalls das in einem öffentlichen Entwicklungsprozess
entstandene OASIS OpenDocument Format verwenden.
Durch das XML-Format und die Entwicklung von Softwarekomponenten kann eine weitgehende
Portabilität der ODF-Dokumente von und zu Office Open XML-Dokumenten
(OOXML) erreicht werden. OOXML ist das von Microsoft favorisierte neue XML-basierte
Standard-Dateiformat in MS Office 2007 418 (siehe auch Kapitel III.C 1.2.4).
Einschränkungen bilden dabei vor allem komplexere Dokumente und eingebettete Tabellen.
Aufgrund des auf XML-basierenden Dateiformats ODF ist die Verwendung anderer
XML-Standards durch XSLT zum Filtern und Konvertieren von XML-Strukturen problemlos
möglich.
Eine Kommunikation über SOAP zu Web Services in OOo/SO besteht derzeit nicht,
kann aber über Java Web Service Bibliotheken implementiert werden.
In OpenOffice.org Dokumenten können HTML-konforme Elemente für die Gestaltung
von Eingabefeldern und Formulare genutzt werden. Ebenfalls unterstützt wird der vom
W3C-Konsortium spezifizierte Standard XForms 419 zur Definition von Formularseiten.
In Bezug auf das Arbeiten mit anwendungsspezifischen XML-Dokumenten beinhalten
beide Office-Suiten einen XSLT-Prozessor, der es erlaubt, Import- und Exportfilter für
beliebige XML-Dateiformate zu erstellen. Mitgeliefert werden zum Beispiel Filter für die
XML-Dateiformate von Microsoft Word 2003 und Excel 2003, sowie auch DocBook, ein
XML-Format, das vorwiegend für die Erstellung technischer Artikel, Bücher und Dokumentationen
verwendet wird.
1.1.1.5 Webservice basierte Integration
Für die Webservice-basierte Integration besitzt OpenOffice.org ebenso wie MS Office
auch ein API 420 . Das OpenOffice.org API ist unabhängig von einer Programmiersprache
oder einem Betriebssystem formuliert. Derzeitig lässt sich OpenOffice.org 2 in den Programmiersprachen
Java, C++, StarBasic und unter Windows mittels OLE/COM-Steuerung
programmieren. Alle Programmiersprachen verwenden dabei das gleiche API, das heißt
das API stellt unabhängig von den verwendeten Dialekten die gleichen Entwicklungsmöglichkeiten
bereit. Sowohl in Java als auch in C++ ist die Entwicklung von Komponenten
möglich, die als Plug-In innerhalb von OpenOffice.org verschiedenste Aufgaben erfüllen
können:
� Neue Chart-Typen
� Neue Calc Funktionen
� Wizards
� Zusätzliche Funktionalität für den Benutzer
� StarBasic Erweiterung.
418 OOXML wurde durch ECMA (European Computer Manufacturers Association) im Dezember
2006 als ECMA-Standard 376 verabschiedet. Die ISO-Standardisierung ist beantragt.
419 http://www.w3c.org/TR/xforms
420 Alle wesentlichen Informationen hierzu unter: http://api.openoffice.org/ (Onlinedokumentation).
Die Spezifikation der Schnittstelle findet sich unter: http://udk.openoffice.org/ .
Seite 429

StarBasic ist die integrierte modulare Skriptsprache in OpenOffice.org und folgt den gleichen
Prinzipien wie VBA. Struktur und Syntax beider Sprachen sind in großen Teilen
sehr ähnlich, wodurch die Portierung vorhandener VBA-Makros nach StarBasic erleichtert
wird.
Neben dem API stellt OpenOffice.org genau wie MS Office eine Entwicklungsumgebung
(Integrated Development Environment (IDE)) zur Verfügung, deren Benutzerschnittstelle
sehr an die der Entwicklungsumgebung von MS Office angelehnt ist, weitere Hinweise
zur Programmier- und Entwicklungsumgebung finden sich im Abschnitt III.C 1.1.1.2,
Programmierung, Makros und Automatisierungsmöglichkeiten).
1.1.1.6 Erweiterungen in StarOffice8
In der Enterprise Edition von StarOffice8 werden einige weitere Funktionalitäten geliefert.
Dazu gehören ein Hilfsmittel zur Migration von Makros und Analysetools zur Risikobewertung
und -abschätzung von Migrationsmöglichkeiten einzelner Dokumente. Darüber
hinaus ersetzt das Java Desktop System (JDS) den aus StarOffice 7 integrierten
StarOffice Configuration Manager.
1.1.2 OpenOffice.org 1 / StarOffice 7
Bei OpenOffice.org 1.x und StarOffice 7 handelt es sich um die Vorgängerversionen der
in Abschnitt III.C 1.1.1) beschriebenen Office-Suiten OpenOffice.org 2.x und StarOffice
8. Um Redundanzen zu vermeiden, konzentriert sich dieser Abschnitt auf die Unterschiede
zu den oben genannten aktuellen Versionen.
OpenOffice.org 1 wurde im Jahr 2002 veröffentlicht und ging damals als frei erhältliche
Office-Variante aus dem Quellcode des kostenpflichtigen StarOffice 5.2 hervor. Die offensichtlichste
Neuerung gegenüber der alten StarOffice-Version ist der Verzicht auf den
integrierten Desktop. In mehreren Stufen wurden Updates angeboten, die u.a. in der
Version 1.1 den Export in PDF-Dateien und - in einigen Komponenten - Flash-Dateien
realisieren, ohne dabei zusätzliche Software installieren zu müssen. Die Integration eines
XSLT-Prozessors ermöglicht zusätzlich die Einbindung anderer XML-Dateiformate
und gestattet den Export von OpenOffice-Dateien in andere XML-Formate (DocBook,
XHTML, Word 2003 etc.).
Die letzte Aktualisierung von OpenOffice.org 1.1 fand unter der Versionsnummer 1.1.5
im Jahre 2005 statt. Fast parallel mit dem Release von OpenOffice.org 2 wurde ein Importfilter
für das damals neue OpenDocument Format integriert, der das Öffnen und Lesen
von Dokumenten der Version 2 ermöglichen sollte.
Korrespondierend dazu bot Sun Microsystems StarOffice 7 an, welches auf den Quellen
von OpenOffice.org 1.1 basiert. Neben professioneller Qualitätssicherung und erweitertem
Support enthält StarOffice 7 Folgendes:
� Die Datenbankanwendung AdabasD
� Eine kostenpflichtige Rechtschreibprüfung
� Stark erweiterte ClipArt- und Vorlagenbibliotheken
� Import- und Exportfilter für WordPerfect-Dokumente
Seite 430

� Zusätzliche Schriftarten
� Eine angepasste Benutzeroberfläche.
1.1.2.1 Bestandteile und Funktionalitäten
OpenOffice.org 1.1 beinhaltet die folgenden und bereits betrachteten Einzelanwendungen:
� Writer
� Calc
� Impress
� Draw
� Math
Die Datenbankkomponente Base kam erst in der OpenOffice.org 2-Suite beziehungsweise
StarOffice 8 hinzu. Ersatzweise war in StarOffice7, wie erwähnt, die Datenbankanwendung
AdabasD der Software-AG enthalten.
Unterschiede des Funktionsumfanges von OpenOffice.org 1.x und StarOffice 7 gegenüber
der Nachfolgeversion können dahingehend differenziert werde, dass sie einerseits
das Office-Paket in seiner Gesamtheit betreffen, oder sich andererseits nur auf bestimmte
Kernkomponenten erstrecken:
Allgemeine Unterschiede:
Openoffice.org und StarOffice kennen in dieser Version nur eine rudimentäre PDF-
Exportfunktion. Einstellmöglichkeiten zum Kompressionsgrad oder Druckbereich sind
nicht möglich. Bezüglich der Usebility wird noch mehr auf Abgrenzung zum Konkurrenzprodukt
Microsoft Office gesetzt. Das bezieht sich auf die Oberflächengestaltung, aber
auch die Benennung einzelner Hilfsmittel. So werden die Formatvorlage Stylist genannt
und die Assistenten Auto-Piloten, was besonders für Umsteiger den Einstieg erschwert.
Die Werkzeugleisten gestallten sich unflexibel und wenig beweglich, wodurch eine individuelle
Einrichtung der Oberfläche erschwert wird. Als Dokumentenformate werden die
alten StarOffice-Formate unterstützt, das OpenDocument-Format war zu diesem Zeitpunkt
noch nicht eingeführt. Import und Export zu den proprietären Microsoft-Formaten
werden zwar angeboten, funktionieren aber nur bei einfach gestalteten Dokumenten. Auf
Vorlagen basierende Dokumente oder animierte Powerpoint-Präsentationen lassen sich
nicht richtig importieren. In Tabellen integrierte Tabellen werden nicht unterstützt, wodurch
der Export in Datei-Formate, welche verschachtelten Tabellen unterstützen (zum
Beispiel Microsoft Powerpoint), beeinträchtigt ist. In Punkto Sicherheit kennt diese Version
keine Unterstützung digitaler Signaturen.
Spezifische Abweichungen:
In OpenOffice.org1 existiert kein eigenes Modul für die Datenbankverwaltung. Dafür wird
ab der Version 1.1 ein sogenanntes Datenquellen-Werkzeug geliefert, mit dem sich Daten
aus verschiedenen Quellen importieren und in Office-Dokumente integrieren lassen.
Für einige Assistenten, die Literaturdatenbank, verschiedene Extensionen und Exportfil-
Seite 431

ter wird das kostenlose Java Runtime Environment (JRE) benötigt. Prinzipiell ist Open-
Office.org aber ohne JRE lauffähig.
1.1.2.2 Programmierung, Makros und Automatisierungsmöglichkeiten
In der Basic-IDE können Makros erstellt werden. Zur Erweiterung der Programmfunktionalität
stehen eine Vielzahl von Vorlagen, Erweiterungen („Add-Ons―) und Makros in den
Sprachen StarOffice Basic und Java zur Verfügung.
1.1.2.3 Dateiformate
Die Hauptanwendungen (Textverarbeitung, Tabellenkalkulation, Präsentationsprogramm)
der Versionsfamilie 1.1 von OpenOffice.org unterstützten folgende Dateiformate:
� Textdokument (.sxw),
� Textdokumentvorlage (.stw),
� Microsoft Word (.doc),
� Microsoft Word 2003 XML (.xml),
� Rich Text Format (.rtf),
� StarWriter 3.0, 4.0 und 5.0 (.sdw),
� StarWriter 3.0, 4.0 und 5.0 Vorlage (.vor),
� Text (.txt),
� HTML Document (OpenOffice.org Writer) (.html und .htm),
� DocBook (.xml),
� AportisDoc (Palm) (.pdb),
� Pocket Word (.psw).
Hinsichtlich der eingebauten Import- und Exportmöglichkeiten in andere Formate verfügt
die Version 1.1.5 von OpenOffice.org bereits über einen Importfilter für das Open Document
Format, welcher die Arbeit mit dem neuen Standardformat ermöglicht. StarOffice7
enthält darüber hinaus die Möglichkeit, WordPerfect-Dokumente zu bearbeiten, eine
Fähigkeit, die in OpenOffice.org1.1 nicht enthalten ist.
Im Übrigen werden die gleichen Import- und Exportfunktionen geliefert wie in der Nachfolge-Versionsfamilie.
Allerdings wurden die Filter zwischenzeitlich verbessert, sodass
die Verwendung alternativer Dateiformate in den neueren Versionen besser funktioniert.
1.1.2.4 XML-Technologie
In OpenOffice.org 1.1. sind als Eingabeelemente nur HTML-konforme Elemente nutzbar.
Dies wurde mit der Version 2.0 von OpenOffice.org beseitigt.
Unter dem Gesichtspunkt der Nutzbarkeit Anwendungsspezifischer XML-Schemas ist es
auf Grund des XML-basierten Standardformats in OpenOffice.org möglich, ein XML-
Schema zu importieren und zu bearbeiten. Nach dem Import eines solchen Schemas
kann ein XML-fähiges Dokument unter Verwendung aller bekannten Funktionen des
Programms wie ein ganz normales Textbearbeitungs-Dokument aufgebaut werden.
Seite 432

Die Fähigkeit zur Webservice-basierten Integration wird durch OpenOffice.org Basic,
einer Programmiersprache aus der Familie der Basic-Programmiersprachen, unterstützt.
Diese ist weitgehend kompatibel mit anderen Basic Sprachversionen wie zum Beispiel
Visual Basic von Microsoft. OpenOffice.org bietet Programmierschnittstellen zu
WRITER-Dokumenten mit Hilfe von UNO (Universal Network Objects) an. Mit UNO
erhält man eine objektorientierte Schnittstelle zu OpenOffice.org-Anwendungen und
OpenOffice.org-Dokumenten.
1.1.3 Zusammenfassung
OOo 2 / SO 8 OOo 1 / SO 7
natives Dateiformat ODF SWX, SWT (Vorlagen)
Eingebaute Importfunktionen
von anderen Formaten
Eingebaute Exportfunktionen
zu anderen Formaten
Erweiterungsmöglichkeiten
Programmierung
Unterstützung von anwendungsspezifischen
XML-
Formaten
Unterstützung, Webservice
basierte Integration in Prozessketten
Lizenzierung
Verfügbarkeit für Betriebssysteme
DOC, XLS, PPT, WordPerfect
PDF, Adobe Flash, (X)HTML,
DOC, XLS, PPT, WordPerfect
Ja, (mit Makros und Java, C++,
JavaScript, Python, Beanshell)
Seite 433
ODF, WordPerfect (v4 – v11),
Lotus Notes 1-2-3 (bis v9.7),
MS Office Formate
PDF, XHTML
Ja (mit Makros und Java, C++
Ja, per XSLT ja, über XSLT Stylesheets
Ja, kann über Java Web Service
Bibliotheken implementiert werden
OpenOffice.org: Freie Software
beziehungsweise LGPL-Lizenz
(GNU Lesser General Public
License von der Free Software
Foundation); StarOffice: kostenpflichtige,
Lizensierung pro Be-
nutzer
OpenOffice.org und StarOffice:
Microsoft Windows, Linux, Solaris;
nur OpenOffice.org: Mac OS
X, FreeBSD und andere Unix-
Varianten.
Bedingt
OpenOffice.org: Freie Software
beziehungsweise LGPL-
Lizenz (GNU Lesser General
Public License von der Free
Software Foundation); StarOffice:
kostenpflichtig, Lizensierung
pro Benutzer
Microsoft Windows, Linux,
Solaris, Mac OS X und weitere
Unix-Varianten.
Tabelle 68: Überblick der Charakteristika von OOo 1/SO 7 und OOo 2/SO 8
1.2 Microsoft Office 2007/2003/2002/97
Microsoft Office ist in der momentan aktuellen Version „Microsoft Office 2007― seit
Januar 2007 verfügbar. Mit Microsoft Office 2007 wurden einige wesentliche Änderungen
zur Vorgängerversion Microsoft Office 2003 eingeführt. Dazu gehören insbesondere
das neue XML-basierte Dateiformat Office Open XML, das die vorherigen
Binärformate ablöst sowie eine neu entwickelte, auf den ersten Blick stark veränderte

Benutzeroberfläche. Die bereits in der Vorgängerversion enthaltene umfangreiche Unterstützung
für das Arbeiten mit anwendungsspezifischen XML-Formaten und Webservices
wurden weiter ausgebaut.
Microsoft Office 2007 ist gegenwärtig für alle gängigen Microsoft Betriebssysteme bis
hinunter zu Windows XP verfügbar. Eine Version von Microsoft Office 2007 für Mac OS
X ist in Planung. Diese Version wird von Microsoft als „Microsoft Office 2008 für Mac"
beziehungsweise „Microsoft Office:mac 2008" bezeichnet und seit dem ersten Quartal
2008 verfügbar 421 .
Innerhalb der öffentlichen Verwaltung ist die Verbreitung von Microsoft Office 2007 zurzeit
noch gering (Stand September 2007). Gegenwärtig überwiegen die Installationen
der verschiedenen Vorgängerversionen von Microsoft Office.
Microsoft Office ist ein kostenpflichtiges Produkt für private und professionelle Anwender.
1.2.1 Bestandteile Office Paket
Microsoft Office wird in verschiedenen Paketen angeboten. Die einzelnen Pakete unterscheiden
sich insbesondere durch die Anzahl von Anwendungen, die zusätzlich zu Microsoft
Word, Microsoft Excel und Microsoft Powerpoint enthalten sind. Nachfolgend wird
ein Überblick über die aktuell verfügbaren Anwendungen in den jeweiligen Paketen am
Beispiel der Version 2007 gegeben:
Windows – Office
Anwendung
Basic Home &
Student
Standard
Small
Business
Seite 434
Professional
Ultimate Professional
Plus
Word X X X X X X X X
Excel X X X X X X X X
Powerpoint X X X X X X X
Outlook X X X X
Outlook mit
ContactManager 422
Accounting
Express 423
X X X
X X X
Publisher X X X X X
Enterprise
421 http://www.macoffice2008.com/#ex_fg
422 Volumenlizenzkunden, die Office Professional Plus 2007 oder Office Enterprise 2007 erwerben,
können Office Outlook 2007 mit Business Contact Manager auf der Volumenlizenzdienste-Website
herunterladen oder sich diesbezüglich an ihren Händler wenden.
423 Microsoft Office Accounting Express 2007 ist nur in den USA verfügbar.

Windows – Office
Anwendung
Basic Home &
Student
Standard
Small
Business
Seite 435
Professional
Ultimate Professional
Plus
Access X X X X
InfoPath X X X
Groove X X
OneNote X X X
Communicator X X
Integriertes
Enterprise Content
Management 424
integrierte
elektronische
Formulare 425
erweiterte
Funktionen von
IRM und Richtlinien
426
X X X
X X X
X X X
Tabelle 69: Anwendungen in den jeweiligen Suiten für MS Office 2007; 427
Enterprise
In der Vorgänger-Version können diese Paket-Zusammenstellungen und die darin
enthaltenen Komponenten trotz gleicher Bezeichnung leicht differieren.
Im Folgenden werden die in den Paketen enthaltenen Anwendungen mit ihren Funktionen
beschrieben. Microsoft erweitert sein Office-Paket in den letzten Jahren um immer
mehr Anwendungen, die auch als Einzellösungen gesehen werden können, daher
werden diese hier nur kurz erwähnt. Außerdem müssen einige Anwendungen, wie zum
Beispiel Outlook, welches je nach Edition Bestandteil der Office-Suite von Microsoft sein,
müssen durchaus anderen Themen, wie im Falle Outlook dem Thema Groupware oder
im Falle Access dem Thema Datenbanken zugeordnet werden. An dieser Stelle sollen
nur die Kernanwendungen (Textverarbeitung, Tabellenkalkulation, Präsentation) im
Fokus der Betrachtung stehen. Hier hat sich die Sichtweise gegenüber den früheren
Versionen des Migrationsleitfadens nicht verändert.
Die drei Kernanwendungen in der MS Office-Suite sind:
424 ECM von Microsoft weitet das Content Management für alle Benutzer in einer Organisation
durch die Integration mit bekannten Tools wie Microsoft Office System aus.
425 Die Version 2007 von Microsoft Office System bietet Kernfunktionen für das Erstellen und
Ausfüllen von Formularen sowie Forms Services zur Vereinfachung von Verteilung und
Verwaltung elektronischer Formulare.
426 Die Version 2007 von Microsoft Office System bietet IRM-Funktionen (Information Rights
Management, Verwaltung von Informationsrechten) sowie Richtlinienkontrollen zum Schutz
digitaler Informationen vor unbefugter Verwendung in Unternehmen und Organisationen.
427 http://office.microsoft.com/de-de/suites/FX101635841031.aspx?pid=CL101732621031

� Microsoft Office Word (Textverarbeitung),
� Microsoft Office Excel (Tabellenkalkulation),
� Microsoft Office PowerPoint (Präsentationen).
Die anderen Anwendungen in der aktuell erhältlichen Office 2007-Version sind abhängig
von der gewählten Paketversion:
� Microsoft Office Publisher 2007 (Desktop-Publishing-Programm),
� Microsoft Office Access 2007 (Datenbankverwaltungssystem),
� Microsoft Office OneNote 2007 (Erstellen und Verwalten von Notizen),
� Microsoft Office Outlook 2007 (Groupware-Anwendung einschließlich Mail-Client,
Kontaktmanager, Terminplaner etc.),
� Microsoft Office InfoPath 2007 (Erstellen und Auswerten von elektron. Formularen),
� Microsoft Office Communicator 2007 (Messengersoftware, die verschiedene
Kommunikationsarten erlaubt wie zum Beispiel IM, Video, Sprache),
� Microsoft Office Groove 2007 (Programm, welches durch mitgelieferte Tools und
Kommunikationsmöglichkeiten das Arbeiten in Gruppen unterstützen soll),
1.2.2 Funktionalitäten
Auf eine Auflistung aller Funktionalitäten der oben genannten Office-Anwendungen wird
an dieser Stelle verzichtet. Nachfolgend soll jedoch ein kurzer Überblick gegeben und
auf die wesentliche Funktionen eingegangen werden:
Microsoft Office Word 2007:
Microsoft Office Word 2007 beinhaltet alle Funktionen der Vorgängerversionen. In der
neuen Version 2007 fällt dem Betrachter als erstes das neue Oberflächenkonzept auf.
Mit der „Fluent"-Benutzeroberfläche werden die Bearbeitungswerkzeuge bedarfsgesteuert
angezeigt. Hiermit soll ein effizienteres und schnelleres Arbeiten ermöglicht werden.
Die gravierendste Änderung in der neuen Version ist mit Abstand das neue Standard-
Dateiformat. Office Open XML (.docx) ersetzt das bisherige binäre Dateiformat (.doc).
Die alten Dateiformate sollen jedoch auch künftig in vollem Umfang unterstützt werden
und die Aufwärtskompatibilität damit gesichert sein. Die Abwärtskompatibilität ist jedoch
nur mit einem Plug-In in den jeweiligen Versionen ab MS Office 2000 möglich.
Weitere wesentliche Merkmale der Version 2007 sind:
� Erweiterte Unterstützung für das Arbeiten mit anwendungsspezifischen XML-
Schemata, da die Inhalte der Dokumente durch das neue Standarddateiformat
auch von produktunabhängigen Lösungen bearbeitet werden können,
� Verbesserte Unterstützung für Web Services, mit denen Daten und Funktionen
aus Anwendungen heraus über Schnittstellen von anderen Anwendungen genutzt
werden können,
Seite 436

� Globale Rechtschreibprüfung, die Änderungen auch für andere Anwendungen
eines Office-Pakets übernimmt.
Microsoft Office Excel 2007:
Microsoft Office Excel 2007 beinhaltet alle bekannten Funktionen der Vorgängerversionen.
Excel ermöglicht es, mit Formeln und Funktionen umfangreiche Berechnungen
durchzuführen. Die Daten können mit Hilfe von Sortier- und Filterfunktionen
sowie Pivot-Tabellen ausgewertet und in Diagrammen grafisch dargestellt werden. Mit
VBA (Visual Basic for Applications) kann der Funktionsumfang von Excel erweitert
werden. Unter Mac ist dies mittels AppleScript möglich.
Weitere wesentliche Merkmale der Version 2007 sind:
� In Verbindung mit dem Sharepoint Server 2007 und Excel Services können Tabellen
in Webbrowsern freigegeben und bearbeitet werden. Excel Services bietet
dafür zwei Schnittstellen: eine Web-basierte UI (User Interface), um Excel Tabellen
innerhalb von einem Browser anzusehen und eine Web Service Schnittstelle,
die einen programmatischen Zugang zu veröffentlichten Tabellen erlaubt.
� Erhöhung der Datenmenge auf bis zu 1Mio Zeilen und 16000 Spalten
� Eine verbesserte Diagramm-Funktion
� Neue OLAP-Formeln und Cube-Funktionen lassen mehr Möglichkeiten für die
Arbeit von mehrdimensionalen Datenbanken zu
� Vereinfachte Verbindung zu externen Datenquellen: Eine Angabe der Verbindungsdaten
gibt es in Excel 2007 nicht mehr, die Verbindung wird einfach aus einer
Liste ausgewählt. Mit Hilfe des Verbindungsmanagers wird jede bereits genutzte
Verbindung gespeichert und kann nach neuem Programmstart wieder
verwendet werden.
Microsoft Office Powerpoint 2007:
Mit Microsoft Office Powerpoint 2007 können Vortragsfolien mit Animationen, verschiedenen
Hintergründen und Übergängen erstellt werden. Vortragsfolien können im binären
Powerpoint Dateiformat .ppt, als PDF (Adobe Portable Document Format) oder auch als
XPS (XML Paper Specification Format) gespeichert werden.
Letzteres bedarf jedoch der Installation von Add-Ins, um diese Speicherfunktion nutzen
zu können. Neben dem Standard-Präsentationsformat (.ppt beziehungsweise .pptx und
.pptm für Dateien mit Makros, letzteres nur Windows) wird häufig das Bildschirmpräsentationsformat
(.pps beziehungsweise .ppsx) verwendet, das der sofortigen Anzeige der
Präsentation im Vollbildmodus dient.
Weitere MS Office-Anwendungen
� Microsoft Office Publisher 2007
Microsoft Office Publisher 2007 ist ein Programm für die Erstellung von seiten-
Seite 437

orientierten Dokumenten wie zum Beispiel Marketingmaterialien oder individuellen
Mailings.
� Microsoft Office Access 2007
Office Access2007 ist ein Datenbankverwaltungsprogramm zur Verwaltung von
strukturierten Daten in Tabellen mit definierter Datensatzstruktur und zum Erstellen
von Berichten.
� Microsoft Office OneNote 2007
Microsoft Office OneNote 2007 ist ein Programm für das Aufzeichnen und Verwalten
von Notizen.
� Microsoft Office Outlook 2007
Microsoft Office Outlook 2007 ist ein allgemein bekannter Client für Groupware-
Lösungen, insbesondere MS Exchange.
� Microsoft Office InfoPath 2007
Mit der InfoPath-Anwendung können XML-basierte Formulare erstellt und - aus
Office heraus – auch verwendet werden.
� Microsoft Office Communicator
Microsoft Office Communicator ist eine Instant Messaging Lösung.
� Microsoft Office Groove 2007
Das in Microsoft Office Ultimate 2007 enthaltene Microsoft Office Groove 2007 ist
ein Programm für die Unterstützung von Gruppenarbeit.
1.2.3 Programmierung, Makros und Automatisierungsmöglichkeiten
Die Funktionen der Microsoft Office 2007 Anwendungen können mit Hilfe verschiedener
Technologien erweitert, angepasst und individualisiert werden. Zu den dafür vorgesehenen
Technologien gehören:
� Smarttags - sie erlauben zum Beispiel eine kontext-sensitive Automatisierung
durch Informationen und Aktionen. Sie sind mit Hyperlinks vergleichbar, werden
jedoch dynamisch an Schlüsselwörter oder -phrasen geheftet. Sie basieren auf
COM-Klassen, die eine Erkennungs- und eine Aktionsschnittstelle implementieren.
Erstere ist für die Erkennung der Schlüsselwörter und die zweite für die ausführende
Aktion und Darstellung der Aktionsmenüs zuständig.
� Makros sind kleine, in der Regel in Visual Basic for Applications (VBA) geschriebene
Programme. In Office dienen sie dazu, eine definierte Folge von Befehlen
und Aufgaben automatisiert durchzuführen und so den Nutzer zu entlasten.
� .NET – ist eine von Microsoft entwickelte Softwareplattform für die Entwicklung
von Internetanwendungen, die auf offenen Standards basiert. Konzeptionell be-
steht .NET aus 4 Komponenten: Frameworks and Tools, Building Block Servi-
ces, Enterprise Servers und Mobile Devices. Das Framework ist für die einzelnen
Anwendungen zuständig und steuert den Zugriff auf die Daten, stellt eine
Benutzeroberfläche sowie Klassen-Bibliotheken und Web-Technologien zur Verfügung
(zum Beispiel das Ausführen von Programmen in mehreren Sprachen).
Die Building Blocks Services unterstützen verfügbare Internet-Dienste, zum Bei-
Seite 438

spiel Updates und Suchdienste. Darüber hinaus können mit den Mobile Devices
Anwendungen auf mobilen Geräten laufen.
Innerhalb von behördenspezifischen Softwarelösungen werden Erweiterungen der Funktionalitäten
von Microsoft Office zum Teil intensiv verwendet. So werden zum einen die
mit Microsoft Office verfügbaren Programmierumgebung in vielen Behörden und anderen
Organisationen zur Erstellung dokumentenspezifischer Scripting-Lösungen (Makros)
genutzt, um Arbeitsprozesse mit Microsoft Office weitgehend zu automatisieren. Das
reicht bis zur Implementierung abteilungsübergreifender Workflows. Zum anderen gibt es
in den Behörden eine Reihe externer Softwarelösungen, die mehr oder weniger stark mit
Office integriert sind.
An dieser Stelle ist hervorzuheben, dass diese in Teilen sehr intensive Praxis der Office-
Programmierung im Hinblick auf die Schwierigkeiten, die damit immer wieder verbunden
sind:
� für jede Form der Migration
� der Sicherstellung der Interoperabilität mit anderen Office-Anwendungen
� der Gewährleistung einer geordneten Wartung und einem zielgerichteten Support
für solche Softwarestücke
als zweifelhaft anzusehen ist. Grundsätzlich kann festgehalten werden, dass für die Entwicklung
komplexer Anwendungen bessere und professionellere Lösungsalternativen
zur Verfügung stehen, die insbesondere mit Blick auf durchzuführende Migrationen und
die Wartung und den Support für solche Anwendungen sich deutlich besser eigenen.
Dies sollte auch deutlich werden, wenn man sich ansieht, welche Konzepte hier verwendet
werden.
� Die „Visual Basic― Erweiterungen sind sowohl für Office 97 als auch für Office
2000 und Office 2003 einsetzbar und haben eine entsprechend große Verbreitung.
Die „Visual Basic― Programmierumgebung von Microsoft Office 97 - 2003
basiert auf der Programmiersprache BASIC. Die Visual Basic Sprachfamilie umfasst
aktuell mehrere Dialekte:
� Visual Basic (Visual Studio, Vollversion),
� Visual Basic for Application (VBA),
� Visual Basic Scripting Edition (VBS).
Alle Dialekte haben denselben Grundwortschatz der Syntax, unterscheiden sich aber in
Funktionsumfang und Leistungsfähigkeit. (beispielsweise ist im Gegensatz zu Visual
Basic ein Kompilieren bis zum ausführbaren Maschinencode in VBA nicht möglich).
Die Programmierumgebung von MS Office beinhaltet Visual Basic for Application (VBA).
VBA kann von Microsoft lizenziert werden, sodass Dritthersteller VBA in ihre Produkte
einbauen können.
Als Ausgangspunkt für diesen Leitfaden wird der Einsatz des Office-Paketes 97 oder
höher angenommen. In früheren Versionen wurden verschiedene Programmierumgebungen
für die einzelnen Produkte bereitgestellt (Word Basic, Excel VBA, Access Basic).
Mit Office 97 wurde die Programmierumgebung auf VBA der Version 5 vereinheitlicht.
Seite 439

Die folgende Tabelle zeigt die Versionierung von VBA im Zusammenhang mit den verschiedenen
Office Versionen.
Office Versionen VBA Versionen
95 Word Basic, Excel VBA, Access Basic
97 5
2000 6
XP 6.3
2003 6.4
2007 6.5
Tabelle 70: Microsoft Office Versionen und zugehörige Versionen von VBA
VBA ist eine Interpretersprache und nur in Microsoft Office Anwendungen ausführbar.
VBA basiert auf COM (Component Object Model), einer proprietären Weiterentwicklung
der Microsoft Technologie OLE (Object Linking and Embedding).
MS Office kann nicht nur COM Objekte verwenden, sondern bietet selbst COM Objekte
an. Office 97 bringt über 550 eigene COM Objekte mit, Office 2000 über 600. Via COM
lassen sich in Office auch externe Funktionalitäten nutzen. Mittels VBA ist es möglich,
externe Programme (zum Beispiel das Betriebssystem) in Form von DLLs (Dynamic Link
Libraries) zu verwenden, In Visual Basic Script (VBS) ist solch eine Einbindung nicht
möglich.
Die folgende Abbildung zeigt noch einmal die Möglichkeiten von VBA, Funktionalitäten
zu nutzen.
Abbildung 66: VBA in der Office Anwendung
In VBA werden die folgenden Bausteintypen unterschieden:
� Module (moduls),
� Klassenmodule (class moduls),
� und Formulare (forms).
Module enthalten allgemeine Prozeduren, die nicht mit einem Objekt verbunden sind.
Klassenmodule (Formular- und Berichtsmodule) dagegen sind mit Objekten verbunden
Seite 440

und rufen bestimmte Ereignisprozeduren auf (zum Beispiel eine Reaktion auf eine Benutzereingabe,
wie das Klicken einer Befehlsschaltfläche).
Diese Bausteine ermöglichen es, in MS Office vorhandene Funktionalitäten zu erweitern,
Abfolgen von Funktionsaufrufen zu automatisieren und zusätzliche Funktionalitäten zu
implementieren. Die Erweiterungen, Automatisierungen und Ergänzungen werden als
Makros und Scriptings bezeichnet. Zur Integration dieser Makros in MS Office lassen
sich insbesondere die Menüleisten und Schaltflächen der Symbolleisten modifizieren,
sodass dem Benutzer deren Starts erleichtert werden.
Spezielle Prozedurnamen (zum Beispiel AutoOpen, AutoNew) kennzeichnen den Programmcode,
der automatisch ausgeführt wird, wenn Office-Dateien geöffnet werden. Dieser
Mechanismus wird häufig in Vorlagen (Templates) verwendet. Da hiermit auch bösartige
Prozeduren („Makroviren") ausgeführt werden können, ist er ein Sicherheitsrisiko.
Insgesamt können Makros und Scriptings in folgenden Formen innerhalb von Office aufgerufen
beziehungsweise integriert werden:
� als Add-In,
� innerhalb von Vorlagen (Templates),
� als Assistenten (Wizards).
Add-Ins unterscheiden sich aufgrund ihrer Verwendbarkeit nochmals:
� COM Add-Ins:
kompilierte DLL- oder EXE-Dateien, die mit einer Visual Basic (Vollversion) erzeugt
werden. Diese Add-Ins können anwendungsübergreifend verwendet werden.
� Anwendungsspezifische Add-Ins:
Anwendungsspezifische Add-Ins werden mittels der integrierten Programmierumgebung
von Office erzeugt und können nur innerhalb Office verwendet werden.
Der Einsatz von Add-Ins ist in der Regel dort anzutreffen, wo der Programmcode
ständig in der Anwendung zur Verfügung stehen soll, ohne dass der
Benutzer eigens dafür bestimmte Vorlagen laden muss.
Mit VBA der Version 5 wurde innerhalb der Office Anwendungen eine einheitliche Entwicklungsumgebung
integriert. Das sogenannte IDE (Integrated Development Environment)
wird in einem separaten Fenster gestartet, läuft aber im Prozess der Office Anwendung.
Das IDE bietet:
� Editor mit Syntaxprüfung und Farbhervorhebung,
� Project Explorer,
� zusätzliches Eigenschaftsfenster,
� Debugger-Werkzeuge,
� Object Browser,
� bedingte Compilierung,
Seite 441

� Schutzmechanismen vor Veränderung oder Kopieren des programmierten Codes
und
� IntelliSense (Komplettierung, Drop-Down Auswahl, Infos zur Syntax).
In der Anwendung steht ein Makro-Rekorder zur Verfügung, mit dem Abfolgen von Interaktionen
des Benutzers mit der Anwendung aufgezeichnet und gespeichert werden können.
Durch die Nutzung solcher Funktionalitäten durch die Benutzer wird es noch
schwieriger, bei Migrationen die entsprechenden Makros in den Vorlagen und Dokumenten
ausfindig zu machen, denn die wenigsten Benutzer werden dokumentieren, wann sie
wo welche Makros für ihre Arbeit erstellt haben, gehen aber in der Regel davon aus,
dass diese nach der Migration weiterhin verfügbar sind und funktionieren.
Da Office selbst aus einer Vielzahl von COM Objekten besteht, ist es möglich, Office
mittels der sogenannten COM-Automatisierung 'fernzusteuern'. Zur Fernsteuerung können
zum Beispiel der Windows Scripting Host (WSH) oder PerlScript verwendet werden.
Für die Zukunft zeichnet sich ab, dass Microsoft bezüglich der Officeautomatisierung
verstärkt auf die Visual Studio Tools for Microsoft Office Systems 428 (VSTO) und Visual
Studio Tools for Applications (VSTA) 429 setzt. Hierbei handelt es sich um .Net basierte
Toolsets mit denen zum einen Anwendungen auf Basis der Office-Anwendungen entwickelt
werden können (VSTO) und zum anderen für den Einsatz von .NET-Sprachen angepasst
(VSTA) werden können. VSTO und VSTA reihen sich ein in die Familie der Visual
Studio 2008 Produkte. Die aktuellsten Versionen sind VSTO 3.0 und VSTA 2.0, die
seit dem 3. Quartal 2007 verfügbar sind. In wie weit hierdurch VBA einmal abgelöst wird
ist heute nicht absehbar. Vorerst, so scheint es, wird Microsoft die VBA-Linie noch weiter
unterstützen.
1.2.4 Dateiformate
Microsoft Office 2007 unterstützt mehrere native Dateiformate. Dazu gehören:
� Die traditionellen binären Microsoft-Dateiformate .doc, .xls, .ppt usw.
� Das neue XML-Dateiformat Office Open XML.
Mit Erscheinen von Office 2007 ersetzt Microsoft die alten binären Formate durch Office
Open XML als Standarddateiformat, das für Word, Excel und Powerpoint durchgängig
verwendet wird. Im Gegensatz zum vorhergehenden Format werden dabei die Inhalte
(Texte, Grafiken, Tabellen etc.) und die Metadaten (das „Layout― von Inhalten) der Dokumente
in Packages abgelegt und in einem ZIP-Archiv komprimiert gespeichert.
Office Open XML wurde der ECMA (European Computer Manufacturers Association) zur
Standardisierung übergeben und wurde im Dezember 2006 als ECMA-Standard 376
verabschiedet. Die ISO-Standardisierung ist beantragt.
Bezüglich der Import- und Exportmöglichkeiten in andere Formate verfügen die Hauptanwendungen
von Microsoft Office 2007 (Textverarbeitung, Tabellenkalkulation und
428 http://msdn2.microsoft.com/de-de/vstudio/aa718674.aspx
429 http://msdn2.microsoft.com/en-us/vsx2008/products/bb933739.aspx
Seite 442

Präsentation) über folgende, teilweise bereits eingebaute Import- und Exportmöglichkeiten
von eigenen älteren Formaten und fremdem Formaten:
� Binärformate (.doc, .xls. .ppt) von vorherigen Microsoft Office Versionen (Microsoft
Office 97 - 2003)
� WordML (Wordprocessing ML)
� OpenDocument
� PDF.
Die beiden letztgenannten sind nur über Plug-Ins realisierbar.
Neben dem direkten Editieren und Bearbeiten von einzelnen Bestandteilen der
„Packages― ist es in Microsoft Office 2007 möglich, mit durch den Anwender definierten,
anwendungsspezifischen XML-Schemata zu arbeiten. Dabei wird der Anwender durch
eine grafische Benutzeroberfläche unterstützt. Diese ermöglicht u.a. den direkten Import
von anwendungsspezifischen XML-Schemata in ein Dokument. XML-Elemente können
bei Bedarf mit Platzhaltern, z. B. mit einem Beispieltext oder einer Eingabeaufforderung
initialisiert werden. Die hinzugefügten XML-Elemente werden während der Erstellungsphase
farblich hervorgehoben. Beim späteren Einsatz des Dokuments verschwindet
diese farbliche Hervorhebung, sodass die XML-Struktur verborgen bleibt
Nach dem Import eines XML-Schemas kann ein Dokument unter Verwendung aller bekannten
Funktionen des Programms wie ein ganz normales Word-Dokument bearbeitet
werden. Im Labor-Beispiel „Geburtsurkunde― wurde das XML-Schema in das Dokument
eingefügt und dieses anschließend gestaltet.
Seite 443

Abbildung 67: Benutzeroberfläche für das Arbeiten mit XML-Schemas in MS Word 2007
In Abbildung 67 ist die grafische Oberfläche dargestellt. Auf der linken Seite ist das Dokument
zu erkennen, welchem dem XML-Schema zugrunde liegt. Auf der rechten Seite
befindet sich das XML-Struktur-Panel mit einem importierten XML-Schema. Um XML-
Elemente aus dem XML-Schema zum Dokument hinzuzufügen, können diese einfach
mit der Maus per „Drag and Drop― vom XML-Struktur-Panel in das Dokument hineingezogen
werden. Jedoch ist nicht zu unterschätzen, dass eine Validierung der Daten oder
der Struktur in den grafischen Entwicklungstools auch weiterhin nicht möglich ist. Ändert
der Anwender im Dokument die Struktur, so ist das XML-Schema beschädigt. Eine Validierung
kann aber von dem Entwickler selbst implementiert werden. In der neuen Office
2007-Version können jedoch vom Entwickler des XML-Schemas die Knoten vor einer
Änderung geschützt werden, damit entfällt eine Implementierung zur Validierung der
Daten.
Für das Speichern von ausgefüllten Dokumenten existieren verschiedene Optionen,
ebenso für die eingegebenen Daten in Eingabefelder, die durch XML-Markup definiert
werden. Sollen die eingegebenen Daten zusammen mit allen anderen Informationen -
also allen im Dokument eingebetteten Daten - als XML gespeichert werden, kann dies in
dem von Microsoft offen gelegten XML-Format Office Open XML erfolgen.
Ebenso ist es möglich, nur die eingegebenen Daten (ohne jegliche Zusatzinformationen)
heraus zu filtern und zu speichern Die so gespeicherten Daten entsprechen automatisch
der Vorgabe des importierten XML-Schemas.
Seite 444

Die nachfolgende Abbildung zeigt einen Ausschnitt aus einem resultierenden XML-
Datensatz.
Jäger
Christoph Jan
m
07.05.1976
Potsdam
4578456
Christoph Jan Jäger
10070024
Deutsche Bank 24
Jäger
Christoph Jan
Friedrichstr.
47
10117
Berlin
Christoph.Jaeger@egov06
0301245789
Abbildung 68: Datensatz nach dem XML-Schema „Antrag Geburtsurkunde―
Microsoft Office 2007 bietet weiterhin die Möglichkeit einer automatischen Kontrolle der
Daten zum vorgegebenen XML-Schema. Auf diesem Wege können inkorrekte XML-
Datensätze vor dem Export zu beliebigen Webservices, E-Gouvernement-Plattformen
und so weiter erkannt und zurückgehalten werden. Fehlerhafte oder unvollständige Eingaben
werden bereits während der Eingabe markiert. Die Validierung der Eingabe muss
dabei nicht programmiert werden, wie dies noch bei der Vorgänger-Version der Fall war.
Microsoft Office 2007 kann alle notwendigen Informationen aus dem XML-Schema herauslesen
und die Validierung automatisch durchführen.
1.2.5 Webservice basierte Integration
Hinsichtlich des Themas Webservice-basierte Integration bietet Microsoft zwei verschiedene
Tools an, um Microsoft Office 2007 mit einer Web Service-Schnittstelle auszustatten.
Die eine Variante bietet das frei herunterladbare Microsoft Office Web-Services
Toolkit 2.0. Mit Hilfe dieses Toolkits und Visual Basic for Applications (VBA) können
Makros programmiert werden, die Anfragen an Web Services stellen, die zum Beispiel
von Backoffice-Prozessen bereitgestellt werden.
Die zweite, weit elegantere Möglichkeit wird durch die Verwendung des .NET Frameworks
geboten. Das frei verfügbare .NET Framework bietet eine Vielzahl von Funktionen
für die Entwicklung von komplexen Web Service-Schnittstellen.
Seite 445

1.2.6 Differenzen der Vorgänger-Versionen zu MS Office 2007
Die Vorgänger-Versionen Microsoft Office 2007 sind innerhalb der Verwaltung sehr weit
verbreitet. Es ist sogar davon auszugehen, dass die überwiegende Mehrzahl aller
Arbeitsplätze in den deutschen Verwaltungen mit einer der Versionen von Microsoft
Office 97 - 2003 ausgestattet ist.
Mit der Version Microsoft Office 2003 wurde begonnen, eine umfangreiche Unterstützung
für das Arbeiten mit XML-Dateien in das Office-Paket zu integrieren. Dazu gehören
die Unterstützung des XML-basierten Dateiformats WordprocessingML, ferner die umfangreiche
Unterstützung für das Arbeiten mit anwendungsspezifischen XML-Schemata
und für die Integration in prozessorientierte beziehungsweise serviceorientierte Architekturen
(SOA). Mit nachrüstbaren Erweiterungen können Microsoft Office 2003 Anwendungen
auch das neue XML-Format Open Office XML lesen und schreiben. Sollten diese
Erweiterungen nicht implementiert sein, sind diese Versionen nicht in der Lage, das
Dateiformat von Office 2007 zu erkennen.
Im Gegensatz zur aktuellen Office-Version wurden die vorherigen nicht in einer derartigen
Fülle an Paketen angeboten. Für die 2003er Version von Office gab es beispielweise
6 Pakete, unter denen der Anwender wählen konnte (zum Beispiel Professionell
Enterprise Edition, SSL-Edition, Standard-Edition etc.). Wie auch in der aktuellen Version,
unterscheiden sie sich in der Anzahl der Anwendungen, die zusätzlich zu den
Kernanwendungen angeboten werden.
1.2.6.1 Bestandteile
Im Folgenden werden diese Kernanwendungen und die wesentlichen Unterschiede zur
aktuellen Version am Beispiel der direkten Vorversion Office 2003 kurz vorgestellt. Auf
einzelne Funktionen wie auch die restlichen Versionen und Anwendungen wird an dieser
Stelle nicht näher eingegangen.
Microsoft Office Word 2003
Mit Microsoft Office 2003 sind mehrere neue Konzepte und Technologien eingeführt
worden, die in der aktuellen Version 2007 weiter ausgebaut wurden. Zu diesen Konzepten
und Technologien gehörten insbesondere:
� Die Einführung des offenen, XML-basierten Dateiformats Wordprocessing ML.
� Unterstützung für das Arbeiten mit anwendungsspezifischen XML-Formaten.
� Unterstützung für Automatisierungsprozesse, Workflows und Datenanbindung
durch verschiedene Technologien wie zum Beispiel dynamische SmartDocuments,
durch programmierbare Makros und durch .NET-Programmierung.
Microsoft Office Excel 2003
Mit Microsoft Office Excel 2003 wurden ebenso wie bei der Textverarbeitung Word mehrere
neue Konzepte und Technologien eingeführt, die in der aktuellen Version 2007 weiter
ausgebaut wurden. Zu diesen Konzepten und Technologien gehörten insbesondere:
� Import- und Exportfunktionen von und zu beliebigen XML Formaten direkt aus
der Anwendung heraus.
Seite 446

� Unterstützung für die Web Service-basierte Integration.
� Workflows können mit Hilfe von Schaltflächen in der Anwendung angestoßen
werden.
� Weitere Unterstützung für Automatisierungsprozesse, Workflows und Datenanbindung
durch verschiedene Technologien wie zum Beispiel dynamische Smart-
Documents, durch programmierbare Makros und durch .NET-Programmierung.
� Bis Excel 2003 waren die Tabellenblätter noch auf 65.536 Zeilen und 256 Spalten
(von A bis IV) begrenzt. In der aktuellen Version wurde die Begrenzung dann
auf 1.048.576 Zeilen und 16.384 Spalten erhöht.
Microsoft Office Powerpoint 2003:
Mit Microsoft Office Powerpoint 2003 können Vortragsfolien mit Animationen, verschiedenen
Hintergründen und Übergängen erstellt werden. Vortragsfolien können im binären
Powerpoint Dateiformat .ppt, als PDF (Adobe Portable Document Format) oder auch als
XPS (XML Paper Specification Format) gespeichert werden. Letzere sind aber nur durch
Plug-Ins möglich.
1.2.6.2 Weiteres
Die Einführung von sogenannten Smarttags erfolgte mit Office 2000. In Office 2003 wurde
die Funktionalität erweitert. Smarttags sind eine Möglichkeit der kontextsensitiven
Automatisierung. Ein Smarttag löst in Reaktion auf eine Eingabe (zum Beispiel ein vorbestimmtes
Wort oder eine bekannte Zahl) eine Funktion aus. Mit Hilfe von Smarttags
lassen sich auch Funktionen in anderen Anwendungen nutzen, wie zum Beispiel das
automatische Öffnen von weiteren Dokumenten. Unterschieden wird zwischen einfachen
Smarttags und COM-basierten Smarttags. Einfache Smarttags werden in XML-Listen
verwaltet, die an einer zentralen Stelle im Rechner-Netzwerk abgelegt werden und dann
allen Anwendern zur Verfügung stehen. COM-basierte Smarttags hingegen werden als
sogenannte Smarttag-Add-Ins verwendet.
1.2.6.3 Dateiformate
Microsoft Office 2003 unterstützt mehrere native Dateiformate, diese sind:
� Die traditionellen binären Microsoft Dateiformate .doc, .xls, .ppt usw.
� Das mit Microsoft Office 2003 eingeführte XML Dateiformat WordprocessingML.
Die Office 2003-Versionen von Word und Excel boten als erste die Möglichkeit, ihre Dokumente
als XML-Dateien zu speichern. Das dafür zunächst eingesetzte XML Dateiformat
WordprocessingML unterlag allerdings etlichen Einschränkungen. Beispielsweise
gehen beim Speichern einer Excel-Mappe in einer XML-Datei die Diagramme verloren.
Werden zum Beispiel Word-Dokumente mit eingebetteten Excel-Arbeitsblättern als XML-
Datei gespeichert, dann enthalten diese nicht das Excel-Arbeitsblatt als XML, sondern
stattdessen einen druckbar kodierten Binärblock (Auszug):
Seite 447

EAAAAgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
/////v////7///8EAAAABQAAAAYAAAD+////////////////////////////////////////////
AAAAAAAWAAUA//////////8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAUqEb09sQB
AwAAAMAHAAAAAAAAXwAxADEANgA2ADgANQA3ADAAMAAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA
W/4qSGgXHcISgQ9Pn5oRjL8BMAf8skd8x0gp3wsrz82hCyWf5R3rQ9bDvsagN81jsvedI96He9jP
rGndHg5cLaoXHVoV69CHsS5HTtFz4I6h7+BGjz8gsW3uZNGySJ7F8nxD3vlQnstR80VyHnWUeQqX
xaQ2oVk52OmU5jpLq+wt7D6CSINpa0Py9JvbcGBZkEnoJryUTWSq/kqBg+tscXvx/op04tzTkUls
XdXdoGuM/gbBLTCfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
Abbildung 69: Binär kodierte Excel Tabelle in altem WordprocessingML
Das XML-Format WordprocessingML ist in Microsoft Office 2007 vollständig durch das
neue XML-Format Office Open XML abgelöst worden. Bis dahin waren die
standardmäßig eingebauten Import- und Exportmöglichkeiten in den Kernanwendungen
die Binärformate (doc, xls, ppt) sowie WordprocessingML. Mittels Erweiterungen können,
wie bereits erwähnt, auch die neuen Standardformate geöffnet werden.
In Microsoft Office 2003 boten einige Anwendungen die Möglichkeit einer automatischen
Kontrolle der Daten anhand des vergebenen XML-Schemas. Auf diesem Wege können
inkorrekte XML-Datensätze vor der Übertragung zu beliebigen Webservices,
Gouvernement-Plattformen und so weiter erkannt und zurückgehalten werden. Falsche
oder unvollständige Eingabefelder können bereits während der Eingabe markiert
werden. Die Validierung der Eingabe muss dabei nicht programmiert werden. Microsoft
Office 2003 kann alle notwendigen Informationen aus dem XML-Schema herauslesen
und die Validierung automatisch durchführen.
1.2.7 Zusammenfassung
natives Dateiformat
Eingebaute Importfunktionen
von anderen Formaten
Eingebaute Exportfunktionen
zu anderen Formaten
Erweiterungsmöglichkeiten
Programmierung
Unterstützung von anwendungsspezifischen
XML-
Formaten
Unterstützung, Webservice
basierte Integration in Prozessketten
Microsoft Office 2007 Microsoft Office 97 bis2003
Office Open XML (docx, pptc,
usw.) Binärformate
Binärformate (.doc, .xls, .ppt)
Office 97 - 2003
Binärformate (.doc, .xls, .ppt)
Office 97 - 2003
Ja, (mit Makros, Smarttags, Visual
Basic for Applications
(VBA), oder .Net Programmierumgebung)
Ja, umfangreiche Unterstützung
auch mit grafischen Editoren
Ja, umfangreiche Unterstützung
auch mit grafischen Editoren,
Smarttags, und .Net Programmierumgebung
Seite 448
Binärformate (.doc, .xls, .ppt)
Office 97 - 2003
Binärformate (.doc, .xls, .ppt)
Office 97 - 2003
Ja, (mit Makros, Smarttags,
.Net Programmierumgebung
oder VBA)
Ja, umfangreiche Unterstützung
auch mit grafische Editoren,
ab Microsoft Office 2003
Ja, umfangreiche Unterstützung
auch mit grafische Editoren,
Smarttags, und .Net
Programmierumgebung, ab
Microsoft Office 2003

Lizenzierung
Verfügbarkeit für Betriebssysteme
Microsoft Office 2007 Microsoft Office 97 bis2003
Lizenz erforderlich, da kostenpflichtige
Version
Microsoft Windows XP mit Service
Pack (SP) 2, Windows Server
2003 mit SP1 (oder höher) und
Windows Vista
Seite 449
Lizenz erforderlich, da kostenpflichtige
Version
Microsoft Windows XP (oder
höher), Windows Server 2000
mit SP3 (oder höher) und
Windows Server 2003 (oder
höher)
Tabelle 71: Überblick der Charakteristika von MS Office 2007 und Office 97 - 2003
2 Migrationspfade
Thema dieses Kapitels ist die Migration zwischen den einzelnen zuvor betrachteten Office-Anwendungen.
Dabei spielt Interoperabilität zwischen den Anwendungen eine wesentliche
Rolle, sowohl für die Migration von bestehenden Dokumenten und deren Weiternutzung
als auch für den Austausch und die gemeinsame Bearbeitung von Dokumenten.
Mit Blick auf eine Migration muss einerseits während dieser die Interoperabilität zwischen
den betroffenen Organisationseinheiten gewahrt bleiben, da in der Regel nicht alle
Einheiten gleichzeitig migriert werden können und andererseits muss die Interoperabilität
auch nach der Migration mit anderen Organisationen gewahrt bleiben, die nicht die gleichen
Office-Anwendungen verwenden und mit denen eine gemeinsame Bearbeitung von
Dokumenten zum täglichen Geschäft gehört. Damit ist die Sicherstellung der Interoperabilität
ein wesentliches Entscheidungskriterium für die Wahl eines Migrationspfades.
Interoperabilität von Office-Anwendungen ist, wie der Name sagt, keine einseitige Sache
und wird daher im Abschnitt (III.C 2.1) losgelöst von konkreten Migrationspfaden übergreifend
betrachtet.
Neben der Interoperabilität spielen auch die Lock-In Szenarien eine außerordentliche
Rolle bei einer Migrationsentscheidung. Im Vorfeld ist daher zu klären, in welchem Maße
andere Dienste und Anwendungen auf konkrete Office-Anwendungen angewiesen sind.
Sei es, weil bestimmte proprietäre Schnittstellen verwendet werden oder weil bestimmte
Funktionalitäten benötigt werden, die nur von einer Office-Anwendung zur Verfügung
gestellt wird. Das Auftreten solcher Lock-In Szenarien steht in engem Zusammenhang
mit den Möglichkeiten der Office-Programmierung und der Intensität der Nutzung der
Möglichkeiten im Rahmen der Office-Automation. Will eine Organisation hier die notwendige
Unabhängigkeit waren, dann müssen andere Konzepte entwickelt werden. Ein
gutes Beispiel hierfür ist die OSS-Lösung des Dokumentengenerators „tarent_doktor―
(siehe III.C 2.3 „Exkurs―).
Jedes Migrationsverfahren benötigt eine umfassende und gute Vorbereitung und gegebenenfalls
auch eine entsprechende Nachbereitung. Dies hat für die Migration von Office-Anwendungen
eine besonders große Bedeutung, die aus der Vielzahl von Dokumenten
resultiert, die mit den Office-Anwendungen im Laufe der Zeit erstellt wurden und bei
denen nicht immer klar ist, inwieweit eine Übernahme auch notwendig ist und vor allem
in welcher Form diese Übernahme erfolgen soll. Im Abschnitt III.C 2.2 werden hierzu
einige praktische Hinweise gegeben.

Anschließend werden folgende Migrationspfade genauer betrachtet:
� Migration von MS Office 2000 - 2003 nach OOo2/SO8 430
� Migration von MS Office 2000 - 2003 nach MS Office 2007
� Migration von OOo1/OOo2/SO7/SO8 nach MS Office 2007
� Migration von OOo1/SO7 nach OOo2/SO8
Jede Migration von Office-Anwendungen ist im Wesentlichen von folgenden Migrationsmaßnahmen
geprägt:
� die Migration der Dokumente
� die Migration der eingesetzten Makros und Scripte
� die Wiederherstellung der in den Dokumenten verwendeten Anbindung an Datenquellen
� der Umgang mit bestehenden Anwendungsintegrationen
Unter diesen Aspekten werden die oben genannten Migrationspfade betrachtet.
2.1 Interoperabilität von Officeanwendungen
In allen Migrationsszenarien ist die Kompatibilität zwischen der alten und der neuen Anwendung
eine entscheidende Herausforderung. Konkret ist zu klären: Kann die neue
Anwendung die Daten der alten Anwendung unmittelbar importieren? Oder sind Vor-
beziehungsweise Nacharbeiten oder explizite Konvertierungsschritte notwendig? Wie
können sie bewerkstelligt werden? Welche Informationen gehen dabei verloren?
Wenn sich eine Migration über einen längeren Zeitraum erstrecken oder wenn nur Teile
einer Organisation migriert werden sollen, dann gewinnt darüber hinaus die Rückwärts-
Kompatibilität an Bedeutung. Zu klären ist: Wie können Dokumente, die mit der neuen
Anwendung erzeugt oder bearbeitet wurden, mit der alten Anwendung weiter verarbeitet
werden? Entstehen durch die wechselseitige Bearbeitung eines Dokumentes mit verschiedenen
Anwendungen oder Anwendungs-Versionen (Roundtrip) möglicherweise
Fehler, die sich „schneeballhaft― vergrößern? Die gleichen Fragen stellen sich auch
dann, wenn neben der Migration innerhalb einer Organisation auch die Interoperabilität
mit anderen Organisationen angestrebt wird.
2.1.1 Betrachtungsebenen
Wenn von der Interoperabilität von Office-Suiten die Rede ist, ist im Rahmen dieses Leitfadens
der Austausch von Dateien gemeint. Man kann daher auch von einer "dateibasierten
Interoperation" sprechen.
Um das Potenzial aber auch die Grenzen der auf Dateien basierenden Interoperabilität
von Office-Anwendungen auszuloten, ist eine differenziertere Betrachtung der zu lösenden
Kompatibilitätsprobleme hilfreich. Die folgenden Kompatibilitätsebenen werden am
430 OOo2 = OpenOffice.org Version 2.x, SO8 = StarOffice Version 8.x
Seite 450

Beispiel der Textverarbeitung dargestellt, gelten in unterschiedlichem Maße aber auch
für Tabellenkalkulationen, Präsentationsprogramme und viele andere Anwendungen:
� Die logische Ebene: das Dokumentenmodell
Jede Anwendung hat eine interne Sicht auf ein zu bearbeitendes Dokument, die
sich von der menschlichen Wahrnehmung unterscheidet. Ein simpler Brief auf einem
Briefbogen ist für den menschlichen Betrachter ein völlig selbstverständlicher
Gegenstand. Damit ein Textverarbeitungsprogramm ihn aber gestalten
kann, muss es beispielsweise dafür sorgen, dass sich bei Änderungen zwar der
Text mit seinen Fußnoten verschiebt, nicht aber der Briefkopf, das Datum und die
Faltmarken. Dazu kennt die Textverarbeitung Konstruktionen wie Textboxen, eingebettete
Objekte, Fußzeilen oder Wasserzeichen. Die Menge dieser Gestaltungsinstrumente,
die zusammen das Dokumentenmodell ausmachen, sind von
einer Textverarbeitung zur anderen unterschiedlich. Unter Umständen verfügt eine
Office-Suite über Instrumente, die im Dokumentenmodell andere Office-
Anwendungen keinerlei Entsprechung hat.
Auf der Ebene der Dokumentenmodelle misst sich die Kompatibilität zweier Textverarbeitungen
daran, in welchem Maße die Modelle identisch sind (Modellkompatibilität)
und in welchem Maße die Instrumente des einen Modells in die Instrumente
des jeweils anderen Modells übersetzt werden können (Modell-
Abbildbarkeit).
� Die technische Ebene: das Dateiformat
Das eben behandelte Dokumentenmodell ist ein internes Konstrukt einer Anwendung.
Es ist dem Anwender zugänglich, während er mit der Anwendung arbeitet.
Andere Anwendungen haben jedoch i.d.R keinen Zugang dazu. Stattdessen greifen
sie auf die Dateien zu, in der die Anwendung ihre Dokumente speichert. Die
Dateien enthalten zwar alle Informationen des Dokumentenmodells, können
selbst aber durchaus anders strukturiert sein. Beispielsweise können sie anstelle
des letzten Bearbeitungszustandes des Dokumentes einen älteren Stand speichern
und ergänzend dazu die seither vorgenommenen Bearbeitungsschritte.
Darüber hinaus kann die Datei binär kodiert sein, sodass sie nur von geeigneten
Anwendungen genutzt werden kann, wie etwa vom Standardformat von Microsoft
Word. Sie kann aber auch in einem für Menschen mehr oder minder lesbaren
Format geschrieben werden, wie etwa das RTF-Format oder die komprimierten
XML-Archive, die ODF und inzwischen auch OOXML verwenden. Die meisten
Anwendungen sind in der Lage, Dokumente in unterschiedlichen Dateiformaten
zu speichern und zu lesen. Der vollständige Informationsgehalt des Dokumentenmodells
kann jedoch häufig nur in einem einzigen, nämlich dem 'eigenen' ("nativen")
Dateiformat abgelegt werden. Die Verwendung anderer Dateiformate ist in
diesem Fall mit dem Verlust von Informationen verbunden.
Auf der Ebene des Dateiformates misst sich Kompatibilität zunächst daran, ob
das Format technisch lesbar ist. Die technische Lesbarkeit kann dadurch hergestellt
werden, dass es sich um ein standardisiertes Dateiformat handelt (RTF,
XML), oder dass das Format dokumentiert ist. Wenn die technische Lesbarkeit
gegeben ist, muss erkennbar sein, welche der gelesenen Daten den letzten Be-
Seite 451

arbeitungsstand des Dokumentes repräsentieren und wie sie zu interpretieren
sind. Dieser Schritt ist dann wichtig, wenn ein Dateiformat nicht den jüngsten Zustand
eines Dokumentes speichert, sondern die zuletzt vorgenommenen Arbeitsschritte,
gewissermaßen also ein Makro. Wenn die technische Lesbarkeit gegeben
und der Zustand des Dokumentes rekonstruiert ist, muss schließlich dieser
Zustand noch in das Dokumentmodell der lesenden Anwendung übersetzt werden.
Erst in diesem letzten Schritt 'versteht' die lesende Anwendung das Dokument
und kann es für eine Bearbeitung zugänglich machen.
� Grafische Interpretation und Gestaltungstreue
Bei der Bearbeitung eines Textdokumentes ist dem Anwender oft nicht nur am
Wortlaut des Textes gelegen sondern auch an dessen Gestaltung. Moderne
Textverarbeitungen bieten eine Fülle von visuellen Gestaltungsmöglichkeiten und
stellen sie dem Anwender in der Regel im Sinne des WYSIWYG-Paradigmas zur
Verfügung. Der Anwender erwartet mit einer gewissen Berechtigung, dass das
Dokument immer und unter allen Umständen so aussehen wird, wie er es zum
Zeitpunkt der Bearbeitung auf seinem Bildschirm wahrnimmt. „Immer" schließt
dabei alle erdenklichen Drucker, alternative Betriebssysteme und -Umgebungen
ein, im Migrationskontext darüber hinaus auch andere Anwendungen beziehungsweise
Anwendungsversionen. Unglücklicherweise erweist sich WYSIVVYG in
der Praxis seit jeher als guter Vorsatz, der zwar meist annähernd, aber kaum je
vollständig umgesetzt wird. So reicht zum Beispiel der bloße Wechsel des Druckertreibers
aus, um die Gestaltung längerer, mit zahlreichen Grafiken versehene
Dokumente zu ruinieren. Die technischen Gründe dafür sind ebenso vielfältig wie
(zumeist) nachvollziehbar. Was Kompatibilität auf der Ebene der Gestaltungstreue
bedeutet, muss im Einzelfall entschieden werden. Wenn eine Faltmarke an
der falschen Position gedruckt wird, erfüllt sie ihren Zweck nicht mehr. Wenn sie
etwas schmaler oder etwas länger ist, ist dies hingegen keine gravierende Beeinträchtigung.
Wenn jedoch die Gestaltungsdetails zum Beispiel eines Stadtwappens
einer Graustufenkonvertierung zum Opfer fallen, dann ist dies nicht akzeptabel.
Maßgeblich sind somit die Anforderungen, die an ein bestimmtes Resultat
gestellt werden, zum Beispiel an den Druck auf Papier oder die auf die
Übereinstimmung mit amtlichen Vordrucken oder mit Gestaltungsrichtlinien abzielen.
Auf welcher dieser drei Ebenen wird nun über Kompatibilität entschieden? Da Probleme
der Darstellungstreue am deutlichsten sichtbar sind, werden sie häufig als entscheidender
Maßstab für Interoperabilität verstanden. Ob diese Probleme tatsächlich in der Praxis
die Roundtrip-lnteroperabilität beeinträchtigen, hängt allerdings in hohem Maße vom
konkreten Anwendungsszenario ab. Unter Umständen können Mängel der Darstellungstreue
toleriert werden, sofern die Interoperabilität auf den anderen Ebenen gewährleistet
ist.
Die Zuordnung augenscheinlicher Kompatibilitätsprobleme zu einer der drei Ebenen ist
für den Anwender jedoch häufig nicht einfach. Wenn beispielsweise eine Tabelle in einem
Textdokument nach der Konvertierung aus einer Datei der Anwendung A in eine
Datei der Anwendung B völlig anders aussieht, wird diese Veränderung zunächst als
mangelnde Gestaltungstreue wahrgenommen und möglicherweise auf ein Dateiformat-
Seite 452

Problem zurückgeführt. Tatsächlich kann es sich jedoch um eine Inkompatibilität der
Dokumentenmodelle handeln, die ein Konvertierungswerkzeug durch einen gut gemeinten
übersetzenden Eingriff zu überbrücken versuchte, jedoch mit unbefriedigendem Ergebnis.
Die richtige Identifikation der Ebene, der ein Kompatibilitätsproblem zugeordnet ist, hat
jedoch deshalb eine entscheidende Bedeutung, weil sich daraus die in Betracht kommenden
Lösungen ableiten. Der folgende Abschnitt geht insbesondere der Frage nach,
welche Beiträge XML-Technologien auf den unterschiedlichen Ebenen leisten können.
2.1.2 Maßnahmen zur Überwindung von Interoperabilitätshindernissen
Inkompatibilitäten auf der Ebene der Gestaltungstreue sind schwer zu beheben. Bietet
beispielsweise ein Drucker eine deutlich gröbere Auflösung als ein anderer, dann verläuft
die eben noch feine Schraffur im Stadtwappen unter Umständen zu einer indifferenten
schwarzen Fläche. Abhilfe schafft in einer solchen Situation die Vereinheitlichung der
Hardware oder eine professionelle Aufbereitung der Grafik. In anderen Fällen mögen
zwei verschiedene Drucker technisch in der Lage sein, identische Ergebnisse zu produzieren,
doch die Funktionsweise der jeweils notwendigen Druckertreiber einer Anwendung
kann so unterschiedlich sein, dass sie dennoch zu unterschiedlichen Ergebnissen
führt. Ein solches Phänomen ist ein internes Problem der Anwendung. Zur Behebung
dieser Art von Misshelligkeiten kann hier keine Abhilfe geleistet werden. Es mag ein
schwacher Trost sein, dass die Mehrzahl der Gestaltungsprobleme auf Inkompatibilitäten
im Dokumentenmodell zurückzuführen ist.
Inkompatibilitäten auf der Ebene des Dokumentenmodells können durch die bereits angesprochenen
Abbildungen von einem Modell ins andere überbrückt werden. Um eine
uneingeschränkte Roundtrip-lnteroperabilität zwischen beiden Modellen herzustellen,
müssten diese Übersetzungen umkehrbar sein. In der Praxis ist das selten der Fall. Dafür
gibt es eine Reihe von prinzipiellen Gründen. Einer davon ist die unterschiedliche
Verteilung des Gestaltungsreichtums innerhalb der Modelle. Beispielsweise kennt das
Dokumentenmodell der Anwendung A 25 verschiedene Linienmuster, während das von
Anwendung B nur 7 kennt. Ein weiterer prinzipieller Grund ist die Schwierigkeit, bestimmte
Merkmale eines Dokumentes als bewussten Eingriff des Anwenders oder als
das Artefakt einer Modellübersetzung zu identifizieren. Die fast unausweichlichen
Asymmetrien solcher Modell-Übersetzungen sind jedoch die zentrale Ursache für das
„schneeballhafte― Anwachsen von Anomalien beim mehrfachen Hin- und Herkonvertieren
eines Dokumentes zwischen zwei Formaten.
Roundtrip-lnteroperabilität lässt sich unter diesen Umständen dadurch erreichen, dass
nur diejenigen Gestaltungsmöglichkeiten tatsächlich in Dokumenten verwendet werden,
die in allen in Frage kommenden Dokumentenmodellen identisch sind. Ferner kann deren
Übersetzung so gestaltet werden, dass sie im Regelfall umkehrbar ist, zumindest
aber frei von Schneeball-Effekten. Dazu müssen die in Frage kommenden Gestaltungsmöglichkeiten
identifiziert werden. Dokumentenvorlagen können dann so gestaltet werden,
dass sie nur diese interoperablen Gestaltungsmöglichkeiten verwenden. Der praktische
Erfolg hängt schließlich auch davon ab, ob die Anwender über die zulässigen Gestaltungsmöglichkeiten
informiert werden und sich tatsächlich an den gegebenen Rahmen
halten.
Seite 453

Um auch diejenigen Gestaltungsmöglichkeiten nutzen zu können, die die beschriebenen
Bedingungen nicht erfüllen, bietet es sich an, den Bearbeitungszyklus der Dokumente in
zwei Phasen einzuteilen. In der ersten Phase erfolgt die eigentliche Bearbeitung. Sie
beschränkt sich soweit wie möglich auf den Dokumenteninhalt und vermeidet daher weitestgehend
gestaltende Eingriffe. Die zweite Phase beginnt, wenn die inhaltliche Bearbeitung
endgültig abgeschlossen ist. In dieser Phase erfolgt das gestalterische ‗Finetuning‗
des Dokumentes mit nur einer der beteiligten Anwendungen. Eine umlaufende Bearbeitung
findet also in dieser Phase nicht mehr statt, sodass auch die damit verbundenen
Probleme nicht mehr auftreten
Inkompatibilitäten auf der Ebene des Dateiformates sind im Vergleich zu den anderen
Ebenen eine technisch gesehen recht einfache Herausforderung, sie erwiesen sich aber
in der Vergangenheit als erhebliches Hindernis. Die nun übliche Verwendung von XML
sorgt auf dieser Ebene für eine substanzielle Erleichterung.
2.2 Vorbereitung der Migration
Bevor die Migration begonnen wird, sind einige Vorüberlegungen erforderlich, um späteren
Problemen weitgehend aus dem Weg gehen zu können. Eine wesentliche Maßnahme
dabei ist Durchführung einer intensiven Bestandsanalyse, insbesondere der vorliegenden
Office-Dokumente und -Vorlagen. Was dabei zu beachten ist, wird im nachfolgenden
Abschnitt dargelegt. Anschließend werden mögliche Verfahren zur Dokumentenkonvertierung
vorgestellt.
2.2.1 Bestandsanalyse
Zunächst einmal sollte vor einer Migration der Bestand an Dokumenten und Vorlagen
erfasst werden. Sein Zustand ist vor allem für die Wahl einer Migrationsstrategie entscheidend.
Die nachfolgende Auflistung zeigt Untersuchungskriterien, nach denen Bestandsdokumente
und Vorlagen gruppiert werden sollen. Sie verdeutlicht, was bei der
Verwendung externer Datenquellen zu beachten ist und gibt Hinweise, wie bei der Integration
externer Anwendungen zu verfahren ist:
� Weiterverwendbarkeitsbedarf von Dokumenten und Vorlagen
Dieser Untersuchungspunkt ist einer der wichtigsten, da sich hier entscheidet,
wie aufwendig sich die spätere Übernahme der Dokumente gestaltet. Umso mehr
der Bestandsdokumente zukünftig nur noch für den lesenden Zugriff benötigt
werden, desto geringer wird der Aufwand insgesamt für die Übernahme der Dokumente
sein.
o Dokumente und Vorlagen, die evtl. weiter zu bearbeiten sind für diese
Dokumente muss in der Regel eine Konvertierung in ein neues bearbeitbares
Format vorgenommen werden, ohne dass dabei so wenig als möglich
an Verlusten hinsichtlich Inhalt und Qualität entsteht.
o Dokumente, die nur noch gelesen, jedoch nicht mehr bearbeitet werden
sollen für diese Dokumente sollte mit Blick auf eine langfristige Verfügbarkeit
eine Konvertierung nach PDF oder zur Archivierung nach PDF/A
vorgenommen werden.
Seite 454

o Dokumente und Vorlagen, die nicht mehr benötigt werden, sollten auch
vollständig und endgültig gelöscht werden.
� Komplexität der Dokumente
Die Komplexität spielt hinsichtlich des Aufwandes für die Migration eine wesentliche
Rolle.
o einfache Dokumente
Diese enthalten keine Makros, proprietäre Grafiken (zum Beispiel WordArt),
Vektorgrafiken, komplexe Formatierungen oder Elemente wie Fußnoten,
Tabellen oder Indizes. Sie lassen sich am besten durch eine
BatchKonvertierung umwandeln (siehe Abschnitt III.C 2.2.2)
o komplexe Dokumente
Diese enthalten Makros, gemeinsame Komponenten, Absatz- und Seitenformatierung,
proprietäre und Vektorgrafiken, ferner viele Links und Querverweise,
OLE-Objekte, Rahmen, Text-Boxen, Fußnoten, aktive Komponenten,
Formularfelder, Formular-Controls, Formulare oder Tabellen, also
eine Fülle verschiedenster Formatierungen und Elemente. In diesem Bereich
gibt es eine sehr starke Abstufung im Komplexitätsgrad. Diese ist
aber leider weder kategorisierbar noch klar benennbar. Die Abstufung
hängt von der jeweiligen Anwendung ab, mit der sie erstellt wurde und in
welchem Maße die zuvor genannten Punkte im jeweiligen Dokument zum
Einsatz kommen. Daher ist eine genaue Untersuchung der Dokumente,
sofern diese in anderes Format zur Weiterbearbeitung überführt werden
sollen, unausweichlich.
� Komplexität der Vorlagen
Die Komplexität der Vorlagen hat hinsichtlich des Aufwandes der Migration ebenfalls
eine große Bedeutung. Die Anzahl der Vorlagen sollte daher von vornherein
auf das notwendige Maß beschränkt werden.
o einfache Vorlagen
Einfache Vorlagen bestehen aus generischem Text 431 und Formatierungen,
die als Ausgangspunkt oder grober Entwurf für neue Dokumente dienen.
Gute Beispiele hierfür sind Vorlagen für Briefe, Reports oder Protokolle,
die teilweise schon mit den Office-Suiten ausgeliefert und für die
vereinfachte Erstellung neuer Dokumente angeboten werden. Für einfache
Vorlagen bestehen die gleichen Konvertierungsoptionen wie für einfache
Dokumente.
o komplexe Vorlagen
Komplizierte Vorlagen enthalten Formfelder und Makros, die nicht immer
leicht umzuwandeln sind und daher mit Hilfe von Entwicklungsumge-
431 Ein partikulärer Text ohne Entstehungszusammenhang - also das Symbolische in einem
linguistischen Ausdruck ohne jeglichen Bezug zur Wirklichkeit.
Seite 455

ungen der jeweils anderen Office-Suiten nachgebildet oder gar völlig neu
entwickelt werden müssen.
� Verwendung von externen Datenquellen
Diese müssen in der Regel neu angebunden werden. Das ist grundsätzlich recht
problemlos möglich. Zu diesen Datenquellen zählen u.a. Datenbanken.
� Integration externer Software
Zunächst sind die Anwendungen zu identifizieren, deren Einbindung benötigt
wird. Anschließend ist zu prüfen, ob diese für die Umgebung, in die migriert wird,
verfügbar sind. Schließt die Nutzung einer neuen Office-Suite einen Betriebssystemwechsel
mit ein, muss davon ausgegangen werden, dass hier nicht alle
externen Programme lauffähig sind. Unter Umständen können ausführbare Programme
auch für die neue Umgebung erstellt werden, sofern der Quelltext der externen
Software verfügbar ist. Ansonsten müssen Alternativen gesucht werden.
Auch wenn die Migration keinen Betriebssystemwechsel mit sich bringt, ist zu
prüfen, inwieweit eine Einbindung der externen Software (zum Beispiel mittels
Schnitt-stellen) in die alternative Office-Suite möglich ist. Wird eine Integration
nicht unterstützt, müssen auch hier Alternativen gesucht werden, wodurch sich
der Migrationsaufwand erhöht.
Nachbereitung der Migration von Dokumenten
Nach einer Konvertierung ist es sinnvoll, die konvertierten Dokumente auf die korrekte
Übernahme folgender Einstellungen zu überprüfen:
� Ränder
� Tabs und Einrückungen
� Zeilenabstände innerhalb von Absätzen
� Abstände zwischen Absätzen
� Tabellen
� Kopf- und Fußzeilen
� Listen
� Grafiken
Generell ist es immer empfehlenswert, konvertierte Dokumente auf die Korrektheit der
obigen Einstellungen hin zu überprüfen und sich nicht auf Kompatibilitätsversprechen
der Office-Anbieter zu verlassen. Damit eine solche Aufgabe im Rahmen einer Migration
nicht zu einer unendlichen Geschichte wird, ist vorab zu prüfen, welche Dokumente für
welche Zwecke zukünftig noch benötigt werden. Hierbei sowie bei der Prüfung auf korrekte
beziehungsweise akzeptable Konvertierung sollten, so weit als möglich, die Eigentümer,
das heißt die Anwender, welche die Dokumente erstellt haben, in die Prüfung mit
einbezogen werden.
Es ist ferner darauf zu achten, dass nach einer Konvertierung prinzipiell das als Konvertierungsziel
gewählte Dokumentenformat beibehalten wird, um eventuelle Verluste in der
Formatierung durch mehrfaches Hin- und Herkonvertieren zu verhindern.
Seite 456

2.2.2 Wahl eines geeigneten Konvertierungsverfahrens
Prinzipiell bieten sich zwei Verfahren für die Konvertierung von Dokumenten an. Zum
einen können Dokumente in der Officeanwendung, zur der migriert werden soll, im ursprünglichen
Dateiformat geöffnet und später im nativen Ziel-Dateiformat abgespeichert
werden. Die Migration erfolgt also mithilfe eines Importfilters. Solche Filter sind inzwischen
für alle hier betrachteten Office Suiten verfügbar.
Zum anderen kann eine Batch-Konvertierung durchgeführt werden. Bei diesem Verfahren
wird eine Gruppe von Dateien mithilfe eines Konverters in ein anderes Dokumentenformat
umgewandelt.
Welches Verfahren für den vorliegenden Anwendungsfall in Frage kommt, hängt von der
Komplexität, dem Umfang und der Menge der zu konvertierenden Dateien ab.
2.3 Migration von MS Office 97 - 2003 nach StarOffice 8/OOo 2
2.3.1 Migration von Dokumenten
OOo 2/SO 8 bieten Import-/Export-Mechanismen für fremde Dateiformate, sowohl für
binäre wie für XML-basierte. Neben den integrierten Standardfiltern in OOo und SO ist
es auch möglich, den OpenXML-Translator zu nutzen. Diese OpenSource-Lösung wurde
von Novell und Microsoft entwickelt und ermöglicht den Im- und Export von Dokumenten
im ODF-Format. Nachteil dieser Lösung ist jedoch, dass sie nur unter der Novell-eigenen
OpenOffice-Distribution für Linux und Windows zur Verfügung steht. Als Alternative bietet
Sun mit seinem ODF Plugin for Microsoft Office 432 Import-/Export-Filter an, mit dem
MS-Office-Anwender Textdokumente, Kalkulationstabellen und Präsentationen im OpenOffice-
und StarOffice-eigenen Format lesen und schreiben können.
Einige dieser Mechanismen verwenden XSL-Transformationen und werden dementsprechend
durch Stylesheets konfiguriert und erweitert. Filter-Stylesheets können als Pakete
gebündelt und so auch durch den Anwender in einem Schritt installiert werden. Die Filter-Systeme
für Microsoft Office 2003-XML-Formate (SpreadsheetML und WordML) sind
mit OOo 2/SO 8 Teil des Standardinstallationssatzes433. Weiterhin sind folgende Filter
integriert:
� MS Win Word 5.0 Word 6.0, 95, 97, 2000, XP
� MS Excel 4.0, 5.0, 95, 97, 2000, XP
� MS PowerPoint 97, 2000, XP
� Corel WordPerfect
� RichTextFormat
� Text-Dateien
Aus Anwendersicht fügen sich die installierten XSLT-Filter in die vertrauten Funktionalitäten
(„Öffnen...―, „Speichern unter...―) ein und mischen sich dort mit den nach wie vor
432 http://www.sun.com/software/star/odf_plugin/
433 http://www.openoffice.org/issues/show_bug.cgi?id=33450
Seite 457

zahlreichen, fest eingebauten Binärformat-Filtern. Als Teil einer lmportfilter-Konfiguration
kann zusätzlich ein Dokumenten-Template identifiziert werden, dessen (Formatierungs-
)Styles automatisch auf das importierte Dokument angewendet werden. Es wird durch
entsprechende Zuweisungen des (Import-) Stylesheets gesteuert.
Im Allgemeinen erfolgt die Konvertierung in einer akzeptablen Qualität, außer es handelt
sich um komplexe Dokumente mit zum Beispiel Makros. Hier gibt es einige Layouteigenschaften
und Formatierungsattribute in MS Office, die in OOo/SO nicht unterstützt oder
anders behandelt werden. Infolgedessen ist es erforderlich, die durchgeführte Konvertierung
in einem gewissen Grad manuell nachzubearbeiten, um ein dem Ausgangsdokument
entsprechendes Format zu erhalten. Insbesondere bei komplexen und sehr produktspezifischen
Dokumenteneigenschaften wie Indizes, Felder, Frames und Tabellen,
können keine 100%ig befriedigenden Konvertierungen erwartet werden. Weiterhin kann
es auch in einigen Fällen bei der Konvertierung von Basis-Attributen und -
Formatierungen wie Seitenrändern oder Leerräumen zwischen Absätzen zu Unterschieden
zwischen dem Original und dem konvertierten Dokument kommen. Im Gegensatz zu
den vorherigen Versionen wurden diese Einschränkungen jedoch erheblich verringert.
Die folgende Tabelle zeigt anwendungsübergreifende und anwendungsspezifische
Schwierigkeiten, die bei einer Konvertierung auftreten können:
anwendungsübergreifend
Word (.doc)
Excel (.xls)
Anwendung Probleme
Seite 458
� Auto-Formen werden verschoben
� OLE-Objekte gehen verloren (nur unter
Linux!)
� Kontrollfelder und Formularfunktionen
� Makros und VBA-Code
� Verzeichnisse werden nicht in der gleichen
Formatierung übernommen
� Hyperlinks und Textmarken können
verloren gehen
� Kommentare werden nur bedingt
konvertiert (einige Kommentare können als
Text im Dokument erscheinen)
� animierter Text wird nicht immer dargestellt
� Referenzierungen in Tabellen können
fehlerhaft sein
� In Office 2007 gibt es „native Charts―, die
mit den älterer Versionen in Konflikt
geraten können (weil sie keine OLE
Objekte mehr sind)
� Konflikte zwischen selbst definierten
Funktionen / Formeln und integrierten
Funktionen

PowerPoint (.ppt)
Anwendung Probleme
Seite 459
� Nicht alle AutoShapes sind darstellbar
� Masterhintergrund wird nicht dargestellt
� einige Animationen werden nicht
übernommen 434
Tabelle 72: Mögliche Konvertierungsprobleme
2.3.2 Migration von Makros und Skripten
Makros und OLE/COM werden häufig leider zu intensiv zur Erweiterung der Office-
Funktionalitäten und zur Office-Automation unter Windows genutzt. Diese Methode bereitet
bei Migrationen immer wieder Probleme — manchmal sogar bei fortführenden Migrationen.
Da die Makros und Scriptings in den MS Office Suiten in erster Linie auf VBA
basieren, lassen sich diese unter OOo/SO nicht ausführen.
Für eine automatisierte Migration nach OOo/SO gibt es verschiedene Werkzeuge, welche
die vorhandenen Dokumente und Vorlagen analysieren und weitestgehend automatisiert
die vorhandenen Makros aus MS Office nach StarBasic konvertieren. Leider stehen
diese Werkzeuge nicht als freie Software zur Verfügung. Sie sind lediglich Bestandteil
der StarOffice Enterprise Edition. Daher ist es notwendig, genau zu prüfen, welcher
Weg wirtschaftlicher ist:
� die manuelle Überführung beziehungsweise Neuerstellung,
� Investition in die StarOffice Enterprise Edition oder
� die Beauftragung eines Migrationpartners von Sun, der Zugriff auf diese Werkzeuge
hat.
Das Umschreiben der Makros kann neben StarOffice Basic auch in Java oder C++ erfolgen.
Dafür steht ein IDE-Editor zur Verfügung. Grundsätzlich sollte zuvor genau geprüft
werden, welche der bestehenden Makroprogrammierungen weiterhin zwingend benötigt
werden beziehungsweise ob es nicht andere Lösungen gibt, die flexibler und plattformunabhängiger
sind.
Exkurs Dokumentgenerator
Im Rahmen des Pilotprojektes „OSS-Desktop― wurde für das Bundesministerium der
Justiz eine Anwendung entwickelt, die zur standardisierten, lT-gestützten Erzeugung von
Dokumenten dient. Der Dokumentgenerator löste eine auf VBA-Makros basierende Anwendung
ab. Die ursprüngliche Altanwendung bot keine Unterstützung von OpenOffice
beziehungsweise StarOffice, war in einer heterogenen Office-Umgebung nicht einsetzbar
und musste somit abgelöst werden. Der Dokumentgenerator wird unter einer GPL-
Lizenz entwickelt und steht somit allen Interessenten frei zur Verfügung. Die Anwendung
wurde von der tarent GmbH 435 entwickelt. Der Dokumentgenerator dient zur Erstellung
434 siehe dazu den „Migration Guide StarOffice 8― – im Gegensatz zur letzten Version sollen
nunmehr fast alle Animationen und Bildübergänge darstellbar sein
435 Maintainer des Dokumentgenerators: www.tarent.de

und Bearbeitung unterschiedlicher Dokumenttypen, wie sie für die tägliche Arbeit benötigt
werden. Im BMJ werden mit dem Dokumentgenerator beispielsweise Verfügungen
und Reinschriften in unterschiedlicher Ausprägung erstellt, entweder als Vermerk, Verfügung,
Ministervorlage oder Staatssekretärsvorlage.
Gegenüber anderen Lösungen, die ausschließlich die Skript und Makroschnittstellen von
Microsoft Word oder OOo/SO nutzen, wurde der Dokumentgenerator in Java geschrieben.
Er ist daher eine einheitliche Lösung sowohl für Linux- als auch für Windowsbasierte
Clientsysteme. Der Dokumentgenerator unterstützt weiterhin die Textverarbeitungsanwendungen
OOo/SO als auch Microsoft Office. Die folgende Auflistung nennt die
vom Dokumentgenerator unterstützten Office-Suiten:
� StarOffice 7, 8
� OpenOffice.org 1.x, 2
� Microsoft Office 97 - 2003
Der Dokumentgenerator ist in Java implementiert und benötigt für die Nutzung eine Java-Laufzeitumgebung
(Java-Laufzeitumgebung ab Version 1.4) auf den jeweiligen
Client-Systemen. Die Anwendung ist in die jeweiligen Office-Oberflächen (Menü, Symbolleisten)
mit den jeweils officespezifischen verfügbaren Technologien integriert (Star-
Basic/VBA). Da es sich hierbei in der Regel nur um die Aufrufe der Anwendungsdialoge
handelt, ist diese lntegrationsschicht sehr klein und damit auch in der Pflege unkritisch.
Der Dokumentgenerator realisiert die gesamte Logik und Automatismen, die ursprünglich
durch die Verwendung von VBA-Makros implementiert wurden. Er verwendet einfache
Dokumentvorlagen der jeweiligen Office-Suiten zur Bereitstellung des Enddokuments.
Die Anwendung trennt deutlich zwischen Anwendungslogik und Präsentationsschicht,
somit wird eine Unabhängigkeit von der jeweiligen Office-Umgebung erreicht,
und auf den Einsatz von Makros kann verzichtet werden. Die zusätzlich benötigen Dokument-Vorlagen
können vom Anwender oder den Administratoren mit Hilfe von Platzhaltern
und Formatvorlagen selbst gestaltet und den jeweiligen Anforderungen angepasst
werden. In der folgenden Abbildung wird die grundsätzliche Architektur des Dokumentgenerators
dargestellt:
Seite 460

Abbildung 70: Architektur des Dokumentengenerators
Der Nutzer führt die Erstellung der jeweiligen Dokumente mit seinem gewohnten Office-
Programm durch und empfindet den Dokumentgenerator durch die Integration in die
jeweiligen Office-Oberflächen als Teil der Office-Lösung. Der Nutzer kann den Dokumentgenerator
mittels einer eigenen Symbolleiste oder über das Anwendungsmenü bedienen.
Die Dialoge des Dokumentgenerators erscheinen als „Kindfenster― der jeweiligen
Textverarbeitung.
Bei der Erstellung von Dokumenten, insbesondere von Anschreiben, können die Adressaten
der Schreiben aus Adresskatalogen ausgewählt werden. Die Adresskataloge können
mittels der Dialoge des Dokumentgenerators gepflegt werden. Bei den Adresskatalogen
werden zum einen persönliche Kataloge ― diese sind durch den Nutzer frei bearbeitbar
― und zum anderen schreibgeschützte Kataloge unterschieden, die von zentraler
Stelle bereitgestellt werden. Die Bereitstellung der Adressdaten kann sowohl mittels
einfacher Textdateien als auch mittels Datenbanksystemen erfolgen. Die Textdateien
haben unter Windows- als auch Linux-basierten Systemen das gleiche Format. Auch
kann der Dokumentgenerator Adressen im vcard-Format verwenden, wie sie aus verschiedenen
Groupware-Lösungen (zum Beispiel Microsoft Outlook) exportiert werden
können. Eine weitere Variante ist die Nutzung eines zentralen LDAP Verzeichnisdienstes
für die Bereitstellung von Adressinformationen.
2.3.3 Migration von Datenquellen
Microsoft Office 2007 enthält spezielle Treiber, die zum Abrufen von Daten aus mehreren
Datenquellen verwendet werden können. Hierzu gehören u.a.:
� Microsoft SQL Server Analysis Services (OLAP-Anbieter)
� Microsoft Office
� dBASE
� Oracle
Seite 461

Es können auch ODBC-Treiber von anderen Herstellern verwendet werden, um Informationen
aus Datenquellen abzurufen, die hier nicht aufgelistet sind. Informationen zum
Installieren eines ODBC-Treibers oder eines Datenquellentreibers, die nicht hier aufgelistet
sind, finden sich in der Dokumentation zur jeweiligen Datenbank.
2.3.4 Integration von Anwendungen
Hinsichtlich der Integration von externen (das heißt nicht-Office-) Anwendungen und der
Migration solcher Integrationen nach OOo/SO spielt die Art der Integration von MS Office
Suiten und die damit verbundenen Abhängigkeiten (Lock-In Szenarien) eine wichtige
Rolle. Viele der heute eingesetzten Fach- und Standardanwendungen machen starken
Gebrauch von proprietären API-Modulen, wie API, COM und DDE.
Der Grad der Abhängigkeit solcher Integrationen kann ganz unterschiedlich sein. Eine
einfache und noch recht unproblematische Integration ist die Nutzung der MAPI-
Schnittstelle, um aus einer Anwendung heraus beispielsweise auf bestimmte Office-
Anwendungen zuzugreifen. Am Ende ist jedoch unerheblich, ob dies eine Micosoft-
Office-Anwendung oder eine OpenOffice.org-Anwendung ist.
Weitaus problematischer stellt sich eine Integration dar, wenn eine Anwendung nur bestimmte
MS-Office-Anwendungen zulässt beziehungsweise diese sogar zwingend benötigt
werden, um die volle Funktionalität dieser Anwendung nutzen zu können.
Diese Unterschiede bei der Integration von MS Office-Anwendungen in anderen Anwendungen
erfordern eine genaue Prüfung, ob eine Migration technisch machbar und welcher
Aufwand damit verbunden ist. Sofern der Source Code der externen Anwendung
verfügbar ist, muss im Einzelfall geprüft werden, ob eine Integration von OOo/SO-
Anwendungen über die von OOo/SO bereitgestellte Schnittstelle UNO (Universal Network
Objects) möglich ist.
2.4 Migration von MS Office 97 - 2003 nach MS Office 2007
Die in diesem Abschnitt erörterte Migration zwischen den alten Versionen von MS Office
zum neuen Produkt wird im Schwerpunkt zwischen der Office-Suite 2003 und 2007 beschrieben.
Der Fokus der nachfolgenden Betrachtungen liegt auf einer Migration von MS
Office 2003 nach MS Office 2007, da MS Office 2003 bereits in der Vorgängerversion
des Migrationsleitfadens als Ziel von Migrationspfaden betrachtet wurde. Relevante
Punkte, die ältere Versionen von MS Office betreffen und von der Ausgangslage MS
Office 2003 abweichen, werden ebenfalls betrachtet.
2.4.1 Migration von Dokumenten
MS Office 2007 ist von Hause aus in der Lage, die Dokumentenformate der vorherigen
Versionen zu öffnen und zu bearbeiten. Das Standard-Dokumentenformat kann vom
Nutzer auch manuell an die entsprechenden Bedürfnisse angepasst werden. Jedoch
birgt die Nutzung unterschiedlicher Dokumentenformate immer die Gefahr, dass Daten
nicht verlustfrei weitergegeben werden. Microsoft bietet daher für Nutzer der älteren Versionen
MS Office 2003 verschiedene Updates an, mit denen eine Nutzung des neuen
Dateiformats ermöglicht wird. In Verbindung mit dem von Microsoft angebotenen Office
Seite 462

Migration Planning Manager 436 (OMPM) ist es möglich, alle auf dem Rechner befindlichen
Office-Dokumente zu analysieren und mittels Batch-Konvertierung (massenweise
Konvertierung) für die neue Office 2007 Umgebung verarbeitbar zu machen und in das
neue Dateiformat zu überführen. Da der OMPM jedoch für eine Konvertierung speziell
von Dokumenten der Office 2003 Version entwickelt wurde, ist es für Nutzer älterer Office-Versionen
unbedingt ratsam, Änderungen hinsichtlich der Migrationsmöglichkeiten zu
Office 2003 zu beachten. 437
Die Kern-Anwendungen von MS Office 2007 (Word, Excel und PowerPoint) bieten einen
Kompatibilitätsmodus. Er ermöglicht dem Nutzer, Dokumente in MS Office 2007 mit den
Mitteln älterer Versionen zu bearbeiten. Wird beispielsweise ein Diagramm eingefügt,
dann öffnet sich im Kompatibilitätsmodus statt des Diagramm-Tools von Office 2007 das
der älteren Office 2003 Version. Dadurch kann dieses in älteren Versionen wieder bearbeitet
werden und die Abwärtskompatibilität zwischen den Versionen wird sicher gestellt.
Das Einfügen ohne diesen Modus hätte zur Folge, dass dieses Objekt in älteren Versionen
nur eingeschränkt zu editieren wäre. Der Kompatibilitätsmodus ist besonders dann
von Vorteil, wenn in Organisationen MS Office 2007 mit älteren Versionen parallel betrieben
wird. Eine Übersicht darüber, wann sich der Modus aktiviert, ist in der folgenden
Tabelle zu sehen:
Aktion in Office 2007 Excel 2007 PowerPoint
2007
Seite 463
Word 2007
Öffnen von Dateiformaten älterer Office-Versionen X X X
Konvertierung von Dokumenten in Office 2007 in ein
Format älterer Versionen (mittels Speichern unter)
Ändern des Standard-Dokumentenformates
(in das einer älteren Version)
Erzeugen eines neuen Dokuments basierend auf
einem .dot Template
(aus älteren Office-Versionen)
Tabelle 73: Kompatibilitätsmodus bei MS Office 2007
X X X
X X X
Durch das Nutzen dieses Features werden Kompatibilitätsprobleme zwischen den Versionen
erheblich reduziert und eine verlustfreie Migration ermöglicht. Sollten dennoch
Kompatibilitätsprobleme auftreten, wird dem Anwender eine Meldung über eventuelle
Datenverluste und der Grund hierfür angezeigt. Wenn beispielsweise in Excel 2007 eine
Tabelle mit 800.000 Zeilen im Dokumentenformat einer älteren Version gespeichert werden
soll, so wird dem Nutzer die Gefahr eines Datenverlustes gemeldet. Aufgrund der
Erweiterungen und Updatemöglichkeiten ist eine Migration von Dokumenten älterer MS
Office-Anwendungen zur aktuellen Version ohne große Probleme möglich.
436 http://go.microsoft.com/fwlink?linkid=75727
437 Informationen dazu sind im migrationsleitfaden 2.1 zu finden
X

2.4.2 Migration von Makros und Skripten
In der Standardeinstellung enthalten Dokumente im OOXML-Format (XML-Format in MS
Office 2007) keinen ausführbaren Code (keine Makros). Dateien, in denen Makros
enthalten sind, besitzen dasselbe Format wie Dateien ohne Makros. Äußerlich ist also
zunächst einmal kein Unterschied festzustellen. Dateien mit Makros enthalten jedoch
zusätzliche Komponenten, die von dem im Dokument enthaltenen Automatisierungstyp
abhängig sind. So enthält zum Beispiel eine Datei mit aktivierten VBA-Makros eine binäre
Komponente, in der wiederum das VBA-Makro enthalten ist. Wenn eine codespezifische
Komponente in einer Datei ohne Makros enthalten ist (ob versehentlich oder böswillig),
werden die Office-Anwendungen das Ausführen des Codes nicht gestatten —
ohne jede Ausnahme.
Eine Überführung von Makros aus älteren MS Office-Versionen ist problemlos durchführbar.
Die neue Office-Version erkennt selbstständig beim Öffnen den vorhandenen
Code und mittels Speichern im entsprechenden Dokumentenformat (.docm zum Beispiel
bei Word-Dokumenten) wird dieser dann ausführbar.
Das neue Format kann von den neuen MS Office-Anwendungen auf codebasierte Komponenten
und Beziehungen überprüft werden, ohne dass möglicherweise gefährliche
Code ausgeführt werden. Erscheint eine Datei verdächtig, können alle zum Ausführen
von Code fähigen Komponenten aus der Datei entfernt werden, damit der Code keinen
Schaden anrichten kann.
2.4.3 Migration von Datenquellen
Microsoft Office 2007 enthält spezielle Treiber, die zum Abrufen von Daten aus den folgenden
Datenquellen verwendet werden können:
� Microsoft SQL Server Analysis Services (OLAP-Anbieter)
� Microsoft Office Access (ab Version 97 und tiefer muss vorkonvertiert werden)
� dBASE
� Microsoft FoxPro
� Microsoft Office Excel
� Oracle
� Paradox
Mit dem Datenverbindungs-Assistenten von Office 2007 kann eine Verbindung zu einer
bereits definierten externen Datenquelle hergestellt werden.
2.4.4 Integration von externen Anwendungen
In Anlehnung an die Inhalte aus III.C 2.3.4 spielt der Grad der Integration von Microsoft-
Office Suiten bei der hier betrachteten fortführenden Migration eine weniger bedeutende
Rolle, da es sich um die gleiche Produktlinie handelt. Allerdings sollte auch hier die
Kompatibilität der Integrationen im Vorfeld genau geprüft werden. Darüber, ob hier gegebenenfalls
größere Probleme bestehen, liegen bisher noch keine gesicherten Erkenntnisse
vor.
Seite 464

2.5 Migration von StarOffice 7/8 u. OOo1/2 nach MS Office 2007
2.5.1 Migration von Dokumenten
MS Office 2007 bietet von Haus aus keine Unterstützung für die Dokumentenformate der
anderen hier betrachteten Office-Umgebungen, sodass es nicht möglich ist, ODF-
Dokumente oder Dokumente im alten OOo/SO -Format direkt zu importieren. Es befindet
sich jedoch ein von Microsoft subventionierter Konverter in der Entwicklung 438 , der den
Import und Export von ODF-Dokumenten in MS Office 2007 ermöglichen soll.
Der Konverter ist auch als eigenständige Anwendung lauffähig und eignet sich somit zur
Batch-Konvertierung mehrerer Dokumente. Er erzeugt allerdings kein internes Dokumentenmodell,
sondern übersetzt auf der Ebene der XML-Datenstruktur per XSLT. Dies
hat zur Folge, dass einfache Dokumente in der Regel zufriedenstellend übersetzt werden.
Jedoch gibt es Merkmale, in denen sich die Dokumentenmodelle konzeptuell unterscheiden.
Bei der Übersetzung dieser Merkmale produziert der Konverter Fehler beziehungsweise
unnötig komplizierte Dokumente. Dies betrifft beispielsweise folgende
Merkmale von Textdokumenten:
� Einige Formatierungsattribute (Kapitälchen, blinkender Text, Zeilenabstand mit
Durchschuss, Hintergrundbilder für Absätze und Tabellen)
� Automatische Seitenumbrüche nach Absätzen
� Zeilennummerierung
� Sub-Tabellen (nahtlos in eine Tabelle eingefügte Unter-Tabellen)
Da der Konverter jedoch auf solche Schwierigkeiten explizit hinweist, hält sich der Aufwand
für die manuelle Durchsicht der Ergebnisse in Grenzen.
Sollte der eben genannte Weg nur unbefriedigende Ergebnisse erzielen oder liegen die
Quelldateien noch im alten OOo 1.X-/SO 7-Dateiformat vor, so empfiehlt es sich, die
Dokumente mittels der in OpenOffice.org/StarOffice eingebauten Möglichkeiten in das
korrespondierende proprietäre Microsoft-Binärformat zu konvertieren, welches von
MS Office 2007 weitgehend problemlos eingelesen wird. Alternativ bietet sich gegebenenfalls
der ebenfalls über zwei Schritte gehende Konvertierungspfad vom alten
OOo 1.X-/SO 7-Dateiformat zu ODF und dann zu OOXML an. Letztendlich muss die
Qualität der Konvertierungen darüber entscheiden, welcher Weg der beste ist.
2.5.2 Migration von Makros und Skripten
Keiner der in Abschnitt III.C angesprochenen Wege ermöglicht eine automatische Migration
von Makros und OOo/SO -Erweiterungen, sodass eine Neuentwicklung der benötigten
Funktionalitäten notwendig ist. Da aber die Hersteller aller hier angesprochenen
Office-Suiten die jeweiligen Makro-Sprachen bei der Spezifikation ihrer offenen Dateiformate
außen vor lassen, empfiehlt es sich zu evaluieren, ob es nicht im Interesse der
Sicherheit und Interoperabilität sinnvoll ist, die Dokumente mit möglichst wenig „Eigenintelligenz"
auszustatten und stattdessen die Geschäftslogik in zentralisierte Prozesse
438 http://odf-converter.sourceforge.net/
Seite 465

auszulagern. Hierdurch würde gleichzeitig die Wartbarkeit verbessert, da die Änderungen
zentral vorgenommen werden können.
2.5.3 Migration von Datenquellen
Bei der Migration von Datenquellen muss zwischen OpenOffice.org 1.x / StarOffice 7
und OpenOffice.org 2 / StarOffice 8 unterschieden werden, da mit der neuen Version
eine Datenbankkomponente enthalten ist und weitreichende Änderungen bei der Anbindung
von Datenquellen vorgenommen worden sind.
2.5.3.1 Datenanbindung in OpenOffice.org 1.x / StarOffice 7
OpenOffice.org 1.x beziehungsweise StarOffice 7 ermöglichen es, eine Reihe von extern
gespeicherten Datenquellen in der Office-Suite zu registrieren und innerhalb von .sx*-
Dokumenten auf diese zuzugreifen. Bei der für die Migration notwendigen Konvertierung
in das MS-Office-Dateiformat geht diese Bindung allerdings verloren, sodass etwa die
erzeugten MS-Word Dokumente an der betreffenden Stelle lediglich eine textuelle Repräsentation
des jeweiligen Feldnamens enthalten (siehe Abbildung 71).
Abbildung 71: Externe Datenfelder nach Export in MS-Word Dokument
Da die Daten jedoch extern gespeichert und entweder über standardisierte Schnittstellen
wie ODBC beziehungsweise JDBC angesprochen werden oder in einem Format eines
Drittherstellers (zum Beispiel dBase) vorliegen, können die Daten nach Abschluss der
Migration manuell wieder an das Dokument angebunden werden.
2.5.3.2 Datenanbindung in OpenOffice.org 2 / StarOffice 8
In den neuen Versionen der Office-Suiten erfolgt die Anbindung externer Daten immer
über das integrierte Datenbankmodul Base. Dieses bietet neben der oben beschriebe-
Seite 466

nen Möglichkeit, externe Datenbestände einzubinden auch ein natives Datenbankformat
an. Dabei handelt es sich um die Dateistrukturen der Open Source-Datenbank HSQL,
die in die ODF-ZIP-Datei eingebettet sind. Sie können dort problemlos entnommen und
durch eine selbständige HSQL-Instanz 439 erschlossen werden.
2.5.4 Integration von Anwendungen
Die Entscheidungen und Problemstellungen bei einer ablösenden Migration von OpenOffice.org/StarOffice
durch Microsoft Office decken sich mit den in Abschnitt III.C 2.3.4
skizzierten Überlegungen. An die Stelle der dort genannten, Microsoft-spezifischen
Schnittstellen tritt hier im Wesentlichen die Programmierschnittstelle UNO 440 der Office-
Suiten OpenOffice.org beziehungsweise StarOffice. Einfach gestrickte, lose gekoppelte
Anwendungsintegrationen wie zum Beispiel das Öffnen von Hyperlinks im Web-Browser
oder die Einbindung von Adressbüchern verschiedener E-Mail-Programme sind bereits
im Standardumfang von Microsoft Office enthalten oder lassen sich durch Installation
entsprechender Software von Drittherstellern leicht nachrüsten. Hingegen erfordern Anwendungen,
die vergleichsweise eng an die interne Funktionsweise der Office-Suiten
gebunden sind (beispielsweise die sogenannten „Extensions"), eine Neuentwicklung
oder die Suche nach einem gleichwertigen Ersatz.
2.6 Migration von StarOffice 7/OOo1 nach StarOffice 8/OOo2Star
2.6.1 Migration von Dokumenten
SO 7/OOo 1 und SO 8/OOo 2 verwenden unterschiedliche Dateiformate. Daher werden
für eine Migration entsprechende Konverter beziehungsweise Im- und Exportfilter benötigt,
die jedoch durch die neuen Versionen zur Verfügung gestellt werden.
Die folgende Tabelle zeigt die in SO 8/OOo 2 zur Verfügung gestellten Filter, die alle
sowohl für den Export als auch für den Import verwendet werden können:
Filtername Betreffendes Format
StarOffice 6.0/7 Text Document StarOffice XML Textdokument
StarOffice 6.0/7 Text Document Template StarOffice_XML Textvorlage
OpenDocument Text Open Document Text
OpenDocument Text Template Open Document Textvorlage
StarOffice 6.0/7 Master Document Writer Globaldocument
OpenDocument Master Document Open Document Master
StarOffice 6.0/7 Spreadsheet StarOffice XML (Calc)
439 Siehe http://hsqldb.org/.
440 Siehe http://udk.openoffice.org/
Seite 467

Filtername Betreffendes Format
StarOffice 6.0/7 Spreadsheet Template StarOffice XML Vorlage (Calc)
OpenDocument Spreadsheet Open Dokument Tabellendokument
OpenDocument Spreadsheet Template Open Dokument Tabellendokumentvorlage
StarOffice 6.0/7 Drawing StarOffice XML (Draw)
StarOffice 6.0/7 Drawing Template StarOffice XML Vorlage (Draw)
OpenDocument Drawing OpenDocument Zeichnung
OpenDocument Drawing Template OpenDocument Zeichnungsvorlage
StarOffice 6.0/7 Presentation StarOffice XML (Impress)
StarOffice 6.0/7 Presentation Template StarOffice XML Vorlage (Impress)
OpenDocument Presentation OpenDocument Präsentation
OpenDocument Presentation Template OpenDocument Präsentationsvorlage
StarOffice 6.0/7 Chart StarOffice XML (Chart)
OpenDocument Chart OpenDocument Chartdokument
StarOffice 6.0/7 Formula StarOffice XML (Math)
OpenDocument Formula OpenDocument Formeldeditor
Tabelle 74: Verfügbare Dokumentenformatfilter in SO 8/OOo 2
Die Funktionalitäten der gezeigten Filter sind sehr umfangreich und ermöglichen eine
vollständige Konvertierung zwischen den Dokumenten und Vorlagen in die verschiedenen
Datei-Formate. Eine Installation der Filter ist nicht erforderlich, da sie zum Standardumfang
der Office Suite gehören und beim Öffnen eines Dokumentes automatisch
angewandt werden. Seit der Version 1.1.5 ist der Filter für das Open Document Format
in OpenOffice.org integriert. Für ältere Versionen existiert ein Patch, das diese Funktionalität
bereitstellt. Für die Nutzung sind daher keine besonderen Kenntnisse notwendig.
Die Migration kann hier problemlos durch das Öffnen der Dokumente in der Anwendung
erfolgen. Auf eine automatisierte Konvertierung mit Batch-Scripten kann verzichtet werden.
Erwähnenswert ist ferner, dass es für die alten Versionen, SO 7/OOo 1, einen
Patch gibt, mit dessen Hilfe diese dann auch das neue Format (ODF) nutzen können.
2.6.2 Migration von Makros und Skripten
Innerhalb der beiden OpenOffice.org- und StarOffice-Versionen gibt es keine wesentlichen
Unterschiede in der Programmierung. Der Nutzer kann weiterhin auf ein betriebssystem-
und programmiersprachenunabhängiges API zurückgreifen und mit StarBasic,
Java, C++ und Python Erweiterungen erstellen.
Seite 468

Dennoch können sich Probleme bei der Migration älterer Makros und Skripte ergeben.
Das liegt insbesondere daran, dass diese Erweiterungen sehr nah am internen Systemmodell
von OpenOffice.org ansetzen und bestimmte Funktionalitäten durch das API evtl.
nicht mehr angeboten werden. Das kann dazu führen, dass Teile von Makros nicht mehr
ausführbar sind oder nicht mehr die gewünschte Funktionalität liefern. Bei quelloffenen
Entwicklungen findet sich bei solchen Problemen meist Hilfe in der Dokumentation oder
den „Developer Notes―. Unternehmensinterne Macroentwicklungen sollten vor ihrer Anwendung
auch auf ihre korrekte Funktionsweise überprüft werden.
2.6.3 Migration von Datenquellen
Seit StarOffice 7 und OpenOffice.org 1.1 verfügt die Office-Suite über eine integrierte,
systemunabhängige Datenbankschnittstelle namens Star Database Connectivity
(SDBC). Sie gestattet einen Highlevel-Zugriff 441 auf Datenbanken, unabhängig von den
darunter liegenden Datenbank-BackEnds. Die Einbindung der Datenquellen erfolgt mittels
Treibern, die entweder von Datenbankhersteller geliefert oder mit OpenOffice.org
entwickelt werden. Seit der Version 2 von OpenOffice.org beziehungsweise StarOffice 8
verfügt die OfficeSuite über ein eigenständiges Datenbankmodul, welches das bisher
verwendete Datenbank-Frontend ablöst und die Anbindung von Datenquellen vereinfacht.
Bei einer Migration der alten Datenquellen sind keine Probleme zu erwarten.
2.6.4 Integration von Anwendungen
OpenOffice.org bietet verschiedene Programmierschnittstellen für die Anwendungsintegration.
Mit der Office-Bean, einer Java Klasse, lassen sich OpenOffice.org-
Komponenten in eigene Java-Anwendungen einbinden. Sie ermöglichen damit die Integration
von Funktionen aus der Office-Suite, die mittels eingefügter Buttons aufgerufen
werden können. Die Office-Bean dient dem Einbetten der Office-Funktionalität in Java-
Programme sowie dem Einbetten von Java-Programmen in OpenOffice.org/StarOffice.
Sie verfügt seit der Version 2 über die notwendige Stabilität und Reife für den produktiven
Einsatz. Die Office-Suiten verfügen weiterhin in beiden Versionen über eine OpenOffice/StarOffice-spezifische
Objekt-Middleware namens UNO, die sich aus StarBasic,
Java, C++ und Python ansprechen lässt. UNO ist eine Schnittstelle, über die unterschiedliche
Programmiersprachen die Funktionen von Open Office nutzen. Da die Systeme
zur Anwendungsintegration vom Prinzip her gleich geblieben sind, funktionell aber
deutlich erweitert wurden, kann von einer problemlosen Migration ausgegangen werden,
sofern das gleiche Betriebssystem verwendet wird.
441 Ein Zugriff der unabhängig von dem darunter liegenden Datenbank-Backend erfolgt.
Seite 469

3 Bezüge
3.1 Teaming-/Workgroup Software
Um effizient in Arbeitsgruppen arbeiten zu können, wird Teaming-/Workgroup Software
eingesetzt. Diese Programme ermöglichen eine effiziente Publikation und Archivierung
von Dateien sowie verschiedene Kommunikationsmöglichkeiten. Zu diesem Zweck sind
deren Funktionen häufig als PlugIns innerhalb der Officeanwendungen integrierbar.
Es entsteht hierdurch ein direkter Bezug zu dem Abschnitt III.B .
Seite 470

D Thema Backend-Integration
1 Produkte/Technologien
Dieses Kapitel befasst sich primär mit den beiden Softwareplattformen J2EE und .NET.
Beide Plattformen ermöglichen die Entwicklung von Individualanwendungen. Dabei spielt
es keine Rolle, um welche Art von Anwendung es sich handelt. Auf beiden Plattformen
können sowohl Desktop-Anwendungen für den Client als auch Server-Anwendungen
entwickelt werden. Ein Schwerpunkt beider Technologien ist die Entwicklung von Web-
Anwendungen.
Im Fokus dieses Kapitels stehen jedoch weniger die Funktionalitäten für die Entwicklung
von Web-Anwendungen, sondern die grundlegenden Funktionalitäten im Bereich der
Entwicklung von Anwendungen auf Serverseite sowie die konzeptionellen Unterschiede
der beiden Technologien. Auf die migrationsrelevanten Funktionalitäten in Hinblick auf
die Integration von Backend-Systemen wird darüber hinaus auch im Kapitel Migrationspfade
(siehe Kap.0) eingegangen.
Neben den beiden Softwareplattformen J2EE und .NET finden sich in diesem Rahmen
auch Ausführungen zu CORBA, einer bewährten Middleware-Technologie. Im Unterschied
zu J2EE und .NET können mittels CORBA jedoch keine Anwendungen entwickelt
werden.
Aber auch zwischen Java, insbesondere J2EE, und .NET gibt es grundlegende Unterschiede:
J2EE hat zum Ziel, eine einheitliche, plattformunabhängige Laufzeitumgebung
für verteilte Applikationen bereitzustellen. Dieses Ziel „eine Sprache für alle Plattformen―
ist mit Hilfe beeindruckender Entwicklungsumgebungen erfolgreich in die Praxis umgesetzt
worden. Das .NET-Framework geht den umgekehrten Weg. Hier wird für alle Sprachen,
die vor allem in der Windows-Welt zur Programmierung herangezogen wurden
(u.a. auch Visual Basic), eine einheitliche Laufzeitumgebung für Windows-Maschinen
(Clients und Server) bereitgestellt. Kompatibilität mit anderen Plattformen ist bei diesem
Ansatz „eine Plattform für alle Sprachen― im Kern nicht realisiert worden. Wie die Beispiele
in den folgenden Kapiteln zeigen werden, sind diese grundlegenden Unterschiede
der beiden Ansätze heute nicht mehr in jedem Fall gültig.
1.1 Microsoft .NET-Plattform (COM, DCOM, OLE, ActiveX)
Bei der Microsoft .NET-Plattform handelt es sich um die Umsetzung des sogenannten
Common-Language-Infrastructure-Standard 442 für Windows. Wichtige Teile des Frameworks
(die Common Language Infrastructure (CLI) und die Programmiersprache C#)
wurden darüber hinaus als ISO-Standard verabschiedet. Ziel dieses Standards ist es, die
Entwicklung und die Ausführung von Anwendungen weitgehend unabhängig von der
verwendeten Programmiersprache zu machen.
442 http://www.ecma-international.org/publications/standards/Ecma-335.htm
Seite 471

Damit sollte insbesondere dem Wildwuchs an speziellen Abstraktionstechnologien 443 , die
auf die Unterstützung der Entwicklung einer bestimmten Art von Anwendungen zielten,
sowie den aus der mangelnden Integration dieser Technologien resultierenden Problemen
444 begegnet werden.
Das .NET-Framework ist im Microsoft-Betriebssystem Windows Vista standardmäßig
enthalten und für andere Microsoft-Betriebssysteme kostenlos nachinstallierbar.
Die folgende Abbildung zeigt einen Überblick der Komponenten des Frameworks:
J# C# ... C++
Compiler Compiler Compiler Compiler
IL Code IL Code IL Code IL Code
Common Language Runtime
Betriebssystem
JIT Compiler
Abbildung 72: Komponenten des .NET-Frameworks
Seite 472
ASM Code
Im Common-Language-Infrastructure-Standard werden die folgenden Konzepte spezifiziert:
� Common Language Specification - Festlegung eines einheitlichen Grundumfangs
der einsetzbaren Programmiersprachen
� Common Type System - Definition eines gemeinsamen Typsystems
� Virtual Execution System - Laufzeitumgebung, die eine ebenfalls standardisierte
Zwischensprache (Common Intermediate Language – CIL) verarbeiten kann
� Bibliotheken und Profile - Spezifikation von sieben Standardbibliotheken, die typische
wiederverwendbare Anwendungsfunktionalität enthalten sowie von zwei
Profilen, die sinnvolle Grundmengen von einer Standardimplementation umgesetzter
Bibliotheken beschreiben.
Die Anwendungen werden in einer von .NET unterstützten Sprache programmiert und
können auf die umfangreichen .NET-Klassenbibliotheken zurückgreifen. Durch das .NET
443 Beispiele hierfür sind Microsoft Active Server Pages (ASP) zur Entwicklung aktiver Web-
Seiten und Microsoft Active Template Library (ATL) zur Benutzung anderer Komponenten
durch die eigene Anwendung.
444 Zur Erstellung einer aktiven Web-Seite, die andere Komponenten verwenden soll, muss
sich der Entwickler sowohl in die ASP- als auch in die ATL-Technologie einarbeiten und
beide kombiniert verwenden.

Framework wird eine große Anzahl an Programmiersprachen unterstützt. Der jeweilige
Compiler übersetzt den Quellcode in einen Befehlscode (keinen Maschinencode), der
als CIL-Code (Common Intermediate Language), teilweise auch als IL-Code (Intermediate
Language) bezeichnet wird. Die Kombination aus solchen Kompilaten und zugehörigen
Metadaten wird als „Assembly" bezeichnet und ist die typische Deployment-Einheit
der .NET-Welt. Ergebnis dieser Aktion ist zum Beispiel eine EXE-Datei. Wird diese EXE-
Datei geladen, wird sie von der Common Language Runtime (CLR) mit ihrem JIT-
Compiler (Just-In-Time) in Maschinencode umgesetzt.
In der .NET-Plattform von Microsoft implementiert die Common Language Runtime
(CLR) die Laufzeitumgebung (VES). Neben der Generierung und Verwaltung von Maschinencode
bietet die CLR weitere Leistungen, insbesondere zur Speicherverwaltung
(Garbage Collection).
Ergänzt wird diese neben den Standardbibliotheken durch zahlreiche weitere Klassenbibliotheken
(Microsoft spricht hier von „Technologien‖), durch die .NET in seinem vollen
Umfang nur für Windows verfügbar ist. .NET gibt es in den folgenden Versionen:
� .NET 2.0:
Umfangreichere Erweiterung der Funktionalitäten von .NET, zum Beispiel Data
Protection API (DPAPI), FTP-Unterstützung, bessere Unterstützung für die Internationalisierung
von Anwendungen
� .NET 3.0:
Umfasst .NET 2.0 und ergänzt dieses um einige Microsoft-Technologien 445
� Windows Presentation Foundation:
einheitlicher Ansatz für verschiedene Benutzeroberflächen
� Windows Workflow Foundation:
Unterstützung workflowbasierter Anwendungen
� Windows Communication Foundation:
Unterstützung serviceorientierter Anwendungen durch einen einheitlichen Ansatz
für unterschiedliche Kommunikationstechnologien
� Windows CardSpace:
zentrale und konsistente Verwaltung digitaler Identitäten zur Authentifizierung
(sowohl von Nutzern als auch von Anwendungen)
Neben der Programmiersprachenunabhängigkeit liegt ein weiterer Schwerpunkt der
.NET-Plattform auf der Unterstützung der Entwicklung verteilter Anwendungen, insbesondere
unter Verwendung von Web Services.
Durch die .NET-Plattform sollen auch frühere Microsoft-Technologien zur komponentenbasierten
Anwendungsentwicklung, wie zum Beispiel COM, DCOM und ActiveX abgelöst
werden. Diese Ansätze können jedoch auch weiterhin mit .NET koexistieren. Es existieren
darüber hinaus Möglichkeiten zum gegenseitigen Aufruf von .NET- und COM-
Funktionen. Aufgrund des robusteren Sicherheitsmodells und des automatischen
445 http://www.microsoft.com/germany/msdn/library/net/EinfuehrungInNETFramework30.
mspx?mfr=true
Seite 473

Speichermanagements empfiehlt Microsoft jedoch auch für Neuentwicklungen die .NET-
Plattform.
Das .NET-Framework erlaubt mittels der sogenannten Codezugriffssicherheit (Code
Access Security, CAS) die Beeinflussung der Berechtigung auf Anwendungsebene. Auf
diese Weise kann festgelegt werden, welche Aktionen (zum Beispiel Zugriff auf Ressourcen
wie Dateien, Umgebungsvariablen, Drucker oder Datenbanken) eine Anwendung
durchführen darf, und zwar unabhängig davon, ob der ausführende Benutzer ein
einfacher Benutzer oder ein Administrator ist. Neben den standardmäßig vorhandenen
Berechtigungen können auch neue Berechtigungen implementiert werden. Darüber
hinaus existiert auch die Möglichkeit, Sicherheitseinstellungen in Abhängigkeit von der
Identität des ausführenden Benutzers oder der Herkunft des Programms vorzunehmen.
Die Sicherheitsüberprüfungen werden von der Common Language Runtime vorgenommen
und betreffen nur reine .NET-Anwendungen. So werden beispielsweise aus .NET-
Anwendungen aufgerufene COM-Funktionen ohne sicherheitsbasierte Einschränkungen
(abgesehen von den betriebssystemseitig vergebenen Benutzerrechten) ausgeführt.
Durch solche externe Aufrufe von Altmodulen (COM- oder DCOM-basiert) kann die CAS
umgangen werden, selbst wenn sie eingeschaltet ist. Insbesondere durch die Übernahme
von bewährten aber älteren Softwaremodulen auf COM- oder DCOM-Basis, wird
dadurch die CAS häufig umgangen. Aus diesen Gründen lehnen viele Entwickler die
CAS als prinzipiell hilfreich aber nicht praktikabel ab.
Von der CLR ausgeführte CIL-Programme werden als „Managed Components― bezeichnet,
weil sie von der CLR unter Einbeziehung der CAS kontrolliert ausgeführt werden.
Code, der nicht von der CLR, sondern direkt von der CPU ausgeführt wird, wird im
Gegensatz dazu als „Unmanaged Code― bezeichnet. Dies betrifft zum Beispiel aus .NET-
Anwendungen heraus aufgerufene COM-Funktionen. Der Begriff „Managed Code―
bezeichnet also die Ausführung von Code durch eine Virtual Machine beziehungsweise
das Management dieses Codes. Obwohl der Begriff „Managed Code― durch Microsoft
geprägt wurde, wird diese Technik zum Beispiel auch von Java eingesetzt. Auch hier
übernimmt eine Virtual Machine das Management des Codes.
Die konzeptionell gegebene Plattformunabhängigkeit der zugrundeliegenden Common
Language Infrastructure (CLI) und ihre Standardisierung durch Ecma International und
ISO haben dazu geführt, dass es mittlerweile zwei OpenSource-Projekte gibt, die .NET-
Funktionalitäten auch auf anderen Betriebssystemen zur Verfügung stellen 446 . Dabei
handelt es sich zum einen um das von Novell unterstützte Mono 447 und zum anderen um
das DotGNU Portable.NET 448 .
Bei Mono handelt es sich um eine Entwicklungs- und Laufzeitumgebung, die die Erstellung
und Ausführung von .NET-Anwendungen unter Linux, Solaris, Mac OS X, Windows
und Unix ermöglicht. Der Stand der .NET-Unterstützung von Mono in der aktuellen Version
1.2.4 liegt zwischen .NET 1.1 und .NET 2.0. Bis Ende 2007 soll die .NET-2.0-Unterstützung
vollständig sein.
446 Inwieweit diese technischen Möglichkeiten am Ende durch rechtliche Belange, wie Patente
oder Urheberrecht beschränkt werden, muss sich erst noch zeigen.
447 http://www.mono-project.com/Main_Page
448 http://www.dotgnu.org/pnet.html
Seite 474

Das erklärte Ziel von DotGNUs Portable.NET ist es, eine Sammlung freier Software-
Werkzeuge zur Compilierung und Ausführung von CLI-Anwendungen aufzubauen.
DotGNU Portable.NET konzentriert sich dabei auf die Kompatibilität mit den entsprechenden
Standards ECMA-334 449 (Programmiersprache C#) und ECMA-335 450 (CLI) als
auch auf Microsofts reale CLI-Implementation (.NET). Hierdurch soll erreicht werden,
dass zum einen Anwendungen, die unter Portable.NET entwickelt wurden, problemlos
unter Microsoft .NET laufen, und dass zum anderen auch viele Microsoft .NET-Anwendungen
gut unter Portable.NET und damit auch unter so verschiedenen Betriebssystemen
wie beispielsweise Linux, NetBSD, FreeBSD, Solaris und MacOS X funktionieren.
Zusammenfassend lässt sich festhalten, dass die .NET-Plattform es ermöglicht, Anwendungen
in verschiedensten Programmiersprachen zu entwickeln. Die jüngsten funktionalen
Ergänzungen stehen nur in Microsoft-Windows-Umgebungen zur Verfügung, da die
durch Microsoft erfolgenden Weiterentwicklungen immer erst nach deren Veröffentlichung
von den Open-Source-Plattformen nachvollzogen werden können. In der Regel
stehen alle Erweiterungen nach ihrer Veröffentlichung mit einiger zeitlicher Verzögerung
auch in den Open-Source-Plattformen zur Verfügung. Dabei ist zu beachten, dass proprietäre,
nicht standardisierte Erweiterungen von Microsoft gegebenenfalls aus lizenztechnischen
Gründen nicht in die Open-Source-Plattformen aufgenommen werden können.
1.2 SUN J2EE-Plattform
1999 teilte SUN seine bis dahin in einem einzigen Entwicklungskit gebündelten Java-
Klassenbibliotheken in drei Editionen auf:
� Java 2 Platform, Standard Edition (J2SE):
Diese Edition ist das Grundgerüst der Programmiersprache Java. Die Edition
ermöglicht die Entwicklungen von Java-Anwendungen primär für Clients und
bildet darüber hinaus die technische Grundlage für die Java 2 Platform, Enterprise
Edition (J2EE).
� Java 2 Platform, Enterprise Edition (J2EE):
Die Enterprise Edition erweitert die Standard Edition um eine ganze Reihe von
Funktionalitäten, die die serverseitige Implementierung von Anwendungen unterstützen.
Dazu zählen zum Beispiel Komponentenmodell, Kommunikations-
APIs und Management Funktionalitäten. Die Enterprise Edition wird von SUN für
die Entwicklung von serviceorientierten Architekturen empfohlen.
� Java 2 Platform, Micro Edition (J2ME):
Die Micro Edition schränkt hingegen die Standard Edition dergestalt ein, dass
eine Entwicklung von Java-Anwendungen für Geräte mit geringerer Hardware-
Leistungsfähigkeit (z. B. Mobiltelefone, PDAs u.Ä.) möglich wird.
SUN bietet für die in diesem Abschnitt näher betrachtete Enterprise Edition (J2EE) eine
Referenzimplementierung, die primär jedoch nicht für den praktischen Einsatz vorgesehen
ist. Unterschiedliche Hersteller (darunter auch SUN) bieten auf Basis dieser
449 http://www.ecma-international.org/publications/standards/Ecma-334.htm
450 http://www.ecma-international.org/publications/standards/Ecma-335.htm
Seite 475

Referenzimplementierung Applikationsserver an, die den J2EE Standard gemäß dieser
Referenzimplementierung umsetzen.
Aufgrund der inhärenten Unabhängigkeit der Java-Sprache und -Konzepte von der eingesetzten
Hardware-Betriebssystem-Kombination und ihrer freien Verfügbarkeit 451 hat
die J2EE-Plattform eine weite Verbreitung gefunden 452 .
In der aktuell verfügbaren Version 1.5 453 wurde die Java 2 Platform, Enterprise Edition
(J2EE) in Java Platform, Enterprise Edition (Java EE) umbenannt. Da sich der Name
J2EE eingebürgert hat und erst mit der neuesten Version geändert wurde, wird im Rahmen
dieses Leitfadens weiterhin die Bezeichnung J2EE verwendet.
Die Architektur von J2EE definiert ein Komponentenmodell (Beans), kapselt großkalibrige
Informationstechnik und Querschnittsdienste (Datenbanken, Transaktionen,
Verzeichnisse, Transaktionsmonitoren/Message Queueing, sonstige Legacy-EIS) in
Standardschnittstellen und verbindet beides - Komponenten und Schnittstellen – überwiegend
deklarativ im Laufzeitsystem. Maßgebliche Aufgabe der Implementationen ist,
Querschnittsdienste und Management-Werkzeuge bereit zu stellen. Außerdem definiert
J2EE ein rollenbasiertes Entwicklungsmodell.
Abbildung 73: Strukturelle Sicht - Mehrschichtenarchitektur 454
Die J2EE-Plattform enthält zur Entwicklung von serverbasierten Java-Anwendungen und
Web-Services zahlreiche Klassenbibliotheken, die Funktionalitäten und Dienste zur Entwicklung
verteilter und mehrschichtiger Java-Anwendungen bereitstellen. Die Konzepte
von J2EE bauen auf Architekturprinzipen auf, wie sie u.a. auch von SAGA gefordert
werden. Das heißt, es lassen sich SAGA konforme Mehrschichtarchitekturen realisieren.
Ein wichtiges Grundkonzept dafür sind Komponenten, die auf einem sogenannten Applikationsserver
(J2EE Application Server) ausgeführt werden.
451 http://java.sun.com/javaee/overview/faq/j2ee.jsp#free
452 http://www.java.com/en/javahistory/timeline.jsp hatten die Downloadzahlen des J2EE-
Softwareentwicklungskits bereits im Jahr 2002 die 2-Millionen-Grenze erreicht.
453 Stand Oktober 2007
454 SAGA 4.0
Seite 476

Der Applikationsserver bietet den Komponenten u.a. die folgenden grundlegenden
Dienste an:
� Sicherheitsmanagement
� Transaktionsmanagement
� Namens- und Verzeichnisdienste
� Kommunikation zwischen den Komponenten
� Lebenszyklusmanagement der Komponenten
� Bereitstellungsunterstützung (Deployment)
Ebenso wie eine auf Basis von J2SE entwickelte Anwendung stellt der J2EE Applikationsserver
den Komponenten eine Abstraktion der Ressourcen der zugrunde
liegenden Hardware-Betriebssystem-Kombination (Dateisystem, Netzwerk, …) zur
Verfügung. Damit wird die Entwicklung weitgehend plattformunabhängiger Anwendungen
ermöglicht. 455 Im Gegensatz zu J2SE bietet dieser Server weitergehende Unterstützung
für die Entwicklung serverseitiger Anwendungen, zum Beispiel im Bereich
Multiuserbetrieb, Lastenverteilung und Skalierung.
Die J2EE-Spezifikation definiert die folgenden Komponentenarten:
� Client-Anwendungen und Applets:
Diese Komponenten laufen auf dem Client-Rechner und dienen dem Zugriff auf
die serverseitigen Teile der jeweiligen Anwendung.
� Java Servlet, JavaServer Faces, und JavaServer Pages (JSP):
Hierbei handelt es sich um technische Komponenten, die auf dem Server ausgeführt
werden und zum Beispiel den Zugriff auf die Anwendung über einen Web-
Client (Browser, der serverseitig generierte Web-Seiten anzeigt) ermöglichen.
� Enterprise JavaBeans (EJB):
Die EJBs sind serverseitige Komponenten, welche die Anwendungslogik implementieren.
Sie dienen zur Vereinfachung der Entwicklung komplexer, mehrschichtiger
und verteilter Anwendungssysteme. Es gibt folgende Arten von EJBs:
o Entity Beans, welche die Modellierung von (persistenten) Daten ermöglichen.
o Session Beans, zur Umsetzung zustandsloser oder zustandsbehafteter Vorgänge,
wobei Session Beans seit der Version 1.4 auch als Web Service aufgerufen
werden können.
o Message Driven Beans für eine asynchrone Kommunikation zum Beispiel mit
Legacy-Anwendungen über den Java Message Service (JMS).
� Java Naming and Directory Interface (JNDI):
Hierbei handelt es sich um einen Namens- und Verzeichnisdienst, der zum einen
455 Leitfaden Plattformunabhängigkeit von Fachanwendungen,
http://www.kbst.bund.de/cln_012/nn_836802/SharedDocs/Anlagen-kbst/software_Leitfaden
___20Plattformunabhaengigkeit__von__Fachanwendungen,templateId=raw,property=publi
cationFile.pdf/software_Leitfaden_%20Plattformunabhaengigkeit_von_Fachanwendungen.pdf
Seite 477

die Möglichkeit bietet, Referenzen auf entfernte Objekte unter einem bestimmten
Namen und an einem definierten Platz zu hinterlegen (Binding). Zum anderen ist
es über JNDI möglich, gebundene Objekte über deren Namen wieder zu finden
(Lookup).
� Java IDL/Corba:
Java IDL bildet eine Schnittstelle zu CORBA. Mit Java IDL können Java-ORBs
implementiert werden.
� Remote Method Invocation (RMI) und RMI via IIOP (RMI-IIOP):
RMI wird für die verteilte Kommunikation zwischen Objekten eingesetzt. Mit RMI-
IIOP ist J2EE kompatibel mit CORBA.
Auch die J2EE-Plattform verfügt über Mechanismen für die Sicherheit von Anwendungen,
mittels derer Berechtigungen auch auf sehr detaillierten Ebenen in Abhängigkeit,
woher die auszuführende Anwendung stammt oder wer sie ausführt, vergeben werden
können. Beispielhaft sei an dieser Stelle auf JAAS (Java Authentication und Authorization
Service) verwiesen. Mit JAAS steht ein Framework zur Verfügung, mit dem sich
eine Benutzerauthentisierung für unterschiedlichste Arten von Anwendungen, inklusive
Standalone Anwendungen und Rich Clients, realisieren lassen. Häufig bietet J2EE die
Möglichkeit, je nach den individuellen Anforderungen unterschiedliche Lösungen einzusetzen.
Für die Authentisierung besteht neben JAAS zum Beispiel die Möglichkeit einer
formularbasierten oder einer HTTP basierten Authentisierung. Bei der formularbasierten
Authentisierung können, wie der Name sagt, beliebige HTML Formulare für eine Authentisierung
verwendet werden. Die HTTP basierte Authentisierung hingegen veranlasst
einen Webbrowser Username und Passwort über einen entsprechenden Dialog abzufragen.
Somit sind diese beiden Mechanismen im Gegensatz zu JAAS eher für Webanwendungen
gedacht.
Neben der Referenzimplementierung von SUN existieren zahlreiche weitere Applikationsserver-Lösungen.
Darunter finden sich Open-Source-Produkte wie
� GlassFish 456 ,
� JBoss Application Server 457 ,
� Apache Geronimo 458 und
� ObjectWeb JOnAS 459 ,
sowie proprietäre Produkte namhafter Hersteller wie zum Beispiel:
� BEA WebLogic Server 460 ,
� IBM WebSphere Application Server 461 ,
� SAP NetWeaver Application Server 462 und
456 https://glassfish.dev.java.net/
457 http://www.jboss.com/products/jbossas
458 http://geronimo.apache.org/
459 http://wiki.jonas.objectweb.org/xwiki/bin/view/Main/WebHome
460 http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/server/
461 http://www-306.ibm.com/software/webservers/appserv/was/features/
Seite 478

� Oracle Application Server. 463
Der genaue Umfang der J2EE-Unterstützung variiert zwischen den einzelnen Applikationsservern.
Einige der genannten Server sind von SUN J2EE zertifiziert, allerdings liegt
derzeit häufig nur eine Zertifizierung nach J2EE 1.4 vor. Einige Funktionalitäten von Java
EE 5 werden heute noch nicht unterstützt.
Anwendungen, die unter Verwendung der J2EE-Plattform entwickelt wurden, lassen sich
über diverse Schnittstellen mit anderen Systemen oder Anwendungen verbinden. Hierfür
existieren u.a. folgende Technologien:
� The Java Database Connectivity API (JDBC):
Über diese Programmierschnittstelle können relationale Datenbanken aus Java-
Programmen angesprochen werden.
� The Java Persistence API (JPA):
Auch wenn über JDBC der prinzipielle Zugriff auf relationale Datenbanken ermöglicht
wird, ist eine Speicherung von Objekten in einer relationalen Datenbank
nicht ohne weiteres möglich, da sich der Aufbau einer relationalen Datenbank
grundsätzlich von der Struktur der zu speichernden Java-Objekte unterscheidet.
Zur Speicherung der Objekte ist daher ein Object-Relationales-Mapping notwendig.
Die JPA stellt eine datenbankunabhängige Schnittstelle für ein solches Mapping
bereit.
� The J2EE Connector Architecture (JCA):
Diese Technologie ermöglicht die Anbindung existierender Altanwendungen (sogenannter
Enterprise Information Systems) an neuentwickelte Anwendungen
über eine standardisierte Architektur.
� The Java Transaction API (JTA):
Diese API definiert Schnittstellen, über die sich verteilte Transaktionsmanagementsysteme
an J2EE-Anwendungen anbinden lassen.
Im Resümee ist festzuhalten, dass die J2EE-Plattform eine etablierte Technologie bietet,
die sich in der Praxis vielfach bewährt hat. Auch komplexe Anwendungen lassen sich mit
J2EE realisieren. Viele Produkte und Technologien auch namhafter Hersteller basieren
heute auf der Java-Technologie. Neben den Implementierungen von SUN gibt es noch
weitere zahlreiche J2EE-Implementierungen unterschiedlicher Hersteller, sodass der
Kunde die Wahl zwischen einer Vielzahl von Produkten hat.
Bei der J2EE-Plattform stellt sich die Gesamtsituation jedoch anders dar als bei
Microsoft .NET. Während bei .NET der Einsatz unterschiedlicher Programmiersprachen
bereits im Konzept vorgesehen war, basierte die Idee von Java darauf, Anwendungen,
die mit einer Programmiersprache (Java) entwickelt wurden, auf unterschiedlichen
Betriebssystemplattformen laufen zu lassen. Mittlerweile hat SUN damit begonnen, die
Java-Technologie als OpenSource unter die GPLv2 zu stellen. Beispielsweise sind
große Teile von Java SE unter der GPLv2 verfügbar. Open Source Projekte wie zum
462 http://www.sap.com/germany/plattform/netweaver/components/appserver/index.epx
463 http://www.oracle.com/lang/de/appserver/index.html
Seite 479

Beispiel Apache Harmony arbeiten bereits daran, eine Open Source Version der Java-
Technologie zu entwickeln.
Zwar besteht auch bei Java theoretisch die Möglichkeit, Compiler zu entwickeln, die
neben Java weitere Programmiersprachen ermöglichen. Dieser Ansatz ist jedoch in der
Praxis vergleichsweise wenig verbreitet. Mit dem Aufkommen von Sprachen wie Ruby
könnte sich das in der Zukunft jedoch ändern. Beispielweise gibt es mit JRuby bereits
heute eine Möglichkeit, Java und Ruby gleichzeitig einzusetzen.
1.3 Object Management Group CORBA
Die Common Object Request Broker Architecture (CORBA) definiert auf einer sehr
hohen Abstraktionsebene, wie verteilte Objekte miteinander kommunizieren können.
Die CORBA-Spezifikation hat seit ihrer ersten Version 1991 kontinuierliche Verbesserungen
und Erweiterungen im Rahmen eines offenen Standardisierungsprozesses bei
der Object Management Group 464 erfahren. CORBA ist dadurch mittlerweile ein sehr
ausgereifter und umfassender Standard mit breiter Unterstützung.
Die verteilte Kommunikation im CORBA-Umfeld basiert auf dem Zugriff von Clients auf
Server-Objekte. Dazu wird zunächst die Schnittstelle zur vom serverseitigen Objekt angebotenen
Funktionalität mit einer formalen Beschreibungssprache (Interface Definition
Language - IDL) definiert. Für eine konkrete Programmiersprache wird dann diese Definition
in sogenannte Stubs (clientseitig) beziehungsweise Skeletons (serverseitig) überführt.
Die Stubs erlauben dem Client auf die entfernte Funktionalität fast so zuzugreifen, als
wäre diese lokal als Programmfunktion verfügbar. Die Skeletons werden vom Entwickler
des Server-Objekts entsprechend mit Funktionalität ausgefüllt.
Die konkrete Kommunikation zwischen beiden Seiten erfolgt über einen Object Request
Broker (ORB), der neben der Übermittlung von Funktionsaufrufen und Rückgabewerten
auch weitere Dienste, zum Beispiel zum Auffinden eines Server-Objekts mit einer
bestimmten Funktionalität bereitstellt.
Mit CORBA 2.1 wurden im Jahr 1997 wichtige Sicherheitsfunktionen wie zum Beispiel
die SSL Verschlüsselung für IIOP in CORBA aufgenommen. Inzwischen existiert eine
ständig weiterentwickelte Spezifikation eines Dienstes 465 (Secure Service Specification),
der umfangreiche Möglichkeiten zur Umsetzung von Sicherheitsanforderungen, wie zum
Beispiel Identifikation von Nutzern und Objekten, Zugriffskontrolle, Vertraulichkeit und
Integrität, in CORBA-Umgebungen bereitstellt.
Es existieren zahlreiche CORBA-konforme ORB-Implementierungen, darunter sowohl
Open-Source-Produkte wie zum Beispiel
� MICO 466 ,
� ORBit 467 ,
464 http://www.omg.org/technology/documents/formal/corba_iiop.htm
465 Natürlich existieren auch Implementierungen dieses Dienstes, sogar bei einigen der OSS-
Produkte (zum Beispiel bei MICO und TAO).
466 http://www.mico.org/
Seite 480

� omniORB 468 ,
� JacORB 469 und
� TAO 470 ,
als auch proprietäre Lösungen wie
� IONA Orbix 471 und
� Borland Visibroker 472 .
Client- und serverseitig wird die CORBA-Funktionalität über sogenannte Language Mappings
473 zwischen der IDL und der jeweiligen Programmiersprache verfügbar gemacht.
Eine Übersicht der von der OMG spezifizierten Mappings ist Internet verfügbar 474 .
Zu den unterstützten Programmiersprachen zählen Ada, C, C++, COBOL, Java 475 , Lisp,
PL/I, Python und Smalltalk. Für Modellierungsaufgaben existieren darüber hinaus auch
noch Mappings für XML und MOF 476 .
Zusammenfassend ist CORBA eine in der allgemeinen Wahrnehmung unterschätzte
Technologie. Beispielsweise ist es mit CORBA möglich, eine serviceorientierte Architektur
(SOA) aufzubauen. Der zugrunde liegende Standard ist ausgereift und es existieren
zahlreiche OSS-Implementationen. Frühere Performance-Probleme sind inzwischen
behoben. Dennoch spielt CORBA in der aktuellen Diskussion um WebServices und SOA
kaum eine Rolle und wird häufig nur noch als eine theoretische Möglichkeit betrachtet,
die in der Praxis immer weniger Bedeutung hat. Für Migrationszwecke muss daher sehr
genau abgewogen werden, ob und wozu die ORB-Konzepte von CORBA verwendet
werden. Wann immer möglich, sollten statt CORBA die Standard-Backend-
Technologien, insbesondere unter J2EE, zur Umsetzung verwendet werden. Wo das
nicht ausreicht, sind Schnittstellen zu CORBA vorhanden.
2 Migrationspfade
2.1 Migration einer Anwendung auf Basis .NET nach J2EE
Die Migration einer Anwendung von einer Programmierplattform auf eine andere kann
nicht voll automatisiert erfolgen. Es ist davon auszugehen, dass große Teile des Codes
neu geschrieben werden müssen. Zwar verfügen Java und .Net Sprachen über ähnliche
467 http://orbit-resource.sourceforge.net/
468 http://omniorb.sourceforge.net/
469 http://www.jacorb.org/features.html
470 http://www.cs.wustl.edu/~schmidt/TAO.html
471 http://www.iona.com/products/orbix/
472 http://www.borland.com/de/products/visibroker/index.html
473 Mappings sind Transformationsregeln, anhand derer IDL-Konstrukte in entsprechende
Konstrukte der verwendeten Programmiersprache überführt werden.
474 http://www.omg.org/technology/documents/idl2x_spec_catalog.htm.
475 Im Falle von Java existiert sowohl ein Mapping, das IDL-Konstrukte nach Java überführt,
als auch ein Mapping, mit dem aus Java-Konstrukten IDL-Konstrukte erzeugt werden können.
476 MOF: Meta Object Facility, ein OMG-Standard zur plattformunabhängigen Definition, Manipulation
und Integration von Daten und Metadaten.
Seite 481

Konzepte und die Syntax von zum Beispiel C# ist im Vergleich zu Java nahezu identisch,
aber im Kern verfolgen sie unterschiedliche Ziele. Die Hauptproblematik liegt in den
unterschiedlichen Systembibliotheken. Der Umfang und Aufbau dieser Bibliotheken
unterscheidet sich deutlich. Folgende Betrachtungen helfen bei der Analyse der Möglichkeiten
und des Aufwands im Zuge einer Migration.
2.1.1 Betrachtung der einzelnen Anwendungsschichten bei der Migration
Bei einer Migration ist es sinnvoll, die Anwendung nicht als einen monolithischen Block
zu betrachten, sondern in logische Schichten zu unterteilen. Bei der Entwicklung einer
Software wird normalerweise eine Unterteilung in folgende Schichten vorgenommen:
� Präsentationsschicht
Diese Schicht sollte im Idealfall keine eigene Logik beinhalten und nur die Möglichkeit
zur Interaktion des Systems mit dem Benutzer bieten.
� Kommunikationsschicht
Falls eine Anwendung auf mehrere Rechner verteilt ist, um zum Beispiel Daten
von einem externen Rechnungssystem abzuholen, wird die Kommunikationslogik
in dieser Schicht umgesetzt.
� Geschäftslogik-Schicht
Hier werden die Geschäftsprozesse einer Anwendung abgebildet, zum Beispiel
ein Workflow zur Erfassung von Daten.
� Datenzugriffsschicht
In dieser Schicht erfolgt der Zugriff auf die Datenquellen.
Je nach Schicht werden unterschiedliche Technologien eingesetzt. Diese müssen bei
der Migration einzeln betrachtet werden. So muss zum Beispiel die Migration von ASP
Seiten (.Net) auf JSP Seiten (J2EE) in der Präsentationsschicht komplett anders gehandhabt
werden als die Migration von ADO.Net Komponenten auf JDBC in der Datenzugriffsschicht.
Desweiteren muss bei der Analyse der zu migrierenden Anwendung auf eingesetzte
Frameworks geachtet werden. In der .Net und Java Welt existieren zahlreiche Frameworks,
die bei der Entwicklung komplexer Anwendungen unterstützen. Im Idealfall gibt
es sowohl eine Java als auch eine .Net Version eines Frameworks. Damit wird die Migration
deutlich erleichtert. Falls ein Framework nur auf einer Plattform verfügbar ist, wird
die Migration deutlich aufwändiger, da gegebenenfalls vollständig unterschiedliche Konzepte
und Philosophien zu berücksichtigen sind.
2.1.1.1 Präsentationsschicht
Je nach Art der Anwendung werden hier unterschiedliche Technologien bei der Implementierung
eingesetzt:
� Standalone Anwendungen – diese werden auf dem Rechner des Benutzers installiert
und ausgeführt. In der .Net Welt werden diese Anwendungen mit Hilfe
der Windows Forms Technologie implementiert. In der Java Welt sind es die
SWING/AWT Oberflächen. Zusätzlich können diverse Frameworks eingesetzt
Seite 482

werden, zum Beispiel SWT 477 (Open Source Komponente des Eclipse Projektes).
Durch den unterschiedlichen Umfang und den Aufbau der Komponenten kann
hier keine automatisierte Migration der Komponenten durchgeführt werden. Es
gibt jedoch Ansätze, um den Entwicklern die Migration zu erleichtern. Als Beispiel
sei an dieser Stelle das Eclipse Modelling Framework (EMF 478 ) erwähnt. Das
Framework kann aus einem strukturierten Modell Java Code erzeugen. Im Fall
einer Windows Forms Oberfläche kann anhand der XML-Beschreibung der Oberflächenelemente
und eines Code Generators das Grundgerüst für die
SWING/AWT Elemente generiert werden. Dieses Vorgehen beschleunigt die
Migration deutlich, da die Entwickler anhand des Grundgerüsts die fehlenden
Code Teile nur ergänzen und nicht komplett neu entwickeln müssen.
� Web Anwendungen – diese laufen auf dem Server ab. Der Benutzer erhält den
Zugriff auf die Oberfläche über einen Web Browser. In der .Net Welt sind diese
normalerweise als ASP(.NET) Seiten implementiert. In der Java Welt gibt es
hingegen unterschiedliche Standards wie zum Beispiel die JavaServer Pages
(JSP) oder auch die in letzter Zeit immer wichtiger gewordenen JavaServer
Faces (JSF). Falls die Web Seiten als einfache Formulare ausgeführt sind, ist die
Migration relativ einfach. In diesem Fall kann das bereits erwähnte EMF
Framework eingesetzt oder mit Hilfe von einfachen Parsern wie Xerces
gearbeitet werden. Rich Clients wie zum Beispiel Java-Applets werden in diesem
Kontext nicht als Webanwendungen verstanden, da sie unter Migrationsgesichtspunkten
mit Standalone Anwendungen vergleichbar sind.
2.1.1.2 Kommunikationsschicht
Die Kommunikation zwischen Teilen einer Anwendung, die auf mehrere Rechner verteilt
ist, läuft für gewöhnlich über Standardprotokolle und Technologien wie TCP/IP oder
SOAP ab. In diesem Fall bereitet die Migration keine großen Probleme, da auf beiden
Plattformen die gängigen Kommunikationsstandards zur Verfügung stehen. Bei der
Kommunikation über Web Services kann im Rahmen der Migration anhand einer WSDL
(Web Service Beschreibung) das Grundgerüst sowohl in .Net als auch in J2EE generiert
werden. Probleme sind jedoch dann zu erwarten, wenn höhere Anforderungen, zum
Beispiel im Bereich Sicherheit, gestellt werden und daher unterschiedliche Web Service
Standards wie zum Beispiel OASIS WS-Security zum Einsatz kommen. Die Vielzahl
unterschiedlicher Web Service Standards sowie Unterschiede bei der Unterstützung der
Standards in den unterschiedlichen Tools und Frameworks bedingen diese Probleme.
Eine Migration zwischen unterschiedlichen Sicherheitsstandards kann dadurch vom
Aufwand mit einer Neuentwicklung vergleichbar sein.
2.1.1.3 Geschäftslogik-Schicht
Bei einfachen, auf einem einzigen Server laufenden Anwendungen besteht die Geschäftslogik
zumeist aus normalen Klassen sowohl in C# als auch in Java. Hier sollte die
Migration keine großen Probleme bereiten. Die Syntax zwischen diesen beiden Sprachen
ist ähnlich und für die Konvertierung gibt es entsprechende Tools. Für den Weg
477 SWT – Standard Widget Toolkit - http://www.eclipse.org/swt
478 EMF – Eclipse Modelling Framework - http://www.eclipse.org/emf
Seite 483

von .Net zur Java kann zum Beispiel das Open Source Projekt net2java 479 und für die
Migration von Java zu .Net der JLCA 480 (Java Language Conversion Assistant) von
Microsoft genutzt werden. Insbesondere JLCA ist inzwischen ein ausgereiftes Tool mit
umfangreicher Unterstützung von Microsoft, mit dem in der Regel ein Großteil des
Codes automatisiert konvertiert werden kann.
Komplizierter wird es bei Enterprise Anwendungen wie sie zum Beispiel über COM+ in
der .Net Welt und über EJBs in der J2EE Welt realisiert werden. Hier müssen die Entwickler
die Logik genau betrachten und den entsprechenden Code in der Zielsprache
neu schreiben. In der Regel ist jedoch die Migration von COM+ zu EJB problemloser als
die umgekehrte Migration, da der Funktionsumfang von COM+ eine Teilmenge der EJB
Funktionen bildet. Die Migration von EJB zu COM+ ist insbesondere dann deutlich
komplexer, wenn Funktionen verwendet werden, die in COM+ Technologie nicht enthalten
sind.
2.1.1.4 Datenzugriffsschicht
Bei der Migration der Datenzugriffsschicht werden zwei unterschiedliche Teile einer Anwendung
migriert: der Programmcode und die SQL Statements. Die Migration des Programmcodes
läuft ähnlich wie die Migration des Codes in der Logikschicht mit Hilfe von
entsprechenden Tools ab. Hier gibt es zwar Unterschiede bei den Zugriffen zwischen
ADO.NET und JDBC, diese sind jedoch nicht gravierend und bereiten in der Regel keine
größeren Schwierigkeiten. Die SQL-Abfragen bleiben unberührt, solange auf die gleiche
Datenbank zugegriffen wird. Falls auch die Datenbank migriert wird, müssen in jedem
Fall die SQL-Statements entsprechend der Syntaxunterschiede angepasst werden. Darüber
hinaus können weitere Aktivitäten notwendig sein (siehe Kapitel II.A).
Beim Einsatz von Persistenzframeworks, wie Hibernate, ist der Aufwand bei der Migration
entweder gering, falls es eine entsprechende Version dieses Frameworks auf der
anderen Plattform gibt, oder sehr hoch, falls es keine entsprechende Version gibt und
die Datenzugriffsschicht dadurch komplett neu entwickelt werden muss.
2.1.2 Migration einer verteilten Anwendung auf SOA Basis
Basiert die Anwendungslandschaft auf einer SOA Architektur, kann dies die Migration
zwischen den einzelnen Plattformen deutlich erleichtern. Falls die Anwendungen, wie für
eine SOA Archtitektur typisch, über Web Services implementiert sind, kann die Migration
in vielen kleinen Schritten erfolgen. So kann zum Beispiel ein einzelner .Net Web
Service durch einen J2EE Web Service ersetzt werden, ohne dass Änderungen in
anderen Anwendungen notwendig sind und diese entsprechend unbeeinflusst bleiben.
Die Anwendungsmodule können so nach und nach schrittweise ersetzt werden. Dadurch
erhöht sich zwar die Gesamtzahl der Migrationsprojekte, die Komplexität der einzelnen
Projekte wird jedoch deutlich reduziert. Außerdem wird das Migrationsrisiko minimiert,
indem zunächst Erfahrungen mit dem Betrieb einzelner, möglichst unkritischer Services
auf Basis der neuen Plattform gesammelt werden und diese Erfahrungen in die weiteren
479 siehe https://net2java.dev.java.net/
480 JLCA – Java Language Conversion Assistant -
http://msdn.microsoft.com/vstudio/java/migrate/jlca/default.aspx
Seite 484

Migrationsprojekte einfließen können. Auch wenn die Komplexität der Einzelprojekte
sinkt, gelten trotzdem alle in diesem Leitfaden beschriebenen Aspekte und Risiken.
Daher müssen auch diese Projekte als Migrationsprojekte Ernst genommen und entsprechend
geplant werden. Zu beachten ist außerdem, dass über einen bestimmten
Zeitraum sowohl Plattformen auf Java als auch auf .Net-Basis parallel betrieben werden
müssen, wodurch sich gegebenenfalls die Betriebsaufwände erhöhen.
2.1.2.1 Bridge Technologien
Unter Umständen ist es notwendig, dass Java und .Net Technologien zusammen
arbeiten müssen. Dies wäre zum Beispiel bei einer großen Anwendung der Fall, die nicht
in einem Zug durch die neue Technologie ersetzt werden kann. Hier müssen zum
Beispiel .Net Module Java Module entweder auf demselben System oder über das
Netzwerk aufrufen. Eine Möglichkeit besteht zum Beispiel darin, eine Art Proxy mit Web
Services zu realisieren. Ein .Net Programm Modul kann dann über diesen Proxy Daten
mit Java Modulen austauschen. Diesem Vorgehen stehen jedoch die relativ umständliche
Programmierung der Proxies sowie die Performanceeinbußen durch das
Arbeiten mit XML und das Übertragen der Daten zwischen den Web Services entgegen.
Um diese Nachteile zu umgehen, wird die sogenannte Bridge Technologie eingesetzt.
Mittels dieser ist es möglich, auf .Net Klassen von Java Klassen aus so zuzugreifen, als
ob diese Java Klassen wären und umgekehrt. Auch hierbei kommen Proxies zum Einsatz,
die jedoch automatisiert durch entsprechende Tools generiert werden. Damit entfällt
die aufwändige Programmierung der Proxies. Außerdem werden Performanceverluste
verringert, da neben Web Services auch weitere performanceoptimierte
Kommunikationskanäle wie zum Beispiel TCP/Binary von den Produkten angeboten
werden. Ein Produkt, das erfolgreich in der Praxis eingesetzt wird, ist JNBridge 481 von
JNBridge LLC.
2.1.2.2 .Net Anwendungen auf nicht Windows basierten Betriebssystemen
Als Alternative zu einer vollständigen Migration von .Net zu J2EE gibt es Möglichkeiten,
.Net Anwendungen auch auf nicht Windows Betriebssystemen laufen zu lassen und damit
eine Migration der Betriebssysteme relativ unabhängig von der Migration der Anwendungen
zu ermöglichen. Dadurch kann zum Beispiel eine Migration nach Linux erfolgen,
ohne dass eine bestehende .Net Anwendung gleichzeitig migriert werden muss.
Das Mono Open Source Projekt unter der Führung von Novell bietet eine Anzahl von
Modulen wie C# Compiler und die Common Language Runtime, die es ermöglichen,
.Net Anwendungen auf Linux, BSD, Unix, Mac OS X oder Solaris Betriebssystemen zu
betreiben. Mono bildet die Funktionalität des aktuellen .NET-Frameworks jedoch z.Zt.
nicht vollständig ab. Aufgrund der Dynamik in der Weiterentwicklung von .NET ist mit
diesem Sachverhalt in der Zukunft weiterhin zu rechnen. Insofern muss im Einzelfall genau
geprüft werden, ob Mono als vorübergehende Migrationsalternative auf Anwendungsebene
geeignet ist.
Eine weitere Möglichkeit bietet der Cross Compiler von Mainsoft. Dieser ermöglicht es,
.Net Code direkt in Java Bytecode zu kompilieren und auf einem J2EE Application
481 JNBridge – Ein Produkt der JNBridge LLC - http://www.jnbridge.com/
Seite 485

Server laufen zu lassen. Zusätzlich existiert ein Modul für Visual Studio, das die
Entwicklung von .Net Anwendungen für Windows fremde Betriebssysteme deutlich
erleichtert. Dieses Produkt ist insofern interessant, als es den Entwicklern weiterhin
erlaubt, mit Visual Studio in .Net zu entwickeln, aber die Ergebnisse direkt als J2EE
Anwendung auf einem J2EE Applikationsserver zu deployen und zu betreiben.
2.1.3 Fazit
Zusammenfassend lässt sich sagen, dass eine Migration zwischen J2EE und .Net in
jedem Fall aufwändig ist. Es lässt sich jedoch keine grundsätzliche Aussage darüber
treffen, ob eine Migration oder eine vollständige Neuentwicklung sinnvoller ist. Je nach
Komplexität der Anwendung und der verwendeten Technologien muss diese Entscheidung
situationsbezogen auf Basis einer entsprechenden Analyse getroffen werden. Keinesfalls
ist jedoch eine automatisierte Migration möglich. Zwar gibt es Vorgehen und
Tools, die die Migration erleichtern, dennoch ist in jedem Fall mit großem manuellem
Aufwand zu rechnen.
In diesem Kapitel wurden auch alternative Wege zu einer vollständigen Migration aufgezeigt.
Hierzu gehören die schrittweise Migration mit Hilfe von Bridge Technologien und
Web Services und das Betreiben von .Net Anwendungen auf nicht Windows basierten
Betriebssystemen. Diese zwei Ansätze ermöglichen es, die Anwendungen nach und
nach zu migrieren und so den Umstellungsaufwand auf einen größeren Zeitraum zu verteilen
und gleichzeitig die Komplexität der einzelnen Migrationsprojekte zu reduzieren.
Seite 486

E Thema Terminal-Dienste und Client-Konzepte
Die Entscheidung für den Einsatz von Terminalservern und Thin Clients kann sowohl
während eines Migrationsprojekts als auch im Vorfeld erfolgen und soll daher auch in
diesem Rahmen betrachtet werden. Es ist jedoch kein klassisches Migrationsthema, da
in der Regel keine Terminalserverumgebungen migriert werden. Bei der Umsetzung und
Unterstützung von Migrationen können Terminalserver hingegen sehr hilfreich sein. Dies
ist zum Beispiel dann der Fall, wenn es im Rahmen einer stufenweisen Migration darum
geht, Fachanwendung sukzessive für eine neue Betriebssystemumgebung bereitzustellen,
wobei die sonstige Server-Landschaft schon umgestellt wurde.
Der Einsatz der im Folgenden betrachteten Technologie ist primär eine Entscheidung,
die im Rahmen der Gesamt-IT-Strategie einer Behörde zu treffen ist. Die vorgestellten
Lösungen sollen einen Einblick in die gesamte Thematik geben und das Potential der
Technologie verdeutlichen.
Vorgestellt werden Technologien, die in den unterschiedlichsten Bereichen eingesetzt
werden können:
� Linux basierte Server- und Clientsysteme mit dem Linux-Terminal-Server-Project
� NX-Server der Firma NoMachine mit Linux basierten Serversystemen und Clientsystemen
für Windows und Linux
� Windows Terminalserver der Firma Microsoft mit (vorrangig) Windows basierten
Clientsystemen
� Presentation Server der Firma Citrix mit Windows basierten Serversystemen und
diversen Clientsystemen (Linux, Unix, DOS, Windows usw.)
Die vorgestellten Systeme bieten eine große Bandbreite an technischen Lösungen und
sind im Einzelfall gemäß den vorliegenden Anforderungen genauer zu betrachten. Neben
den technischen Unterschieden und Möglichkeiten variieren die Systeme auch stark
im Hinblick auf die Lizenzierungsmodelle und -kosten.
Die Administration und Betreuung von Arbeitsplatzrechnern ist eine Aufgabe mit hohem
Personalaufwand, insbesondere dann, wenn die Ausstattung der Rechner mit unterschiedlicher
Hard- und Software erfolgte. Auch die wachsende Komplexität der eingesetzten
Hard- und Software kann die Arbeitsplatzrechner störanfälliger machen und damit
die administrativen Aufwände erhöhen. Die mit der Systembetreuung verbunden Arbeiten
werden im Folgenden exemplarisch aufgeführt:
� Installation, gegebenenfalls Konfiguration vor Ort
� Anpassungen an individuelle Bedürfnisse
� Verwaltung von Softwareaktualisierungen und -neuinstallationen (Test, Verteilung,
Installation)
� Fehlerdiagnose und -behebung, Support
� Ersatzbeschaffung.
Seite 487

Zwar können die Aufgaben mit Unterstützung geeigneter Verwaltungswerkzeuge beziehungsweise
System-Managementanwendungen größtenteils automatisiert und die Aufwände
verringert werden, insgesamt bleibt der Arbeitsaufwand jedoch sehr hoch. Hinzu
kommt, dass nicht jede Organisation in der Lage ist, sich mit der zum Teil sehr kostspieligen
Systemmanagementsoftware auszustatten und das hierfür benötigte Personal zu
beschaffen oder entsprechend zu schulen. Dies gilt insbesondere für kleinere Organisationen.
Durch den Einsatz von Terminalservern können die skizzierten Probleme reduziert
werden.
In einer dezentralen IT-Architektur findet die Installation und Ausführung von Programmen
in der Regel auf den Arbeitsplatzrechnern statt. Server dienen primär zur zentralen
Datenverwaltung, zu Datenbackups und zur Steuerung der Zugriffsrechte. Bei der Verwendung
einer Terminalserverlösung liefern ein oder mehrere leistungsfähige Zentralrechner,
die eigentlichen Terminalserver, einen standortunabhängigen Zugriff auf die
notwendigen Daten und Anwendungen. Die Terminalserver bieten den Benutzern dabei
einen direkten Zugang mittels einer grafischen Benutzerschnittstelle des Betriebssystems
über das Netzwerk. Terminaldienste ermöglichen den Anwendern die Nutzung von
Software, die nicht auf ihrem lokalen Rechner installiert sind. Die Anwendungen werden
von einem Terminalserver bereitgestellt und über einen Client/Terminal in Anspruch genommen.
Ein Terminalserver emuliert dabei in der Regel mehrere Clients (Sessions).
Das heißt, er stellt den meist entfernten Clients Anwendungen zur Verfügung, für die der
Benutzer eine Berechtigung hat. Diese Anwendungen können von dem Benutzer wie an
einem normalen PC per Maus und Tastatur bedient werden können.
Im Gegensatz zu dezentralen IT-Architekturen erfolgt auf den zentralen Servern neben
der Bereitstellung der Daten auch die der Anwendungen. Der Zugriff auf die Anwendungen
und Daten der Terminalserver muss mittels spezieller Terminal-Clientanwendungen
erfolgen.
Die folgende Tabelle gibt einen kurzen Überblick über die Vorteile, die durch den Einsatz
von Terminalservern entstehen.
Vorteile Erläuterung
Zentrale Verwaltung Betriebssystem und Anwendungen werden nur in einfacher Form
zentral auf den Terminalservern angeboten.
Die Pflege der Software kann zentral erfolgen (Updates).
Es sind selten Arbeiten an den Client-Systemen notwendig.
Die Betreuung der Anwendungen findet zentral statt, Fehlerdiagnose
und -behebung werden vereinfacht.
Erhöhung der Produktivität für Anwender und Administration.
Die Bereitstellung zusätzlicher Anwendungen (die bereits auf dem
Terminalserver eingerichtet sind) für den Benutzer wird beschleunigt.
Durch den Wegfall personalintensiver Fehlerbehebungen vor Ort
werden die administrativen Aufwände drastisch reduziert.
Zudem ist sichergestellt, dass alle Anwender mit konsistenten Applikationen
arbeiten.
Verringerte Hardware- Clientsysteme benötigen weniger Hardwareressourcen (gegebenen-
Seite 488

Vorteile Erläuterung
anforderungen falls kann sogar auf eine eigene Festplatte im Client verzichtet werden),
da bei Bedarf fast alle Operationen auf dem Server stattfinden
können.
Ein regelmäßiger Ausbau / Austausch der Clienthardware aufgrund
erhöhter Anforderungen der Betriebssysteme und Anwendungen ist
nicht mehr notwendig.
Die vorhandene Hardware kann länger genutzt werden, da die Anforderungen
an die Leistungsfähigkeit nicht von Softwarewechsel
bestimmt werden.
Erhöhte Sicherheit Durch den Einsatz von Clientrechnern (zum Beispiel ohne Festplatten)
können Daten beispielsweise nur noch auf den zentralen
Servern gespeichert werden. Somit ist die Gefahr des Datenverlusts,
des unbefugten Zugriffs, der Manipulation oder des Diebstahls verringert.
Unabhängigkeit vom
Clientrechner
Flexible Unterstützung
bei Migrationen
Geringerer Energieverbrauch
Clientrechner können schnell ausgetauscht werden, da keine persönlichen
Daten oder Einstellungen auf den Clients gespeichert
werden. Vor allem aber können Benutzer einfach den Arbeitsplatz
wechseln, ohne auf „ihre― vertraute Umgebung verzichten zu müssen.
Der Einsatz von Terminalservern kann Migrationsprojekte entscheidend
unterstützen, da diese beispielsweise eine schrittweise Migration
ermöglichen.
So können bei einem Wechsel der Clientbetriebssysteme auf ein
Linux basiertes System die vertrauten Windowsanwendungen über
einen Terminalserver solange bereitgestellt werden, bis die Benutzer
in die neue Linux-Anwendung eingewiesen wurden.
Über Terminalserver können auch kostspielige Portierungen oder
sogar Neuentwicklungen notwendiger Anwendungen vermieden
werden. Einmal für den Einsatz auf einem entsprechenden Terminalserver
vorbereitet, sind diese auch unter dem neuen Betriebssystem
anwendbar.
Durch den Einsatz eines oder weniger leistungsfähiger Server und
vieler Clientrechner mit einfacher Hardwareausstattung und niedrigem
Energieverbrauch sinkt der gesamte Energieverbrauch. Nach
Angaben von IBM verbraucht ein Großrechner bei gleicher Leistung
nur max. 10% der Energie einer dezentralen IT-Architektur. 482
Tabelle 75: Vorteile von Terminal-Servern und Thin Clients
Neben den genannten Vorteilen gibt es auch einige Nachteile, die bei der Überlegung für
oder gegen den Einsatz von Terminalservern abgewogen werden müssen.
482 http://www.computerwoche.de/index.cfm?pid=858&pk=556868;
http://www.heise.de/newsticker/meldung/97276
Seite 489

Nachteile Erläuterung
Abhängigkeit Benutzersitzungen werden bei Ausfall der Terminalserver abgebrochen
und die Arbeitsaufnahme ist erst dann wieder möglich, wenn
der Fehler auf dem Terminalserver behoben ist. Zudem kann es
beim Abbruch der Benutzersitzung zu Datenverlusten kommen. Dieses
Risiko kann durch den Einsatz einer Serverfarm (Cluster) minimiert
werden.
Erhöhter Ressourcenbedarf
beim Terminalserver
Spezielle Maßnahmen für
mobile Endgeräte
Die Terminalserver müssen über eine deutlich erhöhte Ressourcenausstattung
verfügen, insbesondere beim Arbeitsspeicher. In Relation
zum Gesamtbedarf (Server und Clients) werden jedoch weniger
Ressourcen benötigt, da bestimmte Operationen auf einem Server
nur einmal für alle Benutzer ausgeführt werden müssen und nicht
auf jedem Client einzeln.
Die Einbindung von zum Beispiel Notebooks, die keinen permanenten
Netzzugang haben, erfordert zusätzliche Maßnahmen, zum Beispiel
den Offline Modus des Application Streamings von Citrix. 483
Erhöhter Netzwerkverkehr Die Kommunikation zwischen den Server- und Clientsystemen erfolgt
auf der Netzwerkebene. Übertragen werden die Inhalts-
Differenzen beim Bildaufbau oder Anweisungen für den Bildaufbau.
Bestimmte Anwendungen (zum Beispiel Grafikprogramme) können
die Netzlast stark erhöhen. Andererseits kann sich bei einigen Applikationen
(zum Beispiel Textverarbeitung) der Netzverkehr auch reduzieren,
da nicht regelmäßig ganze Dateien beim Speichern auf
den zentralen Datenserver übertragen werden, sondern nur die Änderungen
(Tastatureingaben und Bildschirmveränderungen).
Anpassungen bzgl. verwendeter
Anwendungen
Nicht alle Anwendungen können problemlos auf einem Terminalserver
betrieben werden, insbesondere im Windowsbereich kann es
Applikationen geben, die Systemdateien zum Schreiben öffnen und
für andere Benutzer sperren. Solche Probleme können in der Regel
durch administrative Eingriffe, zum Beispiel eine geänderte Rechtevergabe,
gelöst werden.
Tabelle 76: Ausgewählte Nachteile von Terminal-Servern und Thin Clients
Für die Anbindung an die Terminal-Server können verschiedene Clienttypen eingesetzt
werden.
� Fat Clients
Es handelt sich dabei um einen vollwertigen Arbeitplatzrechner. Der Zugriff auf
die Terminal-Server erfolgt über eine spezielle Terminalserver-Client-Software.
� Thin Clients
Hierbei handelt es sich um Rechnersysteme mit minimalen Hardware-
Ausstattungen. Das Betriebsystem bezieht die Clients entweder aus einem
Flash-EPROM oder sie können mittels Netzwerk (pxe, tftp, nfs) gebootet werden
483 http://www.citrix.de/produkte/schnellsuche/presentation-server/Application-Streaming/
Seite 490

1 Produkte / Technologien
1.1 Linux Terminal Server Project
Das Linux Terminal Server Project (LTSP) 484 ist eine Software für Linux, die den Einsatz
von Linux als Terminalserver ermöglicht.
Die Software ist vielfach in Schulen und Bildungseinrichtungen sowie in Entwicklungs-
und Schwellenländern verbreitet, da sie insbesondere die weitere Verwendung älterer,
leistungsschwacher Arbeitsplatzrechner ermöglicht. 2006 ist LTSP in der Version 4.2
erschienen. LTSP ist eine freie Software, die unter der GNU General Public License verfügbar
ist.
Technisch gesehen vereinfacht LTSP die Ausnutzung der Fähigkeiten des grafischen X-
Servers, ein beliebiges Linux-Programm in zwei Teile, Programmausführung und Anzeige,
zu trennen. Die Programmausführung erfolgt auf einem Server, während die Anzeige
zusammen mit der Eingabe über Tastatur oder Maus auf beliebig vielen Terminals erfolgen
kann. Die Anzahl der Thin Clients wird hierbei von der Übertragungsrate des Netzwerkes
und der Leistungsfähigkeit des Servers bestimmt.
Die Hardwareanforderungen an den Server sind als sehr gering zu bezeichnen. Es ist
durchaus nicht ungewöhnlich, 50 Workstations mit Mozilla und OpenOffice über einen
DUAL P4 -2,4 (XEON) mit 4 GB RAM zu betreiben.
Im Gegensatz zu den geringen Hardwareanforderungen werden hohe Anforderungen an
das Netzwerk (Bandbreite und Latenz) gestellt. Allein die Verwendung des X-Protokolls
hat zum Beispiel zur Folge, dass ein 100-MBit/s-Netzwerk nur für die Bereitstellung von
ca. 30 Sessions mit zum Beispiel Office-Anwendungen ausreicht.
Die Software besteht aus einer Serveranwendung, von der Clients via Netboot remote
booten und ihr Betriebssystem erhalten können. Die Anwendungen laufen in dieser Konfiguration
komplett auf dem Terminalserver und können im Prinzip auf eine eigene Festplatte
verzichten.
Der ohnehin schon niedrige Speicherverbrauch der Clients wurde in der aktuellen Version
nochmals verringert, sodass die Anforderungen an den Client-Rechner als sehr
gering zu bezeichnen sind. Die Minimalanforderungen sind ein Rechner mit 32 MB RAM
und einem PCI-Bus. Zudem wurde die Hotplug-Fähigkeit der Clients verbessert. Es können
auch lokale Scanner oder USB-Sticks verwendet werden. Die Unterstützung von
Multihead-X ermöglicht zudem den Einsatz mehrerer Monitore.
Als Serversystem dient eine beliebige Linux-Distribution. Hierdurch werden u.a. auch
Verfahren zur Authentisierung an einem Active Directory, das auf einem Windows Server
läuft, unterstützt, und der Zugriff auf Ressourcen eines Windows Netzes wird dadurch
ermöglicht.
484 http://www.ltsp.org/ (Stand 01.11.2007)
Seite 491

LTSP-Client unterstützt sowohl den Zugriff auf LTSP als auch auf Windows-
Terminalserveranwendungen. Neben der Variante, bei der der Server dem Client das
Betriebssystem zur Verfügung stellt, werden clientseitig auch eine Vielzahl von Hardwarearchitekturen
und Betriebssystemen, insbesondere Apple OS X und Windows XP, unterstützt.
Zusammenfassend kann festgehalten werden: Aufgrund der niedrigen Hardwareanforderungen
wird das Projekt LTSP insbesondere als preiswerte Alternative zu herkömmlichen
Workstations in Schulen und Weiterbildungseinrichtungen positioniert, in denen
die Verbindung zwischen Terminalserver und Client über eine LAN-Verbindung hergestellt
wird und die Anzahl paralleler Zugriffe begrenzt bleibt. Leider zeigen die Erfahrungen,
dass LSTP nicht besonders gut skaliert. Dies ist ein weiterer Grund dafür, dass
LSTP in erster Linie für kleinere Organisationen oder Arbeitsgruppen eingesetzt wird.
Der Einsatz ist darüber hinaus nur im Rahmen geringer Sicherheitsanforderungen zu
empfehlen, insbesondere da Netzunterbrechungen zu einem Datenverlust führen können.
1.2 NoMachine NX Server
Mitte 2007 hat Medialogic den Terminalserver NoMachine NX 485 und den NX-Client in
der Version 3.0 veröffentlicht. Aktuell wird die Bezeichnung Desktop-Virtualisierungs-
und Fernwartungs-System verwendet.
Die freie Version, die für Linux und Solaris verfügbar ist, ist gegenüber der kostenpflichtigen
Version (ebenfalls für Linux und Solaris) funktional eingeschränkt. Eine Übersicht
der funktionalen Unterschiede kann man auf den Webseiten von NoMachine im Internet
finden 486 . Die Lizenzierung 487 des NX-Servers erfolgt nicht pro Verbindung, sondern über
die Anzahl gleichzeitiger Benutzer und pro Server. In der Enterprise Lizenz ist die Benutzeranzahl
unbeschränkt.
Die NX Distributed Computing Architecture basiert auf einer Weiterentwicklung von X-
Window. X-Window kann als Grundsystem für grafische Benutzeroberflächen in Linux
basierten Betriebssystemen bezeichnet werden. Dabei lässt sich die Bildschirmanzeige
nicht nur auf dem lokalen Rechner, sondern auch netzwerktransparent auf einem entfernten
Rechner umsetzen. Zusätzlich werden auch die Tastatur- und Mausbefehle weitergeleitet.
Es kann zwischen einem X-Server, der die grafischen Daten aufbereitet und
verschickt, und einen X-Client, der die Daten empfängt und grafisch darstellt, unterschieden
werden. Antworten (meist Tastatur- und Mauseingaben) des Clients werden
wiederum vom X-Server empfangen. Beide kommunizieren über das X-Protokoll. Zusammengehörige
Paare von X-Client-Anfragen und X-Server-Antworten bilden einen
round-trip, wobei nicht jede Anfrage eine Antwort erfordert. Round-trips beanspruchen
viel Bandbreite und verhindern so den Einsatz des X-Protokolls in langsamen Netzen.
Über das NX-Protokoll lässt sich eine Komprimierung der übertragenen Daten von
durchschnittlich ca. 70:1 erreichen. 488
485 http://www.nomachine.com/
486 http://www.nomachine.com/features.php (Stand 01.11.2007)
487 http://www.nomachine.com/licensing (Stand 01.11.2007)
488 http://www.pl-berichte.de/berichte/lt2004-nxartikel.html
Seite 492

Die NX-Komprimierungstechnologie erlaubt damit den Einsatz von X-Window auch in
Netzen mit geringer Bandbreite und hoher Latenz. Durch intelligente Komprimierung und
Cachen schon übertragener Daten sollte es jedem Anwender möglich sein, die Originalversionen
der gängigsten X-Desktop-Umgebungen über jede beliebige Netzwerkverbindung
auf einem Standard-X-Server auszuführen. Neben speziellen X-Protokoll-
Komprimierungsverfahren hat NoMachine integrierte Proxy-Agenten entwickelt, mit denen
komplette Remote-Desktop-Sitzungen über schmalbandige Internetverbindungen
realisiert werden können.
NX verfügt ebenfalls über eine Lastverteilung, indem Server die Netzlast gleichmäßig
verteilen und Sitzungen mehreren unterschiedlichen Servern zuweisen. Weiterhin erlaubt
es NX, einzelne Applikationen über schmalbandige Verbindungen zu übertragen
und so beispielsweise auf einem Linux-Server laufende Applikationen unter Windows
oder auf einem ThinClient zu nutzen.
Mit der Version 3 verfügt Medialogic NoMachine (NX) über zum Beispiel folgende Funktionalitäten:
� Session shadowing: Mehrere Benutzer können sich nun gleichzeitig eine einzige
Session zum Beispiel für Präsentationen oder Support teilen.
� Desktop sharing: Der Zugriff auf das lokale X Display erfolgt über NX.
� Verbesserte Verfügbarkeit: Die Flexibilität im Bereich der „Multi Node Setups―
wurde erhöht.
� Eventgesteuerte Skripte auf dem Server: Der Administrator kann eigene Skripte
aufrufen lassen, zum Beispiel beim Starten einer neuen Session oder beim Anlegen
eines neuen Benutzers.
Das Management der NX-Server wurde dadurch vereinfacht, dass aufgrund einer verbesserten
Integration mit den Host-Systemen (bereits seit Version 1.5 aus dem Jahr
2005) das Anlegen eigener NX-Accounts überflüssig ist.
Für die Authentisierung bietet NX eine LDAP-Unterstützung. NX verwendet die Remotefunktionen
von SSH für den Zugriff auf die Funktionen eines Servers, wobei die gesamte
Kommunikation verschlüsselt stattfindet. Zur erweiterten Sicherung der internen IT Infrastruktur
sind Zusatzprodukte zur Integration von Security-Token (zum Beispiel Aladdin
eToken PRO, Rainbow iKey 3000) entwickelt worden. Hierdurch kann eine sichere Möglichkeit
zur Authentisierung geboten werden.
NX-Server und Clientprodukte arbeiten primär unter Linux verschiedener Distributionen.
Während der Server künftig nur noch unter Solaris angeboten wird, ist der NX-Client
prinzipiell für jede Hardwareplattform unter Linux sowie für alle gängigen Betriebssysteme
wie Windows, Mac OS X oder Solaris verfügbar. Die Funktionalitäten von NX für das
Network Computing können daher außer in Linux-Umgebungen auch mit anderen Betriebssystemen
genutzt werden. Dabei übersetzt NX die Protokolle dieser Umgebungen
in das X-Protokoll, zum Beispiel das RDP, das von Microsoft und Citrix verwendet wird.
Somit ist auch der Zugriff auf Windows Anwendungen möglich.
Zusammenfassend kann festgestellt werden: NX-Server können OpenOffice-, KDE- und
andere X-Anwendungen einer großen Zahl von Anwendern parallel zur Verfügung stel-
Seite 493

len. Im Einzelfenster-Modus (etwa von KMail, bedient von Windows aus) wird dies einer
„stufenweisen" Migration dienlich sein. 489 NX wertet generell andere Terminalserver-
Installationen durch die Kompatibilität zu diesen auf (genauer die Umwandlung der Protokolle
in NX), auch indem Bandbreite eingespart und die Performanz erhöht wird. Mit
NX wächst somit eine Basistechnologie heran, die zu etablierten Lösungen eine Alternative
ist. NX braucht hinsichtlich Performanz und Features keinen Vergleich mit anderen
Produkten zu scheuen.
1.3 Microsoft Windows Terminal Server
Microsoft bietet Terminaldienste schon seit 1995 mit NT 3.51 an. Seitdem wurden die
Funktionen mit jeder neuen Windows Server Version ständig weiterentwickelt. Der Terminalserver
ist dabei integraler Bestandteil des jeweiligen Serverbetriebssystems, muss
jedoch gesondert lizenziert werden. Für Windows Server 2003 bedeutet dies, dass sowohl
Server 2003 entsprechende Lizenzen erworben werden müssen als auch für die
Terminalserver. Für die Nutzung der Terminaldienste unter Windows Server 2003 sind
für mehr als zwei parallel laufende Sessions Lizenzkosten für die Zugriffe zu entrichten.
Unter Windows Server 2003 ist unabhängig vom benutzten Desktop-System eine CAL
(Client Access License) zu erwerben, wobei zwischen Lizenzen pro Gerät und Lizenzen
pro Benutzer unterschieden werden. Jede Geräte-CAL gestattet einem Gerät (von einem
beliebigen Benutzer verwendet) Windows-Sitzungen auf einem Server durchzuführen.
Jede Benutzer-CAL gestattet einem Benutzer (der ein beliebiges Gerät verwendet) Windows-Sitzungen
auf einem Server durchzuführen.
Nachdem der Markt über lange Zeit hinweg weitgehend Citrix überlassen wurde, gewinnt
Microsoft im Markt für Terminalserver gegenüber Citrix zunehmend an Bedeutung. In
großen Umgebungen bleibt Citrix jedoch Marktführer und wird durch eine strategische
Partnerschaft mit Microsoft unterstützt.
Remote Desktop Protocol (RDP) ist das Protokoll, das die Microsoft Terminaldienste
verwenden, um eine sichere Kommunikation zwischen dem Terminal und dem Terminalserver
zu gewährleisten. 2006 wurde RDP 6.0 für Windows Vista veröffentlicht. RDP
bietet vielfältige Möglichkeiten. So können die beanspruchte Bandbreite reduziert, Ressourcen
mit anderen geteilt und mehrerer Bildschirme am Terminal eingesetzt werden.
Der Terminalserver von Microsoft ermöglicht Remotecomputern den Zugriff auf Windows
basierte Programme, die unter Windows Server 2003 ausgeführt werden. Dabei bietet
der Server die grundlegenden Funktionen, um Programme auszuführen, Dateien zu
speichern oder Netzwerkressourcen zu nutzen. Mit Windows Server 2003 ist es möglich,
einfache Audiodaten zur Ausgabe am Client bereitzustellen, Gruppenrichtlinien in die
Sessions zu integrieren und Bildschirme mit beliebiger Auflösung und Farbtiefe anzusteuern.
Auch die Übertragung von Druck- und Audiosignalen zu lokalen Geräten, die
direkt am Terminal angeschlossen sind, ist möglich. Des Weiteren besteht die Möglichkeit,
Verbindungen temporär zu unterbrechen, ohne dass sich der Nutzer am Terminalserver
abmelden muss.
489 http://www.pl-berichte.de/berichte/lt2004-nxartikel.html
Seite 494

Die Konfiguration von Anwendungen für den Terminalserverbetrieb über Gruppenrichtlinien
vereinfacht die Verwaltung der Windows Terminalserver. Administratoren müssen
Einstellungen daher nicht mehr pro Server vornehmen, sondern können dies übergreifend
an zentraler Stelle erledigen. Ein Active Directory Dienste Interface (ADSI)-Provider
erlaubt programmgesteuerten Zugriff auf benutzerabhängige Terminaldienste-
Einstellungen wie zum Beispiel Homedirectory, Berechtigungen und ähnliches. Neben
der Bereitstellung von Anwendungen bietet RDP Möglichkeiten, den Terminal entfernt zu
verwalten und Probleme des Anwenders schnell zu beheben.
Das RDP bietet Verschlüsselungsmöglichkeiten (128 Bit-Schlüssel) und die Möglichkeit
zur Smartcard-Authentisierung. RDB besitzt allerdings, aufgrund der Tatsache, dass
Client und Server sich nicht gegenseitig authentisieren müssen, eine Schwäche, welche
die Möglichkeit eines Man-in-the Middle Angriffs ermöglichen kann. Mit der Version RDP
v5.2 weist sich der Server dem Client gegenüber zwar mit einem Zertifikat aus, sodass
die Angriffe hätten unterbunden werden müssen. Doch dies gelang letztlich nur eingeschränkt,
da die verwendeten Schlüssel ausgelesen werden konnten. Microsoft empfiehlt
daher die RDP-Kommunikation zusätzlich über TLS abzusichern, da hiermit eine Authentisierung
gewährleistet ist. 490
Microsoft bietet sowohl die Server- (Windows Server 2000 und 2003) als auch die
Clientsoftware ausschließlich für Windows Betriebssysteme an. Es existieren Clients für
die meisten Windows-Versionen (auch Pocket-PC), Mac OS X, Linux und FreeBSD.
Über das Portable Operating System Interface (POSIX) lassen sich auch (PO-
SIX-konforme Linux- und Unix-Anwendungen bereitstellen.
Zusammenfassend ist zu bemerken: Die Kaufentscheidung für Terminalserverlösungen
unter Windows wird dadurch erschwert, dass sich die Grenze zwischen den Microsoft-
Basisfunktionen und den Add-ons permanent verschiebt. Der Markt für Zusatzprodukte
wird klar von Citrix mit dem Produkt Presentation Server dominiert. Erschwert wird die
Entscheidung auch dadurch, dass mit jeder neuen Windowsversion auch die Fähigkeiten
des Terminalservers und der dazugehörigen Clients erweitert werden, da sich Microsoft
im Markt für Softwareinfrastruktur gegen andere Serversysteme, in zunehmendem Maße
aus dem Linuxumfeld, behaupten muss. Gleichzeitig geraten die Anbieter von ergänzender
Software unter Druck und sind gezwungen, ihre Produktpalette ständig um neue
Features und Programme zu erweitern.
Dieses Dilemma setzt sich fort: Während sich einerseits die gebotenen Basisfunktionen
mit verschiedenen Versionen von Windows und in Abhängigkeit der geplanten Anwendung
ändern, beklagen sich andererseits die Kunden über kostenpflichtige Features, da
die Standarddienste durch Reduzierung der Funktionalität aus Gründen des Lizenzmarketings
auf den Windows Serverbetriebssystemen zu wenig Nutzen bieten.
Insgesamt führten die Verbesserungen an den Terminaldiensten jedoch dazu, dass der
Anteil der Installationen, die ohne fremde Add-ons auskommen, größer wird. In Windows
Server 2003 wurde die Ausstattung des Terminalservers weiter verbessert, sodass für
seine Nutzung weder kostspielige Zusatzsoftware oder kostenlose Alternativen (VNC
usw.) erforderlich sind. Nur bei größeren Installationen bedarf es weiterhin der Unterstüt-
490 http://www.heise.de/security/artikel/print/61945
Seite 495

zung durch Add-ons von Drittanbietern, in der Regel durch den Citrix Presentation Server.
1.4 Citrix Presentationserver
Citrix ist eine US-amerikanische Softwarefirma, die insbesondere durch das Produkt
Terminalserver bekannt wurde und lange Zeit als Synonym für Terminalserver galt. Citrix
kooperiert sehr eng mit Microsoft. Diese Kooperation umfasst eine technische Zusammenarbeit
im Bereich neuer Erweiterungsmöglichkeiten des Windows Terminalserver
und die gegenseitige Lizenzierung von Patenten. Darüber hinaus hat Citrix Zugriff auf
den Quellcode des Windows-Servers.
Obwohl die Citrix-Produkte nach wie vor sehr verbreitet sind und ein hohes Ansehen in
großen, heterogenen Netzen genießen, die komplexe Managementanforderungen nach
sich ziehen, sieht sich Citrix einer wachsenden Konkurrenz (u.a. Microsoft Terminalservers)
gegenüber.
Der Citrix Presentation Server ist Nachfolger des Marktführers Citrix Metaframe und
dient der Bereitstellung von Windows-Anwendungen. Mit Metaframe konnten mehrere
Terminalserver logisch zu einer Serverfarm zusammengeschlossen werden. Der Anwender
(Client) sieht hierbei nicht einen einzelnen Server sondern sogenannte veröffentlichte
Anwendungen, mit denen er sich verbindet. Auf welchem Server dann seine Anwendungen
ausgeführt werden, entscheidet ein Mechanismus innerhalb der Serverfarm.
Diese Architektur gewährleistet auch Verfügbarkeit bei Ausfall eines Servers.
Der Presentation Server von Citrix erfordert neben den Lizenzen für Microsoft Windows
Server/Terminalserver die eigenen Server- und Client-Lizenzen. Citrix Presentation Server
unterliegt wie alle Produkte aus dem Hause Citrix dem „Concurrent User" Lizenzmodell,
das heißt es müssen nur so viele Lizenzen erworben werden, wie Anwender gleichzeitig
auf dem Presentation Server arbeiten sollen. Die Citrix Presentation Server-
Software selbst darf auf beliebig vielen Servern installiert werden.
ICA (Independent Computing Architecture), so der Name des verwendeten Protokolls,
wird ausschließlich für die Kommunikation zwischen Terminalserver und Client genutzt.
Neben der Übertragung von Grafik- und Tastatur-/Mauseingabedaten unterstützt ICA
ebenfalls die Übertragung von Audiodaten, den Zugriff auf lokale Speicher oder angeschlossene
Geräte, wie zum Beispiel einen Scanner oder USB-Sticks. Generell benötigt
das ICA-Protokoll sehr wenig Bandbreite (10-20 kbps für einfache Anwendungen), da
u.a. nur tatsächlich geänderte Grafikdaten oder Maus- und Tastatureingaben des Nutzers
übertragen werden. Es können auch GPRS- oder GSM-Verbindungen genutzt werden,
für deren Endgeräte zum Beispiel Smartphones, ebenfalls Clientanwendungen,
verfügbar sind.
Die 2007 erschienene Version 4.5 des Citrix Presentation Server wird in drei Varianten
angeboten, die jeweils auf einem Windows Terminalserver aufsetzen:
Seite 496

� Advanced Edition:
Die Advanced Edition ist auf die Anforderungen von mittleren Umgebungen ausgelegt.
Eine sichere Bereitstellung der Windowsanwendungen über das Netzwerk
ist ohne jegliche Modifikation der Anwendungen sofort möglich. Neben zahlreichen
anderen Funktionen stellt die Advanced Edition ausgereiftes Load-
Balancing zum Aufbau von leistungsstarken Serverfarmen zur Verfügung. Über
das Load-Balancing wird erreicht, dass einzelne Sessions gleichmäßig auf alle
Citrix Server einer Farm verteilt werden. Dies geschieht in Abhängigkeit von der
aktuellen Auslastung des einzelnen Servers. Gemessen werden zum Beispiel
CPU-Last, verfügbarer Arbeitsspeicher und Netzwerk- und Plattenzugriffe. So
können auch Server mit sehr unterschiedlicher Leistungsfähigkeit zu einer Farm
zusammengeschlossen werden.
� Enterprise Edition:
Die Enterprise Edition ist auf die Anforderungen von größeren Umgebungen ausgelegt.
Sie bietet zusätzlich ein Application-Streaming, mit dem zentral konfigurierte
und verwaltete Windows-Anwendungen auf Benutzerdesktops oder weitere
Presentation Server im gesamten Unternehmen gestreamt und dort zur Ausführung
bereitgestellt werden können. Beim Application-Streaming werden Desktop-
Anwendungen „on demand" auf das Endgerät übertragen. Dort werden sie in einer
geschützten Umgebung lokal ausgeführt, ohne selbst am Endgerät installiert
sein zu müssen. Dieses „Pull basierte" Bereitstellungsmodell ist eine Alternative
zu lokalen Desktop-Installationen auf den einzelnen Endgeräten. Die gestreamten
Applikationen laufen dort in einer isolierten Umgebung auf dem Endgerät.
Damit werden von vornherein Versionskonflikte auf dem Endgerät vermieden, da
die gestreamte Anwendung mit anderen installierten Applikationen nicht in Berührung
kommt. Beim Streaming werden die einzelnen Programmkomponenten jeweils
nach Bedarf heruntergeladen und lokal ausgeführt. Wenn die Anwendung
einmal auf das Endgerät heruntergeladen wurde, kann sie auch im Offline-Modus
verwendet werden. Sobald wieder eine Verbindung zum Server hergestellt wird,
wird die Anwendung automatisch mit dem zuvor gespeicherten Anwendungsprofil
auf dem Server verglichen und gegebenenfalls automatisch mit bereitgestellten
Updates aktualisiert. Die Enterprise Edition enthält zusätzliche Verwaltungswerkzeuge
zur Unterstützung von großen Server-Farmen.
� Platinum Edition:
Die Platinum Edition beinhaltet darüber hinaus weitergehende Funktionen für IT-
Sicherheit und Performance Management.
Die primäre Authentisierung erfolgt über die Credentials von Microsoft. Desweiteren
kann auch die Authentisierung über biometrische Merkmale oder Smartcards erfolgen.
Die Verbindung zwischen Server und Client sind SSL/TLS gesichert.
Alle drei Citrix Presentation Server 4.5 Editionen unterstützen die Microsoft Plattformen
Windows Server 2003 und Windows Server 2003 x64. Zur Unterstützung von Windows
2000 Server-Umgebungen sind in allen Editionen weiterhin Presentation Server 4.0 Installationsmedien
enthalten.
Seite 497

Presentation Server Enterprise und Platinum Edition beinhalten zusätzlich Presentation
Server für UNIX-Betriebssysteme und bieten Unterstützung für Sun Solaris, IBM AIX und
Hewlett-Packard HP-UX.
Die Clientanwendung heißt Citrix-ICA-Client und ist für eine Vielzahl von Betriebssystemen,
zum Beispiel sämtliche Windows Betriebssysteme, DOS, Java, Linux, weitere
Unix-Derivate und Handheldsysteme, verfügbar.
Zusammenfassend kann festgehalten werden: Der Citrix Presentation Server ist insbesondere
für große Netze, die ausgefeilte Management-Konzepte erfordern, von großer
Bedeutung. Die Protokolle RDP und ICA können als annähernd funktionsgleich angesehen
werden. Gegenüber anderen Anbietern von Terminallösungen hat Citrix den Vorteil,
Client-Anwendungen für fast jede Plattform (aus einer Hand) anzubieten, wobei jedoch
neben den Citrix-Lizenzen immer auch die Lizenzen von Microsoft (mit-) erworben werden
müssen.
2 Migrationspfade
Wie bereits in der Einleitung des Themas Terminal-Dienste und Client-Konzepte erwähnt,
sind Terminalserver und deren zugehörige Clients kein klassisches Migrationsthema
in dem Sinne, dass Daten, Konten, Einstellungen etc. von einer Umgebung in
eine andere migriert werden müssen. Dem Einsatz von Terminalservern sind grundsätzliche,
strategische Entscheidungen vorgelagert, mit denen Ziele wie zum Beispiel eine
Verringerung des Administrationsaufwands, eine Erhöhung der Datensicherheit oder
geringere Hardware- und Energiekosten verfolgt werden (siehe auch Einleitung zu diesem
Themenblock – Kapitel III.E 1). Der Einsatz von Terminalservern ist in diesem Zusammenhang
dann Teil einer grundlegenden strategischen Entscheidung, die häufig die
Konsolidierung und Neuausrichtung der IT-Landschaft zum Inhalt hat. Andererseits kann
der Einsatz von Terminalservern ein Hilfsmittel sein, um einen mittel- bis langfristig angelegten
strategischen Wechsel in der IT-Landschaft durchzuführen, wie zum Beispiel ein
durchgehender Wechsel des Betriebssystems. Im Rahmen solch grundsätzlicher Entscheidungen
nehmen Terminalserver eine entscheidende Rolle bei der Unterstützung
von Migrationen ein. Sie können dort eingesetzt werden, wo Anwendungen z. B. einer
Windows-Umgebung in einer Linux- beziehungsweise OSS-Umgebung nicht lauffähig
sind. Wenn auf diese Anwendungen nicht verzichtet werden kann, können diese den
Benutzern über einen Terminalserver zur Verfügung gestellt werden. So wird eine in der
Regel aufwändige und zeitintensive Neuentwicklung umgangen und eine effiziente Umstellung
ermöglicht. Langfristig besteht hierbei aber dann das Ziel, diese Anwendungen
im Rahmen der laufenden Neubeschaffung unter Einhaltung der Prinzipien der Wirtschaftlichkeit
und des Investitionsschutzes durch Anwendungen zu ersetzen, die kompatibel
zur neuen IT-Infrastruktur sind. Damit werden die eingesetzten Terminalserver überflüssig.
Sind Terminalserver aber grundlegender Bestandteil einer IT-Infrastruktur, dann wird ein
Wechsel der eingesetzten Terminalservertechnologie in der Regel durch ähnliche strategische
Entscheidungen getrieben wie ein grundlegender Wechsel des Betriebssystems
oder der darauf aufsetzenden Software. Die Gründe für solche Entscheidung können
ganz unterschiedlich sein und sollen hier nicht näher betrachtet werden (siehe Modul I)
Seite 498

Die Entscheidung selbst ist der erste wichtige Schritt der Migration. Der zweite Schritt ist
die Wahl der neuen Terminalservertechnologie. Diese hängt zum einen sicherlich auch
von Gründen ab, die zu einer Wechselentscheidung geführt haben, und zum anderen
von Anforderungen, die an die Technologie gestellt werden.
Der Versuch einer Gegenüberstellung von Funktionen einzelner Terminalserverlösungen
ist aufgrund der Vielzahl der Funktionen und der Tatsache, dass sich fehlende Funktionen
häufig durch den Einsatz weiterer Tools ausgleichen lassen, nur sehr schwer möglich.
Die Grundfunktionen der Bereitstellung von Anwendungen auf einem Client-
Rechner werden prinzipiell von allen vorgestellten Lösungen erfüllt. Unterschiede, die
der einen oder anderen Lösung den Vorzug geben, liegen oft in den spezifischen Anforderungen
z. B. einzelner Behörden. Angefangen bei den Anwendungen, über die Anzahl
paralleler Sitzungen, bis hin zum Client-Betriebssystem oder am Client notwendiger
Hardware (z. B. die Möglichkeit mehrere Monitore an einem Client anzuschließen) ergeben
sie in jeder Organisation Anforderungen, die eine eingehende Analyse auch im
Hinblick auf zukünftige Anforderungen erfordern. Zudem erweist sich der Markt für Terminalserverlösungen
als sehr dynamisch und intransparent. So kommt es beispielsweise
zu Überschneidungen mit Konzepten, die unter dem Schlagwort Virtualisierung diskutiert
werden.
Die folgende Übersicht der Terminalserverlösungen, die im Abschnitt III.E 1 betrachtet
werden, hat daher nur den Charakter einer ersten Orientierung, um dem Leser einen
Eindruck über mögliche Beurteilungskriterien zu geben. Es besteht kein Anspruch auf
Vollständigkeit. Auch die Beurteilung einzelner Kriterien kann beim Lesen bereits überholt
sein.
LTSP NoMachine
NX
Seite 499
Microsoft
Terminalserver
2000
Microsoft
Terminalserver
2003
Lokale Drucker X 491 X X X X
Lokale Speichermedien,
USB-Sticks
X X X X X
Lokale Audioausgabe X X X X X
Load Balancing
(Farm)
Geringe Anforderungen
ans Netz (Maßnahmen
bei Unterbrechungen)
492 X X X X
X X X X
491 X = (tendenziell) erfüllt
492 Es befinden sich Entwicklungen in der Erprobung. siehe z. B.
http://www.mindtouchsoftware.com/blog/2007/04/30/ltsp/.
Citrix
Presentationserver

Nutzung von Anwendungen
durch den
Client ohne Netzzugang
Authentifizierung LDAP 493 ,
SSH
Active Directory Unterstützung
LTSP NoMachine
NX
Seite 500
Microsoft
Terminalserver
2000
Microsoft
Terminalserver
2003
X X
LDAP, SSH MS Credentials
MS Credentials
X 494 X 495 X X X
Citrix
Presentationserver
MS Credentials
Verschlüsselung SSH SSH SSL/TLS SSL/TLS SSL/TLS
Client-
Betriebssysteme
Client – Protokollunterstützung
Server-
Betriebssysteme
gängige
(Linux,
Windows
XP, OS X)
X-Window,
RDP
gängige
(Linux,
Windows
XP, OS X)
X-Window,
NX, RDP
Linux Linux, Solaris
Lizenzkosten keine Abhängig
von Anzahl
installierter
Server 497
Betriebssystem-basis
für Terminal-
Anwendungen
Betrieb des Clients
ohne Festplatte (Thin
Client)
Windows-
Versionen,
OS X, Linux
Windows-
Versionen,
OS X, Linux
(alle) gängigen
(DOS, Windows,
Java,
Linux
Handheld
etc.)
RDP RDP RDP, ICA
Win 2000 Win 2003 Win 2003,
2003 x64,
(Solaris,
AIX, HP-
UX) 496
Server und
Client (Benutzer
/
Geräte) –
Lizenzen
Server und
Client (Benutzer
/
Geräte) –
Lizenzen
Microsoft-
Lizenzen
+
Abhängig
von Anzahl
paralleler
Sitzungen
Linux Linux Windows Windows Windows,
(Unix)
X X
Tabelle 77: Übersicht der Funktionen verschiedener Terminalserverlösungen
493
http://www.pcxperience.org/thinclient/documentation/ldap.html
494
Werden nicht von allen Versionen unerstützt (nur NX Enterprise Server
NX Advanced Server)
495
http://www.linux-magazin.de/content/view/full/13549/month/12/year/2007
496
497
Nur in der Platinum-Edition.
http://www.linuxland.de/store/em99/EM99-202-EN/de/?view=desc

An dieser Stelle soll nochmals betont werden, dass sich nicht jede Anwendung problemlos
über einen Terminalserver zugänglich machen lässt. In der Tendenz sind 3D-grafik-
und multimedialastige Anwendungen für den Terminalserverbetrieb ungeeigneter. Der
Aufwand ist ex-ante allerdings schwer prognostizierbar oder auch nur zum Beispiel nach
Programmier- oder Administrationsaufwand kategorisierbar, da die Probleme stark durch
die vorhandene Infrastruktur und die vorhandene Parametrisierung bestimmt werden. Im
Rahmen einer geplanten Migration (von Client- und Serverbetriebssytemen und Anwendungen)
ist neben der Aufwandsschätzung für die Einrichtung von Terminalservern insbesondere
die Einrichtung möglichst realitätsnaher Testumgebungen sehr zu empfehlen,
da sich das Verhalten unter Last und eventuelle Inkompatibilitäten z. T. nur schwer
vorhersagen lassen.
In erheblichem Maße werden Terminalserverentscheidungen auch vom vorhandenen
Knowhow beeinflusst. So existieren oft wenig bekannte Lösungen, die als Zusatzsoftware
funktionale Anforderungen abdecken. Gerade im OSS-Umfeld empfiehlt sich daher
eine genauere Sondierung des Marktes.
Nachdem eine Auswahl für eine neue Terminalserverlösung getroffen wurde, welche den
definierten Anforderungen gerecht wird, stellt sich die Frage des Vorgehens bei der Migration.
Diese stellt sich insbesondere dann, wenn es darum geht, einen Wechsel des
Betriebssystems durchzuführen. Denn eigentlich nützt es nichts, lediglich einen Wechsel
der Terminalserverlösung durchzuführen, wenn die bestehenden Anwendungen nicht
damit zurecht kommen. Prinzipiell müssen hier ähnliche Vorgehensmodelle in Betracht
gezogen werden, wie sie auch bei einem Wechsel des Betriebssystems in Umgebungen
ohne Terminalserver zur Verfügung stehen (siehe Abschnitt I.D 2).
Aus der vorangegangenen Darstellung wird deutlich, dass ein Wechsel einer Terminalservertechnologie,
welche Gründe auch immer zu einer entsprechenden Entscheidung
führen, keinen grundlegenden Unterschied zu anderen Migrationen darstellt. Letztendlich
ergeben sich die Detailunterschiede aus den speziellen Entscheidungen und Anforderungen
der jeweiligen Behörde.
Im Folgenden werden mögliche Migrationspfade in erster Linie im Hinblick auf notwendige
Voraussetzungen und bemerkenswerte Funktionsunterschiede untersucht.
2.1 Migration von Microsoft Windows Terminal Server nach NoMachine NX
Server
Dem Wechsel von einem Microsoft Terminalserver auf einen NoMachine NX Server geht
in der Regel die Entscheidung für einen Wechsel der Client- und der Serverbetriebssysteme
von Microsoft zu Linux voraus beziehungsweise diese geht mit der Entscheidung
zu NoMachine NX Server einher. Die Entscheidung zur Migration auf Linux erfordert
dabei nicht zwingend die Ablösung des Windows Terminalserver, da Microsoft Clients für
Linux anbietet. Zudem gibt es mit rdesktop einen OSS-Client, der den meisten Linux-
Distributionen bereits beiliegt und den binären MS-Client ersetzen kann.
Spätestens wenn auch Linux-Anwendungen über einen Terminalserver bereitgestellt
werden sollen, müssen Alternativen gefunden werden. Hier zeichnet sich der NoMachine
NX Server zum einen durch seine Performance wegen des NX-Protokolls, das nur wenig
Seite 501

Bandbreite benötigt, und zum anderen durch ein Lizenzmodell, das Kosten pro Server
und nicht pro Verbindung verursacht, aus.
Des Weiteren eignet sich der NoMachine NX Server auch hervorragend zur Integration
beider Welten. Der kostenlose NX-Client unterstützt zum einen neben dem NX- und dem
X-Protokoll auch noch das von Microsoft verwendete Remote Desktop Protokoll (RDP).
Zudem lassen sich Anwendungen, die von einem Windows Terminalserver über das
RDP bereitgestellt werden, über Agenten in den NX-Server integrieren. Der NX-Server
kann die Anwendung daraufhin über das sehr effiziente NX-Protokoll den NX-Clients zur
Verfügung stellen. 498
Die Hauptbeweggründe für einen Wechsel lassen sich also in
� genereller Wechsel zu Linux,
� Bereitstellung von Linux-Anwendungen und
� Integration von Anwendungen aus Windows- und Linuxumgebungen
zusammenfassen.
Die Multifunktionalität der Lösung darf aber nicht die Bedeutung der Aufgabe einschränken,
am Anfang des Einsatzes von Terminalservern immer eine Bestandsaufnahme aller
Funktionen, Dienste und Programme durchzuführen. Nur auf dieser Basis kann dann
untersucht werden, für welche eine Ablösung durch Open Source erfolgen kann und
welche aus technischen oder wirtschaftlichen Gründen heraus beibehalten werden. 499
Auch hier gilt, dass zum Beispiel Office-Anwendungen und ERP-Clients, die in der Regel
weniger 3D-Darstellungen oder hoch auflösende Grafiken erfordern, sich eher für den
Terminalservereinsatz eignen als CAD-Anwendungen oder Anwendungen zur Bearbeitung
von Audio- oder Video-Daten.
Wie bereits bei der Vorstellung des NX-Servers erwähnt, zeichnet sich NX durch
� eine effiziente Kompression des normalen X-Verkehrs,
� einen intelligenten Mechanismus zum Speichern und Wiederverwenden (Cachen)
bereits übertragener Daten und
� eine starke Reduzierung zeitraubender X „round-trips―
aus und ermöglicht so eine kaum eingeschränkte Arbeitsgeschwindigkeit des Benutzers
und eine nur geringe Beanspruchung der Bandbreite des Netzes. 500
Bei einem Wechsel des Teminalservers von Microsoft zu NoMachine ist zu beachten,
dass auf jeden Client-Rechner ein NX-Client ausgerollt werden muss, sofern dieser nicht
als Web-Client laufen soll. Da der NX-Client nicht OpenSource ist, haben gängige Linux-
Distributionen in der Regel keinen NX-Client installiert. Auf Windows-Rechnern befindet
sich standardmäßig ohnehin kein NX-Client. Im Gegensatz dazu ist der Client zur Verbindung
mit dem Windows Terminalserver bei aktuellen Windows-Rechnern dabei.
498 http://www.pl-berichte.de/berichte/lt2004-nxartikel.html
499 http://www.dtnet.de/Loesungen/OSS-
Migration/OpenSourceEinfuehrunginUnternehmen/index.html
500 http://www.pl-berichte.de/berichte/lt2004-nxartikel.html
Seite 502

Die Installation der Clients gestaltet sich allerdings sehr einfach. Für alle Betriebssysteme
werden die Standard-Installationsarten verwendet (.exe unter Windows, .rpm oder
.deb – Dateien für Linux).
2.2 Migration von Microsoft Windows Terminal Server 2000 nach Microsoft
Windows Terminal Server 2003
Ein Wechsel von Windows Terminalserver 2000 zu Windows Terminalserver 2003 wird
in erster Linie durch den Wechsel des darunter liegenden Servers bestimmt. Gegenüber
dem Windows 2000 Server hat der Windows Server 2003 insbesondere in den Bereichen
Hochverfügbarkeit, Sicherheit, Skalierbarkeit und Administration/Wartung gewonnen;
diese unterstützen indirekt auch den Terminalserver:
� Hochverfügbarkeit
Neben dem Microsoft Cluster Service und Network Load Balancing, das seit
Windows 2000 bekannt ist, tragen zusätzliche Monitoring- und Prozessrecycling-
Features zur Verbesserung bei.
� Sicherheit:
Wichtige Änderungen im Sicherheitsbereich betreffen die Definition von Serverrollen.
Dabei werden nur die von der jeweiligen Serverrolle benötigten Dienste installiert.
Die kritische Funktionalität 501 muss explizit frei geschaltet werden. Zusammen
mit dem aus Windows 2000 Server bewährten und natürlich auch in
Windows Server 2003 vorhandenen Sicherheitsmechanismen wie Kerberos, PKI,
SSL, IPSec, und so weiter lassen sich sichere Systeme aufbauen.
� Skalierbarkeit
Um auch für Lastspitzen, zum Beispiel bei Internet-Anwendungen, gut gerüstet
zu sein, hat sich in der Vergangenheit die Verwendung von Network Load Balancing
Clustern bewährt. Diese Funktionalität ist in Windows Server 2003 durch ein
neues grafisches Benutzerinterface einfacher zu bedienen.
� Administration und Wartung
Die von Windows Server 2003 bereitgestellte Funktionalität ist um einige Stufen
granularer sowie auf die Bedürfnisse im realen Betrieb besser abgestimmt, als
die von den Bordmitteln vorangegangener MS-Serverbetriebssysteme bekannten
Tools. 502
Gegenüber Terminalserver 2000 sind beim Terminalserver 2003 insbesondere folgende
Erweiterungen hervorzuheben: 503
� Bessere Skalierbarkeit
Der Terminalserver 2003 unterstützt mehr Benutzer pro Server als Windows
501 Als Beispiel seien die Frontpage Extensions im IIS genannt.
502 Einen Vergleich der Funktionalitäten findet man unter
http://www.microsoft.com/germany/windowsserver2003/uebersicht/vergleich.mspx oder
http://www.microsoft.com/germany/msdn/library/windows/windowsserver2003/WindowsSer
ver2003AlsAnwendungsplattform.mspx?mfr=true
503 http://msdn2.microsoft.com/en-us/library/Aa383015.aspx;
http://www.abacus.ch/downloads/pages/2004-03/s58-59.pdf
Seite 503

2000 Terminalserver. Ebenso werden Technologien zum Ausgleich von Netzwerklasten
und von Serverlasten unterstützt.
� Einfachere Verwaltbarkeit
Über die Einbindung von Gruppenrichtlinien bietet Terminalserver 2003 bessere
Möglichkeiten, einen Client remote zu verwalten. Über WMI (Windows Management
Instrumentation) Provider mit Schreib- und Lesezugriff stehen eine Vielzahl
von Verwaltungsmöglichkeiten zur Verfügung.
� Benutzerfreundliche Remote-Desktop-Verbindung
Die Remote-Desktop-Verbindung ist der Terminalclient von Windows. Eine neue
Benutzeroberfläche ermöglicht eine leichtere Bedienung, ein Speichern von Verbindungseinstellungen,
eine dynamische Anpassung an die verfügbare Bandbreite
und so weiter.
� Erweitertes RDP
Windows Terminalserver 2003 unterstützt die RDP 5.1, das mit dem Servicepack
1 für Windows XP ausgeliefert wurde. Dies bedeutet eine Vielzahl von Erweiterungen
gegenüber RDP 5.0, das von Windows Terminalserver 2000 genutzt wurde.
Bei der Verwendung von RDP 5.1 stehen im Rahmen der Session lokale
Ressourcen zur Verfügung, zum Beispiel das Dateisystem des Clients, Audioausgabe,
serielle Anschlüsse, Drucker oder Zwischenablage. So können Dateien
auf dem lokalen Client geöffnet, gespeichert oder gedruckt werden, auch wenn
die Anwendung auf dem entfernten Terminalserver läuft. Mit RDP 5.1 können zudem
eine Farbtiefe von 256 Farben bis zu True Color ausgewählt und Bildschirmauflösungen
von 640 x 480 bis zu 1600 x 1200 festgelegt werden. 504
Ein Wechsel des Terminalservers von der Version 2000 auf 2003 ist insgesamt nur ratsam,
wenn die erweiterten Funktionen benötigt werden. Clientseitig stehen die erweiterten
Möglichkeiten, Multimediaanwendungen zu nutzen, die eine hohe Bildschirmauflösung
und große Farbtiefe erfordern oder die Ausgabe von Audiodaten verlangen, im
Vordergrund. Serverseitig kann auch die Entscheidung einer Serverkonsolidierung zum
Beispiel der Ersatz mehrerer kleinerer Server durch einen leistungsfähigeren Server einen
Wechsel sinnvoll machen, insbesondere vor dem Hintergrund, dass Microsoft den
Support für Windows 2000 bereits aufgekündigt hat.
Bei einem Wechsel des Terminalservers von 2000 nach 2003 ist des Weiteren darauf zu
achten, dass die Client-Software aktualisiert wird, damit die erweiterten Funktionen des
RDP genutzt werden können. Hierbei handelt es sich um die Remote Desktop Connection
Software, die für alle neueren Windows-Versionen verfügbar ist. 505
Die Migration von Windows 2000 Server auf Windows Server 2003 verläuft in der Regel
„out of the box― und ist gut dokumentiert. 506 Probleme können in Abhängigkeit von der
definierten Serverrolle, der Parametrisierung und gegebenenfalls installierter Zusatz-
504
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/
7750ed9c-f468-484e-a08f-ccab73ddd3fe.mspx?mfr=true
505
http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=80111F21-
D48D-426E-96C2-08AA2BD23A49
506
Eine Seite mit Microsoft-Hinweise findet man unter
http://www.microsoft.com/windowsserver2003/upgrading/w2k/default.mspx
Seite 504

software auftreten, wobei sich diese nicht generell vorhersagen lassen. Erfahrungsgemäß
kommt es so gut wie nie aufgrund der Terminalserver-Einstellungen oder -
Funktionen zu Problemen.
2.3 Von Microsoft Windows Terminal Server nach Citrix Presentationserver
Gartner Research hat in einer Studie vom Juli 2004 den Windows Terminalserver 2003
und den damaligen Citrix MetaFrame Terminalserver miteinander verglichen. Danach ist
der Windows 2003 Terminalserver ausreichend, wenn nur Windows Applikationen genutzt
werden, weniger als 800 Benutzer angeschlossen sind, nicht mehr als 10 Anwendungen
verwendet werden und die Microsoft Windowsserver Management Funktionalität
eingesetzt wird. 507
Eine spätere Untersuchung der Tolly Group im Auftrag von Citrix bestätigte die Aussagen
von Gartner Research. Neben einer leichten generellen Verbesserung der Geschwindigkeit
lagen die Vorteile des Citrix Presentation Server gegenüber dem Windows
2003 Terminalserver insbesondere im Bereich Leistungsstabilität auch bei höherer Serverauslastung.
Während sich die Antwortzeiten des Windows Terminalserver 2003 bei
steigender Last überproportional verlängerten, blieben diese beim Presentation Server
sehr stabil. 508
Diese Aussagen gelten bis heute. Bei dem Citrix Presentation Server handelt es sich um
die große Lösung im Bereich der Terminaldienste. So wurden beispielsweise im Bereich
der öffentlichen Verwaltung bei der LVA Rheinprovinz, einem Träger der gesetzlichen
Rentenversicherung, ca. 5000 Benutzer über mehrere Standorte mit Anwendungen versorgt.
Die Anwendungssoftware wurde hier auf eine zentrale Serverfarm mit mehr als 80
Citrix Presentation Servern verlagert. Des Weiteren wurden für das Rechenzentrum der
Finanzverwaltung des Landes Nordrhein-Westfalen über 140 Dienststellen mit ca.
17.000 Benutzern mit entsprechenden Anwendungen versorgt. Als weiteres Referenzprojekt
im öffentlichen Sektor nennt Citrix eine Implementierung des Servers bei den
Stadtwerken Herne, bei der ca. 300 Benutzer angeschlossen sind. 509 Hierbei dürfte es
sich allerdings tendenziell um die untere Grenze sinnvoll mit dem Citrix Presentation
Server versorgter Benutzer handeln.
Neben Vorteilen bei der Skalierbarkeit beinhaltet die Lösung von Citrix weitere Funktionen,
die Windows Terminalserver 2003 allein nicht bietet, sodass Citrix Presentationserver
insgesamt die umfassendere Lösung darstellt, die speziell auf die Bedürfnisse großer
Behörden und Unternehmen mit vielfältigen Einsatzszenarien ausgelegt ist. Die weiteren
Funktionsunterschiede lassen sich in die Kategorien Benutzerwahrnehmung, Administration,
Kompatibilität und Sicherheit bzgl. Vertraulichkeit und Integrität der Daten unterteilen.
507 Gemäß http://www.abacus.ch/downloads/pages/2004-03/s58-59.pdf
508 http://www.tolly.com/ts/2006/Citrix/PresentationServerEnterprise/ TollyTS206146CitrixSystemsPresentationServer4August2006.pdf
509 Diese und weitere Beispiele für Citrix in der öffentlichen Verwaltung finden sich unter
http://www.citrix.de/modules/resource/download/42e116630e199a42010e1caf38e5000a/Oe
ffentliche%20Verwaltung.pdf
Seite 505

Im Folgenden werden die einzelnen Kategorien näher betrachtet und kurz exemplarische
Einsatzszenarien angedacht, die den Zusatznutzen der erweiterten Funktionalität (neben
der besseren Skalierbarkeit) eines Presentation Server gegenüber Windows Terminalserver
darstellen. 510
� Benutzerwahrnehmung:
Im Bereich der Benutzerwahrnehmung sind neben den erwähnten Performance-
Verbesserungen der Anwendungen (insbesondere bei hoher Serverauslastung)
verbesserte und schnellere Druckfunktionen zu erwähnen. So verringert sich die
Bearbeitung eines Druckauftrags um den Faktor 2-3. Des Weiteren ermöglichen
verbesserte Multimedia-Möglichkeiten (zum Beispiel die Synchronisation von Audio
und Video oder bidirektionaler Austausch von Audiodaten) E-Learning-
Anwendungen oder anspruchsvolle Grafik-Programme.
Für mobile Nutzer eines Laptops bietet der Citrix Presentation Server eine Funktion
namens Application Streaming. Diese ermöglicht den Benutzern die Verwendung
einer Applikation, ohne dass eine Verbindung zum Netzwerk besteht.
� Administration:
Der Presentation Server bietet insgesamt weitaus differenziertere Möglichkeiten
der Administration. Über eine Mangement-Konsole kann gezielt festgelegt werden,
wann welche Anwendung veröffentlicht wird oder welche Rechte zur Nutzung
einer Anwendung erforderlich sind. Anwendungen können zudem automatisiert
auf verschiedenen Presentation Servern installiert werden.
Einzelne Sitzungen lassen sich anhand verschiedener Kriterien wie CPU-Last
oder RAM-Auslastung verteilen. Geografisch verteilte Server lassen sich in einer
sogenannten Farm zusammenfassen und bieten hierdurch einen verbesserten
Schutz bei Ausfall eines Servers und ermöglichen die gezielte Überwachung einzelner
Anwendungen. Darüber hinaus erlaubt es der Presentation Server, einzelne
Anwendungen über einen Web-Browser zu nutzen oder diese in ein Web-
Portal einzubinden, ohne dass ein erneutes Anmelden erforderlich wird. Über ein
erweitertes Management der Druckdienste lassen sich neben zusätzlichen Funktionen,
wie zum Beispiel die gezielte Auswahl eines Papierfachs, das Heften,
beidseitiger Druck und so weiter, auch eine Vielzahl von Druckern einbinden, deren
Nutzung über Richtlinien eingeschränkt werden kann.
� Kompatibilität:
Die größere Kompatibilität des Presentation Server gegenüber dem Terminalserver
2003 zeigt sich (neben der Möglichkeit, eine Vielzahl von Druckern einzubinden)
zum Beispiel dadurch, dass mehr Client-Betriebssysteme (auch für viele
Handhelds und Smartphones) und mehr USB-Geräte (zum Beispiel Scanner oder
zur USB-Synchronisation von Pocket-PCs) unterstützt werden.
Über die Funktion der Application Isolation können Anwendungen über einen
Terminalserver veröffentlich werden, die nicht für den Einsatz auf diesen entwi-
510 http://www.citrix.de/modules/resource/download/42e1166210bbd11f0110bcd89f500003/
eng_ValueAdd_CPS4.5_TS2003.pdf
Seite 506

ckelt wurden. So können zum Beispiel Registry-Einträge, die Sperrung von Bibliotheken,
Objekt-Benennungen und so weiter isoliert werden, sodass andere Anwendungen
von den Einstellungen nicht betroffen werden.
� Sicherheit bzgl. Vertraulichkeit und Integrität der Daten:
Neben einer Verschlüsselung über einen SSL Gateway oder ein hardwareunterstütztes
VPN bietet Citrix eine breite Unterstützung sicherheitsrelevanter Technologien.
Zum Beispiel werden im Bereich starker Authentifizierung Token, Smartcards
oder biometrische Sensoren unterstützt. Zudem müssen DMZs nicht gesondert
konfiguriert werden, um den Datenverkehr des Presentation Server
durchzuleiten.
Hilfreiche Foren zum Thema Migration und zur Installation des Citrix Presentation Server
mit Problemlösungen beziehungsweise Ursachen finden sich auf den Seiten der Deutschen
Citrix User Group (DCUG). 511
3 Bezüge
Bei der Migration von Terminaldiensten existieren vor allem Bezüge zu den Themen
Authentifizierungsdienste und Netzwerkdienste.
3.1 Authentifizierungs- und Verzeichnisdienste
Authentifizierungs- und Verzeichnisdienste werden in der Regel im Rahmen von Terminaldiensten
und Clientkonzepten integriert, um damit eine höhere Anzahl von Benutzern
und deren Identitätsdaten besser verwalten und steuern zu können. Hierdurch wird zum
einen eine redundante Datenhaltung vermieden und zum anderen erheblicher Verwaltungsaufwand
eingespart. Siehe hierzu Kapitel II.C .
3.2 Netzwerkdienste
Netzwerkdienste sind prinzipielle Voraussetzung für den Einsatz von Terminaldiensten.
Sie stellen überhaupt erst die Möglichkeit zur Realisierung von Terminaldiensten über
die Verbindung der Terminals mit den Servern zur Verfügung und liefern grundlegende
Werkzeuge für die Administration. Im Zuge einer Migration sollten daher die Betrachtungen
des Kapitels II.D Berücksichtigung finden.
511 http://www.dcug.de/cms/portal.php.
Seite 507

IV. Anhang
A Abkürzungsverzeichnis
a.a.O am angegebenen Ort
Abs. Absatz
ACE Access Control Entries
ACL Access Control List
AD Active Directory
ADAM Active Directory Application Mode
ADC Active Directory Connector
ADMT Active Directory Migration Tool
ADO ActiveX Data Objects
ADS Active Directory Service
ADSI Active Directory Service Interface
AfA Aufwand für Abschreibung
AFS Andrew File System
AIX Unix Distribution der Firma IBM
AJAX Asynchronous JavaScript and XML
Alt. Alternative
Anz. Anzahl
APC Arbeitsplatzcomputer
API Application Programming Interface
APOC A Point Of Control
APOP Authenticated Post Office Protocol
APT Advanced Package Tool
ASCII American Standard Code for Information Interchange
ASF Apache Software Foundation
ASP Active Server Pages
ATL Active Template Library
ATM Asynchronous Transfer Mode
Aufl. Auflage
AZ Aktenzeichen
BB Bulletin Boards
Seite 508

BDC Backup Domain Controller
BfD Bundesbeauftragter für den Datenschutz
BGB Bürgerliches Gesetzbuch
BHO Bundes-Haushalts-Ordnung
BIND Berkeley Internet Name Domain
BMF Bundesministerium für Finanzen
BMI Bundesministerium des Innern
BOOTP Bootstrap Protocol
BS Betriebssicht
BSD Berkeley Software Distribution
BSI Bundesamt für Sicherheit in der Informationstechnik
bspw. beispielsweise
BVA Bundesverwaltungsamt
BVB Besondere Vertragsbedingungen
bzgl. bezügliche
bzw. beziehungsweise
CA Certification Authority
ca. cirka
CAL Client Access License
Calc. Calculation (Kalkulation)
CAS Code Access Security
CCSMT SMS Migration Tool
CDO Collaboration Data Objects
CGI Common Gateway Interface
CIFS Common Internet File System
CIM Common Information Model
CIS COM Internet Service
CLI Common Language Infrastructur
CLR Common Language Runtime
cn common Name
CO Crossover Office
COLS Commercial Linux Software
COM Component Object Models
COM+ Component Object Models
Seite 509

CORBA Common Objects Request Broker Architecture
CPU Central Processing Unit
CSS Cascading Style Sheets
CUPS Common UNIX Printing System
DACL Discretionary Access Control List
DAV Distributed Authoring and Versioning
DB Datenbank
DBMS Datenbankmanagementsystem
DC Domain Controller
dc domainComponent
DCOM Distributed Component Object Models
DDE Dynamic Data Exchange
DDNS Dynamic DNS
DFS Distributed File System
DHCP Dynamic Host Configuration Protocol
DIT Directory Information Tree
DLC Data Link Control
DLL Dynamic Link Libraries
DMS Dokumentenmanagementsystem
DMZ Demilitarized Zone
DN Distinguished Name
DNS Domain Name Server
DNSSEC Domain Name System Security
DOM Document Object Model
DOMEA Dokumenten-Management und elektronische Archivierung
DRBD Distributed Replicated Block Device
DS Directory Service
DSO Dynamic Shared Objects
DTD Document Type Definition
DTS Data Transformation Services
DV Datenverarbeitung
DXL Domino Extensible Language
E2K Exchange 2000
ECMA European Computer Manufacturers Association
Seite 510

EFQM European Foundation for Quality Management
EFS Encrypting File System
EJB Enterprise Java Beans
EMF Enhanced Meta Format
ESC/P Epson Printer Language
etc. et cetera
EULA End User License Agreement
EVB-IT Ergänzende Vertragsbedingungen für die Beschaffung von IT-
Leistungen
EXT2 Extendend Filesysten Version 2
EXT3 Extended Filesystem Version 3
f. folgend
f., ff. folgend(e)
FAT File Allocation Table
Fn. Fußnote
FQDN Full Qualified Domain Name
FRS File Replication Service
FSG Free Standard Group
FSMO Flexible Single Master Operation
FTP File Transfer Protocol
GC Global Catalog
GDI Graphics Device Interface
GGO Gemeinsame Geschäftsordnung der Bundesministerien
ggü. gegenüber
GmbH Gesellschaft mit beschränkter Haftung
GMBI Gemeinsames Ministerialblatt
GNOME GNU Network Object Model Environment
GNU GNU's Not UNIX ???
GPL General/Gnu Public License
GPOs Group Policy Objects
GPS Global Positioning System
GSS-API Generic Security Service API
GUID Global Unique Identifier
GWB Gesetz gegen Wettbewerbsbeschränkungen
Seite 511

HACMP High Availability Cluster Management Protocol
HAL Hardware Abstraction Layer
HD Harddisk
HIS Host Integration Server
HP Hewlett-Packard
Hrsg. Herausgeber
HS Haushaltssicht
HSM Hierarchical Storage Management
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hyper-Text Transfer Protocol Secure
i. d. F. v. in der Fassung von
i. d. R. in der Regel
i. w. S. im weiteren Sinn
ICA Independent Computing Architecture
IDE Integrated Development Enviroment
IEAK Internet Explorer Administration Kit
IETF Internet Engineering Task Force
IIOP Internet Inter-ORB Protocol
IIS Internet Information Server
IL Intermediate Language
IMAP4 Internet Mail Access Protocol 4
IMAPS Internet Mail Access Protocol Secure
IMKA Interministerieller Koordinierungsausschuss für Informationstechnik in
der Bundesverwaltung
IP Internet Protocoll
IPC Interprocess Communication
IPP Internet Printing Protocol
Ipsec Internet Protocol Security Protocol
IPv6 IP Version 6
IPX Internet Packet Exchange
IRC Internet Relay Chat
IRM Information Rights Management
IS Information Store
Seite 512

ISA Internet Security and Acceleration
ISAPI Internet Service Application Programming Interface
ISC Internet Software Consortium
ISO International Organization for Standardization
ISSN International Standard Serial Number
IT Informationstechnologie
IT-WiBe Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen
beim Einsatz der IT in der Bundesverwaltung
IuK Information und Kommunikation
J2EE Java 2 Enterprise Edition
J2SE Java 2 Standard Edition
JAXP Java API for XML
JDBC Java Database Connectivity
JDS Sun Java Desktop System
JFS Journaled File System
JIT Just In Time
JMC Java Message Service
JNDI Java Naming and Directory Interface
JRE Java Runtime Environment
JRMI Java Remote Method Invocation
JSP Java Server Pages
JTA Java Transaction API
JVM Java Virtual Machine
KBSt Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik
in der Bundesverwaltung
KDC Key Distribution Center
KDE K Desktop Environment
KLR Kosten- und Leistungsrechnung
KMS Key Management Server
KN Kosten/Nutzen
kWh Kilowattstunde
kw-Stelle „künftig wegfallend― Stelle
LAMP Linux, Apache, MySQL, PHP
LAN Local Area Network
Seite 513

LANANA Linux Assigned Names and Numbers Authority
LDAP Lightweight Directory Access Protocol
LDIF LDAP Data Interchange Format
LGPL Lesser General Public License
Li18nux Linux Internationalization Initiative
LM LAN Manager
LMRepl Verzeichnisreplikationsdienst
LPD Line Printing Daemon
LPI Linux Professional Institute
LPR Line Printing Redirector
LSA Local Security Authority
LSB Linux Standard Base
LTSP Linux Terminal Server Project
LVM Logical Volume Manager
LVS Linux Virtual Server
MAC Media Access Control
MAPI Messaging Application Programming Interface
MB Megabyte
MDX Message Digest X
MFT Master File Table
MIME Multipurpose Internet Mail Extension
MLP Message/Multilayer Link Protocol
MMC Microsoft Management Console
MMQS Microsoft Message Queue Server
MOM Microsoft Operation Manager
MPL Mozilla Public License
MRTG/RRD Multi Router Traffic Grapher/Round Robin Database
MS Microsoft
MSMQ Microsoft Message Queuing
MSPS Microsoft Proprietary Standards
MT Manntage
MTA Message Transfer Agent
MTBF mean time between failure
MTS Microsoft Transaction Server
Seite 514

MTTR Mean Time To Repair
NAS Network Attached Storage
NAT Network Address Translation
NCSA National Center for Supercomputing Application
NDS Novell Directory Service
NetBEUI NetBIOS Extended User Interface
NetBIOS Network Basic Input and Output System
NetBT NetBIOS over TCP/IP
NFS Network File System
NIS Network Information Service
NLD Novell Linux Desktop
NNTP Network News Transport Protocol
NPL Netscape Public License
NSS Name Service Switch
NTDS NT Directory Service
NTFS NT File System
NTFS4 NT File System 4
NTFS5 New Technology File System 5
NTLM Windows NT LAN Manager
NTLMv2 Windows NT LAN Manager Version 2
NTP Network Time Protocol
ODBC Open Database Connectivity
ODF Open Document Format
OGo OpenGroupware.org
OLAP Online Analytical Processing
OLE Object Linking and Embedding
OMG Object Management Group
OMPM Office Migration Planning Manager
OOo OpenOffice.org
OOo/SO Open Office.org/StarOffice
OOXML Office Open XML
OpenLDAP Open Lightweight Directory Access Protocol (LDAP)
ORB Object Request Broker
OSI Open Systems Interconnection
Seite 515

OSOS Open Standards mit Open Source
OSS Open Source Software
OU Organizational Unit
OWA Outlook Web Access
PAM Pluggable Authentication Module
PatG Patentgesetz
PBS Portable Batch System
PBX Private Branch Exchanger
PC Personalcomputer
PCL Printer Control Language
PDA Personal Digital Assistant
PDC Primary Domain Controller
PDF Portable Document Format
Perl Practical Extraction and Report Language
PHP PHP Hypertext Pre-processor
PIM Personal Information Manager
PKI Public Key Infrastructure
PM Projektmanagement
POP3 Post Office Protocol Version 3
POSIX Portable Operating System Interface for UNIX
PPD PostScript Printer Descriptions
ProdHaftG Produkthaftungsgesetz
PS Projektsicht
PT Personentage
PXE Pre-Boot Execution Environment
QS Qualitätssicherung
RAC Real Application Cluster
RAID Redundant Array of Inexpensive/Independent Discs
RAM Random Access Machine/Memory
RAS Remote Access Service
RAW Read After Write
RDBMS Relationales Datenbank Management System
RDP Remote Desktop Protocol
ReiserFS Reiser File System
Seite 516

RFCs Request for Comments
RHCE Red Hat Certified Engineer
RHD Red Hat Desktop
RHN Red Hat Network
RID Relative Identifier
RISC Reduced Instruction Set Computer
RMI Remote Method Invocation
RMS Rights Management Services
RPC Remote Procedure Calls
RPM Red Hat Packet Management
Rz. Randziffer
S. Seite
S/MIME Secure MIME (Multipurpose Internet Mail Extensions)
SA System Attendant
SACL System Access Control List
SAGA Standards und Architekturen für E-Government-Anwendungen
SAM Security Accounts Manager
SAN Storage Area Network
SASL Simple Authentication and Security Layer
SBS Small Business Server
SC Samsung Contact
SCCM System Center Configuration Manager
SCM Security Configuration Manager
SCOM System Centre Operations Manager
SCS Sun Control Station
SCSI Small Computer System Interface
SDB Simple Database Backend
SDBC Star Database Connectivity
SDK Software Developer Kit
SFU Service for UNIX
SID Security Identifier
SISL Sun Industry Source License
SLAs Service Level Agreements
SLOX Suse Linux Openexchange
Seite 517

SMB Server Message Block
SMS Short Message Service
SMS System Management Server
SMTP Simple Mail Transfer Protocol
SNA Storage Network Attached
SNMP Simple Network Management Protocol
SO StarOffice
SOAP Simple Object Access Protocol
SPM Standard TCP/IP Port Monitor
SPX Sequenced Packet Exchange
SQL Structured Query Language
SQL-DMO SQL Distributed Management Objects
SRS Standard Replication Service
SSH Secure Shell
SSL Secure Sockets Layer
SSL/TLS Secure Sockets Layer / Transport Layer Security
SSO Single Sign-On
SUS Java System Update Service
SVG Scalable Vector Graphic
SW Software
SWA Scalix Web Access
SWAP Simple Workgroup Access Protocol
SWAT Samba Web Administration Tool
TB Terabyte
TCL Tool Command Language
TCO Total Costs of Ownership
TCP/IP Transmission Control Protocol / Internet Protocol
TDS Tabular Data Stream
TGS Ticket Granting Service
TGT Ticket Granting Ticket
TLS Transport Layer Security
TNEF Transport Neutral Encapsulation Format
TTS Trouble Ticket System
u. a. unter anderem
Seite 518

u. ä. und ähnliches
u. U. unter Umständen
UCS Univention Corporate Server
UDDI Universal Description, Discovery and Integration
UDP User Datagram Protocol
UfAB Unterlage für die Ausschreibung und Bewertung von IT-Leistungen
UGS Univention Groupware Server
UHD User Help Desks
UI User Interface
UNC Uniform Naming Convention
UNO Universal Network Objects
UrhG Urheberrechtsgesetz
URL Uniform Resource Locator
USB Universal Serial Bus
USN Unique Sequence Number
usw. und so weiter
Var. Variante
VBA Visual Basic for Applications
VBS Visual Basic Scripting Edition
VBScript Visual Basic Script
VFS Virtual File System
VLDB Very Large Database
VMX Vintela Management Extensions
VOL Verdingungsordnung für Leistungen
VOL/A Verdingungsordnung für Leistungen/ Teil A Allgemeine Bestimmungen
für die Vergabe von Leistungen
VPN Virtual Private Network
vs. versus
VSF Vorschriftensammlung der Bundesfinanzverwaltung
VV Verwaltungsvorschrift
W2K Windows 2000
W3C World Wide Web Consortiums
WAN Wide Area Network
WAP Wireless Application Protocol
Seite 519

WBEM Web Based Enterprise Management
WebDAVS Web Document Authoring And Versioning
WiBe Wirtschaftlichkeitsbetrachtung
WINS Windows Internet Name Service
WMI Windows Management Instrumentation
WSDL Web-Services Description Language
WSH Windows Sripting Host
WWW World Wide Web
WYSIWYG what you see is what you get
XFS Extended File System
XHTML eXtensible HyperText Markup Language
XML Extensible Markup Language
XPS XML Paper Specification Format
XSL Extensible Style Sheet Language
XSLT Extensible Stylesheet Language for Transformations
YaST Yet another Setup Tool
z. B. zum Beispiel
z. T. zum Teil
Seite 520

B Glossar
.NET .NET ist die Bezeichnung für die aktuelle Programmierumgebung von Microsoft.
Sie besteht aus verschiedenen Frameworks (Klassenbibliotheken),
einer virtuellen Laufzeitumgebung (ähnlich der Java Virtual Maschine) und
einer Entwicklungsumgebung (Visual Studio .NET). .NET unterstützt mehrere
Programmiersprachen. Dazu gehören C#, C++, J# und Visual Basic.
ACL Eine Access Control List ist eine Liste mit Zugriffsrechten. Anhand dieser
Listen erfolgt die Zugriffsteuerung auf die Ressourcen des IT-Systems.
Anhand der ACLs entscheidet das System, welchen Zugriff ein Benutzer
auf eine Ressource, zum Beispiel ein Verzeichnis, hat.
ActiveX Sammelbegriff für eine von Microsoft eingeführte Technologie, die (inter)aktive
Inhalte auf Webseiten ermöglicht. Der Browser lädt ActiveX-
Programmteile vom Server herunter und führt sie auf dem PC des Benutzers
aus. ActiveX wurde von Microsoft als Alternative zu Java-Applets
entwickelt.
ADO ADO steht für Active Data Objects und ist eine High-Level Schnittstelle
(zum Beispiel aus Visual Basic) für den allgemeinen Datenzugriff von Microsoft
über einen OLE DB Provider (zum Beispiel für SQL Server, ODBC,
Oracle, Active Directory Service, u.a.). ADO enthält Objekte für das Erstellen
einer Verbindung zu einer Datenquelle, für Lese-, Update-, Schreib-
und Löschoperationen.
API Application Programming Interface (Definierte Programmierschnittstelle,
die für die Integration und Erweiterung genutzt werden kann)
ASP Steht für Active Server Pages; ist das Microsoft-Konzept für die serverseitige
Generierung (zum Beispiel mit JavaScript, Visual Basic Script) dynamischer
Web-Seiten (s.a. JSP).
ATM Asynchronous Transfer Mode (ATM) ist eine Technologie, bei der der Datenverkehr
in kleine Pakete, Zellen genannt, mit fester Länge (53 Byte)
codiert und über asynchrones Zeitmultiplexing übertragen wird. Die Zellen-Technik
hat im Vergleich zu Übertragungstechniken mit variabler Paketgröße
(zum Beispiel Ethernet) den Vorteil, dass die Zellen durch sogenanntes
Zell-Relay (ähnlich Frame Relay) effizienter weitergeleitet werden
können.
BOOTP Das Bootstrap Protocol (BOOTP) dient dazu, einem Computer in einem
TCP/IP-Netzwerk eine IP-Adresse und eine Reihe von weiteren Parametern
zuzuweisen.
Verwendet wird BOOTP zum Beispiel zur Einstellung der Netzwerkadresse
von Terminals und plattenlosen Workstations, die ihr Betriebssystem
von einem Bootserver beziehen. Die Übertragung des Betriebsprogramms
geschieht dann üblicherweise über das TFTP-Protokoll. Daneben können
einige Peripheriegeräte wie beispielsweise Netzwerkdrucker das BOOTP-
Protokoll zur Ermittlung ihrer IP-Adresse und Netzwerkkonfiguration (Sub-
Seite 521

netz/Gateway) verwenden.
Früher wurde das RARP-Protokoll zur Ermittlung der IP-Adresse bei plattenlosen
Geräten verwendet. Im Gegensatz zu RARP, das ausschließlich
die IP-Adresse liefert, besitzt BOOTP eine ganze Reihe von Parametern,
insbesondere können Subnetzmaske, Gateway sowie Bootserver übermittelt
werden. Zur Konfiguration von Workstations und PCs reichen diese
jedoch nicht aus, da hier zusätzliche Einstellungen wie Drucker, Zeitserver
und andere nötig sind. Das DHCP-Protokoll stellt eine Erweiterung der
BOOTP-Parameter dar.
C# Von Microsoft auf Basis von C und C++ entwickelte objektorientierte Programmiersprache.
CGI Das Common Gateway Interface ist die Urvariante der Web-Server-
Schnittstellen. Praktisch jeder aktuelle Web-Server unterstützt dieses
Interface. Anwendungen, die über CGI arbeiten, können mit verschiedenen
Programmiersprachen entwickelt werden. Neben Interpretersprachen
wie beispielsweise PERL können auch kompilierte Anwendungen, die in C
oder C++ geschrieben sind, verwendet werden.
COM Das Component Object Model ist ein Software-Standard von Microsoft,
mit dessen Hilfe die Kommunikation zwischen Prozessen und Programmen
realisiert werden kann. COM definiert dazu eine objektorientierte
Schnittstelle, mit der ein Programm oder eine Software-Komponente
Dienste zur Verfügung stellt.
CORBA CORBA steht für Common Object Request Broker Architecture und wurde
mit dem Ziel geschaffen, eine orts-, plattform- und implementationsunabhängige
Kommunikation zwischen Applikationen zu ermöglichen. CORBA
ist ein offener Standard, der durch die Object Management Group (OMG)
definiert wird.
DCOM Das Distributed Component Object Model ist eine Variante des Microsoft-
Standards COM. Über das Netzwerk können mit DCOM Dienste einer
Software verteilt zur Verfügung gestellt werden. DCOM verwendet zur
Realisierung RPC (Remote Procedure Calls), um mittels Nachrichtenaustausch
Funktionen auf einem anderen Computer aufzurufen.
DDE Dynamic Data Exchange ist eine Technik unter Windows, welche es Anwenderprogrammen
ermöglicht, Daten miteinander auszutauschen. Der
Datenaustausch selbst erfolgt dabei dynamisch. Wird eine der mittels
DDE verbundenen Dateien geändert, erfolgt die Übernahme der Änderung
in alle mit der betreffenden Datei kommunizierenden Dateien automatisch.
DHCP Das Dynamic Host Configuration Protocol schafft die Grundlage zur dynamischen
Vergabe von IP-Adressen. Der DHCP-Client erhält von zentralen
DHCP-Servern dynamisch eine IP-Adresse. Neben den IP-Adressen
können dem Client noch weitere Konfigurationsparameter übergeben
werden.
Seite 522

DNS Das Domain Name System ist ein hierarchisch aufgebautes System für
die Vergabe von Namen für an das Internet/Intranet angeschlossene
Rechner.
DTD Dokument-Typ-Definitionen definieren formal die Struktur eines XML-
Dokuments. Sie geben die Syntax vor, die für einen bestimmten Dokument-Typ
(und somit auch für ein bestimmtes Datenformat) gelten sollen.
Emulation Fähigkeit eines Systems beziehungsweise eines Programms, die Arbeitsweise
eines anderen Computersystems mit Hardware- oder Softwaremitteln
nachzuahmen.
Failover Ist die spezifische Betriebsweise von Hard- oder Software, z. B. einer Datenbank,
eines Servers oder eines Netzwerks, die so konfiguriert sind,
dass ihre Dienste bei einem vorübergehenden Systemausfall automatisch
von einem System mit ähnlicher oder gleicher Funktionsweise übernommen
werden.
GGO Die Bundesregierung hat am 26. Juli 2000 die neue Gemeinsame Geschäftsordnung
der Bundesministerien (GGO) beschlossen. Die Zusammenarbeit
und Organisation der Bundesministerien sowie die Vorbereitung
von Gesetzesentwürfen werden damit umfassend modernisiert. Verwaltungsabläufe
werden künftig schneller und einfacher. Neu aufgenommen
sind die erweiterten Möglichkeiten für den Einsatz moderner Informationstechnik.
Die novellierten Regelungen setzen zudem auf zeitgemäße
Steuerungs- und Führungsinstrumente, wie sie aus der Wirtschaft bekannt
sind.
HTML Hypertext Markup Language – der offene Standard beziehungsweise das
Dateiformat für die Darstellung von Inhalten im Internet beziehungsweise
Intranet.
HTTP Standard für die elektronische Interaktion bei der Übertragung von Web-
Dokumenten ins Internet.
IMAP Mit dem Internet Mail Access Protocol lassen sich E-Mail-Postfächer verwalten.
Im Gegensatz zu POP3 verwaltet IMAP die Mail auf dem Server.
Beim Start des Mail-Programms werden standardmäßig nur die Kopfdaten
(Absender, Betreff und Eingangszeit) geladen. Jetzt können Mails vom
Adressaten gezielt ausgewählt und komplett heruntergeladen werden. Eine
Mail, die auf dem Server verbleiben soll, kann dort in besonderen Ordnern
abgelegt werden.
IPsec Ein Standard für Netzwerksicherheitslösungen, der sich vor allem für die
Implementierung von VPNs sowie den Fernzugriff auf private Netzwerke
über Wählverbindungen eignet.
IPv6 Ist die neue Version 6 des Internet-Protokolls (IP), bei der die IP-Adressen
aus 128 statt 32 Bit wie beim IPv4 bestehen sollen. U. a. werden dadurch
mehr Adressierungsmöglichkeiten für Websites geschaffen.
IPX Ein von der Firma Novell definierter Standard für die Datenübertragung.
Seite 523

J2EE Java 2 Enterprise Edition (J2EE) ist ein Oberbegriff für verschiedene Konzepte
und Java-basierte Komponenten, die insbesondere bei dem Betrieb
von J2EE-Application-Servern genutzt werden.
Neben der Client-seitigen Kommunikation mit J2EE-Application-Servern,
die meist mit einem Browser erfolgt, unterstützt J2EE auch eine Kommunikation
zwischen Anwendungskomponenten (Applications). Für die anwendungsseitige
Kommunikation können verschiedene Techniken eingesetzt
werden: XML-basierte Web-Services, CORBA und direkte Aufrufe
aus Java-Programmen.
Java Beans Java Beans sind wieder verwendbare Softwarekomponenten, die in Java
realisiert wurden.
Java Script Eine ursprünglich von der Firma Netscape definierte Skriptsprache zur
Verknüpfung von Programmcode mit statischen HTML-Seiten. In der Regel
erfolgt die Ausführung des Codes im Browser des Benutzers.
Java Von SUN Microsystems entwickelte objektorientierte Programmiersprache,
die vor allem im Bereich der Internettechnologie genutzt wird. Aus
den Quelltexten wird durch einen sogenannten Compiler ein plattformunabhängiger
Zwischencode übersetzt. Dieser kann von einem geeigneten
Interpreter auf beliebigen Rechnern ausgeführt werden. Dadurch können
Java-Programme auf allen Rechnerplattformen laufen, für die ein
passendes Interpreter-Programm existiert.
JDBC Die Java Database Connectivity bietet einen Mechanismus zur Kommunikation
mit bestehenden Datenbanken. Dabei bilden Treiber die Schnittstelle
zwischen dem Java-Programm und der Datenbank.
JSP JavaServer-Pages sind HTML-Dateien mit eingebettetem Java-
Programmcode, die mit Hilfe einer JSP-Engine einmalig in Servlets umgewandelt
und anschließend im Webserver ausgeführt werden. Das Ergebnis
wird dann im normalen HTML-Format an den Client gesendet (s. a.
ASP).
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 erfolgt eine einmalige Anmeldung an einem Key
Distribution Center (KDC, gelegentlich auch als Kerberos Domänencontroller
bezeichnet), welches dem Benutzer zur Authentifizierung gegenüber
den von ihm genutzten Diensten ein Ticket mit definierter Gültigkeitsdauer
zur Verfügung stellt.
LAMP Eine auf Linux, Apache, MySQL und PHP beziehungsweise PERL oder
Python basierende Open Source Plattform für Web-Entwickler und Webanwendungen.
LDAP Das Lightweight Directory Access Protocol (X.509) ist eine vereinfachte
Version des DAP (X.500). Mit LDAP werden Zugriffe auf Verzeichnisdienste
realisiert, mit denen z. B. Benutzermerkmale abgefragt werden
können.
Seite 524

Makro Eine Kombination einzelner Anweisungen beziehungsweise eine Folge
von Befehlen und Vorgängen, die festgehalten und gespeichert werden
kann. Wird ein Makro aufgerufen, werden die Vorgänge und Aktionen in
der entsprechenden Reihenfolge automatisch wieder abgearbeitet.
MP3 Standardformat für komprimierte Audiodateien, das im Rahmen der
MPEG vom Fraunhofer-Institut entwickelt wurde und sich vor allem im
Internet verbreitet hat.
MTA Softwarekomponente, die für die Verteilung von E-Mails zwischen verschiedenen
Computersystemen zuständig ist. Ein MTA nimmt Nachrichten
sowohl von anderen MTAs als auch von MUAs entgegen und leitet diese
an die entsprechenden Empfänger weiter.
MUA Der Mail User Agent ist das E-Mail-Programm, das es dem Benutzer ermöglicht,
auf elektronische Nachrichten zuzugreifen, sie anzuzeigen, zu
lesen, zu bearbeiten und zu verwalten.
NDS Die NDS (Novell Directory Services) ist ein hochskalierbarer und redundanter
Verzeichnisdienst, der von Novell mit seinem Betriebssystem Net-
Ware 4.x eingeführt wurde.
NTP Das Network Time Protocol dient dazu die Uhrzeiten verschiedener Computer
über ein Netzwerk zu synchronisieren. Das NTP ermöglicht eine millisekunden
genaue Einstellung der Rechnerzeiten; ist insbesondere sehr
wichtig für Vorgänge, an denen gleichzeitig mehrere Rechner beteiligt
sind.
ODBC Standardisiertes Verfahren, das den Zugriff auf Datenbanken gewährleistet.
Beispielsweise können Anwendungsprogramme auf Datenbanken unterschiedlichsten
Art mittels ODBC zugreifen.
OLE OLE steht für Objekt Linking and Embedding und ist eine Methode zur
gemeinsamen Nutzung von Informationen. Dabei können die Informationen
in unterschiedlichen Formaten vorliegen und mit unterschiedlichen
Anwendungen erstellt worden sein. Es werden Daten aus einem Quelldokument
mit einem Zieldokument verknüpft beziehungsweise in dieses eingebettet.
Wenn die eingebetteten Daten im Zieldokument markiert werden,
wird wieder die Quell-Anwendung geöffnet, damit die Daten in gewohnter
Umgebung mit den notwendigen Funktionen bearbeitet werden
können. Man spricht auch von „OLE Compound Documents".
OpenLDAP OpenLDAP ist eine Implementierung des LDAP-Protokolls als freie Software.
OpenLDAP wird bei den meisten verbreiteten und aktuellen Linux-
Distributionen zur Verfügung gestellt. Da OpenLDAP den LDAP-Standard
verfolgt, ist es mit OpenLDAP möglich, eine zentrale Benutzerdatenverwaltung
aufzubauen und zentral zu warten.
OSI Internationaler Standard für den Datenaustausch in Netzwerken. OSI wird
in sieben Schichten dargestellt, die jeweils die einzelnen Kommunikationsprozesse
beschreiben.
Seite 525

PDF Plattformübergreifendes Dokumentenformat der Firma Adobe Systems,
mit welchem sich aus Texten, Bildern und Grafiken bestehende Dokumente
erzeugen und darstellen lassen.
Perl Die Practical Extraction and Report Language ist eine frei verfügbare
Programmiersprache, die besonders häufig zum Schreiben von CGI-
Skripten verwendet wird. Durch die vielfältigen Möglichkeiten, insbesondere
auch in der Verarbeitung von Strings, werden Perl-Programme auch
häufig für administrative Routineaufgaben verwendet.
PHP Serverseitige Skriptsprache zur Erstellung datenbankgestützter und dynamischer
Webinhalte.
POP3 Beim Arbeiten mit Post Office Protocol in der Version 3 lädt das lokale
Mail-Programm (Client) grundsätzlich nach dem Start alle neue Post vom
Mail-Server auf den lokalen Computer. Normalerweise ist der Client so
konfiguriert, dass die Mail nach dem Download auf dem Server gelöscht
wird.
POSIX Auf UNIX basierender Schnittstellen-Standard gemäß IEEE, der von allen
UNIX-Derivaten unterstützt wird.
PostScript Von der Firma Adobe entwickelte Seitenbeschreibungssprache für die
Steuerung von Druckern. postscriptfähige Drucker erhalten ihre Druckbefehle
von dem jeweiligen Anwendungsprogramm in Form einer standardisierten
Anweisungsfolge; diese interpretiert der entsprechende Drucker
und setzt sie in einen Druckvorgang um.
Prozess Mit dem Begriff Prozess wird in der Informationstechnik der Ablauf eines
Computerprogrammes auf einem Prozessor bezeichnet. Einem Prozess
sind ein Speicherraum und weitere Betriebssystemmittel zugeordnet. Ein
Prozess kann aus einem oder mehreren Threads bestehen, die sich innerhalb
eines Prozesses den Speicher und andere, betriebssystemabhängige
Ressourcen wie Dateien und Netzwerkverbindungen teilen, jedoch
sonst unabhängig voneinander ablaufen. Ein Prozess kann auch aus
genau einem Thread bestehen, wenn bei dem Programmablauf keine Parallelverarbeitung
vorgesehen ist.
RAS Ist die Microsoft-Bezeichnung für Bereitstellung von Dial-Up-Diensten innerhalb
des Microsoft-Betriebssystems.
RDBMS In einem relationalen Datenbank-Managementsystem liegen die Informationen
der Datenbank in Tabellen vor, die zueinander in Relation stehen.
Organisiert nach dem relationalen Modell.
Server Ein Prozess, ein Programm oder ein Computer zur Bearbeitung der Anforderungen
eines Clients beziehungsweise zur Bereitstellung von Diensten,
die von einem Client genutzt werden können.
SQL Stellt die Standard-Abfragesprache für relationale Datenbanken dar.
SSH Ein Protokoll beziehungsweise eine entsprechende Implementierung
(Unix/Linux-Systemen) dieses Protokolls, das den sicheren Zugriff auf an
Seite 526

ein Netzwerk angeschlossene Rechner gewährleistet. Die Implementierung
bietet eine gesicherte Datenübertragung auf ungesicherten Verbindungen
an.
SSL Eine von der Firma Netscape entwickelte Verschlüsselungstechnologie
und ein Protokoll für die sichere Kommunikation beziehungsweise Dokumentenübermittlung
zwischen Webbrowsern und Webservern.
TCP/IP Ein Satz von Netzwerkprotokollen, die innerhalb eines Netzwerkes verwendet
werden, um dem Benutzer eine Reihe von Diensten zur Verfügung
zu stellen. TCP (Transmission Control Protocol) und IP (Internet
Protocol) bieten die Grundlagen über die Formulierung der einzelnen Datenpakete,
deren Versendung und Zustellung.
Thread siehe Prozess
UNO UNO ist ein Komponentenmodell, welches Interoperabilität zwischen unterschiedlichen
Programmiersprachen, unterschiedlichen Objektmodellen,
unterschiedlicher Maschinenarchitekturen und unterschiedlichen Prozessen
schafft. Diese kann in einem LAN oder über das Internet hergestellt
werden. UNO wird von der OpenOffice Community zusammen mit den
Entwicklungslabors von Sun Microsystems entwickelt. Die Basis-
Bibliotheken von UNO sind unabhängig von OpenOffice und StarOffice
und können als Framework für andere Anwendungen eingesetzt werden.
UNO ist frei verfügbar und steht unter der LGPL-Lizenz. Derzeit werden
Java, C und C++ auf Windows, Linux und Solaris unterstützt. (siehe auch
http://udk.openoffice.org/common­/man/uno.html)
URL Der Uniform Resource Locator beschreibt eine eindeutige Adresse im
World Wide Web, z. B. „http://www.kbst.bund.de".
VBA Visual Basic for Applications
W3C Das World Wide Web Consortium koordiniert die Entwicklung des WWW
und die Standardisierung von HTML, XML und deren Derivate.
WebDAV Das Web-based Distributed Authoring and Versioning ist eine Erweiterung
des Hypertext Transfer Protocol (HTTP) und bietet eine standardisierte
Unterstützung für asynchrones, kollaboratives Erstellen von Inhalten über
das Internet beziehungsweise Intranet.
WINS Microsoft-System zur Namensauflösung innerhalb eines Netzwerkes
(Netzwerknamen IP-Adressen).
XML Eine Spezifikation für die Definition von Sprachen zur Formatierung von
Dokumenten. XML bietet eine strenge Trennung von Inhalten und Design.
XSLT Vom W3C empfohlene Sprache zur Erstellung von Stilvorlagen, die XML-
Strukturen regelbasiert in andere XML-Strukturen umwandeln, z. B. in eine
Seitenbeschreibungssprache wie HTML.
Seite 527

C Abbildungsverzeichnis
Abbildung 1: Struktur des Migrationsleitfaden .................................................................. 6
Abbildung 2: Vertragsverhältnisse ................................................................................. 44
Abbildung 3: Regelkreis der Wirtschaftlichkeitsbetrachtung ........................................... 76
Abbildung 4: Beispiel: Personalaufwendungen in den Migrationsphasen....................... 81
Abbildung 5: Beispiel: Gesamtpersonalaufwand ............................................................ 81
Abbildung 6: Beispiel Erhebungsbogen - Infrastruktur der Server .................................. 87
Abbildung 7: Beispiel Erhebungsbogen - Infrastruktur der Arbeitsplatz-Computer ......... 88
Abbildung 8: Beispiel Erhebungsbogen - Infrastruktur des Netzwerks ........................... 89
Abbildung 9: Beispiel Erhebungsbogen - Drucker-Infrastruktur ...................................... 89
Abbildung 10: Beispiel Erhebungsbogen - Erhebungsbogen für
Serverinfrastrukturdienste ...................................................................... 91
Abbildung 11: Beispiel Erhebungsbogen - Standardsoftware ........................................ 91
Abbildung 12: Beispiel Erhebungsbogen - Office ........................................................... 92
Abbildung 13: Beispiel Erhebungsbogen - IT-Fachverfahren – Architektur und Nutzer .. 94
Abbildung 14: Beispiel Erhebungsbogen - IT-Fachverfahren – Client-
/Serverbetriebssysteme .......................................................................... 94
Abbildung 15: Beispiel Erhebungsbogen - IT-Fachverfahren – Datenbanksysteme und
Applikationsserver .................................................................................. 95
Abbildung 16: Beispiel Erhebungsbogen - IT-Fachverfahren – Benutzer-
/Rechteverwaltung und Schnittstellen ..................................................... 95
Abbildung 17: Beispiel Erhebungsbogen - IT-Fachverfahren – Hosting, Verfahrens-
Entwicklung und Ausprägung ................................................................. 96
Abbildung 18: Beispiel Erhebungsbogen - IT-Fachverfahren – Ausblick, Kosten und
Anmerkungen ......................................................................................... 97
Abbildung 19: Methodik WiBe Migrationen .................................................................. 104
Abbildung 20: WiBe - Beispielhafte WiBe Kalkulation 1, Einführungskosten/ -nutzen .. 120
Abbildung 21: Beispielhafte WiBe Kalkulation 2, Betriebskosten/ -nutzen.................... 121
Abbildung 22: Phasen eines Migrationsprozesses ....................................................... 140
Abbildung 23: Entscheidungsprozess zur Durchführung einer Migration ..................... 141
Abbildung 24: Beispiel einer sanften und stufenweisen Migration ................................ 145
Abbildung 25: Beispiel NT-Domänenstruktur ............................................................... 211
Abbildung 26: Beispiel Windows 2000 ......................................................................... 211
Abbildung 27: B-G-L-R Methode ................................................................................. 257
Seite 528

Abbildung 28: B-G-R Methode ..................................................................................... 258
Abbildung 29: Drucken unter CUPSF .......................................................................... 277
Abbildung 30: Allgemein: Drucken unter Windows ...................................................... 287
Abbildung 31: OpenGroupware-Architektur ................................................................. 311
Abbildung 32: Open-Xchange Architektur .................................................................... 316
Abbildung 33: eGroupWare-Architektur ....................................................................... 320
Abbildung 34: Technische Zusammenhänge in Zarafa ................................................ 323
Abbildung 35: LDAP-basierter grafischer Benutzer-Editor ........................................... 325
Abbildung 36: Scalix-Plattform ..................................................................................... 333
Abbildung 37: Scalix-Clientsysteme ............................................................................. 334
Abbildung 38: Scalix – Versionen/Funktionsüberblick .................................................. 335
Abbildung 39: Scalix- Integration ................................................................................. 336
Abbildung 40: Zusammenspiel der Server Rollen ........................................................ 338
Abbildung 41: Notes Architektur .................................................................................. 341
Abbildung 42: Architektur Mindquarry .......................................................................... 358
Abbildung 43: Beziehung zwischen MSS 3.0 und MOSS 2007 .................................... 365
Abbildung 44: logische Architektur – SharePoint ......................................................... 366
Abbildung 45: Topologien von Sharepoint Server Farmen ........................................... 366
Abbildung 46: Funktionalität von MOSS 2007 ............................................................. 371
Abbildung 47: Funktionalitäten der verschiedenen SharePoint Editionen .................... 372
Abbildung 48: Grundlegende SharePoint Site-Struktur ................................................ 374
Abbildung 49: Metadaten eines Dokumentes im Browser ............................................ 376
Abbildung 50: Word 2007 (Datei --> Eigenschaften) .................................................... 376
Abbildung 51: Workflow Tool - SharePoint Designer ................................................... 379
Abbildung 52: Workflow Entwicklung mit Visual Studio ................................................ 380
Abbildung 53: Template Management Module............................................................. 388
Abbildung 54: Funktionen von ICEcore OSS, Novell Teaming + Conferencing und
ICEcore Add-On Modulen .................................................................... 391
Abbildung 55: Architektur des Novell Teamingsoftwarepakets ..................................... 393
Abbildung 56: Enterprise Admin Portlet ....................................................................... 395
Abbildung 57: Architektur Novell Conferencing ............................................................ 396
Abbildung 58: Oberfläche der Administrationsschnittstelle zu Novell Conferencing ..... 398
Abbildung 59: Workflow gesteuerte Collaboration ....................................................... 399
Abbildung 60: Erweiterte Suche Novell Teaming ......................................................... 401
Seite 529

Abbildung 61: Zustandsübergänge im Novell Teaming Workflow ................................ 403
Abbildung 62: Grafische Darstellung eines Workflows in Novell Teaming .................... 403
Abbildung 63 Dokumente im HTML-Format darstellen ................................................ 404
Abbildung 64: Der Navigator in OpenOffice.org Writer................................................. 426
Abbildung 65: Natürlichsprachige Formeln in OpenOffice.org Calc.............................. 426
Abbildung 66: VBA in der Office Anwendung ............................................................... 442
Abbildung 67: Benutzeroberfläche für das Arbeiten mit XML-Schemas
in MS Word 2007.................................................................................. 446
Abbildung 68: Datensatz nach dem XML-Schema „Antrag Geburtsurkunde― ............... 447
Abbildung 69: Binär kodierte Excel Tabelle in altem WordprocessingML ..................... 450
Abbildung 70: Architektur des Dokumentengenerators ................................................ 463
Abbildung 71: Externe Datenfelder nach Export in MS-Word Dokument...................... 468
Abbildung 72: Komponenten des .NET-Frameworks ................................................... 474
Abbildung 73: Strukturelle Sicht - Mehrschichtenarchitektur ........................................ 478
Abbildung 74: Katalog monetäre Kriterien der WiBe für Migrationen
– Entwicklungs-/Einführungskosten und -nutzen .................................. 536
Abbildung 75: Katalog monetäre Kriterien der WiBe für Migrationen
– Betriebskosten und -nutzen ............................................................... 537
Abbildung 76: Katalog nicht-monetäre Kriterien der WiBe für Migrationen
– Dringlichkeit ....................................................................................... 538
Abbildung 77: Gewichtungsskala für Dringlichkeitskriterien ......................................... 538
Abbildung 78: Katalog nicht-monetäre Kriterien der WiBe für Migrationen
– Qualität/ Strategie .............................................................................. 539
Abbildung 79: Gewichtungsskala für Qualitätskriterien ................................................ 539
Abbildung 80: Matrix zur Soft- und Hardware-Kostenermittlung ................................... 540
Seite 530

D Tabellenverzeichnis
Tabelle 1: Auswirkungen von Integration und Standardisierung auf ausgewählte Ziele
einer Behörde ......................................................................................... 32
Tabelle 2: Übersicht der Komponenten und Protokolle der Beispiele für
Integrationslösungen .............................................................................. 38
Tabelle 3: Beurteilung des Integrationsgrades der Beispiellösungen ............................. 39
Tabelle 4: Relevanz der OSS-Lizenzen für Nutzer ........................................................ 45
Tabelle 5: Vertragsverhältnisse Nutzer-Zwischenhändler .............................................. 47
Tabelle 6: Anwendbares Recht ...................................................................................... 49
Tabelle 7 Urheberrechtliche Fragen: ............................................................................. 57
Tabelle 8: Vertragliche Ansprüche auf Haftung und Gewährleistung gegen den
Zwischenhändler .................................................................................... 62
Tabelle 9: Migrationsphasen.......................................................................................... 80
Tabelle 10: Erhebungsstruktur Preisinformationen Hard-/ Software - Server ................. 82
Tabelle 11: Erhebungsstruktur Preisinformationen Hard-/ Software -
Arbeitsplatzcomputer .............................................................................. 83
Tabelle 12: Erhebungsstruktur Preisinformationen Hard-/ Software -
Arbeitsplatzcomputer .............................................................................. 86
Tabelle 13: Klassifizierung von Dokumentvorlagen und Makros .................................... 92
Tabelle 14: Informationscluster für die Erhebung der IT-Fachverfahren......................... 93
Tabelle 15: Punktbewertungsskala Unterstützungskontinuität Altsystem ..................... 122
Tabelle 16: Punktbewertungsskala Fehler und Ausfälle („downtime―) .......................... 123
Tabelle 17: Punktbewertungsskala Wartungsprobleme, Personalengpässe ................ 123
Tabelle 18: Punktbewertungsskala Ausbau-/Erweiterungsgrenzen .............................. 123
Tabelle 19: Punktbewertungsskala Interoperabilität, Schnittstellenprobleme
aktuell/zukünftig ................................................................................... 124
Tabelle 20: Punktbewertungsskala Bedienbarkeit und Ergonomie
(Benutzerfreundlichkeit)........................................................................ 124
Tabelle 21: Punktbewertungsskala Einhaltung gesetzlicher Vorgaben ........................ 124
Tabelle 22: Punktbewertungsskala Erfüllung von Datenschutz/ -sicherheit .................. 125
Tabelle 23: Punktbewertungsskala Ordnungsmäßigkeit der Arbeitsabläufe ................. 126
Tabelle 24: Punktbewertungsskala Erfüllung von Auflagen und Empfehlungen ........... 126
Tabelle 25: Punktbewertungsskala Bedeutung innerhalb IT- Rahmenkonzept ............ 127
Seite 531

Tabelle 26: Punktbewertungsskala Einpassung in den IT-Ausbau der Bundesverwaltung
insgesamt ............................................................................................. 128
Tabelle 27: Punktbewertungsskala Folgewirkung für Kommunikationspartner ............. 128
Tabelle 28: Punktbewertungsskala Pilot-Projekt-Charakter des IT-Investitionsvorhabens
............................................................................................................. 129
Tabelle 29: Punktbewertungsskala Nachnutzung bereits vorhandener Technologien .. 130
Tabelle 30: Punktbewertungsskala Plattform-/Herstellerunabhängigkeit ...................... 131
Tabelle 31: Punktbewertungsskala Qualitätsverbesserung bei der Aufgabenabwicklung
............................................................................................................. 132
Tabelle 32: Punktbewertungsskala Beschleunigung von Arbeitsabläufen und -prozessen
............................................................................................................. 132
Tabelle 33: Punktbewertungsskala Einheitliches Verwaltungshandeln ........................ 133
Tabelle 34: Punktbewertungsskala Verständlichkeit und Nachvollziehbarkeit .............. 133
Tabelle 35: Punktbewertungsskala Imageverbesserung .............................................. 134
Tabelle 36: Punktbewertungsskala Attraktivität der Arbeitsbedingungen ..................... 134
Tabelle 37: Punktbewertungsskala Qualifikationssicherung/ -erweiterung ................... 135
Tabelle 38: Apache-Module ......................................................................................... 178
Tabelle 39: Funktionen von OpenLDAP unter Linux .................................................... 192
Tabelle 40: RFCs in denen DNS spezifiziert wird ........................................................ 227
Tabelle 41: Übersicht der unterstützten DNS Resource Record Typen ....................... 229
Tabelle 42: Übersicht der DHCP Optionen .................................................................. 233
Tabelle 43: POSIX-Berechtigungen und Windows-Aggregationen............................... 245
Tabelle 44: POSIX- und Windowsberechtigungen ....................................................... 246
Tabelle 45: Eigenschaften der Windows Sammelberechtigungen................................ 255
Tabelle 46: Windows Attribute ..................................................................................... 255
Tabelle 47: Vergleich der Dateiserver .......................................................................... 264
Tabelle 48: Lizensierung der Microsoft System-Management-Komponenten............... 301
Tabelle 49: Mögliche Komponenten der Open-Xchange-Lösung ................................. 317
Tabelle 50: Auswahl an eGroupWare-Modulen ........................................................... 321
Tabelle 51: Zarafa Komponenten ................................................................................ 324
Tabelle 52: Zentrale Kolab-Server-Komponenten ........................................................ 327
Tabelle 53: Optionale Kolab Server-Komponenten ...................................................... 327
Tabelle 54: Mögliche Migrations- und Transitionspfade ............................................... 348
Tabelle 55: Funktionen von Mindquarry ....................................................................... 363
Tabelle 56: SharePoint-Historie ................................................................................... 364
Seite 532

Tabelle 57: Beispiele für Autorisierungsgruppen in SharePoint ................................... 369
Tabelle 58: Produktfunktionsmatrix.............................................................................. 373
Tabelle 59: Funktionen O3Spaces Workplace ............................................................. 389
Tabelle 60: O3Space – Funktionen in den verschiedenen Editionen ........................... 390
Tabelle 61: Novell Teaming Funktionen....................................................................... 400
Tabelle 62: Novell Conferencing Funktionen ............................................................... 405
Tabelle 63: Systemkomponenten und –voraussetzungen Lotus Quickr 8 .................... 410
Tabelle 64: Funktionen von Lotus Quickr Services für Domino .................................... 416
Tabelle 65: Funktionen von Lotus Quickr Services für WebSphere Portal ................... 420
Tabelle 66: Datei-Endungen von ODF-Dokumenten .................................................... 430
Tabelle 67: Import- und Exportmöglichkeiten in OOo /SO ........................................... 430
Tabelle 68: Überblick der Charakteristika von OOo 1/SO 7 und OOo 2/SO 8 .............. 435
Tabelle 69: Anwendungen in den jeweiligen Suiten für MS Office 2007;...................... 437
Tabelle 70: Microsoft Office Versionen und zugehörige Versionen von VBA ............... 442
Tabelle 71: Überblick der Charakteristika von MS Office 2007 und Office 97 - 2003 ... 451
Tabelle 72: Mögliche Konvertierungsprobleme ............................................................ 461
Tabelle 73: Kompatibilitätsmodus bei MS Office 2007 ................................................. 465
Tabelle 74: Verfügbare Dokumentenformatfilter in SO 8/OOo 2 .................................. 470
Tabelle 75: Vorteile von Terminal-Servern und Thin Clients ........................................ 491
Tabelle 76: Ausgewählte Nachteile von Terminal-Servern und Thin Clients ................ 492
Tabelle 77: Übersicht der Funktionen verschiedener Terminalserverlösungen ............ 502
Seite 533

E Anhang –WiBe für Migrationen
1 Kriterienkatalog WiBe für Migrationen
WiBe
Migrationen
Bezeichnung Kriterien für Migrationen
Monetäre Kriterien WiBe
1 Entwicklungskosten/ Einführungskosten und -nutzen
1.1 Zur Ermittlung der Entwicklungskosten
1.1.1 Planungs- und Entwicklungskosten
1.1.1.1 Personalkosten (eigenes Personal)
1.1.1.2 Kosten Externer Beratung
1.1.1.3 Kosten der Entwicklungsumgebung
1.1.1.4 Sonstige Kosten für Sach-/Hilfsmittel
1.1.1.5 Reisekosten (eigenes Personal)
1.1.2 Systemkosten
1.1.2.1 Hardwarekosten
1.1.2.1.1 Host/ Server, Netzbetrieb
1.1.2.1.2 Arbeitsplatzrechner
1.1.2.2 Softwarekosten
1.1.2.2.1 Kosten für Entwicklung bzw. Beschaffung von Software
1.1.2.2.2 Kosten für Anpassung von Software und/oder Schnittstellen, Treiber
1.1.2.2.3 Kosten für Evaluierung, Zertifizierung und Qualitätssicherung
1.1.3 Kosten der Systemeinführung
1.1.3.1 System- und Integrationstest(s)
1.1.3.2 Kosten der Systeminstallation
1.1.3.3 Übernahme von Datenbeständen
1.1.3.4 Erstschulung Anwender und IT-Fachpersonal
1.1.3.5 Einarbeitungskosten Anwender und IT-Fachpersonal
1.1.3.6 Sonstige Umstellungskosten
1.2 Entwicklungs-/Einführungsnutzen aus Ablösung des alten
Verfahrens
1.2.1 Einmalige Kosteneinsparungen (Vermeidung von Erhaltungs-/
Erweiterungskosten Altsystem)
1.2.2 Einmalige Erlöse (aus Verwertung Altsystem)
Abbildung 74: Katalog monetäre Kriterien der WiBe für Migrationen – Entwicklungs-
/Einführungskosten und -nutzen
Seite 534

WiBe
Migrationen
Bezeichnung Kriterien für Migrationen
Monetäre Kriterien WiBe
1 Entwicklungskosten/ Einführungskosten und -nutzen
1.1 Zur Ermittlung der Entwicklungskosten
1.1.1 Planungs- und Entwicklungskosten
1.1.1.1 Personalkosten (eigenes Personal)
1.1.1.2 Kosten Externer Beratung
1.1.1.3 Kosten der Entwicklungsumgebung
1.1.1.4 Sonstige Kosten für Sach-/Hilfsmittel
1.1.1.5 Reisekosten (eigenes Personal)
1.1.2 Systemkosten
1.1.2.1 Hardwarekosten
1.1.2.1.1 Host/ Server, Netzbetrieb
1.1.2.1.2 Arbeitsplatzrechner
1.1.2.2 Softwarekosten
1.1.2.2.1 Kosten für Entwicklung bzw. Beschaffung von Software
1.1.2.2.2 Kosten für Anpassung von Software und/oder Schnittstellen, Treiber
1.1.2.2.3 Kosten für Evaluierung, Zertifizierung und Qualitätssicherung
1.1.3 Kosten der Systemeinführung
1.1.3.1 System- und Integrationstest(s)
1.1.3.2 Kosten der Systeminstallation
1.1.3.3 Übernahme von Datenbeständen
1.1.3.4 Erstschulung Anwender und IT-Fachpersonal
1.1.3.5 Einarbeitungskosten Anwender und IT-Fachpersonal
1.1.3.6 Sonstige Umstellungskosten
1.2 Entwicklungs-/Einführungsnutzen aus Ablösung des alten
Verfahrens
1.2.1 Einmalige Kosteneinsparungen (Vermeidung von Erhaltungs-/
Erweiterungskosten Altsystem)
1.2.2 Einmalige Erlöse (aus Verwertung Altsystem)
Abbildung 75: Katalog monetäre Kriterien der WiBe für Migrationen – Betriebskosten und -nutzen
Seite 535

WiBe
Migrationen
Bezeichnung Kriterien für Migrationen
Nicht-Monetäre Kriterien WiBe
3 Dringlichkeits-Kriterien
3.1 Ablösedringlichkeit Altsystem
3.1.1 Unterstützungs-Kontinuität Altsystem
3.1.2 Stabilität Altsystem
3.1.2.1 Fehler und Ausfälle („downtime―)
3.1.2.2 Wartungsprobleme, Personalengpässe
3.1.3 Flexibilität Altsystem
3.1.3.1 Ausbau-/Erweiterungsgrenzen
3.1.3.2 Interoperabilität, Schnittstellenprobleme aktuell/zukünftig
3.1.3.3 Bedienbarkeit und Ergonomie (Benutzerfreundlichkeit)
3.2 Einhaltung von Verwaltungsvorschriften und Gesetzen
3.2.1 Einhaltung gesetzlicher Vorgaben
3.2.2 Erfüllung Datenschutz/ -sicherheit
3.2.3 Ordnungsmäßigkeit Arbeitsabläufe
3.2.4 Erfüllung von Auflagen und Empfehlungen
Abbildung 76: Katalog nicht-monetäre Kriterien der WiBe für Migrationen – Dringlichkeit
Nr. Kriterien "D"
3 Dringlichkeits-Kriterien 100
3.1 Ablösedringlichkeit Altsystem 75
3.1.1 Unterstützungs-Kontinuität Altsystem 20
3.1.2 Stabilität Altsystem
3.1.2.1 Fehler und Ausfälle („downtime―) 15
3.1.2.2 Wartungsprobleme, Personalengpässe 15
3.1.3 Flexibilität Altsystem
3.1.3.1 Ausbau-/Erweiterungsgrenzen 10
3.1.3.2 Interoperabilität, Schnittstellenprobleme aktuell/zukünftig 10
3.1.3.3 Bedienbarkeit und Ergonomie (Benutzerfreundlichkeit) 5
3.2 Einhaltung von Verwaltungsvorschriften und Gesetzen 25
3.2.1 Einhaltung gesetzlicher Vorgaben 5
3.2.2 Erfüllung Datenschutz/ -sicherheit 10
3.2.3 Ordnungsmäßigkeit Arbeitsabläufe 5
3.2.4 Erfüllung von Auflagen und Empfehlungen 5
Abbildung 77: Gewichtungsskala für Dringlichkeitskriterien
Seite 536
Gewichtung für
Migrationen

WiBe
Migrationen
Bezeichnung Kriterien für Migrationen
Nicht-Monetäre Kriterien WiBe
3 Dringlichkeits-Kriterien
4 Qualitativ-Strategische -Kriterien
4.1 Priorität des IT-Vorhabens
4.1.1 Bedeutung innerhalb IT-Rahmenkonzept
4.1.2 Einpassung in den IT-Ausbau der Bundesverwaltung
insgesamt
4.1.3
Folgewirkung für Kommunikationspartner
4.1.4 4.1.3 Pilot-Projekt-Charakter des IT-Investitionsvorhabens
4.1.5 4.1.4 Nachnutzung bereits vorhandener Technologien
4.1.6 4.1.5 Plattform-/Herstellerunabhängigkeit
Herstellerunabhängigkeit
4.2 Qualitätszuwachs bei Erledigung von Fachaufgaben
4.2.1 Qualitätsverbesserung bei der Aufgabenabwicklung
(Leistungssteigerung bei …)
4.2.2 Beschleunigung von Arbeitsabläufen und -prozessen
4.2.3 Einheitliches Verwaltungshandeln
Erhöhung von Verständlichkeit und Nachvollziehbarkeit
4.2.4 Imageverbesserung
4.3 Mitarbeiterbezogene Effekte
4.3.1 Attraktivität der Arbeitsbedingungen
4.3.2 Qualifikationssicherung/ -erweiterung
Abbildung 78: Katalog nicht-monetäre Kriterien der WiBe für Migrationen – Qualität/ Strategie
Nr.
Kriterien "Q"
4 Qualitativ-Strategische -Kriterien 100
4.1 Priorität des IT-Vorhabens 40
4.1.1 Bedeutung innerhalb IT- Rahmenkonzept 5
4.1.2 Einpassung in den IT-Ausbau der Bundesverwaltung insgesamt 5
4.1.3 Folgewirkung für Kommunikationspartner 5
4.1.4 Pilot-Projekt-Charakter des IT-Investitionsvorhabens 10
4.1.5 Nachnutzung bereits vorhandener Technologien 5
4.1.6 Herstellerunabhängigkeit 10
Qualitätszuwachs bei Aufgabenerledigung 50
4.2.1 Qualitätsverbesserung bei der Aufgabenabwicklung 15
4.2.2 Beschleunigung von Arbeitsabläufen und -prozessen 10
4.2.3 Einheitliches Verwaltungshandeln 10
4.2.4 Erhöhung von Verständlichkeit und Nachvollziehbarkeit 10
4.2.5 Imageverbesserung 5
Mitarbeiterbezogene Effekte 10
4.3.1 Attraktivität der Arbeitsbedingungen 5
4.3.2 Qualifikationssicherung/ -erweiterung 5
Abbildung 79: Gewichtungsskala für Qualitätskriterien
Seite 537
Gewichtung für
Migrationen

2 Matrix zur Soft- und Hardware-Kostenermittlung
M ig ra tion s o bje k t S yste m ty p P ro d u k t K o m p o ne n te n
… B e ispie le … In ve stitio n s-
K o ste n
S erve r
S o ftw a re
H a rd w a re
In fra stru ktu rd ie n ste D ire cto ry N D S
F ile N e tw a re 4 .1 1
D ruc k Je t D ire ct
D N S / D H C P / B O O T P B IN D
S y ste m m a n a g em en t S o ftw a re v e rte ilu n g
In ve n ta risie ru ng
H e lp D e sk
S y ste m ü b e rw a ch u n g
N e tzw e rk ü be rw a ch u n g
G ro u p w a re & M e ss ag ing G ro u p w are eG ro u p w a re
M a il S u se E m a il 2
T e rm in a lse rve r
A rb e its p la tzc o m p u te r
S o ftw a re
B e trie b ssy ste m B e trie b ssy ste m W in d o w s N T 4 .0
S ta n d a rd so ftw a re D o ku m e n te n a us ta us ch , P D F - A crob a t R e ad e r
T e rm in a ls e rve r (C lie n t Z u g riff)
H a rd w a re
B e tra ch te r
W e b b ro w se r u n d M a ilc lie n t M oz illa
B ü ro O p e n O ffice
K o m p rim ie ru n g W in Z ip
D a te n ba n k A cce s s
T a b elle n ka lku la tion E xce l
P rä se n ta tio n P o we rp o in t
T e xtve ra rb e itu n g W o rd
Seite 538
M R T G / N ag io s /
S N M P W a tch N e tvie w
Abbildung 80: Matrix zur Soft- und Hardware-Kostenermittlung
lfd . K o ste n
Jahr 1
lfd

3 Rechtsgrundlagen
BHO 512 , § 7 Wirtschaftlichkeit und Sparsamkeit, Kosten- und Leistungsrechnung
(1) Bei Aufstellung und Ausführung des Haushaltsplans sind die Grundsätze der Wirtschaftlichkeit
und Sparsamkeit zu beachten. Diese Grundsätze verpflichten zur Prüfung,
inwieweit staatliche Aufgaben oder öffentlichen Zwecken dienende wirtschaftliche Tätigkeiten
durch Ausgliederung und Entstaatlichung oder Privatisierung erfüllt werden können.
(2) Für alle finanzwirksamen Maßnahmen sind angemessene Wirtschaftlichkeitsuntersuchungen
durchzuführen. Dabei ist auch die mit den Maßnahmen verbundene Risikoverteilung
zu berücksichtigen. In geeigneten Fällen ist privaten Anbietern die Möglichkeit zu
geben darzulegen, ob und inwieweit sie staatliche Aufgaben oder öffentlichen Zwecken
dienende wirtschaftliche Tätigkeiten nicht ebenso gut oder besser erbringen können
(Interessenbekundungsverfahren).
(3) In geeigneten Bereichen ist eine Kosten- und Leistungsrechnung einzuführen.
Allgemeine Verwaltungsvorschrift (VV) 513 zu § 7 BHO:
1 Grundsatz der Wirtschaftlichkeit 514
Die Ausrichtung jeglichen Verwaltungshandelns nach dem Grundsatz der Wirtschaftlichkeit
soll die bestmögliche Nutzung von Ressourcen bewirken. Damit gehört zur Beachtung
des Grundsatzes der Wirtschaftlichkeit auch die Prüfung, ob eine Aufgabe
durchgeführt werden muss und ob sie durch die staatliche Stelle durchgeführt werden
muss.
Nach dem Grundsatz der Wirtschaftlichkeit ist die günstigste Relation zwischen dem
verfolgten Zweck und den einzusetzenden Mitteln (Ressourcen) anzustreben. Der
Grundsatz der Wirtschaftlichkeit umfasst das Sparsamkeits- und das Ergiebigkeitsprinzip.
Das Sparsamkeitsprinzip (Minimalprinzip) verlangt, ein bestimmtes Ergebnis mit
möglichst geringem Mitteleinsatz zu erzielen. Das Ergiebigkeitsprinzip (Maximalprinzip)
verlangt, mit einem bestimmten Mitteleinsatz das bestmögliche Ergebnis zu erzielen. Bei
der Ausführung des Haushaltsplans, der in aller Regel die Aufgaben (Ergebnis, Ziele)
bereits formuliert, steht der Grundsatz der Wirtschaftlichkeit in seiner Ausprägung als
Sparsamkeitsprinzip im Vordergrund.
Der Grundsatz der Wirtschaftlichkeit ist bei allen Maßnahmen des Bundes, die die Einnahmen
und Ausgaben des Bundeshaushaltes unmittelbar oder mittelbar beeinflussen,
zu beachten. Dies betrifft sowohl Maßnahmen, die nach einzelwirtschaftlichen Kriterien
(z. B. Beschaffungen für den eigenen Verwaltungsbereich und Organisationsänderungen
512
siehe Bundeshaushaltsordnung, i.d.F.v. 19.8.1969, zuletzt geändert durch Art. 3 G v. 22.
9.2005 I 2809.
513
siehe Vorschriftensammlung der Bundesfinanzverwaltung, Verwaltungsvorschrift zur Bundeshaushaltsordnung,
i.d.F.v. 16.05.2001, S. 16 ff..
514
Mit dem Grundsatz der Wirtschaftlichkeit sind - in Übereinstimmung mit der herrschenden
Meinung in den Verwaltungswissenschaften - die Grundsätze der Wirtschaftlichkeit und
Sparsamkeit im Sinne des § 7 BHO gemeint.
Seite 539

in der eigenen Verwaltung) als auch Maßnahmen, die nach gesamtwirtschaftlichen Kriterien
(z. B. Investitionsvorhaben im Verkehrsbereich, Subventionen und Maßnahmen der
Sozial- und Steuerpolitik) zu beurteilen sind. Unter die Maßnahmen fallen auch Gesetzgebungsvorhaben.
2 Wirtschaftlichkeitsuntersuchungen
Wirtschaftlichkeitsuntersuchungen sind Instrumente zur Umsetzung des Grundsatzes
der Wirtschaftlichkeit. Es ist zwischen einzel- und gesamtwirtschaftlichen Wirtschaftlichkeitsuntersuchungen
zu unterscheiden.
Wirtschaftlichkeitsuntersuchungen sind bei allen Maßnahmen durchzuführen. Sie sind
daher bei der Planung neuer Maßnahmen einschließlich der Änderung bereits laufender
Maßnahmen (Planungsphase) sowie während der Durchführung (im Rahmen einer begleitenden
Erfolgskontrolle) und nach Abschluss von Maßnahmen (im Rahmen einer
abschließenden Erfolgskontrolle) vorzunehmen.
2.1 Wirtschaftlichkeitsuntersuchungen als Planungsinstrument
Wirtschaftlichkeitsuntersuchungen in der Planungsphase bilden die Grundlage für die
begleitenden und abschließenden Erfolgskontrollen. Wirtschaftlichkeitsuntersuchungen
müssen mindestens Aussagen zu folgenden Teilaspekten enthalten:
� 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,
� Zeitplan für die Durchführung der Maßnahme,
� Kriterien und Verfahren für Erfolgskontrollen (siehe Nr. 2.2).
Ist das angestrebte Ziel nach dem Ergebnis der Ermittlungen oder aus finanziellen
Gründen nicht in vollem Umfang zu verwirklichen, so ist zu prüfen, ob das erreichbare
Teilziel den Einsatz von Mitteln überhaupt rechtfertigt und ob die geplante Maßnahme
besser zu einem späteren Zeitpunkt durchgeführt werden sollte.
Besteht für den Erwerb oder die Nutzung von Vermögensgegenständen eine Wahlmöglichkeit
zwischen Kauf-, Miet-, Leasing-, Mietkauf- und ähnlichen Verträgen, so ist vor
dem Vertragsabschluss zu prüfen, welche Vertragsart für die Verwaltung am wirtschaftlichsten
ist; ein Mangel an Haushaltsmitteln für den Erwerb durch Kauf reicht als Rechtfertigungsgrund
für die Begründung von Dauerschuldverhältnissen nicht aus. Bei der
Ausübung der Wahlmöglichkeit ist zu berücksichtigen, dass Leasingverträge hinsichtlich
ihrer Wirtschaftlichkeit im Einzelfall einer besonders eingehenden Prüfung bedürfen.
Seite 540

2.2 Wirtschaftlichkeitsuntersuchungen als Instrument der Erfolgskontrolle
Die Erfolgskontrolle ist ein systematisches Prüfungsverfahren. Sie dient dazu, während
der Durchführung (begleitende Erfolgskontrolle) und nach Abschluss (abschließende
Erfolgskontrolle) einer Maßnahme ausgehend von der Planung festzustellen, ob und in
welchem Ausmaß die angestrebten Ziele erreicht wurden, ob die Maßnahme ursächlich
für die Zielerreichung war und ob die Maßnahme wirtschaftlich war.
Bei Maßnahmen, die sich über mehr als zwei Jahre erstrecken, und in sonstigen geeigneten
Fällen sind nach individuell festzulegenden Laufzeiten oder zu Zeitpunkten, an
denen abgrenzbare Ergebnisse oder Teilrealisierungen einer Maßnahme zu erwarten
sind, begleitende Erfolgskontrollen durchzuführen. Sie liefern vor dem Hintergrund zwischenzeitlich
eingetretener ökonomischer, gesellschaftlicher und technischer Veränderungen
die notwendigen Informationen für die Entscheidung, ob und wie die Maßnahme
fortgeführt werden soll.
Von der begleitenden Erfolgskontrolle ist die laufende Beobachtung zu unterscheiden.
Im Gegensatz zum systematisch angelegten umfassenden Prüfungsverfahren der Erfolgskontrolle
ist sie eine fortlaufende gezielte Sammlung und Auswertung von Hinweisen
und Daten zur ergänzenden Beurteilung der Entwicklung einer Maßnahme. Alle
Maßnahmen sind nach ihrer Beendigung einer abschließenden Erfolgskontrolle zur
Überprüfung des erreichten Ergebnisses zu unterziehen.
Methodisch besteht zwischen begleitender und abschließender Erfolgskontrolle kein
Unterschied.
Die Erfolgskontrolle umfasst grundsätzlich folgende Untersuchungen:
� Zielerreichungskontrolle
Mit der Zielerreichungskontrolle wird durch einen Vergleich der geplanten Ziele
mit der tatsächlich erreichten Zielrealisierung (Soll-Ist-Vergleich) festgestellt, welcher
Zielerreichungsgrad zum Zeitpunkt der Erfolgskontrolle gegeben ist. Sie bildet
gleichzeitig den Ausgangspunkt von Überlegungen, ob die vorgegebenen
Ziele nach wie vor Bestand haben.
� Wirkungskontrolle
Im Wege der Wirkungskontrolle wird ermittelt, ob die Maßnahme für die Zielerreichung
geeignet und ursächlich war. Hierbei sind alle beabsichtigten und unbeabsichtigten
Auswirkungen der durchgeführten Maßnahme zu ermitteln.
� Wirtschaftlichkeitskontrolle
Mit der Wirtschaftlichkeitskontrolle wird untersucht, ob der Vollzug der Maßnahme
im Hinblick auf den Ressourcenverbrauch wirtschaftlich war (Vollzugswirtschaftlichkeit)
und ob die Maßnahme im Hinblick auf übergeordnete Zielsetzungen
insgesamt wirtschaftlich war (Maßnahmenwirtschaftlichkeit).
Erfolgskontrollen sind auch durchzuführen, wenn die Dokumentation in der Planungsphase
unzureichend war. In diesem Fall sind die benötigten Informationen nachträglich
zu beschaffen.
Seite 541

Die Zielerreichungskontrolle und die Wirkungskontrolle sind die Grundlagen für die Wirtschaftlichkeitskontrolle.
Im Gegensatz zur Wirtschaftlichkeitskontrolle lassen sie aber
den Mitteleinsatz unberücksichtigt.
2.3 Methoden (Verfahren) der Wirtschaftlichkeitsuntersuchungen 515
2.3.1 Allgemeines
Bei der Durchführung von Wirtschaftlichkeitsuntersuchungen ist die nach den Erfordernissen
des Einzelfalls einfachste und wirtschaftlichste Methode anzuwenden. Zur Verfügung
stehen einzelwirtschaftlich und gesamtwirtschaftlich orientierte Verfahren. Welches
Verfahren anzuwenden ist, bestimmt sich nach der Art der Maßnahme, dem mit ihr verfolgten
Zweck und den mit der Maßnahme verbundenen Auswirkungen.
Gesamtwirtschaftlich orientierte Verfahren sind für alle Maßnahmen mit erheblichen gesamtwirtschaftlichen
Auswirkungen geeignet. Einzelwirtschaftlich orientierte Verfahren
sind geeignet für Maßnahmen, die sich in erster Linie auf den betrachteten Verwaltungsbereich
(z. B. Ministerium, Behörde) beziehen.
2.3.2 Einzelwirtschaftliche Verfahren
Für Maßnahmen mit nur geringen und damit zu vernachlässigenden gesamtwirtschaftlichen
Nutzen und Kosten sind grundsätzlich die finanzmathematischen Methoden der
Investitionsrechnung (z. B. Kapitalwertmethode) zu verwenden. Für Maßnahmen mit nur
geringer finanzieller Bedeutung können auch Hilfsverfahren der Praxis (z. B. Kostenvergleichsrechnungen,
Angebotsvergleiche) durchgeführt werden.
2.3.3 Gesamtwirtschaftliche Verfahren
Für Maßnahmen, die nicht zu vernachlässigende gesamtwirtschaftliche Auswirkungen
haben, sind gesamtwirtschaftliche Wirtschaftlichkeitsuntersuchungen (z. B. Kosten-
Nutzen-Analyse) durchzuführen.
2.4 Verfahrensvorschriften
2.4.1 Die Wirtschaftlichkeitsuntersuchungen sind grundsätzlich von der Organisationseinheit
durchzuführen, die mit der Maßnahme befasst ist.
2.4.2 Das Ergebnis der Untersuchung ist zu vermerken und zu den Akten zu nehmen.
Bei Maßnahmen mit nur geringer finanzieller Bedeutung kann hiervon abgesehen werden.
2.4.3 Zu den Unterlagen nach § 24 gehören auch Wirtschaftlichkeitsuntersuchungen.
2.4.4 Die Beauftragten für den Haushalt entscheiden, über welche Wirtschaftlichkeitsuntersuchungen
sie zu unterrichten sind. Sie können sich an den Wirtschaftlichkeitsuntersuchungen
beteiligen und die Berücksichtigung einer Maßnahme bei der Aufstellung der
Voranschläge und bei der Ausführung des Haushaltsplans von der Vorlage von Wirtschaftlichkeitsuntersuchungen
abhängig machen.
515 siehe Arbeitsanleitung Einführung in Wirtschaftlichkeitsuntersuchungen, Anlage zum Rundschreiben
des BMF vom 31. August 1995 - II A 3 - H 1005 - 23/95 - (GMBl 1995, S. 764).
Seite 542

3 Interessenbekundungsverfahren 516
In geeigneten Fällen ist privaten Anbietern die Möglichkeit zu geben darzulegen, ob und
inwieweit sie staatliche Aufgaben oder öffentlichen Zwecken dienende wirtschaftliche
Tätigkeiten nicht ebenso gut oder besser erbringen können (Interessenbekundungsverfahren).
Ein Interessenbekundungsverfahren kommt bei der Planung neuer und der Überprüfung
bestehender Maßnahmen oder Einrichtungen in Betracht. Es erfordert eine Erkundung
des Marktes nach wettbewerblichen Grundsätzen. Das Ergebnis der Markterkundung ist
mit den sich bietenden staatlichen Lösungsmöglichkeiten zu vergleichen, um eine wirtschaftliche
Bewertung zu gewährleisten.
Das Interessenbekundungsverfahren ersetzt nicht das Verfahren zur Vergabe öffentlicher
Aufträge. Wenn das Interessenbekundungsverfahren ergibt, dass eine private Lösung
voraussichtlich wirtschaftlich ist, ist ein Verfahren zur Vergabe öffentlicher Aufträge
durchzuführen.
4 Kosten- und Leistungsrechnung
Dauerhafte Aufgabe der öffentlichen Verwaltung ist es, das Verhältnis von Kosten und
Leistungen bei der Aufgabenwahrnehmung zu verbessern. Grundlage dafür ist die Einführung
einer Kosten- und Leistungsrechnung gemäß der Standard-KLR 517 .
Die mit der Kosten- und Leistungsrechnung erzielten Ergebnisse machen entstandene
Kosten und erbrachte Leistungen transparent. Ebenso wird eine wirksame Planung,
Steuerung und Kontrolle ermöglicht. Auch die Haushaltsplanung und -ausführung kann
durch die Kosten- und Leistungsrechnung unterstützt werden. Ebenso ist durch Informationen
der Kosten- und Leistungsrechnung eine Ermittlung von kostendeckenden Gebühren
und Entgelten realisierbar.
516 Zur Durchführung des Interessenbekundungsverfahrens siehe Rundschreiben des BMF
vom 31. August 1995 - II A 3 - H 1005 - 22/95 - (GMBl 1995, S. 764).
517 VSF H 90 01
Seite 543