In this guide, I will show you how to mount a drive and persist an Azure File share connection with Windows, so even if you reboot your computer the connection is persisted.
Updated – 06/05/2019 – Global mapping support for Windows 10, version 1709 / Windows Server 2019 or later
Azure File storage offers shared storage for applications using the standard SMB 3.0 protocol. Microsoft Azure virtual machines and cloud services can share file data across application components via mounted shares, and on-premises applications can access file data in a share via the File storage API.
Applications running on Azure virtual machines can mount a File storage share to access file data, just as a desktop application would mount a typical SMB share. Any number of Azure virtual machines or roles can mount and access the File Storage share simultaneously.
Microsoft also introduced the Azure File Sync service which is a new service that will allow you to centralize your file shares in Azure Files, whilst maintaining the compatibility of an on-premises file server with all the flexibility and performance benefits provide. Any protocol installed on the Windows Server can access the Azure file share, including SMB, NFS, and FTPS. For more information about Azure File Sync and how to get started, please check the following step-by-step guide.
Since a File storage share is a standard SMB 3.0 file share, applications running in Azure can access data in the share via file I/O APIs. Developers can, therefore, leverage their existing code and skills to migrate existing applications. IT Professionals can use PowerShell cmdlets to create, mount, and manage File storage shares as part of the administration of Azure applications.
Now if you have been working with file shares for quite some time, you have probably come across a situation where you map a drive, and then reboot your computer to find out that the drive disappears…
If this is the case, please read on!
Store Azure storage account credentials
To get the mapped drive to persist, we should first store the Azure storage account key (credentials) using the cmdkey utility. Cmdkey is a utility that helps you to create, list, and delete stored usernames and passwords.
Open a normal PowerShell window (not as Administrator) and type the following command (make sure to change the storage account name, username and password):
Invoke-Expression -Command "cmdkey /add:<storageaccountname>.file.core.windows.net /user:<storageaccountname> /pass:<storagekey>"
If you open Windows Credentials in Credential Manager, you can see that the credentials are stored now as persistence.
Once the credentials are persisted, you can mount the drive now by specifying the Azure File Share full UNC path but without providing credentials. To do so, open a normal PowerShell window (not as Administrator) and type the following command:
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\storageaccountname.file.core.windows.net\filesharename" -Persist
Now every time you reboot your machine, the mapped drive, in this case, Z drive is always persisted as shown in the following screenshot.
That’s it there you have it!
Please note that Windows Credentials are persisted in the same user context, in other words, if you logged in with a different user account on the same machine, you will notice that the credentials are not persisted. You need to follow the same steps as described above for every user who wants to use the UNC path after each login.
If you have an application that wants to access the UNC path in Azure files, what you can do is to set up the application with a deployment service to run as the (NT Authority\System) account instead of a user account. In this case, you need to download the PsExec tool from Microsoft, and then use the Cmdkey utility as described above to add the credentials. In this way, you can cache the credentials for the remote file share using the Windows Credential Manager.
To add the credentials when the target account is SYSTEM, you need to open a PowerShell session as Administrator, and then type the following commands (make sure to change the storage account name, file share name, username, and password):
.\PsExec.exe -s -accepteula -nobanner cmdkey /add:<storageaccountname>.file.core.windows.net /user:<storageaccountname> /pass:<storagekey> .\PsExec.exe -s -accepteula -nobanner cmd.exe Net use Z: "\\<storageaccountname>.file.core.windows.net\filesharename" /persistent:yes Exit
Windows 10 1709 and Windows Server 2019
The steps described above are based on Windows Server 2016 or lower, including Windows 10 version 1703 or lower.
There are two caveats that you want to be aware of. In December 2018, Microsoft released an update (KB4469342) to addresses an important issue that causes mapped drives to fail to reconnect after starting and logging onto a Windows device. However, this fix still only applies to regular user accounts under the user context scenario as described above. It would have no effect for mapped drives created by service accounts such as SYSTEM or NetworkService. In other words, every time you reboot your machine, the SMB connection will not reconnect. If you want to persist a connection for file share under SYSTEM or NetworkService account, you need to run a script at startup as described in this article.
The good news is, that starting with Windows 10 version 1709, or Windows Server 2019 or newer, you can use the new SMB Global mapping functionality to create a ‘global’ mapping that can be made accessible to the desired accounts.
To persist an SMB connection with Azure File Share under SYSTEM account, you need to open a PowerShell session as Administrator, and then run the New-SMBGlobalMapping cmdlet as shown below (make sure to change the storage account name, file share name, username, and password):
$cred = Get-Credential New-SmbGlobalMapping -RemotePath <storageaccountname>.file.core.windows.net -Credential $cred -LocalPath Z: -FullAccess @( "NT AUTHORITY\SYSTEM", "NT AUTHORITY\NetworkService" ) -Persistent $true -RequirePrivacy $true
These mappings can be accessed by any account that satisfies the ACL constructed from the -FullAccess and -DenyAccess parameters. However, for lower versions of Windows, the Startup script is the best solution.
It’s very important to follow the two steps described in this article because if you mount the drive first by specifying the credentials, and then store the storage account key, the drive won’t actually persist.
Azure Files and Azure File Sync give you the ability to share files without the need to deploy the underlying server infrastructure provides several benefits when building an Azure-based application.
Hope this helps!
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.