Entwurf und Implementierung eines Client/Server basierten Management-Pakets zur automatisierten Verteilung und Wartung von Software

Transkript

1 Studiengang: Softwaretechnik Prüfer: Betreuer: Prof. Dr. rer. nat. Otto Eggenberger Prof. Dr. rer. nat. Otto Eggenberger begonnen am: 23. Juni 2004 beendet am: 15. Dezember 2004 CR-Klassifikation: K.6.4 (System Management) Diplomarbeit Nr Entwurf und Implementierung eines Client/Server basierten Management-Pakets zur automatisierten Verteilung und Wartung von Software Alexander Hartelt ZDI

2 Inhaltsverzeichnis 1 Einführung 4 2 Das aktuelle Szenario und die vorhandene Lösung Einleitung Die Rechnerpools Die Windows-Umgebung Die Linux-Umgebung und deren Administration Administration der Windows-Umgebung Überblick Symantec Ghost Corporate Edition Vor dem Erstellen des ersten Images Konfiguration des Servers Erstellen weiterer Vorgänge Verbreiten eines Images auf alle Rechner Erzeugen eines Images im normalen Betrieb Zusammenfassung Die offenen Probleme Einleitung Synchronisation von Linux und Windows Windows-Updates Remote-Installation von Programmen Übersicht über alle Rechner Zusammenfassung Mögliche Lösungen für die offenen Probleme Einleitung Synchronisation von Linux und Windows Windows-Updates Remote-Installation von Programmen Übersicht über alle Rechner

3 5 Entwurf konkreter Lösungen Hilfsklassen unter Windows Database.cs FileLogger.cs UserLookup.cs Synchronisation von Windows und Linux WinLogger.cs parselog.cpp ShutdownServiceV2 (Service1.cs) SMTConfigurator (Form1.cs) Logout (Form1.cs) Neustart unter Linux Windows-Updates Service1.cs UpdateLogger.cs UpdateConfigurator (Form1.cs) Intranet-Seiten Allgemeiner Aufbau einer PHP-Datei index.php current.php errorlog.php, systemlog.php, updatelog.php, userlog.php reboot.php showdetails.php pagefunctions.php dbfunctions.php Zusammenfassung Installation der implementierten Software MySQL-Datenbank WWW-Seiten Windows-Applikationen DLL-Dateien Windows-Update-Dienst Dienst zum Neustarten der Rechner Logging-Applikation Linux-Applikationen Parser für die Log-Dateien Konfiguration zum Neustarten der Rechner Zusammenfassung und Ausblick 66 2

4 A Windows-Update V4 68 A.1 Der Update-Vorgang A.1.1 Die Anfrage A.1.2 Die Antwort A.1.3 Die Providers-Query A.1.4 Die Products-Query A.1.5 Die Items-Query A.1.6 Die Itemdetails-Query B Sysprep.inf 81 Glossar 83 3

5 Kapitel 1 Einführung Diese Diplomarbeit ist innerhalb der Abteilung ZDI der Fakultät Informatik entstanden. Das Ziel ist es, für den studentischen Grundstudiums- und den Microsoft-Pool ein Client-Server basiertes Management-Tool zu entwickeln, um verschiedene Probleme auf eine automatisierte Art zu lösen, welche innerhalb der letzten drei Jahre, vor allem in Verbindung mit dem Betriebssystem Windows der Firma Microsoft, aufgetreten sind und bisher nur auf manuelle Art gelöst werden. Dazu gehört vor allem das Problem, daß Betriebssystem-Updates, welche mögliche Sicherheitslücken schließen, bisher nur in einem aufwendigen Prozeß durch die Systemadministration auf den Rechnern verteilt werden können. Um dieses Problem automatisiert zu lösen, wird in dieser Diplomarbeit ein Update-Client entwickelt, welcher diese Arbeit der Systemadministration abnimmt. Außerdem wird beschrieben, wie der Windows-Update-Prozeß genau funktioniert, um die Arbeitsweise dieses Clients zu verstehen. Daneben werden weitere Probleme gelöst, um z.b. an zentraler Stelle festzuhalten, welche Benutzer sich wann auf welchem Rechner eingeloggt haben. Dieses Dokument ist wie folgt strukturiert: Nach dieser Einleitung folgt eine Beschreibung des aktuellen Szenarios und der vorhandenen Lösung. Hier wird also die Umgebung beschrieben, unter welcher das zu entwickelnde System später eingesetzt werden soll. Anschließend werden die noch offenen Probleme beschrieben, welche eine automatisierte Lösung bekommen werden. Das nächste Kapitel bildet eine Beschreibung aller verschiedenen Lösungsmöglichkeiten, welche die Grundlage für die Implementierung des Client-Server-Systems bilden, deren Entwurf und Implementierung im darauf folgenden Kapitel erläutert wird. Den Abschluß dieses Dokumentes bildet eine Zusammenfassung der erreichten Ergebnisse und ein Ausblick, welche Punkte in einer weiteren Studien- oder Diplomarbeit zusätzlich betrachtet werden könnten. 4

6 Kapitel 2 Das aktuelle Szenario und die vorhandene Lösung 2.1 Einleitung Dieses Kapitel soll dem Leser einen Überblick über die aktuelle Ist-Situation der beiden studentischen Rechnerpools der Abteilung ZDI geben. Dabei wird zum größten Teil auf die Windows-Umgebung eingegangen, da unter Linux bereits eine sehr gute Lösung der meisten Probleme, welche während der Systemadministration anfallen, besteht, und diese bereits dokumentiert ist. 1 Den größten Teil dieses Kapitels nimmt Teil 2.5 Administration der Windows-Umgebung auf Seite 8 ein, in welchem detailliert die Verteilung des Windows-Betriebssystems mit der kompletten Software-Ausstattung auf allen Rechnern beschrieben wird. 2.2 Die Rechnerpools Die studentischen Rechnerpools der Fakultät Informatik, Abteilung ZDI, sind vor allem deshalb eingerichtet, um es den Studenten zu ermöglichen, verschiedene Tätigkeiten, welche mit dem Studium verbunden sind, an den Rechnern der Universität zu erledigen. Zu den hauptsächlichen Aufgaben gehört dabei die Entwicklung von Software in verschiedenen Programmiersprachen und der dazugehörigen Dokumentation. Außerdem besitzt jeder Student ein eigenes Homeverzeichnis, in welchem er seine Dateien ablegen kann, sowie eine persönliche -Adresse, über die er im Zeitraum des gesamten Studiums erreichbar ist. 1 Diese Dokumentation befindet sich unter dokumentation/wiki/admindoku 5

7 Der modernere der beiden Rechnerpools besitzt 70 Arbeitsplätze. An jedem Arbeitsplatz befindet sich ein Computer, welcher mit einem Pentium III 600MHz-Prozessor, 256MB Arbeitsspeicher und einer 22GB-Festplatte ausgerüstet ist. Dabei ist einer dieser Computer behindertengerecht mit einer speziellen Tastatur und drahtlosen Maus ausgestattet. Ein weiterer Computer ist für die Benutzerberatung eingerichtet, welcher eine größere Festplatte und einen CD-Brenner besitzt. Desweiteren befindet sich in jedem Rechnerpool ein Drucker, auf welchem die Studenten ihre Arbeiten ausdrucken können. Die Computer beider Pools sind mit mehreren Servern über ein Netzwerk mit dem Maschinenraum verbunden. Auf diesen liegen alle Homeverzeichnisse, Passwörter, Konfigurationen und Log-Dateien. Die Server erledigen die Login-Vorgänge, kopieren Dateien auf die Rechner und wieder zurück und sind für die Änderung von Passwörtern und verschiedene andere Vorgänge zuständig. 2.3 Die Windows-Umgebung An den studentischen Computern der Universität arbeiten im Laufe der Zeit, im Unterschied zu den Computern einer Firma oder eines privaten Anwenders, nicht nur einer sondern etwa 1000 Benutzer. Dies ist also eine echte Multiuser-Umgebung. Zusätzlich kommt hinzu, daß spezielle Sicherheitsrichtlinien notwendig sind, damit die Studenten nicht irgendwelche Systemeinstellungen so verändern, um einem nachfolgenden Studenten das Arbeiten zu erschweren. Bereits während der Installation des Betriebssystems hat sich herausgestellt, daß sowohl Windows 2000 als auch Windows XP Professional nicht hundertprozentig für diese Art von Umgebung geeignet sind. Es entsteht der Eindruck, daß die Firma Microsoft und auch andere Hersteller von Software für diese Betriebssysteme davon ausgehen, daß ein Benutzer am Rechner immer über Administrationsrechte verfügt. Da dies in den Rechnerpools nicht der Fall ist, kommt es bei vielen Anwendungen zu Problemen, falls diese ihre Konfigurationsdateien in einem Systemordner ablegen. Ein Schreibvorgang wird in diesem Fall abgebrochen, weil der Benutzer nicht die entsprechenden Rechte hat, in solch einem Ordner etwas zu verändern. Dieses Verhalten wurde beispielsweise bei der Anwendung Corel Draw 10 entdeckt. Nur durch manuelle Änderungen in der Registry von Windows und durch das Entwickeln eines eigenen Installationsprogrammes, welches der Benutzer vor dem ersten Start der Anwendung ausführen muss, konnte dieses Fehlverhalten behoben werden. Andere Programme, wie beispielsweise das Programm Microsoft Outlook 6

8 2000 besitzen zwar nicht diesen Fehler, kommen jedoch mit den Roaming Profiles nicht klar. Diese Art von Programmen schreiben Dateien in einen versteckten Ordner im Benutzerverzeichnis, welches beim Abmelden am Rechner nicht mit auf den Server synchronisiert wird. Deshalb muss der Benutzer nach dem nächsten Anmelden auf dem gleichen oder einem anderen Rechner diese Anwendung erneut konfigurieren. Im Falle von Microsoft Outlook gehen dabei also alle s bei einem Abmeldevorgang verloren. Neben der installierten Basis-Software (u.a. Microsoft Office und Visual Studio) gibt es, je nach Semester und Übungsleiter, weitere Software, welche nach Bedarf installiert wird. Dabei handelt es sich unter anderem um verschiedene Compiler, Entwicklungsumgebungen, Entwurfswerkzeuge oder beispielsweise auch um Webserver. Diese Art von Software wird nach dem Ende der jeweiligen Übung meistens wieder vom System entfernt. Für manche Übungen oder Seminare werden die Rechner auch komplett gelöscht und nach der Übung das Betriebssystem und die Software wieder hergestellt (für weitere Details siehe Kapitel 2.5 auf Seite 8). Zusätzlich zu den oben genannten Anwendungen sind weitere eigene Programme installiert. Neben dem Installationsprogramm von Corel Draw 10 gibt es für den Benutzer ein Programm, mit welchem die Installation von Microsoft Outlook erleichtert wird. Außerdem laufen Programme im Hintergrund, um die Rechner zu einer bestimmten Uhrzeit herunterzufahren, einen Benutzer auszuloggen und um diesen wichtige Meldungen (die sogenannte Message of the Day ) nach dem Einloggen anzuzeigen. Der Vollständigkeit halber folgt in dem nächsten Kapitel eine Übersicht über die Linux-Umgebung und deren Administration. Dies ist jedoch nur eine kurze Beschreibung, da sich dieses Dokument hauptsächlich mit der Windows-Umgebung beschäftigt und unter Linux bereits eine gute Lösung existiert mit welcher die meisten Probleme behoben sind. 2.4 Die Linux-Umgebung und deren Administration Im Grundstudiumspool der Fakultät Informatik ist neben Windows XP zur Zeit das Fedora Linux Core 1 installiert. Hier laufen, ähnlich wie unter Windows, neben der Basis-Software, welche jedoch unter Linux schon einige hundert Programme umfaßt, Programme für die verschiedensten Vorlesungen und Übungen. Zur Installation des Betriebssystems auf allen Rechnern wird die Kickstart Installation der Firma Redhat verwendet, welche, nach 7

9 entsprechender Konfiguration, eine vollautomatische Installation ermöglicht und alle benötigten Programme auf die Rechner installiert. Um während des laufenden Betriebes Updates und zusätzliche Software zu installieren, wird ein selbstentwickeltes Skript zusammen mit einer cfengine2 verwendet. Diese Lösung installiert die neue Anwendung oder das Update auch, während ein Benutzer eingeloggt ist. Die Installation verläuft für den Benutzer völlig unbemerkt. Zur Installation können fertige RPMund TAR-Dateien sowie ganze Verzeichnisse angegeben werden. Hier wird der Vorteil von Linux genutzt, da die meisten Installationen ohne irgendwelche Zwischenfragen ablaufen. Leider funktioniert die Installation eines Programmes unter dem Betriebssystem Windows nicht so problemlos. Unter diesem System wird der Benutzer während der Installation durch mehrere Dialoge geführt. Diese Art von Installation hat für den ungeübten Benutzer den Vorteil, daß dieser nicht irgendwelche Befehle eingeben muß. Für eine Administration mehrerer Rechner stellt dies jedoch einen großen Nachteil dar - im ungünstigsten Falle muß der Administrator auf mehreren Rechnern die zu installierende Software manuell aufspielen. Im folgenden Kapitel wird nun gezeigt, wie an der Fakultät Informatik im Grundstudiums- und Microsoft-Pool das Betriebssystem Windows XP mit der kompletten Software, durch das Erstellen und Verbreiten von Partitions-Images einer Festplatte, verteilt wird. Der Aufwand ist hier etwas größer als das Verteilen der Software unter Linux, da bereits das Erzeugen eines Images und das anschließende Verteilen etwa zwei Stunden in Anspruch nimmt, ohne daß irgendeine neue Software installiert wird. Nach meinen eigenen Erfahrungen lohnt sich dieses Vorgehen erst, wenn auf mindestens 5-10 Rechnern (je nach Dauer der eigentlichen Installation der Software) neue Programme installiert werden sollen. 2.5 Administration der Windows-Umgebung Überblick Das Betriebssystem Windows XP der Firma Microsoft wird im Grundstudiums- und Microsoft-Pool auf allen Rechnern verteilt, indem zuerst auf einem zufällig gewähltem und am besten neu formatierten Rechner das Betriebssystem und die komplette Softwareausstattung manuell installiert wird. Anschließend wird von der Festplatten-Partition, auf welcher das Betriebssystem installiert wurde, mit Hilfe des Programmes Symantec 2 8

