Windows: SMB per VPN seit Nov./Dez. 2020 langsam

Ein Blog-Leser hat mich kürzlich darauf aufmerksam gemacht, dass in seiner Umgebung ein Zugriff auf Freigaben per SMB-Protokoll über VPN-Verbindungen in Windows 10 seit ca. November oder Dezember 2020 extrem langsam geworden ist. Es deutet sich ein Bug in Windows 10 an. Hier einige Informationen zum Thema.


Anzeige

Ende Februar 2021 meldete sich ein Blog-Leser per E-Mail bei mir, weil er auf ein Problem gestoßen war und hoffte, dass ich etwas darüber weiß.

Problem: SMB-Zugriffe per VPN langsam

In der Unternehmensumgebung des Blog-Lesers werden VPN-Verbindungen zur Kommunikation mit anderen Rechnern eingesetzt. Dabei soll auch über das SMB-Protokoll auf andere Rechner zugegriffen werden. Aber es gibt dort Geschwindigkeitsprobleme, die irgendwann von den letzten Updates im Dezember oder sogar schon im November 2020  verursacht werden. Hier die erste Nachricht des Blog-Leser mit der Beschreibung des Problems.

Seit November/Dezember 2020 stellen wir (und auch eine andere Firma die ich kenne) fest, das SMB über VPN teilweise extrem langsam ist. Ein Arbeiten mit dem Explorer ist dann fast nicht mehr möglich. Das Browsen von Daten ist eine richtig Qual.

Das Problem tritt seit November/Dezember in unterschiedlichster Konstellation und leider auch unterschiedlichster Unregelmäßigkeit als Phänomen auf. Beide Firmen verwenden unterschiedliche VPN Lösungen, unterschiedliche Virenscanner etc. Die einzige Gemeinsamkeit ist ein aktuell gepatchtes Windows. Wir selbst konnten die Probleme in 1909 und 2004 beobachten.

Auf 20H2 haben wir bisher noch nicht upgedatet. Auch Zugriffe mittels MMC mit Active Directory Users & Computers sind extremst langsam und das starten der Console dauert 3-10 Minuten.

