none
langes laden von docx oder pptx über DFS Pfad? RRS feed

  • Frage

  • hallo Zusammen,

    von unterschiedlichen Clients, werden Dateien vom Lokalen Fileserver über den DFS Pfad sehr spät geöffnet, wenn ein andere User die die gleiche Datei bereits geöffnet hat.

    Nimmt man dagegen den Server Freigabepfad \\server\freigabe, geht sie gleiche mit der entsprechenden Meldung zur Bearbeitung auf.

    Kann man das beheben?

    Dienstag, 16. April 2013 13:30

Antworten

  • hallo, anscheinend hatt das System meine letzte Antwort nicht übernommen!

    Also nochmal zum Feedback,

    ich hatte auf 2 Clients und dem Fileserver die Einträge im "NetCache" Key vorgenommen (auf dem Server musste der Key erst noch erstellt werden), es brachte aber keine Änderung bei Öffnungsverhalten.

    Ich habe später testweise einen Fileserver installiert, und mit gleicher DFS Konfig eingerichtet. Es gab kein Problem beim Öffnen, bis ich den Virenscanner installiert habe! Hier lag letztendlich das Problem. Also immer wenn man als Zweiter eine PPTX, DOCX usw. öffnete, kam es anschließend zu dieser Verzögerung, bei den alten (nicht XML) Dateien nicht!

    Vielleicht hilft es ja Jemanden weiter.

    Gruß

    Dienstag, 14. Mai 2013 12:58

