Die DesktopdateienErweiterte Funktionalität in WDS

Wes Miller

Inhalt

Befehlszeilenverwaltung
Abbildspeicher
Multicast
Protokollierung in WDS
Andere Probleme
Zusammenfassung

In den letzten beiden Ausgaben dieser Rubrik wurden die Windows-Bereitstellungsdienste (Windows Deployment Services, WDS) untersucht. Zuerst wurde der Hintergrund der auf PXE (Pre-boot eXecution Environment) basierenden Bereitstellungstools von Microsoft beleuchtet, gefolgt von einem Überblick über WDS. In diesem Monat stehen tiefere Einblicke in einige erweiterte Themen an:

WDSUtil (das leistungsfähige Befehlszeilendienstprogramm für WDS), der WDS-Abbildspeicher, die WDS-Protokollierung sowie die Arbeit mit der Multicastfunktionalität in WDS für Windows Server® 2008.

Als in Windows® 2000 und Windows Server 2003 die Remoteinstallationsdienste (Remote Installation Services, RIS) veröffentlicht wurden, boten sie nicht so viele Features, wie es sich viele gewünscht hatten. Dabei fallen vor allem drei Bereiche auf:

• Leistung (mehr Skalierbarkeit bei der Bereitstellung)
• Protokollierung/Überwachung
• Befehlszeilenautomatisierung

Im Artikel dieses Monats erfahren Sie, dass mit der anfänglichen Veröffentlichung von WDS, und insbesondere mit WDS unter Windows Server 2008, wesentliche Fortschritte in allen diesen Bereichen erzielt wurden.

Befehlszeilenverwaltung

Im letzten Monat wurde angemerkt, dass WDS eine stark verbesserte Verwaltungskonsole bietet. Was aber für die meisten Unternehmen noch wichtiger ist: WDS bietet ein neues Befehlszeilendienstprogramm für die Verwaltung namens „WDSUtil.exe“ (siehe Abbildung 1). WDSUtil wird mit WDS Optional Component unter Windows Server 2003 (SP1+WDS oder SP2) und mit WDS Role unter Windows Server 2008 installiert.

Abbildung 1 Aktivieren der Architekturerkennungsoption mittels WDSUtil (zum Vergrößern auf das Bild klicken)

WDSUtil ist ein erstaunlich leistungsfähiges Dienstprogramm, aber es ist ziemlich komplex. Im Grunde kann alles, was Sie mit Microsoft® Management Console (MMC) tun, auch mit WDSUtil erreicht werden. Eigentlich ist das ein großartiges Beispiel dafür, dass es auch eine der besten Möglichkeiten zum Analysieren von Problemen ist. Versuchen Sie es:

wdsutil /get-server /show:config

Die Ergebnisse spiegeln fast vollständig das wider, was Sie im gesamten WDS MMC sehen würden, und WDSUtil kann es auch in einem problemlos lesbaren Format ausgeben, das Sie dann in eine Textdatei ausgeben können.

Nicht genug Informationen? Versuchen Sie, stattdessen den folgenden Befehl auszuführen, der noch mehr zurückgibt:

wdsutil /get-server /show:all /detailed

Sie können den WDS-Server beenden und neu starten, indem Sie Folgendes ausführen:

wdsutil /stop-server
wdsutil /start-server

Einen Befehlsüberblick für WDSUtil finden Sie unter go.microsoft.com/fwlink/?LinkId=112194. Bei Bedarf können Sie unter go.microsoft.com/fwlink/?LinkId=89381 auch eine .chm-Version (zusammen mit allen WDS 2008-Dokumenten) herunterladen.

Ohne ein ADSI-Experte (Active Directory® Service Interfaces) zu sein, gab es bei RIS keine einfache Möglichkeit, über die Befehlszeile herauszufinden, ob eine bestimmte MAC-Adresse oder GUID mit einem Computerkontoobjekt (Machine Account Object, MAO) in Active Directory verknüpft war. Mit WDSUtil können Abfragen auf beidem basieren.