10 Ghost Corporate Edition eine 1:1-Kopie (ein sogenanntes Image ) erstellt. Diese wird auf dem Server gespeichert und anschließend zeitgleich auf allen Rechnern verteilt. Da das Image auf dem Server gespeichert bleibt, ist es ohne großen Aufwand möglich, es erneut auf einen oder mehrere Rechner zu verteilen, falls es einmal zu Problemen mit dem Betriebssystem kommen sollte (z.b., wenn ein Benutzer den Rechner ausschaltet, ohne diesen zuvor herunterzufahren oder bei einem Virenbefall). Es folgt nun eine Beschreibung der Software Symantec Ghost Corporate Edition. Es wird sich sowohl hier als auch im weiteren Verlauf dieses Dokumentes auf die Software in der Version 7.5 bezogen, da diese im Augenblick für beide Rechnerpools verwendet wird. Anschließend wird gezeigt, wie in beiden Rechnerpools mit Hilfe dieses Programmes das Partitions-Image einer Festplatte erstellt und verbreitet wird. Am Ende dieses Kapitels wird gezeigt, wie bestimmte Sicherheitsrichtlinien über die ActiveDirectory-Technologie an die Rechner weitergegeben werden und wie die Zusammenarbeit zwischen Windows und Linux funktioniert Symantec Ghost Corporate Edition Symantec Ghost Corporate Edition wird für den Grundstudiums- und Microsoft-Pool zur Zeit in der Version 7.5 verwendet. Das Paket besteht aus einer Sammlung von Werkzeugen, um Festplatten- oder Partitions-Images zu erstellen und zu verbreiten. An der Fakultät Informatik wird Symantec Ghost Corporate Edition eingesetzt, da es gegenüber der Konkurrenz-Produkte einige Vorzüge besitzt. Unter Symantec Ghost ist es möglich, jedem Rechner eine eigene Konfiguration, d.h. in unserem Falle einen eindeutigen Computer-Namen zu geben. Außerdem stellt die Zusammenarbeit mit dem Linux-Bootmanager (Grub) für Ghost kein Problem dar. Nach dem Start des Vorgangs zur Verteilung eines Images deaktiviert Symantec Ghost den Bootmanager Grub automatisch, da die Computer während des Vorganges des öfteren neu gestartet werden und normalerweise der Bootmanager Grub, welcher ansonsten immer nach einem Neustart des Rechners angezeigt wird, nach 30 Sekunden das Betriebssystem Linux startet. Ein weiterer Vorteil von Symantec Ghost ist es, daß es mit dem ActiveDirectory von Microsoft Windows zusammenarbeitet. Dies bedeutet, daß die Rechner, welche ein neues Image bekommen, automatisch in das ActiveDirectory hinzugefügt werden. Außerdem unterstützt Symantec Ghost die Verteilung der Images über Multicast. Dies bedeutet, daß das Image nicht an alle Rechner einzeln über das Netzwerk gesendet wird, sondern der Server das Image einmal sendet und alle Rechner auf diesen Server hören. Dies führt 9

11 zu einer weit geringeren Auslastung des Netzwerks. Außerdem besitzt Ghost die Möglichkeit, die eindeutige SID eines Rechners noch im DOS-Modus, d.h. direkt nach dem Aufspielen des Images, zu ändern. Dies ist notwendig, da nach dem Aufspielen des Images jeder Rechner die selbe SID besitzt, wodurch es beim ersten Start nach Windows XP zu Problemen kommen könnte. Desweiteren wird das Programm Microsoft Sysprep unterstützt. Dieses wird nach dem ersten Start von Windows XP verwendet, um die Hardware-Erkennung durchzuführen und einige Dialoge während des Mini-Setups, welches beim ersten Neustart automatisch ausgeführt wird, zu beantworten. In diesem Mini-Setup werden einige Details zur Konfiguration von Windows XP, wie beispielsweise der Produkt-Schlüssel und die Netzwerkeinstellungen, abgefragt. Symantec Ghost besitzt leider nicht nur Vorteile. Ein großer Nachteil ist, daß kein Client für Linux zur Verfügung steht. Dies bedeutet, daß alle Rechner, welche unter Linux laufen, vor dem Verbreiten eines Images manuell nach Windows gestartet werden müssen. Außerdem besitzt Symantec Ghost einige Probleme im Bereich der Zusammenarbeit mit dem ActiveDirectory. Die Rechner können zwar in das ActiveDirectory automatisch eingefügt werden, landen jedoch an der falschen Stelle, da die Position nicht konfigurierbar ist. Daneben werden die Rechner nicht in alle ActiveDirectories innerhalb der Domäne eingetragen, sondern lediglich auf einem Server. Dies hat zur Folge, daß unerklärliche Phänomene nach der Installation des Images auf die Rechner auftreten können, d.h. die Benutzer können sich beispielsweise nicht an der Domäne Informatik anmelden, obwohl diese wählbar ist. Die Stärken von Symantec Ghost liegen vor allem im Bereich der Verbreitung kompletter Images. Es wird zwar auch die Verbreitung einzelner Programme unterstützt, welche jedoch im MSI-Format vorliegen müssen. Da die meisten Programme jedoch nicht als MSI-Datei ausgeliefert werden, sondern eine dialog-geführte Installation besitzen, ist diese Möglichkeit, einzelne Programme zu installieren, nur sehr selten brauchbar. Symantec Ghost besitzt auch ein Tool, welches die Erstellung von MSI-Paketen erlaubt, indem auf einem Testrechner vor und nach der Installation ein Abbild der aktuellen Dateien auf der Festplatte und aller Registry-Einträge erstellt wird und beide Abbilder verglichen werden. Da jedoch im Hintergrund während der Installation weitere Programme und Systemdienste laufen, hat sich das Tool als kaum brauchbar herausgestellt, da sich meistens mehr Dateien ändern, als während der Installation vorgesehen. Es gibt zwar auch die Möglichkeit, manuell zu entscheiden, welche Änderungen in das MSI-Paket sollen und welche nicht. Vergleicht man jedoch den zeitlichen Aufwand zwischen der Art, ein Programm per MSI-Paket oder per neuem Image zu 10

