Systeminstallation und Softwareverteilung

Inhaltsverzeichnis

1 Einleitung

2 Schematischer Aufbau des Verteilungsprozesses
2.1 Verteilung auf Herstellerseite (Producer Deployment)
2.2 Verteilung auf Unternehmensseite (Enterprise Deployment)
2.3 Verteilung auf Benutzerseite (User Deployment)
2.4 Modelle und Richtlinien
2.4.1 Anwendungsmodell
2.4.2 Unternehmensmodell
2.4.3 Verteilungsrichtlinien und -modelle
2.4.4 Site Models

3 Techniken und Verfahren der Softwareverteilung
3.1 Netzwerkverfahren
3.1.1 Push und Pull
3.1.2 Unicast/Multicast
3.1.3 Peer-to-Peer
3.2 Unattendend Setup
3.3 Native Installation
3.4 Snapshot-Verfahren
3.5 Windows Installer (MSI)
3.6 Imaging/Cloning
3.7 Inventarisierung und Licensing
3.8 Patch Management

4 Weitere Aspekte eines Deploymentsystems
4.1 Reporting
4.2 Hierarchiebildung
4.2.1 Gründe für Hierarchiebildung
4.2.2 Hierarchiemodelle
4.3 Hardwareunterstützung (System Preparation)
4.4 Systemmigration
4.5 Sicherheitseigenschaften

5 Anwendungen im Detail
5.1 RIS/ADS/Longhorn Deployment
5.2 Symantec Ghost/Ghost Solution Suite
5.3 Systems Management Server (SMS)
5.4 Altiris CMS
5.5 Baramundi CMS
5.6 LANDesk CMS
5.7 Fazit

6 Ausblick/Conclusion

Literaturverzeichnis

Abbildungsverzeichnis

Autorenverzeichnis

1 Einleitung

Stationäre Computer und mobile Endgeräte wie Personal Digital Assistants oder Laptops sind aus dem heutigen Geschäftsalltag nicht mehr wegzudenken. Umgestaltungen der Software–landschaft, sowie die sicherheitstechnische Pflege der Geräte bedingen Softwarelösungen, welche die IT-Abteilung eines Unternehmens bei der Programmverwaltung unterstützen. Die hohe Anzahl an Endgeräten bedingt eine automatisierbare Möglichkeit zur Systemvorbe–reitung, sowie der Installation von Betriebssystem und weiteren Anwendungen. Dabei stellt gerade die Heterogenität der Hardwareumgebung und die Erhaltung benutzerspezifischer Ein–stellungen eine nicht unerhebliche Herausforderung dar.

Abbildung in dieser Leseprobe nicht enthalten

Die automatisierte Verteilung und Wartung von Software gewinnt deshalb stetig an Bedeutung. Da sich, wie in [1] angegeben, die Innovationszyklen für System- und Anwendungssoftware verkürzen, vergrößert sich das Volumen an Software-Komponenten. Das Resultat sind immer häufigere Installationen und Programmupdates. Die Marktstudie Client Management 2002 [2] belegt, dass allein 2002 bei den befragten Unternehmen, pro System durchschnittlich neun Installationen in diesem Jahr durchgeführt wurden. Von Hand ist dieser Aufwand nur noch teuer zu bewältigen. Durch automatisierte Softwarelösungen kann hier bares Geld gespart werden.

Softwaredeploymentsysteme bieten dazu verschiedene Lösungen, um die Erfordernisse eines Unternehmens abzudecken. Schwerpunkte sind die Inventarisierung, die Verteilung und Installation von Betriebssystemen, Anwendungen und Systemeinstellungen.

Durch den Einsatz eines Softwareverteilungstools sollen vornehmlich folgende Ziele erreicht werden:

- verringerter Administrationsaufwand
- einheitliche Installationen
- schnelle Updates der Systeme
- schnelles System-Recovery
- Installationsmöglichkeit außerhalb der Arbeitszeit
- Möglichkeit für umfassende Rollouts
- zentrale Betreuung dezentraler Infrastrukturen
- Kosteneinsparung

