Performance Degradation When Accessing Azure File Shares from On-Premises PCs over a VPN Connection

The metrics point to network or client-side latency rather than Azure Files service latency.

SuccessE2ELatency includes the full request path, while SuccessServerLatency reflects service-side processing. A large gap between them indicates latency introduced outside the Azure Files service, typically by the network path or client. In this case, 353 ms versus 132 ms aligns with the delays seen in File Explorer refresh and newly created folder visibility.

Recommended troubleshooting path:

1. Verify region placement. Run the workload from a VM in the same region as the Azure file share. If latency drops there, the issue is on the on-premises-to-Azure path rather than the file share itself.
2. Confirm the latency pattern in Azure Monitor. In Azure portal, review the storage account transaction metrics for SuccessE2ELatency and SuccessServerLatency. A consistently high difference between these two metrics indicates network or client latency.
3. Check whether the workload is metadata-heavy. Folder creation and Explorer refresh rely heavily on metadata operations such as createfile, openfile, closefile, queryinfo, and querydirectory. Metadata-centric workloads can show higher latency than read/write operations. In Azure portal, go to the storage account metrics and add a property filter for API name to see whether these operations dominate.
4. Check for throttling. In Azure portal:
   • Go to the storage account.
   • Under Monitoring, select Metrics.
   • Select File as the metric namespace.
   • Select Transactions.
   • Add a filter for ResponseType.
   • Check for SuccessWithThrottling for SMB.
   If throttling appears, that can increase client-side latency.
5. If using a premium file share, increase the provisioned share size. For premium file shares, increasing the provisioned file share size increases the IOPS limit.
6. If the affected operation is mostly namespace or metadata activity, reduce metadata pressure where possible. Supported workarounds include:
   • Modify the application or usage pattern to reduce metadata operations.
   • Separate data into multiple file shares within the same storage account.
   • For premium SMB Azure file shares, use metadata caching.
7. Check the client OS level. Older clients can have performance issues with Azure Files. For Windows 8.1 or Windows Server 2012 R2, ensure hotfix KB3114025 is installed.
8. If antivirus is installed on the Azure client VM, check for excessive DirectoryOpen/DirectoryClose calls. If those calls are unexpectedly high, antivirus software can be a cause. The documented workaround is to update Microsoft Defender Antivirus antimalware platform.

Important note: changing IIS registry settings such as ConfigPollMilliSeconds applies only to web sites hosted on file shares and carries registry-edit risk. It is not relevant unless the issue is specifically with IIS-hosted web content on Azure Files.

If the issue occurs only from certain sites, while other sites access the same share normally, that further supports the network path from those sites as the primary cause rather than Azure Files service behavior.

References:

• Troubleshoot Azure Files performance problems
• Troubleshoot Azure Files