I recently created a DFS namespace for tying multiple file servers into the same path structure with the hope that this would make it easier for people to remember where to find files and to give flexibility on the back-end to change out servers or spread out files across multiple servers as needed. Once in place, I tested accessibility from Windows and Mac which worked fine. Shortly after, it was brought to my attention that access to the server did not work from a Mac connecting to the network over VPN. Neither the Cisco AnyConnect client nor the built-in Cisco IPSec VPN connections allowed this to work. The odd thing was that the Mac would prompt for credentials rather than just failing that the server wasn’t available, which is what the error message indicated.
I assumed the problem was related to not using the fully-qualified names but I tested a lot of different angles and confirmed it was definitely related to the DFS. It was a domain-based DFS and you could reach the sysvol/netlogon folders on the domain just fine. You could also connect to the server directly (bypassing the namespace pathing) as a Mac via VPN connection. Windows over VPN was still able to connect to the share.
Tangled up in the problem, I went back to the documentation and a great TechNet article ‘How DFS Works‘ shed some light. I found the section “How DFS Works in Environments Without WINS” to be the most helpful. Even though I had added all of my folder targets with the FQDN, it was still using the NetBIOS names in the target paths when added to the DFS metadata. A registry key DFSDnsConfig set on all namespace servers can modify the configuration to use DNS rather than NetBIOS.
I had two DFS Namespace management servers, so I created the registry key on both of them and restarted the DFS service.
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\
Name: DFSDnsConfig
Type: REG_DWORD
Value: 1
When set to 1, specifies that this server will use fully qualified domain names (FQDN) in referrals. When set to 0 (the default), specifies that this server will use NetBIOS names in referrals.
More information about DFS-related Registry keys is available on the ‘DFS Tools and Settings‘ TechNet article.
Despite the fact that my namespace and folder targets were populated with the FQDN path to the target servers, I still had to recreate the namespace as the directions specify. I scripted the process in PowerShell to add the folder targets and set the appropriate permissions as it goes. This would mean my downtime would be minimal. I could delete the namespace and recreate it to be available again in seconds.
Once I had that registry key name, I was able to search and find other cases reporting similar issues. I do not understand why the current approach is to use NetBIOS by default rather than DNS or why that isn’t a straight-forward option during the creation and configuration of the DFS namespace. After the namespace was recreated, I tested with all of my clients and found the Mac over VPN was now able to connect in addition to the other cases.
