Keine CU Updates über WSUS nach Inplace Upgrade von Windows 10 auf Windows 11

[NorbertFe 2.035]

vor 3 Minuten schrieb Alex_a10:

das keine weiteren Updates vom WSUS erforderlich sind. 

Was passiert, wenn du diese Clients mal gegen den MU bei Microsoft laufen lässt? Bekommen die dann Updates angeboten? Ich kenn sowas von irgendeiner Serverversion, bei der im WSUS irgendeine Abhängigkeit nicht passte und deswegen nichts angeboten wurde. Aber auch nur, wenn man ein Inplace Update durchgeführt hat. 

[zahni 554]

Solche Effekte gab es mal bei anderen Windows-Versionen, wenn der SUS-Client zu alt war.

Ich habe eben noch das hier gefunden:

 

https://learn.microsoft.com/de-de/windows-server/administration/windows-server-update-services/plan/plan-your-wsus-deployment#uup-considerations

[Sunny61 806]

@zahni Danke, die URL kannte ich nicht. ;)

 

@Alex_a10 Wie aktuell ist denn die Source für das Inplace Upgrade? Habt ihr dort das letzte CU integriert? Das wäre auch noch eine Möglichkeit.

[Weingeist 159]

Bei einem Windows 11 Build dürfte es nicht an veraltetem Update Client liegen. Allerhöchstens an einem veralteten WSUS. Ist aber auch eher unwahrscheinlich. Synchronisiert der WSUS überhaupt die Windows 11-Updates? Sonst hilft nämlich alles nichts.

Zum test könntest auch mal einen neuen Windows 11 aufsetzen und schauen ob der die Updates kriegt.

 

Und da MS mit fast allen Builds irgendwas an den Update-Einstellungen rumschraubt und gleiche Einstellungen auf unterschiedlichen Builds teilweise unterschiedlich wirken, würde ich mal schauen ob Du einen aktuellen GPO-Satz mit aktuellen Einstellungen hast und verteilst.

Oder mal nur den WSUS selber per GPO verteilen, keine sonstigen Einstellungen wie Internetadressen verhindern oder ähnliches. Am besten als FQDN und mit SSL.

 

Das Powershell-Script von hier: https://woshub.com/pswindowsupdate-module/ nehme ich gerne um Industriemaschine up to date zu halten (Dienste deaktiviert).

Das erzwingt eine Kommunikation zuverlässig und sofort. Wie auch immer es das anstellt.

 

Zusätzlich könntest das Logging für die Windows-Firewall bzw. BFE aktivieren. Dann siehst ob etwas geblockt wird bzw. oder die Kommunikation an den falschen Ort gehen will. In Deinem Fall würde ich failure und success aktivieren. Zu guter letzte dann noch die Kommunikation mit Wireshark oder so prüfen.

 

Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable
Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable
Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

 

Wenn Du exakt wissen möchtest welcher Dienst wohin möchte, musst den Update-Diensten wie bits, wuauserv und usosvc einen eigenen Hardlink auf die svchost.exe spendieren und im Dienst hinterlegen (z.B. svchost_bits.exe). Dann kannst gut analysieren. Die Exe erscheint dann auch im Sicherheitslog.

 

Die Einträge erscheinen in Sicherheit. Am besten erstellst dann eine gefilterte Ansicht für die Eeignisse der BFE. Auch die Loggrösse würde ich auf mindestens 250 MB hochschrauben.

 

[Alex_a10 0]

Am 6.9.2024 um 17:37 schrieb Sunny61:

@zahni Danke, die URL kannte ich nicht. ;)

 

@Alex_a10 Wie aktuell ist denn die Source für das Inplace Upgrade? Habt ihr dort das letzte CU integriert? Das wäre auch noch eine Möglichkeit.

Hi, die Source ist die aktuell verfügbare 23H2.4. Integriert habe ich das letzte CU noch nicht, aber da auch ein manuelles nachträgliches installieren keine Besserung gebracht hat, habe ich wenig Hoffnung. Werde es aber auf jeden Fall nochmal testen, genau wie das Update gegen die Microsoft Online Update Services.

vor 21 Stunden schrieb Weingeist:

Bei einem Windows 11 Build dürfte es nicht an veraltetem Update Client liegen. Allerhöchstens an einem veralteten WSUS. Ist aber auch eher unwahrscheinlich. Synchronisiert der WSUS überhaupt die Windows 11-Updates? Sonst hilft nämlich alles nichts.