Die vorliegende Arbeit soll aus dem Uneins der vorhandenen Informationsquellen und den verschiedenen verfügbaren Produkten und Lösungen zur Softwareverteilung, den Prozess der Softwareverteilung umfassend darstellen und Gemeinsamkeiten aufzeigen. Auch werden gän–gige Verfahren erläutert und eine Übersicht über einige, am Markt befindlichen Produkte gegeben und auf das IT-Umfeld der Universität Augsburg eingegangen.

2 Schematischer Aufbau des Verteilungsprozesses

„Application (Software) development is a complex process which covers all the activities that have to be carried out from the end of the development itself on producer sites to the actual installation and maintenance of the application on consumer computers“ ([3]).

Es ist daher sinnvoll den Ablauf der Softwareverteilung so umfassend wie möglich zu erfassen. Als Beispiele für Aktionen dieses Ablaufs, sind an dieser Stelle die Paketierung der Software beim Hersteller, ihre Übertragung vom Hersteller zum Benutzer und die Installation, Aktualisierung und eventuelle De-Installation beim Benutzer zu nennen.

Aufgrund der Schwierigkeit der zugrunde liegenden vielschichtigen Vorgänge ist speziell die Softwareverteilung im größeren Umfeld in der Regel als kritisches Thema einzustufen. Dies liegt zum einen an den immer komplexer werdenden Anwendungen selbst und zum anderen am immer komplexer werdenden Umfeld. Es gibt ständig neue und unterschiedliche Ver–sionen von Hardwarekomponenten, Betriebssystemen und Anwendungen die berücksichtigt werden müssen um einen reibungslosen Ablauf und ein ungehindertes Zusammenspiel zu ge–währleisten. Auch der zeitliche Ablauf spielt bei der Softwareverteilung eine entscheidende Rolle. Laut [3] müssen daher folgende Fragen in größeren Unternehmen unbedingt beachtet werden: Soll die Verteilung auf allen Endgeräten gleichzeitig erfolgen („big bang“, [3]) oder lieber Schritt für Schritt nach festgelegten Bereichen? Ist die Konsistenz der Systeme gesi–chert und können Wechselwirkungen mit anderen Anwendungen auftreten? Wird die Pro-duktivität des Unternehmens dadurch beeinträchtigt?

Es ist demnach in erster Linie wichtig den finanziellen und zeitlichen Aufwand und das damit verbundene Risiko so klein wie möglich zu halten und dennoch so flexibel wie möglich zu sein.

In [3] beschreiben die Autoren Coupaye und Estublier ein Modell mit drei Schichten als Grundlage für den Softwareverteilungsprozess. Dieses Modell ist auch in diesem Kapitel das Thema, da es den Sachverhalt deutlich und umfassend darlegt. Die Schichten sind die Produ–cer (Hersteller-), die Enterprise (Unternehmens-) und die User (Benutzer-) Schicht.

Abbildung in dieser Leseprobe nicht enthalten

Eine eigene Enterprise-Schicht ist in vielen Fällen nicht durch bestehende Technologien abgedeckt, da meistens nur der Verteilungsprozess zwischen einem Softwarelieferanten (producer) und einem Softwareabnehmer (user) und nicht der globale Prozess betrachtet wird. Große Unternehmen benötigen aber die Kontrolle über die Verteilung der Software. Die Software muss teil–weise erst auf das Unternehmen abge–stimmt, angepasst bzw. Erweiterungen eingebunden werden. Das Ganze muss abschließend noch getestet werden, bevor es dann in gesicherten Bahnen verteilt werden kann. Diese Faktoren können in einem Zwei-Schichten-Modell nicht ausreichend dargelegt werden. Die Autoren betrachten die Anwendungsverteilung als einen Vorgang, dessen Ak–tionen einzelne Handlungsschritte ver–körpern. Modelle und Richtlinien, die als Produkte be–zzeichnet werden, stellen eine Art Daten–fluss zwischen Aktionen und Ressourcen (Personen, Hardware, Software) dar. Das Ganze er–gibt ein, in sich geschlossenes System, da der Vorgang nicht ohne Aktionen, Produkte und Ressourcen ablaufen kann.