12 verbreiten, so ist die Methode mit dem neuen Image meistens die bessere. Eine Produktbeschreibung von Symantec Ghost und eine Testversion finden Sie unter[2] Vor dem Erstellen des ersten Images Bevor das erste Image auf die Rechner verteilt werden kann, muß es natürlich erst einmal erstellt werden. Dazu sollte zuerst ein Rechner gefunden werden, welcher von der Hardware ähnlich wie der Zielrechner ausgestattet ist, da vor allem dann, wenn der IDE-Controller nicht mit dem der Zielrechner identisch ist, Problemen auftreten können, d.h der Zielrechner wird nur dann booten, wenn spezielle Parameter in der Konfigurations-Datei von Sysprep 3 (siehe Anhang B) angegeben werden. Der nächste Schritt besteht darin, ein Windows-Betriebssystem (in unserem Falle Windows XP) auf dem Quellrechner zu installieren. Dies geschieht ganz normal durch eine manuelle Installation über die Windows-CD. Die Zielrechner werden am Ende die Konfiguration vom Windows-Betriebssystem und der dazugehörigen Software genauso erhalten, wie sie auf dem Quellrechner angegeben wird. Lediglich der Rechnername und die IP-Adresse wird durch Symantec Ghost auf dem jeweiligen Zielrechner angepaßt. Ist Windows-XP installiert und gegebenenfalls aktiviert, so sollten auf dem Quellrechner alle Softwarepakete so installiert und konfiguriert werden, wie diese dann später auf den Zielrechnern zu finden sein sollen. Wenn möglich, sollte eine Windows-Version gewählt werden, welche nicht aktiviert werden muß, da ansonsten alle Rechner, welche nicht die selbe Hardware-Konfiguration wie die Quellrechner besitzen, manuell erneut aktiviert werden müssen. Ist die komplette Software auf dem Quellrechner installiert und konfiguriert, so kommt das Programm Symantec Ghost Corporate Edition ins Spiel. Von der Installations-CD wird als erstes das Programm Ghost Console Client auf den Quellrechner innerhalb von Windows installiert. Während der Installation sollte, wenn möglich, der Name des später verwendeten Servers mit angegeben werden, obwohl diese Eingabe optional ist. So können Probleme minimiert werden. Nach der Installation des Console Clients auf dem Quellrechner sollte die Installation der Ghost Enterprise Console auf dem Server durchgeführt werden. Anschließend muß diese, je nach Version, bei Symantec 3 cai oziz.asp 11

13 registriert werden. Ist auch dies erledigt, so wird als nächster Schritt eine Netzwerk-Boot-Diskette mit dem Ghost Boot Wizard erzeugt. Um vom Quellrechner das erste Image herzustellen, wird dieser von der soeben erstellten Netzwerk-Boot-Diskette neu gestartet. Auf dem Server wird der GhostCast Server geladen und so konfiguriert, daß ein Image von der entsprechenden Partition des Quellrechners erzeugt wird. Mit einem Klick auf Accept clients wartet der Server auf den Quellrechner. Diesen verbindet man mit dem Server, indem eine Multicast-Verbindung gestartet und der auf dem Server eingegebene Session-Name angegeben wird. Erscheint der Rechner auf der GhostCast Server -Oberfläche, so wird mit einem Klick auf Send das Image vom Quellrechner zum Server gesendet. Ist der Vorgang beendet, so kommen die Zielrechner (inklusive dem Quellrechner, falls dieser zu den Zielrechnern gehört) an die Reihe. Auf diesen muß eine Ghost Boot-Partition installiert werden, damit die Rechner später von der Ghost Enterprise Console aus gesteuert werden können. Um ein Image dieser Partition zu erzeugen, wird der bereits bekannte Ghost Boot Wizard gestartet und die Console Boot Partition erzeugt, welche anschließend auf alle Zielrechner verteilt wird. Dies ist etwas aufwendiger, da das Image nur manuell verteilt werden kann. Dazu startet man auf dem Server den GhostCast Server, konfiguriert diesen so, daß das soeben erzeugte Image als kompletter Inhalt auf die Festplatte der Zielrechner gesendet werden soll und klickt auf Accept clients. Die Zielrechner verbindet man, wie schon vorher mit dem Quellrechner geschehen, über eine Multicast-Verbindung (oder, wie in unserem Falle, einer Unicast-Verbindung, da hier die Multicast-Verbindung nicht richtig funktioniert) und der Angabe des Session-Namens mit dem Server. Sind alle Rechner auf dem Server erschienen, so wird das Image mit einem Klick auf Send an alle Zielrechner übertragen. Ist der Vorgang beendet, werden alle Rechner neu gestartet, damit diese die soeben übermittelte Boot-Partition laden und auf Befehle der Ghost Enterprise Console warten. Um nicht alle Rechner per Boot-Diskette zu starten und diese mit dem Server zu verbinden, gibt es in unserem Falle eine weitere Möglichkeit, das Boot-Image an die Zielrechner zu übermitteln. Da neben Windows XP auf jedem Rechner Linux installiert ist, kann mit Hilfe von Linux zuerst die notwendige Partition mit der benötigten Größe automatisch auf jedem Rechner erstellt werden, wobei auch eine erneute Installation von Linux notwendig ist.anschließend kann mit dem Linux-Befehl dd die Partition kopiert und verteilt werden. Nach der Verteilung dieser Partition muß der Typ von Hidden FAT12 auf FAT12 geändert und diese aktiviert werden, damit nach einem Neustart diese Partition geladen wird. Wird auf dem Server die Enterprise Console gestartet, so erscheinen 12

