 I did a video just the other day and I'll leave a link to it, but that may be what had brought you to this video of how do you host or where do you host the Unify controller. And from an IT perspective, we have different needs than maybe an end user or a company that maybe only has a couple offices and they want to manage it in-house. We're a little bit different because we're an IT provider, a managed service provider and we manage networks and infrastructure for our clients as well as their entire computers and everything else. Unify is a very popular product line that we like. It's not our only product line, but it really hits the sweet spot of what value it provides for clients at a very reasonable cost. Someone is going to point out maybe there's something they like better and they're going to mash the buttons in the comments about this and I'm fine with that and it comes down to value that you can perceive to the client versus the cost. Unify, like I said, does really good job in that particular category. Now let's get a little bit more specific about why we like it and what you need to do to host it. First thing you need is to pick the right URL that you want to set this up at. Unify.youracompanyname.com, that's the first step. Pick something that is not just an IP address. The challenge you have with an IP address is if that IP address changes or you want to change it, you then have to go push a lot of configuration changes out to get all the systems updated versus if the backend server changes at all and we've upgraded, we've even replaced it when we are rearranging infrastructure, you just update the DNS entry for that, you know, unify.youracompanyname.com in a way you go. Now you don't have to call it unified and call it whatever you want.youracompany.com as long as it's common and you establish this in the beginning when you're setting all these up. It helped a lot of companies that started by just using IP address and transitioned it to make life a little bit easier. Now where you host it, that can be internal as in physically within your building or externally in some type of cloud hosted environment, digital ocean, AWS, etc, etc. Whatever you wherever you want, wherever your infrastructure resides in your comfortable with what needs to be exposed. That's the third part and that's we're going to dive into a little bit. So when you're setting this up, you want to have, and especially because we have so many MSP clients and so many people's, you know, everything tied into this, we don't want much exposed. We keep the exposure to the absolute minimum. That means only opening on ports that are necessary and no more. What is necessary though? Necessary is for just the functionality of Unify 3478 and 88 and I'll leave links to this. This is right from Unify site to tell you which ports you need open. The access here to use the GUI's slash API that you use in a web browser, we keep that behind a VPN and lockdown and IP restricted even on our own network. Even though we have, you know, good usernames, not reuse passwords, I still don't want any external exposure at that. So I do not leave port 8443 open to the general public. If you're using captive portal, that's going to be a little bit different. And if you're using the Unify mobile speed test and you want those open, those are going to be a little bit, you know, you may have to open those. If those are things you want to do is host the captive portal and host a speed test. Neither one of those we're doing. If the client has a captive portal or requires it and we're going to be using Unify, we will put a controller on site. That's pretty rare instance. And I think zero of our MSPs currently have it. Usually their portal is something else and more related to how they're running their firewall. But with just these two ports open, we can keep the server here and not a problem at all. I have full control and I'm going to show you with only these two ports open and no, I'm not going to go over to firewall rules. Some point you have to take my word for it. This is one of our clients, which is a football field soccer for those of you that are American. But what this allows us to do is even get into an SSHN without opening any ports, by the way. This is all done through the toolbox that they have here. So I can actually go to tools, open up the debug terminal, and then I can ping other devices. And the only downside is, in case you're wondering, yes, the font's really small. But I can get in here, ping things, see the devices, see the uptime, push configuration changes, push updates, push firmware updates. And by having all of my clients in a single controller, I only have one controller to update, and then I can push all these updates or changes between all of our clients. And it works really, really well. This has been just so convenient when someone's having any connectivity problems, when they have all unify switches and unify access points, we get to drill down very quickly their IP address. Can we ping that workstation? Can we see it? So even our other tools that we have that monitor workstations directly, this is one more tool in the toolkit. So maybe it went offline from the monitoring standpoint, but we can see it online from the network infrastructure standpoint. And without having to get inside their network or pivot in or even cut through the firewall, which if we're managing a firewall, obviously wouldn't be too difficult, I can quickly open up a debug terminal and start pinging things and seeing things on their local network. So there's a real advantage. And like I said, this is all done with just those two ports open. Just using port 3478 for UDP. This is the STUN protocol that's used to basically keep alive information that so we can understand some stats. And we're gathering all the stats on all of their devices so we can see things like neighboring access points. We can get all the diagnostic data from unify right through that. And combined with port 8080, port used for device and controller communication. So it's a combination of those two ports is all you need to have all that data fed back come coming in here. Now, a couple things about this configuration that I highly recommend. One, we have our backups set up hourly on Unify. We just have so many clients in there, there's always a change coming in. So whether my staff is doing it at, you know, any different interval, if a client needs a change made, we need to do something or push an update or anything, we really need to have that data backed up. And this is done pretty simply through the auto backup methodology that you can use right inside the Unify controller. So here's our Unify backup. And you can see that we have it set to be every hour and 30 minutes past the hour. This allows us to keep plenty of revisions in case we ever needed to restore a different revision and I only care about the settings. I'm not backing up all the other data we collect because that makes the file very big and it's just not necessary because it's mostly configurations that we're read about. Also, the controller itself is part of our VM stack and we have continuous replications where we're replicating the controller itself in case our VM stack were to die. And then to go further, we take these files with a really simple cron job that looks for changes and new files to show up inside the directory that these are in and copies them over to another backup server, which then replicates them again offsite. And all this is done with really simple tools. It's just all Linux cron jobs that take it from the back end off because Unify is just simply creating a file here. So all of these different backup methodologies and of course immutable snapshots that we take when we do our weekly backups and keep them offline is all part of the strategy. So if anything happens to our infrastructure or physically happens to the building where it's in or anything else, we keep a series of revisions of these. And hourly backups to me make the most sense when it comes to the data because that is huge. Like we may not, I mean we could always reverse engineer and go through our logs and say, all right, these are the changes the client request. But obviously, if you loaded an old controller, it would unravel all the changes and break things at your client. So you go, oh, I'm two hours behind in a backup. I need to restore it. It'll push all the changes back. Then you have to update it again to put all the changes back in. You can see how this could be a real problem, especially when you're talking about a lot of sites. It's a lot of work. Hourly backups are easy. You can see the files are really, really small because you're not retaining the data. Other than that, there's a couple more things that you want to look into and do some reading on Unify. Here is their whole sites discussion. I'll leave a link to this one. People talking about large scale sites and some of the challenges with it. And the more specific thing that you should be reading is this. How to tune a Unify controller for high number of devices. And this is one of the things that is really important is device tuning. When you start using this at a larger scale, you're going to be doing it like we are as an manager or provider. And we're going to manage a whole lot of sites in one single controller. You want to increase the amount of memory and increase a lot of other little tuning details. It's all broke down in here. Database, connection, timing, number of hosts. And it's basically that the Unify controller out of the box runs perfectly fine on like one of their small boxes that's somewhat limited in memory and things like that. Because you're only expecting to run a handful of sites. Once you start scaling it up and you have 50, 100, 200 sites, and it's not actually the sites that take as much memory. It's the devices. Because we have a client that has a single site with over 350 devices all together on their network that are all Unify devices. That volume of data coming back at that particular box plus the number of clients they have and the logging they have turned on. We just had to up the memory quite a bit. But even with that scale of a single site, I believe the machine isn't slightly older i5 with eight gigs of RAM. And it's not completely full on memory to do this. So it's not like it takes an incredible amount of power to do this. But it does take a little bit of horsepower to run it once you get to that level of scale. So think accordingly. And for us we're running in a virtual machine and we can pretty elastically just add more memory as needed and add more processors as needed. So it's not that big of a deal. But this is kind of a real basic overview. I have other videos where I deep dive on how to load the controller, how to set up a controller and things like that. But this is just the basics of how we manage it, how we host it, and having that visibility into the client's networks all in one dashboard versus installing a cloud key at every single client or a controller just in general at every single client which would be more difficult for us to manage. Because well then I'd have to make sure I update all the different controllers. Now we do have clients who we manage their external controllers for them. And of course that comes at a higher cost than when we have them in our dashboard and part of our MSP plan. That's going to be a lower cost. In which you're billing for is the time. We bill more because it takes more time to manage the external controller and all the updates that may come with it. And you know whatever exposure it may have versus us we're only exposing in two ports so I feel as though we're mitigating the risk. We're not tying it even to the cloud account. We keep it very locked down internally. And then only those two little pinholes exposed. Those two ports is all you need to be able to manage it as long as you're not earning anything like you have to portal. So hopefully this was helpful and thanks. And thank you for making it to the end of the video. If you like this video please give it a thumbs up. If you'd like to see more content from the channel hit the subscribe button and hit the bell icon. If you like YouTube to notify you when new videos come out. If you'd like to hire us head over to laurancesystems.com. Fill out our contact page and let us know what we can help you with and what projects you'd like us to work together on. If you want to carry on the discussion head over to forums.laurancesystems.com where we can carry on the discussion about this video, other videos, or other tech topics in general. Even suggestions for new videos they're accepted right there on our forums which are free. Also if you'd like to help the channel out in other ways head over to our affiliate page. We have a lot of great tech offers for you. And once again thanks for watching and see you next time.