Azure Files offers shared storage for applications using the standard SMB 3.0 protocol or the Network File System (NFS) protocol. 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 also 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.
One of the questions that I often get asked by customers, is it possible to use an alternate name like for example an existing file server name to mount the Azure file share instead of using the fully qualified domain name (FQDN) of my Azure storage account?
The answer is YES!
In this article, I will share with you how to take an existing file server name whether this server is deployed on-premises or in the cloud, and mount the Azure file share. This scenario is useful if you are migrating your data to an Azure file share and you want to keep a seamless experience for your users accessing the old server name.
To make this happen, we need to use the Distributed File System Namespaces (DFS-N) server role to be able to act as an intermediary and take over the existing file server name. DFS Namespaces is a role service in Windows Server that enables you to group shared folders located on different servers into one or more logically structured namespaces. This makes it possible to give users a virtual view of shared folders, where a single path leads to files located on multiple servers, in this case, an Azure file share(s) as shown in the following figure:
To follow this article, you need to have the following:
- Azure subscription – If you don’t have an Azure subscription, you can create a free one here.
- Azure Resource Group obviously.
- Azure storage v2 account – To create a general-purpose v2 storage account, you can follow the instructions described here.
- You also need to create one Azure file share in your storage account, you can follow the instructions described here.
- You need to have some files in your Azure file share. You can add these files directly in the portal or by mounting the share, or you can sync your data from Windows Servers to the file share with Azure File Sync.
- You need to join your Azure storage account to your local Active Directory to enable SMB authentication for Azure Files. You can follow the instructions described here to integrate Azure file share with your local AD DS over SMB.
- Lastly, you need to have a Windows Server virtual machine with the DFS-N server role installed (more on this in the next section).
- This machine can be deployed on-premises or in Azure as an IaaS VM.
Install and Configure DFS-N
This guide assumes that you already have Windows Server deployed to act as a DFS server. You can use Windows Server 2012 R2 and later versions (2016/2019/2022).
To install Distributed File System Namespaces (DFS-N) server role, open PowerShell and run the following command:
# Install DFS-N and DFS Management Console Install-WindowsFeature -Name FS-DFS-Namespace, RSAT-DFS-Mgmt-Con # Verify DFS-N Role is installed Get-WindowsFeature -Name "*-DFS*" | ft -AutoSize
The next step is to use a feature of DFS-N called “Route Consolidation“. This is not a particularly well-known usage of DFS, but extremely useful in the scenario where you want to transform your existing file server to a cloud file share. What DFS Consolidation Root allows you to do is to create a namespace called the old server name with a hashtag (#) symbol in front, which will then respond to DNS requests as the old server.
In this example, I have an existing file server called “FSRV02” which has a couple of shares “Marketing” and “Training”.
In this case, I want to move these shares and data to Azure file shares as follows:
However, I want to retain the old paths (\\FSRV01\Marketing and \\FSRV01\Training). We can do this by using the DFS Consolidation Root option.
Open the PowerShell console on your DFS-N server and run the following PowerShell commands to set the appropriate registry keys:
New-Item -Type Registry -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" -ErrorAction SilentlyContinue New-Item -Type Registry -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" -ErrorAction SilentlyContinue New-Item -Type Registry -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" -ErrorAction SilentlyContinue Set-ItemProperty -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" -Name "ServerConsolidationRetry" -Value 1
Now you have the DFS “Consolidation Root” feature enabled, it is time to redirect the traffic to the Azure File Share and make it act as if the old file server name still exists. To do this you need to update or create a DNS ‘A‘ record of your existing file server name and give it the IP address of your DFS-N server instead. In my example, I have the DFS-N server role installed on my “FSRV02” machine, and the existing file server that I want to replace on-premises is called “FSRV01“.
Once this change has been propagated on your DNS, check you are targeting the DFS-N server IP address by using the ping command against the old file server name.
Now you have DNS updated, it’s time to configure DFS-N to take over the old file server name. I will use the DFSN PowerShell module to automate this process.
Please note that you want to run those commands on your DFS-N server with a user who is already has been granted access to the Azure storage account level, or on an individual Azure file share Access Control (IAM) as described in this article.
Open a PowerShell session on your DFS-N server and run the following PowerShell commands to create a stand-alone DFS namespace. You may ask why a stand-alone namespace instead of a domain-based namespace? Because the route consolidation feature only works with the standalone namespace option.
#Create first a directory and share for the namespace on the DFS-N Server New-Item -Type Directory C:\DFSRoots\#fsrv01 #=> existing/old file server name New-SmbShare -Name '#fsrv01' -Path C:\DFSRoots\#fsrv01 #=> existing/old file server name #Create the DFS Root namespace new-dfsnroot -Type Standalone -TargetPath '\\localhost\#fsrv01' -path \\localhost\#fsrv01 #Create new folder and add Azure file share(s) as folder target New-DfsnFolder -Path \\localhost\#fsrv01\marketing -TargetPath \\azstoragedcjoin.file.core.windows.net\marketing New-DfsnFolder -Path \\localhost\#fsrv01\training -TargetPath \\azstoragedcjoin.file.core.windows.net\training
When you want to take over the name of your existing file server, you need to prepend with a hashtag (#) symbol before the server name in DFS. Now if you open the DFS Management console, you will see the DFS root namespace and folder targets are created as shown in the figure below.
We are not done yet.
If you try to browse and connect to the old server name (e.g. \\FSRV01\Training) from any machine with a user who has access to the Azure file share, it will fail. We can see an error logged in the System Event Log of the client who is trying to connect similar to below (Event ID 4). This is due to the DSF-N server (FSRV02) not correctly decrypting Kerberos tickets intended for FSRV01 (old file server name).
To fix this, you must register the old server name against the new server using the SetSPN command from an elevated command prompt logged in as a user with Domain Admin rights. With SetSPN, you can read, modify, and delete the Service Principal Names (SPN) directory property for an Active Directory service account. You can read more about SetSPN here.
My domain is called VIRT.LAB, so just change the domain name, the old file server name, and the DFS-N server name.
# Delete the existing file server host entries from your domain using the following commands # You need a user with Domain Admin rights setspn -d HOST/fsrv01 fsrv01 #=> existing/old file server name setspn -d HOST/fsrv01.virt.lab fsrv01 #=> existing/old file server name # Add the entries back for the new DFS-N server using the following commands # You need a user with Domain Admin rights setspn -a HOST/fsrv01 fsrv02 #=> DFS-N server name setspn -a HOST/fsrv01.virt.lab fsrv02 #=> DFS-N server name
The final step is to reboot your DFS-N server after you set the SPN.
Finally, we need to verify that the DFS Namespace folders that we just created are working.
In this quick video, I will launch file explorer with the old server name (\\FSRV01\Marketing and \\FSRV01\Training), as well as, the fully qualified domain name (FQDN) of my Azure storage account file share, and then validate the experience both in file explorer and the Azure Portal.
Now, what about if a user is trying to access the share on Azure and does not have permission on the file share?
He will receive a network error similar to the below.
That’s it there you have it!
In this article, I showed you how to take an existing file server name whether this server is deployed on-premises or in the cloud, and mount the Azure file share. This scenario is useful if you are migrating or integrating Azure file shares in your environment and you want to keep a seamless experience for your users accessing the old server name.
This method works for the DFS Namespace server deployed on-premises or in the cloud, in case of an on-premises deployment, it’s NOT required to create a private endpoint and site-to-site VPN to access the Azure file share unless the SMB TCP port 445 is blocked.
If you have port 445 blocked in your environment, then you need to follow the steps below to create a private endpoint for your Azure storage account and configure a site-to-site VPN.
- Check how to use private endpoints for Azure Storage.
- Configure Azure Files network endpoints.
- Configure a site-to-site VPN for use with Azure Files.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.