14 dort alle Rechner, welche erfolgreich die Ghost-Partition geladen haben. Die nächsten Schritte sind das Erstellen eines Images innerhalb der Enterprise Console, neuer Rechner-Konfigurationen und neuer Tasks und einer Sysprep-Konfiguration, um das Image zu verteilen. Eine detaillierte Beschreibung dieses Vorgehens ist im nächsten Kapitel zu finden Konfiguration des Servers Als nächster Schritt sollte die Enterprise Console konfiguriert werden, damit die bereits wartenden Rechner ihr Windows-Image bekommen. Dazu wird als erstes innerhalb der Default-Rechnergruppe nachgesehen, ob alle Rechner vorhanden sind. Diese sind jeweils mit ihrer MAC-Adresse bezeichnet. Nachdem einmal ein Rechner innerhalb eines Vorganges einen Namen bekommen hat, wird dieser anstelle der MAC-Adresse zu sehen sein. Sind nicht alle Rechner vorhanden, so gibt es wahrscheinlich Probleme mit der Netzwerkverbindung oder der Rechner hat nicht erfolgreich die Boot-Partition gestartet. Es ist sinnvoll, die Rechner zu gruppieren, da später ein Vorgang jeweils auf einer Rechnergruppe ausgeführt werden kann. Da es auch möglich ist, innerhalb einer Gruppe weitere Untergruppen zu erstellen, ist es denkbar, für jeden Rechner eine Gruppe anzulegen. Dann ist es jederzeit möglich, von der MAC-Adresse auf den zugehörigen Rechner zu schließen und diese Gruppen jeweils in eine Obergruppe zu verschieben. Kopieren lassen sich die Rechner zwar auch, da es jedoch nur möglich ist, einen Rechner zu löschen, wenn dieser in keinem Vorgang mehr eingebunden ist, kann das Kopieren der Rechner zum Chaos führen. Als nächstes erstellt man für jeden Rechner eine eigene Konfiguration. Dazu gibt man im Dialog zum Erstellen einer neuen Konfiguration unter Namen am besten den Rechnernamen an, um die Konfiguration später eindeutig identifizieren zu können. Die Einstellung Zielbetriebssystem wird entsprechend dem Betriebssystem, welches im Image vorhanden ist, eingestellt. Nun wird Kennung ausgewählt, die Einstellung Rechnername zuweisen aktiviert und der Name des Rechners so eingegeben, wie er später unter Windows erscheinen soll. Falls der Rechner zu einer Domäne oder Arbeitsgruppe hinzugefügt werden soll, werden auch hier die notwendigen Einstellungen angegeben. Zum Schluß wird TCP/IP-Einstellungen aktiviert und hier angegeben, ob der Rechner die IP via DHCP erhalten oder diese in den Unterpunkten statisch angegeben werden soll. Mit einem Klick auf Ok wird die Konfiguration gesichert. Auf diese Weise ist mit den weiteren Konfigurationen für die restlichen Rechner fortzufahren. Nach der Gruppierung der Rechner und dem Erstellen der 13

15 Konfigurationen können nun neue Vorgänge erstellt werden. Zuerst einmal wird ein Vorgang benötigt, um das erstellte Image zu verteilen. Dazu wird ein neuer Vorgang erzeugt und wie folgt konfiguriert: Im Reiter Allgemein wird ein passender Name für diesen Vorgang vergeben (die Vorgänge werden später alphabetisch sortiert). Unter Vorgangsschritte wird Duplizierung, Konfiguration, Konfigurationsaktualisierung und, falls nach dem Aufspielen des Images der Linux-Bootmanager deaktiviert werden soll, da Windows 3-4 mal neugestartet wird, bis alle Konfigurationen abgeschlossen sind, der Punkt Befehl ausführen aktiviert. Unter Zielrechnergruppe / Zielrechner wird die soeben erstelle Rechnergruppe angegeben. Im Reiter Netzwerk werden die Einstellungen an das eigene Netzwerk angepaßt. In unserem Falle wird die Einstellung Datenübertragungsmodus aktiviert und diese auf Direkte Rundsendung eingestellt, da die Einstellung Multicasting nicht funktioniert, d.h. die Rechner empfangen mit dieser Einstellung nicht das komplette Image. Im Reiter Duplizierung wird die Einstellung In Partition laden aktiviert, unter Ziellaufwerk die Nummer der Festplatte eingestellt, auf welche das Image soll (in unserem Falle 1 ) und unter Zielpartition die gewünschte Partition eingestellt, wobei die Ghost-Partition die Nummer 1 besitzt (in unserem Falle besitzt die Zielpartition die Nummer 3, da sich auf Nummer 2 die Boot-Partition von Linux befindet). Im Feld Image wird das neu erzeugte Ghost-Image mit einem Klick auf Durchsuchen gewählt. Unter Quellpartition wird die Partition angegeben, welche aus dem Image auf die Zielrechner kopiert werden soll. Wichtig ist, die Option Mit GhostWalker die Sicherheits-ID auf dem Zielrechner ändern unbedingt zu aktivieren, da es ansonsten auf den Zielrechnern innerhalb des Windows-Netzwerkes zu Problemen kommen könnte. Im Reiter Konfiguration wird der Punkt Benutzerdefiniert gewählt und die Einstellung Standardeinstellungen aktiviert. Mit einem Klick auf Anpassen wird ein Konfigurations-Dialog geladen, welcher jedem Rechner die passende Konfiguration zuordnet. Soll der Bootmanager von Linux deaktiviert werden, so wechselt man als nächstes in den Reiter Befehl. Dort werden folgende zwei Befehle hinzugefügt, welche jeweils in der Ghost-Bootpartition ausgeführt werden sollen: gdisk 1 /act /p:3, welcher die 3. Partition (also die Windows-Partition) aktiviert und gdisk 1 /hide /p:1, welcher die Ghost-Bootpartition versteckt. Somit wird nach einem Neustart der Zielrechner Windows gestartet. Mit einem Klick auf Ok wird der soeben konfigurierte Vorgang erstellt. Ist Ok nicht wählbar, so wurde in irgend einem Reiter eine notwendige Einstellung nicht getätigt. In diesem Fall sollten noch einmal 14

