Kopieren zwischen 2 Netzwerklaufwerken (auf dem Server) dauert ewig

Nach Stunden der Fehlersuche, bekomme ich es nichtin den Griff.

Vielleicht kann mir jemand helfen ?

Der Server 2003 SBS hat div. Festplatten:

Laufwerk E und F sind je freigegeben.

Kopiere ich lokal von E nach F keine Probleme.

Kopiere ich jetzt aber von E nach F über einen Client (XP), der beide Laufwerke als Netzwerklaufwerke verbunden hat (Q und R), dauert das ganze eine Ewigkeit, obwohl es doch im Endeffekt die gleichen Platten sind.

Es ist also irgendein Netzwerkproblem und tritt auch auf, wenn andere Clients auf den Server zugreifen.

Jetzt kommt es aber noch besser:
Kopiere ich von einem der Serverlaufwerke (sagen wir Q) auf ein LOKALES am Client (z.B.), stimmt der Speed. Der Server bekommt also irgendwie nicht gebacken, dass der Kram auf seinen Platten ist und schickt alles wohl auf die Reise durchs LAN :-(

AD ist im Einsatz. Ich vermute dort oder im DNS-Server das Problem.

Zur Info: Alle betreffenden Rechner sind direkt an einem Switch.

Is ja logisch. Beim kopieren laufen die Daten über den lokalen Cache.

Wenn du also von E: auf F: kopierst, werden erst die Daten lokal gecached und dann auf F: geschoben.
Und da daurch natürlcih die Leitung in beiden Richtungen voll ausgelastet wird gehts halt länger als vom Netz auf lokal kopieren.

Hallo

generell gebe ich Dir Recht. Nur sollte auch dieser Vorgang bei einer 3 MB Datei nicht fast 15 Minunten dauern.

Ich teste mal ein bissel weiter.

Läuft das Netzwerk im Voll-Duplex-Modus?

Hallo

ja...das funktioniert..ich baue nochmals eine nachvollziehbare Testumgebung auf.

Hi,

ich hatte ein ähnliches Problem auch, bei mir lag der Fehler, dass meine Netzwerkkarte auf 100/Half Duplex eingestellt war. Nachdem ich sie auf AutoDetect gestellt habe lief es einwandfrei.

gruß
KingOfMalle

Hallo

konnte den Fehler eingrenzen:

Es liegt nicht an der Hardware. Wenn der Admin kopiert (von Serverlaufwerk X auf Y), funktioniert es wie erwartet. Macht es aber ein Benuter aus dem AD, tritt der Effekt auf, wenn es sich um ein Laufwerk auf dem Server handelt.

Hm...

Also

ich habe nun gebastelt und festgestellt, dass es am Active Directory liegt.

Wenn auf die Freigaben ohne AD (d.h. über lokale Accounts am Server mit gleichem Username/Passwort) über das Netz, dauert das kopieren keine 15 Sekunden..

Sind die Accounts im AD angelegt, dauert es dagegen 15 Minunten!.

Einzige Ausnahme ist der Domänenadmin bei der Installation. Eine nachträgliche Beförderung der Normalos bringt dagegen wieder nix.

Und hier die Lösung: Wobei sowohl XP als auch der Win2003-Server sowie der SBS-Server out of the box waren:

Das kopieren von Dateien auf Netzlaufwerke, die von einem Windows 2003 Server zur Verfügung gestellt werden, dauert unter Windows XP extrem lange. Hierbei liegt das Problem daran, dass Windows XP versucht beim kopieren eine Digitale Verbindung auszuhandeln. Das Problem wird im Microsoft Artikel D321169 genauer erklärt.

Umgehungsmöglichkeit 1
Starten Sie den Registrierungseditor (Regedt32.exe).
Suchen Sie den folgenden Registrierungsschlüssel und klicken Sie ihn dann an:

HKEY_LOCAL_MACHINE\System\CCS\Services\LanmanServer\Parameters

Doppelklicken Sie auf den Wert RequireSecuritySignature, geben Sie 0 im Feld Wert ein und klicken Sie auf OK.
Doppelklicken Sie auf den Wert EnableSecuritySignature, geben Sie 0 im Feld Wert ein und klicken Sie auf OK.
Beenden Sie den Registrierungseditor.
Standardmäßig ist der Wert EnableSecuritySignature auf einem Domänencontroller auf 1 (EIN) eingestellt, auf einem Nicht-Domänencontroller auf 0 (AUS). Deshalb ist die SMB-Leistung beim Kopieren nur dann langsam, wenn Sie Elemente auf einen Domänencontroller kopieren.

In der Domain Default Group Policy kann das Aushandeln

Das Problem kann auch über die Gruppenrichtlinien am Server behoben werden, dazu sollte die Default Domaincontroller Policy bearbeitet:

Über die Konsole Active Directory Benutzer und Computer mit der rechten Maustaste auf Default Domain Controllers Policy, klicken und in die Eigenschaften wechseln.
Arbeite Dich bis zu folgender Option vor:

Computerkonfiguration\Windows Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheits Optionen.
Wenn eine der Folgenden Einstellungen auf Aktiviert steht, müssen diese auf Deaktiviert gesetzt werden, um eine Geschwindigkeitszunahme zu erreichen. Hinweis: Standardmäßig, ist nur eine Einstellung auf Aktiviert gesetzt.

Microsoft Netzwerk (Client): Kommunikation digital signieren (immer)
Microsoft Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)
Microsoft Netzwerk (Server) Kommunikation digital signieren (immer)
Microsoft Netzwerk (Server) Kommunikation digital siginieren (wenn Client zustimmt)