GUIDs können verwirrend sein, da Sie sie als binäre Zeichenfolgen oder als GUID-Zeichenfolge eingeben können, und der einzige Unterschied ist die Bytereihenfolge und die Abwesenheit der Bindestriche. MAC-Adressen können mit oder ohne Bindestriche eingegeben werden, indem eine der folgenden Codezeilen verwendet wird:

wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB

Sie können die Geräteinformationen durch eine binäre Zeichenfolge mit dem folgenden Befehl abrufen:

wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6

Sie können die Geräteinformationen durch eine GUID-Zeichenfolge mit dem folgenden Befehl abrufen:

wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6

Viele Ihrer Computer können wahrscheinlich die 64-Bit-Version von Windows ausführen, aber einige melden ihre Architektur leider nicht richtig. Sie können gestatten, dass WDS versucht zu bestimmen, ob ein System x64-fähig ist, indem es ein kleines Net-Boot-Programm, das in WDS enthalten ist, ausführt. Wie in Abbildung 1 dargestellt, erreichen Sie das folgendermaßen:

wdsutil /set-server /architecturediscovery:yes

Tatsächlich ermöglicht der set-server-Befehl von WDSUtil die Konfiguration einer großen Anzahl von Servereinstellungen. Um die Möglichkeiten zu sehen, führen Sie den folgenden Befehl aus:

wdsutil /set-server /?

Wenn Sie einen Windows Server 2003 WDS-Server auf Windows Server 2008 aktualisiert haben, können Sie alle RIPrep-Abbilder in WIM-Abbilder (Windows Imaging Format) konvertieren, indem Sie Folgendes ausführen:

WDSUtil /convert-RIPrepImage

Obwohl WDSUtil RIPrep-Abbilder konvertieren kann, können alle übrigen RISetup-Abbilder (herkömmliche RIS- und ältere, von WDS erstellte Installationen) nicht konvertiert werden.

Die Leistungsfähigkeit von WDSUtil liegt in der von ihm gebotenen Möglichkeit, sich wiederholende Aufgaben zu automatisieren. Die Befehle in Abbildung 2 geben Ihnen eine Vorstellung von den WDSUtil-Funktionen. Ob Sie neue WDS-Server einführen, Abbilder über mehrere Server hinzufügen oder ändern, Ihre Multicastinfrastruktur verwalten oder angeben, welches Netzwerkstartprogramm für einen bestimmten Startclient verwendet werden soll, WDSUtil stellt leistungsfähige Funktionen bereit, die bei RIS bisher nicht verfügbar war.

Abbildung 2 WDSUtil-Befehle

Abbildspeicher

Letzten Monat wurde erwähnt, wie Einzelinstanzspeicherung (Single Instance Storage, SIS), die von RIS für das effizientere Speichern von Dateien auf dem Datenträger verwendet wurde, in WDS ignoriert wurde. Jetzt sind alle Abbilder des einheitlichen Modus (WIM), unabhängig vom Betriebssystem, im WDS-Abbildspeicher enthalten. Wie in früheren Artikeln beschrieben, konnten Sie durch die Einzelinstanzfunktionalität in .wim-Dateien Speicherplatz einsparen, wenn die Volumeabbilder entsprechende Dateien aufwiesen. Der WDS-Abbildspeicher funktioniert genauso. Er verwendet die WIM-Funktionalität, um Abbilder zu speichern.

Um mit dem Abbildspeicher zu arbeiten, müssen Sie mindestens eine Abbildgruppe haben. Die WDS-Initialisierung wird Sie in der Regel auffordern, eine zu erstellen. Sie können auch eine neue Abbildgruppe erstellen, während Sie ein Installationsabbild hinzufügen, und das Abbild wird ihr hinzugefügt (siehe Abbildung 3).

Abbildung 3 Erstellen einer neuen Abbildgruppe (zum Vergrößern auf das Bild klicken)

