%3CLINGO-SUB%20id%3D%22lingo-sub-1649892%22%20slang%3D%22en-US%22%3EUse%20DFS-N%20with%20Azure%20Files%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1649892%22%20slang%3D%22en-US%22%3E%3CP%3ERecently%20I%20was%20working%20with%20a%20customer%20who%20wanted%20to%20use%20%3CA%20title%3D%22Azure%20Files%22%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fstorage%2Ffiles%2Fstorage-files-introduction%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EAzure%20Files%3C%2FA%3E%20to%20help%20alleviate%20the%20on-premises%20storage%20issue%20where%20they%20were%20rapidly%20running%20out%20of%20space.%26nbsp%3B%20One%20of%20the%20targets%20to%20help%20alleviate%20this%20issue%20were%20the%20sizeable%20file%20shares%20that%20migrating%20to%20Azure%20Files%20would%20allow%20for%20a%20large%20amount%20of%20on-premises%20space%20to%20be%20freed%20up.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%20id%3D%22toc-hId--1269349737%22%3ENamespaces%3C%2FH2%3E%0A%3CP%3EOne%20of%20the%20challenges%20that%20the%20customer%20had%20was%20that%20there%20were%20LOB%20applications%20that%20would%20files%20on%20these%20shares%2C%20and%20the%20namespace%20they%20used%20were%20hard%20coded%20into%20the%20applications%20and%20could%20not%20be%20easily%20modified%20across%20the%20entire%20enterprise%20in%20a%20timely%20manner.%26nbsp%3B%20The%20migration%20to%20Azure%20Files%20would%20definitely%20change%20those%20namespaces%20and%20break%20these%20LOB%20applications.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%20id%3D%22toc-hId-1218163096%22%3EDFS-N%3C%2FH2%3E%0A%3CP%3E%3CA%20title%3D%22DFS%20Namespaces%22%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-server%2Fstorage%2Fdfs-namespaces%2Fdfs-overview%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EDFS%20Namespaces%3C%2FA%3E%20is%20a%20role%20service%20in%20Windows%20Server%20that%20enables%20you%20to%20group%20shared%20folders%20located%20on%20different%20servers%20into%20one%20or%20more%20logically%20structured%20namespaces.%20This%20makes%20it%20possible%20to%20give%20users%20a%20virtual%20view%20of%20shared%20folders%2C%20where%20a%20single%20path%20leads%20to%20files%20located%20on%20multiple%20server.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EBy%20installing%20Stand-Alone%20DFS-N%20on%20the%20current%20file%20servers%20they%20were%20able%20to%20keep%20the%20same%20namespace%20but%20map%20it%20to%20Azure%20Files%20endpoints%20without%20interruption%20to%20their%20LOB%20apps.%26nbsp%3B%20This%20allowed%20for%20freeing%20up%20of%20the%20significant%20storage%20space%20that%20the%20file%20shares%20were%20taking%20up%20as%20the%20shares%20were%20migrated%2C%20though%20it%20did%20leave%20the%20file%20servers%20up%20until%20the%20LOB%20applications%20could%20be%20updated.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1649892%22%20slang%3D%22en-US%22%3E%3CP%3EUse%20DFS-N%20to%20keep%20the%20same%20namespaces%20you%20currently%20use%20for%20your%20on-premises%20file%20shares.%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-center%22%20image-alt%3D%22dfs-n.jpg%22%20style%3D%22width%3A%20400px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F217338iD7FFC724814CBE28%2Fimage-size%2Fmedium%3Fv%3D1.0%26amp%3Bpx%3D400%22%20title%3D%22dfs-n.jpg%22%20alt%3D%22dfs-n.jpg%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1649892%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EInfrastructure%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1652718%22%20slang%3D%22en-US%22%3ERe%3A%20Use%20DFS-N%20with%20Azure%20Files%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1652718%22%20slang%3D%22en-US%22%3E%3CP%3EHow%20did%20DFSN%20helped%3F%20So%20LOB%20application%20had%20%2F%2Fserver1%2Fshare%20hardcoded%20into%20them%20which%20was%20served%20say%20from%20c%3A%5Cshare.%20What%20was%20the%20challenge%3F%20To%20keep%20%2F%2Fserver1%2Fshare%20in%20place%20but%20move%20underlying%20location%20of%20c%3A%5Cshare%20somewhere%20else%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1652757%22%20slang%3D%22en-US%22%3ERe%3A%20Use%20DFS-N%20with%20Azure%20Files%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1652757%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Gregory%20-%20Yes%20the%20current%20share%20namespace%20(%5C%5CServer%5CShare)%20could%20not%20be%20changed%2C%20but%20they%20wanted%20the%20files%20to%20live%20on%20Azure%20files%20(%3CSPAN%3E%5C%5Canexampleaccountname.file.core.windows.net%5Cexample-share-name)%2C%20using%20DFS-N%20Standalone%20they%20could%20keep%20the%20same%20namespace%20and%20point%20it%20to%20the%20Azure%20Files%20namespace%20with%20no%20change%20to%20the%20LOB%20applications.%26nbsp%3B%20Ill%20update%20the%20article%20with%20an%20example%20to%20make%20it%20more%20clear%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1652764%22%20slang%3D%22en-US%22%3ERe%3A%20Use%20DFS-N%20with%20Azure%20Files%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1652764%22%20slang%3D%22en-US%22%3E%3CP%3EWould%20not%20be%20easier%20just%20leave%20local%20share%20intact%20and%20just%20use%20Azure%20FileSync%20to%20keep%20hot%20cache%20locally%20but%20still%20achieve%20the%20same%20functionality%3F%20Just%20wondering.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1652769%22%20slang%3D%22en-US%22%3ERe%3A%20Use%20DFS-N%20with%20Azure%20Files%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1652769%22%20slang%3D%22en-US%22%3E%3CP%3EYes%20that%20was%20an%20option%20that%20was%20offered%2C%20but%20they%20didn't%20want%20to%20keep%20any%20of%20the%20data%20local%2C%20even%20a%20smaller%20amount%20from%20the%20tiered%20cache%2C%20this%20is%20definitely%20an%20edge%20use%20case%20and%20not%20something%20that%20should%20be%20used%20if%20you%20could%20just%20do%20Azure%20File%20Sync%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1707833%22%20slang%3D%22en-US%22%3ERe%3A%20Use%20DFS-N%20with%20Azure%20Files%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1707833%22%20slang%3D%22en-US%22%3E%3CP%3EWhat%20if%20domain-based%20DFS-N%20is%20already%20in%20use%20and%20I'd%20just%20like%20to%20add%20an%20Azure%20Files%20share%20as%20a%20new%20folder%20in%20the%20namespace%3F%20Is%20there%20a%20specific%20permission%20on%20the%20File%20Share%20which%20needs%20to%20be%20enabled%20for%20the%20on-prem%20DFS%20server%20to%20be%20able%20to%20reach%20it%3F%20On-prem%20devices%20can%20already%20reach%20Azure%20Files%20share%20via%20long%20UNC%20(%5C%5Canexampleaccountname.file.core.windows.net%5Cexample-share-name)%2C%20would%20like%20to%20shorten%20to%20(%5C%5Cdomain%5Cexample-share-name).%3C%2FP%3E%3C%2FLINGO-BODY%3E
Microsoft

Recently I was working with a customer who wanted to use Azure Files to help alleviate the on-premises storage issue where they were rapidly running out of space.  One of the targets to help alleviate this issue were the sizeable file shares that migrating to Azure Files would allow for a large amount of on-premises space to be freed up.  

 

Namespaces

One of the challenges that the customer had was that there were LOB applications that would files on these shares, and the namespace they used were hard coded into the applications and could not be easily modified across the entire enterprise in a timely manner.  The migration to Azure Files would definitely change those namespaces and break these LOB applications.  

 

DFS-N

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 server. 

 

By installing Stand-Alone DFS-N on the current file servers they were able to keep the same namespace but map it to Azure Files endpoints without interruption to their LOB apps.  This allowed for freeing up of the significant storage space that the file shares were taking up as the shares were migrated, though it did leave the file servers up until the LOB applications could be updated.

 

In our use case they needed to keep the same server names, but if you have domain based namespace it works out even better because you don't have to keep the old file servers up to host the DFS-N but it still works the same.

Steps to Setup

  1. Define and Choose the type of Namespace needed
  2. Create Azure File Share
  3. Setup Active Directory Domain Services authentication for Azure File Shares
  4. Migrate files to make sure that your ACLs stay intact
  5. If not already setup deploy DFS-N based on your Namespace Type
  6. Use the Azure File share as the DFS-N folder target
