When working with DFS namespaces that have multiple referral targets (like our \\company.local\users
spanning UK and US servers), administrators often need to verify which physical server a client is actually accessing. Here's how to uncover this programmatically.
The most reliable tool is Microsoft's dfsutil
command-line utility. To check the active referral target:
dfsutil /view /attr \\company.local\users
This returns detailed metadata including the currently active target server. For scripting purposes, parse the "Referral" section in output.
For automation in modern environments, PowerShell provides better control:
$namespace = "\\company.local\users" $referral = (Get-DfsnFolderTarget -Path $namespace | Where-Object { $_.State -eq "Online" }).TargetPath Write-Host "Active referral: $referral"
Sometimes you need lower-level verification. Use net statistics
after accessing a file:
net statistics server | find "\\company.local"
The output will show active SMB connections including the physical server name.
When troubleshooting unexpected failovers like UK→US replication, check the DFS client cache:
dfsutil /pktflush dfsutil /spcflush
Then force fresh referral with dir \\company.local\users
before rechecking target.
Here's a complete PowerShell script that logs referral changes:
$logFile = "C:\DFS_monitor.log" $namespace = "\\company.local\users" $currentTarget = (Get-DfsnFolderTarget -Path $namespace | Where-Object { $_.State -eq "Online" }).TargetPath if (Test-Path $logFile) { $lastTarget = Get-Content $logFile | Select-Object -Last 1 if ($lastTarget -ne $currentTarget) { "$(Get-Date -Format 'yyyy-MM-dd HH:mm') - Referral changed from $lastTarget to $currentTarget" | Out-File $logFile -Append } } else { $currentTarget | Out-File $logFile }
When working with Distributed File System (DFS) namespaces like \\company.local\users that span multiple geographic locations, it's crucial to determine which physical server your session is actually connecting to. The referral process happens transparently to users, but sometimes you need visibility - especially during failover events.
Windows provides several tools to inspect DFS connections. The most powerful command-line approach combines dfsutil
with dir
commands:
dfsutil /view /verbose \\company.local\users :: Sample output showing referral targets :: Referral Entry: \\UK-SERVER\Users :: Referral Entry: \\US-SERVER\Users :: Active Target: \\UK-SERVER\Users (Site: LON)
For scriptable solutions, PowerShell's Get-DfsnFolderTarget
provides richer information:
$namespacePath = "\\company.local\users" $targets = Get-DfsnFolderTarget -Path $namespacePath foreach ($target in $targets) { $properties = @{ TargetPath = $target.TargetPath State = $target.State ReferralPriorityRank = $target.ReferralPriorityRank LastReferralTime = $target.LastReferralTime } New-Object PSObject -Property $properties }
When you need to see the actual network traffic during DFS resolution:
netsh trace start scenario=NetConnection capture=yes tracefile=C:\temp\DFStrace.etl :: Access your DFS path netsh trace stop
Analyze the trace file with Network Monitor or Message Analyzer to see the exact server IP responding to SMB requests.
Here's a complete script to log DFS resolution changes over time:
function Get-DFSActiveTarget { param ( [string]$NamespacePath ) $result = [PSCustomObject]@{ Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss" Namespace = $NamespacePath ActiveTarget = $null AllTargets = @() } try { $targets = Get-DfsnFolderTarget -Path $NamespacePath -ErrorAction Stop $result.AllTargets = $targets.TargetPath $connection = Get-SmbConnection -RemotePath $NamespacePath -ErrorAction SilentlyContinue if ($connection) { $result.ActiveTarget = $connection.ServerName } } catch { $result | Add-Member -NotePropertyName "Error" -NotePropertyValue $_.Exception.Message } return $result } :: Usage example Get-DFSActiveTarget -NamespacePath "\\company.local\users" | Export-Csv -Path "DFS_Monitoring.csv" -Append