Was also ist der Abbildspeicher? Wenn Sie in Ihrem RemoteInstall-Verzeichnis im Verzeichnis „Images“ nachsehen, finden Sie Verzeichnisse für jede Abbildgruppe, die Sie erstellt haben. Wie in Abbildung 4 dargestellt, gibt es eine .wim-Datei für jedes Installationsabbild, das Sie in die Abbildgruppe importiert haben, und eine einzige .rwm-Datei (Resource WIM).

Abbildung 4 Inhalt einer Abbildgruppe (zum Vergrößern auf das Bild klicken)

Sehen Sie sich die Dateien in Abbildung 4 sorgfältig an. Diese Abbildgruppe besteht aus Folgendem:

• install.wim (Windows Server 2008, Standard Edition)
• install-(2).wim (Windows Server 2008, Enterprise Edition)
• install-(3).wim (Windows Server 2008, Datacenter Edition)
• install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
• install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
• install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)

Vergleichen Sie jetzt die Größen dieser Dateien mit den Größen von MMC (siehe Abbildung 5). Die Größe der einzelnen .wim-Dateien in Abbildung 4 entspricht einem Bruchteil der Größe der Res.rwm-Datei. Warum? Um Platz zu sparen, sind die angezeigten .wim-Dateien einfach Stubs der eigentlichen Dateien. Sie enthalten die Metadaten, um die .wim-Datei wiederherzustellen, enthalten aber nicht die Dateiressourcen. Alle Dateiressourcen in einer Abbildgruppe sind in der .rwm-Datei für diese Abbildgruppe gespeichert.

Abbildung 5 Im Server-Manager angezeigte Abbilder (zum Vergrößern auf das Bild klicken)

Um ein Installationsabbild in einem Abbildspeicher zu bearbeiten, können Sie entweder das Abbild exportieren, Ihre Bearbeitungen vornehmen und dann das Abbild ersetzen (oder es erneut importieren), oder Sie können mit ihm interagieren, indem Sie das entsprechende Installationsabbild vom MMC deaktivieren und Ihre Bearbeitungen durch das Bereitstellen und Ändern der .wim-Datei vornehmen.

Ein Problem, das RIS schon immer hatte, war die Abbildreplikation. Wenn Sie die mit SIS bearbeiteten Dateien über das Netzwerk kopieren, geht SIS verloren, da es ein NTFS-Attribut ist. Das bedeutete, dass Sie 40 GB von RISetup- und RIPrep-Abbildern hatten und sie auf einen anderen Server replizierten. Selbst wenn SIS Groveler ihre Größe auf nur 5 GB verringert hatte, replizierten Sie immer noch 40 GB über das Netzwerk. Dies ist beim WDS-Abbildspeicher nicht der Fall. Wegen der Architektur des Abbildspeichers können Sie sie auf einem DFS-Server (Distributed File System, verteiltes Dateisystem) speichern und die DFS-Replikation (DFS-R) verwenden, um sie von Standort zu Standort zu replizieren.

Die Einzelheiten hierfür ändern sich je nach WDS-Version. Informationen zu Windows Server 2003 finden Sie in Kapitel 7 „Arbeiten mit Abbildern“ in der Dokumentation, die Sie unter go.microsoft.com/fwlink/?LinkId=81031 herunterladen können. Informationen zu Windows Server 2008 finden Sie unter „Speichern und Replizieren von Abbildern mit DFS“ unter go.microsoft.com/fwlink/?LinkId=121960. Da die Ressourcen alle in der .rwm-Datei gespeichert werden, weist die übermittelte Datenmenge, auch wenn Sie eine Abbildgruppe von einem Server auf den anderen kopieren, nur einen Bruchteil der Größe auf, die bei der Übertragung der gesamten .wim-Datei anfallen würde (bzw. in der alten RIS SIS-Architektur).

