I'd put one script on each remote computer and have it send an email whenever the service stops. Or check whatever it is you really want to know with the service.
Sadly, we already monitor the service. I can be 'running' but fail and need to be stop/started. We've also already done the scheduled task route where it checked it ever 15 min and stop/started it. But there are still times it needs to be manually stop/started. And this is 10x better then what they were doing when I started last year....
OK, so the script is part of something you actually use to restart it when you decide to?
Yes - while I would like to solve it with PS,.. my batch script works fine. I just figured with all that I am / have been doing with PS,.. why not convert it to PS and go one.
Now - if there is another way to accomplish this - I'm open to learning. It's what I'm applying with PS - learning.
I don't know if that is the case with Ubiquiti but some products in their line sure looks like it.
Looking at the number of employees working at Ubiquiti versus their revenue, also suggests that (most?) of their products are not designed in-house. That's just speculation of course.
Well the Edge line, and this is me guessing, is likely third party hardware that they buy (that's pretty easy) and they basically use an open source OS barely modified. They were half public about that when they started, so it kinda made sense with that line. No idea if they continued that with Unifi and others.
Well, they started with RF-based products so they have that expertise in-house.
It would make sense that their wifi products are developed by themselves and manufactured by OEMs while the rest are ODM products.
That's the quickest way to expand the product range. Otherwise you need a ton of employees. From the info online they're only about 1000 employees worldwide.
If you add another admin in the cloud control panel, is an account for that user created on all cloud instances that person can access?
In Vultr, there aren't users in the cloud panel at all. There are keys that you can choose to deploy at deploy time for root. Other than that, if we wanted to deploy keys (as an example), we'd do that through our management system (script, Salt, Ansible, etc.). I would not want the cloud platform to be touching my users.
OK, got it.
Does that also mean that only one person can have access to the actual Vultr account as well? I'm guessing it's multi-user.
Yeah, the cloud level is multi-user. But just as you can have multiple people with access to a data closet, and multiple people with access to a Windows instance housed in that closet, you don't want the physical closet to maintain the Windows logins. Same here, your cloud provider is like a data center or data closet with its own level of access unrelated to applications or other workloads running higher up the stack and 99.999% of the time, no association or commonality between them.