@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.

In the event now.

@Dashrender said in Consultancies Advertise People; VARs Advertise Products:

@EddieJennings said in Consultancies Advertise People; VARs Advertise Products:

This may seem simplistic, but if I were in this scenario, on which side of the MSP / VAR would I stand?

A person hires me to help spec out a server for their office. I'm paid to help them determine how much RAM, storage, processors, etc. they need.

This part is clear, I'm being paid for advice; thus, MSP.

A point of clarity - advising only this is not being an MSP - you'r not managing anything (managed service provider). ITSP or Consultancy would be better terms for this portion... heck - the whole thing, including recommending a hardware vendor, because again, you're not managing anything.

True. I ought to have used those other terms.

And this one...

https://ntg.co/outsourcing-and-offshoring/

@kelly said in How Can the FTE Model Compete with the MSP Model?:

Maybe not directly for the company, but the MSP has to recoup the costs of time and travel somehow, and that will affect rates if you're going to stay profitable.

That is very true, no denying that. But you can build those costs in. There are certainly costs involved, but there are savings too. You have to look at the whole picture.

In this example, we have housing costs about 20% lower than they do, our fuel is way cheaper ($.25 I bet), and our Internet is a fraction of the cost (about 10% the cost, I kid you not.) Going local to them would require us to raise prices, traveling to them is trivial.

@carnival-boy said in MSP or VAR or just avoid:

For an MSP to be truly agnostic it would either have to massive (to be able to employ both Oracle and SQL Server experts), or it is full of generalists who can support both but lack expertise in either.

That's part of the goal, or typical goals, of moving to the MSP model. They bring more scale and with scale comes agnosticism (the move towards it, but obtaining it as you pointed out.) You might not have expertise or experience with every OS out there, but even a moderately small MSP like NTG regularly supports and works with many databases. Not Oracle, which isn't a big deal as it has essentially no place in any intentional deployment, but MS SQL Server, MySQL, MariaDB, PostgreSQL, REDIS, MongoDB, SQLite, etc. all regularly supported.

MSPs are way more likely to have the desire and ability to grow support skill sets, although this can happen internally as well. But internal skill growth is costly and risky to maintain. For an MSP, skill growth increases potential customer support options. So MSPs have more incentive to consider things they've not done specifically before than internal IT departments do.

Nothing is perfect, but MSPs make agnosticism easier and more likely.

@mike-davis said in How MSPs provide their services:

@scottalanmiller said in How MSPs provide their services:

That's a lot of investment for a system like that. If you have hundreds of customers, it can make sense. But it takes a lot of customers to recoup the lost time into that system. It can work out well for a traditional MSP, but depends on large scale standardization to justify the investment.

I don't know about hundreds of customers. The number of end points might be more relevant. For me at about 10 MSP customers I can justify the investment. When you look at the time it takes to set up something like a zabbix server and maintaining a WSUS server vs not having to that helps make it worth it. Missed revenue because you didn't have a system in place to capture every minute hurts.

It would be a blend, I'm sure. A single customer with a million end points wouldn't make sense because you'd use more traditional tools in a single customer scenario. And a hundred with only one end point each wouldn't do it either. So some combination of enough end points for volume and enough customers for complexity put together.

@storageninja said in The argument for official support vs third party support:

@dashrender said in The argument for official support vs third party support:

Same problem for the vendors. If you are dealing with unpatched spares, so are they. Having worked for some of the big ones, I know that their supply chains struggle to get parts, too. Heck, IBM couldn't deliver a server internally in more than six months, imagine how hard it is to get support parts!

Shit like this just blows my mind.

Parts Bins, internal supplies for labs, and customer supply chains are all completely different (well IBM may have been a gong show). Dell and HPE staff can't just go grab something off the line, with Mfg you have to account for the costs and someone gets to pay (and often at a premium to prevent abuse) for those internal servers.

Parts Bins and stocking those are different, and supply chain for a OEM might actually be different in the us than EMEA.

At IBM< we were an external customer, even though we were inside IBM. We showed up just like any external enterprise customer. So their inability to support was universal.