Softwareverteilung und Systeminstallation. Methoden, Verfahren und Tools

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Zielsetzung
1.2 Aufbau der Diplomarbeit

2 Grundlagen
2.1 Die IT-Infrastructure Library - ITIL
2.1.1 Service-Support
2.1.2 Service-Delivery
2.1.3 ITIL und Softwareverteilung
2.2 Client- und Softwaremanagement
2.3 Der Software-Lebenszyklus
2.4 Arten der Softwareverteilung
2.5 Softwareverteilung als fortlaufender Prozess

3 Installationsverfahren und Paketierung
3.1 Allgemeine Überlegungen
3.2 Anforderungen an eine Paketierungsumgebung
3.3 Manuelle Installation
3.4 Unattended Setup
3.4.1 Ermittlung des Installertyps
3.4.2 Windows Installer
3.4.2.1 Features
3.4.2.2 Transforms erstellen
3.4.2.3 Bedeutung von MSI Paketen für Softwareverteilung .
3.4.2.4 Fazit Windows Installer
3.4.3 INNO Installer
3.4.4 Nullsoft Scriptable Install System
3.4.5 InstallShield
3.4.6 WISE Installer
3.4.7 Fazit Unattended Setup
3.5 Skriptgesteuerte Installation
3.5.1 Skriptsprachen für Windows
3.5.2 Beispiel: Skriptgesteuerte Installation mit AutoIt
3.5.3 Fazit Skriptgesteuerte Installation
3.6 Snapshot Verfahren
3.6.1 Repacketierung mit WinInstall LE
3.6.2 Fazit Snapshotverfahren

4 Systeminstallation am Beispiel von Windows XP
4.1 Installationsquelle vorbereiten
4.1.1 Integration eines Service Pack
4.1.2 Sicherheitsupdates integrieren
4.1.3 Treiber und weitere Anwendungen integrieren
4.1.3.1 Treiber integrieren
4.1.3.2 Anwendungen integrieren
4.1.4 Antwordatei erstellen
4.1.5 Tool-Tip nLite
4.2 Remote Installation Services
4.3 Systeminstallation im Netzwerk mit PXE
4.4 Imaging zur Betriebssysteminstallation
4.4.1 Die Windows SID Problematik
4.4.2 Fazit Imaging

5 Verteilung
5.1 Grundsätzliche Varianten der Softwareverteilung
5.1.1 Pull Prinzip
5.1.2 Push Prinzip
5.1.3 Thin Client Betrieb
5.2 Softwareverteilung mittels Netzwerkfreigabe
5.3 Softwareverteilung mittels Windows Gruppenrichtlinien
5.4 Softwareverteilung mit Hilfe spezieller Software

6 Integrierte Softwaremanagementlösungen
6.1 Open PC Server Integration (Opsi)
6.2 Microsoft Systems Management Server
6.3 Baramundi
6.4 enteo NetInstall
6.5 Fazit

7 Weitere Aspekte des Softwaremanagements
7.1 Inventarisierung
7.2 Lizenzmanagement
7.3 Patch und Update Management
7.3.1 Windows Server Update Services
7.4 Fernwartung

8 Softwareverteilung unter Windows Vista
8.1 Windows Vista Systeminstallation
8.2 Änderungen an Windows Vista

9 Schlussbetrachtung und Fazit
9.1 Schlussbetrachtung
9.2 Fazit

Literatur

Anhang
A-1 Autoit 7-Zip Installationskript
A-2 Beispiel Windows XP Antwortdatei

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

2.1 ITIL im Überblick
2.2 Management von Hard- und Software im Kontext von ITIL Service Support . 7
2.3 Softwarelebenszyklus
2.4 Der Kreislauf der Softwareverteilung

3.1 WinInstall LE in VirtualPC, eine saubere und zeitsparende Paketierungsum- gebung
3.2 Parameter des Setups Service Pack 1 SQL Server 2005
3.3 USSF erkennt viele Installationsprogramme und liefert die Parameter für die automatisierte Installation
3.4 Funktionalitäten der Windows Installer Technologie
3.5 Microsoft Office Custom Installation Wizard
3.6 Mit Hilfe des Adobe Installshield Tuner lässt sich die Installation des Adobe Reader sehr genau konfigurieren
3.7 Inno Installer im Einsatz
3.8 Der für NSIS typische Schriftzug verrät diesen Installer
3.9 Der typische erste Bildschirm des InstallShield Installers
3.10 Der Wise Installer ist einfach durch dieses Fenster zu erkennen
3.11 Einfaches AutoIt Skript - öffnet Notepad, gibt Hello World ein, schließt das Fenster und speichert nicht
3.12 AutoScriptWriter nimmt Tastatur- und Mauseingaben auf und erstellt daraus ein AutoHotKey Skript
3.13 Das Installationsprogramm von 7-Zip
3.14 7-Zip fertig installiert
3.15 7-Zip File Manager
3.16 7-Zip lässt sich mittels des Filemanger mit unterstützten Dateitypen verknüpfen
3.17 Window Info liefert viele Informationen zu Programmfenstern
3.18 WinInstall Discover
3.19 Dateien können von der Erstellung des Snapshots ausgenommen werden . .
3.20 WinInstall erstellt den „vorher“ Snapshot
3.21 WinInstall erstellt aus den Unterschieden der Snaptshots ein MSI Paket . .
3.22 WinInstall Paketübersicht

