- Welcome to Episode 175 of the Microsoft Cloud IT Pro Podcast recorded live on April 24, 2020. This is a show about Microsoft 365 and Azure from the perspective of IT pros and end users, where we discuss the topic or recent news and how it relates to you. In this episode, Ben and Scott discuss Azure file shares for client devices, domain controllers, Azure AD networking and other cloud services and how they all fit together.

- The thunder is never done, all the tornadoes rolling through. It was nasty last night.

- You know what? I did not hear a thing. I may or may not have been up until like, 2:30 the night before working on stuff and then I crawled in bed at like 12:30 last night. I was so tired, I passed out and I woke up when one of my kids came in our bedroom at some time, 4:00 a.m. and my wife was like, "Did the thunder wake them up?" I was like, "Was it thundering?" I never heard a thing.

- Man, corona times have not been kind to my sleep schedule. It's turned into like, aah, let's watch a movie and then the movies over and it's aah, maybe I would like just one TV show or let me read this book for a little while or whatever it happens to be. So I think last night, I was up until... Last night, I was late, it was 3:00 a.m., hence, my coffee brewing slowly this morning. So I heard that whole storm all through and the whole thing. I was sitting in my kitchen, it was awesome coming through, it was a good one. I like a good storm.

- So I woke up and I was actually bummed it didn't wake me up 'cause I'm the same way, I love a good thunderstorm, especially at night. For whatever reason, those night thunderstorms and the lightning lights up the whole house and the thunder just rolls. I don't know, it's cathartic for some strange reason, as long as there's not a tornado blowing my house down.

- Yeah, well, there's that whole thing, but it was definitely a good thunder and lightning storm and it was tornadoes and stuff farther to the north, but not so much for us. So, it was just a good rain event.

- Yes, I will say not growing up in Jacksonville, I have been impressed with the geographic surrounding of Jacksonville and how it seems to deter most storms from hitting us. Like we never really seem to get tornadoes or really bad storms from the west because of the river and because we're sitting just down low enough. I think the Gulf of Mexico messes up a lot of them and then the way Jacksonville's kind of set in on the coast if you're going up the Florida coast and up in the Georgia and South Carolina, it seems to deter any hurricanes from really having a direct hit on Jacksonville.

- Yes, it is the farthest point west on the East Coast. Like when you think about that dip in, so it's not just Florida to Georgia and all that, like pull out a map and look all the way up, it is the farthest point west, from Maine all the way down to us.

- What about the Keys? Don't the Keys loop back into the west?

- They do, but they're sitting actually like--

- They're just sitting in the middle of the ocean.

- They are, right? But they're all the way down at that eastern tip of Florida is, think about like going down to Miami and you're pretty much a straight line down to the Keys from there. So they are still farther east than we are, but as a chain of islands, they stretch pretty far over, but at that point, they're underwater anyway .

- Got it.

- So as a landmass with too big bodies of water like you talked about, between the ocean and the river, being a pretty substantial river, but at least nice and wide, it's good enough to pick up a lot of the weather that comes through here.

- I remember that growing up in Michigan too. I mean, like Michigan is significantly bigger than the river but Michigan was spared at least a lot of the bad thunderstorms and tornadoes and all of that because of like Michigan. They would hit Wisconsin, the lake would break it all up before it hit Michigan. I went and spent a week in Wisconsin. It was like tornadoes every day. Don't go to Wisconsin.

- Don't go to--

- Sorry to anybody that's from Wisconsin that's listening. I much prefer Michigan to Wisconsin.

- You're gonna start a fight or something.

- Probably. I have some good stories about Wisconsin and Michigan, but we don't need to talk about those today.

- As IT professionals in the cloud era, sometimes it feels like we don't speak the same language as the rest of the organization. So when stakeholders from finance or other departments start asking about a specific project or Teams Azure costs, they don't always realize how much work is involved in obtaining that information, sifting through cluttered CSVs and a complex mess of metadata in order to manually create custom views and reports. It's a real headache. On top of helping you understand and reduce your organization's overall Azure spend. ShareGate Overcast lets you group resources into meaningful cost tabs and map them to real world business scenarios. This way you can track costs in the way that makes most sense with your corporate structure, whether it's by product, business unit, team or otherwise. It's a flexible, intuitive and business friendly way of tracking Azure infrastructure costs and it's only available in ShareGates Overcast. Find out more on sharegate.com/itpro.

- Should we talk about what I was staying up late playing with today?

- Yeah, it sounds like you were staying up late doing things that I was not. While I was watching, crappy movies and contributing to Netflix viewing hours, you were doing real work, supposedly.

- Well, so supposedly 'cause it all started with a client question which led to me playing with this, with my own domain and Azure tenants 'cause I don't wanna break anything. So, to set this up, Azure Files with... So Azure Files has been able to do SMB for a while. You can use the like storage account name and the private key to actually map a network drive to Azure Files, all of this. They have recently and I think it's still certain aspects of this are still in preview.

- Yes, they are.