Die dazu erforderlich Abläufe werden in den nächsten drei Unterkapiteln beschrieben. Die zu–grunde liegenden Modelle und Richtlinien sind im Anschluss daran ausführlich dargelegt.

2.1 Verteilung auf Herstellerseite (Producer Deployment)

Abbildung in dieser Leseprobe nicht enthalten

Das Ziel des Herstellers einer Anwendung ist, diese geschlossen an den Kunden zu bringen. Dazu muss er sie nach ihrer Fertigstellung erst einmal zu einer Einheit zusammenschnüren (paketieren), um sie dann ausliefern zu können. Der Hersteller muss dazu die neue Anwendung dem Kundenkreis erst noch bekannt machen (advertise). Es muss aber auch dafür Sorge getragen werden, dass der Kunde darüber in–formiert wird, wenn alte Versionen abgekündigt werden und nicht mehr unterstützt bzw. durch neue Versionen ersetzt werden (unrelease retire, [3]).

Das Bekanntmachen der neuen Anwendung (Ad–vertising) kann beispielsweise per E-Mail, Newsletter oder direkt durch installierte Anwendungen/Dienste erfolgen. Die Vorgänge zur Bereitstellung der Anwendung werden meist durch Software Configuration Manager (Näheres siehe [4]) oder durch Paketmanager und automatisierte In–stallationslösungen (RPM [5], .deb/dpkg [6], MSI [7], InstallFromTheWeb [8], usw.) realisi]ert, die spezielle Programme für das Paketieren an–bieten.

2.2 Verteilung auf Unternehmensseite (Enterprise Deployment)

Im Folgenden werden die Aktionen, die in einem Unternehmen beim Verteilungsprozess not–wendig sind, beschrieben. Sie dienen der Vorbereitung zur tatsächlichen Verteilung der Anwendung zum Endbenutzer. Da dieser Bereich die organisatorischen Entscheidungen be–züglich des Verteilungsprozesses im ganzen Unternehmen widerspiegelt, ist er entscheidend für die Unternehmensseite [3].

Der erste Schritt nach dem Herausbringen einer neuen Anwendung ist die Übertragung zum Unternehmen (siehe Abb. 2). Diese Aktion kann vom Hersteller oder vom Unternehmen selbst ausgehen und wird abhängig davon dann unterschiedlich realisiert. Genauer wird auf die verwendeten Verfahren (Push und Pull) in Kapitel 3 eingegangen.

Abbildung in dieser Leseprobe nicht enthalten

Hat das Unternehmen die Anwendung erhalten, muss sie diese als Erstes an die unternehmenseigene Umge–bung anpassen. Dazu kann es notwendig sein, spezi–elle Erweiterungen einzubinden, Konfigurationen oder gar andere Anwendungen zu verändern, um die gegen–seitige Verträglichkeit sicherzustellen – je nach Kom–plexität, Größe und Komplikationsgrad der neuen Anwendung. Daraufhin muss das Unternehmen die modifizierte Anwendung testen und anschließend wieder ein verteilbares Paket erzeugen, bevor die Übertragung zum Endbenutzer erfolgt. Dazu stehen dem Unternehmen in der Regel ähnliche Werkzeuge wie dem Hersteller zur Verfügung. Die Anpassung ist laut [3] einer der zeit- und aufwandsintensivsten Vorgänge des gesamten Ablaufs, da sie größ–ößtenteils nicht automatisiert werden können.

Abbildung in dieser Leseprobe nicht enthalten