4.1 Integration Windows XP Service Pack 3
4.2 Die beiden Arten von Sicherheitsupdates benötigen unterschiedliche Parametr
4.3 Setupmanager erlaubt die Erstellung einer Antwortdatei
4.4 nLite im Einsatz
4.5 Typischer PXE Bootbildschirm
4.6 PXE Kommunikation

5.1 Beispiel für das Pull Prinzip: Zenworks Application Launcher
5.2 Einfache Netzwerkfreigabe zur Softwareverteilung
5.3 Konfiguration der Softwareverteilung
5.4 Kategorien für die Softwarepakete
5.5 Die Software ist fertig eingerichtet und wird bei der nächsten Anmeldung verteilt

8.1 Typische autoamtisierte Systeminstalltion von Windows Vista
8.2 Benutzerkontensteuerung von Windows Vista

1 Einleitung

Stationäre Computer und Laptops sind aus dem heutigen Alltag nicht mehr wegzudenken. Beinahe alle Prozesse in einem Unternehmen werden heute von Computern unterstützt. Es obliegt dabei einer speziellen Gruppe von Mitarbeitern diese Computer und die Infrastruktur am Laufen zu halten. Diese Administratoren sind dabei auch für die Versorgung der Rechner mit der nötigen Software verantwortlich. Sobald ein zu verwaltendes Netzwerk von Com- putern eine gewisse Größe erreicht hat, wird die Installation der Rechner schnell zur Qual. Während es bei ein paar PCs noch kein großes Problem darstellt ’mal eben’ diese und jene Anwendung zu installieren, wird dies bei größeren Netzwerken zu einer Mammutaufgabe. Allzu schnell sind die Adminstratioren nur noch dabei von PC zu PC laufen und per Hand die nötige Software zu installieren.

1.1 Zielsetzung

Zielsetzung dieser Diplomarbeit ist es, Methoden Verfahren und Tools der Softwareverteilung vorzustellen. Wie der Titel vermuten lässt, soll dabei neben den theoretischen Grundlagen auch die Praxis nicht zu kurz kommen. Die theoretischen und praktischen Ausführungen erheben dabei nicht den Anspruch auf Vollständigkeit. Die Arbeit möchte dabei die folgende Frage beantworten:

Wie kriege ich die Installation von Anwendungen und Rechnern über das Netz- werk automatisiert und was muss ich dafür tun und beachten?

1.2 Aufbau der Diplomarbeit

Die vorliegende Arbeit ist grob in die drei Bereiche Grundlagen, Kernkomponeten der Soft- wareverteilung und Verschiedenes unterteilbar.

Im ersten Teil werden die Grundlagen der Softwareverteilung erklärt und ein erster Überblick über das Thema gegeben. Dabei wird versucht einen theoretischen Rahmen für das Thema Softwareverteilung zu schaffen. Hierzu werden einige der interessantesten Ansätze vorgestellt. Auch wird hier eine erste Untergliederung in die Teilbereiche Betriebssysteminstallation und Ergänzungsinsallationen vollzogen.

Der zweite Teil der Arbeit beschäftigt sich mit den Kernkomponenten der Softwareverteilung. Dies sind die Installation und Paketierung von Software, die automatisierte Installation und Konfiguration von Betriebsystemen und die Verteilung dieser Pakete und Betriebssysteme über das Netzwerk.

Kapitel zwei hat die Installation von Software zum Thema. Es werden Verfahren vorgestellt wie sich die Installation und Konfiguration von Software automatisieren lässt. Zusätzlich werden hier Praxisbeispiele zu den wichtigsten Verfahren gegeben und an Beispielen veran- schaulicht, wie sich die Installation und Konfiguration automatisieren lässt.

Das Kapitel Systeminstallation behandelt die Installation und Verteilung von Betriebssys- temen. Hier wird am Beispiel von Windows XP gezeigt wie sich ein Betriebssystem für die automatische und unbeaufsichtigte Installation vorbereiten lässt. Weiterhin werden übliche Methoden vorgestellt, wie sich ein entsprechend vorbereitetes Betriebssystem möglichst be- quem über das Netzwerk verteilen und installieren lässt.

Kapitel vier beschäftigt sich allgemein mit den Möglichkeiten der Verteilung von Softwa- re über das Netzwerk und stellt übliche Verfahren hierfür im Windows Umfeld vor.

Der dritte Teil der Arbeit beschäftigt sich mit verschieden Aspekten der Softwarevertei- lung und gibt einen Ausblick in die Zukunft der Softwareverteilung unter Windows Vista.

