I set up a private Azure Files share using Entra ID authentication and private access only. My Windows 11 25H2 workstation is Entra ID joined and reaches Azure through a point-to-site VPN. I mapped the share at \\xxxxxstorage01.file.core.windows.net\apps using both File Explorer and PowerShell.
When the VPN is disconnected or the share is otherwise unreachable, File Explorer repeatedly becomes unresponsive and is effectively unusable. Reconnecting to the VPN immediately resolves the problem. I reproduced the same behavior after reinstalling Windows.
Is this expected behavior for mapped Azure Files drives? What is the recommended way to make the drive available only after the VPN connects—for example, by using a logon script, a scheduled task triggered by a VPN event, or another approach?
4 Answers
Instead of assigning a drive letter, add the share as a shortcut under Network locations or use an Explorer shortcut to the UNC path. That avoids presenting an always-connected mapped drive and may prevent Explorer from treating the unavailable share as a required resource.
If the files can be hosted there, SharePoint may provide a better experience for users who frequently work away from the VPN. Otherwise, a VPN-connect script that maps the share—and a disconnect or logoff script that removes it—is likely the cleanest option.
This appears to be a broader Windows Explorer behavior rather than something unique to Azure Files. Unreachable persistent network resources can cause Explorer to keep retrying, and the result can be especially disruptive in virtual desktop sessions. The usual workaround is to connect the VPN first and map the drive afterward, then clean up the mapping when the VPN is unavailable.
Avoid permanently automapping the share when the VPN may be disconnected. Map it only after the VPN connection is established, then remove the mapping during logoff or when the VPN disconnects. A script or scheduled task triggered by the VPN connection is a practical way to handle that. You can also access the UNC path only when connectivity is available instead of keeping a persistent drive mapping.
That makes sense. I was hoping Windows would fail quickly like it does with some on-premises file servers, but I’ll look into connecting and removing the mapping as part of the VPN lifecycle.