- They rolled out the ability to do Azure Files over SMB, leveraging either Active Directory or Active Directory Domain Services to authenticate users to the file shares, rather than using a storage name and a key so that all of those NTFS type permissions can be used or supported through a mapped Azure file share. But there are a ton of restrictions and requirements and prerequisites around doing that, which could lead to the question that we were actually debating before we started recording of should you actually do this and if you do this, what all do you need to think about? Because this has led me down a massive rabbit hole of VNets and DNS and AD and AD DS and all of that.

- Yes and you're leveraging preview services, which is even, well preview functionality I guess, which makes it even more interesting. So, when you initially came and you had asked me the question of, okay, I'm trying to stand up a file share and I'm doing the domain authentication thing and it's really a pain and in the back of my head, I'm thinking isn't that relatively new and probably in preview and my first question back would be, well, why do the preview functionality, right? Especially, if it's for a customer. Like typically, we don't wanna take customers into preview stuff, even if it's public preview, because if we just consider Azure life cycle, there's no guarantee that a preview service ever actually goes GA'd. So obviously, Azure Files is GA'd and all that kind of stuff and it's sitting there ready to go, but Microsoft could look at this feature where they're doing SMB file shares with AD, with Azure AD rather, and with on-prem AD and they can say like, "Yeah, I don't wanna do on-prem AD anymore, "I'm only gonna do AD "because that's an easier scenario to support."

- Well, but it's not just AAD, it's AAD DS. It doesn't support AAD.

- Yeah.

- Remember? We gotta clarify these two.

- I get my storage confused because there actually are parts of storage, like blobs and containers which do support Azure Active Directory for role based access controls and things. So you can totally do AAD authentication there. Anybody who thinks Azure Storage isn't a confusing service being that it's a storage account, but it's not just a storage, it's blobs, its files, it's tables, its queues, its disks, it's--

- Right, it's got sub services.

- It's static websites, it's like 10 other different things, it's amazing.

- Azure Files are gonna be like the Teams of Office 365 or everything's just gonna get sucked into the storage fortex.

- Well, if you think about it, storage is kind of important, right? In the grand scheme of things and the overall fabric because what is Azure? It's a bunch of hosts who are running hypervisors and it's a bunch of file servers that are pulling configuration off of storage controllers and things like that, right? So, at the end of the day, storage is what makes--

- Storage is important.

- It makes the world go round.

- Which is digressing. So, this whole storage authentication thing, I'm not gonna say it's just Azure AD DS. Should I go through the prerequisites and what I found and then we can keep talking through this scenario?

- Sure, just to lay out the scenario, what you're trying to do is you're trying to stand up a file share in Azure that is available to clients, not to other servers that exist out there.

- Yeah, so you're not going to a server.

- But to individual clients and you require per user authentication from each of those clients to the file share, right? Okay.

- Right. So, scenario being client does not want to use SharePoint or OneDrive because they don't want to deal with the whole sync thing and files and demand thing and having to access the browser and maybe not being able to sync all their files based on hard drive sizes and all that. They like traditional file shares on-premises, but they want to be in the cloud, they wanna be able to work from anywhere. So, said client wants to be able to go to Starbucks or go home or be in the office and be able to map to their network drive the same way they would if they're on-premises and they're not a huge client, so they actually don't have a current VPN to get to their on-premises server from off premises. They can't VPN into their office. Internet connection is okay, but it's not like a large enterprise network that has Cisco, has VPN, has all of that stood up. So they were like, well, what if we just move everything to the cloud and we can map this network drive from anywhere using our traditional AD usernames for securing all of this across all of our users?

- I always love when customers come up with their technical solution, right? Like they have a business problem they're trying to solve. The technology that solves that problem really shouldn't matter as long as it aligns to the business outcome. So, what is the process, the workflow or the outcome that we're trying to solve and then you can backfill technology around that. They're going backwards. They're coming to you with the technology and saying, "Hey, make this work." And then--

- Yes, because I had spent some time with them. We looked at SharePoint for maybe six or seven months and ultimately the decision was, we don't wanna use SharePoint. We want to use Azure Files. So, I was tasked with figuring out can this be possible, does this work, especially given some of these new features combined with preview? So for this all to work, you do still require Azure AD, but it also requires either an on-premises AD server or Azure Active Directory DS or Domain Services. So you have to have one of those two synced with your Azure AD and have your users synced in both places and then you can go configure this file share for either Active Directory authentication or Azure Active Directory DS authentication, but it's still also using Azure AD in the background.

- Correct.

- And the problem we started running into, well, the first problem we ran into is SMB 3.0, which Azure File uses, goes over port 445.

- It does.

- Almost every ISP block's port 445.

- They do, true story.

- So, first problem was okay, we need VPN for it, which we can talk about that more later and then we got VPN setup, we started testing this and there's a bunch of prerequisites. Your machines either have to be Hybrid Azure AD joined or they have to be AD joined, but once you get all this set up and configured, when you go to authenticate to map your network drive, your computer, even though it's using Azure AD synced with AD Domain Services or AD, it like, reaches out, but then it's like, oh, I also still have to use Domain Services or Azure AD. So it requires access to both Azure AD using new UPN and Azure AD, but then it like takes a side route and goes and has to ping to your domain server or your Azure Active Directory Domain Services server to actually do the verification for your map network drive, which means that if you're at home or if you're somewhere not in your local network or anywhere for that matter, you have to be able to properly authenticate against either a domain controller or Azure AD Domain Services wherever you are, which means that it has to either go over that same VPN that you can use to bypass the port 445 rule or it just has to be a publicly available domain controller, which we all know is a bad idea.