Zuerst werden hier Softwaremanagementlösungen vorgestellt. Diese Anwendungen integrie- ren viele der Methoden und Verfahren die in den vorherigen Kapiteln vorgestellt wurden. Auch unterstützen diese Softwaremanagementlösungen weitere Funktionen. Diese weiteren Aspekte des Softwaremanagements werden anschließend in einem eigenen Kapitel vorgestellt.

Das letzte Kapitel stellt die Änderungen und Neuerungen von Windows Vista im Bezug auf das Thema Softwareverteilung vor. Die Windows Vista wirken sich auf etablierte Metho- den der Softwareverteilung aus. Auch gibt es einige Änderungen bei den von Microsoft für Vista vorgesehenen Methoden der Softwareverteilung und Betriebssysteminstallation.

2 Grundlagen

2.1 Die IT-Infrastructure Library - ITIL

Im Laufe der 1990er Jahre wurde die Information Technology Infrastructure Library, kurz ITIL, als Rahmenwerk (Framework) für standardisierte IT Prozesse entwickelt. Es hat sich seitdem als Quasi-Standard etabliert. Jedoch ist ITIL keine verbindliche Norm wie etwa ISO 9000. Es ist viel mehr ein herstellerunabhängiger Leitfaden, der bewährte Vorgehensweisen und Methoden beschreibt [HS07, S. 106 ff]. Es werden erforderliche Prozesse, Aufgaben und Rollen definiert und auf Abhängigkeiten derer eingegangen. ITIL verzichtet auf konkrete Realisierungen, was oft kritisiert wird. ITIL ist mittlerweile in Version 3 angekommen. In dieser Arbeit soll jedoch noch auf Version 2 eingegangen werden. Gegliedert sind die Prozesse von ITIL v2 in die zwei Kategorien Service-Support und Service-Delivery.

2.1.1 Service-Support

Innerhalb des Service-Support werden die Prozesse behandelt, die den direkten Support von Nutzern und die Betriebsunterstützung betreffen. Diese äußerst komplexe Aufgabe wird auf fünf Kernbereiche verteilt.

Change Management

Das Change Management bildet die Schnittstelle zwischen den ITIL Prozessen. Änderungs- anträge werden geprüft, genehmigt und die ordnungsgemäße Durchführung oder Änderung überwacht und dokumentiert. Weiterhin wird die Einhaltung gültiger Standards und Ver- fahren überwacht und die Abhängigkeiten und Risiken im Gesamtsystem im Auge behalten.

Incident Management

Im Incident Management wird beschrieben, wie mit Störungen (englisch incident = Störung) und Hilfsanfragen umzugehen ist. Ziel dabei ist es, Fehler und Probleme möglichst schnell zu beseitigen, um den regulären Betrieb wieder herzustellen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: ITIL im Überblick [Olb04, S. 12]

Problem Management

Das Problem Management arbeitet oft mit dem Incident Management zusammen. Hier be- fasst man sich aber mit der Suche nach der Ursache des Problems und dessen Beseitigung, um den störungsfreien Betrieb nachhaltig sicherzustellen.

Configuration Management

Im Configuration Management wird die gesamte IT-Infrastruktur eines Unternehmens abge- bildet. Dies erfolgt in Form eines Datenbankmodells der sogenannten Configuration Mana- gement Database (CMDB). Alle Prozesse des Service-Support und Service-Delivery intera- gieren mit dieser Datenbank.

Release Management

Durch das Release Management werden neue Versionen von IT Komponenten geplant und implementiert. Auch werden hier Patch- und Versionsstände verwaltet. Zusätzlich werden Trainingsmaßnahmen und die Dokumentation veränderter Funktionalitäten organisiert.

2.1.2 Service-Delivery

Der Service-Support soll für die Nutzer und den Betrieb der IT eine abgestimmte Leistung zur Verfügung stellen. Diese Leistungen genauer zu spezifizieren ist Aufgabe des Service-Delivery. Service-Delivery kümmert sich eher um eine strategische Ausrichtung der IT Services und überlässt das „Tagesgeschäft“ den Prozessen des Service-Support. Beim Service-Delivery wer- den wiederum fünf wichtige Prozesse unterschieden.

Service Level Management

Im Service Level Management werden Vereinbarungen der IT mit ihren Kunden über die Lieferung bestimmter Leistungen getroffen. Gegenstand dieser Service Level Agreements (SLA) sind zum Beispiel Service- und Reaktionszeiten innerhalb derer auf Störungen reagiert wird.

Continuity Management

Im Continuity Management wird sichergestellt, dass bei Teil- oder Totalausfällen von Funk- tionalitäten der IT ein ordnungsgemäßer Betrieb durch Ersatzsysteme sichergestellt ist. Im Vorfeld werden solche Szenarien, Pläne und Vorgehensweisen erarbeitet, um Ausfälle zu ver- meiden oder mit ihnen umzugehen.

Availabity Management

Durch Risiko- und Schwachstellenanalysen soll im Availability Management die Verfügbarkeit von IT Diensten sichergestellt werden.

