DarylsCorner

Recently Microsoft announced that Azure Files went GA. Prior to that you could still take advantage of Azure File Shares in Preview but they were only exposed in the v1 portal, aka Azure Services Management (ASM) mode. In addition, Azure Files only supported the standard SMB 2.1 protocol and you could not connect on-premises systems to Azure File Shares. With the recent announcement, Azure Files is now supported in the v2 portal (ARM mode) and there is support for SMB 3.0 which allows for on-premises systems to connect to Azure Files across the internet without the requirement of a site-to-site VPN. Additional capabilities include VMs and Cloud Services being able to share file data across application components via mounted shares. There is no limit as to the number of VMs or roles that can mount and access file shares simultaneously.

While testing the new features of Azure Files I found a bug. If you mount a share using Azure PowerShell, the share will be accessible from only PowerShell and will not be exposed in Explorer or the Command Prompt. Likewise, if you mount a share in Explorer, you cannot access it from PowerShell. This only applies when mounting a share across the internet. I did open a case with the Azure team so that this can get resolved.

In this post we are going to deploy Azure Files using Resource Manager and demo mounting a file share on a VM in the same region, on a VM across regions, and on a client across the internet. In a previous post we deployed a VNet-to-VNet connection and verified connectivity. Ensure you still have connectivity and If you haven’t already deployed a VM in each region, do so now. If needed, you can refer back to the previous post by clicking here. So let’s move forward.

Some common uses of Azure Files include:

• store shared applications settings like config files in a common place
• store log file data in a common place
• store tools and utilities in a common place
• to aid in the migration of on-prem applications that rely on file shares

Take note that the commands below are using Azure PowerShell 0.9.8. If you wish to use the 1.0 Preview you can refer to a previous post I did here on Keeping Azure PowerShell Cmdlets Updated. In addition, you will need to edit the cmdlets using the pattern {verb}-AzureRM{noun}.

Deploy Azure File Storage Service

1. Connect to your Azure subscription.

2. Select which subscription you would like to deploy to. I am using my “Azure Pass” subscription.

3. Switch to Azure Resource Manager mode.

4. Now we need to deploy a storage account. Storage accounts can support up to 500 TB per storage account. An existing storage account can be used since the file storage is built on the same technology as blob storage and leverages the existing availability, durability, and scalability that comes with the Azure storage platform. First we will define a unique storage account name. Note: Storage account names must be globally unique, lowercase, no spaces, or dashes.

Now we will define the type of storage account to be used. In my example I am just using local redundant storage but choose what works best for your scenario.

Now we will create the new storage account to be used by the file share.

5. Now that we have a new storage account, we need to set it as the default. First, lets get the subscription ID.

Next, we set the default storage account.

6. Next, we need to define a few variables to be used for the file share name, and the share URL. In my example I used sharedfiles but choose what works best for your scenario. Note: The name of the file share must be all lowercase.

7. Here we will get a storage account access key and define it as a variable.

8. Now create the storage account context. The context encapsulates the account name and key.

9. Now we are ready to create a share. By default the quota is set for 5 TB , which happens to be the max size of a file share, but the quota can be changed to suit your needs.

10. Next we will create a directory in the share. In my example I created a directory called SampleDir but choose what works best for your scenario.

11. I have a test file that I have created on my local system. Now we will upload that test file to the directory we just created. The max size of a file in a file share is 1 TB with the number of files only limited to the capacity of the share.

12. If we go look in the Preview Portal we can see that we have our file located in the share. In addition, there is a nice bread crumb across the top of the File share blade. As you can see there are several available options for managing shares, directories, and files directly within the portal as well.

13. Here we can list out the files and sub-directories of a specified directory using PowerShell.

14. What if you wanted to download a file from the Azure File storage service? As you can see the file doesn’t exist on the desktop of my local system. After running the command below, viola!

15. What if you wanted to remove a file from the Azure File Storage service? You could either run the command below or just remove it from the portal. I will not run this one so we have a file to use for demo.

 

Mount Shares

Now that we have our share deployed and we have a test file to view, we need to mount the share.

1. In the first example we will be mounting a file share in an Azure VM located in the same region where the Azure File Share service is deployed. For this example we will mount the share to VM1 which is deployed in the West US region as shown below.

Run the command below to get the Azure File Storage account access key. Copy the access key and paste it in the cmdkey command below in the place of [storage account key], to include the brackets.

Establish an RDP connection to VM1, copy the two commands below, and run from the PowerShell console of the VM.

And Viola!

2. Now we will perform the same actions on VM2 which is located in the East US region. This will demonstrate connecting to a file share across regions. I will refrain from boring you with all the same screenshots. Perform the same steps above on VM2 to mount the share. As you can see we were successful.

3. Finally we will mount the share on a system across the internet. I will use my laptop to demo this. Previously I mentioned a bug where you would mount a share across the internet using PowerShell and it not show up in Explorer and vice versa. I would expect this to get resolved soon so this may not be an issue depending on when you are viewing this post. In addition, in order to successfully mount an SMB 3.0 share we will need to make a registry edit. Azure Files requires NTLMv2 to prevent data compromise over the internet. NTLMv2 significantly improves both the authentication and session security mechanisms. For a client to be able to connect to the share, it will need to support NTLMv2. Additional requirements are: Clients running Windows 8 and up support for SMB 3.0 and port 445 (TCP Outbound) must also be open.

If I look in the registry at  HKLM\SYSTEM\CurrentControlSet\Control\Lsa\lmcompatibilitylevel the DWORD is set to 1. You can see the various settings listed here. Changing the value to 3 forces the client to only use NTLMv2. Prior to changing this setting you can see that the client fails to connect with a system error 53.

Change the value from 1 to 3, reboot if necessary (In my case I did not have to reboot). To ease in administration, changing this setting could be done from a Group Policy. Here are the results. Now I am able to navigate the Z drive and see the directories and files.

To remove the drive mapping you can simply run “net use z: /DELETE”.

4. Now lets see this from Explorer. Select the drive you wish to mount, enter the share path, and select Connect using different credentials.

Upon clicking Finish you are asked for credentials. Enter the storage account name as the User name and the storage access key as the password.

Now, from your workstation, you have access across the internet to a file share hosted in Azure Files.

With Azure Files now having the ability to mount a file share from an on-premises application or workstation, this really opens the doors for support of many other scenarios. However, there are still a few capabilities missing like AD authentication and file permissions that would make this a viable replacement for an on-premises file server. At this point in time I see Azure Files having a great use case for teams wanting a single shared location for files where everyone has the same access requirements. One thing worth mentioning is that i saw a different experience with a Windows 10 client when mounting an Azure File share across the internet. As always, test, test, and then test before deploying into production.

I hope you learned something here and feel free to comment if you have any experiences that you would like to share.