Zum test könntest auch mal einen neuen Windows 11 aufsetzen und schauen ob der die Updates kriegt.

 

Und da MS mit fast allen Builds irgendwas an den Update-Einstellungen rumschraubt und gleiche Einstellungen auf unterschiedlichen Builds teilweise unterschiedlich wirken, würde ich mal schauen ob Du einen aktuellen GPO-Satz mit aktuellen Einstellungen hast und verteilst.

Oder mal nur den WSUS selber per GPO verteilen, keine sonstigen Einstellungen wie Internetadressen verhindern oder ähnliches. Am besten als FQDN und mit SSL.

 

Das Powershell-Script von hier: https://woshub.com/pswindowsupdate-module/ nehme ich gerne um Industriemaschine up to date zu halten (Dienste deaktiviert).

Das erzwingt eine Kommunikation zuverlässig und sofort. Wie auch immer es das anstellt.

 

Zusätzlich könntest das Logging für die Windows-Firewall bzw. BFE aktivieren. Dann siehst ob etwas geblockt wird bzw. oder die Kommunikation an den falschen Ort gehen will. In Deinem Fall würde ich failure und success aktivieren. Zu guter letzte dann noch die Kommunikation mit Wireshark oder so prüfen.

 

Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable
Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable
Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

 

Wenn Du exakt wissen möchtest welcher Dienst wohin möchte, musst den Update-Diensten wie bits, wuauserv und usosvc einen eigenen Hardlink auf die svchost.exe spendieren und im Dienst hinterlegen (z.B. svchost_bits.exe). Dann kannst gut analysieren. Die Exe erscheint dann auch im Sicherheitslog.

 

Die Einträge erscheinen in Sicherheit. Am besten erstellst dann eine gefilterte Ansicht für die Eeignisse der BFE. Auch die Loggrösse würde ich auf mindestens 250 MB hochschrauben.

 

Also das es am WSUS liegt bezweifle ich, da ja Windows 11 Client, die direkt aufgesetzt wurden (mit der gleichen Source die auch für das Inplace Upgrade genutzt wird) ganz normal gepatcht werden.

Und ein händisch mit Windows 10 per USB Stick aufgesetzt Client lässt sich auch mit dieser Source per Implace Upgrade auf Windows 11 aktualisieren. Diese können dann auch normal per WSUS gepatcht werden. Eigentlich können nur unsere per Softwareverteilung installierten Windows 10 Clients nicht richtig per Implace Upgrade aktualisiert. 

 

Daher vermute ich, das es an dieser Windows 10 Installation liegt. Aber ich weiß nicht wie man es reparieren kann, da ja unter Windows 10 der WSUS problemlos geht.  Bzw. nach dem Implace Upgrade auf Windows 11 geht WSUS dort auch noch, nur es werden halt nur Office Patche als fehlend erkannt und installiert. 

bearbeitet 10. September von Alex_a10

[Weingeist 159]

Wie gesagt, ich würde einerseits die Kommunikation prüfen und auch die Einstellungen von Windows Update vergleichen und wens identisch ist, mal manuell mit dem Powershell-Script anstossen. Es muss etwas unterschiedlich sein, der Update-Client dürfte es nicht sein, aber irgend eine Einstellung. Möglich ist auch, dass ein Inplace die klassiche Update-Art verwendet und eine Neuinstallation die neuen kleinen Files und das Du nur eines von beidem in WSUS aktiviert hast.

 

Daher Einstellungen vergleichen. Frisch aufgesetzt vs Inplace. Wenn Du alte Einstellungen drin hast, kann das problemlos eine neue Version der Update-Geschichte lahmlegen. Wenn bei W11 alles über UsoSvc läuft (weiss ich nicht, W11 noch nicht analysiert) und früher über wuauserv dann kann es auch sein, dass deine Firewall-Rules nicht mehr passen (Wenn Du Standard-Block-Out drin hast und neue Freigaben fehlen würden). Daher, FW-Logs aktivieren, dann siehst ob und wohin die Kommunikation geht.

 

Ein paar Reg-Pfade zum vergleichen:

HKLM\SOFTWARE\Microsoft\PolicyManager\default\Update

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

sowie die Wow64 Pendants

 

Und ja Windows hat manchmal die Eigenart zu sagen, dass alles gut ist, obwohl gar keine Kommunikation möglich ist.