Capacity Management

Im Capacity Management soll eine rechtzeitige Bereitstellung von IT Komponenten gewähr- leistet werden. Zentraler Punkt ist die Vermeidung von Engpässen im Betrieb.

Financial Management

Im Financial Management werden die effektiven Kosten den Verursachern zugeordnet um diese später genauer abrechnen zu können. Weiterhin werden hier finanzielle Optimierungs- potentiale gefunden.

2.1.3 ITIL und Softwareverteilung

Es ist nicht verwunderlich, dass ein Thema wie Softwareverteilung sich auch in ITIL wieder- findet. Auch hier wird nur ein optimaler Zustand beschrieben und keine konkrete Realisierung vorgegeben. Jedoch orientieren sich viele Prozesse des Client Management an den ITIL Pro- zessen des Service Supports. Die folgende Abbildung setzt den ITIL Service Support mit den Teilgebieten des Managements von Hard- und Software in Beziehung.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Management von Hard- und Software im Kontext von ITIL Service Support [HS07, S. 205]

Softwareverteilung in seiner reinsten Form findet sich im Release Management wieder. Jedoch werden auch andere Prozesse des ITIL hiervon berührt. Jede Einführung oder Änderung von Softwareinstallationen wird über das Change Management abgewickelt und mit dem Configuration Management abgestimmt.

2.2 Client- und Softwaremanagement

Leider ist der Begriff Client Management als solcher nicht klar definiert. In der Literatur finden sich andere Bezeichnungen wie Desktop Management, Desktop Management Services, Asset Lifecycle Managment oder PC-Lifecycle Management - um nur einige zu nennen. Zwar mögen sich je nach Bezeichnung und Auslegung der Begriffe Unterschiede im Detail ergeben, jedoch ist letztendlich oft dasselbe gemeint. Bei Client Management handelt es sich um die Verwaltung von Hard- und Software während ihres gesamten Lebenszyklus. Hierbei geht es jedoch weniger um strategische Infrastrukturentscheidungen als vielmehr um die operative Sicht.

Softwareverteilung an sich ist nur ein Teilbereich des Softwaremanagement, welches wie- derum nur ein Teil des Client Management ist. Leider werden auch für Softwareverteilung unterschiedliche Begriffe verwendet. So ist Softwareverteilung auch als Deployment, Asset Management, oder Softwaremanagement bekannt. Der von ITIL vorgegebene Begriff Release Management hat sich bisher scheinbar noch nicht durchgesetzt.

2.3 Der Software-Lebenszyklus

Ein anderer Ansatz für die Einordnung der Softwareverteilung ist der Software-Lebenszyklus [Dor02]. Dieses Modell kommt dem in der Literatur üblichen Verständnis von Softwarever- teilung am nächsten und wird hier kurz beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3: Softwarelebenszyklus [Dor02, Kapitel 3]

Anforderung

Der Beginn des Lebenszyklus liegt meist außerhalb der EDV Abteilung. Ein Anwender oder eine Gruppe von Anwendern stellt fest, dass eine bestimmte Software benötigt wird. In Un- ternehmen gibt es verschiedene Prozesse zur Anforderung neuer Software. Im einfachsten Fall schreibt ein Anwender eine E-Mail an die IT Abteilung, dass er eine bestimmte Software be- nötigt. Diese Anforderung startet weitere Prozesse. So kann eine Kosten/Nutzenbetrachtung erforderlich sein oder ein Pflichtenheft für eine Neuentwicklung erstellt werden.

Beschaffung/Ent wicklung

Nachdem die Anforderung einer Software erfolgt ist, gibt es grundsätzlich zwei Alternativen: Neuentwicklung oder Beschaffung einer Standardsoftware. Eine Software muss in ausrei- chender Stückzahl (Lizenzen) beschafft werden und entsprechend angepasst werden (Custo- mizing). Findet sich keine passende Software muss die Software neu entwickelt werden. Auch kann eine Entwicklung angestrebt werden, obwohl eine passende Software existiert. Beispiels- weise kann die Eigenentwicklung günstiger sein. Zudem ist man durch eine Eigenentwicklung vom Softwarehersteller unabhängiger.

Konfiguration

Die Konfiguration von Software kann mit einem erheblichen Zeitaufwand verbunden sein. Bei kostenfreien kleinen Programmen kann sie bereits mit der Angabe des Installationspfades erledigt sein. Bei größeren Softwarepaketen ist jedoch oft ein erheblicher Anpassungsaufwand erforderlich. Man denke nur an das Customizing¹ von SAP ERP² Systemen, welches ohne externe Berater so gut wie unmöglich scheint. Auch die Migration auf eine neue Windows Version ist oft mit einem erheblichen Konfigurationsaufwand verbunden.

Test und Pilotierung

