W2K3-XP: Kopieren größerer Dateien nicht möglich
Hallo aus Stuttgart,
ich hätt da gern mal ein Problem: Ich hab heut 4 Stunden beim Kunden gesessen und nix erreicht. Vielleicht kann mir ja hier jemand weiterhelfen?!
Also, da steht ein W2K3 SBS SP1 mit allen Patches, die Clients sind XP und W2K mit allen Patches. Seit ein paar Wochen kann man keine Dateien die größer als ca. 27MB sind vom Share auf nen Client kopieren. Das ist aufgefallen bei einer Clientneuinstallation, als der Acrobatreader nicht vom Server auf lokal kopierbar war.
Das Ganze sieht so aus:
Es geht los und nach einiger Zeit bleibt der Fortschrittsbalken stehen und nochmal später heißt es dann: "Der Netzwerkname ist nicht mehr verfügbar". Je nachdem wie groß die Datei ist, werden mal 70, mal auch 150MB übertragen, aber Größeres wird eben nicht fertig.
Eigentlich wurde an dem Netz nichts verändert, außer über "automatische Updates". Die Treiber aufm Server (HP ML350 G3) sind neu (vom 25.09. heute installiert) und an größeren Umkonfigurationen wurde seit Monaten nichts vorgenommen.
Es gibt auch noch einen Linuxserver mit Samba3, der Mitgliedsserver der AD ist. Mit dem gibt es die Probleme unter Samba auch, es muß also am SMB Protokoll der M$ Maschinen liegen.
Ich hab bis jetzt folgendes gemacht (erfolglos):
- Zeitserverfunktionalität überprüft: ok
- Zugriff aus Sysvol: ok
- DNS Funktionalität überprüft: ok
- SMB Signing nach Gruppenrichtlinien.de eingestellt (also "Immer signieren" deaktiviert): GPO wird clientseitig upgedatet
- mit KillCopy rumkopiert, Bandbreite auf ein Minimum runtergesetzt, no way!
- per ftp und netio die Netzperformance überprüft: Solange man kein SMB verwendet ist alles bestens, netio macht 10,5-11MBytes/s in nem 100MBit/s Netz. Somit kann man die physikalische Netzhardware wohl ausschließen.
- mit ethereal Kopiersessions gesnifft: Am Schluß kommen einfach keine Pakete mehr vom Client, dann erfolgt ein SMB RST (Reset), das Share wird neu eingelesen und in dem Moment kommt obige Meldung.
- mit WinXPTCPFix.exe die TCP/IP Konfiguration an einem Client exemplarisch zurückgesetzt - kein Erfolg.
- Auf dem Server das neue HP Support Pack mit neuen Treibern eingespielt, kein Chance!
- Auf dem Server testweise sämtliche zusätzlichen Dienste disabled: Oracle, Exchange, Blackberry etc., vergiß es!
- gegoogelt wie blöd und ne Menge Threads gelesen, wo entweder Sachen faul waren, die hier funzen (Kabel, Switch etc.) oder wo es keine Lösung zum Problem gab.
Zu guter Letzt: man kann z.B. ein 1,7GB großes Imagefile vom Client auf den Server kopieren, aber nicht umgekehrt.
Ich bin mit meinem Latein grad voll am Ende, hab keine Ahnung was ich noch machen kann. Einzige Idee ist einen Client-PC neu aufzusetzen und die Patches nach und nach einzuspielen, bis der Faule auftaucht.
Vielleicht hat ja hier noch jemand ne Idee? Jede Hilfe ist willkommen.
Greetz,
Tom
Das Ganze sieht so aus:
Es geht los und nach einiger Zeit bleibt der Fortschrittsbalken stehen und nochmal später heißt es dann: "Der Netzwerkname ist nicht mehr verfügbar". Je nachdem wie groß die Datei ist, werden mal 70, mal auch 150MB übertragen, aber Größeres wird eben nicht fertig.
Eigentlich wurde an dem Netz nichts verändert, außer über "automatische Updates". Die Treiber aufm Server (HP ML350 G3) sind neu (vom 25.09. heute installiert) und an größeren Umkonfigurationen wurde seit Monaten nichts vorgenommen.
Es gibt auch noch einen Linuxserver mit Samba3, der Mitgliedsserver der AD ist. Mit dem gibt es die Probleme unter Samba auch, es muß also am SMB Protokoll der M$ Maschinen liegen.
Ich hab bis jetzt folgendes gemacht (erfolglos):
- Zeitserverfunktionalität überprüft: ok
- Zugriff aus Sysvol: ok
- DNS Funktionalität überprüft: ok
- SMB Signing nach Gruppenrichtlinien.de eingestellt (also "Immer signieren" deaktiviert): GPO wird clientseitig upgedatet
- mit KillCopy rumkopiert, Bandbreite auf ein Minimum runtergesetzt, no way!
- per ftp und netio die Netzperformance überprüft: Solange man kein SMB verwendet ist alles bestens, netio macht 10,5-11MBytes/s in nem 100MBit/s Netz. Somit kann man die physikalische Netzhardware wohl ausschließen.
- mit ethereal Kopiersessions gesnifft: Am Schluß kommen einfach keine Pakete mehr vom Client, dann erfolgt ein SMB RST (Reset), das Share wird neu eingelesen und in dem Moment kommt obige Meldung.
- mit WinXPTCPFix.exe die TCP/IP Konfiguration an einem Client exemplarisch zurückgesetzt - kein Erfolg.
- Auf dem Server das neue HP Support Pack mit neuen Treibern eingespielt, kein Chance!
- Auf dem Server testweise sämtliche zusätzlichen Dienste disabled: Oracle, Exchange, Blackberry etc., vergiß es!
- gegoogelt wie blöd und ne Menge Threads gelesen, wo entweder Sachen faul waren, die hier funzen (Kabel, Switch etc.) oder wo es keine Lösung zum Problem gab.
Zu guter Letzt: man kann z.B. ein 1,7GB großes Imagefile vom Client auf den Server kopieren, aber nicht umgekehrt.
Ich bin mit meinem Latein grad voll am Ende, hab keine Ahnung was ich noch machen kann. Einzige Idee ist einen Client-PC neu aufzusetzen und die Patches nach und nach einzuspielen, bis der Faule auftaucht.
Vielleicht hat ja hier noch jemand ne Idee? Jede Hilfe ist willkommen.
Greetz,
Tom
Please also mark the comments that contributed to the solution of the article
Content-Key: 41977
Url: https://administrator.de/contentid/41977
Printed on: April 25, 2024 at 07:04 o'clock
3 Comments
Latest comment
Fehler-Möglichkeiten:
1.) Fehlerhafte Windows Netzwerkkonfiguration (z.B. zwei Windows-Clients mit dem gleichen Hostname).
2.) Fehlerhafter Treiber. => Mit verifier prüfen:
http://wiki.bsdforen.de/index.php/Windows_-_Sicherheit_unter_Windows#Ve ...
3.) Fehlerhafter Virenscanner auf dem Windows-Client, der sich bei grösseren Dateien verschluckt. Mit Taskmanager die CPU-Last und Prozesszeiten kontrollieren.
1.) Fehlerhafte Windows Netzwerkkonfiguration (z.B. zwei Windows-Clients mit dem gleichen Hostname).
2.) Fehlerhafter Treiber. => Mit verifier prüfen:
http://wiki.bsdforen.de/index.php/Windows_-_Sicherheit_unter_Windows#Ve ...
3.) Fehlerhafter Virenscanner auf dem Windows-Client, der sich bei grösseren Dateien verschluckt. Mit Taskmanager die CPU-Last und Prozesszeiten kontrollieren.