Wann erstellen Sie also eine neue Abbildgruppe, und wann verwenden Sie die alte? Die Regeln sind normalerweise dieselben wie für eine .wim-Datei. Obwohl Sie ein Abbild von Windows XP Professional SP3 in einer Abbildgruppe platzieren könnten, die überwiegend aus Windows Server 2008-Abbildern besteht, würde dies nicht viel Sinn machen, da Sie nicht viel Platz einsparen. Wie bei .wim-Dateien empfiehlt sich eine Abbildgruppe im Allgemeinen zumindest für Folgendes:

• Jede spezifische Veröffentlichung von Windows, bei der eine Veröffentlichung sowohl ein SKU (Windows XP Professional) als auch eine Service Pack-Revision (SP3) ist.
• Windows Server 2003 und früher: Jede lokalisierte Sprachveröffentlichung (keine mehrsprachige Benutzeroberfläche). Vor Windows Vista® waren lokalisierte Builds vollständig verschiedene Binärdateien. Deshalb konnten sie hinsichtlich der Einzelinstanziierung nicht gut in einer .wim-Datei gespeichert werden.
• Jedes Service Pack einer Veröffentlichung. Auch wenn Sie Windows Server 2008-Abbilder und Windows Vista SP1-Abbilder zusammen speichern können, überlegen Sie, ob diese Funktionalität in Ihrer Organisation angebracht ist.

Der Abbildspeicher trägt gut zum Einsparen von Speicherplatz bei, sogar besser als SIS davor, und zwar sowohl auf Datenträger als auch über das Netzwerk, und sein reibungsloser Betrieb erfordert in der Regel wenig Aufwand.

Einer der größten Schwachpunkte der Remoteinstallationsdienste war ihr Mangel an Skalierbarkeit. Bei der Multicastbereitstellung geht es hauptsächlich darum, dies zu korrigieren. Bei Multicast denken viele an eine „schnellere“ Bereitstellung, aber es geht nicht wirklich darum, dass „schneller“, sondern dass „mehr“ bereitgestellt wird. Sie könnten mehrere Systeme über RIS bereitstellen. Eigentlich könnte RIS die gleichzeitige Bereitstellung von ungefähr 75 Systemen bewältigen.

Aber lange bevor dieser Punkt erreicht wurde, gab es Auswirkungen auf die Leistung, und jede Installation dauerte zunehmend länger. Schlimmer noch, mit der steigenden Anzahl der Installationen stieg auch das Potenzial für Fehler. Gleichzeitig sorgten mehrere Installationen dafür, dass Ihr Netzwerk mit SMB-Netzwerkverkehr (Server Message Block) ausgelastet wurde (sodass während der Bereitstellung die Mitarbeiter auf wichtige Netzwerkressourcen, wie z. B. Microsoft Exchange Server, nicht zugreifen konnten).

Bei Multicast geht es um das Aufwärtsskalieren Ihrer Bereitstellungszahlen. Ob Sie vier Server oder ein Konferenzzentrum mit 100 Systemen bereitstellen, mit Multicasting können Sie diese Bereitstellung ohne lange Wartezeiten und ohne eine vollständige Auslastung des Netzwerks abschließen. Sie können mit Multicast zwar ein einziges System bereitstellen, aber erst bei mehreren Systemen, die die Übertragung empfangen, ist der Vorteil der Skalierung ersichtlich.

Um Multicast zu verwenden, müssen Sie über Router verfügen, die Multicast unterstützen. In der Regel heißt das, dass das Internet Group Management-Protokoll (IGMP) aktiviert sein muss. Sie müssen außerdem über Windows PE 2.1 verfügen (Windows Server 2008 RTM oder Windows Vista SP1), da die Version (2.0), die in Windows Vista RTM enthalten ist, keine Multicastübertragung empfangen kann.

Sie sollten zudem sicherstellen, dass Sie bei mehreren WDS-Servern (oder anderen Multicastservern) auf dem gleichen Netzwerk einen benutzerdefinierten IP-Adressbereich angeben. Dies kann problemlos über WDS MMC vorgenommen werden, indem Sie mit der rechten Maustaste auf den Server klicken und anschließend auf „Eigenschaften“ und auf die Registerkarte „Netzwerkeinstellungen“ klicken.

