 So, hi everyone. I'm here with Will Greese from the Azure Files team. So, we're traveling a lot with Ignite, the tour, right? So, I get often asked by a lot of people about Azure Files Inc. They think it's a great tool. It helps them with their file servers, which they deploy around the world to replicate those and use the advantage of using the Cloud on their own prime environment. So, you're working on Azure Files, is that correct? Yeah. So, the great thing about Azure Files Inc and it really goes back to what we started with is this question of really trying to get to where the customer actually was with their data. So, customers have on-prem file servers today, and in a lot of cases, customers really like their on-prem file servers. So, Azure Files Inc. is really positioned as a way that you can start to take advantage of some of the great things in the Cloud like Azure backup, like the fast disaster recovery feature of Azure Files Inc. Without giving up that on-prem experience, I mean, your file servers right down the hall, typically from where your end users are. So, things are really fast. You're getting that cash and ability on-premises. So, yeah, Files Inc. has been definitely a big hit with customers and definitely one of our shining spots with the Azure Files. Yeah. Now, we hear that a lot when we go out on the tour and we show that people really love it. But one question I get a lot is some of them, you still need a server on-prem, right? You need to like sync and you have that agent. It's basically caching, as you said, your files there. But even some of the companies, they want to get rid of that, right? They want to get rid of their on-prem servers at all. And you're here to talk about this. Yeah. So, it's not surprising we get customers coming up to us saying, hey, I've pitched Azure Files Inc. to my management. My CTO said, no more on-premises servers. And we do get some customers that will run Azure Files Inc. against an Azure VM. And that's a great solution if you fit into that category of wanting to do that. But we look at that and say, oh, that's not the best because it forces you to have to run a server and you're not getting the benefit of the caching, right? You're caching the file share also in Azure. So, from our perspective, we really want to be able to transition people to, if they're in this boat where they want to deploy Azure Files this way, that they're able to just use the serverless aspect of Azure Files and just ask for a file share and get a file share and go. Okay. That sounds awesome. So, can you show me how that would work? Yeah. So, the big thing that really has stopped people from doing this in the past and up until now makes customers use Azure Files Inc. as sort of a stopgap to this is the lack of Active Directory integration for Azure Files. So, at Ignite, we actually announced in our session that we're coming out with Azure Files Active Directory domain join support. And so, that's coming very soon. And basically, the core of this really starts from domain joining your storage account. Okay. Oh, that sounds pretty cool. And I think a lot of people have been waiting that for a long time. It's been a many asked, much asked feature. And so, we have that now to be able to show you. Okay. That's awesome. Can you show it to me? Yes, of course. So, like I said, the first step here is to domain join the storage account to your domain. And so, to do that, I'll show you, I have a storage account here. And inside of this storage account, I actually have a nice file share called Test Share. There it is. So, this is exactly what we had before, right? This is not something you use. This is like the normal Azure storage account with Azure Files as we know it. Yes, exactly. Nothing special with this particular storage account other than it's deployed into a region, a development region that has this functionality enabled. So, the next thing I need to do is actually pop up in the PowerShell terminal. I'm using the nice Windows terminal app. And I'm gonna run the actual domain join. Essentially, I'm doing an offline domain join. So, I'll type in the utility PowerShell module we have. And then I'll actually just go straight forward typing in the domain join command. So, I'll do join az storage account for auth. And I'll type in the information about my storage account, like resource group, storage account name, all the things that you'd expect. This is sort of standard Azure PowerShell. So, is this now connecting to my Azure Active Directory? Yeah. So, effectively what this commandlet does is it creates a computer account in your on-premises AD on behalf of your storage account. And while we were talking there, actually I just did that. So, I've created the computer account. I've set the password on that computer account to be one of our new storage account keys for the storage account called curbkey one. And then I have actually set a special property on the computer account that I just created called the service principal name. That matches the storage account's name. So, this enables me to when I come into my windows client, I have my file explorer type in the path or I do a net use to mount using my windows identity. I actually pass a Kerberos ticket to the Azure file service and Azure files can authenticate and authorize. Okay, oh, that sounds pretty good. So, from here, I might be inclined to just jump forward and wanna start playing around with the share. But if you're like most customers and this demo environment that I have here is like this, you actually can't because most customers actually block the port that SMB communicates over, which is port 445. So, to address that, we're actually gonna configure some of the advanced networking features of the storage account to be able to tunnel and access over VPN. Okay, that makes a lot of sense because also not just company blocking that port, but I also heard like service providers blocking the SMB port and things like that. Of course, so if you're in the position where you're trying this at home, you have one of the big service providers just as a way to attempt to protect their customers, they've blocked this port thinking, oh, nobody needs to access a file share over the internet except for you do in this case. And so, this enables you to tunnel over a VPN. Okay. I do wanna stress that if your organization is willing to open up port 445, there's nothing inherently insecure about doing that and Azure Files uses SMB3 with encryption. So, it's an internet safe protocol, but we're just sort of looking at it from the perspective that most customers are not wanting to open up this port. Yeah. Cool, so let's move on. So, the first thing that we're gonna do here is we're gonna create a private endpoint for the storage account. So, this is a great new feature from the networking team and effectively what it does is it gives your storage account a dedicated NIC with an IP address assigned from inside the address space of a virtual network. So, I have my same storage account here and I have a virtual network that I wanna add a NIC in. So, I'm gonna show you how to do that. So, I'll click into the storage account and I'll navigate to the private endpoint connection and click new private endpoint. So, it's an Azure resource just like anything else. So, I'm gonna give it a name and I actually need to select the region that I want it to be in. So, in this case, my VNet is in French Central. So, I've selected French Central as the region that I want the private endpoint to be in. So, if I advance here to sort of the next step, I need to select the storage account. So, let me see if I can find it in this list. Good thing is I can type it out here because it's not coming to me. You're dealing with a lot of storage. Yes, it's a shared subscription. I'm sure many of you know that. So, I've selected the storage account that I want and then I've actually picked the target resource here. The storage account is a managed object in Azure that serves like five different Azure storage services. So, Azure files is the one that we want here, obviously. And then I go through some of the final configuration steps. So, I need to select my virtual network and the subnet that I want it in. And then you'll notice I didn't modify any of the settings, but you'll notice this private DNS integration. You know, strictly from the perspective of private endpoints, that's optional. But from the perspective of actually using this to connect from on-premises, that's actually a requirement that you have to configure that. Okay, yeah. Good news is it automatically does it for you. So, it's not hard to do. Perfect, yeah. And then obviously just go through and create the private endpoint. So, it's gonna do all the validation and then create. And you'll see in real time here that I'll actually go through and do this private endpoint creation. So, after that private endpoint gets created, does that then in that case mean I can access it privately, right? But does it also block it from public access? So, that's a great question. So, inside of your Azure VNet, when you type in the storage account's name, so like storageaccount.photocord.windows.net, that's the file endpoint. You'll actually be able to resolve the private IP address. So, they do that through C names and nice DNS. I'll show you that in a minute actually. If you're outside the storage account, simply configuring the private endpoint doesn't prohibit you from connecting to the actual public endpoint. So, there's actually another feature that Azure Storage has called firewalls and VNet ACLs. And so, you can configure your storage account such that it will reject requests coming from public. Okay, so perfect. So, I can do actually both. So, if I'm a company who I want to have private access, but also for some reason want to have the public access, I can have both. But if I wanna just have the private one now, I can also just put ACLs on it and basically protect it. Yep, that's exactly right. And actually, we've had customers that have expressed both ways. Like, I really need to lock this down and have it go over an express route because I need to deterministic routes, government and sort of financial customers will say that. Or like, I actually want the public endpoint open because I do want my external users to be able to mount if they're not on my on-premises location. Yeah. All right, so I'll show you the resources that we have here. So, here's my NIC that I created and you'll see that I have a private IP address. And then the other main thing I wanna draw attention to, I guess before I do that, you'll notice I actually deployed three resources. The private endpoint, the network interface and the private DNS zone. If I already had a private DNS zone, it would just update the existing one. But in this case, I didn't. So, the one thing I wanna really draw your attention to is this private DNS zone. So, you'll see I created a record, an A record for this storage account that matches the private IP address. And then this actually turns out to be really important later. So, I won't make you wait long, but I'll make you wait one second to show you why this is important. Okay. All right, so the next main thing that you'd have to do here is to set up an express route or VPN connection. Obviously, this is quite a time consuming thing to do. Not a hard thing to do, but it's also something that you really only have to do once. You don't have to do it for every storage account. So, we're gonna skip showing how to do this, but we do have documentation we'll provide in the video link. Okay, yeah. So, this is exactly how you would do it. There's nothing special about this. This is like if you have- It's a regular standard express route connection. Okay. And importantly, because you created a private endpoint, you don't have to do Microsoft pairing. If you wanna do only private pairing, you can. Perfect. Okay. All right, so the next thing we need to do here is because we wanna access from on-premises, we need to actually forward the Azure Storage DNS zone to be answered by the Azure Private DNS that I just showed you, as opposed to being answered by the Azure Public DNS. Yeah. So really what that looks like is, I have a nice slide to show you here. Without this, I ask Public DNS for the IP, and then I try to do a request over the public endpoint, and if I block four per five, SMB will fail. Yeah. So really what we wanna do is we wanna do this sort of layer of indirection. We wanna hit my on-prem DNS, which hits a DNS server that I set up in Azure, which hits the Azure Private DNS service. And you need that layer of indirection of having a DNS server that you run in your Azure VNet from the perspective that that Azure Private DNS IP is not accessible outside of your Azure VNet. Okay, which makes absolutely sense, right? You wanna just change the naming. Yeah, I mean, from talking to customers, I've talked to a few Azure files customers that have already set this up for other services, which case you can just update your configuration in place to redirect core.windows.net, or if you're in a non-public cloud to redirect the endpoint relative to your cloud to the right IP address. But we'll also be providing some sample ARM templates that will go to deploy the DNS server for you. Okay, nice. All right, so let's actually look at how to do this. And of course you have SMB. So here's my view of my Windows server. I've loaded a couple of MMCs to actually show you things. So what I wanna show you first is essentially the DNS forwarder that I've put in on my domain DNS, so I'm trying to say. So I have these two IP addresses. I showed the 192.168.24 and 192.5, they're actually the servers I set up in Azure. Okay, they point at this, my on-prem points at these servers over the virtual network. Yeah, so I'll flip to my page here. I have those DNS servers that I set up. And like I said, we'll be having an ARM template that configures those for you. Perfect. So I'll flip back to my other view here. And then I'll actually look from one of these DNS forwarders at that I have a similar conditional forwarder for core.windows.net. And that points at the internal IP address assigned. It's actually the same in every VNets, a special reserved IP address Azure networking has. So essentially what that means is that my on-prem DNS, which I called Contoso AD, will redirect requests for anything under the core.windows.net zone to the DNS forwarder zero or DNS forwarder one, which will redirect at core.windows.net requests to that internal private DNS IP. Okay. And then you can actually see the effect of this by typing in the resolve DNS name command. I'll type in my storage account's name. And what I get back is I get back a CNAME record for the public name of the storage account to this private link DNS zone that I created. And then I get back the, that's the authority is the private link. And of course I see the IP address that I expected, the one from the VNets space that I own. So it's a private, it's not usually, when you do that, would do that, you would actually get a public IP address back right now. You get the public IP of the Azure storage service. Okay. Yep. All right. So one additional thing that I wanted to show here, and this is strictly optional, is that if you have an on-premises server that you want to preserve the name for, you can actually use DFSN and a nice feature of DFSN called root consolidation to actually take over that existing name and redirect those requests to your file shares. Okay. So that's basically, especially if I, I mean, I probably will have users which have mounted shares and all of that, right? Or like you have in office, you have basically like paths to certain files to the file server. So with DFSN, and if you configure that, you can basically take over that, that name. Yep, that's exactly right. I do want to point out, what I'm showing here is using root consolidation, but you can also do this just as easily with a domain DNS, or sorry, DFSN, it's easy to get those acronyms. And by the way, if you didn't know, DFSN is distributed file system namespaces. But just for the purpose of this, I'm showing the root consolidation. So let's look at that. So I've already set this up. You'll notice I have here these two DFSN servers. And if I actually flip back to my view of my Azure portal, you'll see that I have them here. We're going to be providing an ARM template to set these up as well. Now, strictly speaking, there's no requirement that these DFSN servers be in Azure, but sort of sticking with the scenario that I don't want to provision on-prem servers anymore, this is a nice way to be able to do it. So what you'll actually see here is I have the DFSN namespaces, and I have the two servers. You see I have this hashtag mytestserver, and underneath I have the pointing at the actual UNC path of the storage account. So the reason that hashtag is there is actually that's what you do for the DFSN root consolidation. So there's one more aspect to this, which is I've also put a load balancer in front of this. So there's my IP address. That just lets me sort of balance between these two servers, primarily for the purpose of ensuring that if one of the VMs is down because of an update or whatever, they used to are able to satisfy the DNS, DFSN direction requests. You don't want to create a single point of failure. Exactly. So essentially what I've done here is I've created a DNS entry for my test server that points out that IP address for the load balancer. And then the final thing that you do is you mount the file share. So without further ado, let's do that. So here's my client desktop. I'll open up a file explorer here, and I'm gonna type in the actual direct path, the UNC path of the storage account. So let me type that out, and I'll type out test share. And what you see here is it connected, it used my Windows identity. And then I'm actually going to do the same thing with my DFSN root consolidated server name. So this is presumably an existing server that I have that I want to take over the namespace for. So my test server and my test share, you notice that the UNC path is totally different, but I get the exact same namespace there. And to just prove it, I'll actually go ahead and create a file and show you that it creates the file instantly, name the file and even add some content in it and save it. And when I open it on the other side, it just works. So exactly what you'd expect from a file share, use my Windows login identity. I didn't have to do any special sauce to be able to access this. I just, yeah, I didn't. So it looks like it's like your own prem file share, but actually it is the one in the cloud where you use Azure files. Exactly. Okay, this is great. Now that I'm super excited about this, because again, as I said, we've got a lot of questions around this and people are super waiting for this. But one question I get now, I mean, having the files there, that's great, right? So I have the file synced. However, is now that Azure file shares, if I have an identity, could I use like my existing permissions for that? Yeah, so I mean, this is obviously one of the big reasons to want to mount with your Windows login identity. So basically when we get your Kerberos ticket as part of the SMB mount, we get a list of your SIDS that, you know, the groups that you're in, the various user identities that you have. And then we're able to actually authorize against access control list or ACLs that are stored on the file. So it's the full thing. It's exactly what you'd expect from a file share. Yeah, so I can fully replace actually my file servers using Azure files now. Okay, this is awesome. Thank you very much for being here. So we put all the links and everything in the descriptions of that video. So if you want to know more about it, we have an announcement blog, we have documentation for it. You can just go out and try it out.