DFS - Ganze Ordner in ConflicrAndDeleted obwohl Replikation deaktiviert ist

[speedcOre]

Hallo allerseits,

merkwürdige Nummer in der Firma.
Wir betreiben ein DFS mit einem 2008R2 und einem 2012R2. Das Hauptziel des ganzen soll jedoch die Replikation sein, nicht der DFS in seiner eigentlichen Funktion. Deshalb greifen viele Nutzer auch nach wie vor über die direkte IP des Hauptservers auf die Netzlaufwerke zu.

Nun häuften sich zuletzt die Kuriositäten im Zusammenhang mit dem DFS(-R): ständig landeten Dateien und Ordner im ConflictAndDeleted-Ordner, weshalb ich, da ja ohnehin alle auf Server A arbeiten, die Replikation per Zeitplan auf Nachts gelegt habe und das Netzlaufwerk direkt per IP zugewiesen habe, so dass ich sicher gehe, dass keine Datenmissstände bestehen. Repliziert wird nun also nur noch nachts, und quasi nur für den Fall, dass Server A mal hardwaretechnisch abraucht und nicht zeitnah genug in Betrieb genommen werden kann.
Das kann man technisch finden, wie man will; es soll nun aber um folgendes gehen:

Soeben verschwand ein ganzer, etwa 4GB großer Unterordner des Netzlaufwerks. Die Ereignisanzeigen der Dateidienste beider Server spuckten nichts aus.
Ich fand den gelöschten Ordner im ConflictAndDeleted - Ordner wieder, wo auch - laut DFS-Verwaltung - "gelöschte Dateien" landen (Auf der Seite, die das Kontingent des ConflictAndDeleted-Ordners angibt ist das Häkchen gesetzt bei "Gelöschte Dateien hierhin verschieben").

Da die Replikation nachts nicht läuft, gehe ich aktuell von einer händischen Löschung aus. Gebt ihr mir da recht? Oder kann es andere Gründe geben?

In dem Zusammenhang würde sich natürlich die Frage stellen, ob/inwiefern man irgendwie nachvollziehen kann, wer die Dinge ggf. gelöscht hat. Und wenn nicht mit Bordmitteln, ob man das für die Zukunft einstellen kann.

Über Eure Hilfe würde ich mich SEHR freuen!

Beste Grüße und VIELEN DANK im Voraus!

 

[ntloader]

Wenn du kein Auditing für den Share eingerichtet hast, kannst du im nachhinein nicht feststellen, wer da etwas gelöscht hat oder nicht.

 

[speedcOre]

Hallo,

danke für die schnelle Reaktion!

Zwei Fragen:

--> Denkst Du auch, dass es händisch gelöscht worden sein muss, wenn aktuell nicht repliziert wird? (Außer SYSVOL, da beides DCs sind)

--> Habe ich eingerichtet - ich muss doch "nur" das Auditing aktivieren, indem ich die relevante Sicherheitsgruppe (in diesem Falle Domain\Benutzer) einfüge und die Häkchen bei "Löschen" setze, so dass er Erfolg wie auch Misserfolg protokolliert; anschließend als GPO festlegen, dass er es tatsächlich auf allen Domänen-PCs protokolliert - richtig? Dann wird es mir am DC angezeigt? Oder habe ich was vergessen?


Beste Grüße

 

[ntloader]

DFSR schreibt Logfiles nach c:\Windows\Debug. Such in den Logfiles nach dem Ordnernamen, dann siehst du ob der DFSR Service den Ordner gelöscht hat. Wenn nicht wars ein Nutzer.
Nein das hast du fasch verstanden. Das muss man nur auf Serverseite einstellen. Da muss da Auditing aber generell erst aktiviert werden.
Siehe:
https://technet.microsoft.com/en-us/library/cc771070.aspx
http://blogs.technet.com/b/mspfe/archive/2013/08/27/auditing-file-access-on-file-servers.aspx (etwas komplexer)

Eure DFS Strategie scheint mir zudem etwas fragwürdig zu sein. Vielleicht überdenkst du das besser nochmal (das ist nicht böse gemeint).

 

[speedcOre]

Habe nun die Verbindungen erst einmal deaktiviert. Mal schauen, wie es weiter geht. Dies funktioniert im Gegensatz zu der Definition eines Zeitplans wenigstens.

Das mit der DFS-Strategie mag stimmen - nehme ich Dir nicht übel. War seinerzeit ein Schnellschuss, und so etwas zurück zu rüsten überlegt man natürlich eher fünf als ein Mal ;-)


Beste Grüße