Das Problem des widerspenstigen Ordners

Die Ausgangssituation stellte sich zunächst trivial dar: Es gab ein Servicedesk-Ticket, dass auf Server X auf der Freigabe der Ordner Y komplett zu löschen sei. Mein Kollege verband sich mit Administrationsrechten mit Server X, löschte Ordner Y und beendete das Ticket.

Kurze Zeit später meldete sich der Benutzer wieder und meldete, dass Ordner Y noch vorhanden sei. Da auf diesem Datenträger „Volume Shadow Copy“ (= Vorgängerversionen) aktiv ist, dachte der Kollege an ein Zurückspielen der Daten durch Dritte. Er verband sich wieder auf den Server, aber Ordner Y war weder in dem Verzeichnis noch in den Vorgängerversionen zu finden. Damit entfiel auch die Möglichkeit, den Ordner zurückzuspielen und dann komplett zu löschen. Ein Benutzer-Wechsel zu einem Domänen-Administratoren-Konto zeigte keinen Unterschied. Er öffnete anschließend eine Remotesitzung auf den Client Rechner und Ordner Y war da zu sehen.

Die Versuche, den Ordner über die GUI vom Client Rechner zu löschen oder umzubenennen schlugen fehl. Stets gab es die Fehlermeldung „Dieser Vorgang kann nur ausgeführt werden, wenn Sie eine Verbindung mit dem Netzwerk hergestellt haben.“

Bei Betrachtung der Ordner-Eigenschaften fehlte auch noch der Reiter „Sicherheit“.

Da uns in der letzten Zeit immer dann die PowerShell aus der Klemme geholfen hatte, wenn die anderen bekannten Methoden versagt hatten, probierte der Kollege dann erfolglos die PowerShell mit wechselnden Berechtigungen aus. Nach einigen Tagen landete das Ticket dann bei mir.

Da der Benutzer in den nächsten Tagen neue Hardware bekommen sollte, wollte ich das Problem von seinem neuen Rechner aus lösen. Dabei hoffte ich genug Zeit zu haben, um die Problematik in Ruhe zu untersuchen, ohne dass ich den Benutzer von seinem PC fernhalte. Ich meldete mich gemeinsam mit diesem Benutzer am Laptop an: Ordner Y war weg. Damit sollte das Problem am alten Rechner sein. Wenn man die paar Tage bis zur Auslieferung des Laptops noch abwarten würde, dann wäre das Thema durch ;-). Aber es versprach interessant zu werden.

Ich habe mich mit dem Benutzer in Verbindung gesetzt und trotz der Vorarbeit meines Kollegen alles noch einmal selbst überprüft und gleich ein paar Screenshots angefertigt. Aus Gewohnheit ließ ich den Process Monitor während eines Löschversuchs mitlaufen. Währenddessen befragte ich die dicke Tante aus Mountain View im Internet zu der Fehlermeldung. Die Ergebnisse waren ziemlich mager und trafen auf den ersten Blick nicht einmal annähernd zu. Also warf ich einen Blick in die Log-Datei des Process Monitors. Über „Tools – Count Occurrences…“ wurde auf Anzahl der Ergebnisbegriffe gefiltert. Da stach mit fünf Treffern das Ergebnis „0xC00002CC“ prominent heraus. Auch der angegebene Pfad in diesen Ergebnissen zeigte genau auf den zickigen Ordner.

Die Suchmaschine war nun etwas auskunftsfreudiger. Viele der Treffer beschäftigten sich mit fehlerhaften Offline-Dateien.

Offline-Dateien?

Für gewöhnlich schalte ich die Offline-Option bei der Erstellung der Freigaben ab, aber just in diesem Moment konnte ich mich nicht erinnern, ob ich diese Freigabe „anno Röhrendeckel“ überhaupt erzeugt hatte. Außerdem sind wir mit solchen Optionen und Informationen darüber den Benutzern gegenüber sehr sparsam. Ein kurzer Blick auf den Server bestätigte mir, dass Offline-Dateien auf der Freigabe aktiv waren. Bevor ich die Offline-Dateien am Server deaktiviere, wollte ich erst den Client-Cache löschen. Ich verband mich auf den Client-Rechner und deaktivierte im Sychronisationscenter die Offline-Dateien.

Nach einem erforderlichen Neustart war Ordner Y auf dem Client endlich weg. Mission erfüllt.

PS: Vermutlich hätte auch der KB-Artikel (https://support.microsoft.com/en-us/kb/942974) das gleiche Resultat erzielt, aber für mich was der Weg über das Sychronisationscenter der einfachere Weg.