Diese Phase des Softwarelebenszyklus sollte sich eigentlich mehrmals im Modell finden. Be- sonders bei größere Softwarepaketen sollten im Rahmen des Softwarelebenszyklus folgende Fragen geklärt werden. Verträgt sich die Anwendung mit anderen Anwendungen, die bereits im Einsatz sind? Welche Abhängigkeiten sind zu erfüllen? Läuft die Anwendung überhaupt auf den Rechnern? Oft ist es auch ratsam, größere Softwarepakete im Rahmen eines Pilot- Einsatzes ausführlich zu testen. Je ausführlicher neue Software getestet wird, desto weniger Probleme sind beim Einsatz der Software zu erwarten. In der Praxis wird diese Phase leider häufig vernachlässigt - vor allem in kleineren Unternehmen.

Paketierung und Repaketierung

Moderne Software wird fast immer mit einem Installationsprogramm ausgeliefert. Diese In- stallationsprogramme tragen stimmige Namen wie zum Beispiel Setup.exe. Sie führen den Anwender durch eine Reihe von Eingabemasken und erlauben so eine vergleichsweise einfa- che Installation. Was für eine einzelne Installation sinnvoll ist, wird auf mehreren Rechnern jedoch schnell zur Qual, da die gleichen Masken mehrfach durchlaufen werden müssen. Oft haben Anwendungen auch gewisse Anforderungen, die vor der Installation oder zur Nut- zung notwendig sind. Beispielsweise benötigen Java Programme eine Java Laufzeitumgebung, manche Programme eine aktuelle Version von DirectX³oder eine zusätzlich installierte Da- tenbank. Andere Anwendungen bestehen aus mehreren einzelnen Programmen, die zu Pake- ten zusammengefasst werden. Ein Paket kann aus einer einzelnen Anwendung bestehen oder aus mehreren nötigen Programmen und Konfigurationsdateien. Oft müssen die Anwendun- gen auch nach bestimmten Vorgaben installiert werden. So kann es sinnvoll sein, Programme standardmäßig immer unter einem gewissen Pfad zu installieren, kein Desktop Icon anzulegen oder die Verknüpfungen im Start Menü nach Anwendungsgebiet zu sortieren. Weiterhin kann es notwendig sein, Programme entsprechend den Vorgaben der Organisation einzurichten. So können beispielsweise entsprechende Vorlagen in Microsoft Office eingebunden werden. Da viele dieser Änderungen ein „Umpacken“ der ursprünglichen Installationspakete erfordern, spricht man hier von Repaketierung. Die beschaffte Software wird installiert, Abhängig- keiten aufgelöst und so angepasst, dass weitere Installationsvorgänge automatisiert erfolgen können. Aus dieser Anpassung entsteht ein neues Paket, welches in den weiteren Phasen des Softwarelebenszyklus verwendet wird.

Verteilung

Die zuvor erstellten Pakete müssen auf die Rechner der Anwender, die sie benötigen, verteilt werden. In der Praxis kann man heutzutage von vernetzten Arbeitsplätzen ausgehen und die Verteilung der Software über das Netzwerk ist somit der Regelfall. Die Möglichkeiten reichen hierfür von der Verteilung per Nerzwerkfreigabe bis zum Einsatz von aufwendigen Software- verteilungswerkzeugen. Alle Verfahren streben dabei eine effektive Nutzung der verfügbaren Netzwerkressourcen an. Weiterhin ist eine zeitgenaue Installation und ein zuverlässiger In- formationsfluss über den Installationsstatus wünschenswert.

Installation

Nachdem Software entsprechend angepasst und zum Zielrechner transportiert wurde, wird sie lokal installiert. Wenn bei der Paketierung alles richtig gemacht wurde, läuft die Installation an sich ohne Interaktion und im Hintergrund ab. Ausgefeiltere Softwareverteilungswerkzeuge erlauben eine Installation zeitverzögert zur Verteilung. Weiterhin ist eine Rückmeldung über den Status der Installation an die zentrale Stelle der Softwareverteilung wünschenswert.

Aktualisierung

Eine Aktualisierung installierter Software kann viele Gründe haben. So kann eine neue Ver- sion der Software benötigte Funktionen mitbringen. Auch können Fehler in Software mittels eines Patches oder Service Packs korrigiert werden. Ob nun die ganze Software neu verteilt wird, oder lediglich ein Patch installiert wird, ist von der Software abhängig.

Deinstallation

Nachdem die Software ihren Dienst erfüllt hat, wird sie in dieser Phase quasi „zu Grabe getragen“. Vor der Deinstallation sollten eigene Fragen beantwortet werden. Handelt es sich bei der Deinstallation um einen Einzelfall oder wird die Software im ganzen Unternehmen abgeschafft? Existieren Abhängigkeiten die aufgelöst werden müssen? In der Praxis wird Software oft nicht deinstalliert weil es Anwender geben könnte, die genau diese Software noch benötigen. Ein überhastetes deinstallieren von Software sollte allgemein vermieden werden, jedoch können für nicht mehr benötigte Software weiterhin Lizenzgebühren fällig werden. Eine Software „stirbt“ nicht, sie kann sehr wohl noch einen Wert für das Unternehmen darstellen. Hier kann das Lizenzmanagement ansetzen um deinstallierte Software noch weiter zu verwerten. So können nicht benötigte Lizenzen weiterverkauft werden.

