Why isn’t every VAR a successful managed service provider (MSP)? There are many paths to success, but aspiring MSPs also make many common mistakes that hinder their ability to become profitable. In our previous guest blog, we talked about four common errors MSPs make. Interested in becoming a successful provider of managed services? Here are four more common blunders you need to avoid.
Error 5: You wing it – you don’t need new sales tools.
Typical product sales tools focus on the technology of the offering, and perhaps the reputation of the manufacturer. But a managed service is delivered by you, and it becomes an integral part of your customer’s business. This means you’re selling the value proposition of managed services (e.g. IT outsourcing) via the competence and reliability of your organization. To do that you’ll need new sales tools – some that focus on the business value of managed services and others that highlight your organization.
Error 6: You make the customer conform to your technology.
Whatever technology you use to deploy managed services, it must have very low impact on the customer’s environment. The more things you have to change to deploy managed services, the more objections will be raised, and the longer the deployment will take.
From a technical perspective, the following are critical requirements:
- No agents – you shouldn’t need to deploy agents on customer platforms.
- No VPN – shared VPN setups are difficult and unreliable, and they take time to maintain.
- Low WAN impact – you should strictly minimize the impact on the customer’s WAN connection, e.g. through local performance and fault monitoring.
- Broad endpoint support – you’ll need to cover a broad array of servers, network devices, desktops, and applications.
Error 7: No news is good news.
If you encounter a problem in your delivery of the managed service, e.g. in monitoring the customer environment, you’d better know about it. Nothing will cause a customer to lose confidence more quickly than having them discover issues you don’t spot and correct. To that end, you need to actively monitor your ability to manage your customers. There are two aspects to this:
- You need to continuously monitor the network connectivity to your customers, and performance and fault monitoring reliability.
- You need to continuously monitor the status of your core monitoring system itself, so you can be alerted if an overall system failure occurs.
Error 8: You deliver the service, send the bill, and think you’re done!
In many instances, if you’re delivering managed services properly, the customer never sees a problem or the efforts you’re undertaking on their behalf. But because you’re billing them regularly, it’s critical to justify the invoice with a demonstration of the value you’ve provided. The best way: comprehensive, high quality, management-level reporting.
Customer reporting should include, at a minimum, the following information:
- The number and types of systems and applications you’re monitoring.
- Key system performance metrics during the reporting period.
- The number and severity of fault conditions detected, with a highlight of those that are most significant.
- Security vulnerabilities detected on the monitored systems.
- Patches that are missing, and patches that were remediated during the reporting period.
- Remediation activities undertaken on the customer’s behalf.
- A set of IT recommendations, e.g. for hardware/software upgrades or configuration changes.
Stay tuned for our next blog post when we will discuss several more mistakes companies need to avoid in order to become successful MSPs.
Peter Klanian is a senior channel sales manager in the Dell Global Services organization at Dell Inc., which develops managed services software for MSPs. Guest blog entries such as this one are contributed on a monthly basis as part of MSPmentor.net’s 2009 Platinum sponsorship.
Read More About This Topic
Share This Post
Posted In: Guest Bloggers | Marketing | Platforms | Sales | Service Level Agreements
Tags: Dell managed services | Everdream | managed services best practices | managed services mistakes | Peter Klanian | Silverback Technologies
Interact: Add a Comment | Trackback Link | Permalink
Subscribe: RSS Feed
Get Started: Visit our new 
I strongly disagree with #6. Your assertion that using an agent-based monitoring solution is near-sited and sounds very much like a sales pitch to the Dell solution. I can think of many situations for which an agent will be beneficial (remote workers, small offices, remote offices, etc).
You also assert that a VPN should not be utilized, either. Again, this sounds like an argument strictly to enforce the benefits of the Dell solution. We use VPN technology extensively and reliably, and I’d argue that although a VPN solution can be difficult to maintain and keep reliable, it isn’t necessarily.
Instead of requiring a “no agents” and “no vpn” approach, you might consider recommending “a well thought-out approach that includes weighing the pros and cons of agents and vpns before deciding on an approach.”
By saying that the “more things you have to change to deploy managed services” is a bad thing, you imply that a customer’s network is already running well. I have no problem changing a LOT of things when we take over, because I am confident that our changes are for the better.
Like Travis, I must disagree with #6 as well, but probably not as strongly. We currently use a RMM technology that doesn’t require agents to be installed, yet we find ourselves all the time wishing in some circumstances that we could deploy an agent for roaming laptops and branch offices. The flexibility of an agentless technology is good – but often leaves some things to be desired.
Furthermore, I’m not sure what Travis is using VPN for – maybe you can elaborate? Our support staff does use VPN for support functions but we never perform our monitoring over VPN (for the aforementioned points by Peter in his article). There have been situations where I’m sure our support staff has used VPN for monitoring things such as bandwidth and choke points but I’m pretty sure that would be the extent of it.
Not making the customer conform to a technology? I’ll disagree as well. Why would I want to knowingly support a customer with antiquated technology that will hurt my profitability and my bottom-line revenue? Maybe you were talking about a vendor’s technology or specified application instead Peter, I could be mistaken. But even if that is the case, I’d much rather be supporting a technology our engineers are comfortable with if it poses a viable and smart upgrade for the customer (all the while providing them more reliable and predictable support services).
I am going to have to agree with Pete on # 6. Having to deploy an agent to every system on a network is not only time consuming and difficult to manage. There are surely some situations where an agent makes since but I would have to say this is an exception as compared to the norm. So why would you base your solution on the exception? About 8 years ago we deployed an agent based system to all of our customers, about a month into it they released a patch to the agent this patch had a bug and ended up bringing down the networks of several of our largest accounts. Needless to say we moved away from an agentless system pretty quickly after that and have never looked back.
Also the No VPN requirement is a pretty solid suggestion as well. For our first few years as an MSP we required a VPN connection to our customers as there were no other options as the RMM tools were too immature and did not have any remote connectivity. This steadily became more and more difficult to manage and started to limit our ability to support our customers. Fortunately today with the functionality that the RMM tools and the remote desktop tools have there really is no need to have a VPN connection anymore.
Travis & John,
Thanks to both of you for your comments. I’ll respond to each of your main points.
Agents:
The wording I used regarding agent-based technology may have been too focused on server/network monitoring. In fact, Dell offers agent-based options for laptop and desktop monitoring. Perhaps a better statement to make regarding agents is, “Avoiding agent-based solutions, where possible, allows for the simplest, lowest-impact deployments.” To Travis’ and John’s points… avoiding complexity whenever possible is typically the best approach and avoiding agents is in line with this theory.
VPN:
There may be areas where VPNs are optimal for point remediation but deploying VPNs as part of a standard monitoring architecture is simply not needed with the technology we have available today. They are costly and complex and offer no tangible benefits for day-to-day networking monitoring.
Conforming to technology:
My point here is that MSPs should not have to force sweeping changes to their customers’ environments just to implement a monitoring solution. Monitoring platforms that allow light, simple deployments are best for MSPs and their customers.
In the interest of full disclosure, you should know that I work for the folks that run http://www.virtualadministrator.com, so take whatever necessary amount of salt you’d like with what I say. However I should tell you that many of the people that have come to use our service have left environments like Level Platforms that have been “network based”. The fact is the network, as we used to know it, doesn’t exist any more. Any system that requires connectivity to the actual internal network for antivirus updates, patching, etc, is somewhat flawed, as more often than not, the threats are collected in the field when not behind any kind of firewalling (hotels, homes, etc.) and then brought back to the office. Kaseya, Zenith, and other agent based systems (according to Peter, including Dell) are based on the belief that the network exists wherever the machines are. Use situations like the Conficker scare as an example. Whatever solution people choose should be able to respond instantly, and universally, to such concerns. Peter, I look forward to your response(s).
Standing up for agent technology…
I’m reading that agents are time consuming to deploy, complex, etc. and agentless is quick, easy, etc… I disagree and would argue back that for MSPs agents should be the preference, not the exception – here’s why;
- Agent based systems monitor more health check points than agentless solutions – this is key to ‘see’ more of the target managed system and to architect a highly resilient monitoring system
- Unlike agentless solutions, agent based systems continue alarm analysis and data collection on the local system when network connections are down, when connections are back up data is released to the central server – this results in no gaps in service level reporting
- Agent based solutions function in an exception based fashion – meaning health check data is analyzed on the monitored system with only exception alarms being sent to the central management server, this eases the demand on network bandwidth
- Agent based solutions typically much more robust for event log monitoring
Regarding agentless monitoring being quick and easy when compared to agent-based solutions, I would argue against that notion… agentless solutions require monitored systems to have proper remote access services and protocols available and running on the target systems (i.e. WMI, SNMP, SSH, Telnet, etc.) – in many cases these requisite components are not running or missing and the effort to get each system ready for agentless monitoring can equal, or more likely exceed, the time and effort to install agents across numerous systems. Let’s also consider firewall configurations for each agentless monitored system – this is a significant effort as well.
Adding to the potential challenge of setting up an agentless environment are its limitations in monitoring and architecture that could introduce risk;
- Many agentless monitoring solutions lack resiliency; unlike agent-based solutions, with an agentless approach there is a risk of lost data in instances of broken connections between the central management server and target system resulting in gaps in service level reporting
- Agentless is usually ok for basic operating system and network monitoring but is typically less able for deep network, database, and commercial/custom application monitoring
- Log monitoring (ascii, syslog, event) may be lacking and inefficient (i.e. transporting log file contents across the network for central processing) or non-existent
- Agentless monitoring consumes excessive network bandwidth due to frequent communications and heavy data collection between the central management server and abundant target systems
- Agentless system monitoring is typically limited in the volume of unique health check points that can be observed on the target managed system, this limitation introduces risk.
There certainly are good reasons for agentless monitoring, for example;
- Where deep system/server resident monitoring is not a requirement
- When lack of monitoring robustness and resiliency does not introduce risk
- When agents are not allowed to run resident on the customers servers
- Monitoring application performance from the end-users perspective, i.e. transaction simulation
10 of 10 Nimsoft customers choose agents or a hybrid approach;
Nimsoft partners/customers have a choice – we offer robust agent and agentless monitoring. However interesting is that 10 of 10 Nimsoft customers will chose agent monitoring with a percentage of those 10 choosing a hybrid approach (agent plus agentless).
Ken Vanderweel
Nimsoft, Inc.
You have got to be kidding me. C’mon Peter. #6 is just not true. For you to state that, even in the context of your “restated” #6 in a later comment, clearly points out that you have never been in the trenches and provided excellent managed services to a company. Agents can easily be low impact, and the things that they let you do far outweigh any overhead imposed on the system. I suppose next you are going to try to tell the MSP’s that antivirus should not be installed either (after all, they are agents, and they monitor, right?) because they impact the system.
Joe P., your blog is quickly losing credibility here. While I appreciate the business model (they pay, they get to guest blog), allowing guest blogs like this from people who have no idea how to actually do managed services is a discredit to the MSP community as a whole. After all, someone might actually read this and believe what Peter is saying. Just because someone has Dell pasted in their signature line (or any company for that matter) doesn’t make them an expert on Managed Services. Neither does buying out a monitoring software company.
The only plausable argument in this blog post is #5. And that’s only because you should never “wing it”.
Please quit letting them post falsehoods here, and let’s get back to some real honest reporting!
Tim Beard/Networthy Systems
And yes, I resell Dell products, so I have nothing against Dell, other than this incredulous guest blog.
Tim B/Networthy Systems
Peter’s comment on Dell’s agentless architecture seems to have hit a painful nerve. Let me share my views on why the agent-based products have every reason to be concerned and why products like Dell, Level Platforms and the new agentless products now coming to market will ultimately win this debate where it counts – in the field.
The agent-based products promoted in these blog comments are all excellent and mature products that were conceived and built in the 90s. In those days client server was the basic computing model and the only way to manage these devices was to deploy a proprietary agent. SNMP was for the network guys but the real issue was managing the PCs and servers.
Early this decade Microsoft introduced WMI signaling the end for third party agents on Windows devices. Not stopping at WMI, Microsoft has continued to add new management features to their operating systems. I encourage you to look at Windows 7 to see first-hand the new features that the agentless products will soon be exploiting. And the related WS- Man standard now being implemented across open source, MACs, SUN servers etc., will allow agentless products that exploit WMI to manage these outlier technologies with the same core agentless technology.
Not only are agents becoming irrelevant but as soon as you look at technology beyond basic PCs and servers, agent-based products begin to run into some big problems. A wave of new technology is supplementing and will ultimately replace the time worn client server computing model.
Virtualization, SaaS, cloud, unified communications, Intel’s AMT, etc., can all be far better managed within a common agentless architecture that leverages standards to provide a comprehensive view of all the components of IT and their interactions. I enjoy watching the introduction of “hybrid” solutions and “special agents” as older products scramble to introduce agentless capabilities in the face of a rapidly approaching end-of-life.
Finally large MSPs and Master MSPs need scalability. A single tier architecture with hundreds of thousands of agents each individually firing in to a data center, in what should be close to real time, cannot compare to the two tier architecture represented by an agentless solution where the workload and communications management can be distributed.
MSPs need to think seriously about how they will be positioned to compete both today and tomorrow as a wave of new technology enters the market.
If anyone is interested in receiving our Agent versus Agentless White Paper please let me know and I will ensure you receive a copy.
Peter Sandiford
CEO
Level Platforms
psandiford@levelplatforms.com
I don’t think the failure of a managed service provider has to do with choosing an agent or agent less solution. There are agentless solutions that work well e.g. Silverback, Level Platforms as well as solutions that work with agents e.g. Kaseya and the solution provided by us (Zenith Infotech). Failure or success of an IT services company providing a broad spectrum of managed services depends more on their sales organization, the quality of their staff, their delivery processes, the breadth of their services offerings and a host of other “business” things. An RMM tool is a very small portion of it – a commodity to anyone willing to pay a small amount of money. Its like saying that the success of a sculptor depends on the hammer and chisels he uses rather than the skill and the process used by the sculptor and quality of people working with the sculptor. In short my message to MSPs is focus on what makes the business tick (give that 90% of your time) rather than getting carried away by tool capability. At Zenith we have Everon Technology Services (a MSPMentor 100 company) as a partner as well as a large number of not so successful partners.
Akash Saraf
CEO
Zenith Infotech
I apologize, I left my comment incomplete. The last thing I wanted to say that at Zenith we have very successful partners like Everon, Pointivity, LMS Technical Services (all MSPMentor 100 companies) as well as a large number of partners who not had much success in providing managed services. The reason is because its not the tool or the vendor that makes the difference, its how you run the business, deliver you managed services, maintain your customer relationships that really matter.
Akash Saraf
CEO
Zenith Infotech
Let’s face the facts…there are a huge number of people that think that agent-less is the only way to go and then there are a huge number of people that absolutely require agents. There is no answer to the agent vs agent-less question apart from “it depends”.
Of course, included in the list of proponents for one method versus the other are representatives (like me) of the vendors that provide their solutions and guess what…they will create all the arguments in the world to support the capabilities of their products.
Customers and therefore MSPs must have flexibility. They must be able to choose between agent based or agent-less or, in many cases a combination approach. Nimsoft offers both, so, just like the other vendor CEOs, I am also supporting our company position. This is why Nimsoft tends to be chosen by the more established MSPs who have matured beyond the limited approach of some of the lower end products (that are very good by the way for smaller MSPs getting started).
Nimsoft has recently replaced Silverback at a number of high profile MSPs, including one who wanted to use agent-less and the other wanted agents. Interestingly, the agent-less MSP “absolutely refused” to use WMI as the mechanism for managing Windows servers. The extract from the customer’s email to us…. “The reason this would not work for us currently is that we have approximately 1200 windows systems under management today, and WMI is very problematic to say the least on the newer windows based platforms”. This is a real life MSP, dealing with real life management issues – not a vendor supporting their position.
Nimsoft responded by adding in other methods for getting the data from the Windows server platforms (RPC).
One final comment…agent-less for Cloud? Resources that are there one minute and gone the next, that don’t have a fixed IP address, that communicate their information across the public internet, that you need secure, encrypted and guaranteed delivery of the monitoring information. From our research to date, and we have both Cloud providers and Cloud consumers using Nimsoft, it looks like an agent-based approach is definitely the preferred method but we’ll see….having both capabilities means that we can take a neutral position.
So…don’t believe the vendors who arguing one method to the detriment of the other simply to position themselves correctly.
Bottom line – as an MSP you want flexibility – ensure that any solution you invest in has the flexibility and breadth that you need.
Gary Read
CEO
Nimsoft
garyread@nimsoft.com
Right on Akash, it is how you service them. We’ve probably all been less than thrilled with some of the tools, we’ve used in the past, but you adjust as necessary.
Now agent vs agentless, vpn vs. no vpn. I have had the opportunity to support multiple clients of every imaginable configuration utilizing a number of tools mentioned, and not mentioned. IMO, thus far, agent based wins out over agentless if you account for all the time spent deploying and managing the tool and it’s idiosyncrasies, and really, that is what the tools you manage your customers with are for, to save your time and your customers time. Now, that being said, we are in the process of evaluating one of the agentless products and run it thru it’s paces to see what if it can deliver what we require. We’ve previously used two (mentioned in the comments) of the agentless companies, but it’s been years. Back then, their tools were definately not up to the challenge and we replaced them with agent based tools. Today the agentless architectures available might be mature enough to work as required.
We also maintain static vpn’s to all clients. We don’t monitor over them, but use these ease our remote access to certain devices and securely deliver all of our services. All of our tools will run securely without the vpn, but having the vpn in place allows us to provide more rapid problem resolution in most cases. We’ll have to adjust as more SaaS offerings emerge, but thus far it works well for us.
I strongly favor what Akash said about how to run the managed services business. the failure and success doesn’t depend upon the agent and agent less deployments but how quickly and efficiently you deliver the services you offer.
Anit Chaudhary
Manager
Real Time Data Services
Akash and others advocate that business comes first and that the “tools” are commodities of little concern to the MSP. This is fine for today but what about tomorrow?
The analogy used of the sculptor and his tools is quite appropriate. If industrial designers today were limited to “hammers and chisels” I am not certain what our world of steel and plastics would look like today. I am not sure any of us would want a hand chiseled automobile no matter how skilled the workman and his team.
My point is simply that cloud computing, virtualization, SaaS, unified communications, etc, are the technologies of tomorrow. Client server computing and the companion agent based management “tools” designed for this era are hard pressed to support these new technologies. Emerging standards across the computing industry over the last decade are redefining the tools required around an agentless future.
MSPs can be successful with both agent and agentless technologies today where we continue to frame the problem in terms of PCs and servers. My argument is simply that the world of network-based computing is already moving onto center stage. MSPs with the appropriate tools will have a growing and ultimately unassailable advantage as they apply their ingenuity and business skills to addressing their customers’ needs with the tools appropriate to the task.
Peter Sandiford
CEO
Level Platforms
psandiford@levelplatforms.com
Rich Forsen referred to the often-observed issue that a device not connected to the LAN cannot be managed by an agentless solution. This has traditionally been a fair criticism of agentless systems.
Level Platforms new Offsite Assistant is in beta today and will be released shortly as part of our Mnaged Workplace 2009 r2 release. This is a network-based solution and does not require the deployment of a management agent on the device, thereby maintaining all the benefits of agentless systems without introducing the significant problems and limitations associated with agent-based systems. Anyone interested in learning more about this breakthrough technology is welcome to contact me directly.
Peter Sandiford
CEO
Level Platforms
psandiford@levelplatforms.com
Gary Read’s recognition of the opportunity represented by agentless technology is certainly welcome. However his colleague Ken Vanderweel’s comments above “standing up for agent technology” provide some insight into why this embrace seems half-hearted.
Here is a specific point by point response to Ken’s comments, which as they are commonly expressed by agent technology proponents, I have characterized broadly as “myths”.
Myth 1 – Agent based systems monitor more health check points than agentless solutions – this is key to ‘see’ more of the target managed system and to architect a highly resilient monitoring system
Fact – Agentless systems are policy based, meaning that they have a general capability to monitor any attribute via a monitoring protocol. That makes their capability unlimited when it comes to monitoring health check points. In contrast, most agent-based solutions feature built-in monitoring of selected attributes. Only a few support the ability to download policies for monitoring.
Myth 2 – Unlike agentless solutions, agent based systems continue alarm analysis and data collection on the local system when network connections are down, when connections are back up data is released to the central server – this results in no gaps in service level reporting.
Fact – A Windows server probably fails orders of magnitude more frequently than a Cisco switch. When a system is failing its agent is impaired and when it fails it is dead. Only agentless systems can monitor unavailability. When service is restored, agentless systems can continue to monitor seamlessly the transition from unavailability to availability. In the event an external connection is down, the local management software component (in Level Platforms case the Onsite Manager) can continue to collect data from all devices and maintain a continuous record of the entire health of the network.
Myth 3 – Agent based solutions function in an exception based fashion – meaning health check data is analyzed on the monitored system with only exception alarms being sent to the central management server, this eases the demand on network bandwidth.
Fact – Agentless systems operate in exactly the same way. In fact in our case the Onsite Manager also compresses the resulting data flow of exception conditions received from many end-systems, further reducing network traffic. This is something agent-based systems can never do.
Myth 4 – Agent based solutions are typically much more robust for event log monitoring.
Fact – Agentless systems can capture any event with the added flexibility of policy based management to easily add new events. Agentless technologies have the additional ability to catch event log entries made by the operating system between the time when all services have failed (including any agents) and when the system has restarted those services.
Myth 5 – Regarding agentless monitoring being quick and easy when compared to agent-based solutions, I would argue against that notion… agentless solutions require monitored systems to have proper remote access services and protocols available and running on the target systems (i.e. WMI, SNMP, SSH, Telnet, etc.) – in many cases these requisite components are not running or missing and the effort to get each system ready for agentless monitoring can equal, or more likely exceed, the time and effort to install agents across numerous systems. Let’s also consider firewall configurations for each agentless monitored system – this is a significant effort as well.
Fact – Ensuring that end-systems that are properly configured is a basic requirement for anyone offering managed services. Agentless systems enforce this fundamental best practice. As these technologies are more widely adopted the vendors are moving quickly to automate these processes so that any disadvantage is not only minor but temporary. The ability of an agentless system to immediately detect and manage new assets is a major advantage.
Myth 6 – Adding to the potential challenge of setting up an agentless environment are its limitations in monitoring and architecture that could introduce risk. Many agentless monitoring solutions lack resiliency; unlike agent-based solutions, with an agentless approach there is a risk of lost data in instances of broken connections between the central management server and target system resulting in gaps in service level reporting
Fact – This was addressed above (see Myth 2).
Myth 7 – Agentless is usually ok for basic operating system and network monitoring but is typically less able for deep network, database, and commercial/custom application monitoring.
Fact – Deep network monitoring is actually easier with agentless because it inherently requires consolidating a view across many network elements – none of which can run agents! Deep monitoring of databases is better handled remotely because they all support a remote SQL capability in order to support client/server applications The same facilities can be employed to provide deep monitoring of database system and application tables. The resource consumption of all applications can be monitored deeply via remote monitoring of system performance counters. Custom applications that follow best practices are also readily monitored remotely because they write events to the Windows application event and security logs. Even applications that write to custom logs can also be monitored remotely via WMI. In fact with the advent of virtualization, “deep monitoring” is actually much harder to do with agents since they can never monitor more deeply than that virtual machine that they run within. Agentless solutions can also monitor the hypervisor layer that is hidden from the agent’s VM viewpoint.
Myth 8 – Log monitoring (ascii, syslog, event) may be lacking and inefficient (i.e. transporting log file contents across the network for central processing) or non-existent.
Fact – The majority of standard protocols such as WMI, WS-Man, SNMP/Trap provide a way to filter content. It is not necessary to transport entire log files.
Myth 9 – Agentless monitoring consumes excessive network bandwidth due to frequent communications and heavy data collection between the central management server and abundant target systems.
Fact – In our experience there is no measureable impact on local network performance and significant efficiencies in communicating externally to a remote service management center by centralizing and consolidating external network communication.
Myth 10 – Agentless system monitoring is typically limited in the volume of unique health check points that can be observed on the target managed system, this limitation introduces risk.
Fact – There is no counter in a Windows system that cannot be monitored remotely.
Myth 11 – There certainly are good reasons for agentless monitoring, for example;
- Where deep system/server resident monitoring is not a requirement
- When lack of monitoring robustness and resiliency does not introduce risk
- When agents are not allowed to run resident on the customers servers
- Monitoring application performance from the end-users perspective, i.e. transaction simulation
Fact – None of these conditions need to be present to justify agentless technology’s advantages.
Nimsoft Concluding Observation – 10 of 10 Nimsoft customers choose agents or a hybrid approach.
Fact – While I am sure this is true, I suspect this has more to do with Nimsoft than their customers. The hybrid approach which virtually all the agent based systems are using to deal with the growing inadequacy of agents represents the worst of both worlds. In a hybrid environment, the MSP must keep track of (a) which systems have no agents and are not being monitored (b) which systems have agents (c) which systems have no agents and are being monitored agentless and (d) which systems have agents that also provide agentless monitoring of other systems. Consider the cost of administering this complexity compared to the simplicity of the agentless solution where none of the systems have agents and all are being monitored through one consistent set of centrally established policies.
Peter Sandiford
CEO
Level Platforms
psandiford@levelplatforms.com
Peter, I agree and disagree on your reply. My comment was more in context with the main article which put selecting an agent based tool as a sure way to fail as an MSP – which in my opionion is not accurate. My thinking is that a smart MSP like a smart sculptor needs to keep adjusting his/her tools as technology changes and as customer needs change. I think it is too early to judge which method – whether agents or agentless will work better with technologies like SaaS, unified communications or cloud computing. To give an example to effectively monitor and troubleshoot voice, we’ve found that neither agents or a polling based agentless technology really works to well. Rather a packet sniffing approach (like Ethereal)with the correct pattern matching algorithms works the best. Similarly cloud computing is a whole new ball game (we’ve built a private cloud product that we launch in a couple of months). Hence your point that paying attention to the right tools is spot on. However, I dont think agentless is the best model for every scenario out there.
I must say this has been one of the best conversations I have seen here. I came in to this open but with a definite preference, I have now moved back toward the center (but not completely). The above posts reminded me that while agent vs. agent-less each have their own pros and cons, it is a secondary issue when selecting an RMM. The two real important factors are:
1) The specific RMM’s implementation of their chosen approach and more importantly…
2) The specific needs of the individual MSP’s customer base. The MSP selecting a new RMM platform needs to start with the business drivers. For an MSP focusing on small business where they are the de facto authority on the customer’s environment then they are open chose on other factors. Yet an MSP who’s clients are more sophisticated may have other constraints to contend with: The customer not allowing the deployment of agents; Firewall / ACL configurations on the customer networks, etc. The technology should not be selected in a vacuum of technology considerations, the starting questions should be:
• What does the MSP need to monitor for their profile of customer (e.g. significant workstation tilt, complex networks, databases, etc.) and how deep (are there specific metrics needed)? Which RMMs do that type of monitoring best?
• What solution will be the fastest to deploy in their type of customer (remembering the sooner a new client is turned up the sooner the MSP can start billing)?
• Which solution will provide the best automation and integrations (e.g. PSA systems)?
• Which solution will provide the lowest cost of ownership?
Holding each RMM’s agent or agent-less implementation against questions like these should yield the best result for the MSP.
David Schafran
Transformation Strategies
http://www.TransStrat.com
Akash,
Funny that you mention “An RMM tool is a very small portion of it – a commodity to anyone willing to pay a small amount of money.” in #10, above. Not more than a day ago did I write a blog post about exactly that point.
http://www.dedicatedit.com/blog/south-florida-computer-network-support-from-dedicatedit/reason-23-we-dont-rest-until-your-computer-network-is-safe/
Adam