- Yeah, almost kind of like gives you the sense of that as you talk through it and the requirements, that while it works with clients like Mac and Windows, like it works with Windows 10 and generic SMB mounts and totally doable with a Mac and things like that. It's almost like they're not meant to be used that way.

- Yeah, yeah.

- Back to that shoehorning functionality .

- Yes, exactly. But, what fun would life be if I didn't try to shoehorn in some functionality that wasn't meant to be using preview features?

- Oh boy.

- I like to live life on the edge.

- Yes, it's a fun world you live in. So you have a number of problems or technical blockers that you need to solve along the way there. You need to configure identity in the cloud. So, some type of probably replication and resiliency on the domain side of things.

- Because the first question there is, do you do a server, running Active Directory in the cloud and replicate or do you use Azure AD DS? You need something in the cloud.

- Yes, so there's that piece and that's certainly its own can of worms and decision matrix right there. And then, you also need a VPN, as you said. So, where does that VPN endpoint leave and how are your clients going to connect to that VPN? I'd imagine maybe one of the first inclinations is, you might think in the back of your head, well, I have clients, let me connect the clients through Point-to-Site VPNs and just hook them straight up to the gateway. There's some limitations to Point-to-Site VPNs depending on the size of your customer. There are limits to the number of connections that you can have going in at any given time, which could be a limiting factor for you there. And then once you're into the VPN, there's all the routing and network security and other things that need to come into play for that client to not only talk to the DC itself, but to be able to get back to Azure Files and do all that fun stuff.

- Yes. I think you covered the biggest ones that I've encountered so far.

- Yeah, those would be most of them. So let's break some of down 'cause I think it's an interesting conversation just based on some of the paths you went down and some of the things potentially broke and we can probably talk through why they broke or why they work that way and maybe we'll leave like the whole decision about should you attach clients to Azure Files up in the air.

- So, first problem was domain controller, do I go the Azure AD DS route or do I put another server up in Azure that's just a server 2016, I think server 2019 is out there, stand it up as another domain controller and do domain replication from on-premises to the cloud.

- Yap, well, I might ask myself another question first. So, is your customer going to have more than one 128 connections at any given time, like, are there more than 128 clients that need to connect to this file share?

- And that would be a no. This is like 10 or 12 users connecting occasionally because most of the time they're in the office, which also brought up that Azure File Sync, could come into this at some point in time. They want to be able to connect to the cloud as their backup option.

- Got you.

- If they're not in the office. Something like when this whole last month happened and all of a sudden, nobody can get to their file shares unless they're in the office because they have no VPN.

- Gotcha, gotcha. All right, so that makes more sense. That's all good. Once we get through this whole thing, I might spin it on you and ask you why you didn't go another way with it 'cause I'm coming up with some other ideas as we talk through it.

- We'll see, that's good 'cause I could use... I always like more ideas. All right, so connections, we aren't a problem.

- So we need a VPN and we know we're going to be under the limits for Point-to-Site VPNs and standing all that. So we're good there, so we know we're gonna need a VNet and we're at least gonna need a VPN to connect to. And now, like you said, we need to figure out what domain or directory service are we going to leverage. Are we gonna leverage Azure Active Directory Domain Services, which is AD DS, but it's a projection of your Azure AD into a pair of managed domain controllers. So DCs that you don't RDP into, but you do have access to hook up with things like, a doc and all your tooling that you use today to manage Active Directory. So that's one path you can go down. So don't pay for servers, but pay for the service and the projection and the resiliency and SLA and everything comes with that or stand up your own and manage your own.

- Yap, which standing up and managing your own is definitely cheaper. I looked that Azure AD DS and I think it starts around $140 a month. It's a set fixed price 'cause obviously, this isn't a service that you can spin up and spin down, it's just always running. So it starts at 140 and goes up from there based on... I can't even remember, I think it was based on number of users and there's some functionality that's included in different levels, but it's not cheap considering you can stand up a whole server for like 50 or 60 bucks and AD is not a process intensive service on a Windows Server, but you are left with managing a Windows Server and you don't necessarily have HA.

- Well, you do have HA, so they are redundant pairs.

- Well, not in the DS, not if there's you spin up you own server, unless you spin up two servers.

- Not if you spin up your own. All right, yeah, so if you do AD DS, it is a redundant pair, but if you do your own server, then it's on you to figure all that out and then come up with your resiliency model, are you going to use single instance VMs with premium disk to get some type of SLA at least at the VM level? Are you gonna do availability sets? Are you gonna do zones? What does that look like and how many do you actually need?

- Yep, exactly. And then you're doing all your own patching and server management and if that server crashes and all that.

- Yeah, you're living in IS land for sure.

- Yap, so I asked about... And then I was talking to you a little bit the other day and I said okay, so what does that migration path look like? Let's say I have AD on-prem, I want to go all cloud only. So I'm doing AD on-prem Hybrid with Azure AD to sync all my users up, but now I'm getting rid of all my on-prem servers. So maybe I just wanna go Azure AD DS and deprovision my on-prem AD. Is that a migration path or what does that look like to go cloud only with Azure AD and Azure AD DS and then deep provision that Hybrid Azure AD Connect service and my on-prem AD server.

