Helpdesk: "Since this morning, every user at the BR1 branch gets 'Windows cannot access \\corp.contoso.com\Shares\Finance' with 'Error code 0x80070035 The network path was not found.' on their F: drive. HQ users are fine, and \\BR-FS01\Finance opens by server name from the same branch PCs. Last night the network team re-addressed the branch to 10.40.30.0/24. A forum thread says to delete and recreate the namespace, run dfsutil /clean on the namespace servers, and put the domain controllers in every branch PC's hosts file. Can we do that tonight?"
Not yet. A DFS namespace path is a chain of referrals, and "not accessible" means one link in that chain didn't answer. Microsoft's access-failure article gives three places it breaks: "Failure to connect to a domain controller to obtain a DFSN namespace referral", "Failure to connect to a DFSN server", and "Failure of the DFSN server to provide a folder referral". Deleting and recreating the namespace touches none of them if the real break is a subnet that isn't in AD, a folder set to in-site referrals only, or a folder target that's offline. Work through it as a chain: the exact path, error, and who is affected → the client's referral cache: which referral came back, and which target is ACTIVE → connectivity to a DC and to each namespace server, by IP → name resolution for every server name in the referral → the namespace itself: root, root targets, folders, folder targets, and the DFS Namespace service → AD and the PDC emulator: are the namespace servers reading current metadata? → sites and referral ordering: which site does DFS think the client and each target are in? → the folder target's own share, permissions, and SMB settings → the management side, when DFS Management says "The namespace cannot be queried". dfsutil cache referral, dfsutil cache domain, net view by IP, Test-NetConnection, Resolve-DnsName, Get-DfsnRoot, Get-DfsnRootTarget, Get-DfsnFolderTarget, Get-DfsnServerConfiguration, dfsdiag, repadmin /showrepl, and Get-ADReplicationSubnet are the sources for that chain. Recreate a namespace for a branch whose subnet isn't in AD, and the branch still gets no referral the next morning.
This post covers DFS Namespaces (the \\domain\root\folder paths and their referrals), not DFS Replication. If the namespace hands out the right target but the files on two targets don't match, that's the replication layer, and DFS Replication Not Working covers it. If the namespace path lives in a drive map that never arrives, Group Policy Not Applying covers the GPO side. This post covers "a domain-based or stand-alone DFS namespace path (or one folder in it) is not accessible from some or all clients, or DFS Management reports 'The namespace cannot be queried', and you need a read-first path through the referral cache, DC and namespace server reach, name resolution, namespace configuration, AD metadata, sites, and the folder target before you delete, clean, or recreate anything."
TL;DR
- Read the client's referral cache before you flush it. Microsoft: "If you cannot find an entry for the desired namespace, this is evidence that the domain controller did not return a referral." An entry with no ACTIVE target means the client got the list but reached none of the servers on it.
-
Test servers by IP, without the share. Microsoft's test is
net viewagainst the IP alone, because with the namespace share in the path "you may unknowingly be referred to another DFS root server." - In-site referrals can hide a whole branch. Microsoft: "If no same-site targets exist, the client does not receive a referral and cannot access that portion of the namespace." A re-addressed subnet that isn't in AD Sites and Services puts a client in no site at all (our reading of the site-mapping text).
- Offline is a setting, not only an outage. Microsoft: "Clients do not receive referrals for a DFS namespace target that is offline."
- Changes start at the PDC emulator. Microsoft: "When an administrator makes a change to the domain-based namespace, the change is made on the Primary Domain Controller (PDC) emulator master." A PDC that namespace servers can't reach shows up as stale or missing referrals.
-
Don't clean before you export. Microsoft's cleanup steps "should only be used if recovery of the configuration data is not possible or is not desired." Export the namespace with
dfsutil root exportfirst.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Exact path, error code, affected users and sites, and what changed written down | "DFS is down" with nothing else |
| 2. Referral cache | The client holds a root referral and a folder referral, each with an ACTIVE target | No entry for the namespace, or no ACTIVE target |
| 3. Connectivity | The client reaches a DC and each namespace server by IP over SMB |
net view \\IP fails; TCP 445 blocked |
| 4. Name resolution | Every server name in the referral resolves to the right address | Works by FQDN, fails by short name (or the reverse) |
| 5. The namespace | Root, root targets, folder, and folder targets online; DFS Namespace service running | A target set offline; one root server with its service stopped |
| 6. AD and the PDC | Namespace servers read current metadata from the PDC emulator or a nearby DC | A change made an hour ago still isn't in the referrals |
| 7. Sites and ordering | The client and every target map to the right AD site | Branch users sent to HQ, or no referral at all |
| 8. The folder target | The target share and its permissions and SMB settings accept the client | Namespace path fails exactly like \\server\share fails |
| 9. Management side | DFS Management can query the namespace | "The namespace cannot be queried" plus a reason |
| 10. Change | Only after Steps 1-9 agree: one layer, one change | Recreated the namespace, branch still fails |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| The exact path the user opened |
\\corp.contoso.com\Shares, \\CONTOSO\Shares, and \\FS01\Shares take different referral paths. Note FQDN vs NetBIOS domain name |
| Root or one folder? | The root failing points at DCs and namespace servers. One folder failing points at that folder's targets and settings |
| The exact error text and code | 0x80070035 (network path not found) and 0x80070002 (cannot find) are both on Microsoft's list, with different likely layers (table below) |
| Who and where | One user, one PC, one site, VPN only, or everyone |
Does \\server\share work directly? |
If the folder target opens by server name, the file server and its permissions are probably fine and the referral layer is suspect |
| Client OS build | Windows 11 24H2 changed SMB signing defaults, which matters for third-party targets (Step 8) |
| What changed? | New subnet or re-addressing, a target added or removed, a namespace server retired, a DC moved, a firewall rule, a NAS firmware update |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| "Windows cannot access" the namespace path, 0x80070035 "The network path was not found" | Microsoft's Vista-and-later symptom for the three referral failures | Steps 2, 3 |
| Works at HQ, fails at one branch | Sites: no target in that site with in-site referrals on, or the client subnet isn't in AD | Steps 2, 7 |
| Root opens, one folder fails | That folder's targets: offline, unreachable, or excluded by site | Steps 5, 7, 8 |
Works by \\corp.contoso.com\..., fails by \\CONTOSO\... (or the reverse) |
Name resolution of the names in the referral | Step 4 |
| "Windows cannot find" the path, 0x80070002 "The system cannot find the file specified." | Microsoft lists it under namespace configuration-data problems | Steps 5, 6 |
| "is not accessible. You might not have permission to use this network resource." with "Configuration information could not be read from the domain controller" | Microsoft's older-client wording for the same referral failures | Steps 2, 3, 6 |
| A target was changed and some clients now get "Element not found" | A stale cached referral (a Microsoft Q&A community report) | Step 2 |
| Fails only to a NAS or non-Windows folder target, only on newer Windows 11 | SMB signing or guest access on the target | Step 8 |
| DFS Management shows "The namespace cannot be queried" | The management path: service, ports, PDC, registry. Users may be fine | Step 9 |
Step 2: Read the client's referral cache (read-only)
Reproduce the failure once on the affected PC, then read what the DFS client cached. dfsutil comes with the DFS Management Tools. Microsoft's install command for a client is Add-WindowsCapability -Name Rsat.FileServices.Tools~~~~0.0.1.0 -Online, which is a small install, not a read. If you'd rather not touch the PC, run the same reads from an admin workstation in the same subnet (our habit).
:: Read-only. Reproduce once, then read the referral cache and the domain cache
dir \\corp.contoso.com\Shares\Finance
dfsutil cache referral
dfsutil cache domain
Microsoft's KB 975440 uses the older dfsutil /pktinfo (referral cache, "also known as the PKT cache") and dfsutil /spcinfo (domain cache) forms. Current dfsutil has a cache parameter that "Displays or flushes the client cache." The mapping of cache referral / cache domain to the KB's switches is ours; dfsutil cache /? on your build shows the exact options. Microsoft's sample of a healthy referral cache, for a root with two targets and a folder (link) with one:
Entry: \contoso.com\dfsroot
ShortEntry: \contoso.com\dfsroot
Expires in 300 seconds
UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
0:[\ROOTSERVER1\dfsshare] State:0x119 ( ACTIVE )
1:[\ROOTSERVER2\dfsshare] State:0x09 ( )
Entry: \contoso.com\dfsroot\link
ShortEntry: \contoso.com\dfsroot\link
Expires in 1800 seconds
UseCount: 0 Type:0x1 ( DFS )
0:[\fileserver\data] State:0x131 ( ACTIVE )
| What the referral cache shows | What it means (Microsoft unless noted) | Next |
|---|---|---|
| No entry for the namespace | "If you cannot find an entry for the desired namespace, this is evidence that the domain controller did not return a referral." | Steps 3, 6 |
| A root entry, no target marked ACTIVE | "If not any of the namespace targets that are listed are designated as ACTIVE, that indicates that all targets were unreachable." | Steps 3, 4 |
| A root entry with an ACTIVE target, no entry for the folder | The root server didn't give out a folder referral, Microsoft's third cause (the pairing is our reading) | Steps 5, 7 |
| A folder entry, but every target listed is down or in the wrong site | The ordering or the site mapping, not the DC (our reading) | Steps 7, 8 |
| A folder entry whose ACTIVE target was removed from the namespace | A stale referral. Microsoft's defaults: root referrals "The default setting is 300 seconds (five minutes)." and folder referrals "The default setting is 1800 seconds (30 minutes)." | Wait it out, or Step 10 |
The domain cache answers the first link. Microsoft: "The entries that are marked by a plus sign (+) are the domain controllers that are currently used by the client." If the domain cache shows no DC for your domain, the client never got as far as the namespace. That's DC discovery, and nltest /dsgetdc:corp.contoso.com /force is the quick read before you go further (our addition).
A Microsoft Q&A thread reports cached domain-path entries that didn't expire after folder targets were changed, giving "Element Not Found" until the client restarted or the cache was flushed. That's a community report on Windows 10 and Server 2019, not a documented behavior, but it's a reason to read the cache before blaming the server.
If the cache doesn't settle it, Microsoft's guidance is a network capture on the client: filter tcp.port==445 and DFSC, because "The protocol is named DFSC by packet capture parsers." The client should send a DFS referral request and get a referral response. Microsoft: "If no DFS referral is being sent, and there's no indication of a firewall or anti-virus block, restart the DFS client to clear any DFS referral caching."
Step 3: Connectivity to a DC and to each namespace server (read-only)
Microsoft's first test is a plain SMB connection by IP address, so name resolution and referrals are out of the picture:
:: Read-only. The active DC from the domain cache, then each namespace server, by IP only (addresses are examples)
net view \\10.20.0.10
net view \\10.20.0.21
net view \\10.20.0.22
Microsoft: "A successful connection lists all shares that are hosted by the domain controller." For the namespace servers, it's specific about the form: "you must specify only the IP address of the server, and you must not include the namespace share". The reason: "Otherwise, you may unknowingly be referred to another DFS root server. If this occurs, you will receive misleading results."
Microsoft's port list for the DFS Namespaces service:
| Application protocol | Protocol | Port (Microsoft) |
|---|---|---|
| NetBIOS Datagram Service | UDP | 138 |
| NetBIOS Session Service | TCP | 139 |
| LDAP Server | TCP and UDP | 389 |
| SMB | TCP | 445 |
| RPC | TCP | 135 |
| Randomly allocated high TCP ports | TCP | 49152-65535 |
Microsoft's footnote on the first two rows: "The NETBIOS ports are optional and are not required when DFSN is using FQDN Server names."
# Read-only. TCP reachability from the client to a DC and to each namespace server (names are examples)
foreach ($server in 'DC01.corp.contoso.com', 'FS01.corp.contoso.com', 'FS02.corp.contoso.com') {
foreach ($port in 445, 389, 135) {
Test-NetConnection -ComputerName $server -Port $port -WarningAction SilentlyContinue |
Select-Object ComputerName, RemotePort, TcpTestSucceeded
}
}
Microsoft's Test-NetConnection page describes -Port as "the TCP port number on the remote computer," so this loop can't prove UDP 389. A working nltest /dsgetdc /force is the practical proof for the DC side (our reading).
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
net view \\DC-IP fails |
The client can't reach the DC that would give the root referral | Firewall or routing; Step 6 for the DC |
| DC works, one namespace server fails on 445 | That server is down, blocked, or its Server service is stopped | Step 5 for that root target |
| Every namespace server fails from one site only | A WAN or firewall change for that site | Network team, with Microsoft's port list |
| Everything answers by IP | Connectivity isn't the break | Steps 4-7 |
Microsoft's older "How DFS Works" reference (written for Windows Server 2003) describes the client sending its domain, DC, and root referral requests to the IPC$ share of a DC or root server "in the context of the LocalSystem account". So a rule or policy that treats the computer differently from the user can break referrals while the user's own access looks fine (our reading).
Step 4: Name resolution for every server in the referral (read-only)
Microsoft: "Clients must resolve the name of the DFS namespace and of any servers that are hosting the namespace." And: "By default, DFSN stores NetBIOS names for root servers." Read the names out of the Step 2 cache and resolve each one the way the client would:
# Read-only. Resolve the short and full names from the referral (FS01/FS02/BR-FS01 are examples)
foreach ($name in 'FS01', 'FS01.corp.contoso.com', 'FS02', 'BR-FS01', 'BR-FS01.corp.contoso.com') {
Resolve-DnsName -Name $name -ErrorAction SilentlyContinue | Select-Object @{ n = 'Asked'; e = { $name } }, Name, Type, IPAddress
}
:: Read-only. The NetBIOS name cache and the DNS resolver cache
nbtstat -c
ipconfig /displaydns
Microsoft's nbtstat reference: -c "Displays the contents of the NetBIOS name cache, the table of NetBIOS names and their resolved IP addresses." Then read how the namespace servers answer:
# Read-only. Does each namespace server hand out FQDN or NetBIOS names in referrals?
foreach ($s in 'FS01', 'FS02') { Get-DfsnServerConfiguration -ComputerName $s | Select-Object ComputerName, UseFqdn, EnableInsiteReferrals, EnableSiteCostedReferrals, SyncIntervalSec }
Microsoft on UseFqdn: "The default for DFS namespace servers is to use NetBIOS names in referrals." Its KB 244380 explains who that bites: "some clients don't use NetBIOS. Two examples are clients that aren't running Windows and clients that operate in an environment without WINS or that use DNS name suffixes." And: "In these cases, the client may be unable to resolve the server name that is returned from the root referral query."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Short name fails, FQDN resolves | No WINS and no DNS suffix that completes the short name | DNS suffix search list first; FQDN referrals in Step 10 |
| Short name resolves to an old or wrong address | A stale DNS or WINS record for a re-addressed server | Fix the record; ipconfig /displaydns shows what the client cached |
| Only VPN clients fail | The tunnel's DNS settings don't complete short names, or don't reach AD DNS | VPN DNS suffix and servers |
| Non-Windows clients fail, Windows clients work | Microsoft's KB 244380 case | FQDN referrals (Step 10) |
| Everything resolves correctly | Name resolution isn't the break | Steps 5-7 |
Step 5: The namespace itself (read-only)
Read the namespace, its root targets, the failing folder, and that folder's targets. Run these from a server with the DFS Management Tools; the names are examples:
# Read-only. Root settings, root targets, every folder, and the failing folder's targets
Get-DfsnRoot -Path '\\corp.contoso.com\Shares' | Format-List Path, Type, State, Flags, TimeToLiveSec
Get-DfsnRootTarget -Path '\\corp.contoso.com\Shares' | Select-Object TargetPath, State, ReferralPriorityClass, ReferralPriorityRank
Get-DfsnFolder -Path '\\corp.contoso.com\Shares\*' | Format-List
Get-DfsnFolderTarget -Path '\\corp.contoso.com\Shares\Finance' | Select-Object TargetPath, State, ReferralPriorityClass, ReferralPriorityRank
# Read-only. The DFS Namespace service on each namespace server and DC (WinRM; the remoting form is ours)
Invoke-Command -ComputerName FS01, FS02, DC01, DC02 -ScriptBlock { Get-Service -Name Dfs | Select-Object Name, Status, StartType }
The property names come from Microsoft's Get-DfsnRoot and Get-DfsnFolderTarget examples. KB 975440's first configuration check: "First, verify that the DFS service is started on all domain controllers and on DFS namespace/root servers." Then Microsoft's own namespace checks:
:: Read-only. Service and registry consistency across namespace servers, then metadata integrity, then the referral itself
dfsdiag /testdfsconfig /DFSroot:\\corp.contoso.com\Shares
dfsdiag /testdfsintegrity /DFSRoot:\\corp.contoso.com\Shares /recurse /full
dfsdiag /testreferral /DFSpath:\\corp.contoso.com\Shares\Finance
Microsoft's dfsdiag reference: /testdfsconfig "Verifies that the DFS registry configuration is consistent among namespace servers." /testdfsintegrity "Checks for DFS metadata corruption or inconsistencies between domain controllers." and "Detects overlapping DFS folders (links), duplicate folders, and folders with overlapping folder targets." For a folder path, /testreferral also validates "the site configuration for folder targets" and "the site association of the local host."
On each namespace server, read the root share and the registry entry that ties the server to the root:
# Read-only. The root share, its share permissions, and the root's registry entry (domain-based, Windows Server 2008 mode)
Get-SmbShare -Name Shares | Select-Object Name, Path, Description
Get-SmbShareAccess -Name Shares
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Dfs\Roots\domainV2\Shares' -ErrorAction SilentlyContinue | Select-Object LogicalShare, RootShare
Microsoft's recovery article says the shares named by the LogicalShare and RootShare values "must exist and be accessible for proper operation of a DFS root." And: "Access will be denied to a root if the share is missing or is configured with inappropriate permissions." Stand-alone roots live under Roots\Standalone instead, and Windows 2000 Server mode roots under Roots\Domain.
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
Root State is Offline |
Set a root to Offline and "the entire namespace becomes inaccessible." | Find out who set it and why; Step 10 |
A root target or folder target State is Offline |
"Clients do not receive referrals for a DFS namespace target that is offline." | Was it maintenance? Step 10 |
Dfs stopped on one namespace server |
That root target can't give referrals | Step 9 (the RPC rows) and Step 10 |
| Only one root target | Microsoft calls a single namespace server for a domain-based root "not recommended" | Plan a second one after the fix |
| Root share missing, or share permissions changed | Access to the root is denied | Restore the share before any namespace change |
No domainV2\Shares key on a root target |
That server doesn't know it hosts the root. DFS Management reports "Element not found" | Step 9 |
/testdfsintegrity reports overlapping or duplicate folders |
Metadata problem, not the client | Fix in DFS Management, one folder at a time |
Step 6: AD and the PDC emulator: is the metadata current? (read-only)
For a domain-based namespace, the configuration lives in AD. Microsoft: "When an administrator makes a change to the domain-based namespace, the change is made on the Primary Domain Controller (PDC) emulator master." And: "Domain controllers and DFS root servers periodically poll PDC for configuration information." With root scalability mode on, the root servers read from a nearby DC instead. Microsoft's description of that mode: it "reduces the load on the Primary Domain Controller (PDC) Emulator, but increases the time required for changes to the namespace to replicate to all namespace servers. Until changes replicate to all servers, users might have an inconsistent view of the namespace."
# Read-only. Who holds the PDC emulator role, and can each namespace server reach it on TCP 389/445?
$pdc = (Get-ADDomain -Identity corp.contoso.com).PDCEmulator
$pdc
Invoke-Command -ComputerName FS01, FS02 -ScriptBlock {
param($pdc)
foreach ($port in 389, 445) { Test-NetConnection -ComputerName $pdc -Port $port -WarningAction SilentlyContinue | Select-Object ComputerName, RemotePort, TcpTestSucceeded }
} -ArgumentList $pdc
# Read-only. The PDC emulator's own SRV record, which DFS Management looks up
Resolve-DnsName -Name '_ldap._tcp.pdc._msdcs.corp.contoso.com' -Type SRV -DnsOnly
:: Read-only. Microsoft's replication check from KB 975440, then dfsdiag's DC checks
repadmin /showrepl * DC=corp,DC=contoso,DC=com
dfsdiag /testdcs /domain:corp.contoso.com
Microsoft on the repadmin output: "Review the status and time of the last successful replication to make sure that DFSN configuration changes have reached all domain controllers." And dfsdiag /testdcs checks on each DC that the DFS Namespace service runs with an Automatic startup type, plus site-costed referral support for NETLOGON and SYSVOL. That DC check matters for more than file shares: Microsoft's port reference says "The DFSN service is required for Active Directory domain controllers to advertise the SYSVOL shared folder."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| Namespace servers can't reach the PDC emulator on 389 | They keep serving the metadata they last read, so recent changes never show up | Network path to the PDC; Step 9 rows for 389 |
repadmin shows inbound replication failures to some DCs |
Those DCs give clients root referrals from old metadata (Microsoft: replication failures "may prevent servers from issuing correct referrals") | Fix AD replication first |
| Root scalability on, recent change missing on some servers | Expected lag per Microsoft's text above | Wait, or confirm the DC those servers poll is current |
Dfs not Automatic or not running on a DC |
That DC can't hand out domain or root referrals | Step 10, on that DC |
| PDC SRV record missing | DFS Management fails with "The specified domain either does not exist or cannot be contacted" (Step 9) | Restart Netlogon on the PDC (Step 10) |
Two caches sit between a change and the client. Microsoft's older "How DFS Works" reference (Windows Server 2003 era) says domain controllers "store domain-based root referrals in a memory cache for 15 minutes", and that "Restarting the DFS service on the domain controller will cause this cache to be cleared." Then the client keeps its own copy for the TTL from Step 2. So a root target added at 9:00 may not reach every client until well after 9:15 (our arithmetic from those defaults).
Step 7: Sites and referral ordering (read-only)
This is the step the BR1 ticket lands on. Microsoft's ordering article: "Targets on the client's site are always listed first in a referral." Targets outside the site follow by the ordering method: random order, lowest cost, or exclude targets outside of the client's site. On that last one: "If no same-site targets exist, the client does not receive a referral and cannot access that portion of the namespace."
How DFS decides the sites, from KB 975440: "The DFSN service maps the client to a site by analyzing the source IP address of the client's referral request." And: "The DFS service also maps each root target server to a site by resolving the target server's name to an IP address." It names the failure directly: "One common scenario in which this occurs is a client that belongs to a site that contains no namespace or folder targets."
# Read-only. In-site and site-costing settings at every level: root, folder, and each namespace server
(Get-DfsnRoot -Path '\\corp.contoso.com\Shares').Flags
Get-DfsnFolder -Path '\\corp.contoso.com\Shares\Finance' | Format-List
foreach ($s in 'FS01', 'FS02') { Get-DfsnServerConfiguration -ComputerName $s | Select-Object ComputerName, EnableInsiteReferrals, EnableSiteCostedReferrals }
# Read-only. Is the client's new subnet in AD, and which site does each target's address map to?
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site, Location | Sort-Object Name
Resolve-DnsName -Name 'BR-FS01.corp.contoso.com' -Type A -DnsOnly
:: Read-only. The client's AD site, then Microsoft's site checks for the folder and the target server
nltest /dsgetsite
dfsdiag /testsites /DFSpath:\\corp.contoso.com\Shares\Finance /full
dfsdiag /testsites /machine:BR-FS01
Flags lists the settings that are on (Microsoft's example shows Site Costing). Set-DfsnRoot names the five: site costing, in-site referrals, access-based enumeration, root scalability, and target failback. In-site referrals can be on for the root, for one folder, or for a whole namespace server (with EnableInsiteReferrals on a server, "the server returns only referrals for targets in the same site as the client."), so read all three. dfsdiag /testsites "Checks the configuration of active directory Domain Services (AD DS) sites by verifying that servers that act as namespace servers or folder (link) targets have the same site associations on all domain controllers."
Microsoft's namespace client FAQ lists why clients go to unexpected targets. The ones that show up most:
| Cause from Microsoft's FAQ | What to read |
|---|---|
| "The client's IP address is not in a subnet that is defined in Active Directory and so DFS cannot obtain site information about the client." |
Get-ADReplicationSubnet vs the client's address; nltest /dsgetsite
|
| "The target's IP address is not in a subnet that is defined in Active Directory and so DFS cannot obtain site information about the target." | The target server's address vs the subnet list |
| A server or DC moved in Sites and Services while its IP "still maps to the subnet of the previous site" |
dfsdiag /testsites /machine: for that server |
| "The client is using a cached referral that has become outdated due to target change, site changes, or both." | Step 2 cache; the TTL |
| "Site information has changed, but the old site information is still cached on the root server or domain controller in the target site cache, client site cache, or site cost cache." | Time since the site change |
| NAT or WAN appliances that "change the source IP address of packets sent from a client computer to match the subnet of another site" | Whether the branch traffic is NATed on the way in |
On that cache row, the older "How DFS Works" reference puts the default site cost cache at up to 12 hours on DCs and root servers, so a site-link cost change can take that long to show (Windows Server 2003-era default; check before you rely on it).
Two more behaviors explain "it went to HQ and stayed there." Clients stick: after a failover, a client keeps using the target it's on when the referral refreshes. Microsoft's FAQ: "if a client fails over from a local server to a remove server (such as when the local server fails), the client will continue to access the remote server, even after the local server is restored." (Microsoft's typo: remove for remote.) Target failback changes that: with it on, Set-DfsnRoot says "once the first server becomes available again, the client fails back to the first server." And priority overrides ordering: ReferralPriorityClass takes GlobalHigh, SiteCostHigh, SiteCostNormal, SiteCostLow, or GlobalLow, and targets set to first or last among all targets "are still listed in the referral, even if the ordering method is set to Exclude targets outside of the client's site."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
nltest /dsgetsite empty or wrong on BR1 PCs; 10.40.30.0/24 not in the subnet list |
DFS can't place the client. With in-site on, Microsoft's text says no referral | Step 10: add the subnet to the right site |
| In-site on for the folder, no target in the client's site | Microsoft's "common scenario" | Add a same-site target, or turn in-site off for that folder |
| Branch users get the HQ target first | Branch target in the wrong site, or the branch target is down, or a priority class says so |
dfsdiag /testsites /machine:; the priority columns from Step 5 |
| Users stay on HQ after the branch server came back | Stickiness without failback | Target failback (Step 10) |
| Only after a site or subnet change | Cached site data on DCs and root servers | Time, or the DFS service restart on one server (Step 10) |
Step 8: The folder target itself (read-only)
Once the referral is right, the rest is plain SMB to the target. Microsoft's guidance page: "SMB troubleshooting applies to fixing the file server connection." Test the target by its own path, as the user, from the affected PC:
# Read-only. The folder target directly, then its share and NTFS permissions (run the last two on BR-FS01)
Test-Path -Path '\\BR-FS01\Finance'
Get-SmbShareAccess -Name Finance
(Get-Acl -Path 'D:\Shares\Finance').Access | Select-Object IdentityReference, FileSystemRights, AccessControlType
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
\\BR-FS01\Finance fails the same way |
The target, not the namespace (our reading) | SMB and file-server troubleshooting |
| Users see the folder but get access denied | Share or NTFS permissions on the target. DFS folder permissions don't grant access | Fix permissions on the target share |
| Users can open a folder they shouldn't see listed, or can't see one they can open | Access-based enumeration settings (below) | ABE, not permissions |
| A NAS or non-Windows target fails from Windows 11 24H2 with "The cryptographic signature is invalid." | Microsoft: "Windows 11, version 24H2 Enterprise, Pro, and Education require both outbound and inbound SMB signing." | Enable signing on the device |
| A NAS target fails with "You can't access this shared folder because your organization's security policies block unauthenticated guest access." | The device only offers guest access | Give the device real accounts |
| Two targets, users see different files | Replication between the targets, not referrals | The DFS Replication post |
On the two NAS rows, Microsoft's own caution: "We don't recommend disabling SMB signing as a workaround for third-party servers." And on guest logons: "We recommend that you don't enable insecure guest logons."
Access-based enumeration (ABE) is display, not security. Microsoft: "Access-based enumeration does not prevent users from getting a referral to a folder target if they already know the DFS path." And: "DFS folder permissions are used only for displaying or hiding DFS folders, not for controlling access, making Read access the only relevant permission at the DFS folder level." When ABE seems broken, check Microsoft's prerequisite first: "To enable access-based enumeration on a namespace, all namespace servers must be running Windows Server 2008 or newer. Additionally, domain-based namespaces must use the Windows Server 2008 mode." A namespace that's still in Windows 2000 Server mode (its registry key under Roots\Domain, not Roots\domainV2) can't hide folders until it's migrated. ABE on the namespace also doesn't hide files inside the target; for that, Microsoft says to "enable access-based enumeration on each shared folder by using Share and Storage Management." Read the folder's view permissions with Get-DfsnAccess -Path '\\corp.contoso.com\Shares\Finance'. Microsoft also notes: "In some environments, enabling access-based enumeration can cause high CPU utilization on the server and slow response times for users."
Multiple read/write targets for fast-changing data. If Finance has a branch target and an HQ target kept in step by DFS Replication, and users get failed over between them, read Microsoft's support policy before you call it a namespace bug. It describes home folders and roaming profiles on branch and hub targets and says "the same issue applies to any fast-changing content that may not have been replicated to a replication partner when the referral redirects the user from a different partner to that partner." Its conclusion: "Therefore, they are not supported by Microsoft."
Step 9: When DFS Management says "The namespace cannot be queried" (read-only)
This is the admin's view, and users may be fine while it fails. Microsoft keeps one article per reason text. The short version:
| Reason after "The namespace cannot be queried." | Microsoft's causes | First read |
|---|---|---|
| "The RPC server is unavailable" | DFS Namespace service stopped or not Running; TCP 445 to the namespace server blocked; no same-as-parent A records for the domain (third-party DNS); stand-alone ID/Svc values missing |
Get-Service -Name Dfs on the namespace server; TCP 445; Resolve-DnsName corp.contoso.com
|
| "The remote procedure call failed" | The service crashed or stopped responding after the console connected | The service's state and the System log on that server |
| "Element not found" | The root's registry key or its LogicalShare/RootShare values missing or corrupt; rarely, the PDC or DC unreachable on 389 |
The Step 5 registry read on each root target |
| "The specified domain either does not exist or cannot be contacted" | PDC or DC unreachable on TCP/UDP 389 (CLDAP unanswered); LDAP SRV records for the PDC missing | Step 6: PDC reach and _ldap._tcp.pdc._msdcs
|
| "The specified server cannot perform the requested operation" | PDC or DC unreachable on TCP/UDP 389, or down | Step 6 |
| "The device is not ready for use" | Stand-alone ID/Svc values missing; or the server is still trying to reach the PDC on 389 |
Registry, then Step 6 |
| "Access is denied" when creating a domain-based namespace | The admin account is in Protected Users (NTLM fails); or UNC hardening requires mutual authentication on the domain paths | Your account's groups; gpresult /h; the HardenedPaths key |
| "The data is invalid", "The namespace has no targets", "Not enough memory resources", "The system cannot find the file specified" | Stand-alone root registry values corrupt, modified, or missing | The Roots\Standalone key on the root server |
| "Delegation information for the namespace cannot be queried. The request is not supported" | Rare. Microsoft says to investigate with simultaneous traces | Capture on the console machine and the namespace server |
Every one of those articles carries the same note: "After you apply the solutions, remove the DFS Namespace from the DFS Management console and add it back, or close and reopen the console to make the changes take effect." So reopen the console before you decide a fix didn't work.
On the "same as parent" row, Microsoft is clear that those A records "aren't a requirement and are only used for DNS clients that don't understand SRV records," and that the hosts-file entry it describes is "As an exceptional workaround for exceptional situations" on the machine running the console, not for clients. On the Access is denied row, Microsoft's fixes are to take the account out of Protected Users or to set RequireMutualAuthentication to 0 for the domain's hardened paths. Both relax a protection, so we'd create the namespace with an admin account that isn't in Protected Users and leave UNC hardening alone (our view).
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Deleting and recreating the namespace | Every folder, target, priority, and permission has to come back exactly. If the break was a subnet, a target state, or a port, the new namespace fails the same way (our reading) | Steps 2-7: find the layer; export first (Step 10) |
dfsutil /clean on a working root server |
Microsoft's cleanup steps "should only be used if recovery of the configuration data is not possible or is not desired." and "These changes are not recoverable unless you make a backup of the system state for the domain controller or for the namespace server." | Step 9 tables; Microsoft's recovery article |
Editing the Dfs-Configuration objects in ADSI Edit |
Microsoft on the namespace's AD object: "No parts of this object should ever be modified directly." | The DFSN cmdlets or DFS Management |
Hand-editing the Dfs\Roots registry |
Microsoft: "It is recommended to never directly edit these registry values." | Import the key from a healthy root target (Step 10), if Step 9 says it's missing |
| DCs in every client's hosts file | Microsoft's hosts entry is "As an exceptional workaround for exceptional situations" on the console machine. It pins clients to addresses that will change (our reading) | Step 4 and Step 6: fix DNS |
| Flushing every cache before reading it | The cache is the evidence for Step 2. After a flush you can't tell which referral the client had (our reading) | Read dfsutil cache referral first; flush on one PC as a test |
| Turning on in-site referrals to keep users local | With no target in a site, Microsoft says the client "does not receive a referral" for that part of the namespace | Lowest-cost ordering plus target priority |
| Disabling SMB signing or enabling guest logons for a NAS target | Microsoft recommends against both | Enable signing and real accounts on the device |
| Treating ABE as access control | Microsoft: ABE "does not prevent users from getting a referral to a folder target if they already know the DFS path." | Permissions on the target share and folder |
| Stopping DFS Namespaces on a DC to simplify things | Microsoft: "The DFSN service is required for Active Directory domain controllers to advertise the SYSVOL shared folder." | Leave it running and Automatic on every DC |
Step 10: Change one layer, then prove it (only after the read)
Pick the one change Steps 1-9 point at. Save the configuration first. Microsoft's export command for a domain-based namespace (Windows Server 2008 and later form):
:: Low-risk write. Export the namespace metadata and the DFS registry before any change (writes local files)
dfsutil root export \\corp.contoso.com\Shares C:\Temp\Shares-dfs-root.txt
reg export HKLM\SOFTWARE\Microsoft\Dfs\Roots C:\Temp\dfs-roots-before.reg /y
Microsoft's recovery article says the export "may be used to recreate the missing DFS configuration information lost through accidental deletion." The reg export line is our habit. For a full restore point, Microsoft says "To back up a DFS Namespace server, a system-state backup is required." (Windows Server Backup Failed covers the backup side if that job fails.)
A client subnet that isn't in AD (Step 7, the BR1 ticket). Map the subnet to its site. The subnet, site, and location are examples:
# Change. Map the re-addressed branch subnet to its site. Dry-run first
New-ADReplicationSubnet -Name '10.40.30.0/24' -Site BR1 -Location 'Branch 1' -WhatIf
After AD replication, the namespace servers and DCs still hold cached site data (Step 6 and Step 7), so give it time before you test, and test on one PC.
In-site referrals with no target in the site (Step 7). Either add a target in that site, or turn in-site off for that folder so clients fall through to the ordering method:
# Change. Option A: let the folder refer outside the client's site. Dry-run first
Set-DfsnFolder -Path '\\corp.contoso.com\Shares\Finance' -EnableInsiteReferrals $false -WhatIf
# Change. Option B: keep HQ's copy as the last resort for everyone (Microsoft's GlobalLow class). Dry-run first
Set-DfsnFolderTarget -Path '\\corp.contoso.com\Shares\Finance' -TargetPath '\\FS01\Finance' -ReferralPriorityClass GlobalLow -WhatIf
A target set offline (Step 5). Bring it back only after you know why it was offline:
# Change. Re-enable referrals to one root target or one folder target. Dry-run first
Set-DfsnRootTarget -Path '\\corp.contoso.com\Shares' -TargetPath '\\FS02\Shares' -State Online -WhatIf
Set-DfsnFolderTarget -Path '\\corp.contoso.com\Shares\Finance' -TargetPath '\\BR-FS01\Finance' -State Online -WhatIf
Users stuck on the HQ target after the branch came back (Step 7). Turn on target failback, at the root or for one folder:
# Change. Clients fail back to the preferred target after their referral expires. Dry-run first
Set-DfsnFolder -Path '\\corp.contoso.com\Shares\Finance' -EnableTargetFailback $true -WhatIf
The DFS Namespace service stopped on a namespace server or DC (Steps 5, 9). Microsoft's commands are Get-Service -Name Dfs and Start-Service -Name Dfs. If it won't start, Microsoft points at "a registry corruption or a service dependency issue," so read the dependencies before you retry:
# Change, on FS02 only. Dry-run first
Start-Service -Name Dfs -WhatIf
The PDC's SRV records missing (Steps 6, 9). Microsoft: "Restarting the Netlogon service on domain controllers should repopulate all missing SRV records under the _msdcs.contoso.com zone." Do it on the DC with the missing records:
# Change, on DC01. Clients fail over to other DCs briefly (our note). Dry-run first
Restart-Service -Name Netlogon -WhatIf
A root target's registry key missing ("Element not found", Step 9). Microsoft's fix for a domain-based root is to import the key "from any other DFS root server holding the same DFS Namespace root or a valid registry backup", then "Restart the DFS server or the DFS server service so that the changes in the registries are loaded into memory again." reg import has no dry run, so export from the healthy server, compare the file, then import (the commands are ours):
:: Change. On FS01 (healthy): export the root's key. On FS02 (broken): import it, then restart the DFS Namespace service
reg export "HKLM\SOFTWARE\Microsoft\Dfs\Roots\domainV2\Shares" C:\Temp\Shares-domainV2.reg /y
reg import C:\Temp\Shares-domainV2.reg
Short names that clients can't resolve (Step 4). Fix the DNS suffix search list first. Microsoft's server-side answer is FQDN referrals, and its KB 244380 runs it as a sequence per namespace server: remove that server's domain-based root targets (only when another namespace server hosts each namespace: "you should make sure that there is in fact more than one namespace server that is hosting your namespace"), set UseFqdn, restart the service with Stop-Service dfs; Start-Service dfs, re-add the root targets, then update folder targets to FQDNs with dfsutil root export / dfsutil root import set. The one setting, dry-run:
# Change, one namespace server at a time, inside Microsoft's KB 244380 sequence. Dry-run first
Set-DfsnServerConfiguration -ComputerName FS01 -UseFqdn $true -WhatIf
A stale referral on one client (Step 2). Microsoft's FAQ: "You can manually clear the referral cache by using the dfsutil cache referral flush command." Flush one PC, test, then decide whether the rest need it or can wait out the TTL:
:: Change, on one client. Then reproduce
dfsutil cache referral flush
Then prove it from the affected PC. Read the result the same way you read the failure:
# Read-only. The namespace path, the referral the client now holds, and Microsoft's referral test
Test-Path -Path '\\corp.contoso.com\Shares\Finance'
dfsutil cache referral
dfsdiag /testreferral /DFSpath:\\corp.contoso.com\Shares\Finance
nltest /dsgetsite
The folder entry should list the BR1 target first and ACTIVE, and nltest /dsgetsite should return BR1. Check again after the next referral expiry (30 minutes for folders by default), because a fix that only works until the cache refreshes isn't a fix (our habit).
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Client subnet not in AD |
New-ADReplicationSubnet for that subnet and site |
Hard-coding a folder target in a drive map |
| In-site on, no target in the site | A same-site target, or in-site off for that folder | In-site on the whole namespace server |
| Target offline on purpose, maintenance over | Set-DfsnFolderTarget -State Online |
Recreating the folder |
| Users stuck on the remote target | Target failback on the folder or root | Flushing every client's cache daily |
| Short names don't resolve | DNS suffix search list, then Microsoft's FQDN referral sequence | Hosts files on clients |
| Namespace servers can't reach the PDC | Fix the path to the PDC on 389/445 | Root scalability as a workaround |
| Root target registry key missing | Import from a healthy root target, then restart the service |
dfsutil /clean and recreate |
| NAS target fails on Windows 11 24H2 | SMB signing on the device | Disabling signing on clients |
| "Access is denied" creating a namespace | An admin account outside Protected Users | Turning off UNC hardening |
FAQ
What does "DFS namespace not accessible" mean?
The client couldn't finish the chain of referrals for the path. Microsoft's three causes: it couldn't get a namespace referral from a domain controller, it couldn't connect to a namespace server, or the namespace server didn't give out a folder referral. The client's referral cache (dfsutil cache referral) shows which one.
Why can I open \\server\share but not the namespace path?
Because the direct path skips the referral layer. When the file server works by name, read the referral cache, the client's AD site, and the namespace settings (target state, in-site referrals, priorities) before you touch the file server.
Why does the namespace work at HQ but not at a branch or over VPN?
Usually sites or names. DFS maps the client to a site from the source IP of its referral request. A branch or VPN subnet that isn't in AD Sites and Services, combined with in-site referrals, means no referral at all. A VPN client that can't resolve short server names fails on the default NetBIOS-name referrals.
How do I clear the DFS referral cache?
dfsutil cache referral flush on the client, or restart it. dfsutil comes with the DFS Management Tools (RSAT). Read the cache before you flush it, because it's your evidence of which referral the client had.
What does "The namespace cannot be queried" mean?
DFS Management couldn't read the namespace. The reason after the message points at the layer: "The RPC server is unavailable" usually means the DFS Namespace service or TCP 445 to that server, "The specified domain either does not exist or cannot be contacted" means the PDC or its SRV records, and "Element not found" usually means the root's registry entry on a namespace server.
Related posts
- DFS Replication Not Working (when the referral is right but two folder targets don't hold the same files)
- Group Policy Not Applying (the drive map or GPO that points users at the namespace path)
- Windows Server Backup Failed (the system-state backup Microsoft names as the namespace server's restore point)
Free checklist
A folder that works from HQ and fails from the branch is a change nobody tested from where the users sit. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=dfs-namespace-not-accessible
Admin Pack Studio; not affiliated with Microsoft. Steps 1-9 favor read-only checks: dfsutil cache referral / cache domain, net view by IP, Test-NetConnection, Resolve-DnsName, nbtstat -c, ipconfig /displaydns, Get-DfsnRoot, Get-DfsnRootTarget, Get-DfsnFolder, Get-DfsnFolderTarget, Get-DfsnServerConfiguration, Get-DfsnAccess, Get-Service, Get-SmbShare, Get-SmbShareAccess, Get-Acl, Get-ItemProperty, Get-ADDomain, Get-ADReplicationSubnet, nltest /dsgetsite / /dsgetdc, repadmin /showrepl, and dfsdiag /testdfsconfig / /testdfsintegrity / /testreferral / /testdcs / /testsites. Installing the DFS Management Tools on a client is a small change; dfsutil root export and reg export write local files. New AD subnets, in-site and failback settings, target priority and state, starting or restarting services, registry imports, FQDN referrals, and dfsutil cache referral flush are deliberate changes. Change one layer at a time, test on one machine first, and check current Microsoft Learn for version-specific behavior.
