Windows 11 22H2 Update bleibt bei 96% stehen

Windows 11 hat bekanntermaßen mit großen Updates so seine Schwierigkeiten. Die Cummulativen Patches scheinen eher gut zu funktionieren, aber besonders „Upgrades“ wie 22H2 hängen scheinbar überdurchschnittlich oft fest.

Die Ursache dafür kennen wir auch (noch) nicht.

  • Windows 11 Update 22H2 bleibt bei „96% Herunterladen“ stehen
  • Nach einem Neustart steht windows Update wieder bei „Herunterladen und installieren“
  • BITS zeigt keine aktiven Übertragungen an
  • Es gibt keinerlei Systemlast oder anzeichen für eine laufende Prüfung oder Installation

Wir beobachten aber häufiger, das das Update bei verschiedenen Ständen beim „Herunterladen“ in der Einstellungen > Windows Update App stehen bleinbt. Auch Neustarts oder das zurücksetzen des Download-Caches scheinen hier nicht zu helfen, es geht wider nur bis zu dem betroffenen „Stand“. Neustart helfen nicht, weder Dienste noch der ganze PC.

Immer wieder an der selben Stelle stehen geblieben?

Kurzum, wir haben dafür auch keine „richtige“ Lösung 🙂 aber einen Workaround, der bisher immer funktioniert hat (es sei denn es war etwas kaputt).

Lösung

  1. Die Dienste „Windows-Update“ und „Übermittlungsoptimierung“ beenden
    1. net stop wuauserv
    2. net stop DoSvc
  2. Den Windows-Update Download Cache komplett leeren (%windir%\SoftwareDistribution\download)
  3. Windows-Update Dienste und die Übermittlungsoptimierung wieder starten
    1. net start wuauserv
    2. net start DoSvc
  4. Die „PC-Integritätsprüfung“ herunterladen, installieren, starten und wieder beenden (ja, genau so …)
  5. Windows 11 Installation Assistant herunterladen, aufrufen und das Update damit sauber installieren

Und schon hat man nach wenigen Installations-Momenten ein Windows 11 22H2 auf der Maschine.

HPE ProCurve und Aruba Switches NTP Konfiguration und Einstellungen

HPE Aruba (managed) Switches sowie HPE ProCurve Switches kommen im Auslieferungszustand ohne NTP-Einstellungen. Genauer gesagt mit inaktivem NTP-Modul. Das Eventlog (log -r) zeigt daher ab stets das „erste“ Datum 01.01.1980 an und die Syslogs sehe immer etwas wirsch aus.

Das hier ist wieder so eine „Notiz an uns selbst“, denn wenn man weiß wo es steht ist das ja schon fast gewusst wie es geht.

NTP-Einstellungen Aruba Switches

Konsole zum Switch öffnen (SSH oder Seriell)

HP-2530-24G# configure
(In den Config-Kontext wechseln)
HP-2530-24G(config)# time daylight-time-rule western-europe
(Sommerzeit-Regel aktivieren)
HP-2530-24G(config)# time timezone 60
(Die deutsche Zeitzone „MEZ“ ist UTC+60m)
HP-2530-24G(config)# timesync ntp
(Zeitsynchronisation auf NTP stellen)
HP-2530-24G(config)# ntp unicast
(NTP unicast aktivieren)
HP-2530-24G(config)# ntp server 192.168.x.x iburst
(Den NTP-Server konfigurieren und initialen burst aktivieren)
HP-2530-24G(config)# ntp enable
(NTP Modul einschalten)
HP-2530-24G# write memory
(Konfiguration in die Startup-Config übernehmen)

NTP auf Aruba Switches testen

Das Ergebnis der Einstellungen kann man nach ein paar Sekunden (schlimmstenfalls Minuten) überprüfen.

Zeigt die nun aktuelle Zeit des Gerätes:

HP-2530-24G(config)# show time

Zeigt den Status des NTP-Clients:

HP-2530-24G(config)# show ntp status

Zeigt die vollständige laufende Konfiguration an:

HP-2530-24G(config)# show running config

Veeam Repository Firewall Regeln