- Yes, it doesn't eliminate the VPN problem and having to connect to the DCs 'cause you still have that client authentication issue to get over.

- Right, and you still need your VPN for your port 445 going into another topic. So, there's no way to get around this VPN issue.

- You do, so all that stuff stays. Really what you've done is you shifted your... At that point, you've shifted your DCs from on-prem to Azure just inside of IaaS. But you've still got the hookups and the conductivity and all the other things that come in. So I'd be worried about a couple things in there in general, by saying my DCs are only gonna live on the cloud. Since you said your users are theoretically in normal times in the office, the majority of the time, I would want them talking to the most network close authentication service that they could. And then maybe if they were going into something like Windows Virtual Desktop or something like that up in Azure, then okay, there's your kind of file share, and you're all set and ready to go and you've got your DCs up in Azure. But if you really wanted to get rid of them, you would do AD Connect. So you would do your hybrid identity, and do all your projections from on-prem to AD. And you could configure AD DS at any point in here, 'cause that's just a projection from your Azure AD. And then once all your identities are there, and all the things that you need to do, 'cause all AD Connect is gonna do is synchronize users groups, and kind of some limited in the grand scheme of things metadata up, it's not synchronizing your computers that are showing to the domain. So that's a whole nother issue that you'd have to solve. But you could take AD Connect, and then once everything's up there users and groups, just rip AD Connect down, get everything, all the synchronization going into the new domain, rejoin all the computers to the new domain that lives up in Azure, 'cause they've got to get back in there, right? You're probably still gonna wanna manage them with GPOs and things like that. So all that gets in place and then stand down the on-prem DCs. Now I think one of the issues there is AD DS was not a real replica of your on-prem domain. So it's not all the same FSMO roles and everything else. If you don't catch everything, there's potential that you leave something behind, you'd almost want, like if this is really for backup, maybe a redundant pair of read only DCs or something like that up in Azure, that are ready to go that somebody could hook up to through that VPN on a Point-to-Site perspective. And they'd authenticate to the most network close DC. Or if they were on-prem, they'd still be able to authenticate to the one that's there. Best of both worlds maybe.

- Yeah, so it's not really a migration from AD to AD DS. It's more of a let's go have all three of them running. And then let's just remove one and make sure that you manually copied, rebuilt, did everything in Azure AD DS that you had in your on-prem DS.

- Yap, you've just got to be very cognizant of the limitations of AD DS as a projection from Azure AD, it's not the same exact type of thing. So yes, it lets you join computers and servers to domain. Yes, it has GPOs. But it doesn't have all the functionality that you're gonna get in your on-prem AD. And especially when I think about client management, you're probably doing GPOs that rely on things like ADMX templates. Maybe you're managing Office client installs, or I'm sorry, Microsoft 365 Apps for enterprise 'cause you haven't moved--

- I just wanted to say, I was trying to figure out how to get you to say that this episode.

- I had to say it twice this week in a presentation and it feels really dirty, like what, just Office Pro Plus people.

- That's a mouthful.

- It is. But you still have management that you need to do there. So then do you look downstream of saying, well do I move over to cloud policy or some other type of service, which, arguably--

- Like what it's been up into, right?

- Right, there's all these options out there. But all you wanted was a file share. And now all of a sudden, you have this technical implementation and the spread of things that operationally is turning into a little bit of a nightmare, who's gonna maintain all this stuff and keep it patched and up to date and ready to go and write all the guides for what do we do when the VPN is down and everything else that comes along the way. So that's kind of AD DS, I think when you weigh the two out in a lot of scenarios, AD DS has a place. It's quite often the path of least resistance when I think about like friction and time to implementation to just stand up new DCs, As you said, they're often cheaper to run, they can run on lower cost hardware and lower cost VM sizes, you might wanna upsize them while you're kind of configuring everything the first time and then scale them down a little bit later once everything's up and running. But it tends to be a known path, where AD DS can still have some pain points, especially if you haven't worked with it before. And you haven't really taken the time to dig through all the documentation and the FAQs and things like that.

- Yeah, I feel like going through all of this as I was digging around with it and playing with it. AD DS serves a purpose a lot more when you're gonna keep all your existing on-prem domain controllers. And Azure AD DS is simply a way to extend your Active Directory to the cloud in order to do just LDAP authentication against a cloud service without standing up another VM in the cloud.

