Inoffizielles deutsches Xbase-Forum

ich meine wenn es an dem SMB1 liegen würde, dann dürfte es entweder gar nicht gegangen sein (weil nicht installiert)
oder der Patch müsste mit genau dem etwas geändert haben, so wie ich JAN verstehe hat er eine Verbindung, nur directory() ist viel langsamer als vorher.
Er hat nicht geschrieben, dass es nichts mehr liefert - oder ich habe es überlesen.

Hallo Jan

hast du auf einem betroffenen Rechner mal versucht in einer CMD Box mit dem Befehl dir ??*.* die Dateien zu suchen? Dauert dies auf den betroffenen Rechnern auch so lange?

Hast du evtl. ein Netzwerkproblem auf den Rechner? Ich hatte schon öfters Perf. Probleme da haben sich bestimme Netzwerkarten und Switch einfach nicht korrekt verhalten. .... Oder ein Kabelproblem ?

Wenn du eine 4-5 GB grosse Datei hin und her kopierst zieht das voll durch?


Gruss Carlo

brandelh hat geschrieben: ↑Do, 14. Jun 2018 19:51 ich meine wenn es an dem SMB1 liegen würde

hast du auch bedacht was noch alles "abgeschaltet" werden kann wenn SMB1 nicht aktive ist
"Das" ist IMHO passiert denn wenn man eine "Clean" Installation fährt ist in der 1803 "mehr" abgeschaltet als in der 1709

nun "sollten" beim Upgrade 1709 -> 1803 die Einstellungen übernommen werden und das hat bei den meisten wohl auch geklappt.
wenn nicht wurden dann die 1803 default Einstellungen genommen die, begründet auf SMB1, Dienste nicht installiert bzw. auf manuell stellt.

wenn der Explorer-Knoten „Netzwerk“ keine Windows-Computer mehr über die Legacymethode zum Durchsuchen von NetBIOS-Datagrammen anzeigen kann, liegt es vermutlich am Computersuchdienst der SMB1 nutzt.

wenn es lange dauert bis es klappt könnte es z.b. sein das der gewünschte Dienst abgestellt ist oder noch nicht läuft.
es kann also eine ganze Zeit dauern bis ein Timeout (kann man in der Regsitry einstellen) einen Dienst mit "manuelle" Einstellung startet.

---

es gibt eine 15 Tage Frist ...
https://support.microsoft.com/en-ca/hel ... in-windows

Windows 10 Home and Windows 10 Professional still contain the SMBv1 client by default after a clean installation.
If the SMBv1 client is not used for 15 days in total (excluding the computer being turned off), it automatically uninstalls itself.
In-place upgrades and Insider flights of Windows 10 Home and Windows 10 Professional do not automatically remove SMB1 initially.
If the SMBv1 client or server is not used for 15 days in total (excluding the time during which the computer is off), they each automatically uninstall themselves.

es ist also eine Zeitbombe die tickt und jeden von uns noch treffen kann ...

brandelh hat geschrieben: ↑Do, 14. Jun 2018 19:51 ich meine wenn es an dem SMB1 liegen würde, dann dürfte es entweder gar nicht gegangen sein (weil nicht installiert)
oder der Patch müsste mit genau dem etwas geändert haben, so wie ich JAN verstehe hat er eine Verbindung, nur directory() ist viel langsamer als vorher.
Er hat nicht geschrieben, dass es nichts mehr liefert - oder ich habe es überlesen.

Hubert,

exakt so. Alles funktioniert wie gewohnt. Nur DIrectory() ist quälend langsam. Nur bei Rechnern mit 1803, aber auch da nicht bei allen - wir haben inzwischen mindestens zwei im Netzwerk, die trotz 1803 sauber arbeiten. Und auch auf meinem Rechner klappt alles ordentlich, solange ich auf die Dateien im Entwicklungssystem zurückgreife. Sobald ich im produktiven System arbeite, ist es ebenfalls langsam. Obwohl beide dahinter liegende Server Windows Server 2016 mit allen aktuellen Updates sind.

Jan

sind die betreffenden PCs immer bei Directory() langsam oder nur beim ersten mal

Immer.

Jan

So richtig lesen wird hier nicht oder ?
Es sind weder Netzwerkprobleme noch sonst was, ausschließlich Win 10 (1803) !

Jupp.

Jan

Hallo Klaus

So richtig lesen wird hier nicht oder ?

Es war nur ein Tip aus Erfahrung. Neue Win-Treiber haben verursacht dass bestimmte Kombinationen zusammen einfach nicht mehr richtig schnell funktionierten. Wie du hatten wir auch lange nicht daran gelaubt sondern gedacht: "Es sind keine Netzwerkprobleme" ... Windows lernte uns etwas anderes. Die Wege des Windows sind unergründlich ......

