How to Set up a Locally-Available Network Share Using Azure File Service

Last week saw Azure File Service go into general availability (source) with full support for SMB 3.0, and introduced a simplified way of using Azure resources and creating locally available network shares in order to facilitate all kinds of new productivity scenarios.

For this quick walkthrough I used the following MSDN article that describes in more detail all the possible scenarios, including creation of native .Net applications and using the service with Azure Virtual Machines (VMs). What the article does not explicitly say is that you can use the same procedure to make the share available to your on-premises workstations.

The great news is that you no longer require either an Azure VM to act as a File Server or a VPN connection which renders this approach immensely cost-effective. All you really need is an Azure Subscription and a Storage Account, preferably in the Data Centre closest to your physical location. You will also need a workstation running an operating system supporting the SMB 3.0 protocol, like Windows 8 and newer for desktops and Windows Server 2012 and newer for server systems. It should also be noted that at the time of writing there was a 5TB share limit and a 1TB single file size limit, as per the Azure Storage Quotas page.

Step One – Storage Account

First off you need to log on to the Azure Management Portal, create or select a Storage Account you want to use and navigate to its Dashboard. There will you find a button labelled “Manage Access Keys”. You should be presented with a popup similar to this:


We will be interested in both the Account Name and the Primary Access Key as those two are currently used to authorise users to use the share. Please make note of those values and switch to Azure PowerShell. The following MSDN article provides a good explanation on how to install Azure PowerShell on your machine.


Step Two – Creating the Share

Launch the Azure PowerShell and type in the following command to create the context of the Storage Account:

$ctx=New-AzureStorageContext <nameOfTheStorageAccount> <thePrimaryAccessKey>

If everything went well it should immediately return to the command prompt. If so, please continue with the following, providing your own, desired name for the new network share:

$s = New-AzureStorageShare <yourChosenNameForTheShare> -Context $ctx

And again, upon success you should immediately go back to the prompt. At this point the share should be created and already accessible. The last step by now is to map it in Windows:

net use M: \\<nameOfTheStorageAccount>\<yourChosenNameForTheShare> /u:<nameOfTheStorageAccount> <thePrimaryAccessKey>

If everything was typed in correctly your new network drive should be available to use (in my case it was mapped under letter M: ).



Step Three – Optional Windows Configuration

You could also use the typical Windows Map Network Drive prompt and provide the Storage Account name as the username and Storage Account Primary Key as the password. You may also choose to store those credentials for future use.





Final Remarks

As it was mentioned before, the limitation of this approach is the need to use your Storage Account credentials on every machine that needs access to the share which means revoking access to a single individual may be difficult. I would also recommend creating a dedicated Storage Account for this purpose alone, as otherwise theses credentials are sufficient to gain full control over its entire contents.

Leave a Reply