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 : DC01.contoso.com
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
- Anonymous
May 24, 2017
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- Anonymous
May 24, 2017
The comment has been removed
- Anonymous