nikolauspflege 0 Geschrieben 17. Oktober Melden Teilen Geschrieben 17. Oktober (bearbeitet) Hi Zusammen, ich habe ein merkwürdiges Problem. Ich habe in unserem WSUS (Server 2022) vor kurzem "Windows 11" als Produkt hinzugefügt. Kurze Zeit später sind unserer Windows 10 (22H2) Geräte bei der Suche nach Updates in einen timeout gelaufen. Fehler 0x800705b4 Eine Updatesuche ist nicht mehr möglich. Auf anderen Server 2022 oder Server 2019 Systemen ist die Updatesuche aber noch möglich. Ich habe das ganze mit Backup-Restores mehrfach getestet. Es genügt, das Produkt "Windows 11" hinzuzufügen, die Updates müssen nicht einmal genehmigt werden. Also gut, dachte ich mir, dann setzen wir die ganze Nummer nochmal frisch auf. Also habe ich beide WSUS Server (up und downstream) komplett neu aufgesetzt. Inkl. AJTek Cleanup, SSL, IIS Optimierungen und so weiter. Alles "from scratch" Nun konnten die W10 clients wieder Updates ziehen. Also habe ich Snapshots gezogen und wieder das Produkt "Windows 11" hinzugefügt. Unmittelbar danach sind die W10 Clients wieder in den Timeout gelaufen bzw. suchen ewig nach Updates bevor der Timeout Fehler kommt. Freue mich über jeglichen Denkanstoß! Habe dazu auch einen Faden auf wsus.de eröffnet https://www.wsus.de/cgi-bin/yabb/YaBB.pl?num=1729164077/0#0 Grüße bearbeitet 17. Oktober von nikolauspflege Zitieren Link zu diesem Kommentar
Admin666 3 Geschrieben 22. Oktober Melden Teilen Geschrieben 22. Oktober Hallo Niko, das ist ein seltsames Problem das du da hast, Kannst du mir gerade noch sagen ob du "nur" Windows 11 angeklickt hast? Speichert dein WSUS die Updates oder lässt du die von den Clients und Servern runterladen bzw über einen anderen PC/Server verteilen? Hast du eine neue Gruppe angelegt bei "Computer"? Hast du eine Automatische Genehmigung drinne? Wenn ja hast du es mal ohne versucht? Zitieren Link zu diesem Kommentar
nikolauspflege 0 Geschrieben 22. Oktober Autor Melden Teilen Geschrieben 22. Oktober vor 22 Minuten schrieb Admin666: Zwischen dem WSUS Server und den Clients sind diverse Firewalls. Auf denen war nur Port 8531 freigegeben. WSUS ist komplett auf SSL gestellt und überall ist Port 8531 angegeben. Nachdem 8530 freigegeben wurde, ging es instant. Vielen Dank für die Hilfe hier! 1 Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 22. Oktober Melden Teilen Geschrieben 22. Oktober Ohne 8530 (http wsus) kann es aber vorher auch nicht funktioniert haben und kann damit eben genau nicht an der Auswahl von Windows 11 im WSUS liegen. Zitieren Link zu diesem Kommentar
nikolauspflege 0 Geschrieben 22. Oktober Autor Melden Teilen Geschrieben 22. Oktober vor 2 Minuten schrieb NorbertFe: Ohne 8530 (http wsus) kann es aber vorher auch nicht funktioniert haben und kann damit eben genau nicht an der Auswahl von Windows 11 im WSUS liegen. Doch so war es aber :) Ich hatte eine Testmaschine, die auf dem selben vcenter wie der WSUS läuft. Dort ging es die ganze zeit. Ich dachte aber es läge an unterschiedlichen GPO Einstellungen oder daran dass es sich um ein 20H2 W10 handelte für das der WSUS ohnehin nichts mehr liefert (Office Udpates konnten installiert werden). Hier greift aber keine FW weshalb die Suche hier auch nach dem Hinzufügen von W11 noch ging. Ich hab das ganze Szenario heute zum X. mal durchgespielt. Update-Suche UND Installation auf Clients außerhalb des RZ hat super funktioniert, Clients sind up2date. Haben gestern mehrere Neuinstallationen durchlaufen lassen, ohne Probleme. Es war sicher nur Port 8531 freigegeben. Sobald W11 hinzugefügt und fertig gesynced war, liefen die W10 22H2 Clients in den Timeout. Kaum hatten wir port 8530 freigegeben war die Suche erfolgreich. Es ging definitiv davor ohne Port 8530. Suche und Installation. Zitieren Link zu diesem Kommentar
Admin666 3 Geschrieben 22. Oktober Melden Teilen Geschrieben 22. Oktober (bearbeitet) Ich bin jetzt kein Experte aber das einzige das sowas erklären würde wäre wenn MS die Win 10 Updates auf genau diesen Port legen würde wenn im WSUS Win 11 hinzugefügt wird. Denke aber mal das es sehr unwahrscheinlich ist. bearbeitet 22. Oktober von Admin666 Zitieren Link zu diesem Kommentar
nikolauspflege 0 Geschrieben 22. Oktober Autor Melden Teilen Geschrieben 22. Oktober Es kommt mir auch komplett spanisch vor, so ist das nicht. Allerdings habe ich das nun wirklich mindestens 5 mal durchgespielt und habe die gesamte WSUS Umgebung neu aufgesetzt. Vor W11 gings nur mit Port 8531, danach nicht mehr. Super strange. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 22. Oktober Melden Teilen Geschrieben 22. Oktober (bearbeitet) Zitat WSUS erfordert zwei Ports für Verbindungen mit anderen WSUS-Servern und Clientcomputern. Ein Port verwendet SSL/HTTPS, um Update-Metadaten (wichtige Informationen zu den Updates) zu senden. Standardmäßig ist dies Port 8531. Ein zweiter Port verwendet HTTP, um Updatenutzlasten zu senden. Standardmäßig ist dies Port 8530. Zitat Sie können nicht die gesamte WSUS-Website so konfigurieren, dass SSL erforderlich ist. WSUS ist nur für die Verschlüsselung von Updatemetadaten konzipiert. Auf dieselbe Weise werden die Updates auch von Windows Update verteilt. https://learn.microsoft.com/de-de/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus Also ich gehe nicht davon aus, dass sich an der WSUS Funktionsweise irgendwas geändert hat. Da muss irgendwo an anderer Stelle bei dir das "Problem" liegen. Und bevor jetzt jemand sagt, ich würde das einfach so behaupten: Wenn ich bei mir in der DMZ den Port 8530 schließe zum WSUS, dann sieht mein Server in der DMZ zwar die Updates, kann sie aber nicht runterladen. Also genau so, wie das bei MS vorgesehen ist. Und ich habe natürlich auch Windows 11 im WSUS freigegeben. bearbeitet 22. Oktober von NorbertFe 1 Zitieren Link zu diesem Kommentar
Admin666 3 Geschrieben 22. Oktober Melden Teilen Geschrieben 22. Oktober Ah danke Norbert hab mich noch nicht in dieser Tiefe mit dem WSUS beschäftigt (fehlende Zeit ) Gut was neues zu lernen. Zitieren Link zu diesem Kommentar
nikolauspflege 0 Geschrieben 22. Oktober Autor Melden Teilen Geschrieben 22. Oktober vor 21 Minuten schrieb NorbertFe: https://learn.microsoft.com/de-de/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus Also ich gehe nicht davon aus, dass sich an der WSUS Funktionsweise irgendwas geändert hat. Da muss irgendwo an anderer Stelle bei dir das "Problem" liegen. Und bevor jetzt jemand sagt, ich würde das einfach so behaupten: Wenn ich bei mir in der DMZ den Port 8530 schließe zum WSUS, dann sieht mein Server in der DMZ zwar die Updates, kann sie aber nicht runterladen. Also genau so, wie das bei MS vorgesehen ist. Und ich habe natürlich auch Windows 11 im WSUS freigegeben. Ich will dir (und vor allem MS) auch wirklich nicht widersprechen. Aber ich habe mich nun ne starke Woche intensiv mit dem Thema beschäftigt. Ich habe gestern den funktionierenden Snap wiederhergestellt, konnte Updates suchen und installieren auf Clients außerhalb des RZ. Also durch die Firewalls und nur über 8531. Der FW Admin hat Urlaub und hat da ganz sicher nichts kurzfristig umgestellt. Meine Kollegen haben mehrere Clients frisch aufgesetzt und mit Updates vom WSUS bespielt ohne Probleme. Ich konnte den WSUS mehrfach manuell syncen. Dann habe ich W11 aktiviert im WSUS und solange der nächste manuelle Sync noch lief, konnte ich Updates auf W10 22H2 suchen. Kaum war der Sync abgeschlossen (es wurden ca. 350 Updates gefunden aber noch nicht heruntergeladen) ist die Suche wieder in einen Timeout gelaufen. Auch mit anschließendem WU Reset auf dem Client. (Client vorher aus WSUS entfernt). Auf der Firewall konnten wir dann im Log sehen, dass Verbindungsversuche via 8530 geblockt wurden. Und kaum wurde der Port freigegeben, war die Suche wieder erfolgreich. Im IIS stehen alle benötigten Pools auf "Require SSL" und in der Reg der Clients steht der WSUS in allen drei Schlüsseln mit 8531. Ich checks ja selber nicht, wir nutzen schon lange WSUS mit SSL/8531 und hatten bis dato keine Probleme bei der Update Installation. Ich kann mir höchstens vorstellen, dass die Cients bisher eine Art Fallback über 8531 gemacht haben wenns über 8530 nicht ging. Und dass das nun, warum auch immer, nicht mehr geht wenn W11 mit im Paket ist. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 22. Oktober Melden Teilen Geschrieben 22. Oktober vor 30 Minuten schrieb nikolauspflege: allen drei Schlüsseln mit 8531. Bei mir nicht. Denn der dritte wird so gut wie nie benötigt. Kann es evtl. sein, dass die Clients sich die Updates eben nicht vom WSUS sondern von MS direkt geholt haben (Stichwort Dual scan)? vor 4 Minuten schrieb NorbertFe: Denn der dritte wird so gut wie nie benötigt https://community.spiceworks.com/t/clarification-on-wsus-alternate-download-server-setting/946748/3 ist hier übrigens ganz gut erklärt. 1 Zitieren Link zu diesem Kommentar
nikolauspflege 0 Geschrieben 22. Oktober Autor Melden Teilen Geschrieben 22. Oktober vor 7 Minuten schrieb NorbertFe: Bei mir nicht. Denn der dritte wird so gut wie nie benötigt. Kann es evtl. sein, dass die Clients sich die Updates eben nicht vom WSUS sondern von MS direkt geholt haben (Stichwort Dual scan)? https://community.spiceworks.com/t/clarification-on-wsus-alternate-download-server-setting/946748/3 ist hier übrigens ganz gut erklärt. Ja gut möglich, dass es das nicht braucht. Dualscan ist und war jedenfalls die ganze zeit disabled. Hier mal meine Client Settings: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "SetActiveHours"=dword:00000001 "ActiveHoursStart"=dword:00000005 "ActiveHoursEnd"=dword:00000017 "SetAutoRestartRequiredNotificationDismissal"=dword:00000001 "AutoRestartRequiredNotificationDismissal"=dword:00000002 "ExcludeWUDriversInQualityUpdate"=dword:00000001 "DisableWindowsUpdateAccess"=dword:00000001 "DisableDualScan"=dword:00000001 "ElevateNonAdmins"=dword:00000000 "WUServer"="https://update.xxx.xx:8531" "WUStatusServer"="https://update.xxx.xx:8531" "UpdateServiceUrlAlternate"="https://update.xxx.xx:8531" "DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001 "TargetGroupEnabled"=dword:00000001 "TargetGroup"="Notebooks und Fat Clients" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000004 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:0000000c "ScheduledInstallEveryWeek"=dword:00000001 "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "AutoInstallMinorUpdates"=dword:00000000 "NoAUAsDefaultShutdownOption"=dword:00000001 "AlwaysAutoRebootAtScheduledTime"=dword:00000000 "EnableFeaturedSoftware"=dword:00000000 "DetectionFrequencyEnabled"=dword:00000001 "DetectionFrequency"=dword:00000004 "UseWUServer"=dword:00000001 "IncludeRecommendedUpdates"=dword:00000001 "AllowMUUpdateService"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization] "DODownloadMode"=dword:00000063(99) Zitieren Link zu diesem Kommentar
nikolauspflege 0 Geschrieben 23. Oktober Autor Melden Teilen Geschrieben 23. Oktober vor 20 Stunden schrieb nikolauspflege: Ja gut möglich, dass es das nicht braucht. Dualscan ist und war jedenfalls die ganze zeit disabled. Hier mal meine Client Settings: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "SetActiveHours"=dword:00000001 "ActiveHoursStart"=dword:00000005 "ActiveHoursEnd"=dword:00000017 "SetAutoRestartRequiredNotificationDismissal"=dword:00000001 "AutoRestartRequiredNotificationDismissal"=dword:00000002 "ExcludeWUDriversInQualityUpdate"=dword:00000001 "DisableWindowsUpdateAccess"=dword:00000001 "DisableDualScan"=dword:00000001 "ElevateNonAdmins"=dword:00000000 "WUServer"="https://update.xxx.xx:8531" "WUStatusServer"="https://update.xxx.xx:8531" "UpdateServiceUrlAlternate"="https://update.xxx.xx:8531" "DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001 "TargetGroupEnabled"=dword:00000001 "TargetGroup"="Notebooks und Fat Clients" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000004 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:0000000c "ScheduledInstallEveryWeek"=dword:00000001 "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "AutoInstallMinorUpdates"=dword:00000000 "NoAUAsDefaultShutdownOption"=dword:00000001 "AlwaysAutoRebootAtScheduledTime"=dword:00000000 "EnableFeaturedSoftware"=dword:00000000 "DetectionFrequencyEnabled"=dword:00000001 "DetectionFrequency"=dword:00000004 "UseWUServer"=dword:00000001 "IncludeRecommendedUpdates"=dword:00000001 "AllowMUUpdateService"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization] "DODownloadMode"=dword:00000063(99) Hier wurden unsere Client-Settings kommentiert. Ich werde Sie anhand dieser Infos nochmal überarbeiten. https://learn.microsoft.com/en-us/answers/questions/2105450/wsus-after-adding-w11-as-product-w10-machines-can?page=1&orderby=helpful&comment=answer-1866565#newest-answer-comment Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.