@gjacobse I'm setting one up in our lab today and as a basic SMB router with VPN capabilities its OK. Compared to an ER-L I'd probably stick with the EdgeRouter.

@dashrender said in Where are MSP managed on-prem workloads moving?:

@pete-s said in Where are MSP managed on-prem workloads moving?:

Thanks, it does makes sense to move to SaaS solutions for a single customer that is doing their own IT.

But a MSP is in a different position because they, besides know-how, have a larger scale. So it can make economic sense to host things for their customers that doesn't make sense for each individual customer.

For instance does it makes sense for a company to have a server to host their website on? No, it doesn't. But if you're an MSP and your customers have a thousand websites that needs to live somewhere, it might make sense for you to host them.

I guess it also depends if you're an MSP that just manages things or if you also have your own hosting/cloud infrastructure or use another provider for that.

All good points. I have no view into that world, the few ITSPs I know are using other companies solutions, not rolling their own, or even hosting their own. Though some of them, we'll take JB for example, do manage all the stuffs other than hypervisor and hardware for things like a Ubiquiti controller, and PBXs.

If you really do have need to host 1000's of websites (or really massive sites, it could make sense to manage the whole stack, but then again, it could be better to get services from someone like Vultr, or in extreme cases like Amazon/Azure.

It's possible that ITSP/MSPs in the SMB space in general don't own any infrastructure themselves.

I know large companies that fully outsource their workloads to service providers. Those service providers host the workloads primarily in their own datacenters but also on public cloud infrastructure. But these service providers are often large companies themselves so they have scale.

That's awesome, thank you!

@CCWTech said in Defining "Emergency" For MSP Customers:

@JaredBusch said in Defining "Emergency" For MSP Customers:

This is what we currently do for hourly phone system jobs.

933b95d1-3c95-490a-ae00-02765016e775-image.png

Basically as long as you schedule it, you get the normal rate. Time of day doesn't matter.

Do you charge differently for on site vs. remote support?

No, but as I’ve said many times. We are not really an MSP. Strictly consulting.

@VoIP_n00b said in MSP Helpdesk Options:

@scottalanmiller said in MSP Helpdesk Options:

They literally get to pay LinkedIn to bypass the spam blockersmessage people who aren't connected to.

One and the same. They have a spam white list that you can pay to get around.

@EddieJennings said in Suggestion for books on MSP and others?:

@Pete-S said in Suggestion for books on MSP and others?:

@EddieJennings said in Suggestion for books on MSP and others?:

@Pete-S I bought the digital version a while ago, but never got around to reading it.

Well, I just plowed through it. I like to do that to quickly get up to speed and then I'll go back later.

I'm not sure how useful the book is going to be for someone already doing MSP work. But on the other hand, seeing it from another persons perspective is always useful.

I'd be curious to see if there's information that could apply to a one-man operation / side job kind of thing.

Someone needs to write a Dummies Guide to... kind of book.

@Pete-S said in Service provider - monitoring questions:

Thanks guys for your replies!

I had a feeling that monitoring was "underutilized" compared to what is technically possible. But as always, it's the business needs and the effort (cost) that determines the service level.

totally underutilized compared to what is possible. you are 100% spot on with that.

@Pete-S said in Hybrid SaaS?:

@dafyre said in Hybrid SaaS?:

@Pete-S said in Hybrid SaaS?:

Yes, the Startech device is an industrial embedded server.

I am checking to make sure of the model of the ones that are in use now. But basically the devices that I am thinking of, all they do is take whatever comes in over the serial port and send it to the server ip and port you set it for.

If your program is a special program that requires using a COM port, it can be set up for that too. (for instance, if your scale has to communicate over COM3 in Windows).

I understand what you are saying. It's a fact though that every device that does this is a linux/bsd computer of some kind. It doesn't take much processing power but you need a complete tcp/ip stack inside. There are a bunch of manufacturers for these devices.

Also if we talk about scales that you would normally use in some kind of production or quality control, nowadays they commonly have an ethernet port either as standard or as an option. Still any real-time processing will be on-prem. Results might be sent to the cloud though for presentation and final storage.

That's what I'm seeing... can't imagine when we'd want a server "somewhere" storing a bunch of random scale data.

@scottalanmiller It's pretty mature now. The feature set is minimal but works fine compared to some other options I've played with. If they added a few more features it would be golden.

Congrats!

@PhlipElder said in Protek Support MSP Ransomware Hits Customers in Salt Lake City, Utah:

@Pete-S said in Protek Support MSP Ransomware Hits Customers in Salt Lake City, Utah:

@PhlipElder said in Protek Support MSP Ransomware Hits Customers in Salt Lake City, Utah:

@Dashrender said in Protek Support MSP Ransomware Hits Customers in Salt Lake City, Utah:

@dafyre said in Protek Support MSP Ransomware Hits Customers in Salt Lake City, Utah:

@PhlipElder said in Protek Support MSP Ransomware Hits Customers in Salt Lake City, Utah:

All it takes is one absentminded click or drive-by that's completely shielded from us as we go about the day to day stuff and it's done. Game over. Say, "Bubbye".

There's always going to be that risk or one absentminded click.

Granted an Air-gapped PWA is a good way to handle it.... but so is not saving passwords in RDP files (I don't do this), and if you use an app like MobaXterm that can encrypt the files for you, use a good pass phrase.

However if your admin machine is owned, you have bigger issues to start with.

Well, the idea is that the air-gapped machine won't ever be in a situation to become compromised, is my guess. I haven't had a chance to look at the MS link Philip sent earlier.

There are several ways to implement with the simplest being the main machine having two VMs installed on it. One for day-to-day and one for client/systems management. Nothing is done on the machine itself with all designated tasks being done in their respective VM.

We have a number of laptops that came back from client refreshes. So, we're using them as our dedicated management machines. Asus makes a great external USB3 DisplayLink and DisplayPort external monitor that allows for two screens. That makes the work easier.

There is security leakage between VMs on a client machine for instance over clipboard.

Have a look at Qubes. https://www.qubes-os.org/

It's probably the best implementation of security separation to date.

Using the Hyper-V VM Console without RDS pass-through eliminates any access to the VM beyond console.

Same with KVM or whatever.

MSP Maturity Model. Strictly speaking, the MSPMM does not tell MSPs to make all of their customers identical. But in practice, it encourages it and many MSPs talk about the MSPMM in these terms - finding ways to make customers all run the same tools, software, practices, network design, etc. This makes management so much easier for the MSP, but has two major problems.

First, it forces the customer to conform to the vendor, which makes very little sense. IT needs to adapt to the business, not the business to IT. But that's another topic.

Secondary, it means that an attack vector that works on the MSP will likely work on every single one of their customers making the prospect of breaching the MSP that much better. Sure, if a targeted attack by experienced state-sponsored hackers goes after an MSP, the MSP has little chance of winning that battle. But that isn't the real risk. In the real world, the risk is automated attacks looking for common vulnerabilities and spreading organically through shared tooling - things that are only possible or reasonably likely when the environments are homogeneous: both amongst the MSP clients, and between clients and the MSP themselves.

The traditional approach of MSPs, especially VAR - MSP combo companies, is to have not only the same tools and software, but even the same hardware and products so that any hole anywhere because a hole everywhere and breaching any one piece of the infrastructure means you are likely to breach it all.