DFSR - Entfernen von TMP Dateien aus der Exclusion List kann zu Problemen beim Speichern von Office Dokumenten fuehren

Hallo, hier mal wieder Hubert mit seinem zweiten Gastbeitrag aus dem Netzwerk Team.

Ich möchte heute von einigen Erkenntnissen berichten, die wir im Rahmen einer Kundenanfrage in Zusammenarbeit mit den Kollegen vom Domain- und Office Team erarbeiten konnten.

Die Symptome sind wie folgt:
Beim Speichern von Office Dateien aus Word, Excel oder Powerpoint (in diesem Fall Office 2010) auf ein Netzwerk Share, dass mit DFSR Repliziert wird bekommt der User regelmäßig eine Fehlermeldung:
„ \\server\share\test.ppt is in use. Please try again later“
Auf dem Share wird dann eine test.ppt mit 0 Byte Größe angelegt.
Speichern auf ein lokales Laufwerk und anschließendes Verschieben auf das Netzwerkshare funktioniert problemlos genauso wie das Speichern aus anderen Applikationen wie 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.
Bei dem 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 wir gleichzeitig zu den Netzwerktraces Process Monitor Logs vom Fileserver eingesammelt haben, konnten wir dort sehen, dass zum fraglichen Zeitpunkt die DFSR.EXE ihre Griffel auf der .tmp Datei hat, und somit zu der Sharing Violation führt.

Zuerst war uns 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.

Nachdem „*.tmp“ wieder zur Exclusion List hinzugefügt wurde, waren die Speicher Probleme gelöst:

Ebenso macht es natürlich Sinn, 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 macht wohl meistens wenig Sinn.
Also auch hier gilt: Im Zweifelsfall ist die Default-Einstellung zu belassen, eine gute Idee.

Noch eine Anmerkung zum Schluss:
Es gibt natürlich auch anderen Gründe, die zu einer Sharing Violation und somit zu den oben beschriebenen Symptomen führen können. Hierzu zählt zum Beispiel auch der zeitgleiche exklusive Zugriff von zwei Clients auf die selbe Datei.
Um solchen Problemen auf die Schliche zu kommen empfiehlt es sich, Netzwerktraces auf dem Fileserver aufzuzeichnen, und wenn sich herausstellt, dass die Sharing Violation lokal auf dem Fileserver entsteht (also nicht durch eine andere Maschine im Netzwerk) sind zusätzliche Process Monitor Logs eine gute Maßnahme um zu schauen, 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 sich diese im Process Monitor Log genauer anschauen.

Euer Hubert