Die DesktopdateienWindows-Netzwerkstart

Wes Miller

Inhalt

Funktionsweise von PXE
Einstieg in RIS
Die Anfänge von WDS
Weitere Entwicklungen
Zusammenfassung

Über die kommenden Monate werde ich mich mit den Windows-Bereitstellungsdiensten (Windows Deployment Services, WDS) befassen, die für Windows Server 2003 verfügbar und in Windows Server 2008 integriert sind. Die WDS können eine sehr wichtige Komponente in Ihrer Bereitstellungsinfrastruktur bilden, und hier erhalten Sie eine gute Grundlage zu diesem Thema. In diesem

ersten Artikel werden die Architektur der Pre-boot eXecution Environment (PXE, sprich: „Pixie“), die Entwicklung der Remoteinstallationsdienste (Remote Installation Services, RIS) sowie weitere bei Microsoft verwendete PXE-Technologien behandelt.

Als ich im Jahr 2001 zur Windows-Kernbetriebssystem-Gruppe wechselte, war RIS eine der dort bereits etablierten Technologien. Aufgrund ihrer Komplexität und ihrer Abhängigkeit von BIOS-Implementierungen und Hardware machte mich diese Technologie ziemlich nervös. Aber sie wurde neben Windows® PE eine der Technologien, mit denen ich in meiner Rolle als Programmmanager am liebsten gearbeitet habe.

Ich erinnere mich an meine erste Installation von Windows 3.0 – mit einem Satz von 3,5-Zoll-Disketten. Im Lauf der Zeit ist die Installation einfacher geworden, weil startbare CDs aufkamen (in einigen Versionen von Windows 98). Aber das Problem war, dass die Installation immer lokale Medien erforderte und auch eine lokale Festplatte.

Im Lauf der Jahre haben Kunden immer wieder die Möglichkeit gefordert, Windows über das Netzwerk zu starten – also einen vollständigen Systemstart über das Netzwerk vorzunehmen, ganz ohne Festplatte. Obwohl einige frühe Versionen von Windows diese Möglichkeit boten, gab es sie in Windows NT® nicht mehr. Während aktuelle Versionen von Windows Server® 2003 und Windows Server 2008 über einen iSCSI-Initiator gestartet werden können, unterscheidet sich dieser Prozess dadurch, dass er nicht vollständig lokal ist, sondern eine kontinuierliche Abhängigkeit von einem Remotelaufwerk als Startlaufwerk voraussetzt.

Vorkonfigurieren von Clients

• Prozessevaluierung für die Vorkonfigurierung von RIS-Clients
• Erhöhung der Netzwerksicherheit mit vorkonfigurierten Clients
• Vorkonfigurieren von Clientcomputern
• Remoteinstallation des Betriebssystems

Ab Windows 2000 entwickelte Microsoft die Technologie, die schließlich als RIS bezeichnet werden und eine netzwerkbasierte Installation ermöglichen sollte. Das Ziel von RIS war relativ simpel: ein Betriebssystemabbild per PXE auf den lokalen Datenträger des Zielcomputers zu stellen.

Funktionsweise von PXE

Abbildung 1 zeigt die PXE-Startsequenz. PXE ist ein relativ einfaches Protokoll, das von Intel und anderen Anbietern als Teil der Initiative „Wired for Management“ entwickelt wurde. PXE ist vom Dynamic Host Configuration-Protokoll (DHCP) abgeleitet, das wiederum von BootP abstammt, und ist in der Regel in der Netzwerkkarte (Network Interface Card, NIC) implementiert. Einfach ausgedrückt, laufen die folgenden Vorgänge ab:

Abbildung 1 PXE-Startsequenz (Zum Vergrößern auf das Bild klicken)

Schritt 1 Das System-BIOS fährt hoch und bestimmt die Startreihenfolge.

Schritt 2 Wenn PXE in der Startreihenfolge vor Festplatten oder Flashlaufwerken oder CD-ROM-Laufwerken steht, oder wenn diese Geräte nicht vorhanden sind, dann wird die universelle Netzwerktreiberschnittstelle (Universal Network Driver Interface, UNDI) von der NIC geladen. Die NIC ist mit einem äußerst kleinen Netzwerkgerätetreiber und einer TFTP-Implementierung (Trivial File Transfer Protocol) ausgestattet. (Bei einigen BIOS-Implementierungen muss der Endbenutzer für den PXE-Start die Taste F12 drücken. Das ist nicht standardmäßig, daher kann diese Funktion deaktiviert werden.)

