An Alternative for DFSR Database GUID-to-Name Resolution

Recently I was connected to a support incident where a SYSVOL DFS Replication storm was causing trouble for a customer. Using the DFSR debug logs, the Microsoft support teams were able to identify that one file was being changed over and over again. The log entries were similar to -

+	fid                             0x5000000019841
+	usn                             0x10a7a560
+	uidVisible                      1
+	filtered                        0
+	journalWrapped                  0
+	slowRecoverCheck                0
+	pendingTombstone                0
+	internalUpdate                  0
+	dirtyShutdownMismatch           0
+	meetInstallUpdate               1
+	meetReanimated                  0
+	recUpdateTime                   16010101 00:00:00.000 GMT
+	present                         1
+	nameConflict                    0
+	attributes                      0x10
+	ghostedHeader                   0
+	data                            0
+	gvsn                            {A7088668-9068-4D1F-BEA5-520C67C94967}-v53
+	uid                             {A7088668-9068-4D1F-BEA5-520C67C94967}-v53
+	parent                          {A7088668-9068-4D1F-BEA5-520C67C94967}-v44
+	fence                           Default (3)
+	clockDecrementedInDirtyShutdown 0
+	clock                           20170503 00:17:08.328 GMT (0x1d2c3a29a04c7b7)
+	createTime                      20170503 00:17:08.328 GMT
+	csId                            {9A829445-BA96-4EDB-9033-D08C3D6B308A}
+	hash                            E5C76297-69747039-B2E8590E-FE3AB33E
+	similarity                      00000000-00000000-00000000-00000000
+	name                            SomeFolder

The standard approach for identifying the server on which the change originated is to extract the GUID from the gvsn (A7088668-9068-4D1F-BEA5-520C67C94967 in this case) and to use DfsrDiag.exe with its guid2name command -

C:\Windows\debug>DfsrDiag.exe guid2name /guid:A7088668-9068-4D1F-BEA5-520C67C94967 /rgname:"Domain System Volume"

   Object Type : DfsrVolumeInfo
   Computer    :
   Volume Guid : 37B3C300-0000-0000-0000-100000000000
   Volume Path : C:
   Volume SN   : 2864180062
   DB Guid     : A7088668-9068-4D1F-BEA5-520C67C94967

This is great except that for my customer, their environment has around 90 read-write DCs in a hub site with over 2000 read-only DCs in spoke sites. This DfsrDiag.exe command walks across every DC and in the heat of a high priority incident, this takes too long. All we really want to do is retrieve the DFSR database GUIDs from the 90 read-write DCs as these are the only servers where change could originate.

As it turns out, the DFSR database GUIDs are available via the DfsrVolumeInfo class. In response to the problem my customer was experiencing, I've written the following PowerShell script that retrieves a list of read-write DCs in the domain and then iterates over them to retrieve the DFSR database GUIDs on each server -

#Retrieve the list of read-write DCs
$rwDCs = (Get-ADDomain).ReplicaDirectoryServers

#Initialize the results array
$results = @()

#Iterate through the list of read-write DCs
foreach ($DC in $rwDCs)
    #Retrieve Dfsr Volume Information
    $volumes = $null
    $volumes = Get-WmiObject -Namespace "Root\MicrosoftDfs" -Class DfsrVolumeInfo -ComputerName $DC -ErrorAction SilentlyContinue

    #Extract the DC name and the Dfsr Db GUID for each Dfsr Volume
    #Add this information to the results array
    if ($volumes)
        foreach ($volume in $volumes)
            $result = "" | Select-Object DC,dbGUID
            $result.DC = $DC
            $result.dbGUID = $volume.DatabaseGuid
            $results += $result

#If the results array is populated, write it out to CSV 'dfsrDbGuids.csv'
if ($results)
    $results | Export-Csv -Path .\dfsrDbGuids.csv -NoTypeInformation

The output is a CSV with a name to GUID mapping.

You could very easily change this script to accept a list of servers as a parameter for scenarios where you're dealing with a replication group other than the SYSVOL replica.

Comments (2)

  1. Hi Mark,

    I would love to connect with you to discuss options for resolving issues inside our DFS-R landscape.
    Looking forward to hear from you.

    Best regards,
    Chris Visscher

    1. Mark Renoden says:

      Hi Chris

      I can try to assist at a high level. How would you like me to get in touch offline?



Skip to main content