Beim Durchführen einer Multicastübertragung kann sich der Multicastserver entweder an die Geschwindigkeit anpassen, die der langsamste Client empfangen kann, oder es kann die Geschwindigkeit auf einer höheren Ebene regeln und die Clients aussortieren, die nicht mithalten können. Aus Gründen der Zuverlässigkeit wird WDS mit der Geschwindigkeit des langsamsten Clients ausgeführt, der die Übertragung empfängt.

Wenn Sie feststellen, dass diese Übertragungsleistung langsamer ist, als Sie erwarten, führen Sie „wdsutil /Get-MulticastTransmission/Show-clients“ aus. Dadurch wird der Masterclient aufgedeckt, der die Übertragung einschränkt. Sie können dann die Verbindung zu diesem Client trennen, sodass er wieder SMB statt Multicast verwendet. Ein Beispielskript für die automatische Trennung von langsamen Clients finden Sie unter go.microsoft.com/fwlink/?LinkId=121961.

Um eine Multicastübertragung zu erstellen, können Sie entweder mit der rechten Maustaste auf ein Installationsabbild klicken und „Multicastübertragung erstellen“ auswählen, oder Sie können in der WDS-Konsole mit der rechten Maustaste auf „Multicastübertragungen“ klicken und „Multicastübertragung erstellen“ auswählen. Während Sie die Multicastübertragung erstellen, können Sie sowohl einen automatischen Cast als auch einen geplanten Cast erstellen. Ein automatischer Cast ist nützlich, wenn Sie mehrere Clients haben, die regelmäßig online sind und alle genau das gleiche Abbild benötigen. Neue Clients werden automatisch der laufenden Übertragung hinzugefügt, die für den allerersten Client initiiert wurde, der ein Installationsabbild angefordert hat. Ein geplanter Cast ermöglicht das Festlegen einer Gruppengröße. Wenn die angegebene Größe erreicht ist, wird die Übertragung gestartet.

Sie können außerdem die Startzeit für die Übertragung festlegen. Sobald Clients die Multicastübertragung verwenden, können Sie sie durch Klicken auf den Abbildnamen anzeigen. Im rechten Fensterbereich werden die Einzelheiten zu den Clients angezeigt, die mit der Übertragung verbunden sind.

In der Regel werden Ihre Endbenutzer Multicast vom WDS Setup-Client verwenden. Es gibt aber ein Befehlszeilendienstprogramm namens „WDSMCast“, das im Windows Server 2008 WAIK (Windows Automated Installation Kit) enthalten ist und mit dem Sie eine .wim-Datei über eine Multicastübertragung von WDS anfordern können. Die .wim-Datei muss in ihrer Gesamtheit übertragen und auf den Client angewendet werden. Deshalb sollten Sie sicherstellen, dass angemessener Speicherplatz für die Speicherung und Anwendung des Abbilds vorhanden ist. Im nächsten Monat wird erläutert, wie Sie WDSMCast in Ihren eigenen benutzerdefinierten Bereitstellungsprozess integrieren können.

Protokollierung in WDS

WDS ist zu einer beachtlichen Protokollierung und Ablaufverfolgung fähig, obwohl vieles davon standardmäßig deaktiviert ist, um Platz zu sparen. Es gibt zwei Arten der Ereignisprotokollierung: Wenn ein Client in das Windows-Ereignisprotokoll schreibt sowie das Schreiben in Verlaufsprotokolle für andere Aspekte von WDS.

In Windows Server 2008 protokolliert WDS jedoch standardmäßig relativ viel. Diese Protokolle sind unter „Verwaltung | Ereignisanzeige“ verfügbar. Die WDS-Protokolle werden in der Ereignisanzeige unter „Anwendungs- und Dienstprotokolle | Microsoft | Windows | Deployment-Services-Diagnostics“ angezeigt. Es ist praktisch, dass es sich hier um die gleichen Protokolle handelt, die angezeigt werden, wenn Sie die WDS-Rolle in der MMC anzeigen (siehe Abbildung 6).