Schritt 3 Das System beginnt mit einer einfachen UDP-Übertragung (User Datagram-Protokoll) und sucht einen DHCP-Server. Dies ist tatsächlich der erste Schritt der PXE-Startsequenz und wird als „Discover“ (Ermitteln) bezeichnet. Denken Sie daran, dass UDP als Protokoll verwendet wird. Falls Sie dieses Protokoll noch nicht besitzen, müssen Sie etwas Zeit mit Ihren Routern und Switches verbringen, um sicherzustellen, dass alle Geräte die PXE-Kommunikation akzeptieren können.

Schritt 4 Wenn ein DHCP-Server die Übertragung hört, antwortet er mit einer IP-Adresse. Dieser Schritt wird als „Offer“ (Anbieten) bezeichnet. Das Wichtigste hierbei ist, dass PXE statusfrei ist und dass der Client zu diesem Zeitpunkt recht wenige systemspezifische Statusinformationen zu bieten hat (die MAC-Adresse und, falls verfügbar, die BIOS-GUID der Systemverwaltung, auch als SMBIOS-GUID bezeichnet).

Schritt 5 Sobald der Client das Paket mit der IP-Adresse erhalten hat, gibt er an, dass eigentlich noch weitere Informationen benötigt werden, nämlich die Adresse des PXE-Servers. Eine andere Übertragung findet statt, die die Informationen vom DHCP-Server enthält, der ursprünglich geantwortet hat. Hier teilt der Client dem DHCP-Server mit: „Ich brauche mehr Informationen, insbesondere den Speicherort eines Netzwerkstartprogramms (Network Boot Program, NBP)”. Dieser Schritt wird als „Request“ (Anfordern) bezeichnet.

Schritt 6 Der PXE-Server antwortet mit der Adresse des PXE-Servers und dem Speicherort des NBP, einer äußerst kleinen ausführbaren Startdatei, die kleiner als 32 KB sein muss. Dieser Schritt wird als „Acknowledge“ (Bestätigen) bezeichnet. Die Namen der Schritte bilden das Akronym DORA (Discover, Offer, Request, Acknowledge, also Ermitteln, Anbieten, Anfordern, Bestätigen). Damit können Sie sich die Sequenz gut merken.

Falls Sie Microsoft DHCP und WDS installiert haben (oder die Technologien eines anderen Anbieters verwenden), findet der Anforderungsschritt nicht statt, und das ursprüngliche Offer-Paket vom DHCP-Server enthält bereits den Speicherort des PXE-Servers und des NBP-Programms (wodurch zwei Schritte entfallen und etwas Zeit eingespart wird).

Schritt 7 Der Client, auf dem sich der bereits erwähnte kleine TFTP-Protokollstack befindet, lädt das NBP vom Netzwerkspeicherort herunter, der vom PXE-Server angegeben wurde. TFTP ist ein älteres, äußerst kleines, statusfreies Protokoll. Dieses Protokoll wurde nicht wegen seiner Sicherheit oder seiner Leistung ausgewählt. Viele Routeradministratoren deaktivieren es demzufolge standardmäßig. Es muss aktiviert werden, damit PXE funktionsfähig ist.

Eine Reihe von PXE-Implementierungen (darunter auch RIS) bieten die Möglichkeit, den Benutzer zu diesem Zeitpunkt aufzufordern, die Taste F12 zu drücken, um den Vorgang fortzusetzen, aber in der Regel kann dies durch den Administrator des PXE-Servers deaktiviert werden. Nächsten Monat werde ich mich näher mit WDS befassen und dabei einige der Verbesserungen erläutern, die Microsoft zur Leistungssteigerung in den TFTPD (TFTP-Daemon) in WDS für Windows Server 2008 eingebracht hat.

Schritt 8 Das NBP wird initialisiert. Bei RIS wird hierbei ein Windows-Startladeprogramm gestartet, mit dem die Bereitstellung erfolgt. PXE (zumindest das eigentliche Protokoll auf der Startebene) ist keine Komponente dieses Prozesses mehr.

Denken Sie immer daran: PXE (RIS, WDS oder andere Infrastrukturen) funktioniert weder gut über langsame Verbindungen (unter Umständen werden beträchtliche Datenmengen übertragen), noch über Verbindungen mit hoher Latenz wie Satelliten (die Kommunikation läuft schlichtweg nicht gut ab und lässt sich ggf. gar nicht aufrechterhalten).