Um einen Veeam-Repository-Server mit der Veeam Infrastruktur zu verbinden, braucht man ein paar Firewall-Regeln. Die sind zum Glück auch hier ganz gut dokumentiert.

Um mir die Arbeit jedesmal aufs neue zu ersparen 🫡 hier eine schnelle Copypasty für die notwendigen Ports.

Repository-Services, Datamover und NFS-Server:

netsh advfirewall firewall add rule name="VEEAM Repository" dir=in action=allow protocol=tcp localport=2500-3300
netsh advfirewall firewall add rule name="VEEAM Datamover" dir=in action=allow protocol=tcp localport=6162
netsh advfirewall firewall add rule name="VEEAM vPower NFS" dir=in action=allow protocol=tcp localport=6161
netsh advfirewall firewall add rule name="VEEAM Backup Proxy" dir=in action=allow protocol=tcp localport=6160

# Nur wenn Veeam-Agenten auf das Repository sollen
netsh advfirewall firewall add rule name="VEEAM Backup Repository-Agents" dir=in action=allow protocol=tcp localport=10001

Daz braucht man dann nur noch 139/445 für das Deployment und Updates (für ein deutsches Windows 2019/2022). Dazu enablen wir einfach die „default“ Regeln und bauen keine zusätzlichen:

netsh advfirewall firewall set rule name="COM+-Netzwerkzugriff (DCOM-In)" new enable=yes
netsh advfirewall firewall set rule name="Datei- und Druckerfreigabe (SMB eingehend)" new enable=yes

Windows Server (alle Versionen) NTP-Server via W32Time konfigurieren

Dieser Artikel funktioniert auch weiterhin – unter Windows Server 2003 bis zu Windows Server 2022. Und bis heute hat Microsoft kein GUI dazu …

Der Windows Zeitdienst (W32Time) kann so einiges. Natürlich sind die sinnvollen und zentral wichtigen Konfigurationsoptionen dazu nicht in einem hübschen Aufgabenorientierten GUI zusammengefasst, sondern gut an der Kommandozeile versteckt. So lässt sich schnell via Batch der NTP (auch der NTP auf Domänencontrollern) prüfen.

Prinzipiell ist der PDC-Emulator immer die erste und fundamentalste Zeitquelle. An dem PDC-Emulator jeder Domain synchronisieren sich die Domänenmitglieder. Damit das klappt, muss dieser „autorisierend“ sein und konsequenterweise auch eine korrekt gehende Uhr haben. Bei einem Zeitunterschied von mehr als fünf Minuten zwischen Server und Client war es das sonst mit der (Kerberos-) Windows-Anmeldung.

PDC-Emulator finden (auf einem DC ausführen)

Mit dieser Abkürzung findet man „seinen“ PDC Zeitserver

ntdsutil roles connections "connect to server SERENITY" q "select operation target" "list roles for connected server" q q q |find/I "PDC"

Windows Zeitserver konfigurieren (auf dem PDC-Emulator ausführen)

net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org 3.de.pool.ntp.org"
w32tm /config /reliable:yes
net start w32time

Mehrere Peers werden in der Liste durch Leerzeichen getrennt, die Peerliste wird von Anführungszeichen umfasst. Ab Windows Server 2016 hat Microsoft das NTP-Verhalten angepasst um den RFC-Spezifikationen zu entsprechen und empfiehlt seitdem bei zwei Peers einen davon mit dem Flag 0x2 wie folgt niedriger zu priorisieren – oder alternativ mehr Peers zu verwenden (siehe oben).

w32tm /config /syncfromflags:manual /manualpeerlist:"de.pool.ntp.org pool.ntp.org,0x2"

Der Server muss logischerweise dafür auch NTP(UDP) mit dem Internet sprechen dürfen, sonst hagelt es W32TM-Fehler im Ereignisprotokoll. Die Synchronisation kann man schnell testen mit:
w32tm /query /status
Und nochmal die Synchronisation vom NTP anstoßen:
w32tm /resync

Testen

Der NTP (und dessen Uhrzeit) lässt sich relativ einfach an der Kommandozeile testen. Mehr dazu im Artikel Testen von NTP