Der Zeitpunkt und die Art der Anwendungsverteilung werden im predispose -Vorgang festgelegt. Wie in Abb.3 dargestellt fließen generelle Richtlinien des Vertei–lungsprozesses und das allgemeine Unternehmensmodell in diesen Vorgang mit ein. In diesem Schritt werden die Organisationsstrukturen des Unternehmens durch das Unter–nehmensmodell auf den Verteilpro–zess abgebildet. Das Predispose ist also das direkte Bindeglied zwischen dem Unternehmen und dem Verteilungsprozess. In den Verteilungsrichtlinien ist festgelegt, welche Teilgruppen oder Anwendungspakete bevorzugt werden (Prioritäten), welche Abhän–gigkeiten erfüllt sein müssen und wie die Verteilung zeit–lich ablaufen soll. Aus diesem predispose- Vorgang ergibt sich das erzeugte Verteilungs–modell, das, abhängig von Funktion und Tätigkeit bzgl. der Organisationsstrukturen die Ver–teilung von Version und Art der Anwendung für jedes Zielsystem/Benutzer regelt. Das Ver–teilungsmodell wird in [3] als Szenario gesehen, welches durch die Infrastruktur des Verteil–systems ausgewertet wird, um selbstständig ablaufende Verteilungsaktionen auf den Zielsys–temen durchzuführen. Um den eigentlichen Verteilprozess starten zu können muss jetzt noch dem Zielsystem (Benutzer/Soft–wtwareagent, etc.) bekannt gemacht werden, dass eine neues Anwendungspaket bereitliegt.

Die Autoren des Quellentextes [3] weisen auf Seite 3 darauf hin, dass die Aktivitäten des predispose- Vorgangs kaum von bestehenden Technologien abgedeckt werden, obwohl er ein Kernelement des Enterprise Software Deployments ist. Dem kann ich zustimmen, da sich seit Erscheinen des zugrunde liegenden Artikels in den vergangenen fünf Jahren, in dieser Bezie––hung kaum etwas geändert hat. Das liegt daran, dass das Predispose einer der umfassendsten und komplexesten Vorgänge der gesamten Softwareverteilung ist und keine einheitlichen Standards existieren, die die verschiedenen Modelle und Richtlinien vereinen.

2.3 Verteilung auf Benutzerseite (User Deployment)

Abbildung in dieser Leseprobe nicht enthalten

Die Vorgänge, die im Bereich des Unternehmens ablaufen, liefern sowohl ein fertig verteilba–res Anwendungspaket als auch ein Verteilungsmodell, das angibt, wann und wohin die Anwendung verteilt werden soll. Ihre Übertragung auf das System des Benutzers kann wie auch im vorherigen Kapitel (2.2 Unter–nehmensseitige Verteilung) über verschie–dene Verfahren (Push und Pull) realisiert werden. Diese werden genauer in Kapitel 3.1 erläutert.

Ist die Anwendung auf das System des Benutzers übertragen worden, übernimmt die dispose Aktivität die Vorbereitung für die nachfolgenden Prozesse – ähnlich dem predispose im Unternehmensmodell. Hier fließen das Anwendungspaket selbst, das Verteilungsmodell und das „site model“, welches die Hard- und Softwarekonfigurati–on des Benutzersystems spezifiziert, in die Vorbereitung ein. Der dispose -Vorgang be–steht im Wesentlichen aus den zwei Teilak–tivitäten auswählen und auspacken. Beim Auswäh–len werden nach dem site model die passenden Optionen für die Anwendung bestimmt (verfügbarer Hauptspeicher, Festplattenka–pazität usw. – siehe [3]). Beim Auspacken wird le–diglich das Anwendungspaket entpackt. Im nächsten Schritt kann die bereitgestellte und vor–konfigurierte Anwendung entweder in–stalliert, aktualisiert werden. Es besteht auch die Möglichkeit alte Version zu deinstallieren. Die Aktualisierung bringt eine alte Version der Anwendung auf einen neuen, vom Hersteller oder Unternehmen herausgegebenen, Versions–stand. Dies können sowohl simple Pro–grammupdates als auch komplett neue Versionen der Anwendungssoftware sein. Bei der In–stallation oder Aktualisierung wird die Anwendung dann in das Benutzersystem integriert. Dazu muss sie dem System angepasst (Pro–grammpfade, Berechtigungen, Programmbibliothe–ken, etc.) und gegebenenfalls für das Sys–tem neu erstellt (bei Linuxsystemen durchaus nor–mal) und abschließend statische Tests durch–geführt werden. Oft ist es auch notwendig, dass System neu zu starten um den Installations–vorgang erfolgreich abschließen zu können. Dies ist im Hinblick auf die Überwachung des Ablaufs der Verteilung und der Installation im Spee–ziellen wichtig (siehe Kapitel 4.1 – Reporting). Sind diese Schritte erfolgreich beendet, ist auf dem System eine ausführbare Anwendung und der Verteilungsprozess für dieses System da–mmit abgeschlossen.

