8
Gemappte Laufwerke erzeugen konstanten Traffic
Ein herzliches Hallo an alle,
seit Tagen suche ich nach der Ursache für einen konstanten Datenstrom von einem Windows 7 Pro Client zu unseren Fileservern.
Szenario:
Ein neu aufgesetzter Client (Windows 7 Pro auf einer Dell Precision T3610 Workstation) funktioniert einwandfrei. Es gibt keinen auffälligen Traffic im Idle-Betrieb oder sonstige Performance-Probleme. Sobald jedoch Laufwerke von den Fileservern gemappt werden, besteht ein konstanter Datenstrom zwischen Server und Client. Dieser liegt bei 10 gemappten Laufwerken bei rund 450 kbps (laut Resmon). Entferne ich die Netzlaufwerke sukzessive, reduziert sich der Datenstrom proportional bis praktisch 0, wenn keine Mappings mehr aktiv sind. Dieser Effekt tritt unabhängig des aktiven Nutzerprofils auf. Ich habe mir 8 weitere Clients angeschaut und konnte dort keinerlei Traffic dieser Art feststellen.
Der betroffene Client verbindet sich mit Shares auf zwei Fileservern (beide Windows Server 2008 R2). Beide Verbindungen sind betroffen.
Eine nähere Analyse via Wireshark zeigt, dass es sich um Aktivitäten im SMB2-Protokoll handelt. Hier ein Beispiel:
2188 7.319000000 192.168.0.50 192.168.1.124 SMB2 394 Create Request File: QMS;Ioctl Request FSCTL_GET_REPARSE_POINT
2189 7.319420000 192.168.1.124 192.168.0.50 SMB2 378 Create Response File: QMS;Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT
2190 7.319626000 192.168.0.50 192.168.1.124 SMB2 146 Close Request File: QMS
2191 7.319900000 192.168.1.124 192.168.0.50 SMB2 182 Close Response
2192 7.320101000 192.168.0.50 192.168.1.124 SMB2 370 Create Request File: QMS;Ioctl Request FSCTL_GET_REPARSE_POINT
2193 7.320376000 192.168.0.50 192.168.1.124 SMB2 346 Create Request File: QMS\$Extend\$Quota:$Q:$INDEX_ALLOCATION
2194 7.320439000 192.168.1.124 192.168.0.50 SMB2 322 Create Response File: QMS;Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT
2195 7.320617000 192.168.1.124 192.168.0.50 SMB2 131 Create Response, Error: STATUS_OBJECT_PATH_NOT_FOUND
2196 7.320633000 192.168.0.50 192.168.1.124 SMB2 146 Close Request File: QMS
2197 7.320853000 192.168.1.124 192.168.0.50 SMB2 182 Close Response
Dieser Abschnitt steht stellvertretend für alle gemappten Laufwerke. "QMS" ist hierbei der Name Freigabename.
Ich habe die Maschine auch einmal neu in die Domäne gehoben - auf gut Glück sozusagen. Ebenso habe ich verschiedene Dienste deaktiviert und versucht eine Ursache zu ermitteln, ohne Erfolg. Jegliche Suche im Web waren Sackgassen. Zwar habe ich vergleichbare und fast identische Symptome gefunden, jedoch gab es dort keinerlei Lösungen. Gegenwärtig habe ich entweder ein gewaltiges Brett vor dem Kopf oder der Urlaub wird dringender denn je ;)
Ich wäre sehr Dankbar für Ideen oder einen Lösungsansatz. Der Client funktioniert ansonsten ohne Probleme, der konstante Traffic ist aber nicht nur ungewöhnlich sondern auch lästig (auch wenn er keine direkten Probleme verursacht).
Vielen Dank schon mal fürs Mitgrübeln
seit Tagen suche ich nach der Ursache für einen konstanten Datenstrom von einem Windows 7 Pro Client zu unseren Fileservern.
Szenario:
Ein neu aufgesetzter Client (Windows 7 Pro auf einer Dell Precision T3610 Workstation) funktioniert einwandfrei. Es gibt keinen auffälligen Traffic im Idle-Betrieb oder sonstige Performance-Probleme. Sobald jedoch Laufwerke von den Fileservern gemappt werden, besteht ein konstanter Datenstrom zwischen Server und Client. Dieser liegt bei 10 gemappten Laufwerken bei rund 450 kbps (laut Resmon). Entferne ich die Netzlaufwerke sukzessive, reduziert sich der Datenstrom proportional bis praktisch 0, wenn keine Mappings mehr aktiv sind. Dieser Effekt tritt unabhängig des aktiven Nutzerprofils auf. Ich habe mir 8 weitere Clients angeschaut und konnte dort keinerlei Traffic dieser Art feststellen.
Der betroffene Client verbindet sich mit Shares auf zwei Fileservern (beide Windows Server 2008 R2). Beide Verbindungen sind betroffen.
Eine nähere Analyse via Wireshark zeigt, dass es sich um Aktivitäten im SMB2-Protokoll handelt. Hier ein Beispiel:
2188 7.319000000 192.168.0.50 192.168.1.124 SMB2 394 Create Request File: QMS;Ioctl Request FSCTL_GET_REPARSE_POINT
2189 7.319420000 192.168.1.124 192.168.0.50 SMB2 378 Create Response File: QMS;Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT
2190 7.319626000 192.168.0.50 192.168.1.124 SMB2 146 Close Request File: QMS
2191 7.319900000 192.168.1.124 192.168.0.50 SMB2 182 Close Response
2192 7.320101000 192.168.0.50 192.168.1.124 SMB2 370 Create Request File: QMS;Ioctl Request FSCTL_GET_REPARSE_POINT
2193 7.320376000 192.168.0.50 192.168.1.124 SMB2 346 Create Request File: QMS\$Extend\$Quota:$Q:$INDEX_ALLOCATION
2194 7.320439000 192.168.1.124 192.168.0.50 SMB2 322 Create Response File: QMS;Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT
2195 7.320617000 192.168.1.124 192.168.0.50 SMB2 131 Create Response, Error: STATUS_OBJECT_PATH_NOT_FOUND
2196 7.320633000 192.168.0.50 192.168.1.124 SMB2 146 Close Request File: QMS
2197 7.320853000 192.168.1.124 192.168.0.50 SMB2 182 Close Response
Dieser Abschnitt steht stellvertretend für alle gemappten Laufwerke. "QMS" ist hierbei der Name Freigabename.
Ich habe die Maschine auch einmal neu in die Domäne gehoben - auf gut Glück sozusagen. Ebenso habe ich verschiedene Dienste deaktiviert und versucht eine Ursache zu ermitteln, ohne Erfolg. Jegliche Suche im Web waren Sackgassen. Zwar habe ich vergleichbare und fast identische Symptome gefunden, jedoch gab es dort keinerlei Lösungen. Gegenwärtig habe ich entweder ein gewaltiges Brett vor dem Kopf oder der Urlaub wird dringender denn je ;)
Ich wäre sehr Dankbar für Ideen oder einen Lösungsansatz. Der Client funktioniert ansonsten ohne Probleme, der konstante Traffic ist aber nicht nur ungewöhnlich sondern auch lästig (auch wenn er keine direkten Probleme verursacht).
Vielen Dank schon mal fürs Mitgrübeln
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 279986
Url: https://administrator.de/contentid/279986
Printed on: May 7, 2024 at 20:05 o'clock
8 Comments
Latest comment
Moin,
Wäre vielleicht mal interessant die Wireshark-Daten zu untersuchen welcher Link das genau ist, welchen der Rechner da sucht.
Ist der Virenscanner so eingestellt das er auch auch Netzlaufwerke scannt ? Aber vermutlich hast du den auch schon mal deaktiviert.
Sind Quotas auf dem Share aktiviert ?
Gruß grexit
FSCTL_GET_REPARSE_POINT
da scheint irgendein Programm auf dem Client kontinuierlich nach symbolischen Links auf dem Share zu suchen und dieses nicht zu finden, denn solch einer wird unter Windows so bezeichnet (REPARSE_POINT).Wäre vielleicht mal interessant die Wireshark-Daten zu untersuchen welcher Link das genau ist, welchen der Rechner da sucht.
Ist der Virenscanner so eingestellt das er auch auch Netzlaufwerke scannt ? Aber vermutlich hast du den auch schon mal deaktiviert.
Sind Quotas auf dem Share aktiviert ?
Gruß grexit
Danke für deine schnelle Antwort,
Die AV-Lösung habe ich natürlich bereits versucht auszuschließen. Hier konnte ich die Ursache nicht ausmachen.
Quotas sind auf den Fileservern aktiv.
Zu der Sache mit den symLinks konnte ich bisher noch nichts konkreteres finden.
Aber...
Ich habe mir mal die aktiven Verbindungen in Bezug zu den PIDs angeschaut und bin dann bei der "Windows Verwaltungsinstrumentation" (wmiprvse.exe - WMI Provider Host) hängen geblieben. Jetzt stelle ich folgendes fest:
Sobald der Client hochgefahren und ein Benutzer angemeldet ist, sind die wilden Anfragen sofort vorhanden. Wenn ich nun den Dienst der Verwaltungsinstrumentation anhalte (nur anhalten, nicht stoppen) ist der Effekt sofort weg. Auch wenn ich den Dienst wieder laufen lasse, tritt der Effekt nicht wieder auf. Erst nach einem Systemneustart ist er wieder da.
Ich habe nun zumindest eine Eingrenzung und einen temporären Workaround, aber noch keine Lösung. Ich finde noch immer keinen Weg herauszufinden, woher diese Anfragen kommen bzw. warum diese entstehen. Ich habe ebenfalls nochmals alle erdenklichen Dienste einzeln beendet, ohne einen weiteren Schuldigen zu finden.
Ich bin weiter offen für Ratschläge oder Impulse
Die AV-Lösung habe ich natürlich bereits versucht auszuschließen. Hier konnte ich die Ursache nicht ausmachen.
Quotas sind auf den Fileservern aktiv.
Zu der Sache mit den symLinks konnte ich bisher noch nichts konkreteres finden.
Aber...
Ich habe mir mal die aktiven Verbindungen in Bezug zu den PIDs angeschaut und bin dann bei der "Windows Verwaltungsinstrumentation" (wmiprvse.exe - WMI Provider Host) hängen geblieben. Jetzt stelle ich folgendes fest:
Sobald der Client hochgefahren und ein Benutzer angemeldet ist, sind die wilden Anfragen sofort vorhanden. Wenn ich nun den Dienst der Verwaltungsinstrumentation anhalte (nur anhalten, nicht stoppen) ist der Effekt sofort weg. Auch wenn ich den Dienst wieder laufen lasse, tritt der Effekt nicht wieder auf. Erst nach einem Systemneustart ist er wieder da.
Ich habe nun zumindest eine Eingrenzung und einen temporären Workaround, aber noch keine Lösung. Ich finde noch immer keinen Weg herauszufinden, woher diese Anfragen kommen bzw. warum diese entstehen. Ich habe ebenfalls nochmals alle erdenklichen Dienste einzeln beendet, ohne einen weiteren Schuldigen zu finden.
Ich bin weiter offen für Ratschläge oder Impulse
Check mal die GPOs für den Client ob es da eine mit einem WMI-Filter gibt.
Auf dem Client greifen laut GPResult zwei GPOs via WMI-Filter.
Einer regelt die Softwareverteilung einer Management-Software sowie die Windows-Updates-Konfig. Ein weiterer deaktiviert den CSC Dienst für Windows 7 Clients, da uns die Offline-Dateien vor ein paar Jahren Probleme bereitet hatten.
Um es zu präzisieren, der WMI-Filter der Offline-Files (CSC) sieht wie folgt aus:
Namespace: root\CIMv2
Abfrage: select * from Win32_OperatingSystem where ProductType="1" and Version like "6.%"
Andere GPOs greifen nicht, da dort der WMI-Filter nicht matcht.
Erwähnen möchte ich noch, dass wir im Haus derzeit rund 50 Win7Pro Clients mit identischen GPs laufen haben und dort dieser Effekt bisher nie auftrat. Ich hatte anfangs den Client nochmals neu in die Domäne gehoben um etwaige GP-Probleme oder ein defektes Maschinenprofil ausschließen zu können. Was an diesem Client im Vergleich zu allen anderen speziell ist, ist nur die Tatsache, dass es eine Dell-Precision-Workstation ist, während alle anderen aus der OptiPlex-Reihe sind. Die verwendeten Anwendungen sind auch vergleichbar, bis auf ein paar Adobe-Produkten.
Einer regelt die Softwareverteilung einer Management-Software sowie die Windows-Updates-Konfig. Ein weiterer deaktiviert den CSC Dienst für Windows 7 Clients, da uns die Offline-Dateien vor ein paar Jahren Probleme bereitet hatten.
Um es zu präzisieren, der WMI-Filter der Offline-Files (CSC) sieht wie folgt aus:
Namespace: root\CIMv2
Abfrage: select * from Win32_OperatingSystem where ProductType="1" and Version like "6.%"
Andere GPOs greifen nicht, da dort der WMI-Filter nicht matcht.
Erwähnen möchte ich noch, dass wir im Haus derzeit rund 50 Win7Pro Clients mit identischen GPs laufen haben und dort dieser Effekt bisher nie auftrat. Ich hatte anfangs den Client nochmals neu in die Domäne gehoben um etwaige GP-Probleme oder ein defektes Maschinenprofil ausschließen zu können. Was an diesem Client im Vergleich zu allen anderen speziell ist, ist nur die Tatsache, dass es eine Dell-Precision-Workstation ist, während alle anderen aus der OptiPlex-Reihe sind. Die verwendeten Anwendungen sind auch vergleichbar, bis auf ein paar Adobe-Produkten.
Dann ziehe mal ein Image der Maschine und setz den Client neu auf. Ist vermutlich die schnellste Methode den Ausreißer wieder ins Boot zu holen.
Mit dem Image kannst du dann in einer VM hantieren und den Fehler in Ruhe ausfindig machen.
Da hilft nur eingrenzen und mal alle GPOs mit WMI-Filtern für diese Maschine zu deaktivieren, step by step eingrenzen.
Von hier aus ist eine genaue Diagnose dieses Fehlers doch ziemlich schwierig.
Gruß grexit
Mit dem Image kannst du dann in einer VM hantieren und den Fehler in Ruhe ausfindig machen.
Da hilft nur eingrenzen und mal alle GPOs mit WMI-Filtern für diese Maschine zu deaktivieren, step by step eingrenzen.
Von hier aus ist eine genaue Diagnose dieses Fehlers doch ziemlich schwierig.
Gruß grexit
Ich werde dem nochmal genauer nachgehen, vielleicht findet sich ja tatsächlich etwas in Verbindung mit den WMI-Filtern. Ich bin allerdings erst mal für drei Wochen im Urlaub und werde daher die Analyse verschieben müssen. Glücklicherweise ist der Client kein betriebskritisches System ;)
Lieben Dank schon mal an grexit für die bisherigen Anregungen. Vielleicht findet sich in der Zwischenzeit ja noch jemand der das Phänomen kennt. Ich werde - trotz Urlaub - hier mitlesen
Sollte ich eine Lösung finden melde ich mich selbstverständlich auch
Lieben Dank schon mal an grexit für die bisherigen Anregungen. Vielleicht findet sich in der Zwischenzeit ja noch jemand der das Phänomen kennt. Ich werde - trotz Urlaub - hier mitlesen
Sollte ich eine Lösung finden melde ich mich selbstverständlich auch
Alles klar, dann schönen Urlaub wünsch ich
Inzwischen sind einige Wochen vergangen und ich war nicht untätig. Mir ließ es keine Ruhe die Ursache zu finden. Gleich vorweg, ich konnte das Problem beseitigen! Jetzt das "Aber": Ich kann leider nicht sicher sagen, was die Ursache war.
Meine Lösung: Neuinstallation des Netzwerkkartentreibers
Es klingt jetzt wirklich banal und stumpf, aber tatsächlich war es "so einfach".
Nachdem ich intensiv bei den WMI-Filtern suchte, diverse MOF's re-registriet, an vielen anderen Stellen suchte, hatte ich es schon fast aufgegeben. Ich konnte die Ursache einfach nicht finden. Als ich dann begann die Treiber zu überprüfen stellte ich zu meinem Erstaunen fest, dass sofort nach der Neuinstallation (kein Update) des Netzwerkkartentreibers der ominöse Traffic verschwunden war.
Ich gehe nicht davon aus dass der Fehler direkt mit dem Treiber zu tun hatte, ich vermute eher, dass durch das installieren des Treibers an anderer Stelle die eigentliche Ursache eliminiert wurde.
Ich bin froh dass nun alles funktioniert, allerdings bedauere ich sehr die Ursache nicht lokalisiert zu haben. So wird dies ein Mysterium bleiben ;)
Meine Lösung: Neuinstallation des Netzwerkkartentreibers
Es klingt jetzt wirklich banal und stumpf, aber tatsächlich war es "so einfach".
Nachdem ich intensiv bei den WMI-Filtern suchte, diverse MOF's re-registriet, an vielen anderen Stellen suchte, hatte ich es schon fast aufgegeben. Ich konnte die Ursache einfach nicht finden. Als ich dann begann die Treiber zu überprüfen stellte ich zu meinem Erstaunen fest, dass sofort nach der Neuinstallation (kein Update) des Netzwerkkartentreibers der ominöse Traffic verschwunden war.
Ich gehe nicht davon aus dass der Fehler direkt mit dem Treiber zu tun hatte, ich vermute eher, dass durch das installieren des Treibers an anderer Stelle die eigentliche Ursache eliminiert wurde.
Ich bin froh dass nun alles funktioniert, allerdings bedauere ich sehr die Ursache nicht lokalisiert zu haben. So wird dies ein Mysterium bleiben ;)