Wie weiss er dass es keine Netzwerkprobleme sind, geschrieben dass er dies getestet hat hat er nicht. Nur dass es vor dem Update besser war.

Gruss Carlo

So. Dank eines externen Supporters ist das Problem erledigt. Es fehlen drei Registry-Enträge:

HKLM\SYSTEM\CurrentControllSet\Services\LanmanWorkstation\Parameters
Neu hinzufügen als DWORD:
DirectoryCacheLifetime = 0
FileInfoCacheLifetime = 0
FileNotFoundCacheLifetime = 0

Klappt sofort, auch ohne Reboot. Die Abfragen per Directory() sind wieder so schnell wie früher.

Jetzt müssen wir das nur noch auf alle Rechner im Netzwerk verteilen ...

Jan

Jans Problem gibt es schon länger und die oben gezeigte Lösung gibt es seit 2 Jahren, hat also nix mit einem aktuellen Windows-Update zu tun.

Zur Behebung des Problems ist ausreichend, wenn an den Arbeitsplatz-Rechnern die Caching-Einstellungen deaktiviert werden, die in Zusammenhang mit neueren SMB Versionen eingeführt wurden.

SMB-Caching ausschalten SMB-Caching einschalten Die Code-Schnipsel als REG-Datei speichern und als Admin im Explorer anklicken zum Eintragen in der Registry.

Jan hat geschrieben: ↑Fr, 15. Jun 2018 16:34 So. Dank eines externen Supporters ist das Problem erledigt. Es fehlen drei Registry-Enträge:

das sind doch die Registry Einträge die auch der der Patch von Alaska schreibt.

Ich wundere mich das diese WORKSTATION Einträge helfen ... oder war der Zugriff mit Directory() auf der Workstation

Ist schon richtig. Es geht um das Caching von Datei-Metadaten in Netzwerksituationen.

Na gut, dass ich diese 3 Einträge schon lange in meinem Clientsetup drin habe

Jan hat geschrieben: ↑Fr, 15. Jun 2018 16:34 So. Dank eines externen Supporters ist das Problem erledigt. Es fehlen drei Registry-Enträge:

HKLM\SYSTEM\CurrentControllSet\Services\LanmanWorkstation\Parameters
Neu hinzufügen als DWORD:
DirectoryCacheLifetime = 0
FileInfoCacheLifetime = 0
FileNotFoundCacheLifetime = 0

Klappt sofort, auch ohne Reboot. Die Abfragen per Directory() sind wieder so schnell wie früher.

Jetzt müssen wir das nur noch auf alle Rechner im Netzwerk verteilen ...

Jan

Ehrlich gesagt wundert es mich, dass es noch Rechner NACH DEM PATCH von Win 7 gibt, die diese Einträge nicht gesetzt haben.
Ohne diese sind bei uns die Indexdateien mehrfach je Tag defekt gewesen.

Eventuell aber hat der Win 10 Patch die Werte zurückgesetzt ?

Hubert,

bei dem Kunden war das immer fester Bestandteil der Installationsprotokolle neuer Rechner, den Alaska-Patch zu installieren. Das wurde also konseqent durchgezogen. Ich glaube, zuletzt nicht mehr, seitdem da der ADS läuft.

Ich bin mir auch nicht wirklich sicher, was genau da abgeht. Ich hatte ja geschrieben, das es von meinem Rechner aus verschiedene Verhaltensweisen gab, je nachdem, auf welchen Server ich zugegriffen hatte.

Der Admin hat mir inzwischen geschrieben, das für das Performanceproblem in Directory() der DirectoryCacheLifetime-Eintrag vollkommen ausreicht. Er hatte da mal verschiedene Kombinationen durchgetestet.

Jan

Hallo Wolfgang
Ja das dachten ich auch. Aber nach dem Windowsupdate war es nicht mehr da.
Batch von Alaska wieder installiert.

Gruss Thomas

Hallo

ich prüfe die Werte seit dies bekannt wurde beim Programmstart. Das geht mit der RegClass ganz einfach, wenn die Werte nicht korrekt entweder angepasst oder bei fehlenden Rechten Meldung und Programmende Ende. So muss ich nichts weiter tun. Falsche Werte werden automatisch korrigiert.


Gruss Carlo

Passend zum Thema gibt es seit Dienstag einen außerplanmässigen Patch: https://www.heise.de/newsticker/meldung ... 93027.html

Viele Grüße,
Martin