Abbildung 6 Anzeigen von WDS im Server-Manager (zum Vergrößern auf das Bild klicken)

Die WDS-Clientprotokollierung (angezeigt in den Ereignisprotokollen in Abbildung 6) kann durch Ausführen von WDSUtil mit den folgenden Argumenten gestartet werden:

wdsutil /wdsclientlogging /enabled:yes /logginglevel:info

Sie können die Ablaufverfolgung auch für mehrere unterschiedliche Unterkomponenten von WDS ermöglichen. Legen Sie zum Konfigurieren der Ablaufverfolgung unter den Registrierungsschlüsseln entsprechend einen DWORD-Registrierungswert fest (siehe Abbildung 7). Alle Protokolle der Ablaufverfolgung werden unter „\Windows\tracing“ gespeichert. Sie müssen dann die entsprechende Komponente neu starten, damit die Protokollierung beginnt.

Abbildung 7 Einrichten der Ablaufverfolgung

WDS verfügt außerdem über Leistungsindikatoren (die unter go.microsoft.com/fwlink/?LinkId=121962beschrieben werden), die Sie bei Systemleistungsproblemen (oder zum Ausführen einer vorgezogenen Systemleistungsanalyse) überwachen können. Wie oben erwähnt, können Sie weitere ausführliche Informationen abrufen, wenn bei der Verwendung der Schalter „/detailed“, „/verbose“ oder „/progress“ mit WDSUtil Probleme auftreten.

Wenn Sie Probleme mit WDS-Clients haben, die mit einem WDS-Server interagieren oder eine Verbindung zu einem WDS-Server herstellen, ist Netmon (Microsoft Network Monitor) ein hervorragendes Tool zum Debuggen der Probleme. Network Monitor kann unter go.microsoft.com/fwlink/?LinkId=121491 heruntergeladen werden.

Andere Probleme

Es fielen einige Probleme auf, die erwähnenswert sind. Das erste Problem betrifft den Speicher. Denken Sie daran, dass WDS grundsätzlich auf Windows PE 2.x basiert. Das heißt, dass WDS-Clients mindestens 384 MB RAM benötigen, und realistisch betrachtet sollten Sie für eine optimale Leistung 512 MB bereitstellen. Denken Sie außerdem daran, dass Windows PE 2.x auf Nicht-ACPI-Systemen (Advanced Configuration and Power Interface) nicht starten kann, und damit ist nicht immer alte Hardware gemeint. Es wurde berichtet, dass relativ neue Systeme ACPI nicht unterstützen.

Beachten Sie, dass diese Systeme auch Windows Vista oder Windows Server 2008 nicht unterstützen werden. Für Systeme, die ACPI nicht unterstützen, müssen Sie entweder einen Windows Server 2003-Server oder einen früheren WDS- oder RIS-Server mit diesen vorkonfigurierten Clients zur Verfügung haben, oder Sie müssen Windows mit einer Nicht-PXE-Methode installieren.

Beachten Sie abschließend Folgendes: Wenn Sie Windows PE 1.x von Ihrem Server aus starten möchten, müssen Sie außerdem einen Windows Server 2003-Server oder früheren WDS- oder RIS-Server verwenden, da WDS unter Windows Server 2008 kein Windows PE 1.x-Abbild (RAMDisk oder PXE) starten kann.

In diesem Artikel wurden die Geschichte von WDS, Grundlagen sowie Themen für Fortgeschrittene behandelt. Im nächsten Monat werden einige benutzerdefinierte WDS-Szenarios untersucht, insbesondere, wie Sie mit WDS interagieren und es so optimieren können, dass es die gewünschten Aufgaben durchführt, oftmals ohne die vorhandene WDS-/Setupfunktionalität zu nutzen.

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.