16 alle Einstellungen überprüft werden. Bevor der Vorgang nun ausgeführt wird, sollten noch einmal die folgenden Kapitel betrachtet werden, da möglicherweise noch weitere Vorbereitungen getroffen werden müssen Erstellen weiterer Vorgänge Damit ein Image auch automatisiert erstellt werden kann und nicht mehr über den GhostCast Server geholt werden muß, kann ein weiterer Vorgang erstellt werden, welcher diese Aufgabe erledigt. Diesem wird wieder ein entsprechender Name gegeben. Unter Quellrechner wird der Rechner gewählt, von welchem das Image geladen werden soll. Wie bei allen Einstellungen ist es auch hier möglich, diese jederzeit zu ändern. Unter dem Feld Image-Name wird mit einem Klick auf Durchsuchen entweder ein bereits existierendes Image, welches überschrieben werden soll, oder ein neues Image gewählt. Unter Image-Komprimierung empfiehlt sich die Einstellung Schnell, da dies kaum Geschwindigkeits-Nachteile gegenüber der Option Keine besitzt, Hoch sich jedoch als extrem langsam herausgestellt hat. Im Reiter Netzwerk sind die selben Einstellungen wie beim vorher beschriebenen Vorgang zum Verbreiten eines Images, zu tätigen. Im Reiter Sysprep werden alle drei Einstellungen aktiviert. Mit einen Klick auf Sysprep-Konfigurationen wird eine neue Konfiguration erstellt und mit einem Klick auf Sysprep.inf bearbeiten eine Sysprep.inf-Datei angegeben. Die bei uns verwendete Datei ist im Anhang dieses Dokumentes zu finden. Mit einem Klick auf Ok wird auch dieser Vorgang gespeichert. Die Anwendung dieses Vorgangs wird im übernächsten Kapitel beschrieben. Falls im Vorgang zum Verbreiten eines Images der Linux-Bootmanager deaktiviert wird, so wird ein weiterer Vorgang erstellt, welcher den Bootmanager wieder aktiviert. Dazu ist im Reiter Allgemein lediglich die Einstellung Befehl ausführen zu aktivieren, ein Name für den Vorgang und eine Zielrechnergruppe anzugeben. Im Reiter Befehl wird der Befehl gdisk 1 /act /p:2 angegeben, welcher in der Ghost-Partition ausgeführt wird. Mit diesem Befehl wird die Linux-Boot-Partition (in unserem Falle die 2. Partition der 1. Platte) aktiviert. Mit einem Klick auf Ok ist auch dieser Vorgang erstellt Verbreiten eines Images auf alle Rechner Um einen Einblick zu bekommen, was neben dem Ausführen des soeben erstellten Vorganges zum Verbreiten eines Images getan werden muß, damit der Vorgang korrekt ausgeführt werden kann, folgt nun eine Beschreibung, 15

17 wie das Verteilen des Images im Grundstudiums- und Microsoft-Pool vonstatten geht. Vorbereitungen Um ein zuvor erstelltes Image zu verbreiten, sollte man sich auf dem Windows-Server Krikkit, welcher als Haupt-Server für den Grundstudiumsund Microsoft-Pool dient, entweder lokal oder per Remote Desktop als User install anmelden. Für diesen User wurden alle benötigten Vorgänge bereits konfiguriert und auf den Desktop alle benötigten Programme kopiert. Vor dem Verteilen des Images sollte man den Benutzer Test Sysprep im Active-Directory unter Users aktivieren. Dieser User wird von Ghost benutzt, um die Rechner in die Domäne einzuhängen. Aus Sicherheitsgründen sollte dieser im normalen Betrieb deaktiviert sein und nur, wenn ein Ghost-Vorgang läuft, aktiviert werden. Anschließend wird das Skript CQuota.vbs ausgeführt und eine Zahl eingegeben, welche größer ist als die aktuell vorhandenen Rechner. Dieses Skript setzt einen bestimmten Wert in der Registry, welcher angibt, wieviele Rechner ein Benutzer maximal zur Domäne hinzufügen kann. Da der Standard-Wert 10 beträgt gibt es Probleme, falls mit einem Ghost-Vorgang mehr als 10 Rechner in die Domäne eingefügt werden sollen. Wird das Skript nicht ausgeführt, so müssen alle anderen Rechner manuell in die Domäne eingetragen werden. Bevor der Ghost-Vorgang ausgeführt werden kann, sollte der Windows-Backup-Server Traal heruntergefahren werden. Dieser Server spiegelt das ActiveDirectory, wird jedoch nur alle zwei Stunden mit Krikkit synchronisiert. Da es innerhalb von Ghost nicht konfigurierbar ist, auf welchen Server die Rechner in die Domäne hinzugefügt werden sollen, ist es vom Zufall abhängig, wo die Rechner plaziert werden. Sind sie nicht auf dem selben Server, auf welchem auch Ghost installiert ist, so kann der Ghost-Vorgang nicht erfolgreich abgeschlossen werden. Das Ausführen des Vorganges Alle Rechner werden nun entweder unter Windows gestartet oder warten direkt in der Ghost-Boot-Partition auf das Image. Damit diese korrekt in das ActiveDirectory eingefügt werden können, sollten sie aus dem ActiveDirectory unter test/zdi/gspool/workstations entfernt werden. Nun, falls noch nicht geschehen, die Ghost Console auf dem Server starten. Unter Rechnergruppen/GSPool überprüfen, ob alle Rechner ansprechbar sind. Es darf kein rotes X auf dem Icon vorhanden sein. 16

18 Sind alle Rechner bereit, so kann der Vorgang, falls nicht schon vorher erledigt, konfiguriert werden. Dazu unter Vorgänge/Image verbreiten/gspool doppelt auf den Vorgang alle Image aufspielen klicken. Im Reiter Duplizierung unter Image das zu verbreitende Image wählen. Nun in den Reiter Konfiguration gehen und auf Anpassen klicken. In diesem Fenster sind auf der rechten Seite unter Konfigurationen/GSPool die Konfigurationen aller Rechner des GSPools zu finden, auf der linken Seite alle Rechner (unsortiert). Nun muß zu jedem Rechner die passende Konfiguration zugeordnet werden, indem die jeweilige Konfiguration unter den Rechner gezogen wird. Wegen einem Fehler in Symantec Ghost 7.5 muß dieses Konfigurieren jedes Mal durchgeführt werden, bevor ein Image verbreitet wird. Sind alle Rechner konfiguriert, so kann man durch einen Klick auf Ok die Konfigurationen sichern. Jetzt geht es auch endlich los: Um das Image zu verteilen, den gewünschten Vorgang (z.b. alle Image aufspielen ) wählen und in der Shortcut-Leiste auf Ausführen klicken. Alternativ kann der Vorgang auch im Kontextmenü unter dem Punkt Vorgang ausführen gestartet werden. Nun starten die Rechner innerhalb der Ghost-Partition den Ghost-Client, laden das Image aus dem Netz, konfigurieren sich und starten 2-3 mal neu. Ist der Vorgang abgeschlossen, so ist dieses im unteren Teil der Ghost-Console auf dem Server zu erkennen. Dort ist auch abzulesen, ob alle Rechner das Image erfolgreich erhalten haben oder ob Fehler beim Ausführen des Vorganges aufgetreten sind. Startet der Vorgang nicht, d.h. die Rechner warten alle auf den Empfang des Images, so ist die wahrscheinlichste Ursache dafür, daß ein oder mehrere Rechner die Ghost-Partition nicht starten können. In diesem Fall sollte überprüft werden, ob auch wirklich jeder Rechner sich unter Windows oder bereits innerhalb der Ghost-Partition befindet. Nach dem Ausführen des Vorganges Zuerst sollten alle Rechner im Active-Directory von Computers nach test/zdi/gspool/workstations/ bewegt werden, damit sich die Benutzer wieder anmelden können und damit die Rechner mit den entsprechenden Sicherheitsrichtlinien konfiguriert werden. Fehlt an dieser Stelle ein oder mehrere Rechner, so müssen diese manuell unter Windows über Systemsteuerung/System unter dem Reiter Computer Name mit einem Klick auf Network ID in die Domäne eingetragen werden. Durch den Ghost-Vorgang wurde der Linux-Bootmanager deaktiviert. Um diesen wieder zu aktivieren, muß der Vorgang alle lilo aktivieren ausgeführt werden. Die Rechner starten nun zwei Mal neu und befinden sich anschließend 17

