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
Häufig gestellte Fragen
Was ist der thematische Schwerpunkt dieses Dokuments zur Softwareverteilung?
Dieses Dokument bietet einen umfassenden Überblick über den Softwareverteilungsprozess, einschließlich Inhaltsverzeichnis, Ziele und Hauptthemen, Kapitelzusammenfassungen und Schlüsselwörter. Es behandelt schematische Strukturen, Techniken, Verfahren und weitere Aspekte von Softwareverteilungssystemen.
Welche Hauptthemen werden im Inhaltsverzeichnis behandelt?
Das Inhaltsverzeichnis umfasst Themen wie Einleitung, schematischer Aufbau des Verteilungsprozesses (Hersteller-, Unternehmens-, Benutzerseite), Techniken und Verfahren der Softwareverteilung (Netzwerkverfahren, Unattendend Setup, Native Installation, Snapshot-Verfahren, Windows Installer, Imaging/Cloning, Inventarisierung und Licensing, Patch Management), weitere Aspekte eines Deploymentsystems (Reporting, Hierarchiebildung, Hardwareunterstützung, Systemmigration, Sicherheitseigenschaften), Anwendungen im Detail (RIS/ADS/Longhorn Deployment, Symantec Ghost/Ghost Solution Suite, Systems Management Server, Altiris CMS, Baramundi CMS, LANDesk CMS), Ausblick und Schlussfolgerung.
Was sind die Ziele beim Einsatz eines Softwareverteilungstools?
Die Hauptziele sind die Verringerung des Administrationsaufwands, 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 und Kosteneinsparung.
Welche drei Schichten werden im Verteilungsprozess unterschieden?
Der Verteilungsprozess wird in drei Schichten unterteilt: die Producer (Hersteller-) Schicht, die Enterprise (Unternehmens-) Schicht und die User (Benutzer-) Schicht.
Was sind die Hauptaufgaben in der Herstellerseite (Producer Deployment)?
Die Hauptaufgaben des Herstellers umfassen das Paketieren der Software, das Bekanntmachen der neuen Anwendung (Advertising) und die Information des Kunden über abgekündigte Versionen (unrelease retire).
Welche Schritte sind auf der Unternehmensseite (Enterprise Deployment) notwendig?
Auf der Unternehmensseite sind die Übertragung der Anwendung, die Anpassung an die unternehmenseigene Umgebung, das Testen der modifizierten Anwendung und das Erzeugen eines verteilbaren Pakets notwendig. Der Zeitpunkt und die Art der Verteilung werden im *predispose* -Vorgang festgelegt.
Was beinhaltet der Verteilungsprozess auf der Benutzerseite (User Deployment)?
Auf der Benutzerseite umfasst der Prozess die Übertragung der Anwendung auf das System des Benutzers, die Vorbereitung durch die *dispose* Aktivität (Auswählen und Auspacken), die Installation, Aktualisierung oder Deinstallation der Anwendung.
Was sind Anwendungsmodelle, Unternehmensmodelle und Site Models?
Das Anwendungsmodell ist die Abstraktion der Anwendungssoftware. Das Unternehmensmodell beschreibt die hierarchischen Organisationsstrukturen des Unternehmens. Site Models sind Abstraktionen der Zielsysteme (Desktop Computer der Benutzer) die dazu dienen, das Verteilungsmodell des Unternehmens auf die Clientsysteme individuell anzupassen und anzuwenden.
Welche Netzwerkverfahren werden bei der Softwareverteilung eingesetzt?
Zu den Netzwerkverfahren gehören Push und Pull, Unicast/Multicast und Peer-to-Peer.
Was sind Unattended Setup, Native Installation, Snapshot-Verfahren und Windows Installer (MSI)?
Dies sind verschiedene Installationsmethoden. Unattended Setup ermöglicht automatische Installationen ohne Benutzereingriff. Native Installation nutzt die systemspezifischen Installationsroutinen. Snapshot-Verfahren erstellen ein Abbild des Systems vor und nach der Installation. Windows Installer (MSI) ist ein Installationsdienst von Microsoft.
Was beinhalten Inventarisierung und Patch Management?
Inventarisierung umfasst die Erfassung von Hard- und Softwarekomponenten. Patch Management beinhaltet die Verteilung und Installation von Software-Updates und Sicherheits-Patches.
- Citar trabajo
- Florian E. Mücke (Autor), Adalbert Ochotta (Autor), 2006, Systeminstallation und Softwareverteilung, Múnich, GRIN Verlag, https://www.grin.com/document/110916