Der Verteilprozess auf Seite des Benutzers (bzw. die technische Seite des Verteilprozesses) ist nach Meinung der Autoren von [3] der Bereich, den von gängigen Programmen/Technologien am besten abgedeckt wird. Hier hat sich in den letzten fünf Jahren zu meinem Bedauern kaum etwas verändert. Produkte wie Microsofts System Management Server (SMS) [9], Altiris Cli–ent Management Suite [10] oder Novells ZENworks [11] decken nahezu alle Tätigkeiten des Erstellungsprozesses ab, kümmern sich aber nur beschränkt um die Umsetzung der hier ge–nannten Strukturen, zumal meistens nur zwei Schichten – Enterpise und User – betrachtet werden. Die Umsetzung der Verteilungsrichtlinien hingegen ist zu einem viel zentraleren Thema geworden, als es noch vor fünf Jahren der Fall war. Das sieht man auch an den einzel–nen Produkten von Microsoft, Altiris, Novell oder LANDesk.

2.4 Modelle und Richtlinien

Modelle dienen der Vereinfachung und Veranschaulichung von (technischen) Vorgängen. In diesem Fall spiegeln die Modelle die Informationen wieder, die den Datenfluss der Aktionen beschreiben. Diese Daten werden von den im Folgenden dargestellten Modellen erfasst.

2.4.1 Anwendungsmodell

Das Anwendungsmodell ist die Abstraktion der Anwendungssoftware. Sie umfasst alle In–formationen, die die Anwendung betreffen. Dazu gehörten die Dateien, die Dokumentation, etc. und eine Beschreibung der Architektur der Anwendung. Die Beschreibung umfasst ihre Komponenten, Voraussetzungen für Hardware und Software, interne und externe Abhängig–keiten zu anderen Programmen oder Programmteilen und diverse andere Informationen (Kon–takte, Releasedatum, usw.). Das von Microsoft und Marimba entwickelte Open Software Description Format (OSD) [12] und das Distributable Software Description Format (DSD) [13] liefern hierfür beispielsweise eine formelle Grundlage. Aber auch die von verschiedenen Application Management Systems und Software Configuration Systems bereitgestellten Anwendungsmodelle erfüllen ihren Zweck. Die Extensible Markup Language (XML) eignet sich besonders gut zur Repräsentation der Modelle und lässt sich leicht mit anderen Tools auswerten. OSD und DSD sind sogar explizit mit XML als Grundlage entworfen. Sie haben die Möglichkeit Softwareabhängigkeiten in Form von gerichteten Graphen darzustellen, was gerade bei modularen Anwendungen notwendig ist (siehe dazu [12] und [13]).

2.4.2 Unternehmensmodell

