Tipp fürs Active Directory und Microsoft Office

Probleme beim Speichern von Office-Dokumenten im Netzwerk beheben

Wenn Anwender beim Speichern von Office Dateien aus Word, Excel oder PowerPoint auf ein Netzwerk-Share, das mit DFSR Repliziert wird, regelmäßig Fehlermeldungen bekommen, kann folgender Tipp weiterhelfen.

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.