Ich würde ja generell sagen mach alles neu, im kleinen mache ich das immer so. Aber bei so vielen würde ich da auch ein paar Stunden investieren. ;)

bearbeitet 10. September von Weingeist

[Sunny61 806]

vor 4 Stunden schrieb Alex_a10:

die Source ist die aktuell verfügbare 23H2.4. Integriert habe ich das letzte CU noch nicht, aber da auch ein manuelles nachträgliches installieren keine Besserung gebracht hat, habe ich wenig Hoffnung. Werde es aber auf jeden Fall nochmal testen, genau wie das Update gegen die Microsoft Online Update Services.

Konntest Du denn das schon alles testen?

 

vor 4 Stunden schrieb Alex_a10:

Daher vermute ich, das es an dieser Windows 10 Installation liegt.

Habt ihr eine angepasste W10 Installation? Falls ja, was habt ihr alles angepasst? Was war das Mittel der Wahl zur Anpassung?

 

Installier doch mal ein nacktes W10 von einer Original Source ohne irgendeine Anpassung, dann schick das Gerät zum WSUS, das geht übrigens auch ohne Domain Join. Lass ihn sich aktualisieren, jetzt machst Du ein Inplace mit der Original Source von MSFT, verlangt der Client jetzt vom WSUS Updates?

[Alex_a10 0]

Hallo zusammen,

 

nach langen Testen haben wir das Problem gefunden und konnten es beheben. Es waren mehrere Dinge  Einmal waren es die WSUS Einstellungen, die aus dem alten Windows 10 mit übernommen wurden und nicht richtig durch die GPO neu gesetzt wurden, obwohl die GPO die gleiche ist. Und ebenfalls waren es zwei Cache Ordner, in denen alte Sachen mit übernommen wurden.

 

Wir haben ein Script gebaut, dass den fehlerhaften Registry Schlüssel löscht, dann die Dienste beendet und die Ordner umbenennt und dann die Dienste wieder startet. Und am Ende nochmal die GPO aktualisiert.

 

Es war folgender Registry Key:

HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

 

und die beiden Ordner mit dem Cache.

 

C:\Windows\SoftwareDistribution

C:\Windows\System32\catroot2

 

Diese Dienste mussten vorher beendet werden.

wuauserv, bits und cryptsvc

 

 

 

 

 

[Sunny61 806]

vor einer Stunde schrieb Alex_a10:

Es war folgender Registry Key:

HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Und welcher Wert denn genau? Oder einfach pauschal?

[Alex_a10 0]

Am 2.10.2024 um 16:01 schrieb Sunny61:

Und welcher Wert denn genau? Oder einfach pauschal?

Es waren mehrere Einträge, die nicht übereingestimmt haben. Daher haben wir den ganzen Schlüssel pauschal gelöscht, um ihn danach wieder sauber über GPO zu setzen.

bearbeitet 7. Oktober von Alex_a10

[Sunny61 806]

vor 11 Minuten schrieb Alex_a10:

Es waren mehrere Einträge, die nicht übereingestimmt haben.

Das hilft leider nicht, welche Werte waren es denn genau?

 

vor 11 Minuten schrieb Alex_a10:

Daher haben wir den ganzen Schlüssel pauschal gelöscht, um ihn danach wieder sauber über GPO zu setzen.

Da können bis zu 40 Werte drin stehen, da ist es schon hilfreich genau zu wissen was vorher und nachher drin stand und so das Update verhindert hat.

[Weingeist 159]

vor 21 Minuten schrieb Sunny61:

Da können bis zu 40 Werte drin stehen, da ist es schon hilfreich genau zu wissen was vorher und nachher drin stand und so das Update verhindert hat.

Ja fände ich auch interessant. Vor allem im Hinblick darauf, falls alte Flags allenfals doch noch ausgewertet werden obwohl sie mit dem aktuellen Rule-Set gar nicht mehr gesetzt werden können. Und: Du möchtest generell alle notwendigen Werte explizit konfiguriert haben damit sowas nicht passiert, auch nicht unabsichtlich.

 

Oft sind es die Internetadresse wo nicht bezogen werden soll wo z.B. eine interne FQDN auch als Internetadresse angeschaut wird. Oder die Geschichte mit der Umgehung der neuen Routinen welche nicht von jedem UpdateClient genau gleich ausgewertet wird. Aber eben, interessant wäre tatsächlich welche das genau sind. Wirst ja sicher einen RegShot oder Export gemacht haben den man vergleichen kann oder?