Das Unternehmensmodell ist die Abstraktion des Unternehmens. Es beschreibt die hierarchischen Organisationsstrukturen des Unternehmens und beinhaltet Abteilungen, Unter–abteilungen, Mitarbeiter und deren Positionen und Funktionen. Unternehmensmodelle lassen sich als Organigramme (Organisationsschaubilder) visualisieren. Das Unternehmensmodell kann aber auch die Prozesse und den Datenfluss zwischen Mitarbeitern darstellen, wie es z.B. in [3] angegeben wird: wenn zum Beispiel der Datenfluss für ein (Daten-)Paket von Abteilung A vorschreibt, dass Abteilung B dieses innerhalb von drei Wochen erhalten muss, dann müssen die Aktionen für dessen Verteilung nach Abteilung B innerhalb von drei Wochen fertig sein. Coupaye und Estublier bemängeln abschließend zwar, dass in den meisten Organi–sationsmodellen eine Verbindung zwischen dem Unternehmen selbst und dem einzelnen Benutzersystem (Rechner) fehlt, diese Beziehung ist aber in den meisten Firmen dadurch gegeben, dass jeder Mitarbeiter an einen eigenen Arbeitsrechner gebunden ist.

2.4.3 Verteilungsrichtlinien und -modelle

Die Verteilungsrichtlinien legen die Zustellungsart, den jeweiligen Empfänger und den Zeit–punkt fest, an dem verteilt werden soll. Wie aus Abb.3 ersichtlich wird, ergibt sich das Ver–teilungsmodell aus dem Unternehmensmodell, den Verteilungsrichtlinien und indirekt über Umwege aus dem Anwendungsmodell. In [3] ist das Verteilungsmodell das Szenario, das von der Verteilinfrastruktur (die beispielsweise eine Prozess-Engine beinhaltet) interpretiert wird, um die tatsächliche Verteilung zum Zielsystem durchzuführen. Ein besseres Verteilungs–modell wäre eine Kombination des bisherigen Modells und des Unternehmensmodells, sodass eine direkte Verknüpfung zwischen der Konfiguration einer Anwendung und der Benutzersei–te entsteht. Dann würde dem verteilenden System direkt die Informationen zur Verfügung stehen, welche Konfiguration auf welcher Seite verteilt werden muss (vgl. [3]).

Kontrolle des Prozesses

Ein Verteilungsmodell kann gemäß [3] folgende unterschiedliche Richtlinien bestimmen, um den gesamten Vorgang zu überwachen:

- Automatisch, manuell oder halbautomatisch. Im automatischen Modus läuft der Ver–teilungsprozess komplett stillschweigend ab und führt die verschiedenen Tätigkeiten selbstständig durch. Im manuellen Modus wird der Benutzer zur Bestätigungen der Aktionen aufgefordert. Im halbautomatischen Modus kann der Benutzer vorher festlegen, bei welchen Aktionen er nach einer Bestätigung gefragt werden will. Der Rest läuft dann automatisch ab.
- Wiederherstellbar oder ersetzbar: Bei wiederherstellbar macht das System in seinem letzten konsistenten Stand weiter, falls es einen Absturz während der Verteilung geben sollte. Ist es ersetzbar, so führt es eine andere (ggf. die nächste) Aktion durch.
- Einfach oder verzweigt: Wenn im einfachen Modus eine Aktivität fehlschlägt, weil be–stimmte Ressourcen fehlen, dann benutzt das Verteilsystem die Wiederherstellung oder die Ersetzung wie oben beschrieben. Im verzweigten Modus kümmert sich das verteilende System selbst um die Organisation der fehlenden Ressourcen.
- Ein Protokoll sollte erstellt werden, um nachvollziehen zu können, ob die Prozesse richtig arbeiten oder nicht (siehe dazu 4.1 – Reporting).
- usw.

Nach Meinung der Autoren ist auch hier eine Schwachstelle in der Umsetzung der Vertei–lungsrichtlinien bei gängigen Technologien zu sehen. Dies ist ein weiterer Unterschied den sie zwischen den Verteilungsmodellen, die aus gängigen Anwendungen hervorgehen, und dem des vorgestellten Enterprise Deployments, sehen.

