As with any technology, when you first get started there are sometimes some bumps to getting the setup or installation correct. Those DOH moment. No matter how many times you read the administrators installation guide there may be some items that are missing that wasn’t included in the documentation or a particular scenario not thought of. Azure file shares is no different and there are some common hiccups that can be avoided with good planning. This blog post is going to give you some tips and tricks to get started with Azure file shares to help eliminate some of those bumps that you may run into.

Intros please

First off, I want to give a quick intro as to what Azure file shares is for those that are hearing about this for the time. The official description of Azure file shares is:

“Fully managed file shares in the cloud that are accessible via Server Message Block (SMB) protocol (also known as Common Internet File System or CIFS). Azure File shares can be mounted concurrently by cloud or on-premises deployments of Windows, Linux, and macOS.”

The short version is:

A file share that is in the cloud.

Azure file shares can be used to completely replace or supplement traditional on-premises file servers or NAS devices. They can be used by Windows, macOS, and Linux which can directly mount Azure file shares wherever they are in the world. If you are thinking of using this to replace your local file shares you will need to use Azure file Sync and be running Windows server 2016.

You can use it for more than supplementing your local file server such as, Azure files can be used to in a lift and shift migration into Azure. This also works well for Hybrid scenario, where the application data is moved to Azure Files, and the application continues to run on-premises. An Azure file share is also a good for cloud applications to write their logs, metrics, and crash dumps.

With security on everyone’s mind you’re probably asking how is this secured? Well, Azure Files access control is maintained with several methods. Announced at Microsoft Ignite 2018, Azure Files supports identity-based authentication and access control with Azure Active Directory (Azure AD) (Preview). As part of the preview, Azure File supports preserving, inheriting, and enforcing NTFS DACLs in a file share. When data is copied from a file share to Azure Files, or vice versa, you can specify that NTFS DACLs are maintained. Please note this is in preview so I would not recommend into production. The stop gap until Azure AD for Azure file shares is GA is to use Azure file sync. When using Azure File Sync on your Windows file server, it preserves and replicates all discretionary ACLs, or DACLs, (whether Active Directory-based or local) to all endpoints that it syncs to in Azure.

Tips and Tricks

Below is a list of some tips and tricks to help remove any bumps you have may with Azure file shares.

Plan, Plan, Plan

I can’t say this enough, but you need to plan why and what before you jump into this head first otherwise you can risk failure.

Develop a clear plan. Identify what you’re moving to Azure files shares and the reasons for why.

Understanding the objectives will help you become more successful as you can determine if this is the right path or possibly a different solution is better.

Once you have those identified gather all the stakeholders and start to develop a plan for the implementation.

Use SMB 3.0

The preferred SMB client is 3.0.

You should be using SMB 3.0, however, you can access Azure file shares with SMB 2.1. Keep in mind that clients that are using SMB client 2.1 can only access it from within the same Azure region. Please also note the connection is without encryption. If you’re thinking of using SMB client 1.0, it won’t’ work.

If you are mounting from an on-premises server or outside your Azure region only SMB 3.0 is supported.

Open Port 445

Common cause for connection issues is Port 445 being block. This can be at the local level within your datacenter to even your ISP. To see the summary of ISPs that allow or disallow access from port 445 see here

Troubleshoot connection issues with Fiddler or PortQRY: You can use Portqry to query the TCP:445 endpoint. If the TCP:445 endpoint is displayed as filtered, the TCP port is blocked. Here is an example query:



If TCP port 445 is blocked by a rule along the network path, you will see the following output

Double check that your Antivirus & Firewall Software Policy allow Port 445. Often local system policies may also block this port.

Persistent Connections

Don’t you hate it when you mapped a drive then when you reboot your computer it disappears? Well that can sometimes happen when you make connections to Azure file shares and you don’t make the connection persistent. To make connections persistent you can use the following:

CMDKEY or Credential Manager to store Azure Storage account credentials

You can also add "/persistent:yes“ to the net use command

Install KB3114025

For those still running Windows Server 2012 R2 you may experience some slowness when you attempt to copy files to Azure file shares. There is a known issue with that which can be corrected by installing KB3114025.

Install on Windows 8.1 or Windows Server 2012 R2.

This also Increases performance on I/O intensive workloads

Access issues with an application or service account

If your application or service is running under a different user account than what the drive is mounted with, you may experience an issue where the application or service account cannot accessing the Azure file share. Some workarounds :

Mount the drive from the same user account that contains the application. You can use a tool such as PsExec.

Pass the storage account name and key in the user name and password parameters of the net use command.

Use the cmdkey command to add the credentials into Credential Manager. Perform this from a command line under the service account context, either through an interactive login or by using runas.

Map the share directly without using a mapped drive letter. Some applications may not reconnect to the drive letter properly, so using the full UNC path may be more reliable.



Network and Security Policies for outside the company network or VPN

When implementing Azure file shares keep in mind it can be accessed from anywhere there is an internet connection if not configured correctly. If this violates any of your company polices on data access you will need to do some extra work. By default, storage accounts accept connections from clients on any network. You can restrict access to Azure file shares by configuring the associated storage account with limited access through the default network access rule.

Please note that making changes to network rules can impact your ability to connect to Azure Storage. Be sure to first grant access to any allowed networks using network rules before you change the default rule to deny access.

Want to know more?

Find out more about Azure File shares here are some places you can go:

Overview of Azure file shares

Overview of Azure file Sync here

Microsoft Ignite sessions for replay:

THR2254 - Deploying Azure File Sync

BRK2379 - Azure Files in 2018: Bigger, faster, better!

THR2253 - Azure Files and Azure File Sync technical foundation

You can also check out my interview with Fabian Uhse, Senior Program Manager at Microsoft Ignite 2018 here.