Beim PXE-Startvorgang bemerken Sie vielleicht, dass der Client beim Senden der Anforderung gar nicht erst nachfragt, ob der Empfänger das übergeordnete Gerät für ihn ist. Es gibt einfach nicht viele Statusinformationen, aus denen der PXE-Server die entsprechenden Schlüsse ziehen könnte. Meistens gilt eine Racebedingung: Der erste Server, der auf die Clientanforderung antwortet, gewinnt. Dieses Problem lässt sich durch gewisse Aktionen verringern:

• Passen Sie die Antwortgeschwindigkeit des einen oder anderen PXE-Servers an. Die Netzwerklatenz und die Serverleistung wirken sich auf die Antwortzeit der Server aus. Bei Microsoft war es manchmal so, dass die von Microsoft IT verwendeten Server so gut waren, dass die Unternehmensserver selbst dann gewannen, wenn der PXE-Server direkt in Ihrem Büro stand. In diesem Fall mussten Sie nur auf dem lokalen PXE-Server angeben, dass für die vorkonfigurierten Clients kein Timeout gelten soll.
• Konfigurieren Sie die Clients vor. Dies ist sehr wichtig, wenn Sie den PXE-Server so manipulieren, dass er vor anderen IT-Unternehmensservern antwortet. Durch die Vorkonfigurierung der Clients kann Active Directory® gegenüber WDS oder RIS behaupten: „Ich bin das übergeordnete Gerät“. Die Verwendung des SMBIOS-GUID ist als eindeutiger Bezeichner für Ihre Systeme in Active Directory weitaus beliebter, aber wenn keine SMBIOS-GUID in den Systemen implementiert ist (meist bei relativ alter Hardware), können (und müssen) Sie eine GUID auf Grundlage der MAC-Adresse verwenden. Weitere Informationen finden Sie in der Randleiste „Vorkonfigurieren von Clients“.
• Lassen Sie es nicht zu, dass die PXE-Kommunikation über Switches oder Router abläuft. Richten Sie stattdessen je einen PXE-Server auf jeder Seite ein. Dies hat den Nachteil, dass sowohl die Implementierung als auch die Wartung teuer ist. (Jeder Server muss sein eigenes Abbild pflegen.)

RIS-Server (und jetzt WDS-Server) müssen wie Microsoft DHCP-Server anhand der Active Directory-Implementierung authentifiziert werden, der sie zugeordnet sind. Das Ziel besteht darin, die Probleme einzuschränken, die diese PXE-Server verursachen (z. B. PXE-Broadcaststorm), indem Sie Active Directory auf diese Server aufmerksam machen.

Denken Sie daran, dass Sie damit nur den Schutz vor Servern erzielen, über die Active Directory informiert wurde. Wenn Sie Ihre eigene Domäne einrichten (oder einen PXE-Server, der nicht von Microsoft stammt), trifft dies nicht zu.

Bei Microsoft hat ein übereifriger Mitarbeiter einmal einen PXE-Server ohne RIS, aber mit „Zero Touch“-Bereitstellung konfiguriert. Bei dieser Implementierung wurde die komplette Festplatte gelöscht und ein neues Abbild aufgespielt. Das wäre schon in Ordnung gewesen, wenn die Bereitstellung in einer isolierten Testumgebung (außerhalb des Netzwerks) stattgefunden hätte. Das war aber leider nicht der Fall, weshalb der Datenträger eines Microsoft-Mitarbeiters gelöscht wurde, bei dem PXE in der Startreihenfolge vor der Festplatte stand.

Das ist oft kein Problem, weil bei Microsoft IT zum Start von PXE immer die Taste F12 gedrückt werden musste, aber dieser PXE-Server bot keine Verzögerung, keine Aufforderung zum Drücken der Taste F12 oder sonst eine Benachrichtigung. Der Mitarbeiter verlor also im Prinzip seinen gesamten Computer und obendrein sämtliche Daten, die nicht durch sein servergespeichertes Benutzerprofil geschützt wurden.

Lassen Sie sich dies ein warnendes Beispiel dafür sein, die PXE-Server immer zu isolieren, wenn Sie sich für „Zero Touch“ entscheiden, oder zumindest das Drücken der Taste F12 zu fordern.

Einstieg in RIS

