3

When have a DFSR "hub and spoke" setup for a replicated folder.

The permissions were set on the folder so no end users could modify the contents.

To my surprise, when running a health report on the hub, I found a few spokes had a single outbound file backlogged.

  1. When I check the backlog with dfsrdiag.exe for the spokes I see one apparently nameless file:

    F:\>dfsrdiag.exe backlog /ReceivingMember:dfsrhub /SendingMember:spoke123 /RGName:myRG /RFName:myRF

Member <dfsrhub> Backlog File Count: 1
Backlog File Names (first 1 files)
     1.

Operation Succeeded

  2. When checking dfsrdiag.exe ReplicationState I see no activity regarding the DFSR members in question.

  3. When I use the GetOutboundBacklogFileIdRecords() method of the DfsrReplicatedFolderInfo class against the DFSR members in question I get a little more info about the file they are trying to replicate back to the hub.

When executing GetOutboundBacklogFileIdRecords() this is what i get back:

IdRecordIndex : 1
BacklogIdRecords : {VersionVectorTombstone}

So it looks like it is trying to replicate the VersionVectorTombstone back to the hub. Could someone shed some light on what this "file" is that it is trying to replication back?

The FullPathName property of the BacklogIdRecords for the file is blank, but I would expect that because I'm assuming this is a special DFSR system file that might be located in the system volume information folder.

Improve this question

1 Answer 1

Reset to default
2

The versionvectortombstone is the way a particular dbguid is marked stale/present to be garbage collected from the database of peers.

When you retrieve the files outbound using the GetOutboundBacklogFileIdRecords() method, look at the UID of the DfsrIdRecordInfo object. It will be like {guid}-v2.

The {guid} is derived from logical AND of previous UID (which represents dbguid) and csID/replicatedfolderguid. If you do a logical AND of the current {guid} as reported in the UID with the replicatedfolderguid you will get the original dbguid back.

This will represent a real dbguid owned by some partner now or in the past. It may or may not be one in use. If its one in use look at the present value. If its zero then either the owner or another partner that knows that dbguid to be present will update the GVSN and sent the same "logical ANDED" {guid} back out with a present=1 later.

See "3.3.4.6.2 Processing Updates " in MS-FRS2 for details on "The UID of version vector tombstones".

http://msdn.microsoft.com/en-us/library/dd304935.aspx

Improve this answer
5
  • Thanks for the very helpful info, but may I ask for clarification? So what this essentially means is that the DBs on these servers is stale, they generated this file to denote they are ready to be garbage collected and I caught them before the version vectortombstone was replicated back to the hub? Also how exactly does DFSR do "garbage collection" I'm confused about that term in the context of DSFR. One more thing, is the versionvectortombstone an actual file? can I locate it somewhere and open it? thanks again.
    – red888
    Aug 12, 2013 at 13:03
  • 1
    No the versionvectortombstone is not a file. garbagecollection runs at midnight to keep the database clean of stale details. This includes database guids. The versionvectortombstone for a dbguid may sometimes get sent with present=0 when it really does exist. This may happen if a server (ServerB) hasn't spoken or heard of an update from ServerA for a while (ServerA was not a source of change for a long while). ServerA or ServerC can then resend another versionvectortombstone for the same dbguid as present=1 to cancel the previous attempt. You can ignore this in backlog as its harmless.
    – maweeras
    Aug 12, 2013 at 18:03
  • Makes sense in my case- this RF changes very rarely. If these are not files, is there a way to check what the present value is for them? Are they just objects in memory? Thanks.
    – red888
    Aug 12, 2013 at 18:15
  • 1
    You can enable level 5 verbosity and see the debug log entries as the records are processed. If you can dump all the idrecords (dfsridrecordinfo class) from the database then you may see entries for versionvectortombstone. But in my experience dumping the database for a select set of query results or the whole database will fail in large datasets due to wmi query quota thresholds. I appreciate, you may be interested in looking at this for educational reasons. But unless there is a problem to troubleshoot, I'd encourage the effort spent on learning what its like in a controlled lab instead.
    – maweeras
    Aug 12, 2013 at 20:51
  • Thanks for all of the awesome info. Could you look at my post regarding paging the dfsridrecordinfo class with the index property (stackoverflow.com/questions/18105685/…)? Also I found the The reason I'm seeing this in the backlog is because we have replication setup between 5:00PM and 11:00PM so if the versionvectortombstone is generated at around 12:00 it would be after the replication schedule has finished.
    – red888
    Aug 13, 2013 at 20:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .