You dont have javascript enabled! Please enable it! Map A File Server To Azure File Share With DFS-N – Comprehensive Guide - CHARBEL NEMNOM - MVP | MCT | CCSP | CISM - Cloud & CyberSecurity

Map a File Server To Azure File Share With DFS-N – Comprehensive Guide

7 Min. Read

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.

In this article, we will show you how to preserve and map an existing file server to Azure File Share with DFS-N.

Introduction

One of the questions that I often get asked by customers, is whether 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?

Example:

\\fileservername\marketing

instead of:

\\storageaccountname.file.core.windows.net\marketing

The short answer is YES!

In this article, we 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 center to 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 diagram:

Map File Server Name to Azure File Share with DFS-N
Map a File Server Name to Azure File Share with DFS-N

DFS-N (DFS Namespace) offers two deployment methods for your DFS Namespace Root Servers: Domain-based namespace and Standalone namespace.

A Domain-based namespace (such as \\domain.com\) allows for multiple target root servers, which provides automatic High-Availability for your namespace. However, it does not offer Root Consolidation, which means it cannot remap old UNC Paths to your DFS Namespace. To achieve DFS Root Consolidation, you will need to use a Standalone Namespace (such as \\FileServer2\), but to make it Highly Available, you will need to use a Windows Server Failover Cluster.

Prerequisites

To follow this article, you need to have the following:

1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.

2) Azure Resource Group obviously.

3) Azure storage v2 account – To create a general-purpose v2 storage account, you can follow the instructions described here.

4) You also need to create one Azure file share in your storage account, you can follow the instructions described here.

5) 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.

6) You need to join your Azure storage account to your local Active Directory to enable SMB authentication for Azure Files. This is a very important step to use Kerberos authentication. You can follow the instructions described here to integrate Azure file share with your local AD DS over SMB.

7) 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. Please note that this machine should be a member server of the domain and the DFS-N role should NOT be running on your domain controller.

Azure File Share with DFS-N

The first step is to 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).

Please remember to use DFS Root Consolidation, you will need to use a Standalone Namespace, but to make it Highly Available, you will need to use a Windows Server Failover Cluster.

To install the 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

Install DFS-N with PowerShell

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.

DFS Namespace Root Consolidation

DFS Root Consolidation is a useful functionality that enables you to achieve the following:

  • Redirect a Server FQDN to point to the DFS Client Access Point.
  • Modify the Service Principal Name of the DFS Client Access Point to include the old server’s NetBIOS name and FQDN.
  • Configure a Namespace that matches the old server, so that DFS recognizes the old server’s NetBIOS name and FQDN as a Namespace.

In this example, we have an existing file server called “FSRV01” which has a couple of shares “Marketing” and “Training”.

  • \\FSRV01\Marketing
  • \\FSRV01\Training

File Server Shared Folders

In this case, we want to move these shares and data to Azure file shares as follows:

  • \\storageaccountname.file.core.windows.net\marketing
  • \\storageaccountname.file.core.windows.net\training

However, we 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 standalone DFS-N server or DFS Cluster Node 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“.

Update DNS File Server IP Address
Update DNS Host (A) record

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. We 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 Root Consolidation feature in DFS-N 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.

DFS-N Management Console

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 because the DSF-N server (FSRV02) not correctly decrypting Kerberos tickets intended for FSRV01 (the old file server name).

The Kerberos client received a KRB_AP_ERR_MODIFIED error

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.

In this example, our domain is called “VIRT.LAB”, so you just need to 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.

Verify DFS Namespace Share Access

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 one below.

Network Access Error
You do not have permission to access

That’s it there you have it!

Summary

In this article, we 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.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect with 21+ years of IT experience. As a Swiss Certified Information Security Manager (ISM), CCSP, CISM, Microsoft MVP, and MCT, he excels in optimizing mission-critical enterprise systems. His extensive practical knowledge spans complex system design, network architecture, business continuity, and cloud security, establishing him as an authoritative and trustworthy expert in the field. Charbel frequently writes about Cloud, Cybersecurity, and IT Certifications.
Previous

5 Ways to Save Costs on AWS Fargate

Celebrate World Backup Day 2021 and WIN with @AltaroSoftware

Next

40 thoughts on “Map a File Server To Azure File Share With DFS-N – Comprehensive Guide”