Danach bitte den Richtlinieneditor schließen, und die Berechtigungen für die Default Domaincontroller Richtlinie auf Domänencomputer: Lesen/Ausführen und Richtlinie übernehmen erweitern. Solltet Ihr vergessen die Berechtigungen zu erweitern, werdet Ihr am Server Probleme bekommen die Default Domaincontroller Richtlinie abzuarbeiten d.h. es gibt Einträge im Ereignisprotokoll. Nachträglich kann man das allerdings über die Registry oder sofern Ihr vorher die Default Policys gesichert oder unberührt gelassen habt das ganze wiederherstellen.

Gefunden bei http://www.patator.de/problembehebung.htm

Hallo

der beschriebene Tipp macht leider auch Probleme. Ich würde daher bis zu dem UMB-Patch von Microsoft für Windows XP eher den ersten Tipp der Seite nehmen:

Das Kopieren vieler kleiner Dateien von Netzlaufwerk auf Netzlaufwerk mit Windows XP Client die von einem Windows 2000/2003 Server zur Verfügung gestellt werden, dauert sehr sehr lange. Bei großen Dateien kann das Problem nicht festgestellt werden. Wie gesagt dieses Problem kann unter Windows XP Professional Clients festgestellt werden, die über den Windows Explorer Dateien kopieren.

Mit den Befehlszeilenprogrammen wie XCOPY oder ROBOCOPY ist kein Geschwindigkeitsproblem festzustellen. Microsoft hat sich hierzu geantwortet und bestätigt, dass es sich hierbei um ein Problem handelt.

Für das Service Pack 2 das noch kommt würde ein dementsprechender Patch zur Verfügung gestellt werden, den Ihr auch bei mir runterladen könnt (Patch Q810907_WXP_SP2), dies geschieht aber unter Ausschluss jeder Gewährleistung, da es sich um einen Patch handelt, der nicht offiziell erhältlich ist. NACHTRAG: Den Patch haben wir wieder runtergenommen, da wir keine rechtlichen Probleme bekommen möchten.

Das Problem ist dass die SMB Server Message Block Schreiboperationen nach jeder kopierten Datei einen Delay von 200msec laufen lassen für eine Rückantwort ob die Datei angekommen ist, bzw. was sich geändert hat.

Am Server kann dieser Timer ausgeschaltet werden, was eine hohe E/A Erhöhung zur Folge hat, aber auch zum Nachteil dass sich die Netzwerkkollisionen erhöhen.

Tipp: Füge folgenden noch nicht enthaltenen Registry Eintrag mit REGEDT32 ein:

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Adapter GUID

Value name: TcpDelAckTicks
Data type: REG_DWORD
Value data: Du kannst hier von 0 to 6 einstellen.
Standard Einstellung 2 (200 milliseconds).
0 deaktiviert den Delay.

Hier bitte auf keinen Fall den Key eintragen:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Hallo Micha,

bist du Dir ganz sicher, daß Eure DNS-Konfiguration völlig i.O. ist? Hierdurch verursacht entstehen oft sehr große Probleme! Etwas stutzig macht mich die Tatsache, daß es lokal schneller geht...
Nutzt Ihr NetBIOS noch, wie sieht es mit DFS aus o. z.B. mit Replikation (Bandbreite u. Zeiten, Standortverknüpfungen etc.)?

Gruß, Frank

Hallo

ob mit oder ohne DNS (Laufwerke über IP gemappt), tritt der Effekt auf. Komischerweise sogar bei Win2k3-Server und XP out of the box.

Wie Microsoft richtig schreibt http://support.microsoft.com/default.aspx?scid=kb;DE;321169 tritt der Effekt auf.

Mit dem SP2 für XP soll der Fehler behoben werden..eigentlich ein Skandal.

Das Problem haben leider auch andere http://www.mcseboard.de/archiv/32/2003/10/4/15899

Hallo Micha,

ja ich weiß; der Fehler ist mir bekannt, aber wie bereits gesagt: oft liegt der Fehler im DNS. Gerade im Bezug auf AD - das wird oft unterschätzt.

Guten Rutsch u. Gruß, Frank

Ebnso guten Rutsch.