Für diese Probleme gibt es verschiedene Ursachen und verschiedene Lösungen.

Eine, die uns immer wieder auch bei den härteren Fällen hilft, ist der

WSUS Offline Updater

Seine Funktion klingt auf den ersten Blick überflüssig: Das Tool lädt Updates von den offiziellen Microsoft-Update-Quellen herunter und installiert sie dann in einem zweiten Schritt. Das hat allerdings zwei Vorteile gegenüber dem in Windows eingebauten Windows-Update:

1. Sind die Updates einmal heruntergeladen, dann kann man sie gleich auf mehreren PCs installieren, ohne sie nochmals herunterzuladen
2. Stottert das normale Windows-Update, dann schafft es der WSUS Offline Updater meistens, die Updates doch noch zu installieren

Die Nutzung ist denkbar einfach:

• Laden Sie das Tool von der Webseite des WSUS Offline Updater herunter und packen Sie in aus
• Starten Sie das UpdateGenerator.exe, wählen Sie aus, für welche Betriebssystemversionen und (allenfalls) Office-Versionen Sie Updates bereitstellen möchten
• Mehrfachnennungen sind möglich
• Klicken Sie Start
• Nach einiger Zeit sind die Updates bereit zur Installation
• Starten Sie nun im client-Verzeichnis den UpdateInstaller
• Der Bequemlichkeit halber können Sie allenfalls die Option zum automatischen Reboot anwählen
• Starten Sie den Updater per Klick auf Start

Falls Sie mehrere Windows-Installationen aufdatieren möchten, können Sie nachdem der UpdateGenerator seine Arbeit getan hat, das komplette Verzeichnis auf mehreren PCs nutzen, ohne die Updates immer wieder herunterzuladen.

Nach Fertigstellung des Updates sollten Sie nicht vergessen, Windows Update noch einmal durchzuführen – der Offline Updater erwischt nicht immer alle Updates.

Statt dessen ist es eher üblich, verteilte DHCP-Server einzusetzen. Auf diesem Gebiet ist der ISC DHCP einer der Platzhirsche. Damit PCs nicht nur das passende PXE-Bootimage finden, sondern danach auch noch mit dem WDS zusammenarbeiten, spielen die DHCP-Optionen 60 (PXE), 66 (Boot-Server) und 67 (Bootfile) eine Rolle. Im einfachsten Fall landen wir bei einer sehr simplen ISC-DHCP-Konfiguration:

# WDS Server IP oder Name
option tftp-server-name "192.168.5.63";
next-server 192.168.5.63;
# PXE Boot Image
option bootfile-name "\\smsboot\\x64\\wdsnbp.com";
filename "\\smsboot\\x64\\wdsnbp.com";

Die Verwendung sowohl von next-server/filename als auch den beiden Optionen tftp-server-name und bootfile-name ist redundant, betrifft aber nicht dieselben Teile der DHCP-Antwort. Aktuelle PCs begnügen sich mit den beiden "option"-Angaben

Wo sich das Boot-Image befindet ist mit der WDS-Installation gegenzuprüfen – gegebenenfalls ist statt smsboot boot zu verwenden. Die IP-Adresse 192.168.5.63 steht hier stellvertretend für den WDS-Server und muss natürlich angepasst werden.

Das funktioniert soweit gut für PCs, die im traditionellen BIOS-Modus starten. PCs im UEFI-Modus benötigen ein anderes Boot-Image, nämlich wdsngfw.efi. Nun liesse sich natürlich in der DHCP-Konfiguration pro Client ein eigenes Boot-Image festlegen. Der Verwaltungsaufwand dafür wäre dann allerdings nicht klein. Am bequemsten ist es deshalb, wenn der DHCP-Server selbst die richtige Angabe liefern kann. Glücklicherweise melden die Clients dem DHCP-Server, welche (Boot-)Architektur sie haben und der DHCP-Server kann abhängig von der Architektur unterschiedlich antworten. Das sieht in der Konfiguration etwa so aus:

option arch code 93 = unsigned integer 16;