2.4 Arten der Softwareverteilung

Im einfachsten Fall gibt es zwei verschiedene Arten der Softwareverteilung im Lebenszyklus eines PCs [Sup06]. Als erstes wäre dies die Systeminstallation oder Grundinstallation eines Rechners. Hierbei wird der Rechner mit einem Betriebsystem und für den Betrieb notwendi- ger Software wie Treibern befüllt. Anschließend wird er in das Netzwerk eingebunden und ist somit betriebsbereit. Alle darauf folgenden Installationen werden als Ergänzungsinstalla- tion gesehen. Hierbei werden neue Programme installiert, vorhandene Programme auf dem neuesten Stand gehalten und das Betriebsystem mit Hotfixes⁴ und Service Packs versorgt. Dieser Zyklus kann sich mehrmals wiederholen.

Man kann argumentieren, dass die Systeminstallation an sich nur ein Spezialfall der Soft- wareverteilung ist. Daher soll in dieser Arbeit zwischen diesen beiden Arten unterschieden werden. Die verwendeten Methoden und Tools unterscheiden sich im Detail, was es zweck- mäßig erscheinen lässt diese Unterteilung durchzuführen.

2.5 Softwareverteilung als fortlaufender Prozess

Softwareteilung ist keine einmalige Sache, die man einmal erledigt und es dabei belässt. Vielmehr sollte man es als fortlaufenden Prozess sehen. Abbildung 2.4 zeigt die Schritte, die an der erfolgreichen Bereitstellung einer Software in einem Unternehmensnetzwerk beteiligt sind [Lüd07, Kap. 2.2.1].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.4: Der Kreislauf der Softwareverteilung [Lüd07, Abbildung 2.3]

Roll-Out beschreibt hier die Verteilung und Installation auf den Rechnern während Roll-Back der Deinstallation entspricht.

3 Installationsverfahren und Paketierung

Heutzutage ist es üblich, dass Software mit einem Installationsprogramm ausgeliefert wird, die den Benutzer durch die Installation führt. Dazu bietet es verschiedene Auswahloptionen für die Konfiguration an und kopiert anschließend die Software entsprechend auf den PC. Dieser Vorgang wird, speziell im Windows Umfeld, oft als Setup bezeichnet. In Anlehnung daran wird auch von „Aufsetzen“ gesprochen. Eine erfolgreiche Installation ist oft zwingende Voraussetzung für die ordnungsgemäße Funktion von Programmen. Je größer und komplexer Programme sind, desto größer ist auch das Risiko, dass hierbei Fehler auftreten. Sobald die Anzahl zu betreuender Client PCs eine gewisse Größe erreicht hat, ist eine Automatisierung der Softwareinstallation wünschenswert. Aus dem ursprünglichen Installationspaket entsteht durch diese Automatisierung und Konfiguration ein neues Softwarepaket. Dieser Vorgang wird als Repaketierung bezeichnet - siehe hierzu auch Kapitel 2.3.

3.1 Allgemeine Überlegungen

Bevor man sich an die Auswahl einer Technik für die automatisierte Installation macht, gilt es einige grundsätzliche Überlegungen anzustellen. Zuerst sollte bestimmt werden was man installieren möchte. Ein Betriebsystem wie Windows bietet viele Einstellungsoptionen bei der Installation. Beispielsweise ist es möglich die von Windows mitgelieferten Spiele nicht zu installieren. Auch sollte die Installation des Betriebsystems möglichst standardisiert wer- den. Falls noch kein entsprechendes Konzept für eine Standardisierung vorhanden ist, sollte eines ausgearbeitet werden. Hier sind Dinge wie eine einheitliche Namensgebung der PCs im Netzwerk und eine fortlaufende IP Adressvergabe festzulegen.

Eine eher grundsätzliche Entscheidung ist es, ob man nur das reine Betriebsystem installiert oder bereits einige Standardapplikationen mitinstalliert. Typische Vertreter für Standard- applikationen sind Microsoft Office, Acrobat Reader oder die Allzweck-Entwicklungsumgebung Eclipse.

3.2 Anforderungen an eine Paketierungsumgebung

