To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.
The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
9 thoughts on “Azure Files SMB Access On-premises with Private Endpoints”
Great Video and very heplful.
I deleted my privatedpoint, redeploy a new private endpoint, I keep getting failed deployment error due to conflict. Can you assist?
I have created SMB share as above, but would like to delete it. Can I just delete the storage account object in AD, and delete the file share (storage account) , or do i need to run a powershell command ?
I have created SMB share as above, but would like to delete it. Can I just delete the storage account object in AD, and delete the file share (storage account) , or do i need to run a powershell command ?
Hey Travis,
Couple question, Is there a way for me to set up a file share for external users who is not on my domain, My theory was I would create an account for the users on my AD DS, and they could just map the drive from where ever, this doesn’t seem to be the case, they would apparently need to be able to at the least contact the domain, so my second attempt was to set up a VPN that connected the users to my site so they could resolve the domain.
This has not worked, the third way I would assume to try is to set up a private endpoint and put them on a P2S Azure VPN but how would this work with the users not able to contact the domain?
Would I have to go two-fold and put a site-to-site VPN from my domain network to azure , then let my external users connect via P2S?
Bit stuck here
The user has to be a member of the domain and the solution requires line-of-sight to work correctly. You could try SMB without NTFS Permissions. Azure Storage supports SMB with a shared access key. Here is an article they may help. https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows
Hi, I follow your video and struggled in Azure Files with ADDS Auth SMB share over private link.
I build and destroy the environment 6 times yesterday and finally found a strange behavior of UPN path.
I was unable to get access to the Azure file share til this morning and the way to succession is a little strange.
My scenario is create an ADDS integrated storage account with file share over private link.
I can only establish the connection with the FQDN without privatelink (StorageAccountName.file.core.windows.net).
It complain with my credential if i try to use StorageAccountName.privatelink.file.core.windows.net.
The FQDN with privatelink was registered in my Domain’s DNS like your setting in video.
Please take a look at the image below
https://imgur.com/5z6RVaI
I’m ok with the result if it is the standard way to achieve the goal.
But somehow I don’t think it’s normal.
Wish you would have some time to look into my case and give me some hint what’s going wrong.
I watch your video again and suddenlly found that you establish the mapping drive with the FQDN without “privatelink”…
Seems I got something misunderstanding…
Travis,
Azure File is working properly when my VPN is configured to send all traffic to the corporate office. When I change the VPN to split VPN, the private endpoint is sometimes resolving to the public IP for the storage account. Is there a fix for this?
Great Post mate we have express route terminating into our azure vwan then peered out to vnets followed the video and bang everything worked access to Azure Files using ADDS from on-prem