MSP Minded? What You Must Know About Remote MonitoringManagement

In early 2006, Steve Solbrack, president of Solbrekk IT Network Solutions in Golden Valley, Minn., decided to make a move into the MSP space. Since building a custom solution for monitoring and managing his clients' networks was far too expensive, he turned to N-able Technologies' software package, which appeared to offer a relatively easy path into the market, he says.

Unfortunately, Solbrack says, things didn't quite go as planned. Like many other solution providers looking to use third-party software platforms to ease the managed service transition, he quickly ran afoul of a combination of problems with the product, the managed service business model and what he calls "unrealistic expectations."

"We're still moving in that direction," he says. "But for the moment, we're regrouping, refocusing and narrowing our offering."

Slide Show: 4 Tools That Put MSPs In (Remote) Control

Solution providers are setting their sights increasingly on remote monitoring and management (RMM) in the quest to expand their services offerings. It's not hard to see why; RMM fuels a consistent revenue stream and relatively high margins. It also offers potential cost reductions in the form of automation and fewer customer site visits.

"Really, what we talk about is how to evolve your strategy and your existing business. So you've spent a long time developing into a services business. You've got to, obviously, because of the reduction in hardware margins and so on," says Dan Wensley, vice president of partner development at Level Platforms. "We as an entire industry have moved toward a service model, and we really see MSPs as nothing more or less than an extension of that model."

The question for most solution providers, then, is not whether to move into RMM, but how. And, as it turns out, that's not an easy question to answer.

Until recently, offering RMM as a service in any kind of systematic fashion required complex and expensive custom-built solutions that were too resource-intensive for most VARs and too cost-prohibitive for most clients. But as the MSP market has grown and solution providers have migrated to the managed service model, new vendors such as Kaseya, Level Platforms, N-able Technologies and SilverBack Technologies have moved in with software to ease the complexity and cost of RMM. In effect, they provide all of an MSP's basic software infrastructure in a box.

All of these RMM products feed the service provider a constant real-time stream of data from a variety of devices on the client's network--including servers, networking hardware and desktops--and allow them to remotely manage those devices. Each of the RMM vendors has sought to find a balance between ease of deployment and customization; new would-be MSPs generally need a relatively forgiving technical learning curve but also must tailor the application to meet their own capacity and their clients' networks. Most vendors sell the primary monitoring and management console for installation on the solution provider's network, though several offer a hosted service option. Some, but not all platforms, require the installation of one or more software agents on the client's network.

NEXT: RMM growing pains.

The RMM market is embryonic. Because RMM platforms are opening the MSP space to new segments of the channel, vendors and their partners are often unsure of what to expect--from the technology, end customer and each other. This has inevitably led to a number of significant stumbles as the various players struggle to find their footing.

"The market has definitely got a ways to go before it's mature," says David Salzberg, director of business and market development at business management software vendor Autotask, which works closely with RMM vendors and their partners. "I've heard glowing reports on each vendor; I've also heard horror stories."

N-able has been the target of particularly intense criticism from VARs and MSPs, many of which believe that the company has devoted too much of its attention to sales and marketing at the expense of software development and support.

"The product just never delivered as we were told it would," says Erin Arnold of Next Step Networking, an MSP and former N-able partner based in Cincinnati. "It was kicking out so much false information that our engineers just ended up ignoring it. We were paying all this money for a tool no one used."

Solbrack sums up the sentiments of many in the channel: "They just oversold and underdelivered. The tool didn't do what they said it would."

N-able CEO Gavin Garbutt acknowledges that the company has had some troubles in the past but says that things have changed significantly in the past year. "Understand, we definitely had our issues, and I'm the first one to admit it," he says. "We aggressively addressed them, and now the feedback we're getting is very, very positive."

Garbutt says the company has significantly invested in its core technology, support and partner programs. "The difference between the company in April of last year and today is just night and day," he says. Though perhaps an extreme case, N-able is far from alone in facing criticism from even committed channel partners; all of the major vendors seem to get their share.

"We're happy with Kaseya," says John Pavlik, president of Hillsboro, Ore.-based MSP Resource One. "But I'll be honest. We get really frustrated sometimes with things that should work that just don't. Having Kaseya is a management job in and of itself; we spend a lot of time reporting bugs and problems. Sometimes it feels like they just haven't tested enough. That said, we're still happy, and I haven't seen any other option that's better."

