[English]Kleiner Hinweis für Administratoren in Firmen, die Windows 11 als Client und Windows Server 2022 einsetzen. Microsoft hat Verbesserungen am SMB-Komprimierungsverhalten und Änderungen an den Einstellungen vorgenommen. Dies geht aus einem Blog-Beitrag von letzter in der Techcommunity hervor.
Anzeige
Preview-Update für Windows 11/Server 2022
Vorige Woche hat Microsoft einige Vorschau-Updates für Windows 11 und Windows Server 2022 freigegeben. So gibt es das Update KB5016691 für Windows 11 (siehe Windows 11: Preview-Update KB5016691 vom 25. August 2022) – und es gibt das Update KB5015879 für Windows Server 202 (siehe Windows Server 2022 Preview Update KB5016693 (16.8.2022). In den Beschreibungen zu beiden Updates wird auch eine Neuerung bei der Server Message Block (SMB) Compression erwähnt, ohne dass dort nähere Details verraten wurden.
Das Server Message Block-Protokoll (SMB-Protokoll) ist ein Client-Server-Kommunikationsprotokoll, das für den gemeinsamen Zugriff auf Dateien, Drucker, serielle Schnittstellen und andere Ressourcen in einem Netzwerk verwendet wird. Es kann auch Transaktionsprotokolle für die Kommunikation zwischen Prozessen.
Neues bei der SMB Compression
Im Blog-Beitrag SMB compression behavior & settings changes geht Ned Pyle von Microsoft in der Techcommunity auf die Neuerungen etwas detaillierter ein.
Der alte Ansatz
Bisher verwendete die SMB-Komprimierung einen Standardalgorithmus, bei dem verschiedene Stragegien versucht wurden.
- Es wurde versucht, die ersten 524.288.000 Bytes (500 MiB) einer Datei während der Übertragung zu komprimieren, Ziel war, dass mindestens 104.857.600 Bytes (100 MiB) innerhalb dieses 500-MiB-Bereichs komprimiert wurden.
- Wenn weniger als 100 MiB komprimiert werden konnten, wurde die SMB-Komprimierung für den Rest der Datei eingestellt.
- Wenn mindestens 100 MiB komprimiert wurden, versuchte die SMB-Komprimierung, den Rest der Datei zu komprimieren.
Das bedeutet, dass sehr große Dateien mit komprimierbaren Daten – z. B. eine mehrere Gigabyte große Festplatte einer virtuellen Maschine – wahrscheinlich komprimiert werden, aber eine relativ kleine Datei – selbst eine sehr komprimierbare – wurde nicht komprimiert.
Neuer Ansatz bei der Komprimierung
Mit der Veröffentlichung des Windows Server 2022-Updates KB5016693 (OS Build 20348.946) und des Windows 11-Updates KB5016691 wurde diese Besonderheit bei der SMB-Komprimierung geändert.
Wird jetzt eine Komprimierung über SMB angefordert, versucht Windows , die Datei zu komprimieren, unabhängig von ihrer Größe oder ihrer scheinbaren Eignung für die Komprimierung. Es spielt keine Rolle, wie die Komprimierung angefordert wurde – Robocopy, Freigabeeinstellung, Registrierungswerte – Windows versucht, die Datei zu komprimieren.
Für bereits komprimierte Formate wie JPG, ZIP, DOCX usw. bringt die SMB-Komprimierung unabhängig von ihrer Größe keine Vorteile. VHDX, ISO, DMP und andere große Dateien mit viel Leerraum werden recht gut komprimiert. Das bedeutet aber, dass bei der Übertragung kleinerer, weniger komprimierbarer Dateien unnötig viel CPU-Zeit für die Komprimierung aufgewendet wird. Administratoren sollten dies im Hinterkopf behalten und sich nicht wundern, wenn das Kopieren vieler solcher Dateien über ein Netzwerk dann länger dauert. Microsoft hat dieses Video veröffentlicht, welches die Änderungen demonstriert.
Weitere Änderungen
Darüber hinaus gibt es jetzt eine Reihe von Gruppenrichtlinien-, PowerShell- und Registrierungsoptionen, mit denen Administratoren das Legacy-Verhalten steuern und die manuelle Bearbeitung der Registrierung zur Konfiguration der Client-Komprimierung vermeiden können. Die Details lassen sich im Blog-Beitrag SMB compression behavior & settings changes nachlesen. (via)
2015
Ich verstehe nicht, warum das nicht mit der Dateisystemkomprimierung in NTFS kombiniert wird. Ja, nutzt kaum jemand auf Servern, aber hier würde es doch extrem Sinn machen, dass die übers Netzwerk komprimierten Dateien schon transparent komprimiert im Dateisystem liegen. Momentan wird jedes Mal "vor" bzw. "hinter" der Netzwerkkarte neu komprimiert, obwohl es im Dateisystem schon komprimiert vorliegt oder in ein komprimiertes Dateisystem reingeschrieben wird. Im Extremfall sind so 4 komprimier/Dekomprimier-Vorgänge, pro Datei nötig, z.B. wenn von einem komprimierten NTFS-Volume auf dem Server eine Datei auf ein komprimiertes NTFS-Volume auf dem Client kopiert wird.
Wäre schon einfacher die bereits für das NTFS komprimierten Daten zu schicken.
Aber wie sollte dann ein Virenscanner die (inzwischen neuen) Signaturen erkennen?
Ich vermute auch, dass die NTFS Kompression anders arbeitet als die für das Netzwerk. Im Netzwerk soll der Transfer schneller gehen, bei NTFS bringt auch die Volumenreduktion einen Vorteil. NTFS könnte z. B. identische Daten de-duplizieren.
Moin
was mir da in den Sinn kommt,
Win 11 kann keinen frei gegebenen Drucker mounten.
In den Unterlagen steht das dies als Hintergrund hat das frei gegebene Drucker über SMB kommunizieren.
Drucker klassisch einzubinden über einen PCL/PS/KPDL Treiber ist kein Problem.
Einen Druckserver der Dienste über LPR anbietet über LPR einzubinden ist auch kein Problem.
Ich muss mal testen ob es nach dem Update jetzt doch klappt mit dem Mounten von Druckern :-)
Ja, es ist kein sauberer Weg gemountete Drucker zu nehmen.
Aber manche Kunden / ITler wollen nicht vom althergebrachten Abweichen und manche Prozesse bauen auf das Mounten auf.
Schönen Tag noch.
Tom
Bitte mal versuchen, ob das zum Wochenende freigegebene Zwischenupdate weiter hilft, da war was mit Druckern.
Danke für den Tipp.
Wenn Ich Zeit habe teste Ich mal :)
Hallo,
Der Satz klingt falsch:
„Wenn weniger als 100 MiB komprimiert werden konnten, wurde die SMB-Komprimierung eingestellt, um den Rest der Datei zu komprimieren."
Sollte eher heißen: „ …., ohne den Rest der Datei zu komprimieren."
Viele Grüße
Matthias
Ich habe es mal umformuliert. Ned Pyle hat eine besondere Art, Sachen zu verklausulieren – hoffe, es ist noch korrekt, was ich dargestellt habe – sonst den englischen Originaltext zu Gemüte führen.
Danke für den Beitrag! Ich habe kürzlich einen Kunden die Fileserver von Server 2016 auf 2022 migriert. Der Kunde hat eine Applikation, welcher er von einem Netzwerklaufwerk startet.
Seit der Migration auf einen neu installierten Server 2022, crasht diese Applikation immer wieder und ich kriege nicht raus wieso. Es gibt einträge im Eventlog, welche auf ein "Netzwerkproblem" hinweisen. Ich habe auch mit procmon64 einen Trace gemacht: Vor dem Crash habe ich tonnen von "NETWORK ERROR" im Log.
Ich habe mal wie im Artikel von Ned beschrieben die Compression via Powershell deaktiviert: Set-SmbServerConfiguration -DisableCompression $true
Hat jemand eine Ahnung woran das sonst noch liegen könnte?