[English]Kleine Info für Benutzer des Windows 10 April Update, die mit Problemen im Netzwerk und möglicherweise bei Multifunktionsgeräten mit Netzwerkscans geschlagen sind. Wie es ausschaut, arbeitet Microsoft daran, im Juni (Patchday wäre der 12. Juni 2018) einen Fix für das 'SMBv1-Problem' bereitzustellen. Nachfolgend habe ich mal einige Informationen zum Thema bereitgestellt.
Anzeige
Hintergrund: Worum geht es genau?
Microsoft hatte bereits seit Sommer 2017 angekündigt, dass SMBv1-Protokoll in Windows 10 auslaufen zu lassen. Das Kürzel SMB steht für Server Message Block (frühere Bezeichnungen sind LAN-Manager- oder NetBIOS-Protokoll), ein Netzwerkprotokoll für Datei-, Druck- und andere Serverdienste in Rechnernetzen. Die Version 1 (SMBv1) des vor über 30 Jahren entworfenen Netzwerkprotokolls und speziell die Microsoft-Implementierung, gilt als sehr fehleranfällig und sicherheitskritisch.
Zwischenzeitlich gibt es SMBv2 und SMBv3, so dass die Verwendung von SMBv1 in Windows-Netzwerken nicht mehr unbedingt erforderlich ist. Windows Vista ist beispielsweise nicht mehr auf SMBv1 angewiesen, da dort SMBv2 verwendet wird. Ich hatte das Thema bereits ausgiebig im Blog-Beitrag Windows 10: Aus für SMBv1 ab Herbst 2017 erläutert.
Und wo ist nun das Problem?
Bei Neuinstallationen von Windows 10 war es spätestens seit Windows 10 V1709 so, dass SMBv1 deaktiviert wurde. Wenn Geräte zwingend SMBv1 benötigten, musste der Administrator halt SMBv1 wieder über Windows Features aktivieren (siehe auch Windows 10: Aus für SMBv1 ab Herbst 2017 ).
Anzeige
Mit Windows 10 V1803 hat das Problem aber wohl eine Menge Leute getroffen, da diese Build auch bei einem Upgrade eine Neuerung bringt. Wird der SMBv1-Client insgesamt 15 Tage lang (mit Ausnahme von Zeiten, zu denen der Computer ausgeschaltet ist) nicht verwendet, deinstalliert Windows 10 April Update den Client automatisch. Ich hatte in den Blog-Beiträgen Windows 10 Version 1803: Netzwerksuche/-umgebung leer und Windows 10: Scanner geht nach Update nicht mehr auf diese Problematik hingewiesen und auch Workarounds skizziert. Aber das hilft bei Windows 10 V1803 nicht bei allen Problemen.
KB4103721, KB4100403, da ist noch was
Im Mai 2018 hat Microsoft ja die Updates KB4103721 (8.5.2018) und KB4100403 (23.5.2018, mit SSD-Fix) für Windows 10 V1803 herausgebracht (siehe die Blog-Beiträge Patchday: Windows 10-Updates 8. Mai 2018 und Windows 10 V1803: Update KB4100403 mit SSD-Fix). Seit dem Upgrade auf Windows 10 V1803 bzw. installation dieser Updates scheint es bei Nutzern von Windows 10 April Update aber Probleme zu geben, wenn das SMBv1-Protokoll verwendet wird. Mir sind Postings in den Microsoft-Answers-Foren aufgefallen, wo mein Hinweis, SMBv1 mal versuchsweise zu aktivieren, leider nicht den gewünschten Erfolg brachte. Konnte ich mir erst nicht erklären. Nun hat Microsoft die beiden oben genannten KB-Artikel (nur in der englischsprachigen Fassung) um folgenden Absatz im 'Known issues'-Abschnitt ergänzt.
Some users running Windows 10 version 1803 may receive an error "An invalid argument was supplied" when accessing files or running programs from a shared folder using the SMBv1 protocol.
In knappen Worten: Auch wer SMBv1 als Protokoll wieder zu Windows 10 Version 1803 hinzufügt, läuft bei bestimmten Programmen, die auf Ordnerfreigaben im Netzwerk zugreifen, auf den Fehler 'Ein ungültiges Argument wurde übergeben'. Das Programm funktioniert nicht mehr – was mein Rätsel in Bezug auf den obigen Hinweis auf Microsoft Answers-Foren löst.
Der Site The Register ist das aufgefallen und sie lassen sich groß über SMBv1 aus. Von Microsoft heißt es in den Nachträgen der KB-Artikel:
Enable SMBv2 or SMBv3 on both the SMB server and the SMB client, as described in KB2696547. Microsoft is working on a resolution that will be available later in June.
Es ist korrekt, dass man in seinen Umgebungen auf SMBv2 oder SMBv3 wechseln sollte (Clients und Server), um das mit SMBv1 einhergehende Sicherheitsproblem endgültig aus der Welt zu schaffen. Aber das ist leider auch das Weltbild der Theoretiker, denn wenn ich einen Client, wie ein NAS-Laufwerk, einen Multifunktionsdrucker etc. habe, der von der Firmware nur SMBv1 unterstützt, ist es mit dem obigen Workaround schlicht Pustekuchen! Dann bleibt nur noch, das Gerät zu ersetzen oder SMBv1 für eine Übergangszeit zu aktivieren.
Der SMBv1-Bug – ein Blick auf die Ursache
Wenn dann in Windows 10 V1803 in der Implementierung von SMBv1 noch ein Bug steckt – so interpretiere ich die Ergänzung der Microsoft KB-Artikel (Microsoft gibt ja in obiger Ergänzung des KB-Artikels keine Details heraus), ist das natürlich bitter. Und die flotte Argumentation diverser Blogs, halt auf das alte SMBv1-Zeugs zu verzichten, geht am Kern vorbei, wenn man SMBv1 noch braucht.
Bei The Register hat man aber einen Hinweis auf eine mögliche Ursache des Problems geliefert. Im MSDN-Forum von Microsoft gibt es den Thread RS4:1803]Windows 10 1803 won't run ODBC SQL connected application from network, der eine intensivere Diskussion enthält. Hier der Ausgangspunkt de Thread-Erstellers.
- Bei einer ODBC-SQL-Verbindung kommt es ab Windows 10 Build 17134.1 (die RTM des April Update) zu einem Zugriffsfehler (z.B. auf Oracle Datenbanken im Netzwerk).
- SMB 1.0/CIFS ist für Freigaben auf Client und Server aktiviert, es müsste also mit den Zugriffen klappen.
Im aktuellen Fall konnte der Betroffene wohl die Probleme durch Aktivierung von SMBv2 lösen. Wer aber auf SMBv1 angewiesen ist (siehe meine obigen Hinweise), kommt nicht weiter. Im Thread hat Nutzer Nicolas Casas dann eine mögliche Erklärung gepostet:
you are pointing something. I have the same issue , that is running an exe from a SMB1 network share
Since windows 10 1803 update the sql server access was filtered that way
but on one PC it was working. this one runs Avast as well.
so I did a fresh installation of 1803, manually enabled SMB1 in windows withdism /online /enable-feature /featurename:SMB1Protocol-Server
and SQL access was not working. I then installed avast latest free version
and it worked! Additionnaly I uninstalled Avast.. and blocked again. so … I look on Defender firewall to add the application in the list, disabled defender but no way to succeed yet
In dünnen Worten: Er hat Windows 10 V1803 frisch installiert und dann Avast als Antivirus-Scanner auf das System geklopft. Plötzlich lief die SQL-Verbindung auf SMBv1-Freigaben. Dann hat er Avast deinstalliert, so dass der Defender wieder zum Tragen kam, und prompt war das Problem wieder da: Der Zugriff ging nicht mehr. Im Thread schreiben andere über ähnliche Beobachtungen mit anderen Drittanbieter-Virenscannern. Es deutet sich an, dass der Windows Defender in Kombination mit der Windows Firewall da ein Problem mit SMBv1-Freigaben verursacht.
Ansätze für Workarounds
Wer auf SMBv1-Freigaben zugreifen muss, kann folgenden Workaround nutzen: Avast Free oder eine Drittanbieter-Firewall installieren, so dass Windows Defender und Windows Firewall abgeschaltet sind, schon klappt es. Einfach irre.
Für eine Windows 10 V1803-Netzwerkumgebung habe ich einen möglichen Workaround ohne Aktivierung des SMBv1-Protokolls im Artikel Windows 10 Version 1803: Netzwerksuche/-umgebung leer skizziert. Das scheint für die meisten Leute zu funktionieren – ich habe es in meiner Umgebung noch nicht nachgestellt (mir fehlen Zeit und genügend Windows 10 V1803-Kisten).
Für Scanner, die über das Netzwerk die Scans in Dateien auf einer Freigabe ablegen, gibt es den Blog-Beitrag Windows 10: Scanner geht nach Update nicht mehr. Falls ein Administrator am Ende des Tages feststellt, dass es an SMBv1 hängt und nach Aktivierung des Protokolls wieder läuft, findet sich sich in diesem Kommentar ein interessanter Vorschlag von Martin Feuerstein. Statt eine Freigabe über das unsichere SMBv1-Protokoll für den Scanner bereitzustellen, kann man einen FTP-Server auf dem Windows Client (oder Server) einrichten. Die meisten Geräte lassen sich so einrichten, dass die Scan-Dateien wahlweise auf einer SMB-Freigabe oder einem FTP-Verzeichnis speichern lassen.
Ansonsten bleibt imho nur abzuwarten, was Microsoft am Dienstag als Update für das Problem bereitstellt oder auch nicht. Oder habe ich noch was (argumentativ) übersehen bzw. nicht bedacht?
Ergänzung: Beachtet auch den nachfolgenden Kommentar mit ergänzenden Hinweisen von Andres Müller zum Thema SMBv1.
Ähnliche Artikel:
SMBv1-Abschaltung bei Windows 10 Enterprise ab 9.6.2017
Windows 10: Aus für SMBv1 ab Herbst 2017
Windows 10: Scanner geht nach Update nicht mehr
Windows 10 Version 1803: Netzwerksuche/-umgebung leer
Windows 10: Netzwerkprobleme durch Updates?
Windows 10: Kein Zugriff auf Freigaben
Windows (Netzwerk-) Fehler 0x800704B3
Windows 10 V1803: Update KB4100403 mit SSD-Fix
Patchday: Windows 10-Updates 8. Mai 2018
Windows 10 V1803: (Boot-)Probleme mit Update KB4103721
Windows Mai 2018-Update blockt CHM-Dateianzeige
Windows 10 V1803: Upgrade bei AVAST-Systemen gestoppt
Anzeige
Ich streame über eine Fritzbox, an der eine Festplatte angeschlossen ist über das SMB-Protokoll. Das funktioniert auch noch mit der neusten Windows 10 Version 1803.
https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/3327_Von-der-FRITZ-Box-unterstuetzte-SMB-Versionen/
Selbst mit einem FTP-Server wie Filezilla FTP-Server können euch ein paar Dinge auf die Füße fallen:
– die Kommunikation zwischen MFP und dem FTP-Server erfolgt standardmäßig unverschlüsselt, das dürfte in Heimumgebungen (LAN) aber kein Problem sein. Anders sieht das aus, wenn euer FTP-Server in der Cloud liegt – hier werden die Daten ggf. unverschlüsselt über das Internet übertragen.
– wählt für den Scan-Benutzer ein Passwort (besser als kein Passwort), gerne mit einem zufälligen Passwort von einem Passwort-Manager wie KeePass (standardmäßig werden dort 20-stellige alphanumerische Kennwörter generiert) oder z. B. https://gaijin.at/olspwgen.php
– falls der Hostname des FTP-Servers als Scanziel konfiguriert wird, stellt sicher, dass der DNS-Server (meist ein Router wie z. B. eine Fritz!Box) den Namen zuverlässig auflöst (auch, wenn sich z. B. die per DHCP bezogene IP-Adresse ändert)
– falls die Namensauflösung über den Router nicht sauber funktioniert, konfiguriert für den lokalen FTP-Server eine statische IP-Adresse (inkl. DNS-Server, Standardgateway usw.)
Bei mir ist es so dass sämtliche Fileserver (Synology und zwei WD Cloud Server) sowohl SMB1 können als auch SMB2 und SMB3 können. Die Geräte sind auch so konfiguriert, ausserdem haben alle auch noch das Unix File System NFS wo man ebenfalls Verzeichnisse/Daten freigeben kann im Netz.
Leider kann ich bei meinem Windows 10 1803 das NFS in Windows Features nicht aktivieren, weil dann alle vorhandenen Server doppelt im Explorer angezeigt werden und die NFS -Verzeichnispfade Umlaute wie äöü nur verstümmelt anzeigen.
Die Netzwerkserver werden auch doppelt angezeigt wenn ich SMB 1 deaktiviere, nur dass dann einer der doppelt aufgeführten Fileserver einen leeren Inhalt hat, der andere ein Verzeichnis mit dem Namen "NFS" worin dann die gesuchten Ordner und Daten zwar vorhanden sind, jedoch eben mit dem Problem mit deutschen Umlauten.
Ein Deaktivieren von SMB 1 auf Windows 10 1803 verursacht bei mir dass die Netzwerkserver zwar noch angezeigt werden, das wenn man sie öffnet jedoch keine Inhalts-Verzeichnisse und Daten darin zu finden sind.
Alle Möglichkeiten habe ich ausprobiert, nur ein aktivierter SMB 1 Client in den Windows Features funktioniert wie erwartet.
Nachtrag: Erstes kommt es anders, zweitens als man denkt.
Heute habe ich mich lange mit diesem SMB 1.0 Thema beschäftigt. Inzwischen wird mir langsam klarer was sich da bei Microsoft im Hintergrund abgespielt haben könnte.
Doch das Wichtigste zuerst.
Vergesst den Ärger um nicht mehr sichtbare Netzwerkgeräte wegen deaktiviertem SMB 1.0 wieder, denn nachdem ihr das Protokoll zuerst deaktiviert und wieder aktiviert habt (wie weiter unten noch im Detail beschrieben werden wird) läuft es danach vielleicht sogar besser und sicherer als vorher.
Grund: Microsoft hat gemäss eines Super Moderator "Barman58" des TenForum, ich zitiere:
"Es gibt eine Änderung mit der SCU unter Windows 10. Das Feature-Set enthält nicht mehr "auto disable SMB1" Schlüssel, der in den Screenshots gezeigt wird, aber nicht im Text erwähnt wird…"
Wie bin ich selbst drauf gekommen? Ich hatte am Freitag einen nagelneuen Lenovo Computer erhalten bei dem ich lediglich sämtliche Windows 10 Updates installiert hatte, worauf sich jetzt ein Windows 1803 darauf befindet. Ich hatte ausser dem automatisch eingerichteten Internetzugriff um Updates zu machen noch keinerlei Netzwerk -Konfiguration gemacht. Daher war ich überrascht als die Kiste mir im Explorer innert sehr kurzer Zeit sämtliche vorhandenen Netzwerkgeräte anzeigte.
Ich hatte eigentlich erwartet das ich zuerst SMB 1.0 aktivieren müsste, so wie ich dies in meinem internen Netzwerk bei anderen Win 10 PC inzwischen machen musste. Alle anderen Vorgehen führten bei mir nicht zum Ziel.
Zu meinem Erstaunen war aber auf dem neuen Lenovo nach dem Download und der Installation der Windows 10 Version 1803 sämtliche SMB Protokolle aktiviert, sogar Client und Server.
Auf Deskmodder behauptete mir jemand dass dies von Lenovo ausgehen würde, bei einer aktuellen Windows 10 Installation nüsste SMB 1.0 bei Neuinstallationen jetzt deaktiviert sein.
Darauf hin durchsuchte ich bei Lenovo die Support Seiten, ein solcher Eingriff entgegen den Ratschlägen von Microsoft das SMB 1 trotz Tojaner Gefahr einzuschalten müsste sich im Support- oder Benutzerforum rumgesprochen haben. Ich fand aber nichts das auf eine solche Aktivität bei Lenovo hingedeutet hätte.
Daraufhin bin ich im TenForum auf unten verlinkte Information gestossen, welche mir klar machte dass der Rummel um ein deaktiviertes SMB 1.0 vermutlich jetzt wieder vorbei ist. Der Artikel widmet sich sehr ausführlich um Deaktivierung und Aktivierung der SMB 1.0 Protokolle:
https://www.tenforums.com/tutorials/107605-enable-disable-smb1-file-sharing-protocol-windows.html#option1
Wenn man auf der Seite ganz nach unten scrollt findet man die erstaunliche Aufklärung von Super Moderator Barman58. SMB 1.0 wird wieder aktiviert!
Und ich habe danach noch weiter im Netz herumgesucht bis ich begriffen habe dass SMB 1.0 nur wegen einer bestimmten Schwachstelle unter Beschuss kam die es einer Ransomware (Verschlüsselungstrojaner) erlaubte über SMB 1 das gesamte Netzwerk zu verseuchen. Aber diese Schwachstelle wurde nun gestopft, woraufhin Microsoft offenbar bei Windows 10 -1803 Neuinstallationen die Protokolle ohne Vorankündigung wieder aktiviert hat.
In den letzten Monaten dauerte es auf verschiedenen PC oft sehr lange bis Windows die Geräte anzeigte (wenn überhaupt). Dabei kam es in den letzten Wochen auch noch zu Fehlern beim Öffnen eines Gerätes, etwa dass kein Inhalt angezeigt wurde oder ein Gerät nicht mehr gefunden wurde.
Auf dem neuen Lenovo läuft die Suche nach Netzwerkgeräten mit Ordnern und Inhalten aber erstaunlich gut. Geräte lassen sich schnell finden, öffnen und durchsuchen –
Erstaunlich -und sogar das SMB 1.0 Server Protokoll ist bei diesem neuen Lenovo per Default aktiviert.
Nun habe ich manuell bei einem anderen PC der zuvor Schwierigkeiten bei der Netzwerk-suche machte gemäss dem im Tenforum beschriebenen Vorgehen mit Hilfe von DISM unter der Shell oder in der Powershell die SMB 1.0 Protokolle zuerst deaktiviert! und danach anch Neustart wieder aktiviert. Resultat bei diesem PC dass die suche nach Netzwerkgeräten viel schneller geht und dass jetzt alle Geräte angezeigt werden. Zuvor wurden nicht immer alle Netzwerkgeräte angezeigt. Ich vermute jetzt mal dass die Schwachstelle auch ohne eingefangenem Tojaner die Ursache für schlechtes Suchverhalten und weiterer Probleme war – was seit Jahren für Kilometer lange Threads zum Beispiel im TenForum verursacht hatte. Ich habe Threads gesehen die Jahre zurück immer wieder daselbe Thema behandelten, dass die Netzwerksuche unter Windows 10 noch katastrophaler war als jemals zuvor.
PS: Ich kann mich noch an Zeiten erinnern wo es mir unbekannt war das Windows mit eingerichtetem Netzwerkzugriff Geräte nicht finden konnte, oder dass Geräte nicht angezeigt wurden oder beim Öffnen eines Gerätes keine Inhalte zu finden waren. Ich glaube das war noch Windows NT 4.0 Workstation, und das war vor etwa 20 Jahren glaube ich.
In 1903 ist es übrigens wieder per default abgestellt, und es hat wieder die Unteroptionen
SMB1.0/CIFS automatisch entfernen
SMB1.0/CIFS-Client
SMB1.0/CIFS-Server
P.S.: Ich hatte das auch unter 95C, 98SE, NT4 und 2000 reichlich häufig, nämlich immer dann wenn die Geräte sich nicht einigen konnten wer denn der Master Browser ist.
Windows 10 und build 2004 will jetzt gar nicht mehr mit SMB1 obwohl die Windows-Features aktiviert sind.
Können sie das bestätigen Herr Born?
Das berichten nicht wenige:
https://answers.microsoft.com/en-us/windows/forum/all/smb-sharing-not-working-after-windows-10-update/298f9988-ddd7-48dd-9924-a21541d98c05
Es scheint keine Ausnahme zu sein, sondern die Regel, dass SMB1 bei V2004 nicht mehr funktioniert.