2.4.4 Site Models

Site Models sind Abstraktionen der Zielsysteme (Desktop Computer der Benutzer) die dazu dienen, das Verteilungsmodell des Unternehmens auf die Clientsysteme individuell anzu–passen und anzuwenden. Das Site Model stellt Hardware (Prozessor, Speicherausbau, Fest–plattenkapazität, etc.) und Software (OS, Treiber, Anwendungen, bereits verteilte Komponenten, ...) der Clientsysteme dar. Die Informationen über die bereits verteilten Komponenten sind insofern wichtig, da sie von anderen Clients mitgenutzt werden können (shared access; siehe auch Kapitel 3 - Multicast).

Als Site Model kann auf das von der Distributed Management Task Force (DMTF) stan–dardisierte Common Information Model (CIM) [14] zurückgegriffen werden. Eine Imple–mentierung wird mittlerweile direkt von aktuellen Betriebssystemen bereitgestellt. Unter Windows (ab NT4.0 SP4) ist das die Windows Management Instrumentation (WMI) (siehe dazu [15] und [16]). Mit ihrer Hilfe kann man von der Ferne (remote) z.B. auf die Registry des Systems zugreifen, Prozesse starten und Hardwarekomponenten verwalten. CIM und seine Erweiterung Web Based Enterprise Management (WBEM) [17] wird nach heutigem Stand von allen ernst zunehmenden Anwendungen zur Softwareverteilung (LANDesk, SMS2003, Altiris, Tivoli) unterstützt. Die im zugrunde liegenden Artikel genannte Application Management Specification (AMS) wurde von CIM abgelöst.

Microsoft beispielsweise spezifiziert im Site Model des Systems Management Servers 2003 Computer, Benutzer, Gruppen und andere Ressourcen die vom SMS gehandhabt werden [9][18].

3 Techniken und Verfahren der Softwareverteilung

„Im Grunde kann man sich ein automatisiertes Softwareverteilungssystem als Transportmechanismus vorstellen. Es dient lediglich als Transportmittel, um einen Auftrag zur Softwareverteilung bzw. Konfiguration vom Softwareverteilungsserver zu einem Client zu transportieren. In welcher Art und Weise dieser Auftrag auf dem Client ausgeführt wird, ist abhängig von der verwendeten Technologie“ ([19]).

Da sich die Techniken und Verfahren zum einen in ihrer Handhabung und zum anderen in ihrem Einsatzbereich stark voneinander unterscheiden können, gilt es für ein Unternehmen abzuwägen, welche Verfahren am günstigsten einzusetzen sind.

Dieses Kapitel gibt einen Überblick über die, in den verschiedenen Produkten zum Einsatz kommenden, Technologien und erläutert diese. Es wird ein Einblick in verschiedene In–stallations-Methoden (Unattended Setup, Native Installation, MSI), Methoden zur Systemab–bildung (SnapShot, Imaging/Cloning) und in Verfahren der Inventarisierung und des Patch-Managements gegeben. Auch auf die, diesen Methoden zugrunde liegenden, Kommunika–tionsmodelle und Techniken der Netzwerkebene wird eingegangen.

3.1 Netzwerkverfahren

Die Verteilung von Software in einem Netzwerk setzt bestimmte Verfahren und Techniken voraus. Diese schreiben vor, wie der Datentransfer zwischen den einzelnen Teilnehmern (Cli–ents, Server) auszusehen hat oder in welcher Reihenfolge er ablaufen kann. Dabei geht es nicht nur um den Transfer als solchen, sondern auch um die involvierte Kommunikation. Diese steuert den Fluss der Transferaktion, ihren zeitlichen (oder räumlichen) Ablauf und ihre Durchführung. Sie legen außerdem die Grundsteine für einen effektiven Einsatz der zur Verfügung stehenden Ressourcen.