Understanding DFSR debug logging (Part 15: Pre-Seeded Data Usage during Initial Sync)
In this scenario we will see a new replication group and replicated folder created, where data has been pre-seeded (i.e. pre-staged) on both servers. This is a common scenario, where data has existed on a few servers and been kept in sync through other mechanisms than DFSR (such as robocopy). It’s also often used when building new DFSR servers in a depot to save initial sync time before deploying the server to the field.
(preseedupstream - Dfsr00012 - 2008.log and preseeddownstream - Dfsr00014 - 2008.log)
These are two Windows Server 2008 servers called 2008x86SRV10 and 2008x86SRV11 in the contoso.com domain. The logs are from 2008x86SRV10 where the file is created (upstream) and from 2008x86SRV11 where it is replicated (downstream). Both servers are participating in the SeededRG replication group for the PreseededRF replicated folder. The upstream server contains files ‘matched.dll’ (which has an identical file pre-seeded on the downstream) and ‘samenameonly.dll’ (which has the same name and path on the downstream but differs in its contents slightly). The downstream server also contains file ‘onlydownstream.dll’ which does not exist on the upstream and will be covered by pre-existing logic.
<Upstream> 20080910 16:22:24.423 2928 VLMG 1158 VolumeManager::Initialize Volume initialized. volId:\.C:
<Upstream> 20080910 16:22:24.423 3392 CSMG 2298 ContentSetManager::CheckContentSetState Content set csId:{7F8CFBB0-4973-4B53-AAD5-3328870036FB} state:InitialBuilding ß New replica set is being built
<Upstream> 20080910 16:22:24.501 3392 CSMG 3182 ContentSetManager::CreateRootRecord Adding root record csId:{7F8CFBB0-4973-4B53-AAD5-3328870036FB} csName:preseededrf ghosted:0
<Upstream> 20080910 16:22:24.517 3392 CSMG 3298 ContentSetManager::CreateRootRecord LDB Inserting ID Record: ß The DFSR database has a base record added for the new replica set.
+ fid 0x80000000000B3
+ usn 0x27f3650
+ uidVisible 1
+ filtered 0
+ journalWrapped 0
+ slowRecoverCheck 0
+ pendingTombstone 0
+ internalUpdate 0
+ dirtyShutdownMismatch 0
+ meetInstallUpdate 0
+ meetReanimated 0
+ recUpdateTime 16010101 00:00:00.000 GMT
+ present 1
+ nameConflict 0
+ attributes 0x10
+ ghostedHeader 0
+ data 0
+ gvsn {F96F1AF0-1F39-4EDB-8493-590B7A9E44EC}-v10
+ uid {7F8CFBB0-4973-4B53-AAD5-3328870036FB}-v1
+ parent {00000000-0000-0000-0000-000000000000}-v0
+ fence 16010101 00:00:00.000 P
+ clockDecrementedInDirtyShutdown 0
+ clock 20080910 19:14:41.883 GMT (0x1c913797a31f6a8)
+ createTime 20080910 17:14:04.242 GMT
+ csId {7F8CFBB0-4973-4B53-AAD5-3328870036FB}
+ hash 00000000-00000000-00000000-00000000
+ similarity 00000000-00000000-00000000-00000000
+ name preseededrf ß name of the replicated folder
+
<Upstream> 20080910 16:22:24.657 3392 LDBX 4028 Ldb::Insert Inserting contentSetRecord: ß The replicated folder record is add into the database
+ contentSetId: {7F8CFBB0-4973-4B53-AAD5-3328870036FB}
+ memberId: {D964421D-59F0-434C-8826-ED91D268B143}
+ state: InitialBuilding ß The RG is in an initial building state
+ startVersion: v9
+ authRebuilding: 0
+ stageVolumeSerialNumber: 0
+ stageFid: 0x0
+ isTombstone: 0
+ readOnlySince: 16010101 00:00:00.000
+ beingDeleted: 0
+ dbLossRecover: 0
+
<Upstream> 20080910 16:22:24.970 3392 STAG 2600 Staging::ScanStagingDirectory Staging space usage is: 0
<Upstream> 20080910 16:22:24.970 3392 STAG 6158 StagingManager::RegisterContentSetsOnPath {7F8CFBB0-4973-4B53-AAD5-3328870036FB} added to the replicated folder list.
<Upstream> 20080910 16:22:24.970 3392 LDBX 4062 Ldb::Update Updating contentSetRecord:
+ contentSetId: {7F8CFBB0-4973-4B53-AAD5-3328870036FB}
+ memberId: {D964421D-59F0-434C-8826-ED91D268B143}
+ state: InitialBuilding
+ startVersion: v9
+ authRebuilding: 0
+ stageVolumeSerialNumber: 48e8de48e8de33c2
+
Comments
- Anonymous
October 08, 2014
Understanding DFSR debug logging (Part 15: Pre-Seeded Data Usage during Initial Sync) - Ask the Directory Services Team - Site Home - TechNet Blogs