9 Comments
Contributor

How did DFSN helped? So LOB application had //server1/share hardcoded into them which was served say from c:\share. What was the challenge? To keep //server1/share in place but move underlying location of c:\share somewhere else?

Microsoft

Hi Gregory - Yes the current share namespace (\\Server\Share) could not be changed, but they wanted the files to live on Azure files (\\anexampleaccountname.file.core.windows.net\example-share-name), using DFS-N Standalone they could keep the same namespace and point it to the Azure Files namespace with no change to the LOB applications.  Ill update the article with an example to make it more clear

Contributor

Would not be easier just leave local share intact and just use Azure FileSync to keep hot cache locally but still achieve the same functionality? Just wondering.

Microsoft

Yes that was an option that was offered, but they didn't want to keep any of the data local, even a smaller amount from the tiered cache, this is definitely an edge use case and not something that should be used if you could just do Azure File Sync

New Contributor

What if domain-based DFS-N is already in use and I'd just like to add an Azure Files share as a new folder in the namespace? Is there a specific permission on the File Share which needs to be enabled for the on-prem DFS server to be able to reach it? On-prem devices can already reach Azure Files share via long UNC (\\anexampleaccountname.file.core.windows.net\example-share-name), would like to shorten to (\\domain\example-share-name).

Microsoft

@David Caruso - I updated the article to include more detail on the steps we needed to achieve this

Occasional Visitor

@DaveLawlor -  Thank you for posting this discussion.  We are also interested in what @david caruso had to say  "What if domain-based DFS-N is already in use and I'd just like to add an Azure Files share as a new folder in the namespace? Is there a specific permission on the File Share which needs to be enabled for the on-prem DFS server to be able to reach it? On-prem devices can already reach Azure Files share via long UNC (\\anexampleaccountname.file.core.windows.net\example-share-name), would like to shorten to (\\domain\example-share-name)"

 

You mentioned you have updated instructions for this scenario.  Can you post these updated instructions for domain based DFS-N that works with an Azure Files share?  I couldn't find them.

 

Thank you  

New Contributor

@KeithLaycockI have this mostly working now with some information not in the original post. Since my DFS Namespace server is on-prem, I needed to add a private endpoint to the Azure Files share, allowing on-prem to resolve to a private ip for the Azure file share over the S2S VPN. In addition, the AFS was also domain-joined as was described above.

 

I do have a DC in Azure now which makes this a bit easier, but once I understood how to properly configure DNS to conditionally forward requests on-prem to core.windows.net, things worked as I was hoping. This video was also helpful for that configuration. https://youtu.be/H04e9AgbcSc

 

Directions I used for private endpoint https://docs.microsoft.com/en-us/azure/storage/files/storage-files-networking-endpoints?tabs=azure-p...

Directions I used for AD join https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-en...

 

So in the end I have an additional folder in the original DFS namespace which targets the Azure Files share and authenticates with AD. Looks pretty seamless.

Occasional Visitor

@David Caruso - Thanks David.  We will take a look at what you sent.