Leave a comment...

  1. Outstanding walk-through as well as clear and concise answers to follow-up questions.
    I have a question as well I’m hoping you can provide some insight on. I need to create a brand new namespace that points to file share in Azure. I need the file share to use the domain-based namespace option.
    I’ve created the share, and private endpoint, and joined the share to the domain and I’m able to map a drive on servers using the share path.
    My problem is when I get to DFSM and attempt to add a new Namespace entry. I see the error states “The namespace cannot be queried. Access is denied.”
    I input the namespace server name and for the local path, I select the “O” drive which is the mapping to the Azure file share. I select Domain-based namespace as the Namespace Type, click Next and that’s when I get the above error. Not sure what I’m doing wrong. Any suggestions?

  2. Hello Ken, thanks for the feedback, I am happy to hear that the article is easy to follow.
    In regard to your question, if I understood your scenario, you are NOT using DFS Namespace Root Consolidation (Standalone Namespace).
    You are using DFS as Domain-based Namespace, you’ve joined the Azure Storage account to your local Active Directory, and you’ve enabled Private Endpoint on your storage account.

    Could you please confirm that you are able to access the fully qualified domain name (FQDN) of the storage account from the server name where the DFS Namespace role is installed? For example, \\storageaccount.file.core.windows.net\share UNC path.
    Can you resolve the private link of your storage account? For example, storageaccount.privatelink.file.core.windows.net
    As a side note, when using a custom or on-premises DNS server, you should configure your DNS server to resolve the storage account name in the privatelink subdomain to the private endpoint IP address. You can do this by delegating the privatelink subdomain to the private DNS zone of the VNet or by configuring the DNS zone on your DNS server and adding the DNS A records.

    You said that [You enter the namespace server name and for the local path, you select the “O” drive which is the mapping to the Azure file share].
    You cannot do that!

    First, you create a namespace. The namespace name is the starting point of the namespace, such that in the UNC path \\domain.com\private\, the namespace root is Private.
    In the Namespace Type section, you choose a Domain-based namespace.
    Then you configure folders and folder targets to point to the FQDN of your Azure storage account/file share. You can think of DFS Namespaces folders as analogous to file shares.
    Your issue is with creating the namespace which is the first step before creating the folder(s) and folder target(s) to the Azure file share.
    Please see below the high-level architecture of configuring a DFS-N Domain-based Namespace with Azure file share(s).
    Configure DFS-N Namespace with Azure file share
    Hope it helps!

  3. Hi Charbel,

    Thank you for your response. If my source file server has multiple CNAMEs in accessing the data by end users, then that additional names are not supported under DFS Root Consolidation, right?

  4. Hello Raghu, thanks for the comment!
    No, you could use additional CNAMEs under DFS Root Consolidation.
    You can create a CNAME (Alias) and point it to the desired file server (share) and the target is Azure file share(s).
    I want to update this comment: Please note that using CNAME for file share mount isn’t supported for identity-based authentication.
    Hope it helps!

  5. Hi Charbel,

    Thanks for the amazing article! I just wanted to respond to Riaz Mahomed’s network delay question from 2 years ago (I know they likely don’t need it anymore but it can help someone else who is faced by the same situation).

    We had the same issue in our environment. A Wireshark showed us that the client was attempting to connect to the DFS server on port 80. This is a known issue where the web client (Webdav) service takes precedence over the SMB service provider. Some articles describe the solution to be changing the priority of the providers, but in our case we simply disable the web client service to resolve the issue.

  6. Hello Sam, thanks for the comment and feedback.
    Thanks for sharing your experience, much appreciated!
    This will help others if they encounter the same issue.
    Yes, disabling the web client service if you don’t need in your environment, is a good approach.
    All the best,

  7. Hi Charbel, thanks for this comprehensive guide! I stumbled this article due to an issue we encountered on one of our newer implementation.

    I have a storage account file share on Azure connected to the on-prem DC and using UNC \\storageaccount.file.core.net\share, I can access it perfectly using the storage key and AD accounts are also able to access with no issues as well.

    The problem lies when we created an alias for it. The alias path is accessible, but we always get a login prompt resulting to “specified password incorrect”. Seems that CNAME is not supported when mounting Azure file shares? https://learn.microsoft.com/en-us/answers/questions/1028669/unable-to-mount-azure-file-share-using-user-creden

    Would configuring a DFS-N applicable or would you know of a simpler approach to make it work?

  8. Hello Aces, thanks for the comment and feedback!
    Yes, as you mentioned using CNAME for file share mount isn’t supported for identity-based authentication.
    However, what you could do is to use DFS-N, then create the name that you want and point it to the Azure file share(s) using file.core.windows.net.
    Hope it helps!

  9. Hi Charbel,

    This DFS Root Consolidation works on NTLM Authentication Only or it support modern authentications like Kerberos because I have recently implemented the same steps and its not working in one of our PROD environments. I want to understand the same from you.

    Thanks in advance.

  10. Hello Raghu, thanks for the comment!
    Yes, DFS Root Consolidation works with Kerberos authentication. This is exactly what I’ve described here.
    For this to work, you need to have your Azure storage account joined to your local AD domain. Have you completed this step?
    As I’ve also described in this article, you must register the old file server name against the new server using the SetSPN command from an elevated command prompt logged in as a user with Domain Admin rights.
    The final step is to reboot your DFS-N server after you set the SPN.
    Hope it helps!

  11. Hi Charbel,
    Thanks for this great article. There’s not much documentation from Microsoft regarding this method of taking over a file server without DFS already implemented.
    My question is – if multiple file servers are being migrated to Azure files – would we have to stand up a Root Consolidation server for EACH file server to maintain the file server names and paths? I’m assuming yes, since each Root Consolidation server would essentially take over the original name.
    Thanks!
    CLO

  12. Hello CLO, thanks for the feedback and the great question!
    No, you don’t need a Root Consolidation server for EACH file server to maintain the file server names and paths.
    You need one Root Consolidation server and multiple Namespaces for EACH file server to maintain the file server names and paths is enough.
    Hope it helps!

  13. Hello Tim, thanks for confirming that it’s working for you!
    No, re-mapping users’ drives using the old names is not intended.
    This could be a local issue due to caching since there were already using the same drive(s) names.
    However, if they browse the UNC share directly, there shouldn’t be any issue.
    They should also be able to map using new drive names.

  14. Hi Charbel,

    I am doing an on-premises file share to Azure Files (with private endpoint) migration and I am having trouble getting the root consolidation feature to work as I want to retain the old share path.
    Everything else works, except for the root consolidation. I have completed the registry settings and restarted along with everything else in your article, but I am unable to browse to the old file path: \\fileserver1\public – (unspecified error 0x80004005)

    Instead I have to specify either the DFS server name and the namespace: \\dfs1\#fileserver1\public or else the following also works: \\fileserver1\#fileserver1\public

    Basically the root consolidation feature does not work. Any ideas? Thanks.

  15. Hello Alan, thanks for the comment!
    Three things to check:
    1) When you try to resolve “storageaccountname.file.core.windows.net” and “storageaccountname.privatelink.file.core.windows.net” from on-premises, is it resolving the private IP address in both cases?
    Note: When using a custom or on-premises DNS server, you should configure your DNS server to resolve the storage account name in the privatelink subdomain to the private endpoint IP address. You can do this by delegating the privatelink subdomain to the private DNS zone of the VNet or by configuring the DNS zone on your DNS server and adding the DNS A records.
    2) Did you create the DFS Root namespace as “Standalone” and not “Domain-based”, right?
    3) Did you set the Service Principal Names (SPN) directory property as described in the article?
    Hope it helps!

  16. Hi Charbel,

    Just to follow up. My DNS resolution is working correctly. I have also tried the public endpoint just to rule out private endpoints as the issue. Using a standalone namespace.

    I believe the issue is related to the SPN. When I add the new HOST SPN records, they get added but quickly disappear automatically. I’m not sure what is causing this, I have even deleted the old fileserver computer account and have also added CIFS SPN records (which don’t get deleted). I’m about ready to give up unless you have any other suggestions?

    Thanks for your time.

  17. Hello Alan, thank you for sharing more details!
    Yes, it seems that the issue might be related to the HOST SPN or the Active Directory.
    Try to reset the SPN by running the “setspn -r servername”, and then verify if the SPNs are displayed correctly “setspn -l servername”.
    Sorry, I cannot provide further support in the comment section, we need to look into the environment.
    All the best, thanks!

  18. Hi Charbel,

    Good step by step article.

    I was experiencing the same symptoms as Alan Kinane (above). It turns out that the issue is that the Domain Controller is not a good choice for a DFS name server for standalone namespaces with root consolidation.

    I moved the role to a member server, and everything works as described. Manually created SPNs for domain controller DFS nameservers hosting standalone namespaces do not stick. They get cleared upon reboot. For this use case, consider using a member server.

  19. Hello Saravanan, thanks for the comment and for sharing your experience here.
    As I noted in the introduction and the prerequisites of this article, to achieve DFS Root Consolidation, you will need to use a Standalone Namespace, and the DFS-N role should NOT be installed/running on Domain Controllers.
    I am happy to hear everything is working for you as described above.
    Hope this will help anyone facing a similar issue!

Let us know what you think, or ask a question...