Parallels RAS High Level Architecture

If we take a look at the high level architecture if you just install RAS and take the defaults next next next you end up with three core components. The boxes on top there in red next to each other are the publishing agents. That's the controller, the the connection broker - it kind of decides what to do. The two boxes off to the right the remote desktop servers, remote desktop session host, or I still call them terminal servers because I've been around for a while, and Microsoft changes their name, and i'm old. But we lay down a very small agent on the server by default. You can decide not to do that but by default, it lays that down. And it creates a... it allows us to manage the remote desktop server. The two purplish boxes just off center with the locks on them that are stacked on top of each other - the secure client gateway. That's what controls access into and out of the system so as I said, if you just install the product and next next next next, you end up with one of each of these on a single server. So, very easy install. I've split them apart here into... uh... pairs so that we can just understand how the traffic flow works. The other piece all by itself there on the left is the High Availability Load Balancer, or by the acronym HALB - it's kind of an awkward acronym but at least it's a descriptive. The HALB is a virtual appliance. It's included in the solution like everything. Everything I talked about is included, but the HALB is a separate download, because it's a virtual appliance. But what it does is it provides front-end load balancing for the product. So, it gives your end users a single connection point, and then distributes that load across multiple gateways. So if we look at these pieces in action, the first user will come into the environment and connect, and they'll connect to the load balancer. The load balancer it just does NLB and round robin. So it's very simple. It's going to say okay first person coming in, we're going to send them to gateway number one. The gateway is actually going to do the work here, but it's going to ask the publishing agent what am i supposed to do with this guy. Right? This user just came in, what am i supposed to do with them? The publishing agent will then have active directory most likely do the authentication. we don't authenticate anything; we don't store passwords, anything like that. We just integrate very seamlessly in with Active Directory. So we're going to ask Active Directory what are we supposed to do with this person. Active Directory will have them authenticated. We'll then query Active Directory for the group membership and then, based on the groups that they're a member of, you know here's their stuff - here's their applications, their desktop, whatever it is that you're giving them. Okay. Second user comes in and almost the same thing. Only last time we went to number one, this time we're going to go to number two, right? It's round robin and then it's going to go through the same process, right? It's going to ask the Publishing Agent what i'm supposed to do with them? The Publishing Agent goes to Active Directory, query group membership so forth and so on and so forth. So, it's just going to go back and forth it gives your end users that single connection point, and it distributes that across multiple gateways. Yes, you can have more than two gateways, and you can have more than one HALB. I just kind of kept it to simplify the screen at the moment. Okay? So, that's what I call front-end load balancing where the load balancer just load balances multiple gateways. but RAS is fully load balanced to end to end, so we also load balance on the back-end. So now that we've got some users on, let's take a look at how that would work. The next user will connect, they'll go to the load balancer, they're going to go to number two - just round robin, just like always. But it's also got to decide which remote desktop server to go to, right? We've got more than one here. And this is not going to do round robin necessarily. I mean, you can set it to do it but out of the box, it's going to do resource-based load balancing. So it's going to take a look at not just the number of user sessions but the memory and the CPU utilization and then, make an intelligent decision about where to send them, right? In this case if you follow all the colorful lines, you'll notice that the there's more users on number two than number one, but they're actually not doing anything as far as the server is concerned. They're not driving workload through the server. So, we'll probably send them to number two in this case. Just a real simple kind of...uh... approach there. Alright? This isn't dynamic load balancing, it is just simply going to decide where the next connection should go. Right? And it's going to try to just make very intelligent decisions. It works really well out of the box. I haven't actually come across anybody that needs to disable or change that. But that's kind of what's going on. The other cool thing about RAS though, is it is an all-inclusive solution and an all-in-one solution. So if you have another user coming in that happens to need VDI, we can handle that as well. VDI is included in the product. We use the same thing, right? They'll go through the load balancer, the gateway, the publishing agent, only this time will hand them off to VDI. And you can mix and match - users can get applications and VDI and so forth and all that. It's all included - we don't change your licensing, anything like that. We're also hypervisor agnostic, so we support just about all the... well, I actually haven't come across a hypervisor that people actually would use in production that we support or we don't support, so that's all right there. A couple of things about VDI, this actually was updated pretty largely in version 16.5, so just a little while ago. But you might come across something that was like a VDI appliance, and I'll show you where that is that we had. That's largely been retired. I... there might be one hypervisor that still needs it - I can't remember - but it's been largely retired because what we do is, we install an agent on the RAS publishing agent server and then it just communicates to the VDI host - whether that's vSphere, Hyper-V KVMs and whatever, right? Nutanix, Scale - it doesn't really matter. It communicates with them via vpi so, instead of having to have a different agent communicating or running on every VDI areas or a hypervisor host, it just runs on the publishing agents and then from there, it can communicate with multiple hosts. So very very simple. And I'll show you how to install that when we get into...uh... the installing part of it. And we'll talk about some of these other auto-deploy features as we go through it...uh... this makes a little bit more sense later. I'll try to reiterate... reiterate it when we kind of do this, but I just want you to kind of have it as a reference when you look back at the slides if you need to. VDI does require active directory if you're doing just remote desktop servers, and you're sticking to maybe a single server. You can get away with local windows security - I wouldn't recommend it, but you can do it. But VDI, because there's so many moving parts, it does require active directory, also the virtual machine name and the host name must match and what do i mean by that? Well, if you right click - create virtual machine and any of the hypervisors, and you give it a name, you know, Windows 10 prod. Well the host name, the windows name must be windows 10 win 10 prod as well - it's got to be the same, all right? We also require DHCP and then, the last one here is true from not the last one but the third one. We cannot push agents through Windows firewall. So if you're trying to add the Parallels RAS guest agent, and again I'll go through this process with you, then just remember if the Windows firewall is on in that local system. We won't be able to push through it, right? It wouldn't be much of a firewall if we could do that. So, you either need to disable the firewall temporarily or permanently - it's up to you and that or open some ports but regardless, we got to get our agent on there first to the firewall. The last note there is if the guest VMs are on a different subnet from the RAS publishing agent, we need to implement this knowledge base article, I actually need to pull that out of the slides, and I'll do that, because that is not a true statement anymore. If you're on RAS version 16.53 and earlier you need to go through this knowledge base article and do that. We have addressed that and resolved that. So you no longer have to worry about this in version 17. So... so ignore the last one. If you're going in version 17, you don't have to worry about that. We're all good, all right? So let's move on a little bit back to the architecture real quick, and let's talk about... let's take a close look at the secure client gateway. And then we'll start talking about kind of how we would lay out the components. So, just how the secure client gateway works - it can do work in one of two different modes. And you don't have to install it in either of these modes - it'll just auto switch depending on the connection type. Most people just leave it alone, and the default is that one that says gateway mode SSL. But let me show you what the different modes look like because you might notice them and wonder what they are. Direct mode versus gateway mode - Well in direct mode, you'll notice if you look at the chart a little bit, the end user device that RDP connection - and yes we're using the RDP Protocol - is directly connected to the remote desktop server, right? So the secure client gateway here is acting like a traffic cop. It's saying you, client, make an RDP connection directly to the remote desktop server, and the gateway is not in the critical path, okay? The gateway mode means that the secure client gateway is actually tunneling - it's creating an extrapolation layer. So for the end user to get to the remote desktop server, they have to tunnel through... uh... the secure client gateway component. And then both methods support SSL - they can be encrypted or not encrypted. So why would you choose one or the other? Well, direct mode actually is pretty nifty. If you're in the office and all your stuff - all your end users and your server gear and all that - is all on the same network, meaning there's no firewalls or anything in between them, then your end users could get away with just direct mode. The connection initially is a little bit zippier, I guess Once they're up and running and the connections established, it's pretty much the same. I haven't noticed anybody that notices a difference in speed. But the initial connection, because you're not having to go through the gateway servers, is a little bit quicker. You also might be able to scale just a little bit more using direct mode versus gateway mode. Gateway mode usually is done for security, or if your networking requires it, right? Your, and i'll talk about networking in a moment, but essentially, users cannot get to the remote desktop servers over port 3389, right? maybe they're at home, we definitely don't want to expose 3389 - the RDP port - to the internet, or maybe don't even do that in the office, but essentially, would mean they can't get to the remote desktop server over port 3389. And so they have to tunnel through the gateway, okay! The box on the left, the connection properties box, actually is a client-side setting. So you notice that you can set the mode, actually, from the client - gateway mode, direct mode, ssl or whatever - that doesn't mean if they set it that way that they'll be able to get there, right? It depends on your network whether they can or cannot. The other nifty thing on the client side - what's hidden by that drop down box that i've got circled in red there - is a button that says "secondary connections". The secondary connections is pretty cool because let's say, you have a user that travels or roams, right? They're in the office most of the time, but occasionally they go on a trip or take their workstation home with them, their laptop or Chromebook home, you could set up a secondary connection. What does that mean? Well, my primary connection could be an internal facing address, right? internal only - like mine's on the 10 network which doesn't route so, it's an internal address. In direct mode, in that connects in the office, but if they go home, unless they're using a VPN, they obviously wouldn't be able to connect to that. So the secondary connection would allow you to have a connection that is set up for, say home, a public-facing address using gateway mode SSL. So when they're in the office it would try their primary connection, and it would work because it's set up that way. They go home and the primary connection would fail, that RAS automatically would attempt the secondary connection and then the users would connect seamlessly without having to use a VPN. So they don't have to keep configuring and changing the connection properties in their client - you set it up once and it works no matter where they are. That's really what that secondary connection button is for. Okay! let's move on here. Okay! so like i said, if you just install RAS - the remote application server - and you take the defaults, you end up with a single server that looks like this. It's got the publishing agent, the remote desktop session host agent and the secure client gateway, running all on a single server. This is great for getting started, it's great for functional testing. We're actually going to do it this way when we install, and thenI'll show you how to break the components outI it's also really good if you've got a very small environment where cost is more important than resiliency, right? It works great. And using this, by the way, I said RAS is all inclusive so, it defaults to the terminal server. But you could take that off and just go pure VDI with this if you'd like. Or, you also can do both. So you can do VDI, remote desktop server - either or both - it doesn't really matter. But it's really great to do that, and get started. One of the things that i'm most fond about this product, however, is that even though I start like this, I haven't locked myself into this configuration - I'm not stuck here. It's trivial to start expanding out and scaling out to get it scalability and redundancy. Okay? so i could start like this and then it's very easy to move to this type of a solution where now i've got kind of two all-in-one servers. I've also introduced the load balancer, I may or may not be connecting to a hypervisor for VDI, and I've now added some resiliency or some redundancy or, excuse me, it was that was redundant redundant...uh... some redundancy or some scalability. I probably haven't added both because i don't have a plus one, right? If i'm fully maxed out and a single server fails, the other server wouldn't be able to handle everything. But i've got one or the other here and it's very trivial to kind of go out. This is where we're going to stop in the lab today. I'm going to take us to this part and we're going to kind of go through the features and functions of everything. Because once you've done this, it's trivial. You guys already know how to do this once you get to this point. It's very easy to start scaling out farther, and usually the next step that people take would be something that looks like this. So now, i've got kind of the publishing agents and gateways running by themselves on their own server. If we look at the load balancer, I have more than one of them for redundancy. And the new piece on this slide is that little box that says virtual IP address - if you can squint into the Webex a little bit. The virtual IP address is just that - it's an IP address that's obviously valid on your network that's assigned to nothing else. We assign that in the virtual... in the RAS administrator console - I'll show you how to do that it's really easy. And multiple load balancers can answer to that address. They share that address. They each have their own address but they also all will answer to the virtual iIP address so if you have a failure in any of the load balancers, the end users can keep going - they don't have to remember to change and try a different load balancer, they just go to that single connection point and they're good no matter what happens. So now we do have some redundancy built into this as well as some scalability. So if you look at just the pieces on the left, I've got the two publishing agent gateway servers running by themselves, I've got two load balancers. That can support about 500 users just with that. And the publishing agent gateway servers probably about four processors four gigs of memory - they're really not very heavy, there are Windows systems of course, Windows server, but four processors, four gigs of memory, most people run them in virtual machines of course, or in the cloud, but that'll work that gets you to about...uh 500 users. the HALBs - the load balancer - a single HALB can support about 2000 users. It's really lightweight appliance, it can support about 2000. So i've added a second one here, really just for redundancy in this environment. The pieces on the right of course, well, that'll change, right? your mileage will vary depending what you do to get to 500 users. You almost assuredly need more than six terminal servers unless you're doing something really lightweight with beefy servers, but you can mix and match VDI, remote desktop servers, whatever, to get to the number that you need to do that. But just the infrastructure pieces on the left can get you to about 500 users, okay? If you need to go a little bit beyond that, we can get up to about 7500 users. It is our testing limit so far, but at that point you would move to something like this. This is simpler and more complex at the same time. It's simpler because there's fewer boxes because I limited them just so we can read the slide, but notice that i've got... um... each of the components running on their same servers or on their own servers - the publishing agents on its own server, the secure client gateway servers on its own server and so on and so forth, right? I've got multiples of each of them and you can see the two load balancers in the virtual IP address. So I can have as many gateways as I'd like, I can have as many load balancers as I'd like, right? Tip! green green, no limit on the number of those, and I can also have as many terminal servers or VDI's as I'd like. Talk about the publishing agent in a minute, but because I've split them apart, I now have better performance since the components are not on the same server. I mentioned that a HALB can support about 2000 users per load balancer, so it gives you an idea for the scalability on that. And the gateway around 750 to 1000 users, depending what you're pushing through in terms of the traffic. But that's about what we've been seeing in production for...um... users per single gateway. So if you had two thousand users, probably three gateways would give you some redundancy, maybe four, but somewhere in that neighbourhood, right? Okay! for two publishing agents I said, two PAs is the limit. They really..uh..I'll talk about them more in a minute. You can have more than two, but they just increase your network traffic, and they don't buy you a whole lot. So we really recommend just two, because they're the ones that are kind of chatting back and forth. So keep it down to two. You can have more than two if you'd like, but we put them... we recommend putting them in something known as 'standby mode' - meaning, they're acting like a hot spare at that point, right? So if one goes down the other takeover. The publishing agents... actually, I'll talk about those in a minute and how that architecture looks when we talk about failures. But...uh... let's go ahead and jump forward, and we'll just kind of get into failures, and we'll kind of look at each one of these directly. So, I talked about resiliency - what happens if something fails? Well, let's look at the gateway or the HALB first. If users are in direct mode, right? Remember direct mode? that's the direct connection, that's that home run connection between the end user and the terminal server or the VDI desktop. Then if you have a failure in either the load balancer or the gateway, they would notice, right? It's done their job, it's told them they connect to the resource, and they've done it. And the RDP connection is up and stable between them and the endpoint device, so users won't notice a thing. If you have a failure in direct mode, new users coming in shouldn't notice either, because they'll get routed through the surviving components, right? So maybe you have a hypervisor host go down that took down one load balancer, one gateway, but your other host is up with another gateway and load balancer. The users will automatically go that direction. We're good! So if you're in direct mode, users won't even notice anything. If you're in gateway mode, they'll notice a little bit but not much. New users coming in won't notice in either mode, right? Because they're just going to get routed to the surviving components. But if you're in gateway mode...remember you're tunneling through the gateway component, and the load balancer actually acts kind of as part of that tunnel. So if the load balancer or a gateway fails, the end users connection will drop, right? They're going to get disconnected. However, just because they're disconnected does not mean it's the end of the world, right? Terminal servers, VDI desktops - we've all done this as administrators. We log in remotely. We click the little x at the top to disconnect instead of logging off. We log back in, and oh yeah! I was in the middle of that. Pick right back up where I left off, that's what will happen to the end users. Just because their connection dropped does not mean that their session ended. So they will reconnect automatically, most likely. So, they'll disconnect; they'll have a moment of panic; they'll reconnect; they'll get routed right back to the original session, and they pick up right where they left off. And maybe, they were worried for a brief moment there or... or just slightly irritated, but it's really no big deal at the end of the day, because they're good, right? So provided that the environment is... uh...sized correctly, right? n+1 size. A failure in any one of the gateway or load balancing components shouldn't really be too big of a deal, right? We've got redundancy built into that. Okay! um...let's see what part is... we have a question in the chat windows, that's good! What part is it that routes the connection to the session? The gateway is actually doing the heavy lifting, right? So that's actually where the routing to the session is. If you're in direct mode, it's actually doing the routing, right? You connect to this if you're in gateway mode - you're tunneling through it, and then it finishes the connection itself, but it's the gateway server that handles that. However because of the way the tunnel works, the load balancer actually would be a part of the tunnel too. So even though it's not doing the heavy lifting, if a load balancer were to drop, it would disrupt their session, and they would have to reconnect. It's just kind of how that...that's designed. But regardless, you should pick up right where you kept off. But good question there. All right! Let's move on to another failure component, and let's take a look at the publishing agents. So how do the publishing agents work? Well first of all, they've got an architecture similar to a Microsoft domain controller. So like a domain controller, they have a built-in database - that's one of the great things about RAS. it's designed so the publishing agents actually aren't doing heavy workload - that's being done by the gateway. They're really just answering questions: Yeah! this person here, yeah! that person there. But the gateway is doing the work. So the publishing agent is pretty lightweight which is why, two of them can get us to about 7500 users. Okay! they're both active active. So if one fails - the master fails - the secondary will take over, right? So we're pretty good there. They're both doing work for you. If you have a third, like i said, it'll act as a hot spare and so forth. That version that came out actually in version 16.5. So, we're well past that. So it continues on there. You'll notice a distinction between the master PA and the secondary PA. What does that mean? Well, let's see if I think back to my domain controller reference. Microsoft has something called operations masters, right? we used to call them, i believe, FISMO - F.S.M.O - back in the day. I don't remember what that stands for, it's been so long. But essentially, the master publishing agent has a few of those - just things that you only want running in one place in your environment at a time. So it's doing 60 percent of the work, but the secondary is doing 40 percent of the work, and if the master fails, the secondary can promote itself and take over and do all the work. So you're really covered there. The main thing that the master is doing that the secondary doesn't is, it is the licensing server. Okay! So that's where all your RAS licenses sit. So if it goes down, the secondary server will take over and act as the licensing server. You got 72 hours before you have to worry about anything. So if it's just the host that went down and you... somebody kicked the power cord or something, you plug it in it comes back up, the PA starts. You don't have to worry about anything. We're good! PA... master PA will come back up and say, 'I've got it!', and take over. If the post... if the master publishing agent went bye-bye for good, right? I mean it's running on a physical server, and that server caught on fire and game over! Something like that... um... In that case, you've got 72 hours to address it. To address it, all you need to do is log into the secondary publishing agent and right click and promote it, and make it permanently the master. That's it! That will require a license reactivation. The license server is tied to the MAC address and the host name of the server. So if you're activating on a second server, it will ask you to reactivate it. what's that entail? Ah...you just got to use the username and password that it was tied to your license. So service account would be great for that. Log in, and do that, and reactivate it, and it goes, right? And if the master comes back up at a later date, you can certainly switch them back later. It's very easy to move these things around. You just have to go through that little activation process. We'll see the activation process when I log in to create stuff, but just so you kind of know, you've got... you've got some time before you have to worry about anything - good three days that you can keep running. But the fact that it's tied to the MAC address of the host name of the publishing agent server 2 is why we also get that little warning when we install RAS that says, "you know if you're using virtual MAC addresses to switch around, this might be one server you don't want to do that with. Because if the MAC address changes, it doesn't kill it, but it shuts it down. And you'll have to reactivate the product, which is kind of annoying. I like to make things easy if I'm administering stuff. Okay, so we have a failure in any one of these components on the left, and all's good and hunky dory because we've designed our system, right? We're n+1. End users keep working. I've just got a little bit of stuff to do on the back- end as an admin, and we're all happy and healthy. All right! So then, what happens if we have a failure at the other side, right - the terminal servers or the VDI desktop. Well, this is the one that's going to be the most impactful for an end-user, right? because this is where their session lives. If that goes away, their session's vaporized, it's gone. So they can reconnect, and they'll get connected to a new session because as good administrators, we've designed resilience into the environment; we have more than one terminal server; we've got additional VDI desktops that perhaps they can get to in a pinch if they need to. So they will be able to get there and be able to start working again, but they'll have lost what they were doing. So the question is: how much did they lose, right? And that answer is the answer that's everything in IT, which is, well, it depends. If you design your system right with some resiliency, right, the impact here will be felt, but it could be minimized and be fairly minimal, right? First of all, to be connecting you can get up to a new session and get going again; that would be the first thing. The second thing, though, is if you work on keeping these guys stateless, right, um... if you can keep the data off of them - you know, don't save local; save somewhere else, right, um... on a file share or something like that - then their data is protected and safe... uh We all know that users like to just save in the default my documents and so forth, which is why I'd recommend: you can still do this... um... use a profile management service. So if you do that, that keeps the profiles off the servers and off the VDI guest desktops and somewhere else so that that... that's how load balancing would work too, right? You log into server two the next day, and hey! where's my stop? Well, it's back on server one because you saved it in the my documents folder. So use a profile management - roaming profile or not roaming profiles - but a profile management service to handle that. There's a few different approaches, by the way, I'll talk a little bit more about this later, that you could do for profile management. You could, i guess, still use the old roaming user profiles, good luck to you, but I suppose you could do that. The second one, which i guess is the more modern version although it's technically, I guess, outdated at this point in time, but user profile disks. We have built-in immigration with RAS into the Microsoft user profile disk technology. So if you want to use user profile disks, you do not have to go through the rigging roller creating collection and all that other stuff. We've actually got that integrated with RAS. A user profile disk is just... it takes a user's profile and it puts it into a virtual hard disk, and the virtual hard disk exists on a file share somewhere so that end users can get to that. We can do a lot of that integration with there for you. The reason I say, 'it's, I guess, kind of outdated' is Microsoft, as some of you may know, purchased a company called FSLogix not too long ago, maybe a year ago, maybe a little bit over. And then not terribly long ago - two or three months - they made an announcement that if you're an Office 365 user, you get FSLogix for free, or at least included with your Office 365 subscription. Well, guess what! FSLogix has a very great and robust profile management service built into it. So, I would use that if you have that access to you. If you don't you can still use user profile disks. that's works and then... um... you can also use any other third-party utility that you like. We... That operates at a lower level than RAS. So if you're using your own profile management service - Liquidware, whatever - that'll work as well. But regardless, if you keep the end user data off the terminal servers and preferably even out of the VDI guests, then if you have a failure there, they get to their data. The answer then becomes, you know, what do I... how much do I lose? Going back to that question, well when did you last click save, right? Those of us that have been around for a while learned that the hard way. I learned it back in college in a very hard way, But I click save save save, and most reasonably, modern applications actually have an auto-save feature. So if you got a save going on, you got your data not on there. The user sessions gets evaporated because the terminal server went down. They connect to a new one, back up and running, data secure, the save wasn't that long ago - it becomes a minor inconvenience. So if you design all that right, then it's not too big of an impact there even at a failure here which would be the most impactful. Okay! I think we beat this to death pretty well, like i said, you'll have advantage access to the recording, so you can listen to me. Go over that again if you'd like. All right! So moving on, let's talk about network access and how you get into and out of the system. By default, RAS uses two ports: the gateway - the users will connect to the gateway server over two ports: port 80 port 443, green! green! zamzam! might want to remember that. That's what the users are connecting to when they hit the gateway port 80 and port 443. They're not connecting to port 3389 which is the RDP port. The only way that would come into play is if, like I said, everybody at work in direct mode, they would hit the gateway server over port 80 and then we would make... the end user would make a 3389 connection to the remote desktop server. But in this scenario, my users are not in the office, or at least there's a firewall in between them. So in that scenario, they would come in over just one port. Most likely, you wouldn't want to open port 80 - a non-encrypted port to the public internet, so you would open, simply, 443 - the encrypted port open to the public internet. I doubt anyone wants to send unencrypted data over to the public internet. So just the single port on the external firewall is all that you need to have open. Okay, that's it! And you can change the port if you'd like; you can use 4040, 444 or whatever; you can certainly change that if you want. But our default is 443. So if you change it, just remember you got to have the client specify a different port because they're not going to default to it, but it works just fine. So you can do that; you make an SSL encryption so they're fully encrypted going all the way into the system and for hunky-dory. The only other thing you need to do is a NAT, right? That public-facing address that maps to an internal-facing address. In this case, it would be the virtual IP address of the load balancers. That's what i do, a map and that for this case, and there you go. And then remember, if they're in the office, out of the office you can use that secondary connection in the RAS client. So... but that's it. So we're not in any way shape or form exposing 3389 to the internet. The only place that 3389 needs to talk - the RDP port - if you can see my mouse skipping around in that Webex, i know it's hard but, it's from the gateway to the terminal server. So the terminal server, and I know you can't see my mouse moving in Webex, but in the gateway. That's the only place that 3389 needs to be talked. And you can change that if you'd like. I haven't come across anybody that's needed to do that yet but you certainly can. So they never need to make a 3389 connection to any of these other components over here and certainly never over the internet - just that one port 443, okay? If you have a DMZ, dual firewall or cascading firewall, depending where you are people call it different things but we tend to call it a DMZ where I'm from. Dual firewalls... this is typically what I would do: I would put the load balancers out in the DMZ and then, nothing internally like that. So virtual appliances, it's really low-risk low foot-print out in the DMZ. You still only have to have that one port 443 open externally. Your internal firewall, there's a handful of ports that you need to open in there. We've got some documentation on that - it's in the Administrator Guide and the port reference, if nothing else. But just a few ports; you don't need to turn it into swiss cheese that'll allow you to traverse that the other way. You could do that, and this slide actually is a bit busy, but I wouldn't. I need to update a little bit - I would take the load balancers probably out of here, but you'll notice there's a gateway out there. We put the gateway in something known as forwarding mode. And that allows the external...um the gate, well, let me back up. A gateway in normal mode is going to accept incoming traffic and then pass that traffic along to the remote desktop server or the VDI desktop. A gateway in forwarding mode is going to look for another gateway in the chain. So, I've kind of cascaded and tied gateways together. So a forwarding gateway will accept incoming traffic, but it's going to look for another gateway to hand it off to that will then make the connection to the actual terminal server or VDI desktop, right? So in this case, I've got a couple of forwarding gateways out there, and they're matched up to the couple of forwarding gateways internally. They can match up to more than one, so that gives me some redundancy that way. I really wouldn't go down this approach too often. I would really stick with this in most cases, but there are a scenario where you might want to do this, and let me show you that next. And this is a limitation of the load balancer, so if you follow the lines a little bit, the users up top are at home and they're going through a DMZ to get in, and the users below, if you follow the little lines, are actually all in the office, right? So they're behind the firewall. A load balancer the HALB can only exist in one place in RAS farm, or site if you will, so if I put the HALB internally, as i've done here, right, then my internal users are load balanced using the HALB or the gateways, etc. hunky dory... we're all good. But look at my external users, I can't also put another set of HALB up there - it just... it's beyond what the product can do. So at this point, my external users aren't load balanced but my internal users are. All right! Ao maybe that works for you. What I see most people doing in this type of scenario is to use a third-party load balancer. The HALB is included in the solution, but it is an optional component; it is not required. It's simply doing NLB - network load balancing - open standards. So you can certainly use a third-party load balancer. So in this scenario, we got large number of users, external as well as internal, people will use something like an f5 or brocade or something like that, right? You can even use a Citrix Net Scaler, to be honest with you, and load balance that. I actually had somebody, not too long ago, come up with an Oracle load balancer, no idea about how to work that, but it'll work. And sure enough, it did! as long as it does NLB. sSo they were able to get that working, so you could certainly use a third-party load balancer there, and if you have one that you'd rather use instead of our HALB, feel free to use that too. But the HALB is available and it's included in the solution. The other place where I would not use a HALB, by the way, is if you're going into a cloud environment - such as Azure, AWS or Google or whatever you're doing. The reason for that is it's a virtual appliance so it's really difficult to get it imported up to the cloud services. But even more important than that is, you know, it's another virtual machine; they're going to charge you rent, Azure or AWS or whoever. Use the Azure load balancing services, I believe that's free. AWS and Google's are pretty attractively priced. Use their load balancing services instead of ours - that's... that's what I would do in the cloud. I wouldn't even attempt the HALB up there. In fact, I don't even know if we support it. Okay! Let's see. When you say third-party load balancer, you're talking about hardware? uh... yeah for the most part. You could use, i guess, a virtual load balancer as well a virtual appliance, if you wanted. It's just NLB. But most people would have like a fancy firewall that's combined with the load balancer. Like i said a good f5 or something like that. But typically would be hardware, but you could certainly use uh... like I said, a virtual appliance as well, from somebody else. But that's it - just an NLB. All right! So real quick here. moving forward. Let's see, sites. I kind of hedged a little bit there, you may have noticed, I said farm or site. I don't want to get into sites too much, but I'll get into it a little bit because most people don't use it. There may be an exam question on it, too. That's why I do want to cover it. uh... When you install RAS, i just go next next next; I end up with that single server. I've created a single farm in a single site. Most people wouldn't notice that but that's what I've done. A farm can have multiple sites. What do I get by having multiple sites? Other than... you'd think multiple locations, well, if I look at this little drawing here, it looks like I have two complete RAS infrastructures, right? They've got publishing agents, gateways, load balancers, remote desktop servers, VDI, whatever. So I've got all of that running, and that's really what a site is is it's almost an entirely separate RAS infrastructure so it's got to have enough stuff to run a full RAS infrastructure, if you will, right? It's got to have a publishing agent and a gateway at the minimum, and it's got to have something for somebody to connect to. So usually a terminal server or a VDI desktop. uh... there also is a concept called a remote PC, at least that that's on the slide. What's your remote PC? Literally, it's that, right? I've got a physical PC in my office and I use the RAS connections to broker and facilitate that connection back. So I'm at home, and I can get to my PC in the office; we can do that also. Okay! So it really is that. What ties them together into a single farm entity is two things: one of them - the big one - is the master publishing agent in the first site, is your licensing server for everything in the farm. So the publishing agents in site two are needing to talk back to that very first publishing agent, the very first site to be the license server, right? so if the... so that's what ties them together. The same rules apply for failover; if something happens, like you know a hurricane in the southeast takes out power or something like that or the network connectivity goes down for a day or so, the site too can run independently for up to three days, right? It can run for 72 hours without having to talk back to the first server to do that. If it goes longer than that, you'll need to do some promotion auto- promotion. It works very easily. It's just the manual step that you need to do. So if site one disappears into a black smoking crater that was, I don't know, a big earthquake or something and is never going to come back, well, then you might just want to promote site 2 to be the master... master, and you're good to go. It's just a quick activation. It's just a manual step; that's all you need to know. But you got a full 72 hours if something separates between those two or severs the links between those two or takes down the site one. But the master publishing agent in site one is the licensing server. Which means that the secondary site has to have pretty good network connections or at least reliable. They don't have to be hyper fast but at least, reliable from at least the publishing agent servers. The master and secondary publishing agent need to be able to reliably talk to the master and secondary publishing agent on site one. Otherwise, you're going to have that kind of promotion and demotion going back and forth all the time, which eh... not really ideal. So you want at least a stable connection between the publishing agent and all the publishing agents in multiple sites. The other thing the site gives you, and this one's kind of a small, small potatoes of my feeling, is from a single pane of glass, from single RAS Console, I could manage multiple sites. I don't manage them... uh... And the way that works, I guess, is I manage one at a time. So I'm managing site one, and then I decide to do stuff on site two, and I right click and say, 'okay! go to site two', and then, I'm now managing site two. But I don't have to exit the console and launch a new one or anything like that. So that's really the two things it gets you. The main thing, I guess, I see people using it for is if they've got users that travel quite frequently between two different locations, and they got two different sites, and they want their... uh... when they're on site one, they log into site one, and when they're at site two, they log into site two. Because you've got your network setup like that or replication or whatever, and you want them to share a single license, right? You want the license to follow them. So that, I've got, you know, 500 users, I got 300 on site 1, 200 on site 2 on Tuesdays, but that number changes every other week, i don't know. You just want the license to be able to follow 'em around; that's usually where it goes through. Most people don't do this, to be honest with you, which is why I don't try to spend too much time on it, though I'm spending a little bit here. Most people just create two separate forms and use two separate keys, that works fine too. Because that's really all it gives you is the publishing agents sharing that single license for it. o most people would just create two separate forms and go go from there. Or, the other way you can do it is you can use a lot of localization services too within RAS. That's probably beyond we're going to get in today, but there's a way to say, 'okay! you're at site two, I want you connecting to these components so, we're gonna make sure that you're going to this terminal server, this publishing agent, that kind of thing, these gateways.' There's ways to kind of handle that..uh... to a point anyway, All right! so I think that's that. Oh! one other thing too! If you're going to use multiple sites, active directory domains, you have to be... everything has to be a member of the same domain, or at least domains that are connected by two-way trusts. So you can have two completely separate active directory forests and do this. You can do it, but you'd have to have two separate RAS farms as well. Our security boundary is the domain and the domain trusting. So just so you know and if you really want to spend some time reading one night, you can get really fancy, I think this is like, three different sites with a bunch of different infrastructure. It's an eye chart. This is the kind of stuff that might be available in our solutions guide which is available with all our other documentation. So if you're interested in that - digging into this a little bit deeper, you can. You can also just shoot us an email ...um... um... and ask us about that, and we can kind of provide information. But most people go down down this. But there may be, like I said, be a question on the exam, and I just want to make sure, you're prepared for that. So green green! every site must consist of a publishing agent, a gateway and something to publish from, right? A remote desktop session host, VDI, remote PC. I believe that's the exam question, right? So it's got to be able to, at least, be a fully functioning like mini RAS. The other thing too, just for your own notification, if you go down this. If you install RAS twice - if I install RAS, run the installer, and then I go install it somewhere else, I have created two separate farms, and there's no way to tie those together. So to create a site I would do it from the RAS Console. So you install RAS; I get a farm. Almost everything from there within RAS, whether it's multiple sites, publishing agents, everything else, should be pushed from the Console. So it's very much a single pane of glass. So you would do that here. You would actually just go up to farm, farm, right click or add new site, and then it'll push out another publishing agent, gateway that's its own site and go from there. You'll kind of get the idea as we go through it. But just don't install RAS twice and expect to be able to tie it together. Once it's done it's done. You've got two farms, and I can't tie them together after the fact.