- Yep, that seems to be what I'm seeing. I've actually used it. I've seen it used in some creative ways. And I had a customer that we ended up going down the AD DS path for, just based on how they were set up. So they were a customer who had a number of disconnected domains on-prem, that didn't have trusts or anything like that in place. So they couldn't stand up AD Connect once and have everything routed through from all these domains, user at Contoso, user at Fabrikam, all those kinds of things into AD at the same time, but relying on some of that functionality that you have where you can do the disconnected domain sync now. And you can bring all those disparate domains for those M&A scenarios into Azure AD. And what they were able to do was they were able to take six different disparate domains and user namespaces, all those use your UPNs, get them all sinking into Azure AD, which was something they didn't have access to, they couldn't put them all in the same resource domain or user domain or things on-prem. And then they were running a lot of their shared services in Azure. So every server that they stood up in Azure was joined to that AD DS instance, it wasn't joined back to company ones AD or company twos AD or company threes. And that way, if I was a user from company one, or company three, or company five, I could log into the servers in Azure to do operations and management, and run my applications. And I was able to authenticate through and do all the things that I needed to do, 'cause servers still need, like this classic auth, Kerberos or NTLM, and all that good stuff. There are use cases for it. I think you just need to understand what your use cases are. If you're just looking at AD DS and saying, alright, this is gonna be a rip and replace, replacement for my existing Domain Services. Quite often, I don't think that's exactly the case today. Give it time and it'll probably get there. It's just not there today.

- And we don't currently know when it'll get there because it has been a slow deployment or rollout.

- It has some quirks to it. I've seen AD DS deployments where you go and you stand it up the first time and you go to do your sync. And it doesn't matter if you have five users in your Azure AD or you have 25,000. You'll just hit the sync button, and you might come back like 48 hours later, and it hasn't started sinking yet. And then you go, oh, what do I do? How do I fix that? The answer is you don't, you call support and hang on the phone.

- And wait a long time. Interesting.

- All right, so you go down that path and I think you weigh the two out, you probably look at DCs.

- Yep, and that's kind of, as I've played with it, and looked at it. And as we talked about it the other day, and even based on what I've seen, you have pretty much convinced me that if we go down this route, that is the way to go in this particular case, which lead to question two. But based on time, we should probably do question two next time, or should we keep going have a really long episode? Let's keep going, it's corona times.

- Okay, yeah, nobody's listening. Nobody's driving anywhere to listen to the podcast, our numbers have actually dropped. It's kind of interesting. And I've seen that side tangent, kind of across the board. I'm in a few different podcasts groups and all of that and people are saying, overall podcast numbers seem to have declined because nobody's commuting anymore. And that's what everybody listen to podcasts.

- Yeah, I'm finding as a rabbit podcast listener. I mean, I subscribed to a lot of podcasts and listen to a lot of things. I'm just falling behind. It's the drain of the times that catches up with you. So where I might have gone and been done with work and just tried to decompress for 30 minutes. Now it's turned into kids are at home, everybody's at home, things are going on, and all of a sudden there's that other Zoom invite for like a happy hour and you haven't talked to people in weeks 'cause you're quarantined and you like, aah I gotta get like, your self isolating or whatever it is, you just have all these other competing things going on. And I am falling behind on all sorts of things which I intend to listen to at some point. It's just gonna take me a while to get there.

- Yep.

- Outlook Add-ins are a great way to improve productivity and save time in the workplace and Sperry Software has all the Add-ins you'll ever need. The Save as PDF add-in is a best seller and is great for project backups, legal discovery and more. This Add-ins saves the email and attachments as PDF files. It's easy to download, easy to install and Sperry Software's unparalleled customer service is always ready to help. Download a free trial at sperrysoftware.com, sperrysoftware.com and see for yourself how great say this PDF is. Listeners can get 20% off their order today by entering the code Cloud IT. That's Cloud IT, C-L-O-U-D-I-T all one word at checkout. Sperry software work in email, not on email.

- Okay, so after that side topic, after that brief commercial on podcast listenership, tidbit of random information. So let's just say for argument's sake, we've decided we're gonna put our DC in the cloud, Azure, it's a server we're doing IS we're gonna stand up a brand new domain controller up there. Now I have all my machines that are still on-prem. And I am going to, again, for argument's sake, because we wanna shift to this whole cloud only model, we are going to eventually will replicate AD for now, but eventually that on-premises domain controller is gonna get depreciated, removed. So our only domain controller is gonna be in the cloud, but I still want to be able to join machines to it. I still need to authenticate against it for something like, Azure file shares and the scenario we talked about. Now I have a whole other set of problems or challenges, I won't call them problems, challenges or things to think about because I have to be able to connect to it to go into my computer, my settings, join domain, and then actually reach out to that domain controller, especially in the case which my own tenant is in this case where I wanted my domain to sync up to Azure AD properly. So my UPN suffix is intelligent.com, which is also my website, which also has public DNS records. So DNS resolution can be a little challenging because I need intelligent.com to resolve to my internal domain controllers, as well as to my external domain controllers if I wanna hit my website, and all of that, going over this VPN connection to it hit my DC.

- Yes.

- Does that make sense?

- It does. Basically, if you wanna be able to authenticate to the DC, you have to be hooked up to the network. And that means you need all the routing and game resolution and other things in place.

- Yes. So I am partway through that. I think I might have it figured out, but we had to record a podcast. So I'll go back to it today. But essentially, same type of thing. I'm using the same VPN gateway because I needed that VPN gateway anyways, for my Azure file shares over SMB. And what I was struggling with last night was to get all of my DNS settings set up properly. So I could join a Windows 10 machine that's running as a VM on my laptop, connected over VPN to join this domain controller sitting up in Azure and the leverage the DNS in Azure so that I actually hit that instead of going out and trying to hit my public website when I tried to join the domain. So my DC up there has, oh and stop this all off. Don't ask the story behind this. I have two virtual networks that I have peered in Azure AD. And my domain controller sits in one virtual network and my VPN gateways sits in another virtual network. So I'm connecting to VPN, connecting to the virtual network in Azure, going over the peering connection between one virtual network to the other virtual network in order to hit my domain controller sitting in said network.

