Die Symptome der Probleme sind folgende: Beim Speichern von Office-Dateien aus Word, Excel oder PowerPoint (in diesem Fall Office 2010) auf ein Netzwerk-Share, das mit DFSR (Distributed File System Replication) repliziert wird, bekommt der User regelmäßig die Fehlermeldung: \\server\share\test.ppt is in use. Please try again later.
Auf dem Share wird dann beispielsweise eine test.ppt-Datei mit 0 Byte Größe angelegt. Das Speichern auf ein lokales Laufwerk und das anschließende Verschieben auf das Netzwerk-Share funktioniert genauso problemlos wie das Speichern aus anderen Applikationen, etwa Notepad.
Was ist passiert? Beim Speichern von Dateien aus Word, Excel oder PowerPoint wird zuerst eine .tmp-Datei mit einem zufälligen Namen erzeugt. In diese Datei werden dann die Informationen geschrieben, und zum Schluss wird diese Datei in den letztendlichen Dateinamen (test.ppt) umbenannt.
Nachdem die Informationen in die .tmp-Datei geschrieben wurden, schließt Office das Handle auf die Datei, bevor es erneut geöffnet wird, um zu prüfen, ob alles angekommen ist, und die Datei in ihren endgültigen Namen umbenannt wird.
Beim Versuch, erneut exklusiven Zugriff auf die .tmp-Datei zu bekommen, sieht man in Netzwerktraces, dass Office vom Fileserver erst ein STATUS_PENDING und nach einem erneuten Create Request kurz darauf ein STATUS_SHARING_VIOLATION erhält.
Da gleichzeitig zu den Netzwerktraces die Process Monitor Logs vom Fileserver eingesammelt wurden, konnte man erkennen, dass zum fraglichen Zeitpunkt die DFSR.EXE Zugriff auf die .tmp-Datei hat und somit zu der Sharing Violation führt.
Zuerst war unklar, was DFSR mit der .tmp-Datei anstellt, da doch .tmp-Dateien, genauso wie Dateien mit der Endung .bak oder mit einer ~ am Anfang des Dateinamens, per Default von der Replication ausgeschlossen sind.
Nach einer Prüfung des File-Filters zeigte sich jedoch, dass für den fraglichen Replicated Folder (Properties) die Exclusion List bis auf ein Komma leer war. Anmerkung am Rande: Steht ein Komma (,) in der Exclusion List der Replicated Folder Properties, ist nichts ausgeschlossen. Wird auch das Komma herausgenommen, greift wieder der Default-File-Filter " ~*, *.bak, *.tmp", wie auch unter "Example" angegeben)
Notepad und andere Applikationen sind nicht betroffen, da diese die Datei ohne Verwendung von .tmp-Dateien direkt auf das Share schreiben. Wenn "*.tmp" wieder zur Exclusion List hinzugefügt wird, sind die Speicherprobleme gelöst.
File Exlcusion List
Ebenso ist es natürlich sinnvoll, Dateien, die mit "~" beginnen, auszuschließen. Office schreibt in einer sogenannten "Owner-Datei" mit einem "~" am Anfang den Namen des aktuellen Bearbeiters, damit andere Bearbeiter informiert werden können, wer die Datei aktuell gerade im Zugriff hält.
Diese "Owner-Dateien" auf einen anderen Server zu replizieren ergibt wohl meistens wenig Sinn. Also auch hier gilt: Im Zweifelsfall ist die Default-Einstellung zu belassen eine gute Idee.
Foto: Microsoft TechNet
Noch eine Anmerkung zum Schluss: Es gibt natürlich auch andere Ursachen, die zu einer Sharing Violation und somit zu den oben beschriebenen Symptomen führen können, zum Beispiel der zeitgleiche exklusive Zugriff von zwei Clients auf dieselbe Datei.
Um solchen Problemen auf die Schliche zu kommen, empfiehlt es sich, Netzwerktraces auf dem File-Server aufzuzeichnen, und wenn sich herausstellt, dass die Sharing Violation lokal auf dem Files-Srver entsteht (also nicht durch eine andere Maschine im Netzwerk), sind zusätzliche Process Monitor Logs eine gute Maßnahme zu prüfen, welcher Prozess was mit der Datei anstellt. In beiden Fällen kann man über den Dateinamen (test.ppt) sehr schnell an die interessanten Stellen springen. Aus dem Netzwerktrace sieht man dann, welche .tmp-Datei der Client erzeugt hat, und kann diese im Process Monitor Log genauer begutachten. (mje)
Dieser Artikel basiert unter anderem auf einem Blog-Beitrag aus dem Aktives Verzeichnis Blog auf Microsofts TechNet.