Alle Antworten

  • Hallo,

    Das sind sehr spärliche Informationen!

    worüber sprechen wir genau? DFS-N oder DFS-R oder beides?

    Ich lese etwas, von Meldung zur Bearbeitung und andere User mit gleicher Datei.....

    DFS-R hat keine File-Lock Mechanismen, hier bitte  Branche Cache nutzen.

    Viele Grüße

    Philipp Halbedel

    Dienstag, 16. April 2013 14:20
  • sorry, dass musste Gestern noch schnell geschrieben werden, da ich weg musste.

    hier mal ein paar genauere Infos:

    1Gb LAN

    Clients Win7 64bit mit Office 2010

    Fileserver MS Server 2008 R2

    Freigabe DFS Namespace mit Namespace Servern in 3 Standorten (der Betreffende Ordner ist nicht Repliziert und wird am gleichen Standort geöffnet).

    Wenn also ein User am Standort des Fileservers z.B. eine PPTX aus dem DFS Ordner öffnet, öffnet sich diese in 2-3 Sekunden. Öffnet die gleiche Datei (am gleichen Standort) ein zweiter User, öffnet sich das Office Fenster mit dem Hinweis "download" und der Prozentangabe "0%", bis nach ca. 30-40 Sekunden der Hinweis zum schreibgeschützten Öffnen oder Abbrechen kommt (die Prozentanzeige ändert sich in diesem Zeitraum nicht). Wählt man dann "öffnen" öffnet sich das Dokument sofort.

    Öffnet man die Datei als Zweiter über den Freigabepfad des Servers, kommt die Meldung zum schreibgeschützten Öffnen sofort, und das Dokument öffnet sich nach Auswahl auch sofort.

    Woher kommt also diese zeitliche Verzögerung bei Verwendugn des DFS Pfades (wenn man der Zweite User ist)?

    Gruß


    • Bearbeitet spectraler Mittwoch, 17. April 2013 05:55 Ergänzung
    Mittwoch, 17. April 2013 05:53
  • Erstelle bitte einen gleichzeitigen, beidseitigen Network-Trace sowohl auf dem betroffenen Windows 7 Client als auch auf dem beteiligten Files-Server(n) während das Problem auftritt nach folgendem Muster:

    Vorab: Beenden sämtlicher weiterer Programme auf dem betroffenen Client die nichts mit dem Problem zu tun haben jedoch ggf. zusätzlichen Netzwerk-Verkehr verursachen und so die Analyse unnötig erschweren.

    klist purge
    klist –li 0x3e7 purge
    ipconfig /flushdns
    NBTStat -R
    netsh trace start capture=yes
    ping -n 1 -l 111 8.8.8.8
    <repro command>
    ping -n 1 -l 222 8.8.8.8
    netsh trace stop

    Werte dann den jeweiligen Network-Trace aus wann und wo es zu dem Fehler kommt.

    Als Referenz kannst du einen 2. Network-Trace anlegen, bei dem das Problem nicht auftritt ("Nimmt man dagegen den Server Freigabepfad \\server\freigabe, geht sie gleiche mit der entsprechenden Meldung zur Bearbeitung auf").

    Jedoch immer obige Befehle vorher ausführen, so dass die Ausgangslage nahezu identisch ist.

    Weitere Informationen:

    Using Network Monitor to View ETL Files
    http://msdn.microsoft.com/en-us/library/windows/desktop/dd569143(v=vs.85).aspx

    Network Tracing in Windows 7
    http://msdn.microsoft.com/en-us/library/windows/desktop/dd569136(v=vs.85).aspx

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Mittwoch, 17. April 2013 06:52
  • hallo,

    ich glaube fast nicht das es an einem bestimmten Client liegt, da ich es an jedem beliebigen Client nachstellen kann. Es wird irgendwie am DFS liegen wo wir an 3 Standorten je einen Namenspaceserver haben, diese Ordnerziel gibt es aber nur an einem Standort.

    Ich werde es mal mit der vergleichenden Analyse probieren.

    Danke und Gruß

    Mittwoch, 17. April 2013 07:57
  • hallo,

    ich habe beim Testen noch festgestellt, dass der Effekt bei xxx.ppt Dateien nicht auftritt, nur bei xxx.pptx (also xml Format). Einen netsh Trace mit pptx habe ich gemacht, bin aber noch nicht zum Auswerten gekommen.

    Die Anzeigen der ETLs im MS NetMon3.4 sind für mich im Moment aber auch noch "nichts sagend", da ich die Art von Diagnose bis jetzt noch nie gebraucht habe.

    Gruß

    Dienstag, 23. April 2013 08:08
  • ich habe im Trace eine Stelle gefunden, an der es reproduzierbar immer genau zu 35 Sekunden Verzögerung kommt. Kann man hierzu schon was sagen?

    1315    12:41:38 24.04.2013    3.9238304    System    192.168.125.247    192.168.125.63    SMB2    SMB2:N   OPLOCK BREAK (0x12)     {SMBOverTCP:12, TCP:11, IPv4:10}
    1561    12:42:13 24.04.2013    38.9236230    System    192.168.125.247    192.168.125.63    SMB2    SMB2:R  - NT Status: System - Error, Code = (67) STATUS_SHARING_VIOLATION  CREATE (0x5) , File=IT_TEST.pptx@#1313     {SMB2:45, SMBOverTCP:12, TCP:11, IPv4:10}

    Mittwoch, 24. April 2013 12:18
  • 1. Apply all the following Hotfixes on both Windows Server 2008 R2 AND Windows 7 Clients

    List of currently available hotfixes for the File Services technologies in Windows Server 2008 and in Windows Server 2008 R2
    http://support.microsoft.com/kb/2473205

    2. Apply the following registry key on the File-Server and add e.g. "pptx" to the dafault values:

    This feature contains a list of file extensions that are excluded from this type behavior and can be located in the following registry key:

    HKLM\Software\Microsoft\Windows\CurrentVersion\NetCache\SparseExclusionList
    Registry Value Type: REG_SZ
    VARIANT Value Type: VT_BSTR
    Value Range: list of file extensions delimited by semicolons. i.e. "*.DAT; *.BOX; *.XYZ "
    Default Value: the default is as follows.
    "*.doc;*.xls;*.xlsx;*.ppt; *.vsd; *.tmp; *.pps; *.msi; *.mst; *.dot; *.opt; *.mpp; *.dts; *.vsmacros; *.mso; *.est; *.suo; *.msg;"

    Background Information:

    The SparseExclusionList setting affects the way that the CSC driver (Offline Files) works with opportunistic locks (OpLocks) on the server. Without going into a lot of detail, OpLocks are a way that a client computer and a server communicate about the sharing of a file on the server. 

    Clients can “request” an OpLock from the server when they open a file on that remote server. 
    As long as that OpLock remains valid, the client is free to service READs and WRITEs from a local cache, knowing that no other process is either reading from or writing to that file on the server. 

    Once the file is closed on the client, any changes may be flushed back to the server. 
    If another handle is opened (from the same or another client computer) the OpLock may be “broken”.
    That “OpLock break” notifies the holder of the OpLock that it must stop caching data locally and flush its changes to the server immediately.

    What makes this setting "SparseExclusionList"?

    Whenever the CSC driver(Offline Files) on the client is notified of an OpLock break, the default behavior is to send all local changes to the server and then mark the local copy “sparse” so that the CSC agent will then fill in the guaranteed-accurate contents from the server copy. 
    For some file types and their applications, this behavior is not desirable. 

    Note:
    If this value is set in the registry, shall contain the list of files that will be excluded from the sparse markup whenever it's "broken" an OpLock and replaces the list included by default.
    If you wish to include an extension to this list that comes by default, the registry value must contain the list by default with the new extension included. If it is to remove the registry key must include all entries that are present by default less the that if you want to delete.
    This functionality can be adjusted in the manner that is most convenient and it is recommended that tests be made before it is applied to all clients.

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Donnerstag, 25. April 2013 13:34
  • hallo, anscheinend hatt das System meine letzte Antwort nicht übernommen!

    Also nochmal zum Feedback,

    ich hatte auf 2 Clients und dem Fileserver die Einträge im "NetCache" Key vorgenommen (auf dem Server musste der Key erst noch erstellt werden), es brachte aber keine Änderung bei Öffnungsverhalten.

    Ich habe später testweise einen Fileserver installiert, und mit gleicher DFS Konfig eingerichtet. Es gab kein Problem beim Öffnen, bis ich den Virenscanner installiert habe! Hier lag letztendlich das Problem. Also immer wenn man als Zweiter eine PPTX, DOCX usw. öffnete, kam es anschließend zu dieser Verzögerung, bei den alten (nicht XML) Dateien nicht!

    Vielleicht hilft es ja Jemanden weiter.

    Gruß

    Dienstag, 14. Mai 2013 12:58