DFS Share and Azure Files - DFS Name Access Extremely Slow when WebClient service Running in Windows

Question

We just did a large on premises file share migration to Azure Files (serverless), and implemented a DFS namespace server (Windows 2022 with root consolidation) so all existing file share paths would be retained and it's less noticeable for our end users.

We mapped drives for everyone using the DFS namespace, and that works fine.

However, we found that when a user browses to the mapped Azure File share via Office Apps or even Adobe, the server says "contacting \dfsname\share...", and it takes 20-30 seconds before the folder structure appears on the screen. If we map the drive directly to the Azure Storage Account path, there is no delay when clicking on it.

 

After much searching, we found a workaround where if the WebClient service is stopped and disabled (it MUST be stopped AND disabled), the delay is completely gone, and the Azure File shares are appearing back to normal speed.

 

I understand the WebClient service is using WebDAV. But why would WebDAV be attempted first (I'm guessing it's trying to access the share via WebDAV, failing, and finally SMB access works)?

 

Seems like an issue with WebDAV functionality and DFS, but can't pinpoint the exact problem. We're trying to disable the WebClient service but also don't know if that will affect other workloads for our users.

All resources are behind private endpoints, and Azure File shares are only accessible via VPN.

Any help is appreciated.

Answer 1

@Carmelo LoPresti Welcome to Microsoft Q&A Forum, Thank you for posting your query here!

As I understand you are experiencing slow performance when accessing Azure Files through Office Apps and Adobe, but not when accessing it directly through the mapped drive. You have found a workaround by disabling the WebClient service, but you are concerned about the impact on other workloads.

It is possible that the delay is caused by the WebClient service attempting to access the Azure Files share via WebDAV before falling back to SMB access. This behavior is expected, as the WebClient service is designed to enable WebDAV access to file shares. However, it is not clear why WebDAV access is slower than SMB access in your environment.

One possible explanation is that the delay is caused by the DFS namespace server resolving the share path to the actual Azure Files share location. This can take some time, especially if the DFS namespace server is located in a different region than the Azure Files share1. Disabling the WebClient service may bypass this delay by preventing WebDAV access and forcing SMB access directly to the Azure Files share.

Regarding the impact of disabling the WebClient service, it is possible that some applications may rely on WebDAV access to file shares. Disabling the WebClient service may cause these applications to fail or experience reduced functionality. However, if you have tested your applications and found that they work fine without the WebClient service, then disabling it may be a viable solution.

You may want to investigate other ways to optimize performance when accessing Azure Files through Office Apps and Adobe. For example, you could try increasing the number of threads in your applications to improve parallelism, or switch to applications where parallelism is possible. You could also review transaction metrics via Azure Monitor to identify any latency issues caused by the network or the client

Understand Azure Files performance

Azure Files scalability and performance targets

If the issue still persist, I would recommend you to contact support, so If you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support. In this case, could you send an email to AzCommunity[at]Microsoft[dot]com referencing this thread as well as your subscription ID. Please mention "ATTN subm" in the subject field. Thank you for your cooperation on this matter and look forward to your reply.

Please let us know if you have any further queries. I’m happy to assist you further.     

---

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Thank you for your comment and information.

Regarding the location of the DFS server, both DFS server and Azure File share are located in the EUS2 region. We did that purposely so they are as close as possible to each other.

I have opened 2 tickets with MS on this issue, we pay for a monthly support plan, and both times they said it was not an "Azure Files" performance issue, which I agree with. However, I cannot get an answer as to how DFS can be optimized so WebDAV isn't used first. Perhaps you can point me in the right direction as to which group I should open a ticket with?

DFS is supported with AZ Files, but there's no documentation or warnings that using DFS can cause delays by WebDAV. There should be some documentation on why this happens and how to fix it.

Thank you.