WEBVTT 00:00:00.000 --> 00:00:02.070 >> Hi, everyone. I'm here with 00:00:02.070 --> 00:00:05.310 Will Gries from the Azure Files team. 00:00:05.310 --> 00:00:08.430 So we're traveling a lot with Ignite tour. 00:00:08.430 --> 00:00:12.570 So I get often asked by a lot of people about Azure File Sync. 00:00:12.570 --> 00:00:14.040 They think it's a great tool, 00:00:14.040 --> 00:00:15.660 it helps them with their file servers, 00:00:15.660 --> 00:00:18.885 which they deploy around the world to replicate those and 00:00:18.885 --> 00:00:22.980 use the advantage of using the Cloud on the on-prem environment. 00:00:22.980 --> 00:00:26.475 So you're working on Azure Files, is that correct? 00:00:26.475 --> 00:00:29.310 >> Yeah. The great thing about Azure File Sync and 00:00:29.310 --> 00:00:32.160 it really goes back to what we started with 00:00:32.160 --> 00:00:36.300 is this question of really trying to get to where 00:00:36.300 --> 00:00:38.040 the customer actually was with their data. 00:00:38.040 --> 00:00:42.065 So customers have on-prem file servers today, 00:00:42.065 --> 00:00:44.480 and in a lot of cases customers 00:00:44.480 --> 00:00:46.520 really like their on-prem file servers. 00:00:46.520 --> 00:00:48.740 So Azure File Sync is really positioned as a way 00:00:48.740 --> 00:00:51.560 that you can start to take advantage 00:00:51.560 --> 00:00:53.090 of some of the great things in the Cloud, 00:00:53.090 --> 00:00:56.720 like Azure Backup, like the fast disaster recovery feature of 00:00:56.720 --> 00:01:01.670 Azure File Sync without giving up that on-prem experience. 00:01:01.670 --> 00:01:03.740 I mean, your file server is right down 00:01:03.740 --> 00:01:06.080 the hall typically from where your end-users are. 00:01:06.080 --> 00:01:06.081 >> Yeah. 00:01:06.081 --> 00:01:07.610 So things are really faster. 00:01:07.610 --> 00:01:10.115 You're getting that cache and ability on-premises. 00:01:10.115 --> 00:01:13.010 Yeah, File Sync has been definitely a big hit with customers 00:01:13.010 --> 00:01:16.240 and definitely one of our shining spots within Azure Files. 00:01:16.240 --> 00:01:18.360 >> Yeah. Now we hear it a lot when we go out in 00:01:18.360 --> 00:01:21.675 the tour and we show that people really love it. 00:01:21.675 --> 00:01:24.610 But one question I get a lot is, 00:01:25.070 --> 00:01:27.690 you still need a server on-prem, right? 00:01:27.690 --> 00:01:29.400 You need to sync and you have to [inaudible] 00:01:29.400 --> 00:01:30.380 and it's basically caching, 00:01:30.380 --> 00:01:32.195 as you said, your files there. 00:01:32.195 --> 00:01:33.770 But even some of the companies, 00:01:33.770 --> 00:01:35.140 they want to get rid of that. 00:01:35.140 --> 00:01:39.975 They want to get rid off their on-prem servers at all, 00:01:39.975 --> 00:01:41.700 and you're here to talk about this. 00:01:41.700 --> 00:01:45.060 >> Yeah. So it's not surprising 00:01:45.060 --> 00:01:47.510 we get customers coming up to us saying, 00:01:47.510 --> 00:01:50.630 "Hey, I've pitched Azure File Sync to my management. 00:01:50.630 --> 00:01:54.775 My CTO said, no more on-premises servers." 00:01:54.775 --> 00:01:57.170 We do get some customers that will 00:01:57.170 --> 00:02:00.065 run Azure File Sync against an Azure VM. 00:02:00.065 --> 00:02:02.240 That's a great solution if you fit 00:02:02.240 --> 00:02:05.060 into that category of wanting to do that. 00:02:05.060 --> 00:02:07.355 But we look at that and say, 00:02:07.355 --> 00:02:09.980 that's not the best because it forces you to have to 00:02:09.980 --> 00:02:14.120 run a server, and you're not getting the benefit of the caching. 00:02:14.120 --> 00:02:17.390 You're caching the file share also in Azure. 00:02:17.390 --> 00:02:20.180 So from our perspective, 00:02:20.180 --> 00:02:22.610 we really want to be able to transition people to, 00:02:22.610 --> 00:02:24.065 if they're in this boat where they want to 00:02:24.065 --> 00:02:26.750 deploy Azure Files this way, 00:02:26.750 --> 00:02:27.830 that they're able to just use 00:02:27.830 --> 00:02:29.060 the serverless aspect of 00:02:29.060 --> 00:02:31.070 Azure Files and just ask for a file share, 00:02:31.070 --> 00:02:32.855 get a file share and go. 00:02:32.855 --> 00:02:34.280 >> Okay. That sounds awesome. 00:02:34.280 --> 00:02:35.750 So can you show me how that would work? 00:02:35.750 --> 00:02:37.980 >> Yeah. So the big thing that 00:02:37.980 --> 00:02:41.300 really has stopped people from doing this in the past 00:02:41.300 --> 00:02:44.990 and up until now makes customers 00:02:44.990 --> 00:02:48.170 use Azure File Sync is a stopgap to this, 00:02:48.170 --> 00:02:51.740 is the lack of active directory integration for Azure Files. 00:02:51.740 --> 00:02:56.165 So at Ignite, we actually announced in our session that we're 00:02:56.165 --> 00:03:01.685 coming out with Azure Files Active Directory domain join support. 00:03:01.685 --> 00:03:03.530 That's coming very soon. 00:03:03.530 --> 00:03:05.870 Basically, the core of this really 00:03:05.870 --> 00:03:08.620 starts from domain joining your storage account. 00:03:08.620 --> 00:03:10.200 >> Okay. That sounds pretty cool, 00:03:10.200 --> 00:03:11.570 and I think a lot of people have been 00:03:11.570 --> 00:03:13.435 waiting that for a long time. 00:03:13.435 --> 00:03:17.655 >> It's been a much ask feature, 00:03:17.655 --> 00:03:19.760 and so we have that now to be able to show you. 00:03:19.760 --> 00:03:21.245 >> Okay, that's awesome. Can you show it to me? 00:03:21.245 --> 00:03:23.570 >> Yes, of course. So like I said, 00:03:23.570 --> 00:03:25.580 the first step here is the domain 00:03:25.580 --> 00:03:28.580 join the storage account to your domain. 00:03:28.580 --> 00:03:33.305 So to do that, I'll show you I have a storage account here, 00:03:33.305 --> 00:03:36.740 and inside of this storage account, I actually have 00:03:36.740 --> 00:03:42.570 a nice file share called TestShare, there it is. 00:03:42.570 --> 00:03:45.206 So this is exactly what we had before. 00:03:45.206 --> 00:03:46.080 It's not something 00:03:46.080 --> 00:03:48.890 just like the normal Azure Storage account 00:03:48.890 --> 00:03:50.570 with Azure Files as we know it. 00:03:50.570 --> 00:03:53.010 >> Yes, exactly. Nothing is 00:03:53.010 --> 00:03:55.370 special with this particular storage account other than 00:03:55.370 --> 00:03:58.520 it's deployed into a development region 00:03:58.520 --> 00:04:01.445 that has this functionality enabled. 00:04:01.445 --> 00:04:04.280 So the next thing I need to do is actually pop up 00:04:04.280 --> 00:04:06.665 in the PowerShell terminal. 00:04:06.665 --> 00:04:09.020 I'm using a nice Windows Terminal app. 00:04:09.020 --> 00:04:11.800 I'm going to run the actual domain join. 00:04:11.800 --> 00:04:14.060 Essentially, I'm doing an offline domain join. 00:04:14.060 --> 00:04:19.940 So I'll type in the utility PowerShell module we have, 00:04:19.940 --> 00:04:21.680 and then I'll actually just go straight 00:04:21.680 --> 00:04:23.810 forward typing in the domain join command. 00:04:23.810 --> 00:04:27.550 So I'll do join Azure Storage account for Auth, 00:04:27.550 --> 00:04:29.990 and I'll type in the information about my storage account, 00:04:29.990 --> 00:04:33.170 like resource group, storage account name, 00:04:33.170 --> 00:04:35.150 all the things that you'd expect. 00:04:35.150 --> 00:04:38.820 This is a standard Azure PowerShell. 00:04:39.020 --> 00:04:44.720 >> So is this now connecting to my Azure Active Directory? 00:04:44.720 --> 00:04:47.570 >> Yeah, so effectively, what this cmdlet does, 00:04:47.570 --> 00:04:50.780 is it creates a computer account in 00:04:50.780 --> 00:04:55.310 your on-premises AD on behalf of your storage account. 00:04:55.310 --> 00:04:58.405 While we were talking there, actually, I just did that. 00:04:58.405 --> 00:05:00.790 So I've created the computer account, 00:05:00.790 --> 00:05:03.310 I've set the password on that computer account 00:05:03.310 --> 00:05:06.040 to be one of our new storage account keys for 00:05:06.040 --> 00:05:09.260 the storage account called Kerb key-1. 00:05:09.330 --> 00:05:12.280 Then I have actually set a special property 00:05:12.280 --> 00:05:14.680 on the computer account 00:05:14.680 --> 00:05:17.050 that I just created called the service principal name 00:05:17.050 --> 00:05:19.645 that matches the storage account's name. 00:05:19.645 --> 00:05:25.830 This enables me when I come into my Windows Client. 00:05:25.830 --> 00:05:26.945 I have my File Explorer. 00:05:26.945 --> 00:05:29.155 I type in the path, or I do a net use 00:05:29.155 --> 00:05:32.040 to mount using my window and identity, 00:05:32.040 --> 00:05:34.330 I actually passed the Kerberos ticket to 00:05:34.330 --> 00:05:35.860 the Azure Files Service and Azure Files 00:05:35.860 --> 00:05:38.170 can authenticate and authorize. 00:05:38.170 --> 00:05:40.840 >> Okay, that sounds pretty good. 00:05:40.840 --> 00:05:43.200 >> So from here, 00:05:43.200 --> 00:05:45.410 I might be inclined to just jump 00:05:45.410 --> 00:05:48.400 forward and want to start playing around with the share, 00:05:48.400 --> 00:05:50.550 but if you're like most customers 00:05:50.550 --> 00:05:53.405 and this demo environment that I have here is like this, 00:05:53.405 --> 00:05:56.270 you actually can't because most customers actually 00:05:56.270 --> 00:05:59.240 block the port that SMB communicates over, 00:05:59.240 --> 00:06:00.710 which is port 445. 00:06:00.710 --> 00:06:03.230 So to address that, 00:06:03.230 --> 00:06:04.430 we're actually going to configure some of 00:06:04.430 --> 00:06:06.320 the advanced networking features of 00:06:06.320 --> 00:06:09.815 the storage account to be able to tunnel and access over VPN. 00:06:09.815 --> 00:06:11.150 >> Okay, that makes a lot of sense. 00:06:11.150 --> 00:06:13.610 Because also, not just company blocking that port, 00:06:13.610 --> 00:06:16.190 but I also heard service providers blocking the SMB port. 00:06:16.190 --> 00:06:17.840 >> Yeah, of course. 00:06:17.840 --> 00:06:20.630 So if you're in a position where you're trying this at home, 00:06:20.630 --> 00:06:25.580 you have one of the big service providers just as 00:06:25.580 --> 00:06:28.520 a way to attempt to protect their customers. 00:06:28.520 --> 00:06:30.245 They've blocked this port and thinking, 00:06:30.245 --> 00:06:31.670 nobody will needs to access 00:06:31.670 --> 00:06:33.800 a file share over the Internet except for, 00:06:33.800 --> 00:06:35.765 you do, in this case. 00:06:35.765 --> 00:06:39.125 So this enables you to tunnel over a VPN. 00:06:39.125 --> 00:06:39.805 >> Okay. 00:06:39.805 --> 00:06:41.960 >> I do want to stress that if 00:06:41.960 --> 00:06:44.869 your organization is willing to open up port 445, 00:06:44.869 --> 00:06:47.210 there's nothing inherently insecure about doing that. 00:06:47.210 --> 00:06:49.285 Azure Files uses SMB-3, 00:06:49.285 --> 00:06:52.575 without encryption, so it's an Internet safe protocol. 00:06:52.575 --> 00:06:55.310 But we're just looking at it from the perspective that 00:06:55.310 --> 00:07:01.370 most customers are not wanting to open up this port. 00:07:01.370 --> 00:07:03.770 Cool, so let's move on. 00:07:03.770 --> 00:07:05.450 So the first thing that we're going to do here, 00:07:05.450 --> 00:07:06.560 is we're going to create a 00:07:06.560 --> 00:07:08.315 private endpoint for the storage account. 00:07:08.315 --> 00:07:11.000 So this is a great new feature from the networking team. 00:07:11.000 --> 00:07:14.765 Effectively what it does is it gives your storage account 00:07:14.765 --> 00:07:17.810 a dedicated NIC with an IP address assigned 00:07:17.810 --> 00:07:21.095 from inside the address space of a virtual network. 00:07:21.095 --> 00:07:24.350 So I have my same storage account here, 00:07:24.350 --> 00:07:27.560 and I have a virtual network that I want to add a NIC in, 00:07:27.560 --> 00:07:29.360 so I'm going to show you how to do that. 00:07:29.360 --> 00:07:31.600 So I'll click into the storage account 00:07:31.600 --> 00:07:36.675 and navigate to the private endpoint connection 00:07:36.675 --> 00:07:38.790 and click "New Private Endpoint". 00:07:38.790 --> 00:07:41.490 So it's an Azure Resource just like anything else, 00:07:41.490 --> 00:07:43.245 so I'm going to give it a name. 00:07:43.245 --> 00:07:46.775 I actually need to select the region that I want it to be in. 00:07:46.775 --> 00:07:49.670 So in this case, my VNet is in France Central, 00:07:49.670 --> 00:07:52.340 so I've selected France Central as the region 00:07:52.340 --> 00:07:54.685 that I want the private endpoint to be in. 00:07:54.685 --> 00:07:58.890 So if I've advanced here to the next step, 00:07:58.890 --> 00:08:02.625 I need to select the storage account. 00:08:02.625 --> 00:08:05.985 So let me see if I can find it in this list. 00:08:05.985 --> 00:08:11.370 The good thing is I can type it out here if it's not coming to me. 00:08:11.370 --> 00:08:13.350 >> You're dealing with a lot of storage. 00:08:13.350 --> 00:08:15.290 >> Yes, it's a shared subscription. 00:08:15.290 --> 00:08:16.700 I'm sure many of you know that. 00:08:16.700 --> 00:08:19.610 So I've selected the storage account that I want, 00:08:19.610 --> 00:08:22.580 and then I've actually picked the target resource here. 00:08:22.580 --> 00:08:25.820 The storage account is a management object in Azure 00:08:25.820 --> 00:08:29.450 that serves like five different Azure Storage Services. 00:08:29.450 --> 00:08:32.825 So Azure Files is the one that we want here, obviously. 00:08:32.825 --> 00:08:36.110 Then I go through some of the final configurations step, 00:08:36.110 --> 00:08:38.075 so I need to select my virtual network 00:08:38.075 --> 00:08:40.295 and the subnet that I wanted in. 00:08:40.295 --> 00:08:43.160 Then you'll notice, I didn't modify any of the settings, 00:08:43.160 --> 00:08:45.875 but you'll notice this private DNS integration. 00:08:45.875 --> 00:08:47.810 Strictly from the perspective of 00:08:47.810 --> 00:08:49.650 private endpoints, that's optional, 00:08:49.650 --> 00:08:51.350 but from the perspective of actually 00:08:51.350 --> 00:08:53.420 using this to connect from on-premises, 00:08:53.420 --> 00:08:55.910 that's actually a requirement that you have to configure that. 00:08:55.910 --> 00:08:56.885 >> Okay. Yeah. 00:08:56.885 --> 00:08:58.580 >> Good news is it automatically does it for you, 00:08:58.580 --> 00:08:59.795 so it's not hard to do. 00:08:59.795 --> 00:09:01.280 >> Perfect. Yeah. 00:09:01.280 --> 00:09:05.915 >> Then obviously, just go through and create the private endpoint. 00:09:05.915 --> 00:09:09.744 So it's going to do all the validation and then create, 00:09:09.744 --> 00:09:12.630 and you'll see in real time here that to go through 00:09:12.630 --> 00:09:16.395 and do this private endpoint creation. 00:09:16.395 --> 00:09:20.265 >> So after that private endpoint is created, 00:09:20.265 --> 00:09:24.225 does that in that case mean I can access it privately, 00:09:24.225 --> 00:09:28.785 but does it also block it from public access? 00:09:28.785 --> 00:09:30.680 >> So that's a great question. 00:09:30.680 --> 00:09:32.795 So inside of your Azure VNet, 00:09:32.795 --> 00:09:35.990 when you type in the storage account's name, 00:09:35.990 --> 00:09:38.615 so like storageaccount.file.core.windows.net, 00:09:38.615 --> 00:09:41.000 that's the file endpoint. 00:09:41.000 --> 00:09:44.810 You'll actually be able to resolve the private IP address. 00:09:44.810 --> 00:09:48.340 So you do that through CNAME and DNS. 00:09:48.340 --> 00:09:49.620 I'll show you that in a minute. 00:09:49.620 --> 00:09:50.685 >> Okay. 00:09:50.685 --> 00:09:52.970 >> If you're outside the storage account, 00:09:52.970 --> 00:09:55.835 simply configuring a private endpoint doesn't prohibit you 00:09:55.835 --> 00:09:59.555 from connecting to the actual public endpoint. 00:09:59.555 --> 00:10:02.540 There's actually another feature that Azure Storage 00:10:02.540 --> 00:10:05.750 has called Firewalls and VNet ACLs. 00:10:05.750 --> 00:10:08.510 So you can configure your storage accounts, 00:10:08.510 --> 00:10:11.690 such that it will reject requests coming from public. 00:10:11.690 --> 00:10:13.730 >> Okay, perfect. So I can do actually both. 00:10:13.730 --> 00:10:16.280 So if I'm a company who wants to have private access 00:10:16.280 --> 00:10:17.950 but also for some reason want 00:10:17.950 --> 00:10:19.940 to have the public access, I can have both. 00:10:19.940 --> 00:10:22.610 But if I want to just have the private one now, 00:10:22.610 --> 00:10:25.085 I can also just put ACLs on it? 00:10:25.085 --> 00:10:27.530 >> Yeah, that's exactly right. Actually, we've 00:10:27.530 --> 00:10:29.625 had customers that have expressed both ways, 00:10:29.625 --> 00:10:32.110 "I really need to lock this down and have to go over 00:10:32.110 --> 00:10:35.020 express route because I need a deterministic route." 00:10:35.020 --> 00:10:38.345 Government and financial customers will say that, 00:10:38.345 --> 00:10:41.660 or, "I actually want the public endpoint open because I do want 00:10:41.660 --> 00:10:43.520 my external users to be able to mount 00:10:43.520 --> 00:10:45.620 if they're not on my on-premises location." 00:10:45.620 --> 00:10:46.205 >> Yeah. 00:10:46.205 --> 00:10:50.660 So I'll show you the resources that we have here. 00:10:50.660 --> 00:10:52.340 So here's my NIC that I created, 00:10:52.340 --> 00:10:55.240 and you'll see that I have a private IP address. 00:10:55.240 --> 00:10:58.460 Then the other main thing I want to draw attention to, 00:10:58.460 --> 00:11:00.140 I guess before I do that, 00:11:00.140 --> 00:11:02.765 you'll notice I actually deployed three resources: 00:11:02.765 --> 00:11:05.210 the private endpoint, the network interface, 00:11:05.210 --> 00:11:06.725 and the private DNS zone. 00:11:06.725 --> 00:11:08.450 If I already had a private DNS zone, 00:11:08.450 --> 00:11:09.860 it would just update the existing one, 00:11:09.860 --> 00:11:11.910 but in this case, I didn't. 00:11:12.070 --> 00:11:14.720 One thing I want to really draw your attention to, 00:11:14.720 --> 00:11:17.240 is this private DNS zone. 00:11:17.240 --> 00:11:20.240 So you'll see I created a new record for 00:11:20.240 --> 00:11:23.435 the storage account that matches the private IP address. 00:11:23.435 --> 00:11:25.970 Then this actually turns out to be really important later. 00:11:25.970 --> 00:11:27.140 So I won't make you wait long, 00:11:27.140 --> 00:11:28.790 but I'll make you wait one second 00:11:28.790 --> 00:11:30.095 to show you why this is important. 00:11:30.095 --> 00:11:31.235 >> Okay. 00:11:31.235 --> 00:11:35.210 >> So the next main thing that you'd have to do here is 00:11:35.210 --> 00:11:38.870 to set up an ExpressRoute or a VPN connection. 00:11:38.870 --> 00:11:42.860 Obviously, it's also a quite time-consuming thing to do. 00:11:42.860 --> 00:11:44.540 Not a hard thing to do, 00:11:44.540 --> 00:11:47.540 but it's also something that you really only have to do once, 00:11:47.540 --> 00:11:49.400 you don't have to do it for every storage account. 00:11:49.400 --> 00:11:51.680 So we're going to skip showing how to do this, 00:11:51.680 --> 00:11:54.815 but we do have documentation we'll provide in the video link. 00:11:54.815 --> 00:11:57.830 >> Okay. So this is exactly how you would do it. 00:11:57.830 --> 00:12:00.110 There's nothing special about this. It is just like if you have- 00:12:00.110 --> 00:12:02.555 >> It's a regular standard ExpressRoute connection, 00:12:02.555 --> 00:12:05.015 and importantly, because you created a private endpoint, 00:12:05.015 --> 00:12:07.100 you don't have to do Microsoft pairing if you 00:12:07.100 --> 00:12:09.410 want to do only private pairing, you can. 00:12:09.410 --> 00:12:10.730 >> Perfect. Okay. 00:12:10.730 --> 00:12:13.700 >> So the next thing we need to do 00:12:13.700 --> 00:12:17.285 here is because we want to access from on-premises, 00:12:17.285 --> 00:12:18.950 we need to actually forward 00:12:18.950 --> 00:12:23.000 the Azure storage DNS zone to be answered by 00:12:23.000 --> 00:12:25.040 the Azure private DNS that I just showed 00:12:25.040 --> 00:12:29.360 you as opposed to being answered by the Azure public DNS. 00:12:29.360 --> 00:12:31.310 So really what that looks like is, 00:12:31.310 --> 00:12:33.665 I have a nice slide to show you here. 00:12:33.665 --> 00:12:37.400 Without this, I ask public DNS for the IP, 00:12:37.400 --> 00:12:40.310 and then I try to do a request over the public endpoint, 00:12:40.310 --> 00:12:43.820 and if I'll block 445, SMB will fail. 00:12:43.820 --> 00:12:45.920 So really what we want to do is we want to do 00:12:45.920 --> 00:12:47.690 this layer of indirection. 00:12:47.690 --> 00:12:51.725 We want to hit my on-prem DNS, 00:12:51.725 --> 00:12:55.355 which hits a DNS server that I set up in Azure, 00:12:55.355 --> 00:12:58.205 which hits the Azure private DNS servers. 00:12:58.205 --> 00:12:59.705 You need that layer of 00:12:59.705 --> 00:13:03.020 indirection of having a DNS server that you run in 00:13:03.020 --> 00:13:06.095 your Azure VNet from the perspective that 00:13:06.095 --> 00:13:10.550 Azure private DNS IP is not accessible outside of your Azure VNet. 00:13:10.550 --> 00:13:12.560 >> Okay, which makes absolutely sense. 00:13:12.560 --> 00:13:14.210 Do you want to just change the naming? 00:13:14.210 --> 00:13:17.375 >> Yeah. From talking to customers, 00:13:17.375 --> 00:13:19.160 I've talked to a few Azure 00:13:19.160 --> 00:13:21.785 File customers that have already set this up for other services 00:13:21.785 --> 00:13:23.240 in which case you can just update 00:13:23.240 --> 00:13:27.860 your configuration in place to redirect core.windows.net or if 00:13:27.860 --> 00:13:33.980 you're in a non-public Cloud to redirect the endpoint relative 00:13:33.980 --> 00:13:36.230 to your Cloud to the right IP address. 00:13:36.230 --> 00:13:37.700 But we're also be providing 00:13:37.700 --> 00:13:39.500 some sample ARM templates 00:13:39.500 --> 00:13:41.660 that will go to play the DNS to set up for you. 00:13:41.660 --> 00:13:43.140 >> Okay. Nice. 00:13:43.150 --> 00:13:46.430 >> Let's actually look at how we do this, 00:13:46.430 --> 00:13:48.290 and of course, you have SMB. 00:13:48.290 --> 00:13:52.970 So here's my view of my Windows server. 00:13:52.970 --> 00:13:57.605 I loaded a couple of MMC's text to show you things. 00:13:57.605 --> 00:14:01.010 So what I want to show you first is essentially 00:14:01.010 --> 00:14:08.620 the DNS folder that I've put in on my domain DNS. 00:14:08.620 --> 00:14:10.280 That's what I'm trying to say. 00:14:10.280 --> 00:14:14.135 So I have these two IP addresses. 00:14:14.135 --> 00:14:20.060 I showed the 192.168.24 and 25. 00:14:20.060 --> 00:14:23.225 They are actually the servers I set up in Azure. 00:14:23.225 --> 00:14:25.460 They point that this mount 00:14:25.460 --> 00:14:29.015 prime points at these servers over the virtual network. 00:14:29.015 --> 00:14:32.090 So I'll flip to my page here. 00:14:32.090 --> 00:14:36.080 I have those DNS servers that I set up, 00:14:36.080 --> 00:14:37.190 and like I said, we'll be having 00:14:37.190 --> 00:14:39.410 an ARM template that configures those for you. 00:14:39.410 --> 00:14:42.635 So I flip back to my other view here. 00:14:42.635 --> 00:14:45.665 Then I'll actually look from one of these DNS folders. 00:14:45.665 --> 00:14:48.470 I have a similar conditional folder for 00:14:48.470 --> 00:14:50.930 core.windows.net and that points out 00:14:50.930 --> 00:14:53.945 the internal IP address assigned. 00:14:53.945 --> 00:14:56.120 It's actually the same in every VNets, 00:14:56.120 --> 00:15:00.050 a special reserved IP address the Azure networking has. 00:15:00.050 --> 00:15:04.850 So essentially, what that means is that my on-prem DNS, 00:15:04.850 --> 00:15:06.815 which I called Contoso AD, 00:15:06.815 --> 00:15:10.250 will redirect requests for anything under the 00:15:10.250 --> 00:15:16.385 core.windows.net zone to the DNS 4 or 0 or DNS 4 or 1, 00:15:16.385 --> 00:15:18.920 which will redirect it at core.windows.net 00:15:18.920 --> 00:15:22.550 requests to that internal private DNS IP. 00:15:22.550 --> 00:15:23.855 >> Okay. 00:15:23.855 --> 00:15:26.765 >> Then you can actually see the effect of this 00:15:26.765 --> 00:15:31.070 by typing in the Resolve-DNSName command. 00:15:31.070 --> 00:15:33.720 I'll type in my storage account's name. 00:15:33.730 --> 00:15:38.765 What I get back is I get back a CNAME record 00:15:38.765 --> 00:15:41.420 for the public name of the storage account to 00:15:41.420 --> 00:15:44.555 this private link DNS zone that I created. 00:15:44.555 --> 00:15:50.225 Then I get back the authority is the private link, and 00:15:50.225 --> 00:15:52.460 of course, I see the IP address that I expected, 00:15:52.460 --> 00:15:55.490 the one from the DNS space that I own. 00:15:55.490 --> 00:15:57.440 >> So it's a private. Usually, if 00:15:57.440 --> 00:15:58.835 I need to do that it would do that, 00:15:58.835 --> 00:16:01.010 you would actually get a public IP address [inaudible] . 00:16:01.010 --> 00:16:04.700 >> Exactly. You get the public IP of the Azure storage service. 00:16:04.700 --> 00:16:05.750 >> Okay. 00:16:05.750 --> 00:16:10.190 >> All right. So one additional thing 00:16:10.190 --> 00:16:12.410 that I wanted to show here and this is strictly 00:16:12.410 --> 00:16:14.735 optional is that if you have 00:16:14.735 --> 00:16:20.255 an on-premises server that you want to preserve the name for, 00:16:20.255 --> 00:16:22.565 you can actually use DFS-N, 00:16:22.565 --> 00:16:26.300 a nice feature of DFS-N called Route Consolidation, 00:16:26.300 --> 00:16:28.745 to actually take over that existing name 00:16:28.745 --> 00:16:31.445 and redirect those requests to your file shares. 00:16:31.445 --> 00:16:32.990 >> Okay. So that's basically, 00:16:32.990 --> 00:16:35.165 especially probably we have 00:16:35.165 --> 00:16:38.465 users which have mount the chairs and all of that, 00:16:38.465 --> 00:16:40.550 or like you have in Office, 00:16:40.550 --> 00:16:44.150 you have basically paths to certain files, 00:16:44.150 --> 00:16:45.275 to the file server, 00:16:45.275 --> 00:16:47.510 so with DFS-N and if you configure that, 00:16:47.510 --> 00:16:48.920 you can basically take over that. 00:16:48.920 --> 00:16:50.450 >> Yeah, that's exactly right. 00:16:50.450 --> 00:16:52.010 I do want to point, what I'm 00:16:52.010 --> 00:16:53.885 showing here is using Route Consolidation, 00:16:53.885 --> 00:16:55.820 but you can also do this just as easily with 00:16:55.820 --> 00:16:58.235 a domain DNS or sorry, DFS-N. 00:16:58.235 --> 00:16:59.930 It's easy to get those acronyms. 00:16:59.930 --> 00:17:02.135 By the way, if you didn't know what the DFS-N is, 00:17:02.135 --> 00:17:05.525 it's Distributed File System namespaces. 00:17:05.525 --> 00:17:08.120 But just for the purpose of this, 00:17:08.120 --> 00:17:11.540 I'm showing the Route Consolidation, so let's look at that. 00:17:11.540 --> 00:17:13.235 So while we set this up, 00:17:13.235 --> 00:17:18.030 you'll notice I have here these two DFS-N servers. 00:17:18.850 --> 00:17:23.240 If I actually flip back to my view of my Azure portal, 00:17:23.240 --> 00:17:25.040 you'll see that I have them here where you're going to be 00:17:25.040 --> 00:17:27.950 provided an ARM template to set these up as well. 00:17:27.950 --> 00:17:30.620 Now, strictly speaking, there is no requirement 00:17:30.620 --> 00:17:33.200 that these DFS-N servers be into Azure. 00:17:33.200 --> 00:17:35.630 But sticking with the scenario 00:17:35.630 --> 00:17:39.110 that I don't want to provision on-prem servers anymore, 00:17:39.110 --> 00:17:41.525 this is a nice way to be able to do it. 00:17:41.525 --> 00:17:44.660 So what you'll actually see here 00:17:44.660 --> 00:17:49.505 is I have DFS namespaces, and I have the two servers. 00:17:49.505 --> 00:17:52.310 You see I have this hashtag, My TestServer, 00:17:52.310 --> 00:17:55.820 and underneath I have pointing 00:17:55.820 --> 00:17:58.415 at the actual UNC path of the storage account. 00:17:58.415 --> 00:18:01.130 So the reason that hashtag is there is actually that's what you 00:18:01.130 --> 00:18:04.770 do for the DFS-N reconsolidation. 00:18:05.140 --> 00:18:07.835 So there's one more aspect to this, 00:18:07.835 --> 00:18:11.420 which is I've also put a load balancer in front of this. 00:18:11.420 --> 00:18:14.855 So there is my IP address. 00:18:14.855 --> 00:18:18.620 Now it just lets me balance between these two servers, 00:18:18.620 --> 00:18:21.050 primarily for the purpose of ensuring 00:18:21.050 --> 00:18:23.720 that if one of the VMs is down because of an update or whatever, 00:18:23.720 --> 00:18:27.860 you still are able to satisfy the DFS-N directional request. 00:18:27.860 --> 00:18:29.000 >> You do not want to point, 00:18:29.000 --> 00:18:30.470 create a single point of failure, right? 00:18:30.470 --> 00:18:34.100 >> Exactly. So essentially, 00:18:34.100 --> 00:18:37.820 what I've done here is I've created a DNS entry for 00:18:37.820 --> 00:18:39.845 my test server that points out that 00:18:39.845 --> 00:18:43.205 IP address for the load balancer. 00:18:43.205 --> 00:18:46.385 Then the final thing that you do is you mount the file share. 00:18:46.385 --> 00:18:48.650 So without further ado, let's do that. 00:18:48.650 --> 00:18:50.960 So here's my client desktop. 00:18:50.960 --> 00:18:54.635 I'll open up a File Explorer here, 00:18:54.635 --> 00:18:56.900 and I'm going to type in the actual direct path, 00:18:56.900 --> 00:18:59.435 the UNC path of the storage account. 00:18:59.435 --> 00:19:01.070 So let me type that out, 00:19:01.070 --> 00:19:03.305 and I'll type out a TestShare. 00:19:03.305 --> 00:19:05.630 What you see here is it is connected. 00:19:05.630 --> 00:19:07.850 I use my Windows identity. 00:19:07.850 --> 00:19:10.610 Then I'm actually going to do the same thing with 00:19:10.610 --> 00:19:14.300 my DFS-N root consolidated server name. 00:19:14.300 --> 00:19:16.490 This is presumably an existing server that I 00:19:16.490 --> 00:19:18.965 have that I want to take over the namespace for. 00:19:18.965 --> 00:19:22.400 So my TestServer and my TestShare, 00:19:22.400 --> 00:19:25.070 you notice the UNC path is totally different 00:19:25.070 --> 00:19:28.115 but I get the exact same namespace there, 00:19:28.115 --> 00:19:29.750 and to just prove it, 00:19:29.750 --> 00:19:32.330 I'll actually go ahead and create a file and 00:19:32.330 --> 00:19:35.630 show you that it creates the file instantly, 00:19:35.630 --> 00:19:44.165 name the file and even add some content in it and save it. 00:19:44.165 --> 00:19:47.780 When I open it on the other side, it just works. 00:19:47.780 --> 00:19:50.810 So exactly what you'd expect from a file share, 00:19:50.810 --> 00:19:52.340 use my Windows logon identity. 00:19:52.340 --> 00:19:55.070 I didn't have to do any special sauce 00:19:55.070 --> 00:19:57.740 to be able to access this, I didn't. 00:19:57.740 --> 00:20:00.875 >> So it's like your on-prem file share but actually, 00:20:00.875 --> 00:20:03.530 it is the one in the Cloud with your Azure files? 00:20:03.530 --> 00:20:04.580 >> Exactly. 00:20:04.580 --> 00:20:05.840 >> Okay, this is great. 00:20:05.840 --> 00:20:08.135 Now I'm super excited about this because again, 00:20:08.135 --> 00:20:09.830 as I said, we get a lot of questions around 00:20:09.830 --> 00:20:12.300 this and people are super waiting for this. 00:20:12.300 --> 00:20:14.215 But one question I get now, 00:20:14.215 --> 00:20:15.565 having to files there, 00:20:15.565 --> 00:20:16.143 that's great, 00:20:16.143 --> 00:20:17.635 so I have to file soon. 00:20:17.635 --> 00:20:20.110 However, it's now that Azure file shares, 00:20:20.110 --> 00:20:21.384 if I have an identity, 00:20:21.384 --> 00:20:23.995 could I use my existing permissions for that? 00:20:23.995 --> 00:20:26.860 >> Yes. This is obviously one of the big reasons to 00:20:26.860 --> 00:20:30.445 want to mount with your Windows logon identity. 00:20:30.445 --> 00:20:33.220 So basically, when we get 00:20:33.220 --> 00:20:36.835 your Kerberos ticket as part of the SMB mount, 00:20:36.835 --> 00:20:41.585 we get a list of your seeds that's the groups that you're in, 00:20:41.585 --> 00:20:44.630 the various user identities that you have, 00:20:44.630 --> 00:20:47.945 and then we're able to actually authorize against 00:20:47.945 --> 00:20:51.755 access control list or ACLs that are stored on the file. 00:20:51.755 --> 00:20:52.115 >> Okay. 00:20:52.115 --> 00:20:53.540 >> So it's the full thing. 00:20:53.540 --> 00:20:55.485 It's exactly what you'd expect from a file server. 00:20:55.485 --> 00:20:59.930 >> So I can fully replace my file servers using Azure file share? 00:20:59.930 --> 00:21:00.295 >> Yeah. 00:21:00.295 --> 00:21:01.895 >> Okay. Now this is awesome. 00:21:01.895 --> 00:21:03.350 Thank you very much for being here. 00:21:03.350 --> 00:21:05.150 So we put all the links and everything in 00:21:05.150 --> 00:21:06.860 the descriptions of that video. 00:21:06.860 --> 00:21:08.270 So if you want to know more about it, 00:21:08.270 --> 00:21:09.800 we have an announcement blog. 00:21:09.800 --> 00:21:11.840 We have documentation for it. 00:21:11.840 --> 00:21:14.670 You can just go out and try it out.