- Yap, so you got a hub spoke.

- Because I like to make things complicated.

- You're trying to make your 12th person entity the largest enterprise in the world.

- Well, this is just my personal, this is a one person entity. This is me right now.

- You and all the voices in your head that told you this would be a good idea to go down this path. Yeah, some interesting things start to happen along the way there I think, as you discovered, particularly with name resolution, when you have a VNet in Azure, there's kinda three DNS models that you can go with, you can do Azure provided DNS, which gives you resolution within the VNet itself. So I stand up VM one and VM two. And I can ping VM one and VM two, and they'll resolve by name, and all those kinds of things, I can do and I slick ups and CM, and I can actually pull their private IPS and I'm all good. Sometimes you don't wanna do that. And you wanna do, bring your own DNS. So you do BYOD DNS, and you take your VNet, and you set your VNet settings to say, no, this is my DNS server. That way, when clients query the VNet for DNS, it's going to point them back to your domain controller, and go like, oh, why are we doing this VNet level, because remember that's where all your network configuration is driven from, you really don't make changes to the NICs on VMs in Azure, you make changes to the configuration of the virtual NIC outside and then that's projected down to your virtual machine, or your virtual machine gets its configuration from there. So you've got to have that resolution end-to-end. So peering is kind of interesting, because you've also got peering with a VPN gateway. So you now you need to allow gateway transit on one end, but not the other end. And you need to make sure that your potential routing and things are in place, you might need UDR at some point, depending on how else you wanna shift traffic around in there. You get all that up and running, I bet your primary VNet, you were going in and saying like, "Oh, this is great. "I'm gonna set it to my custom DNS." And if you stood up VM one next to DC one, they would totally resolve and they do what they need to do. But you introduced that VNet peer. Which then makes resolution a little bit weirder 'cause your client, so you're hooked up on that Point-to-Site VPN or Site-to-Site whatever you're using. So your client now, where is it pulling its DNS from, it's pulling its DNS from the same VNet as the VPN gateway, which most of us I think, would just leave in Azure provided DNS by default. Because it's just a hub, right? It's sitting there doing what it needs to do, let it do it.

- Right, which is what I did.

- Yap, you might see the VM on the other side, but it's gonna resolve as the internal name with the cloud at .net, and all that, and not as the proper NetBIOS name that you're gonna need to join the network. So probably some more configuration to do where now you take the peered network and the peered network that or the hub rather, is also needs to have its DNS configuration updated, so that it pulls its DNS from the DC over in the spoke.

- Yeah, and that was the hint that we found for anybody that finds themselves in a wonky scenario such as myself. I was going out and pinging it and I was like, well, when I do an NsLookup, and I'm looking for my domain controller, it's coming back with this internal.cloudapp.net, not my domain and you were like, I bet your DNS was wonky in that VNet that you have your gateway in. And low and behold, it was.

- Yep, so that's one option is go down that path. The other option is, if you're just doing this for POC, you can't use a host file because of the whole SRV record thing the server records, but you can use an LMHOST file to go ahead and point to your DCs. It's a pain in the proverbial rear end to set it up. But you can do it. I think the other thing to think about is identity is really a core service. It's typically, maybe when you just look at kinda your topological design and you're thinking about how to approach that with your customer, your identity, your firewall, your logging and management. Those are all core services, right or shared services. They're not really application or kind of segment specific. So something like your DC may not actually be living in a spoke in your final configuration, it might be closer in the hub anyway, which will make things a little bit easier.

- Yes, in theory, had I done this properly, and I didn't already have some of these VNets configured and I was paying attention to what I was doing at 2:00 a.m. the other night, I would have just put my gateway in the same VNet with my domain controller instead of in a separate one. And at this point in time now, it's just can I actually do this? Realistically, I should probably just go delete my gateway and go standard up in my other VNet and save myself some hours. But again, I get into this and I look at this as learning and figuring this out. And how does this all work together? And can I get it to work? Not necessarily, is this the way I should do it?

- Absolutely, I'm not saying you shouldn't try things out.

- Yes, but I've wholeheartedly agree with you.

- I just wanna make sure we have the conversation in case somebody actually does end up listening to this and they go, "Oh, that's people are going down some crazy path." Or somebody looks at it and they're like, "Hey, they sound like they know what they're talking about. "Maybe I should go do that." I always like to talk about the other ways you can do it too.

- Yes, don't do it the way I did it unless you have a very specific reason other than it was 2:00 a.m. and I created my gateway in the wrong subnet and I wanted to experiment with is.

- Alright, so DC up, client connects and VPNs there. Theoretically, you can just hook up to files now.

- Theoretically, I think, oh, so Azure Files now gets really weird. Should I talk about Azure Files in the security there?

- Absolutely.

