Initial connection to file share via DFS-N is slow

Question

Initial connection to file share via DFS-N is slow

Ben Cashmore 0

We have recently moved over to using DFS-N for our file shares that are hosted in Azure File Storage.

We have 9 x DCs and 1 x DFS-N server using root consolidation (all running Windows Server 2019). All on the local network.

On a users device, when browsing to the direct file share path their is no delay but when browsing to the DFS path there is an initial 10-20 second delay then you can access all the folders in the share fine for a period of time. Oddly I tested on our DCs and there is no delay when using the DFS path.

I have ran a dfsdiag and no errors were returned. Checked metadata is correctly set to use FQDN. Checked through event viewer.

I added registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs DFSDnsConfig = 1 to all DCs and the DFS server, all servers were then restarted but no change in performance. I did try browsing via netbios and FQDN but there is no difference so above registry change was probably not required but wanted to test anyway.

Site and Services appear to be setup correctly, all servers are in the same local site.

I compared the properties on the DFS tab on both a fast and slow device but they both look exactly the same.

I ran Wireshark to see if anything looked out of place but nothing jumped out at me, only thing I could see is there is no record of it connecting to DNS to pick up the IP for the DFS server which must mean this entry if already cached on the device. There is a lot of back and forth acknowledgments between the device and the Azure File Share location.

We found if you use mapped drives (DFS address) you can get into the file share instantly. You only seem to get the delay when manually browsing to the UNC path of the DFS File Share and when you try to save a document in word/excel/other app to the mapped drive although there is no delay when opening a document from an app using the mapped drive.

Any advice please on what could be causing the initial delay?

1 answer

Your answer

Answer 1

Limitless Technology 44,751

Hello there,

There might be slow data access for DFS namespace referrals when IPV6 is incorrectly disabled.

If this is a network across several locations, the DC sites may not be configured accordingly. Then the client could pick up a DC from a different site and try to access a DFS over a WAN link instead of a local (or closer) replica.

The IPv6 protocol on the DFS-N target's active network interface (NIC) has been partially disabled using an

incorrect method, and must be either re-enabled or fully disabled.

Option I - The preferred method is to place a checkmark next to "Internet Protocol Version 6 (TCP /IPv6)"

on the IP Properties of the active NIC adapter and reboot the DFS-N target server.

Option II - For administrators who want all IPv6 traffic disabled, there is a supported (but not Microsoft

recommended) method to disable outbound IPv6 using the DisabledComponents registry value as

directed by Microsoft KB article 929852.

Guidance for configuring IPv6 in Windows for advanced users https://learn.microsoft.com/en-GB/troubleshoot/windows-server/networking/configure-ipv6-in-windows

Hope this resolves your Query !!

--If the reply is helpful, please Upvote and Accept it as an answer–

Ben Cashmore 0 Reputation points

2023-06-13T07:33:50.1233333+00:00

Thank you for the suggestion. I check IPv6 on the DFS servers NIC last night and could see it was unticked. I ticked the box and restarted the server but sadly it has not resolved the issue, I am still getting the delay.

Any other suggestions please?
Gary Nebbett 6,216 Reputation points

2023-06-13T08:01:37.0866667+00:00

Hello Ben,

Are you prepared to share the Wireshark trace and perhaps other traces?

Gary
Ben Cashmore 0 Reputation points

2023-06-19T10:25:07.01+00:00

Hi Gary, I can provide screenshots of Wireshark traces but will need to redact our public IP addresses
Ben Cashmore 0 Reputation points

2023-06-19T10:26:25.3+00:00

duplicate comment
Gary Nebbett 6,216 Reputation points

2023-06-19T10:49:28.7366667+00:00

Hello Ben,

Don't spend any time preparing redacted images - they probably won't be useful enough to warrant the effort.

Gary
Ben Cashmore 0 Reputation points

2023-06-19T15:00:37.6466667+00:00

Is there anything else you can suggest for resolving or troubleshooting this issue?
Gary Nebbett 6,216 Reputation points

2023-06-19T15:34:44.01+00:00

Hello Ben,

Not really. Troubleshooting often requires trained eyes looking at hard-to-interpret data/traces and that is not practical if the data is too sensitive to be shared. Resolving an issue that is not widely reproducible and without knowing what the cause of the issue is sounds like a tall order too.

Remaining options include reinstalling/reconfiguring components, generally experimenting with changes to the environment, changing the design, accepting the issue, seeking paid professional support and so on.

Gary
Dave Cook 5 Reputation points

2023-11-28T13:13:20.5733333+00:00

Hi Ben, please can I ask if you managed to solve the issue of the delay. We are experiencing the exact same thing. I like you have done the reg keys, ipv6, Wireshark traces. Mapped drives are instant, but UNC path is a 15 to 20 second delay. Thank you.

David.
Ben Cashmore 0 Reputation points

2023-11-28T14:05:35.5933333+00:00

Sadly we did not get to the bottom of this issue and have been living with it. Thankfully we are moving away from DFS-N in the new year as we are moving all data to SharePoint.
Dave Cook 5 Reputation points

2023-11-28T14:13:40.4866667+00:00

Thanks for the swift response Ben. I am moving our NetApp stuff to Native azure files as a stop gap to move to Share-point also, I have moved three shares so far and it looks like we will have to live with it. I do have a call logged with Enterprise support so if we get anything positive back I will post it here. Luckily browsing UNC paths only affects our admins, its blocked for users, they have mapped drives only.

One thing I have not done is remove all my namespaces and regress the reg key reboot and put it back then re-instate my namespaces as the documentation states its not required for standalone DFS. I may try it anyway even though it is using FQDN.

Thanks again,

Kind regards,

David.
Ben Cashmore 0 Reputation points

2023-11-28T14:24:32.4966667+00:00

That is the same process we are currently going through. At least your staff won't have the issue with mapped drives then and it will only be your admins effected. Please do post on here if you do find a solution. Thanks.

Share via

Initial connection to file share via DFS-N is slow

1 answer

Your answer