[English]Ich fasse die Meldungen aus der Leserschaft im Umfeld des Juli-Patchday (8. Juli 2025) mal zusammen. Der Windows Server Update Services (WSUS) hat seit einigen Stunden wohl massive Probleme und kann derzeit nicht mit den Microsoft-Servern synchronisieren. Sprich: Es werden keine Juli 2025-Updates von den Servern abgerufen. Ergänzung: Sollte behoben sein.
Eine erste Lesermeldung
Blog-Leser Frank M. hat sich gegen 9:00 Uhr per E-Mail gemeldet und fragte, ob es nur ihm so gehe, oder ob sich noch andere Windows-Nutzer bzw. -Administratoren bei mir gemeldet haben. Denn er konnte im Internet noch nichts finden.
Frank schreibt, dass "seit heute morgen es so scheint", als ob der WSUS (Windows Server Update Services) im Unternehmen sich nicht mehr mit den Servern von Microsoft verbinden kann. In der Datei:
C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log
sind folgende Fehler vorhanden:
Warning WsusService.40 WebServiceCommunicationHelper.ProcessWebServiceProxyException ProcessWebServiceProxyException found Exception was WebException. Action: Retry. Exception Details: System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. ---> System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat 135.236.118.2
Die im log genannte IP-Adresse kann variieren, je nachdem, welcher Microsoft Server kontaktiert wird. In diesem Kommentar wird die IP 52.165.164.33:443 genannt. Wegen des Fehlers kann der WSUS auch keine anstehenden Juli 2025-Updates mehr von den Microsoft Servern mehr ziehen – Administratoren müssten höchstens versuchen, ob ein Import heruntergeladener Update-Pakete möglich ist.
Weitere Meldungen der Leserschaft
Bis zu diesem Zeitpunkt hatte ich keine weiteren Meldungen erhalten. Das Ganze scheint aber kein Einzelfall zu sein, da ich bei der Freigabe der Leserkommentare zu den Patchday-Beiträgen zahlreiche Meldungen gesehen habe. Zum Artikel Patchday: Windows 10/11 Updates (8. Juli 2025) hat Blog-Leser Tobi in folgendem Kommentar die gleiche Beobachtung bestätigt.
Gibt es ggf. aktuell gerade Probleme mit dem WSUS-Sync? Ich habe das Problem bei zwei Firmen, wovon eine heut um 00:15 Uhr noch erfolgreich synchronisiert hat, jetzt aber nicht mehr. Beim anderen Server von Firma#2 gab es lt Log heute morgen um 7:03 den ersten Fail und seitdem hängt das dort bei 0%.
Gerade kam auch noch eine Rückmeldung eines Kollegen aus einer anderen (dritten) Firma, der mir das Problem bestätigte. Somit kann ich die Frage fast in eine Aussage umwandeln: aktuell geht kein WSUS Sync …
Diese Beobachtung wird in weitere Folgekommentaren bestätigt – Administratoren schreiben, die Sync-Probleme seit dem 9. Juli 2025, 6:00 Uhr, zu haben. Laut diesem Kommentar konnte zum 8. Juli 2025 gegen 21:14 Uhr ein WSUS noch synchronisieren.
Auch zum Blog-Beitrag Patchday: Windows Server-Updates (8. Juli 2025) gibt es einige Kommentare zu WSUS-Synchronisationsproblemen. Im Kommentar hier schreibt ein Leser, dass die Sync-Probleme des WSUS bereits gegen 2:00 Uhr die Nacht (9. Juli 2025) aufgetreten seien.
Gibt es jemand in der Leserschaft, der bestätigen kann, dass sein WSUS zum 9. Juli 2025 so zwischen 4:00 Uhr bis 9:30 Uhr mit den Windows Servern synchronisieren konnte und der auch keine Fehlereinträge in der oben genannten log-Datei hat?
Ist der RPC-Fix die Ursache?
Ergänzung 1: So ganz blicke ich noch nicht durch, aber für Windows Server 2019 hat Microsoft zum 8. Juli 2025 das Update KB5062557 freigegeben. Dort findet sich folgende Beschreibung:
Bolko weist weiter unten in diesem Kommentar auf eine Inkompatibilität hin (danke dafür). Steht auch in obigem Screenshot unter "Microsoft PRC Netlogon protocol": Nach der Installation dieses Updates erlauben Active Directory-Domänencontroller anonymen Clients nicht mehr, einige RPC-Anforderungen über den Netlogon-RPC-Server aufzurufen. Diese Anfragen beziehen sich in der Regel auf den Standort des Domänencontrollers. Bestimmte Datei- und Druckdienstsoftware (einschließlich Samba) kann betroffen sein.
Hier ist mir aber unklar, wie dies den WSUS bei der Synchronisation beeinträchtigen kann. Denkbar wäre, dass Microsoft die Nacht den Patch auf seine Update-Server verteilt hat und die WSUS bei Kunden nun Probleme mit der Synchronisierung bekommen. Würde das Fehlerbild erklären, dass einzelne WSUS noch Updates erhielten (weil die Update-Verteilung durch Microsoft an die eigenen Update-Server vermutlich gestuft erfolgt und es dann darauf ankam, welcher Update-Server vom WSUS kontaktiert wurde). Hier muss abgewartet werden, ob sich Microsoft zu äußert.
Weitere Analyse von Lesern
Ergänzung 2: Martin Feuerstein hat sich per E-Mail gemeldet, weil er ebenfalls betroffen ist und schrieb ebenfalls, dass "seit heute morgen die WSUS-Synchronisierung von den Microsoft-Servern nicht mehr zu funktionieren scheint". Eine manuelle Synchronisation hängt ewig bei 0%. Martin hat bis jetzt vier Server in verschiedenen Umgebungen überprüft (3x Server 2025, 1x Server 2016) und erhält überall denselben Fehler.
Bei dem Server 2016 ohne vorgeschalteten Webproxy (nur NAT-Routing) erhält er diese Meldung:
WebException: Timeout für Vorgang überschritten bei System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) bei Microsoft.UpdateServices.ServerSync.ServerSyncCompressionProxy.GetWebResponse(WebRequest webRequest) bei System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) bei Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetRevisionIdList(Cookie cookie, ServerSyncFilter filter) bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetRevisionIdList(ServerSyncFilter filter, Boolean isConfigData) bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
Bei einem Windows Server 2025 ohne vorgeschalteten Webproxy (nur NAT-Routing) erhält der Leser diese Meldung:
WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. ---> System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat 20.10.149.151:443 bei System.Net.HttpWebRequest.GetRequestStream(TransportContext& context) bei System.Net.HttpWebRequest.GetRequestStream() bei System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) bei Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetRevisionIdList(Cookie cookie, ServerSyncFilter filter) bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetRevisionIdList(ServerSyncFilter filter, Boolean isConfigData) bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
Ist ein Web-Proxy vorgeschaltet, wird diese Meldung zurückgegeben (nur die erste Zeile ist anders):
WebException: Die zugrunde liegende Verbindung wurde geschlossen: Die Verbindung wurde unerwartet getrennt. bei System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) bei Microsoft.UpdateServices.ServerSync.ServerSyncCompressionProxy.GetWebResponse(WebRequest webRequest) bei System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) bei Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetRevisionIdList(Cookie cookie, ServerSyncFilter filter) bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetRevisionIdList(ServerSyncFilter filter, Boolean isConfigData) bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
Martin Feuerstein merkte an: "Vielleicht sind noch mehr Admins von dem Problem betroffen.", was durch obige Berichte ja bestätigt ist.
Ein anonymer Leser wies in einem nachfolgenden Kommentar darauf hin, dass die Microsoft-Server zur Auslieferung von Updates momentan nicht erreichbar sind.
Eine Erklärung, warum der Server nicht antwortet, habe ich nicht, denn die Hinweise von Microsoft in diesem Support-Beitrag beziehen sich auf Juli 2020, sind also 5 Jahre alt.
Im englischen Blog schrieb jemand: "What worked for me is to uncheck "updates" classification from products and updates configuration, and after manual sync it worked, at least security and critical are downloaded. If the error shows again, sync again, it worked for me the second time."
Microsoft untersucht das Problem
In den nachfolgenden Kommentaren wird ja darauf hingewiesen, dass Nutzer Tickets bei Microsoft eröffnet haben und dass das Unternehmen das Problem untersucht. Auf X habe ich diese Meldung eines MS Beta Engineering-Mitarbeiters gesehen:
WSUS sync issues. Teams still investigating the cause. Preliminary findings likely point towards some bad revisions might have caused the delta sync to fail triggering full sync and making catalog servers unresponsive.
Und es gibt eine offizielle Antwort, die ich von Patchmanagement.org habe und hier mal einstelle:
Affected platforms
Client Versions Message ID Originating KB Resolved KB
Windows 11, version 24H2 WI1112355 – –
Windows 11, version 23H2 WI1112356 – –
Windows 11, version 22H2 WI1112357 – –
Windows 10, version 22H2 WI1112358 – –
Windows 10, version 21H2 WI1112359 – –
Windows 10 Enterprise LTSC 2019 WI1112362 – –
Windows 10, version 1607 WI1112363 – –
Windows 10 Enterprise 2015 LTSB WI1112364 – –
Server Versions Message ID Originating KB Resolved KB
Windows Server 2025 WI1112360 – –
Windows Server 2022 WI1112361 – –
Windows Server, version 1809 WI1112362 – –
Windows Server 2019 WI1112362 – –
Windows Server 2016 WI1112363 – –
Windows Server 2012 R2 WI1112365 – –
Windows Server 2012 WI1112366 – –
Devices trying to synchronize updates from Microsoft Updates using Windows Server for Update Services (WSUS) might fail to complete the synchronization process. As a result, updates cannot be deployed using WSUS or Configuration Manager.
WSUS synchronization tasks are frequently configured to occur automatically in business and enterprise environments, although manual tasks are also possible. Error logs for WSUS are usually found in the SoftwareDistribution.log file under C:\Program Files\Update Services\LogFiles\. Common messages may include text similar to "Unable to connect to the remote server" and "A connection attempt failed because the connected party did not properly respond after a period of time"
There is no workaround at this time. A problematic update revision in the storage layer has been identified as potentially causing this issue, and repairs are in progress.
Next steps: We are working on a resolution and will provide more information when it is available.
Ergänzung: Das Problem wurde durch Microsoft behoben, siehe WSUS-Synchronisierung sollte wieder funktionieren – Juli 2025-Bug behoben.
Ähnliche Artikel:
Microsoft Security Update Summary (8. Juli 2025)
Patchday: Windows 10/11 Updates (8. Juli 2025)
Patchday: Windows Server-Updates (8. Juli 2025)
MVP: 2013 – 2016
Kein generelles Problem, hier sind die Updates angekommen.
Doch, es ist ein generelles Problem.
Siehe die Samba-Mailing-List.
Die Samba-Programmierer arbeiten mit Microsoft zusammen und das Problem ist bestätigt.
forum. proxmox. com/threads/breaking-change-2025-july-8-update-to-active-directory-domain-controllers-for-windows-server-versions-prior-to-2025.168191/#post-782007
siehe IBM-Support:
– "Microsoft Windows Server update disables an API that is used by Storage Scale Cluster Export Services (CES) SMB (Samba Winbind)."
– "Without the API, users no longer can connect to SMB shares served from Storage Scale CES SMB, "
– "NFS users are impacted"
ibm. com/support/pages/node/7239096
Hier sind die Updates ebenfalls wie immer gestern Abend synchronisiert worden.
Es geht aber seit 04:00 Uhr nicht (heute)
Sogar früher. Um 00:44 ging es bei uns noch ein letztes Mal, um 02:44 dann nicht mehr. Die Fehlercodes haben sich seitdem mehrfach geändert.
Die aktuellen Patchday-Updates haben wir somit gestern Abend noch bekomen.
Ich befürchte, dass unser WSUS nach der Fehlerbeseitigung alles bisher Bekannte "vergisst" und sämtliche Updates erneut runter lädt.
Unsere WSUS haben die Updates heute um 00:10 runtergeladen. Meine Privat-PCs habe ich heute morgen ab 8:00 zum Update angestoßen, sie haben es alle runter geladen und installiert.
Ich bleibe dabei, kein generelles Probelm. Vielleicht hängt ihr an einem anderen Distributions-Punkt, geht ja nicht alles global über den gleichen Server. Die werden ja sicher eine regionale Lastverteilung haben.
Identisches Problem bei uns mit dem WSUS seit heute Morgen. Habe bisher auch noch nichts im Netz gefunden zu dem Problem.
Das ist eigenartig. Ich habe gestern Abend manuell synchronisiert (das würde sonst automatisch um 04.30 Uhr passieren), und sowohl Synchronisierung wie auch Download der Updates waren problemlos. Auch die Synchronisierung um 04.30 Uhr, die automatisch erfolgt ist, verlief ohne Fehler. Genutztes System ist MS Windows Server 2022 Standard.
Server 2025, hier wurden die Updates synchronisiert aber der Download schlägt mit der genannten Fehlermeldung fehl.
Kann ich bestätigen
Alle 4 Wsus Server Syncen seit 4 Uhr nicht mehr.
Bei uns auch: WSUS synced seit heute nicht mehr (erster Versuch heute um 04:08).
Der RPC-Fix aus dem aktuellen Windows-Update ist inkompatibel mit SMB/Samba/WinBind.
Man braucht ein Samba-Update von mindestens 7.7.2025.
Siehe:
https://www.borncity.com/blog/2025/07/09/patchday-windows-server-updates-8-juli-2025/#comment-222553
Hi, kannst du mich hier mal abholen bitte? Ich habe einen WSUS der um 00:15 Uhr noch erfolgreich gesynct hat und die aktuellen Updates listet. Es wurde bislang noch keines der gestern Nacht veröffentlichten Updates genehmigt oder installiert. Seite heute morgen kann er nicht mehr synchronisieren. Meinst du damit also, dass Microsoft seine eigenen WSUS Server gerade aktualisiert und unsere Domänen-WSUS-Server deshalb nicht mehr zum WSUS verbinden können?
Heißt das, wenn ich meinen WSUS update, sollte es wieder gehen? :D sorry, wenn ich hier auf dem Schlauch steh.
Ja, so meine ich das.
Hold my beer, heißt das wenn ich meinen WSUS patche, dann kann er wieder mit den Microsoft WSUS-Servern sprechen, aber dann können meine Clients ja nicht mehr mit meinem WSUS Server kommunizieren, richtig? :-D
"heißt das wenn ich meinen WSUS patche, dann kann er wieder mit den Microsoft WSUS-Servern sprechen,"
—
Nicht unbedingt.
Weiter unten hier im Strang tauchten zwei weitere Möglichkeiten auf:
– Zertifikatfehler (welches ist noch unbekannt)
– abgestürzter MS-Update-Server (das müssten dann aber schon eine Menge Offline-"Server" sein, wenn der Load-Balancer keinen funktionierenden Update-Server mehr bei Microsoft findet.)
Ob die Clients den gepatchten WSUS dann noch verstehen wird auch gerade getestet von der Microsoft-Qualitätssicherungsabteilung (kleiner Scherz).
Ja, irgendwann die Nacht hat er bei uns auch das syncen eingestellt.
Juli Patche hat er nach Freigabe runterladen können.
Server 2019 Std, engl.
Hallo, ich betreibe 2 WSUS Server mit dem gleichen Problem – der Sync funktioniert nur gelegentlich.
Der WsusService.exe baut Verbindungen zu verschiedenen Netzwerken von Mircosoft auf, die teilweise nicht reagieren. IP-Adressen im Bereich 4.245.x.x. reagieren nie.
Hatte auch teilweise schon Abbruch nach 10 %. Glücklicherweise wurden alle CU heute Nacht heruntergeladen, vor einer Stunde gab es noch Updates für .Net8 und 9.
die .NET 8 und kamen gestern abend schon, wurden dann (zumindest zum Teil) von MS zurückgezogen und dann heute Nacht erneut freigegeben.
Einige 2025-01 .Net 3.5/4.8x wurden auch erneut freigegen nachdem MS die letzten Tage fleißig ältere .Net 3.5/4.8x zurückgezogen hatte und scheinbar aus versehen auch das 2025-01 erwischt hatte, welches noch nicht "superseded" ist!
Achtung: Die neu freigegebenen Updates müssen erneut genehmigt werden.
Das KB5056578 (net Framework 3.5 und 4.8.1 für Win10 v21H2) ist bit-identisch zwischen gestern abend 19:43 Uhr und heute 11:48 Uhr.
Das selbe gilt für NET Desktop Runtime 8.0.18 und 9.0.7.
Kein neuer Download notwendig.
die wurden aber zwischendurch von MS zurückgezogen, je nach WSUS Einstellung werden die dann automatisch abgelehnt
Die Metadaten (Revisionsverlauf) wurden geändert. Aktuell ist Revision 201
Was fällt Microsoft eigentlich ein, der Öffentlichkeit nicht vor dem Patchday mitzuteilen, dass die Updates die Samba-Verbindungen zerstören?
Die wussten es vorher, denn sie haben mit den Samba-Programmierern zusammen gearbeitet, um das Problem zu beseitigen.
Aus der Samba-Mailing-Liste:
From: Ralph Boehme
Subject: [Samba] Important Change in Upcoming Microsoft Update
Date: July 6, 2025 at 6:40:01 AM CDT
[…]
This update includes a change to the Microsoft RPC Netlogon protocol
[…]
Samba running as domain members in these environments will be impacted by this change
[…]
Members of the Samba team have been collaborating with Microsoft and changes to Samba are currently being developed and tested to ensure full compatibility between Samba and Microsoft products. The Samba team is aiming to provide updated Samba releases on Monday evening (UTC+2).
was fällt dir ein, einen Patch freizugeben, ohne die Releasenotes zu lesen und den Patch zu testen?
eine vorraus Information würde nur von denen gelesen, die erstgennantes machen, ergo unnötig
Dass nennt sich effiziente Kommunikation: Microsoft weiß, dass es die Endanwender so oder so spätestens dann bemerken werden, wenn es für sie zu einem Problem geworden ist. In dem Fall wissen sie es dann auch schon und anderenfalls währe das voherige Informieren ohnehin nicht nötig gewesen. So wird der Aufwand der Kommunikation effizient eingespart.
Leider ist dieser eigentlich sarkastisch gemeinte Ablauf inzwischen mehr und mehr Normalität und das nicht nur bei Microsoft.
…es fehlt noch der gekonnt eingewebte Spin mit dem Hinweis auf Samba und Linux…
Dann kann man achselzuckend in die Luft schauen und ein Liedchen pfeifen…
Kann den Defekt an zwei WSUS unter Server 2019 bestätigen.
Letzte erfolgreiche Sync 9.7. 2:00 Uhr. Zu diesem Zeitpunkt kamen aber die Updates nicht mit. Das ist echt problematisch.
Zweiter WSUS steht mit fehlgeschlagener Sync um 4:35. Bei dieser kamen aber dennoch die Updates mit.
Liest sich wie ein Netzwerkfehler. Vielleicht hat MS irgendwelche URIs geändert. Werde mal auf die Firewall schauen.
Das liegt am RPC-FIX.
Der ist inkompatibel mit SMB/Samba/WinBind
Spar dir die Suche nach geänderten URLs oder IP-Adressen etc.
Updates sind hier ebenfalls ohne Probleme angekommen.
Hallo,
hab eben mal in meine WSUS Sync Logs geschaut. Bis zum 09.07.2025 um 00:50 MESZ habe ich knapp über 100 Updates erhalten. Seit 09.07.2025 02:50 MESZ läuft der Sync auf Fehler. Das alles auf einem M$ WSUS. Auf anderen M$ WSUS Systemen sieht es ähnlich aus, dort unterscheiden sich nur die Uhrzeiten geringfügig.
Und, bevor die Frage aufkommt, ich habe nicht geprüft ob alle vorhandenen Updates aus dem Katalog ordentlich im WSUS angekommen sind :)
Best
Nutze Connected Cache, der rollt die Updates ohne Probleme aus
meine Beobachtung:
Wenn man die Updates via WSUS VOR der Installation des Serverupdates 2016 ( & wohl auch 19/22) auf dem WSUS herunterladen lässt läuft es problemlos.
Lässt man einen Sync laufen NACHDEM das Serverupdate installiert wurde lädt sich der SYNC tot -> somit auch kein Download von Updates in den WSUS mehr möglich. Als Workaround könnte man die m. E. nach aber manuell via UpdateCatalog importieren.
unser WSUS ist noch ungepatched (auf Juni Level) dort tritt das Problem auch auf, sollte also nicht am Juli Update liegen.
Bei uns ebenfalls: WSUS unter Windows Server 2025 noch ungepatched.
Kein Sync. mehr möglich
Wenn der Microsoft-Update-Server das Juli-Update schon installiert hat, der lokale WSUS aber noch nicht, dann scheitert die Verbindung.
Beide kommunizierenden Computer müssen zumindest auf dem selben Patchstand Juli-Juli oder Juni-Juni sein.
Der einseitige RPC-Fix bricht die Verbindung.
Habe das Juli Update auf dem WSUS manuell ist installiert, aber der Sync läuft immer noch nicht.
Firewall meldet was von "untrusted Certifacte"
Hallo,
ein Zertifikatsfehler ist auch plausibler als RPC/ NetLogon, da sich der WSUS nicht an den MS Servern anmeldet und auch nicht per SMB die Daten holt.
Grüße
Tja, dann hat Microsoft mal so richtigen Mist gebaut.
Jetzt musst du die Updates manuell aus dem Microsoft-Catalog runterladen und in den WSUS manuell importieren.
Vorher würde ich aber mal ein Support-Ticket bei Microsoft eröffnen und der KI mal so richtig die Meinung geigen.
Benutze farbige Metaphern und Kraftausdrücke, damit es schnell eskaliert.
Jetzt musst du herausfinden, welches Zertifikat bemängelt wird.
Microsoft-SSL-Zertifikat für die HTTPS-Verbindung oder das PKI-Zertifikat für den WSUS-Server?
Kennt jemand die genaue Bezeichnung des Zertifikats?
Gibt es diesen Zertifikat-Fehler auch schon mit Patchstand Juni?
Oder mach einfach ein Support-Ticket bei Microsoft auf.
Hallo,
der WSUS kommuniziert per HTTPS ohne Authentifizierung mit den Servern bei MS, mir erschließt sich nicht, wo da NetLogon oder RPC ins Spiel kommen soll.
Grüße
und wenn ich dann meine WSUS patche, kann der zwar wieder mit MS aber dafür nicht mehr mit den Clienten kommunizieren???
Dachte ich auch, es stellt sich aber raus: das Gerede vom RPC Patch, der angeblich Schuld haben soll ist nicht tragbar. Es ist schlichtweg so, dass die Kontaktadresse, die unsere WSUS anfunken, tot ist, nämlich sws.update.microsoft.com. Es ist auch kein Zertifikatsproblem, die URL ist einfach tot.
Du kannst deine Server aktualisieren und sie kommunizieren weiterhin wie gewohnt mit den Clients, habe bereits mehrere Anwendungsserver aktualisiert, die DCs stehen jedoch noch aus. Habe hier aber keine Bedenken aktuell
Macht auch irgendwie kein Sinn, dass der WSUS-Server sich schon vor dem Download der Patches selbst aktualisiert hat.
Die Frage ist: können Windows Clients ihren lokalen WSUS noch kontaktieren bzw. nach Updates suchen und sie herunterladen. Zumindest das Herunterladen hat vom lokalen WSUS (JuNi-Patchelvel) vom Microsoft Server (vermutlich JuLi-Patchlevel) noch funktioniert. Der hatte um 0:15 Uhr nochmal erfolgreich synchronisiert. Ich patche den gerade und schau dann, was meine Clients machen.
Hallo,
da das per HTTP(S) ohne Anmeldung erfolgt ja, das läuft nicht per SMB.
Grüße
Den WSUS-Server auf den Juli-Stand zu patchen hat bei mir schon mal gar nichts verändert. lokaler WSUS Server hängt weiterhin bei 0%
Bei und wurden die Updates gestern abend schon runtergeladen, aber
unser WSUS (auf Server 2025) konnte das letzte Mal um 2:00 die Updates syncen
Seit 3:00 schlägt es fehl.
• Updates kamen an
• Aktualisierung hängt bei 0% fest in der Suche
• Die Datenbank für genehmigt/abgelehnt ist (wieder mal) zurückgesetzt worden
Microsoft, den monatlichen Mittelfinger zeige ich Dir.
Ich bestätige ebenfalls das Problem auf einem WS2019, kein Sync seit heute Morgen.
Jetzt scheitert es schon an Basisverbindungen, du meine Güte….
Server 2016, nächtliche Synchronisierunge (Start 3:00 Uhr, dann erneut 3:21, 3:44, 4:58 Uhr) fehlerhaft, Synchronisiert wurden beim ersten Versuch 94 Updates (+2 überarbeitete und 2 mit Fehler) , dann keine mehr.
Die Synchronisation um 4:58 Uhr endete mit der Meldung: "Der Upstreamserver kann diese Anforderung nicht verarbeiten, weil er zu stark ausgelastet ist. "
In den Details dann : "WebException: Der Remoteserver hat einen Fehler zurückgegeben: (503) Server nicht verfügbar.
bei System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
bei System.Net.HttpWebRequest.GetRequestStream()
bei System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
bei Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetRevisionIdList(Cookie cookie, ServerSyncFilter filter)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetRevisionIdList(ServerSyncFilter filter, Boolean isConfigData)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)"
Bei dem halbwegs erfolgreichen Sync mit 94 Updates um 3:00 Uhr Meldung: "Beim Versuch, Updates in den Datenspeicher zu importieren, wurde mindestens ein Fehler erkannt. Die Synchronisierung konnte daher nicht ausgeführt werden. Bei der nächsten Synchronisierung wird versucht, die bei diesem Versuch nicht importierten Updates zu importieren".
Die derzeit manuell gestartete Synchronisierung steht bei 0%.
Um 3:00 Uhr kam bei uns also noch ein Großteil der Updates mit und zwei fehlen mir nun.
Synchronisierung heute Morgen um 1.00 Uhr erfolgreich.
Herunterladen der Updates erfolgt erst nach manueller Genehmigung. Werde berichten, ob das dann klappt.
Windows Server 2019, Patch-Stand Juni.
Die Verbindungsprobleme dürfte es eigentlich nur dann geben, wenn der Update-Server von Microsoft und der lokale WSUS einen unterschiedlichen Patchstand haben, also MS mit RPC-Fix und WSUS ohne RPC-Fix oder umgekehrt.
Sobald der MS-Update-Server und der lokale WSUS beide gepatcht sind, sollte die Verbindung funktionieren (Annahme).
Annahme ist falsch!
MS > WSUS mit 06-25 Patch = sync schlägt fehl
MS > WSUS mit 07-25 Patch = sync schlägt fehl
und
WSUS (06-25) > SubWSUS (06-25) = sync geht
WSUS (07-25) > SubWSUS (06-25) = sync geht
WSUS (07-25) > SubWSUS (07-25) = sync geht
Danke für diese Infos.
Dann wäre das ja geklärt.
Das Problem liegt also an den Microsoft-Update-Servern und eventuell an einem Zertifikat?
Unsere Firewall meint "untrusted Certifcate"
Snyc bleibt bei 0% stehen und bricht nach ca. 1h ab, wegen Timeout
Es wäre hilfreich, wenn man den genauen Namen dieses Zertifikats erfahren könnte.
Schau mal bitte im Log der Firewall und des WSUS nach, was kurz vor dem Fehler gemacht wurde, also welches Zertifikat abgefragt wurde.
Wir haben zwei WSUS im Einsatz. Der eine hat heute von 05:06 Uhr bis 05:15 Uhr 53 Updates synchronisiert, der andere hat es um 05:19 Uhr, 06:30 Uhr, 07:07 Uhr und um 07:38 Uhr erfolglos versucht:
"WebException: Der Remoteserver hat einen Fehler zurückgegeben: (503) Server nicht verfügbar."
Beide Server sind auf dem selben Betriebssystem- und Patchlevel.
Zitat:
"Beide Server sind auf dem selben Betriebssystem- und Patchlevel."
—
Stand Juni oder Stand Juli?
Ich nehme an Juni.
Versuche es mal mit Juli.
Stand Juni. Der Server, der von 05:06 Uhr bis 05:15 Uhr 53 Updates synchronisierte, konnte später dann auch nicht mehr synchronisieren. Beide Server auf Patch Stand Juli gebracht. Geht trotzdem nicht. Somit ist das Problem auf MS Seite zu suchen.
Damit ihr prüfen könnt, ob die Dateien ggf. schon auf dem WSUS heruntergeladen wurden:
WSUS Konsole- > Updates -> Sicherheitsupdates anklicken.
Dann in der Statusleiste einen Rechtsklick "Dateistatus" anklicken.
jetzt sollte ein neues Symbol links von Titel erscheinen.
Wenn das grün ist (Mouseover Meldung "Installationsbereit") sollte das Update heruntergeladen sein
Grau (Mouseover Meldung ".Installationsbereit. Nicht heruntergeladenene Dateien") bedeutet das der WSUS das Update nicht hat.
Ggf, die Genehmigung prüfen (Bei Auto Genehmigung "Genehmigt" und der Status auf "Erforderlich"). Dann ist die Liste der Updates kürzer.
Habe ich das richtig verstanden? Solange das aktuelle 07/2025 Update nicht auf den Domaincontrollern installiert wird, funktioniert das Microsoft RPC-Netlogon Protokoll weiterhin uneingeschränkt in der Domäne?
EDIT: Bolko hat die Antwort auf meine Frage:
https://www.borncity.com/blog/2025/07/09/wsus-hat-synchronisationsprobleme-9-juli-2025/#comment-222602
Ja. Aktualisiere deine Linux-Büchsen, und alles wird gut. Betrifft übrigens , soweit ich das verstehe , nur Linux-Büchsen, die per Samba in die Domäne aufgenommen wurden. Welcher Linuxer macht das schon?
Wir haben keine Linux-Büchsen mit Samba. Wenn es nur Linux-Büchsen mit Samba betrifft, würde das heissen, Microsoft betreibt die Update-Server-Infrastruktur mit Linux? Vertrauen also ihren eigenen Server-Produkten nicht mehr?
Es gibt auch Systeme, bei denen ein Linux "unter der Haube" werkelt, beispielsweise NAS-Systeme von Synology oder QNAP.
Auch ein VMware Vcenter ist Linux-basiert, ebenso viel Firewalls, z.B. Sophos oder Fortigate.
WSUS-Syncronisation mit Microsoft läuft über das HTTP bzw. HTTPS-Protokoll. Hat nichts mit Samba/RPC/… zu tun.
Einmal mit Profis…
Hier vermischen sich gerade zwei Probleme.
Das WSUS-Update hat mit Microsofts Infrastruktur zu tun und kann nur dort behoben werden (*ttps://sws.update.microsoft.com ist auch hier im Moment nicht erreichbar). Undramatisch, da ich die Updates gestern synchronisiert habe und notfalls den Katalog und manuellen Import verwenden könnte.
Das SMB-Problem (inklusive dem Statement vom Samba-Team) finde ich dramatischer, da hier viele Systeme (NAS, Drucker, Firewall, KVM, Appliances wie Vcenter…) laufen, die in irgendeiner Form linux-basiert sind und auch AD-Zugriff brauchen.
Ich habe mich in meiner Testumgebung jetzt darauf fokussiert und bisher keine Inkompatibilität gefunden. Ich bin aber damit noch längst nicht durch.
Hast du AD-integrierte Drucker? Also welche die in der Active Directory Computers und Users Console in einer Org-Unit als Computerkonto gelistet sind?
NAS ist möglich, aber Drucker?
Es geht hier um Systeme, die per Samba 4 einen Domain-join gemacht haben. Wenn die per LDAP/Kerberos/NTLM… und einem dafür erstellten AD-Account einfach nur Nutzer authentifizieren, das sollte weiterhin gehen. So jedenfalls habe ich das verstanden.
Zitat:
This update includes a change to the Microsoft RPC Netlogon protocol, which improves security by tightening access checks for a set of RPC requests. >>>> Samba running as domain members in these environments will be impacted <<<< by this change if a specific configuration is used, see below for which configuration is affected.
https://www.samba.org/samba/history/samba-4.22.3.html
>>> Hast du AD-integrierte Drucker?
Ja, habe ich.
Das mag auf Deiner Blümchenwiese nicht vorkommen, aber hier arbeiten etliche Abteilungsdrucker der Kategorie Xerox DocuCenter.
Das sind Standgeräte, die auf den ersten Blick wie ein klassischer Kopierer aussehen und auch so arbeiten können. Neben Kopieren können sie auch noch drucken, scannen, faxen und alles, was sich mit der Kombination dieser Grundfunktionalitäten abbilden läßt.
Selbstverständlich lassen sich diese Geräte an ein LDAP-ähnliches Verzeichnis, z.B. ein AD anbinden.
Eine häufig genutzte Funktion ist es, ein Dokument einzulegen, zu scannen und per eMail zu versenden. Das zugehörige Adressbuch kommt aus dem AD.
Eine zweite ist es, große Dokumente beim Scan direkt auf ein Verzeichnis auf dem Server abzulegen – im Profil des Nutzers. Auch dazu muß sicher der Drucker an einem Server im AD anmelden können und braucht dazu ein Konto.
Diese Drucker (Geräte im k€-Bereich) waren wegen ihrer schlechten Update-Versorgung gerade neulich erst ein Thema hier im Blog.
Ich weiß nicht wirklich, unter welchem Betriebssystem sie laufen, Windows ist es aber vermutlich nicht. Und die Erfahrung zeigt nun mal, daß die Hersteller nicht-windows-basierter Geräte gerne mal mehr oder weniger große Code-Schnipsel vom Samba-Projekt integrieren.
Ob sie einen der in der Mailingliste genannten RPC-Call verwenden weiß ich nicht, aber es bleibt spannend.
TrueNAS meldet ebenfalls das Problem:
"Windows security update to Active Directory Domain Controllers breaks idmap_ad in winbindd"
[…]
"This affects TrueNAS servers joined to an Active Directory domain and is configured to use unix identity information that is stored in the Active Directory schema using services-for-unix or RFC2307 extensions through the "AD" idmap backend (idmap_ad) in a Windows Active Directory Domain.
This is a non-standard Active Directory configuration and a non-standard TrueNAS configuration that is most commonly used in legacy enterprise environments or universities.
There is no workaround for idmap_ad, we will have to release hotfixes for currently supported enterprise customers."
https://ixsystems.atlassian.net/jira/software/c/projects/NAS/issues/NAS-136590
Das Problem könnte auch an einem fehlerhaften Zertifikat (siehe oben) oder an einem abgestürzten MS-Update-Server (siehe unten) liegen.
Dunkel und mystisch sind die Pfade, auf denen man eines fernen unbestimmten Tages zu einem funktionierenden Microsoft-Universum gelangen könnte.
Die Website wo WSUS runterladen will ist Offline: https://sws.update.microsoft.com/
Das ist der Grund.
siehe: https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/update-management/troubleshoot-wsus-import-sync-issues
Aber warum der Endpoint offline ist, wird nicht genannt – der Support-Beitrag von Microsoft listet auch nichts auf.
Da es nur Deutschland zu betreffen scheint (gibt ja nichts im Netz darüber) könnte der Deutsche Endpunkt/Loadbalancer hinter den Hostname (https://sws.update.microsoft.com/) Down sein.
Der Artikel vorhin zeigt nur auf wie man rausfindet auf welche Adresse der WSUS geht.
Was ich mich auch vorstellen kann ist dass irgendein Zertifikat abgelaufen ist.
Es betrifft derzeit wohl nicht nur Deutschland:
https://downforeveryoneorjustme.com/sws.update.microsoft.com
Nein, laut Reddit sind auch mindestens UK (England) und Italien betroffen.
Consistent-Web1548:
"Same (UK)"
Melo_1983:
"Same from Italy"
flamingo-racer:
"Currently having it in the UK."
old. reddit. com/r/sysadmin/comments/1luf1ql/patch_tuesday_megathread_20250708/
Zumindest auch von Österreich aus – selbiges Problem.
Update: Bei uns läufts grade wieder einwandfrei. Der Frühstückskaffee in Seattle dürfte fertig getrunken sein.
ist doch alt der Artikel
Um 2:59 gab es bei uns noch den folgenden Fehler (etwas gekürzt):
InvalidOperationException: Fehler im XML-Dokument (1,16061). —> System.Net.WebException: Timeout für den Vorgang wurde überschritten.
[…]
Danach dann nur noch und immer wieder einen HTTP-Fehler (auch gekürzt):
WebException: Timeout für Vorgang überschritten
bei System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) […]
Vielleicht wurde da bewusst der Stecker gezogen.
Aus dem Log im Artikel:
"System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)"
—
Sollte das nicht eigentlich httpsWebRequest heißen (mit S)?
Fällt ein WSUS auf unverschlüsselte Verbindung zurück, wenn der HTTPS-Verbindungsversuch zum Microsoft-Update-Server scheitert?
Kann es da ein Problem geben in Verbindung mit "allowRedirect" weiter unten im Log?
Auf welche Adresse wird denn dann die neue unverschlüsselte Verbindung umgeleitet?
Kann sich da zB ein Fake-Update-Server reinhängen?
WSUS benutzt HTTP (nicht HTTPS) für die Updateinhaltsdateien.
Diese sind signiert und der Hash befindetz sich in den Meta-Infos.
Die HTTP-Abfrage ist also normal.
HTTPS (TSL/SSL) wird zum Authentifizieren benutzt:
"WSUS verwendet TLS/SSL zum Authentifizieren von Clientcomputern und WSUS-Downstreamservern beim WSUS-Upstreamserver."
learn. microsoft. com/de-de/intune/configmgr/sum/get-started/software-update-point-ssl
Diese Inhalte der verfügbaren Updates sollten dann aber auch im WSUS angezeigt werden.
https://www.ssllabs.com/ssltest/analyze.html?d=sws.update.microsoft.com
2603:1020:2:3:0:0:0:4e3 = Unable to connect to the server
20.114.59.46 = Unable to connect to the server
Was willst du uns damit sagen?
Dass MS ssllabs auf eine Blocklist gesetzt hat?
Machen viele Klitschen, die lieber Obscurity statt Security betreiben.
https://downforeveryoneorjustme.com/sws.update.microsoft.com
Wie wäre es statt irgendwelche unbekannte 3rd Party Tools einzusetzen, einfach die richtigen Tools zu nutzen? Dann käme man der Ursache vielleicht näher?
Starting Nmap 7.93 ( https://nmap.org ) at 2025-07-09 13:14 CEST
Nmap scan report for 20.10.149.151
Host is up (0.10s latency).
Not shown: 999 filtered tcp ports (no-response)
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 17.89 seconds
ja aber nur von dir aus. so what
– Es liegt also nicht an einem abgestürzten Load-Balancer der Microsoft-Update-Server, denn der LB antwortet auf nmap Anfrage.
– Es liegt nicht an abgestürzten Update-Servern, denn freigegebene Updates können von dort runtergeladen werden (siehe Meldung weiter unten).
– Es liegt nicht an SMB/Samba oder RPC/NetLogon, denn WSUS benutzt das nicht.
– Es liegt nicht am unterschiedlichen Patchstand zwischen WSUS und Microsoft-Update-Servern.
– Es ist nicht auf Deutschland beschränkt.
Weiterhin ungeklärt ist die Zertifikat-Fehlermeldung.
nmap ist auch ein 3rd-Party-Tool. Wie wärs denn mit
tnc -p 443 sws.update.microsoft.com
Das ist ein Powershell-Befehl.
"Attempting TCP Connect"
"Waiting for response."
Die Abfragen dauern lange und manchmal funktionieren sie, manchmal aber auch nicht.
Warning: TCP connect to (4.245.162.142 : 443 ) failed
Warning: TCP connect to (2603:1030:408:7::3f : 443 ) failed
nächster Versuch klappt dann:
TcpTestSucceeded: true
(bei Adresse 4.245.162.142 : 443, die kurz vorher noch nicht erreichbar war).
https://onlineornot.com/website-down-checker?&url=https://sws.update.microsoft.com
Die Abfrage mit tnc dauert manchmal mehr als 20 Sekunden und manchmal erhält man das Ergebnis sofort.
Mal mit Fehlermeldung (failed) und mal ohne (True).
Das scheint wohl der Grund zu sein, die Verbindung zum Zielserver ist nicht stabil. Vielleicht überlastet? Vielleicht ein Teil der Infrastruktur in Texas abgesoffen?
Es geht auch um die Sichtweise von anderen draussen, nicht um nur subjektive Eindrücke…
Test-NetConnection sws.update.microsoft.com -Port 443
Da bekomme ich die Rückmeldung: TcpTestSucceeded : True
WSUS auf Windows Server 2022 Standard, hat ab 1900 Uhr (08.07.) alle Updates ohne Probleme abgeholt.
Der letzte Sync war um 23:11 ohne Probleme, danach war der WSUS Server routinemäßig offline.
Ein manueller Sync heute (09.07.) ab 12:00 Uhr: Sync funktioniert nicht mehr:
2025-07-09 10:29:53.350 UTC Warning WsusService.29 WebServiceCommunicationHelper.ProcessWebServiceProxyException ProcessWebServiceProxyException found Exception was WebException. Action: Retry. Exception Details: System.Net.WebException: Timeout für Vorgang überschritten
bei System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
bei Microsoft.UpdateServices.ServerSync.ServerSyncCompressionProxy.GetWebResponse(WebRequest webRequest)
bei System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
bei Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetRevisionIdList(Cookie cookie, ServerSyncFilter filter)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetRevisionIdList(ServerSyncFilter filter, Boolean isConfigData)
Unser WSUS läuft als eigener separater Server auf WS2019. Kein LINUX, kein Domänecontroller. Der Windows-Server mit WSUS hat seit drei Wochen keine relevanten Updates installiert. Also das kann aus lokaler Sicht nicht die Ursache sein.
Zertifikatsprobleme klingen nicht unplausibel…
MS forciert das AUS für den WSUS aber ziemlich hartnäckig finde ich….
Bei uns funktioniert alles einwandfrei. Sync und Downlaod.
Server 2019, Patchstand Mai 2025
Bei uns hat der WSUS die gleichen Symptome. Und auch die FIPFS-Updates auf dem Exchange machen schlapp:
MS Filtering Engine Update process was unsuccessful to download the engine update for UM from Primary Update Path.
Update Path:http://amupdatedl.microsoft.com/server/amupdate
UpdateVersion:
Reason:"There was an error while downloading the universal manifest. Error:Unable to load universal manifest from: http://amupdatedl.microsoft.com/server/amupdate/metadata/UniversalManifest.cab : HTTP-Status 404: Die angeforderte URL ist auf diesem Server nicht vorhanden.
(Universal Manifest)"
Scheint was größeres zu sein …
Bei uns Synchronisierung seit 5:20 und dann noch 3x danach nicht erfolgreich, zuletzt gestern um 5:20.
Kann es sein, dass aktuell einfach die Server von MS nicht erreichbar sind? Etwas schräg, weil eigentlich vermute ich doch mehrere, aber wenn das Problem beispielsweise ein Loadbalancer wäre…
…hier um 3:10 Uhr hat Synchronisation gestartet und auch erste Elemente erhalten. Dann aber zwischen 3:29 und 5:25 Uhr scheint der Abbruch gekommen zu sein. Hat man nicht die Logdateien bzw. die Synchronisation begutachtet, dann scheint alles normal zu sein, da Updates eigentlich da sind und auch heruntergeladen werden können – sprich Freigabe an (Test) Clients klappt.
Erneute Synchronisation kommt wieder zum Timeout….
Die vielen Postings hier zeigen eindeutig, dass die Ursache auf Seiten von M$ liegen muss… Abwarten und Tee trinken oder auch ein Weizen ;)
VG HV
finde nur ich keine Nachrichten oder Reddit-Posts dazu, außer hier bei Günther?
Es gibt imho noch nichts, was in Suchmaschinen auftaucht (jedenfalls beim letzten Check) – wenn ich sehe, wie fix mein Beitrag (auch in englisch) in Suchmaschinen hochgespült wird, scheinen meine Blogs bisher die einzige Quelle zu sein. Aber zu den englischen Patchday-Artikeln hat sich ein Betroffener gemeldet (laut IP aus Bulgarien), der ebenfalls WSUS Sync Probleme berichtete.
https://www.reddit.com/r/sysadmin/comments/1luf1ql/patch_tuesday_megathread_20250708/
Auch hier bei reddit Meldungen darüber
musst du weiter runterscrollen:
chicaneuk Sysadmin:
"Anyone having issues with WSUS syncing with Microsoft? I have a couple of servers which have all tried a number of times since 5am and all failing despite being able to successfully test connectivity to the numerous Windows Update destinations successfully."
old. reddit. com/r/sysadmin/comments/1luf1ql/patch_tuesday_megathread_20250708/
Darunter dann zahlreiche Bestätigungen, auch aus England, Italien etc.
Das ist mal eine gute Einstellung! Prost!
Gleiche Probematik hier. Habe dann versucht, das kumulative Windows 10 Update per Powershell Script in den WSUS zu importieren. Ohne Erfolg, klappt das bei Euch?
Hier die Fehlermeldung:
PS C:\wsus> .\ImportUpdateToWSUS.ps1 -UpdateId 54b4612e-e64d-46ad-ba37-5d74f189b4
Attempting WSUS Connection using Get-WsusServer… Connection Successful
Attempting WSUS update import for Update ID: 54b4612e-e64d-46ad-ba37-5d74f189b4… C:\wsus\ImportUpdateToWSUS.ps1 : Failed. Exception calling "ImportUpdateFromCatalogSite" with "2" argument(s):
"updateIdStr"
At line:1 char:2
+ .\ImportUpdateToWSUS.ps1 -UpdateId 54b4612e-e64d-46ad-ba37-5d74f189b …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,ImportUpdateToWSUS.ps1
Per PowerShell konnte ich gerade das 2025-07 für Win11 24H2 x64 erfolgreich in den WSUS importieren und es wurde nach Genehmigung auch heruntergeladen. WSUS-Sync geht aber immer noch nicht.
Danke für die Antwort. Geht hier weiterhin nicht auf einem 2022 Server.
Nutzt Du das Script, dass über den Aufruf von „Import Updates…" in der WSUS Console angezeigt wird (Im Browser)?
Hier:
Freigegebene Updates vor Update werden vom WSUS heruntergeladen.
Dann Server mit WSUS gepatcht.
Dann manuell Sync im WSUS angestoßen und es kommt:
"WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. —> System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat 20.10.149.151:443"
Dann ein Update im WSUS freigegeben und der WSUS lädt es normal herunter.
Es scheint also tatsächlich nur der Sync gestört zu sein.
Hier genau dasselbe: Nachdem der Sync heute Nacht (1.00 Uhr) noch funktionierte, tut er jetzt (11.15Uhr) nicht mehr. Die neuen Patches werden nach Genehmigung jedoch anstandslos heruntergeladen.
Ich patche jetzt mal den WSUS selbst und schau, was dann los ist…
Hab ich schon gemacht auf einem 2022er, ändert nichts daran – kein erfolgreicher Sync…
wir haben auch das Problem mit unserem WSUS, seit heute morgen 04:24 Uhr ist der Sync fehlerhaft. Manuelle Syncs auch fehlerhaft.
Die ungepatchten Clients können sich hier problemlos die Patches vom gepatchten WSUS herunterladen.
Update über die normale Online-Updatefunktion funktioniert auch.
Tatsächlich ist also nur der Sync des WSUS zu Microsoft gestört.
*https://onlineornot.com/website-down-checker?requestId=7iB2pEjjMf5CawoSmwsa1&url=https://sws.update.microsoft.com
Obwohl WSUS-Sync wieder funktioniert, sind auf dieser Online-Checker-Webseite trotzdem noch alle 5 Gebiete auf Rot.
Die Anfragen von onlineOrNot und sslLabs stehen also vermutlich auf einer Blocklist von Microsoft und lassen keine Rückschlüsse auf den tatsächlichen Status zu.
Hier wurden heute morgen gegen 4 Uhr bei einem von drei WSUS-Servern beim Sync 2.800 "neue" Updates gefunden (bei normalerweise ~4.500 Updates gesamt im WSUS).
Wie es scheint, wurde so ziemlich alle kumulative Updates für Windows 10, Windows 11, dotNET seit 2019 nochmal neu importiert, ohne dass an den Einstellungen (Kategorien, Upstream-Server o.ä.) etwas geändert wurde.
Kann das Problem jemand bestätigen?
Nicht konkret dieses aktuelle Problem.
Aber hier ist es über die Jahre schon mehrfach vorgekommen, dass alle Update-Pakete neu von Microsoft zum lokalen WSUS heruntergeladen wurden. Auslöser war ein Fehler während des Sync, einhergehend mit einem lokalen WSUS Datenbank-Fehler.
Im Normalfall macht WSUS einen inkrementellen Sync zum letzten lokalen Stand. Ist der nicht ermittelbar oder wurden Einstellungen (Sprachen, Produkte, Klassifizierungen…) geändert, ist eine erneute Vollsynchronisation erforderlich, die auch alte Updates wieder nach oben spülen kann. Das gilt insbesondere, wenn man 3rd-party-Tools (wie AdamJ's Clean-WSUS) zum Bereinigen der Datenbank einsetzt.
"AdamJ's Clean-WSUS" kannte ich noch nicht, aber:
"Please be advised that the use of the early versions of our software known as Adamj Clean-WSUS is now strictly prohibited. This obsolete software is no longer available and should be deleted from your server."
Das liegt daran, weil der Ersteller des damaligen Clean Scripts irgendwann die Lizenz geändert hat unter der das Script veröffentlicht wurde und nunmehr möchte, dass die Nutzer des Scriptes dafür Geld bezahlen.
Das ist dahingehend mMn schwierig, weil die ursprünglich veröffentlichten Versionen vor der Lizenzänderung frei zugänglich für jedermann im Netz und quasi unter jedem gemeldeten WSUS Thema im MS Forum und auch bei Spiceworks und Co. drunter gepostet wurde vom Ersteller des Scripts. Bis eben die Reichweite dessen so groß war, dass er ne eigene Firma gründete und das ganze selbst vermarktet hat(te) -> und dann alle möglichen Mittel und Wege genutzt hat um aus allen Stellen des Netzes (inkl. Archivseiten usw. usf.) das Script rauszulösen bzw. löschen zu lassen. Jegliche Forks der damals veröffentlichen Versionen und alle öffentlichen Foren werden dort systematisch durchforstet und taucht irgendwo das Script (wieder) auf, wird es mit Verweis auf Lizenzverstöße gelöscht.
Das Problem dabei ist eben, dass man rückwirkend auch die bis Version v3.1 bzw. ich meine auch v3.2 real praktisch nicht eingeschränkten Vertriebswege und Mittel eben jetzt im Nachgang mit einer Lizenzänderung versucht weg zu regulieren. Das ist arg hässlich.
Nichts desto trotz – wer es hat und sich auf Basis der damals veröffentlichten Versionen das Script selbst verändert, kann und darf das mMn im Rahmen der seinerzeit mal zugesicherten Nutzungsrechte weiter nutzen. Ansich funktioniert der Kram auch weiterhin noch und es tut auch mit nem 2025er WSUS nach wie vor seinen Dienst.
Haben einen Case bei Microsoft offen und der Fehler wurde bestätigt.
Microsoft arbeitet an der Lösung.
Danke für die Info!
Danke!
Vielen Dank für die Info!! 👍
Vielen Dank für die Info!
Hier der gleiche Fehler seit spätestens 04:17 Uhr kein Sync möglich. Die letzten Updates hat er aber noch Synchronisiert und lassen sich herunterladen.
Ja seit ca. 9:45 Uhr Ortszeit hier auch.
Das gabs schon paar Tage vorher mit Laden der Defender Signaturen, dann wars wieder weg. Aber seit heute Vormittag geht aktuell nichts mehr.
Bei uns kann der WSUS Server seit ca. 14 Uhr wieder Updates laden.
Dann ist das reine Glückssache. Unter der betroffnen URL sws.update.microsoft.com verbergen sich ganze Reihen an IPs und einzelnen Servern. Klar, manchmal hat man Glück, aber das Problem ist dadurch nicht für alle behoben. Vermutlich wirst du schon beim nächsten Versuch wieder bei 0% hängen bleiben.
Updates laden, also die Files selbst und den Catalog syncen sind zwei verschiedene Sachen.
Ich bin mir nicht sicher, was du mir damit sagen möchtest.
Unser Proxyserver zeigt mir, dass die Verbindungsversuch unseres WSUS Servers mit den MS Servern seit 05:00 Uhr heute morgen fast nur von HTTP 503 gekrönt waren. Seit 14:00 Uhr sehe ich in den Proxy-Logs das der Server wieder wie gewohnt mit den MS Servern kommuniziert. Er lädt seit über zwei Stunden von "download.windowsupdate.com" und "dl.delivery.mp.microsoft.com" Dateien herunter. Ich berichte wenn der Vorgang beendet ist.
Hallo,
das Laden der Updateliste incl. Metadaten und das Laden der eigentlichen Installationsdateien erfolgt von unterschiedlichen URLs. Es scheint das nur die URL für die Updateliste (wo der Sync hin will) kaputt ist, die URL wo es die Updatedateien gibt scheint zu funktionieren.
Wenn der WSUS vor der Grätsche noch synchronisieren konnte, dann kann er noch die Dateien laden, kam der Sync zu spät, geht mangels Liste gar nichts (außer händischer Import aus dem Update Catalog).
Grüße
Auf meiner Firewall kann ich sehen das immer 17 bis hin zu 50MB heruntergeladen werden, dann passiert auf der Session bis zum Abbruch nichts mehr. Bekommt da das europäische CDN die Daten aus USA nicht rüber?
Unser lokales Office Click2Run Repository bekomme ich problemlos aktualisiert, zumindest auch das scheint noch zu laufen. Eine Patchscan.cab kann ich auch noch runterladen, scheint echt nur der Dienst gestört zu sein der den WSUS sagt was es neues gibt.
….und dann kommt heute vom Cert folgende Warnung, dass dringend alle Windows Systeme aktualisiert werden sollen:
Beschreibung
****************************************************************************
Microsoft hat eine kritische Sicherheitslücke im Windows SPNEGO
Extended Negotiation (NEGOEX) Security Mechanism veröffentlicht. Die
Schwachstelle ermöglicht es Angreifern, aus der Ferne und ohne
Authentifizierung beliebigen Code auf betroffenen Systemen auszuführen.
CVE-Nummer: CVE-2025-47981
CVSS Base Score: 9.8 (Kritisch
****************************************************************************
Läuft beim Bauchladen aus Redmond ;-)
Ja, so hat jeder sein Päckchen zu tragen, alleine heute 25 CVEs im Linux-Kernel. Kannst ja mal in die EUVD reinschauen, was da vor 4 Stunden alles so gelistet wurde.
Das kann man per GPO abmildern bzw. verhindern unter:
Computerkonfiguration\
Windows-Einstellungen\
Sicherheitseinstellungen\
Lokale Richtlinien\
Sicherheitsoptionen\
Netwerksicherheit: Lässt … PKU2U … zu …
Diese Richtlinie auf Deaktivieren einstellen.
Das soll angeblich das Problem lösen.
Eigenerfahrung oder "KI" Antwort?
Hatte ich vorhin vergessen:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47981
Sollte das von der Microsoft-KI kommen und falsch sein, keine Haftung meinerseits.
Wozu noch per GPO, das Update ist ja da?
Wegen NAS mit Samba als AD-Member z.B.? So kann man sich etwas Zeit kaufen und testen, bevor man die geballten Juli-Updates auf die Domäne loslässt und evtl. Clients den Zugriff auf Fileserver verlieren.
Wir haben derzeit einen Fall bei Microsoft dazu offen. Der Bug ist bestätigt und die Produktgruppe arbeitet mit hoher Priorität daran.
So wie ich das über den Tag beobachten konnte, scheint das wohl tatsächlich ein gestuftes Problem sein, dass mehr oder weniger jeden erwischen kann, aber nicht muss.
Ich habe hier Einblick in mehrere Umgebungen.
Zum Teil trat der bekannte Fehler gestern ab 16 Uhr auf einigen Systemen auf, zur Nacht beruhigte es sich bei ein paar Servern, und es funktionierte dort wieder, während es bei anderen beim Fehler blieb. Bei einigen funktioniert es aktuell wieder. Allerdings warte ich auf morgen, bevor ich Updates einplane. Bei einem System, wo ein Kollege Einblick hatte, funktionierte die Synchronisation, bis auf wenigen Ausnahmen durchgehend, aber die Updates selber können bis jetzt nicht erfolgreich heruntergeladen werden, im Test-Ring verteilt werden.
Das spricht für mich, dass je nachdem welche Version WSUS-Server, aber auch Microsoft-Server hat, die Synchronisierung funktionieren kann, oder fehlschlägt.
Unabhängig davon verhält es sich auch mit den Update-Paketen an sich.
Ich hoffe, dass MS das bis morgen hinbekommt, damit man vernünftig an die Updates kommt und das Patchen planen kann.
Gerade versucht die restlichen Updates zu ziehen. Komischerweise gingen die Win11 Updates recht schnell. Die Server 2016 Updates haben bei gerade einmal 1,7GB fast eine Stunde zum runterladen gebraucht. Der tägliche Sync hängt immer noch bei 0%
WSUS ist gepatcht und in den Synchronisierungen sehe ich plötzlich ein paar Updates, die wohl irgendwo in der Pipeline stecken geblieben waren. Also gleich nochmal manuell synchronisiert und jetzt hängt der Fortschritt bei 10% anstatt 0% :D
Hatte jetzt 21:57 bei einem Kunden der seit gestern einen Internetausfall hatte, gerade noch einmal manuell sync. und es verlief erfolgreich – WOW!
Warte einmal ab ob es meinen restlichen Kunden auch wieder funktioniert…
Ja, läuft hier gerade auch. 21:13 Uhr war eine manuell gestartete Synchronisation erfolgreich. Eine gute halbe Stunde später dann auch eine per Zeitplan gestartete Synchronisation.
An zwei Standorten war die Synchronisation nun wieder erfolgreich.
Sieht wieder gut aus, wir syncen stündlich und:
Seit heute 10.07.2025 0:10 ist der Sync wieder ohne Ausfall OK (also schon 7x)
(begonnen hatte der Ausfall am 9.7.2025 02:10 und war danach bei jedem stündlich Snyc fehlgeschlagen)
Unsere Server synchronisieren wieder.
Bei uns auch 👍
Ja, das Problem scheint behoben, bei uns gehts seit 01:00 Uhr wieder ….
Updates Juli 2025 sind per WSUS angekommen und seit gestern in Produktionseinsatz. Keine Probleme. WSUS ist (noch) ein Server 2016.
Bei uns läuft der Sync auch wieder seit gestern Abend 21:15
Bei mir auch heute morgen um 3 Uhr.
6x EDGE Updates Stable 138.x, Dev 140.x
Mal sehen wie lange
Yes, syncs are now working. A Windows Release Health email stated:
"Resolution: The issue has been addressed through a service-side repair activity and should be resolved. WSUS sync and update activities are expected to proceed as usual at this time."
das sync mit den Windows Servern funktioniert wieder seit dem Morgen, dafür funktioniert jetzt der Statusreport der Clients zum WSUS nicht mehr. Super.
Ich hatte das Problem, das WSUS tausende alte Updates neu synchronisiert hat.
Dabei ist die WSUS-Partition ist vollgelaufen.
Hat gedauert, alles aufzuräumen.
Dasselbe Problem hatte ich auch auf mehreren Servern. Teilweise wurden tausende alte Updates als neu erkannt. Auf anderen Servern wiederum nicht.
Hattet ihr irgend eine schnelle Lösung hierfür?