1 00:00:02,240 --> 00:00:07,600 The next option for deploying VPN services in Azure is using Windows Server. 2 00:00:07,600 --> 00:00:12,270 This is an interesting option, and I think is a pretty compelling one. 3 00:00:12,270 --> 00:00:16,850 But it does have a rather serious limitation or drawback to it, 4 00:00:16,850 --> 00:00:18,440 which we'll discuss here shortly. 5 00:00:18,440 --> 00:00:23,320 But the advantages to deploying Windows Server RRAS, 6 00:00:23,320 --> 00:00:24,850 Routing and Remote Access Service, 7 00:00:24,850 --> 00:00:29,060 on Windows Server in Azure are that it's really easy to deploy. 8 00:00:29,060 --> 00:00:33,380 It's, you know, spinning up virtual machines in Azure is quite simple. 9 00:00:33,380 --> 00:00:37,840 Deploying Windows Server and configuring it for RRAS is not terribly difficult. 10 00:00:37,840 --> 00:00:42,640 You saw how we did that earlier in this course in some of the earlier lessons. 11 00:00:42,640 --> 00:00:45,530 It's not terribly difficult to get things installed and 12 00:00:45,530 --> 00:00:49,200 configured to support VPN on Windows Server. 13 00:00:49,200 --> 00:00:54,750 I like it because it scales very effectively, so you don't have to scale up. 14 00:00:54,750 --> 00:00:56,820 You can just very easily scale out. 15 00:00:56,820 --> 00:01:01,880 I could deploy 2, 3, 5, 20, 100 VMs in Azure, 16 00:01:01,880 --> 00:01:06,660 if I wish, to meet my demand, and just place them behind a load balancer, 17 00:01:06,660 --> 00:01:10,040 and it will run happily and very effectively. 18 00:01:10,040 --> 00:01:13,650 The other advantage to using Windows Server RRAS in Azure is that 19 00:01:13,650 --> 00:01:17,840 you get full support for the full suite of tools and options 20 00:01:17,840 --> 00:01:20,440 available to you as a part of Always On VPN. 21 00:01:20,440 --> 00:01:21,160 For example, 22 00:01:21,160 --> 00:01:25,470 you now can support both device tunnel and user tunnel on the same server, 23 00:01:25,470 --> 00:01:26,770 so that's a huge win. 24 00:01:26,770 --> 00:01:30,340 That was a serious limitation of the native Azure VPN 25 00:01:30,340 --> 00:01:32,450 infrastructure is that you had to kind of choose one. 26 00:01:32,450 --> 00:01:35,880 It was either going to be device or user, but never both. 27 00:01:35,880 --> 00:01:41,590 For the organizations that are either hybrid Azure AD Join and still, 28 00:01:41,590 --> 00:01:45,710 you know, are still joining their devices to on‑premises AD, 29 00:01:45,710 --> 00:01:48,370 and again that's a perfectly valid deployment scenario, 30 00:01:48,370 --> 00:01:50,900 the device tunnel is really helpful in those scenarios, 31 00:01:50,900 --> 00:01:52,850 and here you don't have to pick and choose. 32 00:01:52,850 --> 00:01:53,780 You get both. 33 00:01:53,780 --> 00:01:55,450 You get to have your cake and eat it too. 34 00:01:55,450 --> 00:01:57,960 You get the device tunnel and the user tunnel. 35 00:01:57,960 --> 00:01:59,380 And importantly, 36 00:01:59,380 --> 00:02:03,520 deploying Windows Server RRAS in Azure still allows you 37 00:02:03,520 --> 00:02:05,590 to support geographic redundancy. 38 00:02:05,590 --> 00:02:09,760 So I could have VPN servers in multiple Azure VNets in 39 00:02:09,760 --> 00:02:12,150 multiple regions spread across Azure, 40 00:02:12,150 --> 00:02:16,920 and then I could just simply use DNS round robin or Azure Traffic 41 00:02:16,920 --> 00:02:21,240 Manager or some other GSLB to route traffic intelligently. 42 00:02:21,240 --> 00:02:27,730 Also, in this scenario, you can have VPN servers running in Azure, 43 00:02:27,730 --> 00:02:32,370 and they will happily coexist with other VPN servers running on‑premises, 44 00:02:32,370 --> 00:02:35,760 so you can use this as a backup. 45 00:02:35,760 --> 00:02:39,230 So you could basically have all of your traffic go on‑premises 46 00:02:39,230 --> 00:02:43,190 and then failover to Azure if it's unavailable. 47 00:02:43,190 --> 00:02:46,430 You could load balance it in terms of percentages. 48 00:02:46,430 --> 00:02:49,340 You might spin off a percentage of traffic to Azure. 49 00:02:49,340 --> 00:02:52,500 It really doesn't matter, it really plays well, 50 00:02:52,500 --> 00:02:55,160 and it works quite effectively, and it's a really, 51 00:02:55,160 --> 00:02:56,390 really good solution. 52 00:02:56,390 --> 00:02:58,200 But again, as I mentioned before, 53 00:02:58,200 --> 00:03:01,730 it does come with one rather important drawback, 54 00:03:01,730 --> 00:03:08,440 and that is the RRAS workload is not supported on Windows Server in Azure. 55 00:03:08,440 --> 00:03:11,140 That is just a form of Microsoft support statement. 56 00:03:11,140 --> 00:03:15,380 It is not a supported workload on Windows Server in Azure. 57 00:03:15,380 --> 00:03:17,270 Now, 58 00:03:17,270 --> 00:03:25,030 a widely recognized enterprise mobility expert has often been quoted as saying 59 00:03:25,030 --> 00:03:29,240 that "Not supported is different than doesn't work." And so, 60 00:03:29,240 --> 00:03:34,550 I would encourage you to take a hard look at this option because I 61 00:03:34,550 --> 00:03:40,310 have deployed RRAS in Azure for many customers, and so far, 62 00:03:40,310 --> 00:03:42,120 everyone's had a great experience with it. 63 00:03:42,120 --> 00:03:45,050 There doesn't seem to be any other technical limitations or 64 00:03:45,050 --> 00:03:47,250 drawbacks that prevent this from working. 65 00:03:47,250 --> 00:03:48,800 And so, at the end of the day, 66 00:03:48,800 --> 00:03:53,200 if you can support the limitation of the lack of support, 67 00:03:53,200 --> 00:03:56,840 so if you can handle that and accept that, 68 00:03:56,840 --> 00:03:58,600 this is a fantastic solution, 69 00:03:58,600 --> 00:04:08,000 one that works quite well and one that I think you'll find really meets the needs of your organization quite well.