Bei der Paketierung empfiehlt es sich mit einer so genannten „Clean Mac hine“ zu arbeiten [KTK05, S. 151]. Das bedeutet, dass Pakete auf einem PC erstellt werden der möglichst sauber installiert und konfiguriert ist. Neben dem Betriebsystem sollten sich nur das zu- letzt im Unternehmen freigegebene Service Pack, wichtige Hot Fixes und wichtige Software wie Internet Explorer und Windows Media installiert sein. Ziel ist es eine möglichste sau- bere Umgebung für die Paketierung zu haben um Fremdeinflüsse auszuschließen. So kann vorhandene Software die Installation negativ beeinflussen, da nötige Komponenten nicht in- stalliert werden, weil sie in der Paketierungsumgebung bereits vorhanden sind. Nach der Softwareverteilung fehlt aber genau diese Komponente auf den Client PCs und die Anwen- dung ist somit nicht, oder nur eingeschränkt, lauffähig. Besonders wichtig ist eine saubere Paketierungsumgebung beim Snapshot Verfahren (Kapitel 3.6). Hier werden alle Verände- rungen aufgezeichnet, somit kann bereits ein Update des Virenscanners oder das schreiben einer Log Datei einer Hintergrundanwendung in das zu erstellende Installationspaket mit eingehen. Es ist nicht verwunderlich, dass solche fehlerhaften Pakete nach dem Rollout dann zu Problemen führen. Selbst wenn die Software dann noch lauffähig ist, schleppt sie viel- leicht unnötigen Ballast (temporäre Dateien) mit oder es ergeben sich später unangenehme Probleme wie ein gescheitertes Update.

Eine besonders komfortable Variante einer sauberen Paketierungsumgebung lässt sich mit Virtualisierungssoftware wie VMWare oder VirtualPC erstellen. Diese virtuellen PCs lassen sich mit wenigen Aktionen in einen vorher gespeicherten Zustand versetzen. Dadurch kann man schnell zu einem sauberen Zustand zurückkehren und bei der Paketierung von vielen Anwendungen Zeit sparen. Besonders beim Snapshot Verfahren erfreut sich diese Metho- de großer Beliebtheit, weil man hier den Snapshot vom Anfangstatus vor der Installation wiederverwenden kann. Man speichert dazu den Zustand nach Erfassung des Anfangsstatus und verwendet diesen dann immer wieder als Grundlage für die Paketierung. Mit Packaging Robot¹ existiert eine Software, die die Verwaltung von virtuellen Maschinen direkt in den Ablauf der Paketierung integriert hat.

3.3 Manuelle Installation

Bei der manuellen Installation ruft man den mitgelieferten Installer der Software auf und führt die Installation durch. Da dies bei mehreren PCs einen oft nicht unerheblichen Laufauf- wand für den Administrator verursacht, wird es auch als Turnschuhverfahren bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.1: WinInstall LE in VirtualPC, eine saubere und zeitsparende Paketierungsumgebung

Auch wenn in einer Organisation Software zur automatischen Installation und Verteilung genutzt wird, kommt man um die manuelle Installation von Software nicht herum - und sei es nur um die Installation aufzuzeichnen, um diese dann in Zukunft zu automatisieren. Es gibt Anwendungsfälle bei denen die manuelle Installation von Software auch bei vor- handenen Verteilungswerkzeugen ihre Berechtigung hat oder sogar nötig ist. Es lohnt sich zum Beispiel nicht, die Verteilung von Software, die nur einmal oder ein paar Mal installiert wird, zu automatisieren. Als Beispiel sei hier teure Spezialsoftware genannt, die nur an ei- nem Arbeitsplatz benötigt wird. Ein weiteres Beispiel wäre die Installation einer speziellen Serversoftware - auch hier macht eine Automatisierung nur wenig Sinn. Leider gibt es auch immer noch Software deren Installation sich nicht automatisieren lässt - hier kommt man dann nicht um eine manuelle Installation herum.

Fazit: Die manuelle Softwareinstallation und Verteilung hat immer noch ihre Existenzbe- rechtigung. Sobald jedoch mehrere gleichartige Softwareinstallationen anstehen, sollte man sich Gedanken über eine Automatisierung der Installation und Verteilung machen.

3.4 Unattended Setup

Das Unattended Setup ist ein weit verbreitetes Verfahren zur Installation. Dieses Verfahren ermöglicht eine unbeaufsichtigte, weil automatisierte, Installation von Software und Betrieb- systemen.

Es gibt mehre Möglichkeiten dem Installationsprogramm die benötigten Parameter mitzu- geben. Die Parameter können dem Installationsprogramm beim Aufruf per Kommandozeile übergeben werden. Leider unterscheiden sich die Installtionsprogramme hierbei jedoch er- heblich.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.2: Parameter des Setups Service Pack 1 SQL Server 2005

Seltener ist die Möglichkeit, die Parameter in einer Antwortdatei zu hinterlegen. Dieses Ver- fahren wird gerne bei Betriebsysteminstallationen verwendet. Antwortdateien liefern dabei meist erheblich mehr Optionen für die Konfiguration eines Programms.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.1: Auszug aus einer Antwortdatei zur Installation von Windows XP

Ein spezieller Fall des unattended Setups ist das so genannte Silen t Setup. Oft lässt sich die Installation mit Parametern wie /s oder /silent starten, wodurch dann eine Standardinstal- lation vorgenommen wird ohne das Parameter angegeben werden müssen. Die Installation läuft dann ohne Benutzerinteraktion und ohne visuelle Darstellung des Installationsvorgan- ges ab. Nachdem das Silent Setup und das Unattended Setup sehr oft gemeinsam genutzt werden, werden diese Begriffe synonym verwendet.