- So as they rolled all this out now, we can connect, we're gonna assume that you can... So first thing you should do with Azure Files is once you get all of this figured out, go connect with the storage account in the key to make sure you can actually connect that your routing is going properly. Because at this point in time, assuming you're connected to VPN, you have your network set up right. Download the VPN client to, this is another thing. There's a VPN client that does an executable that goes sets up the whole network and the routing and everything in your Windows 10 machines. Don't touch that until your network is all configured. Because what that executable is doing is downloading a configuration file making a bunch of changes. If you change your network, your VPN client doesn't get that change. And you actually have to just disconnect, remove that VPN connection, go download it again, go set it up again, and get all those network changes. So we're gonna assume all of that took place. I can connect with a storage account name and key. But now I wanna connect using my username instead of that storage account key so I can leverage all the normal NTFS file permissions and permission folders in this Azure file share differently and all of that stuff. So first, the machine you do all this from has to be domain joined and there's some certain PowerShell scripts, you have to go run to actually set up your file share in Azure to be able to authenticate against AD. And those do have to be run from a domain controller, so you go run those scripts. Now your Azure Files are set to authenticate with an AD server. And there are a couple levels of permissions that you need to set and the documentation does walk through all this, but you have to set the RBAC permissions on the file share itself. There are three permissions in RBAC for SMB, specifically, an SMB, I think it's an SMB file reader, an SMB file contributor, and an SMB... It's like, it's not advanced contributor, it's something else, but it's another level up from contributor. So the first thing you have to do is go in set these RBAC permissions. This is gonna look against Azure AD for these RBAC permissions, which is why you have to have everything synchronized together. That does not give you access to the file shares that just gives you that RBAC permission to leverage the Azure service. Now you can go mount it, again with that primary key and your storage account name, and then right click in Windows and go into the properties in security, and then start setting the security on the shares and the folders and the files looking back against your domain controller. So there's both of those permissions that have to be set. And then once all of that is done, assuming whatever client you're connecting to, can connect to both Azure AD and to your domain controller. You can go in and do a typical net use, point it to the Azure file share, you can do a slash you and throw in your UPN from Azure AD, or you can just do the net use and it'll prompt you for a username and password. Type all that in and in theory, you have a map to network drive that's using your typical permissions coming from a domain controller.

- Mm-hmm, in theory.

- In theory, again, taking all those prerequisites and everything we just talked about being configured perfectly for that to even work.

- Yes.

- And there you have it. And there was something else I had to do. I'd have to dig through it. But I did also have to create a private endpoint for my Azure Files. And I can't remember at what point in time they hit that and why I had to do that.

- Why would you want, why?

- 'Cause it's a private endpoint that points to a private IP for my... maybe I didn't need this. This may have been one of my testings. When I was trying to play with everything. I don't think I actually need this.

- So I don't think you would off the top of my head, you could connect across the public endpoint and do things that way. The private endpoint would arguably be more secure for you, especially 'cause your VPNing in, that way your VPNing in. And when they go to connect to the file share, they're actually connecting through the private endpoint. And they're routing straight into the storage service. And even though the public FQDN is still there, nobody can connect to it that way, they can only come through the private endpoint.

- I think this was when all of my testing was going on to try to figure out how all these configurations worked. I think I created this. And yeah, as we're talking about it, looking at it, I don't think I actually need it anymore.

- Hey, look, you simplified things, while making it--

- I simplified things or get rid of a private endpoint connected to a storage account. That yes, that in theory would all work and that would provide you a way to actually be anywhere as long as you connected to the VPN first, you could go mount these file shares as a user instead of using that primary storage key. And then one thing, this client had talked about is, they're like, well, when I'm on-premises, then can I speed up my connection? Because now inevitably, you're going over the internet, you're connecting to a file share. And if you're pulling 100 meg, 200 meg files back and forth over a VPN connection to an Azure file share. It's not gonna be nearly as quick.

- Especially a Point-to-Site connection.

- Yes, especially Point-to-Site connection. It's not gonna be nearly as quick if you're just pulling it off your local server. So then they were like, "What can we do like the Azure File Synced?" So you can have a cached copy locally in the office and use this as kind of a backup emergency option. If we wanna get to those files from externally. And also if you're doing Azure File Sync, it does give you some of that DR type scenario where our office catches fire, we lose our server. And now we, again we have this backup option, we have all of our files up in Azure Files where we can get to them, restore them, do all that if the need arises.

- Mm hmm, it would be there. And it would all be very nifty. Lots of moving parts.

- Yes, that is the biggest thing I took away from this is, this is not, I come from the Office 365 said, this is not stand up an Azure or a SharePoint site and do a sync. There's a lot of moving parts, a lot of routing, a lot of networking. There's a lot of stuff to figure out and take into consideration if you wanna go this route. So you said you had one other thing too, that you were gonna throw out there as why didn't you just do this? What is your thoughts on this whole configuration setup other than SharePoint a lot easier.

- SharePoint would have been easier, you should have just convinced them to go that way. And if SharePoint wasn't there thing, there's lots of other file storage services out there. Like, I don't know, Box or Dropbox. Pick one of those--

- ShareFile or yes.

- Yeah, if files is your thing, and per user authentication is your thing. And you want it to be resilient and live in the cloud. Here you go. There's the right tool for the right job.

