File Server using Azure Files

Why would anyone move files to the Microsoft cloud?

It’s a lot of benefits using the cloud vs. on-premise environment. One of them is reducing the on-premises storage footprint. Reduce management overhead cost can be crucial for SMB companies. Azure Files uses SMB protocol which is an industry-standard protocol using TCP 445 and Azure Storage REST API over HTTPS. All data can be stored in one centralize location and replicate in three different locations. Redundancy in the primary region provides at least 99.999999999% (11 nines), which is pretty good.

TCP port 445 can be block by ISP providers. How can we override?

Out there are a lot of companies using this functionality for their redundancy, faster access between states or even regions. The number of customers who are using file server for there corporate documents is still pretty huge. More and more companies are willing for the BYOD concept and using non-domain joined machines for business access where Azure files functionality is one of the options.

While connecting from on-prem sometimes ISPs block port 445 and there is not much willing to open it for you. If you have that lucky and you are able to access the data through a network share, the problem begins when you moving around and changing ISPs. What then?

Solution for that kind of usage is definitely “custom” deployment for Azure Files of Point to Site VPN solution where you’ll be able to work around port 445 block by sending SMB traffic from a Windows machine over a secure tunnel instead over the internet.

A few quick steps how can you manage this.

·        Generate root & client certificate

After generating a self-signed root and client certificate you need to upload the public key information to Azure and establish trust by Azure for connection over P2S to the virtual network.

You also generate client certificates from the trusted root certificate and then install them on each client computer. The client certificate is used to authenticate the client when it initiates a connection to the VNet.  

·        Create VNet & P2S VPN Gateway

The best and the quickest way to implement VNet is to use a predefined template from here.

A few modifications need to be also done regarding “VPN Client Custom Routes” where public IP must be present and “Client Root Cert Data” entered from a previous step.

 ·        Deploy/download VPN client

VPN clients can be downloaded from the Azure portal locating in Virtual Network Gateway à Point-to-Site confirmation.

From here on there are a few options on how to distribute “msi” packet. I prefer to use GPO as a "slipper" way.  

·        Install cert

This step is needed for computers in which you are installing VPN and connecting to Azure Files. Like in the previous step using GPO is a quicker way to deploy “pfx” certificate.

 Conclusion

From the design perspective, it is highly recommended to use a GRS (Geo-Redundant Storage which uses the three local replicas + three additional replicas in another region) to make sure that all data that is being synchronized to the cloud does not have a single point of failure. Azure Files are fully managed with high available service which means no need to worry about versions or keeping sync servers in deferent geographical locations.

As of February 24th, new and existing ACLs tiered by Azure file sync will be persisted in NTFS format. ACL modifications made directly to the Azure file share will sync to all servers in the sync group and any changes on ACLs made to Azure Files will sync down via Azure file sync. We have been waiting for this functionality for a very long time.

From my point of view for scenarios like this, it will be great if Microsoft considers implementing this functionality similar to OneDrive For Business or even Teams.