Ein großer Vorteil des Unattended Setup ist die Verwendung des originalen Installations- programmes der zu installierenden Software. Es wird auf die “Intelligenz“ des original Setups zurückgegriffen [der03]. So kann das originale Setup abhängig von den Einstellungen des Computers das Programm in ein anderes Verzeichnis installieren. Bei einigen Programmen kann auch eine auf die Architektur der CPU zugeschnittene Version installiert werden. Dies kann bei rechenintensiven Anwendungen wie CAD oder 3D-Rendering Programmen vorteil- haft sein.

Der größte Nachteil des Unattended Setups ist, dass man von den Parametern abhängig ist. In manchen Fällen kann es schwer werden an die Einstellungsmöglichkeiten in der Ant- wortdatei oder die Übergabeparameter zu kommen. Oft sind auch nicht alle Aspekte der Installation konfigurierbar, da der Hersteller dies nicht vorgesehen hat oder nur die wich- tigsten Einstellungsmöglichkeiten vorhanden sind. Kompliziert wird es auch, falls mehrere Antwortdateien für dasselbe Programm existieren. Als Beispiel sei hier das Unattended Se- tup von Windows XP genannt. Zwar ist dieser Prozess gut dokumentiert und verstanden, allerdings finden sich aber zahlreiche Fehler in der Dokumentation. Auch findet man im In- ternet noch weitere Optionen, die in der originalen Dokumentation fehlen, sowies Hinweise auf unerwünschte Seiteneffekte gewisser Optionen des Unattended Setups von Windows XP.

3.4.1 Ermittlung des Installertyps

Leider hat sich bisher unter Windows kein einheitliches Format für Installationen durch- gesetzt. Mit dem Microsoft Software Installer gibt es zwar ein standardisiertes Paketformat unter Windows, jedoch haben sich andere Installer gehalten und werden weiterhin eingesetzt. In diesem Kapitel sollen die am weitest verbreiteten Installationsroutinen kurz beschrieben und ein Überblick darüber gegeben werden wie sich diese automatisieren lassen.

Oft lohnt sich ein Blick in die Anleitung der zu installierenden Anwendung. Zumindest bei größeren kommerziellen Anwendungen finden sich hier die nötigen Parameter für die auto- matisierte Installation. Oft helfen auch die Parameter /? oder /help beim Aufruf des Setups über weiter.

Um Anwendungen automatisch zu installieren, muss man zuerst bestimmen mit welchem Typ von Installer man es zu tun hat. Einige Installer lassen sich durch typische Dateiendun- gen oder den Namen der Installationsdatei erkennen, andere wiederum durch ihr typisches Aussehen. Ein praktisches Tool zur Ermittlung des Installtionstyps ist das kostenlose Uni- versal Silent Switch Finder (USSF)². Es erkennt sehr viele Installer und zeigt die nötigen Parameter zur unattended Installation der jeweiligen Anwendung an.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.3: USSF erkennt viele Installationsprogramme und liefert die Parameter für die au- tomatisierte Installation

3.4.2 Windows Installer

Der Windows Software Installer (früher Microsoft Installer) ist eine von Microsoft zur Verfü- gung gestellte Laufzeitumgebung für Installationsroutinen unter Windows Betriebsystemen. Seit Windows 2000 wird der Windows Installer bei Microsoft Betriebsystemen mitgeliefert. Bei älteren Betriebsystemen wie Windows 95/98 kann er nachinstalliert werden. Auf den PCs läuft ein Windows Systemdienst, der für die Installation, Deinstallation und die Repa- ratur der Pakete verantwortlich ist. Er führt entsprechende Dateien mit der Endung MSI (Microsoft-Software-Installation) aus. MSI hat im Bereich der Softwareverteilung und Pake- tierung einen solch hohen Stellenwert erreicht, dass eigentlich nur noch die Abkürzung MSI für den Microsoft Installer verwendet wird - dies soll auch im Rahmen dieser Arbeit der Fall sein.

[...]

---

¹Im SAP Umfeld Anpassungen die ohne Programmierung möglich sind

²SAP ERP ist das Hauptprodukt des deutschen Softwarehauses SAP, Enterprise Resource Planning ist Software für die Einsatzplanung der in einem Unternehmen vorhandenen Ressourcen

³DirectX ist eine von Microsoft entwickelte Sammlung von Multimedia Schnittstellen für Windows

⁴Ein Hotfix ist eine Anwendung die Fehler in Software korrigiert. Die Fehler sind dabei so gravierend das sie schnell und gezielt behoben werden müssen

¹http://www.packagingrobot.com Packaging Robot von BRAIN FORCE, kommerziell

²http://www.wpiw.net/downloads/ussf.exe Download vom Hersteller

³Prozedurale Programmierung ist der Ansatz, Computerprogramme aus kleineren Aufgaben aufzu- bauen. Diese Aufgaben werden als Prozeduren bezeichnet.