Die Details der vier verschiedenen Bespielungen können Sie sich jederzeit in den Filmen anschauen. Im Folgenden soll es darum gehen, die Hintergründe der vier verschiedenen Verfahren zu erläutern. Das Windows 2003 aus den Filmen wurde nur einmal installiert und dann auf vier verschiedene Arten abgezogen. Das in den Videos zu sehende sichere Anmelden auf dem OMA-Server per ssh unter Verwendung der nicht grafischen OMA-Server-Console "omamini" ist nur dem Film geschuldet, der ja immer nur den Client aufzeichnet.
Grundsatzregeln bei der Verteilung von Windows
Im Rahmen der 08/15-Windows-Musterinstallation haben wir festgelegt, dass der Server erst später konfiguriert wird. Außerdem haben wie die automatischen Updates ausgeschaltet, den Energiesparmodus der Netzwerkkarte deaktiviert und die oma2win-Prozeduren ausgeführt. Durch die oma2win-Prozedur erhalten alle Netzwerkkarten in der Musterinstallation die IP-Adresse 0.0.0.0. Bei der Massenverteilung ist dadurch sichergestellt, dass Windows beim ersten Booten immer nur sich selber sieht und das OMA-Deployment kann in aller Ruhe den Rechnernamen vergeben, die SID setzen, den DHCP-Client aktivieren oder eine feste IP-Adresse setzen. Die mit der Bespielung bereits verteilten Softwarepakte werden beim zweiten Windows Start zu Ende installiert und konfiguriert.
Eines dieser Softwarepakte regelt dann bei Bedarf auch die Konfiguration der automatischen Updates. Wenn Sie später Tag- und Nacht jederzeit auf das laufende Windows zum Nachverteilen von Software zugreifen wollen, sollte sich die Netzwerkkarte nicht wegen der Stromersparnis schlafen gelegt haben.
Methode 1: OMA-Classic-Image
Für den Abzug als OMA-Classic-Image wird der Client in eine auf einem Linux-Kernel basierende OMA-Management-Client-Console gebootet. Per Menüpunkt erfolgt noch ein Ausnullen der Partition, bevor das Image gezogen wird. Gelesen werden alle Blöcke auf Laufwerk "C". Umgekehrt werden beim Bespielen auch alle Blöcke geschrieben, so dass defekte Stellen auf "C" sofort auffallen. Das eigentliche Lesen und Schreiben erfolgt mit dem Programm "dd". Durch das Ausnullen ist sichergestellt, dass die Imagegröße unabhängig von der Partitionsgröße immer nur halb so groß ist wie die Summe der Dateien auf "C".
Wie Sie in Film II-1 sehen können, werden die Individualdateien des Deployment-Prozesses noch vor dem ersten Booten von Windows übertragen, indem Linux die Plattenstücken einhängt. Sowohl für das Abziehen als auch für das Bespielen eines OMA-Classic-Image kann die OMA-Management-Client-Console wahlweise vom Netz oder von einem lokalen Datenträger gestartet werden. In Film II-1 schieben wir 1,1 GByte beziehungsweise 71.396 16-KByte-Blöcke verschlüsselt über das Netz. Der Client dekomprimiert diese Blöcke und schreibt sie auf die Festplatte. Die reine Übertragungszeit des Image beträgt 3:29 Minuten.
Methode 2: OMA-PartImage-Image
Für den Abzug als OMA-PartImage-Image müssen Sie den Client auf jeden Fall per Netz in die auf einem Linux-Kernel basierende OMA-Management-Client-Console booten. Das liegt an dem zum Abziehen verwendeten Programm "partimage". Diese Software kann Images nur auf Netzwerkfreigaben ablegen. Eine Ausgabe des Abbilds in einen Pipe ist nicht möglich. Bei partimage werden nur die mit Daten belegten Blöcke des NTFS-Dateisystems auf "C" gelesen und geschrieben. Dadurch spielt die Größe des Laufwerks keine Rolle. Das Abziehen und Bespielen geht schneller, wenn viele freie Blöcke im Spiel sind. Der NFS-Server, auf dem wir die Images ablegen, ist der OMA-Server. Das Image wird immer erst temporär unter dem Namen des Client auf der NFS-Freigabe abgelegt und final durch den OMA-Server an eine sichere Stelle verschoben.
Der NFS-Server muss auf seiner Freigabe Dateien schreiben können, die größer als 2 GByte sind. Ansonsten funktioniert das Abholen mit partimage nicht. Wenn Sie den Kernel-basierten NFS-Server unter Linux verwenden, sind Sie auf der sicheren Seite. Dieser ist mittlerweile bei allen Linux-Distributionen der voreingestellte Standard. Für das Bespielen eines OMA-PartImage-Image ist die Verwendung einer NFS-Freigabe nicht nötig. Die Übertragung des Abbilds kann per SSH-Protokoll erfolgen, da das partimage ein Image aus einem Pipe heraus lesen kann. Für das Nachschieben der Individualdateien kommen die gleichen Verfahren zum Einsatz wie in Film II-1.
Im Film II-2 schieben wir 1,1 GByte beziehungsweise 70.987 16-Kbyte-Blöcke verschlüsselt über das Netz. Auch hier dekomprimiert der Client diese Blöcke und schreibt sie auf die Festplatte. Das Image ist nur geringfügig kleiner als das OMA-Classic-Image. Die reine Übertragungszeit beträgt 4:33 Minuten. Dass dies länger dauert, liegt an der notwendigen Kalkulation belegter und nicht belegter Blöcke.
Einsatz der OMA-WindowsPE-Client-Console
Für das Aufspielen eines OMA-Archiv-Image als auch für das Aufspielen eines Online-Snapshot-Image booten wir den Computer in die OMA-WindowsPE-Client-Console.
Film II-3 zeigt den Vorgang in stark gekürzter Form. In der Realität kann dieser Schritt zehn bis zwanzig Minuten dauern. Am Ende des auf drei Minuten gekürzten Films sehen Sie den Start des SSH-Serverdienstes und es werden die Adressen angezeigt, die der Linux-Server geliefert hat, der auch alle Bootdateien für Windows bereitgestellt hat. Die Filme II-4 und II-6 beginnen faktisch da, wo Film II-3 aufhört.
Methode 3: OMA-Archiv-Image
OMA-Archiv-Images bieten die größtmögliche Flexibilität und sind bei der OMA-Verteilung von Linux, MacOS X und Solaris inzwischen die Regel. OMA-Archiv-Images setzen voraus, dass mit einer passenden OMA-Management-Client-Console vom Netz gebootet wird. Für Linux-Archiv-Images wird Linux gebootet, für MacOS-Archiv-Images wird MacOS gebootet, für Solaris-Archiv-Images wird Solaris gebootet und für Windows-Archiv-Images wird Windows PE vom Netz gebootet. Als Bootserver fungiert in allen vier Fällen der unter Linux laufende OMA-Server. Während alle anderen vom Netz bootbaren Systeme immer ein komplettes Betriebssystem anbieten, ist Windows beim Booten vom Netz nur eine abgespeckte Karikatur seiner selbst.
Seite 1 von 2 Nächste Seite>>
