NTFRS Morphed Folder ohne Original durch Löschen und Neuerstellen von Verzeichnissen
Hallo, hier mal wieder euer Rol. Diesmal mit einem NTFRS Thema.
FRS ist zwar schon totgesagt, aber bis zum endgültigen Ersetzen durch DFSR wird ja doch noch einige Zeit ins Land gehen. Daher bleibt auch auf weiteres der richtige Umgang mit dem Datei Replikations Dienst ein Thema - gerade dann, wenn SYSVOL damit repliziert wird und jegliche Störung ganz empfindliche Konsequenzen für die Domänen Clients hat.
Der ein oder andere mag ja schon einmal ein NTFRS Morphed Folder gesehen haben. Es handelt sich dabei um Order mit Namen wie “Policies_NTFRS_72a2c00f”. Meistens gibt es parallel zu diesem Folder dann jedoch einen mit dem original Namen, also “Policies”. Das hat dann noch keine so gravierenden Auswirkungen auf Clients. Dazu gibt es auch einen Artikel mit dem Vorgehen zur Bereinigung:
328492 Folder name is changed to "FolderName_NTFRS_<xxxxxxxx>"
https://support.microsoft.com/default.aspx?scid=kb;EN-US;328492
Doch was mag passiert sein, wenn es nun kein Original mehr gibt? Für Clients ist das jedenfalls fatal.
In diesem Fall kann folgendes geschehen sein. Der Ordner wird auf dem Upstream (NTFRS Member auf dem die Änderung passiert) gelöscht und wieder neu angelegt. Auf dem Downstream (NTFRS Member welcher die Änderung erhalten soll) kann die Löschung jedoch nicht umgesetzt werden, da durch einen permanenten Zugriff auf eine Datei innerhalb der Verzeichnisstruktur ein Lock besteht. Da die Neuerstellung des gleichnamigen Verzeichnisses nun aber auch repliziert werden muß, bleibt NTFRS nichts anderes übrig, als den neuen Ordnerzu “morphen” – spricht mit dem oben beschriebenen generischen Namen zu versehen. Die Namensänderung wird nun auch wieder an den ursprünglichen Upstream repliziert. NTFRS versucht weiter die Löschung umzusetzen, was irgendwann (sobald das Lock verschwunden ist) auch möglich ist. Was also übrig bleibt ist dann der Morphed Folder, jedoch ohne original Verzeichnis – mit den entsprechenden Auswirkungen auf die Clients.
Um das näher zu untersuchen, kann man sich das sogenannte NTFRS Outlog ansehen. Die zugehörigen Debug Logs sind meistens schon überschreiben. Das NTFRS Outlog erhält man über:
C:\> NTFRSUTL OUTLOG >Outlog.txt
Zum Outlog von Upstream Member RWVSM2 nun ein Beispiel, bei dem das Verzeichnis Test1 gelöscht, sowie neu erstellt wird und durch den NTFRS Downstream Partner RWVSM1 “gemorphed” wird, da es dort ein File Lock in der Verzeichnisstruktur gibt, welches die Löschung verhindert:
1) altes Directory Test1 wird gelöscht, auf Upstream Member RWVSM2 (OriginatorGuid 60fd3eda-88e0-4da1-a4ceb38e90fdd01c)
Table Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber : 00028e1e
Flags : 00000028 Flags [Locn LclCo ] <- lokale Änderung (Local Changeorder)
IFlags : 00000001 Flags [IFlagVVRetireExec ]
State : 00000014 CO STATE: IBCO_OUTBOUND_REQUEST
ContentCmd : 00000000 Flags [<Flags Clear>]
Lcmd : 00000003 D/F 1 Delete <- Löschung
FileAttributes : 00000010 Flags [DIRECTORY ]
FileVersionNumber : 00000002
PartnerAckSeqNumber : 00000000
FileSize : 00000000 00000000
FileOffset : 00000000 00000000
FrsVsn : 01c9bda7 456e07bd
FileUsn : 00000000 2e4460f0
JrnlUsn : 00000000 2e4460f0
JrnlFirstUsn : 00000000 2e4460f0
OriginalReplica : 1 [???]
NewReplica : 1 [???]
ChangeOrderGuid : 4b4884b4-254e-4544-b782eb6540010381
OriginatorGuid : 60fd3eda-88e0-4da1-a4ceb38e90fdd01c <- GUID des NTFRS Members RWVSM2, der die Änderung einführt
FileGuid : b2f62e58-f7fd-4b80-abb24a5cc03539d6
OldParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid : 45beeef3-0863-4097-8d45ec951e3522d4
Spare1Ull :
MD5CheckSum : MD5: 00000000 00000000 00000000 00000000
RetryCount : 0
FirstTryTime : Fri Jun 5, 2009 16:55:32
EventTime : Fri Jun 5, 2009 16:55:31
FileNameLength : 10
FileName : Test1 <- Name das Verzeichnisses
Cxtion Name : <Jrnl Cxtion> <- <Jrnl Cxtion>\<Jrnl Cxtion>
Cxtion State : Joined
2) neues Verzeichnis Test1 wird auf RWVSM2 angelegt/umbenannt, neue FileGuid 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef
Table Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber : 00028e1f
Flags : 01000028 Flags [Locn LclCo CmpresStage ]
IFlags : 00000001 Flags [IFlagVVRetireExec ]
State : 00000014 CO STATE: IBCO_OUTBOUND_REQUEST
ContentCmd : 00000000 Flags [<Flags Clear>]
Lcmd : 00000001 D/F 1 Create <- ErstellungFileAttributes : 00000010 Flags [DIRECTORY ]
FileVersionNumber : 00000000
PartnerAckSeqNumber : 00000000
FileSize : 00000000 00000000
FileOffset : 00000000 00000000
FrsVsn : 01c9bda7 456e07be
FileUsn : 00000000 2e446300
JrnlUsn : 00000000 2e446138
JrnlFirstUsn : 00000000 2e446138
OriginalReplica : 1 [???]
NewReplica : 1 [???]
ChangeOrderGuid : cda323dd-7a7b-47c0-a882cdc587fb138b
OriginatorGuid : 60fd3eda-88e0-4da1-a4ceb38e90fdd01c FileGuid : 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef <- neue File GUIDOldParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid : 45beeef3-0863-4097-8d45ec951e3522d4
Spare1Ull :
MD5CheckSum : MD5: 142e4db1 eee3922a 94c8e76c 9e126531
RetryCount : 0
FirstTryTime : Fri Jun 5, 2009 16:55:38
EventTime : Fri Jun 5, 2009 16:55:34
FileNameLength : 20
FileName : New Folder Cxtion Name : <Jrnl Cxtion> <- <Jrnl Cxtion>\<Jrnl Cxtion>
Cxtion State : JoinedTable Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber : 00028e20
Flags : 01000024 Flags [Content LclCo CmpresStage ]
IFlags : 00000001 Flags [IFlagVVRetireExec ]
State : 00000014 CO STATE: IBCO_OUTBOUND_REQUEST
ContentCmd : 00002000 Flags [RenNew ] <- Umbenennung in den endgültigen NamenLcmd : 0000000f D/F 1 NoCmd
FileAttributes : 00000010 Flags [DIRECTORY ]
FileVersionNumber : 00000001
PartnerAckSeqNumber : 00000000
FileSize : 00000000 00000000
FileOffset : 00000000 00000000
FrsVsn : 01c9bda7 456e07bf
FileUsn : 00000000 2e446270
JrnlUsn : 00000000 2e446270
JrnlFirstUsn : 00000000 2e446270
OriginalReplica : 1 [???]
NewReplica : 1 [???]
ChangeOrderGuid : 9ad45a1f-6419-46bb-a21fc255b5985f98
OriginatorGuid : 60fd3eda-88e0-4da1-a4ceb38e90fdd01c
FileGuid : 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef OldParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid : 45beeef3-0863-4097-8d45ec951e3522d4
Spare1Ull :
MD5CheckSum : MD5: 142e4db1 eee3922a 94c8e76c 9e126531
RetryCount : 0
FirstTryTime : Fri Jun 5, 2009 16:55:40
EventTime : Fri Jun 5, 2009 16:55:37
FileNameLength : 10
FileName : Test1 Cxtion Name : <Jrnl Cxtion> <- <Jrnl Cxtion>\<Jrnl Cxtion>
Cxtion State : Joined
3) während der NTFRS Replikation konnte jedoch auf dem Downstream RWVSM1 durch ein File Lock das alte Verzeichnis nicht gelöscht werden, es kommt zum Morphed Folder als Änderung durch RWVSM1 (remote OriginatorGuid 0fff42a5-d0d5-4fb6-aacd854ea225f0c4)
Table Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber : 00028e21
Flags : 03100204 Flags [Content OofOrd SkipOrigChk CmpresStage SkipVVUpdt ] <- keine lokale Änderung, also remote
IFlags : 00000001 Flags [IFlagVVRetireExec ]
State : 00000014 CO STATE: IBCO_OUTBOUND_REQUEST
ContentCmd : 00002000 Flags [RenNew ] <- Umbenennung
Lcmd : 0000000f D/F 1 NoCmd
FileAttributes : 00000010 Flags [DIRECTORY ]
FileVersionNumber : 00000002
PartnerAckSeqNumber : 00001d6c
FileSize : 00000000 00000000
FileOffset : 00000000 00000000
FrsVsn : 01c9c739 e01ec252
FileUsn : 00000000 2e447380
JrnlUsn : 00000000 00000000
JrnlFirstUsn : 00000000 00000000
OriginalReplica : 1 [???]
NewReplica : 1 [???]
ChangeOrderGuid : e294e5b4-2494-4b72-b2060aea700510b7
OriginatorGuid : 0fff42a5-d0d5-4fb6-aacd854ea225f0c4 <- Änderung durch remote Partner RWVSM1
FileGuid : 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef <- File GUID des neu erstellten Verzeichnisses
OldParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid : d6946061-6730-4734-a80b1c62fa2677bd
Spare1Ull : Tue Dec 9, 2008 14:59:37
MD5CheckSum : MD5: 142e4db1 eee3922a 94c8e76c 9e126531
RetryCount : 0
FirstTryTime : Fri Jun 5, 2009 16:55:44
EventTime : Fri Jun 5, 2009 16:55:39
FileNameLength : 40
FileName : Test1_NTFRS_c88de319 <- Name des Morphed Folders
Cxtion Name : D6267BD6-398D-4FCB-9743-6131CAFBF257 <- RWVSM1\RWR2DOM\RWVSM1$ <- Verbindung der Replikation
Cxtion State : Joined
Das Verhalten entspricht der NTFRS Conflict Resolution und ist, so komisch es auch klingen mag, By Design. Es mag zwar nur im Zusammenhang mit gesperrten Dateien auftreten ist jedoch nicht unwahrscheinlich. Daher ist es von Microsoft nicht empfohlen, z.B. beim Restoren von Policies, replizierte Ordner zu löschen und wieder neu anzulegen.
Man kann zwar versuchen, den NTFRS Einfluß gesperrter Dateien zu reduzieren, wie es beschrieben ist in
816493 How to configure the File Replication Service to allow fewer sharing violations that block replication
https://support.microsoft.com/default.aspx?scid=kb;EN-US;816493
aber das ist keine Garantie, daß keine solchen Verhalten auftreten. Zur Bereinigung kann man dann wieder auf den Eingangs erwähnten Artikel 328492 zurückgreifen und den Morphed Folder in den Originalnamen umbenennen.
Damit zeigt sich letztendlich wieder, wie vorsichtig man im Umgang mit NTFRS sein muß, um Probleme zu vermeiden und bestimmte Prozeduren ausgiebig testen sollte bevor man sie in der Produktion einsetzt.
Wer sich noch weiter in NTFRS vertiefen mag, findet sehr gute Informationen dazu im Whitepaper
How FRS works
https://technet.microsoft.com/en-us/library/cc962202.aspx
In diesem Sinne, weiter gutes Gelingen!
Euer Rol