[English]Mit den Sicherheitsupdates für Windows 10 und Windows 11, die zum 9. September 2025 freigegeben wurden, hat sich ein Problem beim Zugriff auf SMBv1-Netzwerkfreigaben eingeschlichen. Zum 23. September 2025 hat Microsoft diesen Bug zumindest mit dem Vorschau-Update KB5065790 für Windows 11 23H2 korrigiert.
SMB-Probleme nach Sept. 2025-Update
Zum 9. September 2025 hatte Microsoft kumulative Sicherheitsupdates für die noch im Support befindlichen Versionen von Windows 10 und Windows 11 veröffentlicht. Die Updates beheben einige Bugs und schließen zudem Schwachstellen. Dazu gehören auch die Korrekturen für den UAC-Fehler oder die SMB-Client-Kompatibilität. Die Updates sind im Blog-Beitrag Patchday: Windows 10/11 Updates (9. September 2025) aufgelistet.
Bereits kurz nach Freigabe der September 2025-Updates meldeten sich diverse Blog-Leser und berichteten, dass Netzwerkfreigaben (Shares) nicht mehr erreichbar seien. Die im vorherigen Absatz erwähnten Korrekturen an der Kompatibilität des SMB-Clients führen offensichtlich zu Problemen mit Netzwerkfreigaben. In einem Kommentar kam von Bolko der Hinweis, dass die Probleme an der Korrektur der Schwachstelle CVE-2025-55234 (Windows SMB Elevation of Privilege Vulnerability) liegen.
Microsoft bestätigt das Problem
Microsoft hatte das oben beschriebene Problem dann in einem internen Service-Alert bestätigt (siehe meinen Blog-Beitrag Windows 10/11: September 2025-Updates verursachen SMBv1-Probleme). Susan Bradley hatte den Microsoft Service Alert (Message ID WI1152308) auf patchmanagement.org in diesem Post zitiert.
Unable to connect to shared files/folders on Server Message Block (SMB) v1
"After installing the September 2025 Windows security update [Windows 11 23H2 Update KB5065431] from September 9, 2025 or later updates, you might fail to connect to shared files and folders using the Server Message Block (SMB) v1 protocol on NetBIOS over TCP/IP (NetBT)"
Betroffen sind – meinem Blog-Beitrag Windows 10/11: September 2025-Updates verursachen SMBv1-Probleme zufolge – bei den Clients Windows 10 21H2 – 22H2 sowie Windows 11 22H2 – 24H2. Bei den Servern sind Windows Server 2022 und Windows Server 2025 betroffen.
Microsoft hatte seinerzeit bestätigt, dass man an der Behebung dieses Problems dran sei. Betroffene Kunden müssen in der Zwischenzeit den nachfolgend skizzierten Workaround versuchen.
Workaround: allow traffic on TCP port 445, which will cause the Windows SMB connection to resume successfully by switching to using TCP instead of NetBT.
Microsoft wies darauf hin, dass das SMBv1-Protokoll veraltet ist und in neueren Versionen von Windows-Clients und Windows Server nicht mehr standardmäßig installiert wird. Die neueren Versionen des Protokolls, SMBv2 oder SMBv3, sind von diesem Problem nicht betroffen. Allerdings nutzen noch viele Geräte das veraltete SMBv1-Protokoll.
Windows 11 23H2: Microsoft korrigiert das Problem
Zum 23. September 2025 hat Microsoft das Preview-Update KB5065790 für Windows 11 Version 23H2 veröffentlicht. Eine der dort erwähnten Korrekturen bezieht sich auf den SMBv1-Bug (siehe Windows 11 23H2: Preview Update KB5065790 (23. September 2025)).
Der Fix wird aus im Microsoft Service Alert (Message ID WI1152308) der auf patchmanagement.org in diesem Post zitiert wird, erwähnt. Wann ein Fix für die restlichen betroffenen Windows-Versionen kommt, ist derzeit offen (spätestens im Oktober 2025 Sicherheitsupdate zum 14.10.2025 dürfte der Fix ausgerollt werden).
Ähnliche Artikel:
Microsoft Security Update Summary (9. September 2025)
Patchday: Windows 10/11 Updates (9. September 2025)
Patchday: Windows Server-Updates (9. September 2025)
Patchday: Microsoft Office Updates (9. September 2025)
Windows 11 23H2: Preview Update KB5065790 (23. September 2025)
Windows 10/11: September 2025-Updates verursachen SMBv1-Probleme
MVP: 2013 – 2016
An einem Standort haben wir mind. 3 langlebige Produktionsmaschinen, die als OS Windows 95 drauf haben und weder schnell zu ersetzen sind und auch je einen 7-stelligen Betrag kosten, den man auch in einem Konzern nicht aus dem Ärmel schüttelt, ist SMB1 halt alternativlos.
Für Produktionsmaschinen die nur SMBv1 sprechen haben wir einen "SMB-Proxy" eingerichtet.
Solche Dinge reizen mich dann doch irgendwie auf moderner Hardware zur laufen zu bringen. Gibt einen x86 Emulator – vielleicht eine Lösung
Ich kämpfe seit Tagen bei mehreren Kunden und nun auch intern mit Netzwerkproblemen. Mal wird in der Ereignisanzeige ein sekundenlanger "disconnect" des NICs aufgelistet, mal (auf meinem eigenen Notebook mit USB-C-Dock) die Verbindung ohne Protokolleintrag getrennt und sofort wieder aufgebaut – in der Taskleiste erscheint kurz die Weltkugel statt des Netzwerksymbols. Eine richtige Regelmäßigkeit ist nicht festzustellen, die Häufung in letzter Zeit allerdings bemerkenswert.
Beim ersten Kunden, bei dem es aufgetreten war, haben wir das Update KB5065426 testweise deinstalliert, danach war sofort Ruh.
Jetzt kommt das fette ABER: In keinem dieser Fälle hatten die betroffenen Maschinen irgendwas mit SMBv1 zu tun – das sind allesamt Win11 24H2-PCs in überschaubaren Windows-Domänen mit mindestens Server 2019. Netzwerkkomponenten, die noch SMB1 sprechen sind nicht vorhanden, die Probleme traten direkt auf den Win11-Clients auf.
Ist das jetzt ein fetter Zufall, oder hat jemand Ähnliches beobachtet?
– gleiche SSID bei zwei Computern im selben Netzwerk.
Das entsteht durch Cloning oder Restore des selben Backups auf zwei verschiedenen Computern oder wenn man kein Sysprep benutzt.
Vor dem September-Update wurden identische SSIDs noch toleriert, nachher nicht mehr.
Sysprep oder Neuinstallation oder SidCHG oder NewSID 4.10 hilft dagegen.
– keine Signierung der SMB-Verbindung.
SMB-Signierung ist seit Windows 11 24H2 Pflicht.
also wenn ich das richtig verstehe, dann braucht man keine Hoffnung haben, dass der SSID-"Bug" behoben wird?
Die Auswirkungen halten sich bei uns im Haus zwar in Grenzen aber es is halt mega nervig wenn mans mal braucht :/
Schöne Restwoche
Doppelte SSIDs kann ich in den konkreten Fällen ausschließen, das sind neu aufgesetzte Systeme. Auch die SMB-Signierung passt eigentlich nicht ins Bild, da das Problem vollkommen losgelöst von Netzwerk-Aktivitäten auftritt, z. B. beim reinen Surfen außerhalb des Domänen-Netzwerks. Betroffen sind ausschließlich Win11-Systeme mit 24H2 (Nachtrag: 23H2 auch), Win10 ist unauffällig.
doppelte SID ist ein Mythos, den der Entwickler (Marc Russinovich) von newsid im Jahre 2009 aufgeklärt hat und newsid deswegen beerdigt hat.
https://learn.microsoft.com/en-us/sysinternals/downloads/newsid
https://techcommunity.microsoft.com/blog/sysinternals-blog/filemon-and-regmon-retired-newsid-end-of-life/725877
hast du einen Link, das der Mythos wieder lebt?
siehe die 3 Links in folgendem Kommentar:
https://www.borncity.com/blog/2025/09/16/windows-10-11-september-2025-updates-verursachen-smbv1-probleme/#comment-230393
siehe auch den Kommentar vom Sep 11, 2025, 8:21 PM bezüglich Workaround mittels SIDChg:
learn. microsoft. com/en-us/answers/questions/5545056/(24h2)-build-26100-5074-(kb5064081)-release-previe
Danke.
U N F A S S B A R
ich habe jetzt mal mit NewSID 4.10 das ganze bei meinem Rechner versucht.
Anwendung lässt sich starten und läuft halt dann unendlich weiter… auch kein automatischer Neustart trat ein.
Habe es dann mal risikobereit abgeschossen und neu gestartet … hat aber alles funktioniert inkl. neuer SID und RDP/UNC/Druckerfreigaben funktionieren wieder.
Werde es noch meinen Kollegen testen lassen und dann werden wir mal auf die Leute zugehen die im Haus schon gejammert haben, dass was nicht mehr geht.
Marc Russinovich schrieb doch selber:
"Microsoft does not support images that are prepared using NewSID, we only support images that are prepared using SysPrep."
In der Realität kommt es aber eben doch vor, dass man clont anstatt SysPrep zu benutzen.
Vor den September-Updates hat es trotz doppelter SID funktioniert, nach den September-Updates nicht mehr.
Das konnte Marc Russinovich aber vor mehreren Jahren nicht wissen.
Sysprep ist aufwändiger als clonen und bei SysPrep wird intern ein niedriger Zähler runtergezählt. Sobald dieser Zähler bei Null steht funktioniert ein weiteres Sysprep von dieser neuen Installation nicht mehr, sondern man muss vom Ursprungsimage ausgehen bzw ein neues Ursprungsimage herstellen anstatt einfach die aktuelle Installation für ein neues Image nehmen zu können.
der Zähler für sysprep stand auf 3 und wurde mit Windows 10 auf 1001 gesetzt, da jedes Build Upgrade ihn um -1 reduzieren würde.
Das würde die inplace Upgrade Politik zerlegen
jede Windows 10/11 Version steht auf 1001, siehe slmgr.vbs
In diesem Forum wurde folgende Vermutung zur Ursache geäussert:
„This update seems to change the way auth hashes are mapped, and instead of using hostnames, it is now using the SID."
https://www.elevenforum.com/t/updated-24h2-to-26100-5074-now-cant-connect-to-other-computer.39382/page-2#post-641462
Leser Boris hat hier zuerst auf diesen Beitrag hingewiesen:
https://www.borncity.com/blog/2025/09/10/patchday-windows-10-11-updates-9-september-2025/#comment-229715
Von daher kommt die Theorie, dass die SID (wieder) eindeutig sein muss.
Wir haben 150 VMs, alle mit identischer ID, unterschiedliches OS, je nach Master Image halt identisch SIDs.
Das Master Image wird immer mit sysprep generalisiert. Trotzdem haben wir jetzt das Problem mit den SIDs.
Da gibt es wohl ein Bug im sysprep?
Betrifft auch alle Citrix Server die via MCS erstellt werden.
Wie findet man am einfachsten in einem kleinen lokalen Netzwerk ohne Server aber mit Freigaben untereinander heraus, ob doppelte SSIDs vorliegen, z.B. wenn PCs mit vorinstalliertem Windows gekauft wurden?
doppelte SIDs treten eigentlich nur bei geklonten PCs auf …
10 Rechner OEM vom Systemhaus gekauft haben sehr warscheinlich unterschiedliche SIDs
Remote geht das wie folgt, könnte aber bei betroffenen Systemen daran scheitern, dass der Zugriff eben wegen der doppelten SID nicht funktioniert wenn das September-Patch noch installiert ist.
PsGetsid64.exe \\Computername -u Username -p Password
oder Liste mit Computernamen in eine Datei schreiben:
PsGetsid64.exe @ComputerList.txt -u Username -p Password
PsGetsid64.exe ist in den PSTools von Sysinternals enthalten:
https://learn.microsoft.com/de-de/sysinternals/downloads/pstools
Super, vielen Dank für den Ansatz!
Zitat:
"sekundenlanger "disconnect" des NIC"
—
Sowas kann auch an dem Energiesparplan oder an dem Netzwerktreiber liegen.
Von Realtek gibt es nämlich zwei verschiedene Netzwerktreiber. Der eine unterstützt Powersaving und der andere nicht.
Man muss den Treiber mit Unterstüttzung für Powersaving benutzen.
Von Realtek gab es erst vorige Woche ein Treiberupdate auf Version 10.77.50.807. Vielleicht hilft das bei euch.
Zusätzlich versuchen falls das Netzwerktreiberupdate nicht ausreicht:
Im UEFI kann man die Energiesparmodi C5 und C6 deaktivieren.
Im Energieplan von Windows das Drahtlosnetzwerk und den PCI-Bus vom Energiesparen ausnehmen.
Im Gerätemanager bei dem Netzwerkadapter im Reiter Energieverwaltung den Haken entfernen bei "Windows kann das Gerät ausschalten".
Danke, mit Treibern und Energieeinstellungen experiemtiere ich gerade eh herum, da werde ich mal schauen. Seltsam kam mir halt das geballte Auftreten derartiger Probleme nach dem September-Patchday vor. Und dass die Deinstallation des kumulativen Updates beim Kunden für Ruhe sorgte.
Auf meinem Notebook trat der Fehler heute Vormittag einige dutzend Male auf, seit 11:30 Uhr ist aber plötzlich alles in bester Ordnung. Es ist echt zum Mäuse melken (weil durch dieses Verhalten natürlich auch die Fehlersuche schwierig wird).
Am Ende evtl. doch alles Zufall/Koinzidenz, trotzdem merkwürdig.