Ich hatte nach der Markteinführung von Windows 2000 zum ersten Mal näher mit RIS zu tun. RIS hatte es im Hinblick auf Windows 2000 nicht einfach. Tests, Leistungen und andere Einschränkungen führten dazu, dass RIS für Windows Server 2000 ausschließlich für Bereitstellungen von Windows 2000 Professional verwendet wurde. Allerdings konnten die Serverprodukte leider nicht über RIS bereitgestellt werden. Windows 2000 war nur für x86-Computer verfügbar, weshalb dies ein guter Prüfstand für RIS war, da es genau ein Produkt auf einer Architektur anbot. RIS enthielt (und erforderte) die vollständige Integration in Active Directory, ließ sich gut in den Microsoft DHCP-Server integrieren und umfasste einen eigenen TFTPD.

RIS verwendet das NBP, um den TFTP-Download fortzusetzen und einen ausreichenden Teil des Windows-Kernels herunterzuladen, um den Installationsvorgang beginnen zu können. (An einem bestimmten Zeitpunkt, nachdem Windows von TFTPD zu einer SMB-gestützten Verbindung [Server Message Block] zum Server gewechselt hat, wird der eigentliche Codepfad mit einer herkömmlichen, diskettengestützten Installation von Windows 2000 oder Windows XP gemeinsam genutzt.) Sobald Windows im einheitlichen Modus initialisiert ist, startet Windows-Setup den RIS-Operating System Chooser (OSC)-Assistenten.

Die OSC-Bildschirme sind teilweise konfigurierbare, HTML-2.0-ähnliche Seiten. Es gelten strenge Einschränkungen, und die Seiten können keine Abbilder oder Ähnliches enthalten. Auch ANSI-Zeichen sind nicht zulässig (was die Bereitstellung bestimmter Gebietsschemas von Windows erschwerte).

Das Endprodukt von RIS ist eine „txtsetup.sif“-Datei, die sich auf dem RIS-Server befindet. Wenn der OSChooser-Assistent abgeschlossen ist, wird ein Warmstart des Servers durchgeführt, aber der Speicherort des RIS-Servers und der „txtsetup.sif“-Datei werden beibehalten und nach dem Warmstart erneut geladen. Diese „txtsetup.sif“-Datei ist im Grunde identisch mit einer „unattend.txt“-Datei, wobei mehrere zusätzliche Felder dazu beitragen, dass RIS den Installationsvorgang abschließen kann.

RIS konnte auch ein Setup durchführen, das praktisch identisch mit der traditionellen unbeaufsichtigten Installation ist (RISetup). RIS enthielt zudem eine auf Klonen gestützte Infrastruktur, die ähnlich aufgebaut war wie Sysprep (RIPrep), und nutzte einigen Programmcode gemeinsam mit Sysprep. RIPrep konnte aber auch ein Abbild von sich selbst auf einen RIS-Server hochladen.

Es gab bei RIS jedoch einige grundlegende Einschränkungen, die schnell offensichtlich wurden. Das erste Problem war die fehlende Unterstützung für die Serverbereitstellung. Bestimmte Sicherheitsrisiken, z. B. Code Red und Sasser, zusammen mit den IT-Komplexitäten, die mehrere Hauptkunden bei der Wiederherstellung nach der Tragödie vom 11. September 2001 erlebten, führten dazu, dass eine Lösung für vorhandene Windows 2000-RIS-Server im Schnellverfahren entwickelt und damit eine Windows-Serverbereitstellung ermöglicht wurde. An einer solchen Lösung hatte Microsoft schon für Windows Server 2003 gearbeitet, aber sie wurde nicht offiziell veröffentlicht.

Weitere Informationen zu PXE-Technologien

• PXE-Interaktion zwischen PXE-Client, DHCP und RIS-Server
• PXE-initiierte Betriebssystem-Bereitstellungen
• Die PXE-Architektur
• Remoteinstallationsdienste
• Remoteinstallation des Betriebssystems
• Schrittweise Anleitung für die Remoteinstallation des Betriebssystems
• WDS-PXE-Anbieter
• Was sind die Remoteinstallationsdienste?
• Automatische Bereitstellungsdienste für Windows Server 2003

Zweitens: RIS bot keine Möglichkeit, den OSChooser-Assistenten vollständig zu automatisieren. Dies wurde erst später mit dem Element <META ACTION="AUTOENTER"> in Windows Server 2003 realisiert. Weiterhin konnte der OSChooser nicht richtig mit ANSI-fremden Zeichen arbeiten – eine wichtige Schwäche, die von mehreren Kunden außerhalb der USA gemeldet wurde.

Demzufolge könnten Sie die RIS-Installation beispielsweise nicht mit einer französischen Tastatur vornehmen. Es war äußerst kompliziert, ANSI-fremde Zeichen auf BIOS-Ebene auf Computern in der ganzen Welt zum Funktionieren zu bringen.