Wir haben bisher schon diverse Wireshark Logs geprüft und Google durchsucht, konnten bisher aber noch keine Lösung finden. Auch unser externes Consulting Unternehmen wusste bisher keinen Rat. Wir haben auch bereits eine weitere VPN Lösung getest, leider ohne Erfolg. :(

Der Blog-Leser fragte nach, ob mir was schon untergekommen ist – was ich verneint habe. Idee war, dass vielleicht mal im Blog hier einzustellen, in der Hoffnung, dass jemand etwas weiß.

Eine Vermutung: Offlines Files

Nachdem alle kumulativen Updates auf einer Testmaschine schrittweise deinstalliert sind, bis der Update-Stand Oktober 2020 erreicht ist, klappen die Zugriffe auf Freigaben per SMB unter Verwendung einer VPN-Verbindung wieder mit akzeptabler Geschwindigkeit. Daher lässt sich das hier beschriebene HP Sure Sense eher als Ursache ausschließen.

Was ich bisher herausgefunden habe: Das Problem hat wohl mit den kumulativen Updates für Windows 10 vom Oktober 2020 zu tun, wobei die seit 2012 bereits eingeführten Offline-Files und den Offline-Features mit rein spielen. Bisher sind wohl einige Support-Tickets bei Microsoft anhängig.

Gehe ich mit einigen Fragmenten im Web auf die Suche, könnte dieser Microsoft Answers-Forenbeitrag in die richtige Richtung deuten. Ist die Inhaltssuche aktiv, scheint dies die Zugriffe per VPN und SMB auf Freigaben auszubremsen. Möglicherweise hilft auch die hier skizzierte Möglichkeit, die Eigenschaft Large Send Offload V2 (IPv6) im Netzwerkadapter zu deaktivieren.

In diesem Spiceworks-Community-Thread gibt JustTim einige ganz konkrete Hinweise (der Link zu einem Microsoft-Diagnose-Tool ist allerdings gebrochen). Auf Mirazon finden sich noch diese Hinweise, wo man bei einer langsamen SMB-Verbindung über VPN drehen könnte. Weitere Hinweise finden sich in diesem Blog-Beitrag.

Mir wurde dann noch geraten: Administratoren, die in dieses Geschwindigkeitsproblem laufen, sollten mit dem Support von Microsoft Kontakt aufnehmen. Denn der Support würde einen Workaround für dieses Problem kennen, der dann bereitgestellt werde, aber wohl nicht öffentlich verfügbar sei und unter NDA stehe.


Anzeige

Rückmeldung des Lesers: Der Workaround wirke Performance Wunder. Habe der Explorer vorher 20-30 Sekunden zum Browsen eines Verzeichnis gebraucht, sei alles nun wieder angenehm schnell. Auch das Öffnen von Dateien habe sich wieder normalisiert. Falls jemand die Lösung kennt, immer her damit.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Windows 10 abgelegt und mit Problem, Windows 10 verschlagwortet. Setze ein Lesezeichen auf den Permalink.

19 Antworten zu Windows: SMB per VPN seit Nov./Dez. 2020 langsam

  1. welcher workaround sagt:

    welcher workaround wirkt.dennn nun wunder? wird absolut nich klar.

    • Günter Born sagt:

      Ich hätte ja gerne geschrieben: So geht ihr vor und gut ist. Da Microsoft die genaue Ursache und den Workaround unter der Decke hält (Non Disclosure), kann ich dir nichts zu sagen – ich kenne die Lösung nicht (da ich keinem NDA mehr unterliege, wird man mir auch nichts verraten). Idee des Beitrags war: Vielleicht lässt einer der Leser den Tipp raus.

      Mein Rant: Neue Geschäftspolitik Microsofts? Nein, die wollten die Leute schon immer dumm halten (mir ist regelmäßig der Kamm geschwollen, wenn die Microsoftler mir seinerzeit, als MVP, Sachen unter NDA erzählen wollten, die ich 2 oder 3 Wochen vorher schon gebloggt hatte). Leute mit kostenpflichtigem Wartungsvertrag oder Betreuung bekommen dann die Information, wie sie ein vergurktes Produkt irgendwie zum Laufen bringen. Aber "wir" lieben Microsoft und dessen Produkte. Landauf, landab gibt es Tausende Blogger, die jedes neu umgefärbte Icon in irgend einer MS-Anwendung begeistert beschreiben. Geh doch mal durch die Blogs im Ami-Land.

  2. Marco sagt:

    Ich schließe mich mal an. Bei meinem Notebook mit 20H2 dauert das öffnen des Explorers mit aktiver VPN Verbindung auch ein paar Sekunden. Danach gehts eigentlich relativ normal weiter. Ich habe die Thematik bisher auf die große Anzahl an VPN Connections (mehrere Tausend) in meiner Firma geschoben. Ob es vor den oben genannten updates auch schon vorgekommen ist kann ich leider nicht mehr sagen.
    Ich würde mich auch über einen Fix freuen.

  3. steven sagt:

    Hallo,
    ich weiß nicht ob mein Thema zum obigen Problem passt.
    Ich bin Privatanwender benutze aber surfshark als VPN Anbieter, merkwürdigerweise wurde die Verbindung extrem langasam, Original 1000 Mbps mit VPN in der Regel 200Mbps. Vorgestern bemerkte ich jedoch, dass die Verbindung extrem langasm war 10Mpbs. Nach einem Chat mit dem support habe ich das Protokoll auf wireguard umgestellt und siehe da ich habe wieder eine schnelle Verbindung.
    Ich habe win10 pro in der neusten Version inclusive aller updates.
    MFG

  4. 1ST1 sagt:

    Das kann ich nicht bestätigen, hier ist der Datei/Explorer-Zugriff aus dem Homeoffice auf Firmenressourcen für meinen Internetanschluss (100 Mbit) angemessen. Bin selbst öfters überrascht, wie flott da große Dateien rüber kommen. Vielleicht lässt das Problem sich eingrenzen, wenn man mal sammelt, über welche VPN-Lösung die gebremsten Kisten angebunden sind.

    • Anonymous sagt:

      Das Problem ist glaube ich auch nicht der eigentliche Transport sondern die Auflistung des Ordnerinhalts, wenn ich das richtig verstanden habe.

  5. Anonymous sagt:

    Mir ist seit dem Upgrade auf 20H2 aufgefallen, das der Explorer auch lokal teilweise extrem lange braucht einen Ordner aufzulisten wenn Audiodateien darin enthalten sind. Ich habe erst dieses Jahr auf 20H2 aktualisiert. Beim Öffnen eines Ordners wird versucht sofort die Tags auszulesen. Dabei scheint der Explorer zu hängen, das hat mich am Anfang sehr irritiert. Dazu ist mir aufgefallen das der Explorer als auch der Windows Media Player einen Bug beim Auslesen der Tags in Audiodateien haben. Wenn das Albumcover in den Audiodateien zu groß ist, können der Mediaplayer als auch der Explorer damit nicht umgehen. Das erzeugt einerseits eine hohe CPU Last und sorgt andererseits dafür das dann gar keine Tags ausgelesen werden können. Naja besser als Windows 10 1809 oder Windows Server 2019, denn da wurden bei Flacdateien die Tags nach 30 oder 32 Zeichen abgeschnitten ;)

    Ähnliches wie bei den Tags von Audiodateien wird teilweise auch bei anderen Dateitypen gemacht. Wahrscheinlich ist der Workaround eine Änderung der Ansicht auf Liste, anstatt Details damit diese Informationen nicht ausgelesen werden :D

  6. Martin N. sagt:

    Wir hatten ein ähnliches Problem (Explorer zu Hause lokal lahm), solange Netzlaufwerke vorhanden waren und VPN NICHT verbunden war. Sobald VPN aufgebaut wurde, lief der Explorer in richtiger Geschwindigkeit. Bei uns hat der Workaround von https://think.unblog.ch/keine-netzlaufwerke-nach-windows-update geholfen (auch wenn die Symptome andere waren). Vielleicht probiert jemand diesen Fix aus?

    Achtung: Der Registrykey soll für alle genutzten Netzlaufwerksbuchstaben gesetzt werden und muss nach jedem Trennen und Neuverbinden der Laufwerke neu gesetzt werden (daher ist es eher ein "Würgaround"). Das sollte aber mit gängigen Managementtools gut automatisierbar sein.

  7. Tom sagt:

    Hier gibt es mehrere Ansatzpunkte. Welche SMB Version wird in der Umgebung unterstützt? Wie ist das SMB Signing in der Umgebung konfiguriert. Zum unterschiedlichen Signing für Verbindungen hat Microsoft einige Änderungen seit Oktober für Domänencontroller verteilt, ebenso für MS-NRPC.

  8. Michael sagt:

    Ist jetzt eine vage Theorie ohne hier eine Verschwörung anzetteln zu wollen. Aber ich erinnere mich da noch an etwas, dass der Explorer doch überarbeitet wurde als UWP und Bing wohl auch irgendwie integriert ist. Und an einen Bug im explorer wo Microsoft dann etwas an der Bing Search gedreht hatte und plötzlich ging es wieder ohne ein Windows Update (finde leider gerade keine Referenz, aber ich glaube im Blog hier wurde das thematisiert).
    Was ist wenn über das VPN keine Internetverbindung oder bzw. Bing nicht erreicht wird und der explorer deshalb ständig erst in ein Timeout läuft – könnte man also testen ob die Clients über das VPN geroutet ins Internet bzw. zur Bing Search kommen.

  9. Andre sagt:

    Hallo zusammen,

    wir hatten bei einem Kunden der eine VPN LANLAN Kopplung via Lancom nutzt genau die oben beschriebenen Probleme. Umstieg auf SMB-v2 (mussten bis dahin aus Kompatibilitätsgründen SMBv1 verwenden) hat das Problem komplett gelöst.

    Vielleicht hilft es jemanden hier.

    VG

  10. Marc sagt:

    Kann ich ebenfalls bestätigen!

    Erst mit Herstellersoftware der VPN Lösung versucht. Es war extrem langsam. Der Ordneraufbau von circa 20 Elementen liegt bei 45 Sekunden. Der Umstieg auf OpenVPN brachte eine Verbesserung, so dass der gleiche Ordner in 25 Sekunden aufgebaut wird. Im Einsatz ist Windows 10 20H2 mit allen Updates inklusive Qualitätsupdates.

    Auch der reine Dateitransfer über SMB ist grotten langsam (nur circa 10 Mbit/s) obwohl viel mehr möglich wäre.

  11. Bolko sagt:

    Es betrifft nicht nur VPN, sondern das Problem tritt auch bei auf, wenn man sich in Windows 7 anmeldet und dann die eingetragenen Netzwerkfreigaben nicht gefunden werden (weil die betreffenden Rechner aus sind).

    Dann beginnt ca 30 Sekunden nach dem Login ein Freeze für mehrere Minuten.
    Die Maus kann man dann noch bewegen, aber sonst geht nichts mehr.
    Selbst STRG+ALT+DEL geht nicht sofort, sondern ebenfalls nach mehreren Minuten.

    Pro nicht vorhandener Freigabe verlängert sich das Delay um ca 30 Sekunden.

    Entfernt man hingegen diese toten Freigaben mittels Konsolenbefehl "net share /delete Freigabename", dann gibt es diesen ca 4-minütigen Freeze nicht.

    Ich hatte mehrere solcher Jahre alten und längst vergessenen toten Freigaben in der Registry und die haben auch nie Probleme gemacht, aber seit ca letztem November gab es diese Systembremse kurz nach dem Login.
    Also alle Freigaben löschen, die nicht mehr aktiv sind und dann ist die Bremse weg.

    2.
    Der Defender scannt die Dateien im Netzwerk-Ordner bevor diese Dateien dann im Explorer angezeigt werden. Bei Ordnern mit sehr vielen Dateien kann das etwas dauern.

    3.
    Eventuell kann man den Effekt auch mit folgendem Registry-Eintrag beschleunigen.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

    DirectoryCacheLifetime=0

    h**ps://www.wintips.org/fix-slow-access-to-network-shared-folders-in-windows-10-8-1/

    4.
    Veraltete Kernel-Mode-Filter-Treiber können Netzwerk ebenfalls bremsen.
    Dort sind ein paar Programme aufgezählt, die das verursachen und welche Workarounds es gibt.
    Zum Beispiel "opportunistic locking" abschalten.
    h**ps://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/slow-performance-file-server

    5.
    Da stehen noch mehr Workarounds:
    h**ps://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/slow-network-performance-remote-computer

  12. Tom sagt:

    Servus, danke für den Post.

    Microsoft hat uns nun nach einem Case, folgende Reg Werte zur Fehlerbehebung bereitgestellt. Scheint zu funktionieren.

    REG Add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 3854148235 /t REG_DWORD /d 00000000

    REG Add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 3707761802 /t REG_DWORD /d 00000000

  13. Oliver sagt:

    @Tom: Den Workaround mit den beiden Reg-Einträgen habe ich gerade ausprobiert, hat bei mir leider nichts gebracht.

    Wir haben drei Notebooks, die von den Mitarbeitern im Homeoffice eingesetzt werden und die eine Laufwerksfreigabe brauchen. Alle drei sind via Draytek-Routern mit einem IPSEC-VPN mit dem Firmen-Server (Windows 2012R2) verbunden, wo ebenfalls ein Draytek steht. Während auf einem der Notebooks ein Zugriff auf die Freigabe problemlos möglich ist (Verzeichnis wird im Explorer innerhalb einer Sekunde angezeigt), dauert derselbe Vorgang auf den anderen Notebooks schlicht ewig (> 10 Min.). Windows 10 Pro 20H2 mit allen Updates ist in allen Fällen installiert. Bis vor einigen Wochen funktionierte der Zugriff, wie er soll.

    Das Laufwerk verbinden mit net use … geht schnell und problemlos, aber an Zugriffe ist nicht zu denken.

    RemoteDesktop-Nutzung funktioniert problemlos. Bei beiden Notebooks, bei denen es nicht geht, sind Vodafone-Kabel-Anschlüsse im Spiel (die aber auch schnell genug sein sollten), bei dem funktionierenden gibt es einen Glasfaser-Anschluß mit 300MBit/s Down/Up.

    Wenn RemoteDesktop nicht funktionieren würde, würde ich an ein Problem mit den Internetzugängen oder dem VPN denken, aber so?

  14. Tommy sagt:

    Wir haben die gleichen Probleme bei zwei Kunden.
    Interessant ist, das nur die Mitarbeiter betroffen sind die über O2 LTE bzw. über Vodafon Kabel angebunden sind. Wie schon Oliver schreibt funktionieren alle Zugriffe problemlos (Remote Desktop, HTML usw.) nur der SMB Zugriff nicht, wohlgemerkt nur bei den Mitarbeitern mit O2 und Vodafon Kabel! Bei allen anderen Mitarbeiter gibt es keinerlei Probleme. Testweise wurde ein Arbeitsplatz der betroffen war an einen VDSL der Telekom angeschlossen und die Probleme waren behoben.

    Ein weitere interessanter Teil ist, das die betroffenen Mitarbeiter zwar nicht auf SMB Freigaben von Windows Server zugreifen können, wohl aber Problem auf SMB Freigaben einer Synology.

    Als System wird LANCOM Central Site Router eingesetzt in der Zentrale. Die Homeoffice Arbeitsplätzt sind mit Mikrotik Routern ausgestattet. Setzen wird bei den betroffenen Mitarbeitern den Software Client von Shrewsoft ein, bestehen die Problem auch nicht mehr. Der Unterscheid zwischen den beiden Systemen, abgesehen davon das der Mikrotik dauerhalt AN ist: Mikrotik IKEv2, Shrew IKEv1.

    Das Problem ist wirklich etwas verwirrend und mehr immer mehr Infos wird es auch nicht besser. Wir testen nun noch etwas, wenn wir noch etwas herausfinden, dann schreibe ich das hier.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.