19 alle unter Linux. Da Ghost nicht erkennen kann, wann der Vorgang zu Ende ist, weil die Rechner nicht mehr nach Windows starten und somit der Ghost-Client sich nicht beim Server zurückmelden kann, muß der blinkende Vorgang in der Ghost-Console über das Kontextmenü abgebrochen werden, sobald unter allen Rechnern Linux läuft. Sind alle Vorgänge ausgeführt, so sollte der Benutzer Test Sysprep im Active-Directory wieder deaktiviert werden. Außerdem sollte das Skript CQuota.vbs gestartet und als neuer Wert 0 übergeben werden. So wird verhindert, daß ein neuer Client zur Domäne hinzugefügt werden kann. Zum Schluß muß die Software installiert werden, welche nur auf bestimmten Rechnern laufen soll, wie z.b. die Treiber für die kleine Tastatur Erzeugen eines Images im normalen Betrieb Vorbereitungen Nachdem die neue Software auf dem Quellrechner, von welchem das Image geladen werden soll, installiert wurde, sollte dieser aus der Domäne ausgetragen werden, damit die Zielrechner später wieder automatisch zur Domäne hinzugefügt werden können. Erstellen des Images Zuerst sollte, falls noch nicht geschehen, die Ghost Console gestartet werden. Unter Konfigurationsressourcen / Images sind alle bekannten Images zu finden. Da zur Zeit wenig Speicherplatz auf dem Server vorhanden ist, sollte ein Image überschrieben werden. Das gewählte Image wird normalerweise umbenannt, damit das aktuelle Image zu erkennen ist, indem die Bezeichnung (aktuell) an den Namen angehängt wird. Gleichzeitig muß diese Bezeichnung von dem bisher aktuellen Image entfernt werden. Unter Vorgänge/Image erstellen sind zwei bereits vorkonfigurierte Vorgänge für den Grundstudiums- und Microsoft-Pool zu finden. Als nächsten Schritt dann den entsprechenden Vorgang auswählen und mit einem Doppelklick die Eigenschaften anzeigen. Unter Quellrechner, Name den Namen des Image-Rechners und unter Image-Name das gewünschte Image wählen. Mit einem Klick auf Ok die geänderten Einstellungen sichern. Um den so konfigurierten Vorgang zu starten: Den Vorgang auswählen und diesen über das! -Zeichen in der Button-Leiste oder durch den Kontextmenü-Eintrag Vorgang ausführen den Vorgang starten. Der Quellrechner startet nun automatisch neu und kopiert das Image auf den Server. Nach dem Kopieren wartet der Rechner auf ein neues Image, was 18

20 durch Verbreiten des Images auf alle Zielrechner geschehen kann. 2.6 Zusammenfassung Dieses Kapitel hat gezeigt, wie beide Rechnerpools administriert werden. Die vorgestellte Lösung besitzt nicht nur Vor- sondern auch Nachteile, welche im folgenden Kapitel unter die Lupe genommen werden. 19

21 Kapitel 3 Die offenen Probleme 3.1 Einleitung Dieses Kapitel bildet eines der wichtigsten Kapitel innerhalb des Dokumentes, da von ihm der weitere Verlauf abhängt. Es beschreibt alle noch offenen Probleme, welche bisher nur auf manuelle Art erledigt werden können. Im darauf folgenden Kapitel werden mögliche Lösungsvorschläge für diese offenen Probleme gegeben, welche die Grundlage für konkrete Lösungen bilden. 3.2 Synchronisation von Linux und Windows Des öfteren, vor allem bevor auf allen Rechnern im Grundstudiums-Pool Windows XP oder Linux neu installiert werden soll, gibt es das Problem, daß nicht alle Rechner unter dem gewünschten System laufen. Dies hat zur Folge, daß alle Rechner durch einige Mausklicks neu gestartet werden müssen, was bei 70 Rechnern sehr zeitaufwendig ist. Daher ist der Wunsch nach einer einheitlichen Oberfläche (z.b. einer Passwort-geschützten Internet-Seite) entstanden, unter welcher es ermöglicht wird, durch ein paar Mausklicks alle Rechner gleichzeitig zu steuern. Ein weiteres Problem verursacht die Art, wie Windows XP die Loginund Logout-Vorgänge der Benutzer protokolliert. Dies geschieht auf jedem Rechner einzeln, so daß, wenn ein bestimmter Vorgang gesucht wird, im Extremfall jeder Rechner getrennt angesehen werden muß. Zur Zeit wird dieses Problem gelöst, indem nicht direkt die Login- und Logout-Vorgänge, sondern lediglich die Log-Dateien von Samba, welches dafür zuständig ist, die Homeverzeichnisse der Benutzer bereitzustellen, betrachtet werden. Diese Log-Dateien sind jedoch alles andere als übersichtlich und müssen erst durch 20

22 Skripte nachbearbeitet werden, damit die gesuchten Vorgänge ungefähr zu erkennen sind. Als Lösung wäre es denkbar, durch ein Programm, welches beim Login- und Logout ausgeführt wird, die gewünschten Daten zentral in eine Datenbank zu schreiben. 3.3 Windows-Updates Windows-Updates sind kleine Programme, welche von der Firma Microsoft bereitgestellt werden, um Sicherheitslücken des Betriebssystems Windows zu schließen, verschiedene Windows-Programme, wie den Internet-Explorer oder den Media-Player, zu aktualisieren oder auch, um neue Treiber zu installieren. Die Installation erfolgt, je nach Quelle, entweder automatisch oder manuell. Es gibt vier verschiedene Quellen für die Windows-Updates: Die Internet-Seite den Windows- Update-Client, die Internet-Seite und den Microsoft System Management Server (und Client) SMS, welcher zur Zeit in der Version 2003 zu haben ist. Die Internet-Seite bietet die einfachste Möglichkeit, einen Computer unter einem Windows-Betriebssystem auf den aktuellen Stand zu bringen. Nachdem der Benutzer, welcher Administrationsrechte besitzen muß, diese Internet-Seite betreten hat, wird zuerst eine kleine Anwendung auf den Computer geladen, welche diesen nach vorhandener Hardware, Windows- unter Internet-Explorer-Version und bereits installierten Updates untersucht. Anschließend bekommt der Benutzer die Möglichkeit, aus drei verschiedenen Kategorien auszuwählen, welche neuen Updates auf dem Computer installiert werden sollen. Ist dies geschehen, klickt der Benutzer auf Updates installieren und akzeptiert die Lizenzvereinbarung. Daraufhin werden alle gewählten Updates vollautomatisch installiert. Gegebenenfalls muß nach dieser Aktion der Computer neu gestartet werden, um die installierten Updates zu aktivieren. Eine zweite Möglichkeit, um Windows-Updates zu installieren, bietet der Windows-Update-Client. Dies ist ein kleines Programm, welches mit den meisten Windows-Betriebssystemen mitgeliefert wird und welches regelmäßig die Server bzw. (ab Windows XP mit Service-Pack 2) besucht und diese nach neuen Windows-Updates befragt. Sind neue Updates verfügbar, so führt der Windows-Update-Client, je nach Konfiguration, einen der folgenden Vorgänge aus: Die erste Möglichkeit besteht darin, daß der Windows-Update-Client lediglich eine Meldung anzeigt, sobald neue Updates verfügbar sind und ein Benutzer mit 21