NEXT: The biggest mistake you can make.

Perhaps the biggest pitfall for solution providers, however, is the temptation to allow the choice of a specific RMM platform to drive business model changes, rather than the other way around.

"Because service providers are used to evaluating solutions, they tend to pick a tool first and then try to build an offering around it," says Don Begg, CEO of San Diego-based Do IT Smarter, which hosts SilverBack for other MSPs. "That's a mistake."

Begg says building the MSP practice first is key. Then solution providers should implement a tool to automate their practice. Otherwise you end up with tools that don't fit the customer base and are forced to rebuild and retrofit the tools to make them work the way that you need them to, he contends.

Craig Valentine Brenner, CEO of New England Data Services in Waltham, Mass., which just completed an internal study of various RMM products, agrees. "It's about your business and what you want to accomplish with these products in your business," he says. "Define your service offering first, plan where you want to go next, then pick a platform that fits both of those. Once you decide on your offering, you can invest the resources to go deeper into the products."

Poor planning for the adoption of an RMM platform can have an impact far beyond the selection of a specific tool, however. A VAR can very quickly find itself well beyond its comfort zone, in terms of both technical expertise and business practices.

"The vendors, the clients--everyone's got different expectations about what these things should do," says Harrison Feather, president of Madison, N.J.-based audio-visual solution provider Creative Associates. He argues that most would-be MSPs simply don't understand the full scope of technical capabilities they need to meet the client's expectations of an MSP, and, in turn, they expect too much from their vendors in terms of ease of use.

"There's going to be a lot of pain before the managed service platform market grows up," he predicts.

Ian James, president of Red Square Systems in Pittsburgh, believes that solution providers almost always drastically underestimate the changes to business plans and processes needed to take advantage of an RMM platform. "It's different in the way that it's priced. It's different in the way that it's delivered. It's certainly different in the way that it's sold."

N-able's Garbutt believes that most VARs simply aren't prepared to use these products successfully without substantial support. "We've found that if we give the service provider technology alone, they'll fail," he says. "Bottom line--We've just seen it too many times, where somebody says, 'Oh great, this is a really cool technology and it's going to revolutionize my business.' It's not. The only thing I know for sure is that there's no silver bullet. This is hard work."

NEXT: 5 things to know before you deploy RMM.

Five things to know before you deploy RMM:

1. Know Your Tools
You need to be intimately familiar with all of the ins and outs of your RMM platform well before you start deploying it for clients; these are not simple applications that you can just drop into place. A RMM platform heavily touches mission-critical infrastructure, so you need to know its default responses to any given alert or action and all of your options for modifying those defaults. For example, will your platform automatically reboot a machine after applying an operating system patch? If so, will it warn users first?

2. Calibrate Information Flow
Networks generate a lot of information; you need to decide early on how much information you can handle, which information you need and which you don't. Configure your RMM platform to provide too little information and you'll inevitably miss a key alert. Get too much information and you'll be flooded, unable to distinguish between urgent, important and trivial. Draw information from the wrong sources within your client's network and you'll get the worst of both worlds.

3. Know Your Client's Network
Be familiar with every device your RMM platform will touch, and how it interacts with each. Not every RMM product plays equally well with others. Some can't manage certain devices or operating systems; Kaseya, for example, can't manage Unix- or Linux-based systems. Some require additional software to do so; Level Platforms can manage Unix, Linux and Macintosh, but only via a VNC client. Be particularly aware of legacy hardware or software.

4. Identify Potential Points of Failure
Something will eventually go wrong--it always does. You can't stop it, but you can have a response ready if something goes wrong with a key element of your platform. Does your RMM platform rely on a single software agent or appliance on your client's network? Do you require a VPN connection? Identify those bottlenecks and have a response plan ready to implement when one of them fails.

5. Plan For Scalability
Your initial deployment to a 30-device network may be flawless, but how are you going to implement global changes once it's grown to 3,000 devices? Scalability can come at a price in terms of flexibility or other features, so don't necessarily assume your client's network is going to explode by a factor of 10.