- Right, we had an episode a while back about that. About picking the right tools, specifically when it comes to cloud storage.

- Yeah, so I think one of the other things to maybe think about is, you're doing this as a one off scenario. And you're doing it for the time when those users need to be away from the office and kinda have that remote connectivity through. I think another thing to think about would be what if you didn't have the VPN, and you didn't have that whole client setup piece, and maybe you didn't do Azure Files. You just went with a traditional set of DCs and a replicated file share that lived in the cloud. So say you did like DFSR or something like that over a Site-to-Site VPN connection from the office, you have your clients rather than coming across a VPN and dealing with that headache, maybe just stand up like Windows Virtual Desktop or RDS services, and something like that, and have them connect to that service when they need to. So okay, you need to go to the cloud, your remote, here's your desktop in the cloud, it can talk to all the things you need to talk to, without all those routing issues and everything else that you've kind of run into along the way with ports and protocols. 'Cause then it's just a 443 connection. And anybody can do that. And you'd have more control over sizing, latency, performance, I think you'd have some better client controls there 'cause you'd already have the DCS and Azure, you'd still have AD, but it might let you even move away from Azure Files, which you might not need in this scenario and just have, like you said, like a regular file share running up there, and maybe make it a little bit better like that customer unset file share on their DC say, "Hey, we're gonna Azure, we can make it better." But you really don't need a path service like we can live IaaS and it's a known quantity.

- What if you just did Windows Virtual Desktop, so same thing you're talking about Windows Virtual Desktop, DC sitting in Azure, again, now, you're not dealing with VPN, you're not dealing with network 'cause you're all sitting on the internal Azure network. And you just did Azure file shares with Windows Virtual Desktop and a DC and Azure, because like you said, now you're not dealing with port 445. Everything is in the same VNet, you don't have any routing issues. You can join your Windows Virtual Desktop to your domain, Azure file shares should work, significantly easier. And you could also go that route. You're not gonna have the latency there. Because again, you're going over all that internal networks at this point in time.

- Yeah, I mean, it depends on how you're gonna use it, right? Do you need that per user authentications, probably the biggest thing in there. And just based on the path you're going down with per user authentication and the way it is today being a preview back to that lifecycle thing, it might be easier to go with known quantity, and say, this is gonna be supported and ready to go. Especially, I'd imagine you're looking at something like this for a customer because of the time that we're in. They're coming up with some specific needs based on what's going on today. And we don't know how long what's going on today is gonna go on. And sometimes that roadmap for Azure Files is a little murky. So you might have some other options in there that potentially simplify things or maybe give you some other costs levers or controls.

- Yep, and we did start going down that path, or at least having some of those initial conversations about maybe you do leverage Windows Virtual Desktop for everything because at that point in time, now every computer in the office is essentially just a thin client. It's a terminal, can even be an iPad. With those nifty new keyboards and mice that are hopefully coming today via UPS. And your office computer could just be pretty much anything at this point in time, because you're just connecting to Windows Virtual Desktop and doing everything in the cloud.

- I think it depends on how you look at it. I was maybe thinking of it more as your file share scenario where it's a backup. So maybe you have a limited size host pool. But because it lives in Azure, it can scale when it needs to. So it's not a problem that it's only I forgot maybe one available desktop post sitting there. Because it's gonna be able to scale from one to 12 on demand as users are coming in and out versus having 12 or however many you need running all the time. And then it truly is that backup scenario.

- Yeah, and that's kind of one of those key differentiators is I think this might start as a backup and then turn into maybe this is our everyday functionality, or everyday scenario, we'll just kinda have to see where this goes. But it has been a very interesting exercise on my part to figure all this out.

- Yeah, is always fun to play with new stuff. Welcome to Azure.

- Yes, thanks. I've actually been doing a little bit more Azure stuff. I have a couple other projects that are tied all into Azure IaaS, it's bringing me back to my roots as a system admin and dealing with servers and racks. Only some of it's a little bit more abstract now.

- It's all just in a JSON file someplace.

- Yes, I did not have like these predefined Azure DNS things before to figure out crazy VPN routes and VNet peerings.

- Yeah, but now you've done it--

- It can't work over a peer.

- You'll never forget.

- That's the theory. That's the hope, the plan. All that. All right, well, thanks for this extended episode.

- Yeah, no, thank you. It's fun.

- It was. And we have lots more stuff that we can talk about. We actually have like three or four topics today. So we've got lots more fun stuff coming in the future. So go enjoy your cloudy day while you sit inside in social isolation. Don't work too hard. Go take a walk in the beach. Have you gotten out there yet? Have you gone out and taken a walk on the beach?

- I have not gone to the beach yet. It's been a week. We're going out on the boat this weekend. So that's plan.

- Nice. That sounds nice and relaxing.

- Yeah, all right, man. Well, until next week.

- All right, enjoy.

- If you enjoyed the podcast, go leave us a five star rating in iTunes. It helps to get the word out, so more IT pros can learn about Office 365 and Azure. If you have any questions you want us to address on the show or feedback about the show. Feel free to reach out via our website, Twitter or Facebook. Thanks again for listening and have a great day.