23 Administrationsrechten eingeloggt ist. Ist dies der Fall, so bekommt der Administrator alle neuen Updates angezeigt und kann wählen, welche heruntergeladen werden sollen. Der Download geschieht dabei im Hintergrund. Sind alle gewählten Updates heruntergeladen, so wird der angemeldete Benutzer mit Administrationsrechten gefragt, ob er die Updates sofort, später oder automatisch zu einer frei definierbaren Uhrzeit installieren möchte. Als zweite Möglichkeit steht zur Auswahl, daß die Updates sofort, nachdem der Update-Client diese entdeckt hat, heruntergeladen werden. Erst nachdem diese auf dem Rechner gespeichert wurden, wird der angemeldete Benutzer mit Administrationsrechten gefragt, ob und wann diese installiert werden sollen. Die letzte Wahlmöglichkeit bei der Konfiguration des Windows- Update-Clients bildet die Option, alle verfügbaren Windows-Updates automatisch herunterzuladen und zu einem frei wählbaren Zeitpunkt zu installieren. Die Installation wird auch dann ausgeführt, wenn ein Benutzer ohne Administrationsrechte eingeloggt ist. Erfordert das Abschließen der Installation einen Neustart, so bekommt der Benutzer je nach Konfiguration entweder die Möglichkeit, den Rechner sofort neu zu starten oder der Rechner wird nach fünf Minuten automatisch neu gestartet, wobei ein Countdown dem Benutzer angezeigt wird. Da im Grundstudiums- und Microsoft-Pool am ehesten die zuletzt beschriebene Möglichkeit in Betracht gezogen werden kann, jedoch nicht jedes neue Update installiert werden soll, wird eine Möglichkeit zur Steuerung des Update-Clients benötigt. Hier kommt der Software-Update-Server der Firma Microsoft in Frage, welcher als Ersatz zum Microsoft-Server dient(siehe unten). Ein weiterer Nachteil des Update-Clients ist es, daß dieser nicht zentral protokolliert, welche Updates auf welchen Rechnern installiert worden sind. Eine dritte Möglichkeit, um Windows-Updates zu installieren, bildet das manuelle Durchsuchen der Internet-Seite Hier werden fast alle Windows-Updates als Download angeboten. Nach dem Herunterladen muss jedes Update einzeln wie ein normales Programm installiert werden. Diese Möglichkeit wird meistens dann verwendet, wenn ein bestimmtes Update erneut installiert werden soll oder wenn der Benutzer nicht die Internet-Seite besuchen möchte, da hier einige Daten über das System und den Computer an Microsoft übertragen werden. Um Unternehmen die Möglichkeit einer Kontrolle zu geben, welche Updates auf den Firmen-Computern installiert werden sollen und um die Updates innerhalb des Unternehmens auf einem zentralen Server 22

24 bereitzustellen, stellt die Firma Microsoft das Programm SUS (Software Update Server) kostenlos zur Verfügung. 1 Dieser Server arbeitet mit dem Windows-Update-Client zusammen und benötigt zur Installation den Microsoft IIS (Internet Information Service). In regelmäßigen Abständen muß der System-Administrator über ein Webinterface den eigenen Server mit dem Server von Microsoft synchronisieren. Neue Updates, welche übersichtlich markiert werden, können anschließend akzeptiert werden. Alle akzeptierten Updates sind für den Windows-Update-Client sichtbar, d.h. nur diese werden auf die Computer geladen. Leider protokolliert der SUS nicht mit, welche Computer welche Updates besitzen. Um trotzdem herauszubekommen, auf welchem Stand sich welcher Computer befindet, ist eine aufwendige Kontrolle der IIS-Log-Datei notwendig. Vor allem für große Unternehmen, welche Windows-Rechner besitzen, die unter den verschiedensten Windows-Versionen und im Idealfall 24 Stunden am Tag laufen, ist der System Management Server (SMS 2003) eine Alternative. Dieses Programm besteht aus mindestens einem primären Server, wobei auch der Einsatz von mehreren parallel laufenden Servern unterstützt wird. Die verschiedenen Server werden dabei in verschiedene Standorte eingeteilt. Nachdem jeder Server so konfiguriert wurde, daß jede SMS-Funktion auf mindestens einem Server ausgeführt wird, werden die Client-Programme an die verschiedenen Client-Rechner verteilt. Läuft auf jedem Rechner der Remote-Registry-Dienst und ist das Admin-Share ($Admin) für den Dienst zur Verteilung der Clients auf jedem Client-Rechner zugänglich, so kann der Client automatisch verteilt werden. Ist auch dies geschehen, so wird das Security Update Inventory Tool auf den Servern installiert und ausgeführt. Dieses Tool installiert auf den Client-Rechnern ein Programm, welches diese nach nicht installierten Sicherheitsupdates durchsucht. Dazu werden die Daten, welche in einer XML-Datei stehen (mssecure.xml) 2 benutzt. In dieser Datei befinden sich Informationen über alle bisher veröffentlichten Sicherheitsupdates. Wurden die Informationen über einen Rechner gesammelt, so besteht die Möglichkeit, an diesen neue Sicherheitsupdates zu senden. Dazu wird auf dem System Management Server automatisch eine neue Software-Ankündigung durch die Funktion zum Verteilen neuer Sicherheits-Patches erstellt, wobei dort angegeben werden muß, wo sich der Sicherheits-Patch auf dem Server befindet (muß vorher manuell heruntergeladen werden) und mit welchen Parametern dieser Patch auf dem Client ausgeführt werden soll. 1 Siehe 2 Siehe dazu auch 23