subnet ... {
...
# WDS Server IP oder Name
option tftp-server-name "192.168.5.63";
next-server 192.168.5.63;

# PXE boot image
if option arch = 00:07 or option arch = 00:09 {
   filename "\\smsboot\\x64\\wdsngfw.efi";
   option bootfile-name "\\smsboot\\x64\\wdsngfw.efi";
} else {
  filename  "\\smsboot\\x64\\wdsnbp.com";
  option bootfile-name  "\\smsboot\\x64\\wdsnbp.com";
}

Anhand der Client-Architektur verweisen wir den Client an unterschiedliche Boot-Images. Als Architekturen sind definiert:

0    Intel x86PC
1    NEC/PC98
2    EFI Itanium
3    DEC Alpha
4    Arc x86
5    Intel Lean Client
6    EFI IA32
7    EFI BC (EFI Byte Code)
8    EFI Xscale
9    EFI x86-64

Entsprechend lässt sich natürlich obige if-Anweisung ergänzen um die Unterstützung weiterer Plattformen. z.B. würde sich aufdrängen, für die Architektur 6 (UEFI 32-bit) die Datei smsboot\\x86\\wdsmgfw.efi auszuliefern, und wdsnbp.com nur der Architektur 0 (Legacy BIOS) zuzuordnen.

Es reicht allerdings nicht in jedem Fall aus, einfach das richtige Boot-Image zu übermitteln. Erhalten Sie z.B. folgende Fehlermeldung

Windows Deployment Services (Server IP 0.0.0.0)
Windows Deployment Services encountered an error:
Error Code: 0xc0000023

dann bedeutet dies, dass zwar das .efi-Image geladen wurde, dies nun aber nicht weiss, was es tun soll. Für solche Fälle hat es sich als hilfreich erwiesen, per Option 60 den String "PXEClient" mitzuliefern:

option arch code 93 = unsigned integer 16;
option pxec code 60 = string;

subnet ... {
...
# WDS Server IP oder Name
option tftp-server-name "192.168.5.63";
next-server 192.168.5.63;

# PXE boot image
if option arch = 00:07 or option arch = 00:09 {
   # UEFI 64-bit
   option pxec "PXEClient";   
   filename "\\smsboot\\x64\\wdsngfw.efi";
   option bootfile-name "\\smsboot\\x64\\wdsngfw.efi";
}
if option arch = 00:06 {
   # UEFI 32-bit
   option pxec "PXEClient";   
   filename "\\smsboot\\x86\\wdsngfw.efi";
   option bootfile-name "\\smsboot\\x64\\wdsngfw.efi";
}
if option arch = 00:00 {
  # Legacy BIOS
  filename  "\\smsboot\\x64\\wdsnbp.com";
  option bootfile-name  "\\smsboot\\x64\\wdsnbp.com";
}

Nebenbei haben wir in diesem Beispiel auch noch gleich die Unterscheidung zwischen 32b/64b eingebaut und liefern das Image für BIOS-Boot nur dann, wenn die passende Architektur gefordert wird. Auch der Fehler 102 deutet übrigens auf dieselbe Ursache hin.

Windows hat allerdings von Haus aus eine Funktion, die dem Virenscanner tatkräftig unter die Arme greifen kann und ihn gut ergänzt: Die "Software Restriction Policies" (SRP). Kurz gesagt lässt sich damit Windows so konfigurieren, dass es nur bereits bekannte, explizit vom Anwender (oder Systemadministrator) zugelassene Software ausführt. Statt sich wie ein Virenscanner darum zu bemühen, eventuelle Schadsoftware rechtzeitig vor dem Ausführen zu erkennen, arbeitet SRP mit dem Ansatz, grundsätzlich nur zugelassene Software auszuführen. SRP bringt also genau dort ein Mehr an Sicherheit, wo die meisten Antivirenpakete versagen – sie verhindern nämlich auch die Ausführung brandneuer Schadsoftware.

Die Sache hat natürlich mehrere Haken, u.a.:

• SRP ist zwar in jeder aktuellen Windows-Version verfügbar, jedoch sind die Werkzeuge, um SRP zu konfigurieren nicht in jeder Windows-Variante dabei, und sie sind eher umständlich zu bedienen
• Wer auf seinem PC oft neue Software ausführt – z.B. an einem Test-PC – der wird keine Freude an den Einschränkungen durch SRP haben
• Der Aufwand, um SRP einzuführen, ist nicht zu unterschätzen – in der Einführungsphase muss alle Software identifiziert werden, die ausgeführt werden darf, und entsprechende Regeln erstellt werden

Für den typischen Büro-Arbeitsplatz ist SRP ein Weg, der eine Überlegung wert ist. Mit dem Werkzeug Restric'tor hat sich der Heise-Verlag des Problems angenommen, dass nicht alle Windows-Varianten mit passenden Konfigurationswerkzeugen daherkommen und diese falls vorhanden als eher kompliziert wahrgenommen werden.

Den Restric'tor finden Sie zum Download beim Heise-Verlag.

Auch mit dem Restric'tor ist die Einführung von SRP kein Spaziergang. Aber es kann sich lohnen!

Nun ist es allerdings so, dass Microsoft eine kleine Hürde eingebaut hat: In der Evaluationsversion lässt sich nicht so einfach ein Produktschlüssel für einen produktiven Windows 2016 Standard oder DataCenter einpflegen. Versucht man's per graphischer Oberfläche, so weigert sich Windows 2016.

Damit sich der Produktschlüssel einpflegen lässt, muss die Evaluationsversion zuerst in eine Standard- oder DataCenter-Version umgewandelt werden. Der Schlüssel lässt sich dabei gleichzeitig einpflegen. Dies geht auf der Kommandozeile mit

dism /online /set-edition:ServerStandard /productkey:12345-ABCDE-FGHIJ-KLMNO-PQRST /accepteula

(statt 123… setzen Sie selbstverständlich den echten Schlüssel ein). In welche Editions sich eine Installation verwandeln lässt, lässt sich vorgängig mit

Dism /Online /Get-TargetEditions 

herausfinden.

Achtung: Die Umwandlung kann durchaus einige Zeit in Anspruch nehmen. Ein berüchtigtes Problem ist, dass die Prozedur bei 10% stehen bleibt. Haben Sie etwas Geduld, das kann einige Sekunden, einige Minuten oder auch einige Stunden dauern. Erfahrungsgemäss geht die Prozedur tendenziell schnell, wenn man dem Server vom Netz trennt (vor dem Start).