Mit der Markteinführung von Windows Server 2003 wurde die offizielle Unterstützung für die Intel Itanium-Architektur und alle Servervarianten von Windows 2000 und Windows Server 2003 hinzugefügt. In Windows Server 2003 wurde mit der Unterstützung für die x64-Architektur noch ein weiterer Schritt vorgenommen.

RIS wurde außerdem zur Leistungssteigerung mit einem umfassend überarbeiteten TFTPD-Dienst ausgestattet. Windows Server 2003 unterstützte das Starten von bis zu 75 Clients gleichzeitig. Beachten Sie hierbei, dass die Obergrenze erreicht wird, wenn die SMB-Pipeline mit Netzwerkverkehr zu den Clients gefüllt ist.

Die Anfänge von WDS

Mit den Arbeiten an RIS für „Longhorn“ (unter diesem Codenamen wurde Windows Server 2008 bearbeitet) wurde es offensichtlich, dass wir einen Schritt zurückgehen mussten. Wie bereits erwähnt, hatten wir bereits alles auf das abbildgestützte Setup (WIM) von Windows PE gesetzt. Demzufolge war die entscheidende Grundlage von WDS die abbildgestützte Bereitstellung von einer mit PXE gestarteten Instanz von Windows PE.

Außerdem war uns bekannt, dass Windows Server 2003 die allgemeine Plattform für die Bereitstellung von Windows Vista® bilden würde und dass eine „außerplanmäßige“ Lösung für WDS-Vorgängerversionen erforderlich war. Als Ergebnis konnte WDS unter Windows Server 2003 SP1 ausgeführt werden und wurde in Windows Server 2003 SP2 integriert.

WDS kann als RIS-Server (Legacymodus), als Hybridserver (gemischter Modus) oder als reiner WDS-Server (einheitlicher Modus) arbeiten, sodass Sie mit WDS zu offiziellen Bereitstellungen im WDS-Stil wechseln können. Einige Kunden haben nachgefragt, ob es eine Möglichkeit gibt, RIS auf einem System mit Windows Server 2003 SP2 zu installieren. Diese Möglichkeit gibt es: Führen Sie WDS nach der Installation im Legacymodus aus. Abbildung 2 zeigt die unterstützten Betriebssysteme.

Abbildung 2 Unterstützte Plattformen für die Bereitstellung

Durch WDS in Windows Server 2003 SP1 und SP2 dürfte die Migration zu WDS eingeläutet werden. Wie bereits oben erwähnt, bot WDS in Windows Server 2008 einige zusätzliche Features, darunter einen überarbeiteten TFTPD, die EFI-Startunterstützung (Extensible Firmware Interface) und natürlich die multicastgestützte Bereitstellung.

Weitere Entwicklungen

Ein anderes Team bei Microsoft entwickelte die automatischen Bereitstellungsdienste (Automated Deployment Services, ADS), hauptsächlich mit dem Ziel, die Bereitstellung von Servern zu beschleunigen. ADS umfasste eine formelle sektorbasierte Abbilderstellung, einen eigenen Startagent (kleiner als Windows PE, aber nicht so umfangreich), einen eigenen TFTPD und äußerst fortschrittliche Multicastfunktionen. Die Funktionen in ADS waren zu einem gewissen Grad in SCCM (System Center Configuration Manager) verfügbar, obwohl es keine hundertprozentige Featureparität gab.

Bei Windows XP Embedded war der uneingeschränkte PXE-Startvorgang über den eigenen TFTPD in einer RAMDisk möglich, konnte aber nicht im Remoteverfahren bereitgestellt werden. Die Technologie sollte das gleichzeitige Starten zahlreicher Systeme vom gleichen Datenträgerabbild über PXE unterstützen.

Zusammenfassung

Dies ist also die Entwicklung in Kurzform. Weitere Informationen finden Sie in der Randleiste „Weitere Informationen zu PXE-Technologien“. Im nächsten Monat werden die WDS-Grundlagen behandelt, später dann die erweiterten WDS-Funktionen (Multicast und mehr) und schließlich die Verwendung von WDS ohne WDS, also über die vorhandenen WDS-/Setup-Erfahrungen hinaus unter Verwendung eigener Bereitstellungsverfahren.

Wes Miller ist Senior Technical Product Manager bei CoreTrace (www.CoreTrace.com) in Austin, Texas. Zuvor war er bei Winternals Software und als Programmmanager bei Microsoft tätig. Sie können Wes Miller unter technet@getwired.com erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig