How to Build a Successful Managed Services Team – Part 3

How to Build a Successful Managed Services Team – Part 3

For part 3 in our series on building your championship-caliber MSP, we will examine the final component that is needed from a staffing and roster perspective – your ‘coaching’, support and administrative staff. By now you have established your identity and mapped out who you are going to be as an organization. You’ve made your decision on what traits will be the calling cards of your team so that clients will know you and expect what you plan to deliver. You’ve also filled out your roster with the right kind of talent. You’ve established roles (positions) for your team and found the top talent available for those positions. It’s now time for you to have the right people guiding your team and helping navigate the many challenges that are sure to come your way as you enter the topsy-turvy world of providing Managed Services!

Coaches

Keeping with our sports theme, consider what coaches do, even at the elite level. There’s what happens in practice and training, and then there’s what happens on game day. That is to say a coach is teaching and training during the week, and guiding/directing on game day. In much the same way, your MSP coaches need to be teachers as well as directors. Today’s IT workforce is diverse – in almost every way: age, origin, experience/tenure, gender.  Your coaches need to be able to relate to all their players and meet them where they’re at so that they can continually teach the processes, techniques, and attitudes needed to win it all. Naturally there are limitations to the sports analogy and those of us in the managed services game know that every day is game day. That means your coaches have to be able to switch into director mode and can ‘call the plays’ to put the team members into positions to be successful. Who are your coaches in an MSP? How about a Support Manager? Perhaps a Sales Manager. In the same way it’s common for coaches to wear multiple hats (Offensive Coordinator and Running Backs Coach) – our MSP coaches often do the same. In our company, it’s not uncommon for even some back-office managers to have some direct revenue responsibility as a VCIO or some other capacity.

Help Desk

If you are just getting started or are a smaller company, you may find it daunting to establish a help desk. There have been, and continue to be several companies that offer to fill this function for you on a retainer basis – and we are not here to say those are necessarily bad options. Companies such as IT By Design and even distributors such as Ingram Micro can be “your” team. What we do want to convey to you is that whether you insource or outsource this function (my preference is insourced), that you double-down – scratch that – you triple-down on making sure the quality and consistency are there with that group. Your helpdesk should be staffed by associates that are personable, conscientious and understand customer services. We have often mentioned to our team, we are *really* in the customer service business more than the IT business. It’s an important mind shift. We know by now you’re probably thinking that IT professionals that are both technically competent and personable are in the same class as unicorns and leprechauns. NOT TRUE! (but darn close!) They are hard to find indeed but do exist. While we have always tried to hire first for the “who” than the “what”, we have put even more emphasis on that idea when hiring for our help desk. We have tried to bridge the gap in technical shortcomings with better processes, documentation and in-house training, and we’ve noticed subtle trends of customer satisfaction and engagement improving, even if our Time to Resolve has degraded slightly. To us, it’s an acceptable trade-off. To go further, within your helpdesk you *also* have multiple positions. (Just like an outfield has a Left Fielder, Center Fielder, and Right Fielder). In a Help Desk, you may have multiple tiers of associates that handle increasingly complex issues as needed. Traditional help desk structure is an L1-L2-L3 tiering system or perhaps a Triage-Resolution-Escalation. There are also recent trends in building focused groups within your help desk that work with only certain subsets of customers or industries. All models have their merits and you need to choose which one is right for you and your customers. No matter what you choose, put in the necessary work to have outstanding processes for your help desk to follow so that your customers can experience the consistency we discussed in Part 1, with a personable and positive experience provided by your talented helpdesk team!

GM

Most professional sports teams have a General Manager (GM). They are the ones responsible for assembling the team on the field, the organization behind it and overseeing the whole entity. Correlating that to our MSP, this would be someone who, depending on the size of your organization, could be a COO-type individual that guides the day to day operation. In the scope of this would be ensuring there is an influx of talent (), and that the coaches are developing that talent (they would represent middle-management) as well as deal with upstream concerns. Think about how key individuals in professional sports deal with things like contract negotiations, the media, salary cap management, union concerns – much more “business” related duties. In an MSP it would be no different.

Executive Team, Support Staff, Marketing, Etc

Rounding out the organization, we have the key positions of leadership at the executive or ownership level, as well as support staff and outward facing functions to ensure there is accountability, productivity, and proper branding to the community. In sports, you see this thoroughly as few industries or organizations are marketed more heavily. In an MSP, whether we insource or outsource, having an outbound face to the markets you serve is imperative. Word of mouth is awesome, but only on rare occasions will that form the kind of business development that will sustain your pipeline as you grow. It’s a part, but not the whole. Your support staff is critical. These are often your unsung heroes that ensure that processes are followed, services are billed (and properly!), and even the simple things happen to ensure success. Your positions of leadership must be filled by individuals who can truly lead, but also (in the case of smaller companies) shift into “get it done” mode and manage outcomes. This requires individuals with high emotional intelligence, discipline, and ambition. While those individuals are driving the business and leading the team, it’s the supporting staff positions like Administrative Assistants, Resource Coordinators, Inside Sales Associates that all help make the magic happen and keep the team on the field (think of the beloved Student Manager for the High School basketball team that makes sure the players have water!)
To keep up to date with the latest articles and practices, pay a visit to our Hornetsecurity blog now.

Conclusion

A top-flight Managed Services operation is more about having the right people (personality, strengths/weaknesses, aptitudes, attitudes) in the right places to ensure the whole, is stronger than the sum of its parts. If you are the leader of an organization that is still climbing that championship mountain, follow the blueprint we’re providing in this series to take the steps needed for “playoff contention”! The advice in this series of articles comes from working with hundreds of individuals across 2 decades in the MSP industry however you’re welcome to disagree with my assessment of the best personalities that comprise an effective MSP.

FAQ

Who are considered the 'coaches' in an MSP?

In an MSP, coaches can be roles like Support Manager or Sales Manager. They teach and guide the team, ensuring processes are followed and team members are successful.

What is the role of a General Manager (GM) in an MSP?

The GM in an MSP is akin to a COO. They oversee daily operations, ensure a steady influx of talent, develop middle management, and handle business-related duties like contract negotiations and financial management.

Why is a support staff important in an MSP?

Support staff ensures that processes are followed, services are billed correctly, and administrative tasks are handled efficiently. They are crucial for the smooth operation and success of the MSP.
How to Build a Successful Managed Services Team – Part 3

How to Build a Successful Managed Services Team – Part 2

In part one of this series, we shared with you some truly foundational thoughts as to how you are going to decide what to be as a company providing customer support and managed IT services – essentially establishing your identity in much the same way as a sports team decides who they will be on the field of play. We also shared with you some key traits that we believe are essential to becoming a “champion” in the managed services space – traits of Consistency, Proactivity, and Discipline. We see these as foundational as speed, strength, and intelligence when describing athletes. Speaking of the ‘players’, let’s talk about the positions or roles necessary, and who you should be looking for to fill out our championship roster!

Positions or Roles

We believe there are some absolute core areas that you must address when building out a managed services practice. Often in football, you hear about a team building from the ‘trenches out’ meaning from their offensive and defensive lines, or in basketball you hear about identifying your scorers, defenders, rebounders and the like. We can equate these notions to our managed services team too! Let’s examine.

Help Desk

If you are just getting started or are a smaller company, you may find it daunting to establish a help desk. There have been, and continue to be several companies that offer to fill this function for you on a retainer basis – and we are not here to say those are necessarily bad options. Companies such as IT By Design and even distributors such as Ingram Micro can be “your” team. What we do want to convey to you is that whether you insource or outsource this function (my preference is insourced), that you double-down – scratch that – you triple-down on making sure the quality and consistency are there with that group.

Your helpdesk should be staffed by associates that are personable, conscientious and understand customer services. We have often mentioned to our team, we are *really* in the customer service business more than the IT business. It’s an important mind shift. We know by now you’re probably thinking that IT professionals that are both technically competent and personable are in the same class as unicorns and leprechauns. NOT TRUE! (but darn close!) They are hard to find indeed but do exist. While we have always tried to hire first for the “who” than the “what”, we have put even more emphasis on that idea when hiring for our help desk. We have tried to bridge the gap in technical shortcomings with better processes, documentation and in-house training, and we’ve noticed subtle trends of customer satisfaction and engagement improving, even if our Time to Resolve has degraded slightly. To us, it’s an acceptable trade-off.

To go further, within your helpdesk you *also* have multiple positions. (Just like an outfield has a Left Fielder, Center Fielder, and Right Fielder). In a Help Desk, you may have multiple tiers of associates that handle increasingly complex issues as needed. Traditional help desk structure is an L1-L2-L3 tiering system or perhaps a Triage-Resolution-Escalation. There are also recent trends in building focused groups within your help desk that work with only certain subsets of customers or industries. All models have their merits and you need to choose which one is right for you and your customers.

No matter what you choose, put in the necessary work to have outstanding processes for your help desk to follow so that your customers can experience the consistency we discussed in Part 1, with a personable and positive experience provided by your talented helpdesk team!

Engineers

Contrary to some opinions, the good ‘ol Systems Engineer is NOT extinct! We have read and been in discussions where people will cite the overall reduction in complexity of technology today (primarily hardware and software) and use that to suggest that engineers aren’t needed as much as even five years ago. While we see their point and there is some basis when you consider say a Storage Area Network (SAN) five years ago would have been a six-figure equipment sale and likely a 50-100 hour project to implement and migrate data. Today, in most cases, it’s a $50K equipment sale and many are user-installable! Quite a shift! That said, we believe we are seeing an increasing need for those with technical aptitudes to stay up on technology interoperability and best practices while also wrapping everything around what a sound security posture looks like.

The reality today is that the majority of your clients-to-be for your budding managed services practices are going to have Windows servers, Windows PC’s (maybe some Macs), network printers, switches, routers, firewalls, WAPs, and the like. Pretty “traditional” stuff from an IT infrastructure standpoint. Thus far, we aren’t seeing any requests for us to put IoT or other smart devices under managed services. Given that, your engineers are still very much in vogue and will be for several years. Keep them sharp and develop them to be experts in more than one discipline. Do you have server/storage engineers? Then develop their networking expertise. Do you have ‘techs’? Grow them into engineers! We have found that the ideal “player profile” for this position is someone who thrives on variety and learning, is not afraid of trying new things (not recklessly mind you!) and has 3-5 years of experience building/deploying IT infrastructure. Experience is key in this role – so fill your roster with “vets” versus “rookies” as much as you can here.

Strategist

More than likely, your new managed services clients will not have dedicated IT people, let alone IT management, or perhaps anyone that even *wants* to know about IT. They are hopefully focused on what it is their business does. That’s your opportunity to provide technical thought leadership to your client.

Think of this person as your “team leader” – the one with the “C” on their jersey. Your strategist should be informing your clients about emerging trends that can be helpful to their business (or avoid risks), establish roadmaps, budgets and get to know the business inside and out. Your Strategist will also help call the plays for your team to ensure they are in a position to succeed.

Drafting these types of players has its own challenges. They need to speak ‘business’. While not required that they are a techie, they should truly understand and also speak ‘tech’. Much like your engineer, this is not the role you put a rookie into. Find a professional – someone who has perhaps run an IT department before and give them this roster spot.

To keep up to date with the latest articles and practices, pay a visit to our Hornetsecurity blog now.

Conclusion

While there are more roles we could drill down on, we consider these roles the core of a winning team. In our next part, we’ll talk about the ‘coaching staff’ and any additional support required to reach a championship level.

FAQ

What are the essential roles for a managed services team?

The essential roles include Help Desk associates, Engineers, and Strategists. Help Desk associates provide frontline support, Engineers handle technical infrastructure, and Strategists offer technical leadership and business insights.

Why is it important to have different tiers within a Help Desk team?

Different tiers within a Help Desk team, such as L1, L2, and L3, ensure that issues are resolved efficiently by matching their complexity to the appropriate expertise level. This structure enhances problem-solving and customer satisfaction.

What qualities should a Strategist possess in a managed services team?

A Strategist should have a strong understanding of both business and technology, be capable of offering technical thought leadership, and have experience in IT management. They should help clients with emerging trends, roadmaps, and budgeting.

How to Build a Successful Managed Services Team – Part 3

How to Build a Successful Managed Services Team

In this series, we are going to show you how to build a successful managed services team. We will attempt to bring you along, build our roster, round out a coaching staff, and put a team “on the field” that can carry us to a championship! A unique opportunity to blend the geek and jock worlds! Unfortunately, the MSP world doesn’t quite have the equivalent of the Super Bowl, but if it did, the team we will be putting together would no doubt be holding the Vince Lombardi Trophy aloft every season.

Over the coming articles, we will be breaking down the elements we feel are the most important building blocks for successfully assembling a well-organized Managed Service Provider that will leave your customers and your bank manager delighted. The first topic we’ll be covering is establishing an identity – a critical characteristic of any championship-winning team.

Identity

We firmly believe that building a strong team requires a strong foundation: an ethos. You have to determine what your identity and team philosophy will be before you can start building a winning game plan. In a sport such as football, you may aspire to be hard-nosed and physical. Will we be offensive-minded or defensive? When building your Managed Services team, we think you should aspire for a team whose hallmarks are first and foremost tremendous consistency, proactivity, and discipline. You might notice that while not exclusive, these may not be the top traits you’d normally think of when imagining your classic engineer-types from the T&M and project worlds. That’s because the MSP game is materially different. Think rugby vs. American football. Kinda similar. K-i-n-d-a, but actually quite different. So why those three? Let me elaborate:

  • Consistency – Over the years we’ve heard some MSPs say they aspire to be like McDonald’s. For the most part, a Big Mac purchased in Sacramento, California should be 99.9% consistent with a Big Mac purchased in Grand Rapids, Michigan. The ingredients, the techniques, and the processes are done the same using equipment and tools that are the same. That’s what these MSPs are talking about – being able to deliver a quality product (not gourmet mind you!) with tremendous consistency client in and client out.
  • Proactivity – There may be no other trait AS important as this one when you commit to delivering managed services. If you are consistently the dog getting wagged by the tail due to reactive support volume, you will question whose bright idea it was to get into this game in the first place. It takes people thinking a different way. Rapid response and technical competency are of course necessary and helpful, but someone(s) *must* be thinking about how any given problem can be avoided for the rest of eternity. If there are chronic printing issues – WHY, and what can be done to not just get things working but completely eliminate the problem from ever coming back. What can be done to ward off any potential circumstances that could lead to a reactive situation? This must be the dominant mindset.
  • Discipline – Let me give you some small examples from our journey into Managed Services maturity. In any technical professional services practice, you’ll have numerous projects where you are upgrading, replacing, and installing new things – servers, switches, routers, firewalls, applications, operating systems – you name it. For many of you, this is something you do. Hopefully, when you’re done, you update your client’s documentation, maybe a Visio diagram, and away you go. In the Managed Services arena, those types of things, whether project-related/wholesale changes or a onesy-twosy replacement can cause some very undue stress. Imagine if you are monitoring the network equipment of ABC Company. Your well-intentioned engineer goes on-site to upgrade the firewall at 5 PM and forgets to suppress monitoring or advise someone on the team to do same, or mention that alerts can be ignored. All of a sudden at 5:10 PM several alerts come flying through your monitoring tools and e-mail boxes. Texts are sent and phone calls are made – probably indicating that ALL of the network devices at ABC Company are now offline! Yes, we learned this lesson many times over and even now, occasionally suffer a lapse in the discipline required to avoid unnecessary cycles getting spent. Another example of a shift in thinking relates to my above-mentioned case about updating documentation. If you are responsible for supporting this client for most or all of what they could possibly call in for, then *whose* documentation needs to be updated? That’s right – YOURS! YOU need to have updated documentation on all aspects of their environment. Every equipment change. Credential change. Address change. Location change. Point-of-contact change. You need to have the exquisite discipline to administratively maintain the key information required to enable your team to provide excellent support.

To keep up to date with the latest articles and practices, pay a visit to our Hornetsecurity blog now.

Conclusion

We’ve shared with you the starting point for how to build a successful team – establishing your team’s identity. Recognizing the mind-shift needed to make the change from a traditional professional services team to a Managed Services Team. Just as in building your championship-caliber team, you need to know what your identity will be – what will support and be affirmed by your team (corporate) culture. In the next part of this series, we will begin to look at the next step – establishing the roles for your team and building a roster of superstars!

FAQ

Why is establishing an identity important for a managed services team?

Establishing an identity is crucial as it sets the foundation and ethos of the team. It helps in defining the team’s philosophy, ensuring consistency, proactivity, and discipline, which are essential for delivering high-quality managed services.

How does proactivity benefit a managed services team?

Proactivity helps in preventing issues before they arise, reducing the volume of reactive support needed. By identifying and eliminating potential problems early, the team can maintain smooth operations and improve client satisfaction.

What role does discipline play in managing a successful MSP team?

Discipline ensures that all procedures and documentation are meticulously followed and maintained. It helps in preventing unnecessary stress and inefficiencies, such as avoiding false alerts and ensuring updated client information, which are critical for effective support and management.

Top 3 Proven Patch Deployment Methods for MSPs

Top 3 Proven Patch Deployment Methods for MSPs

To patch or not to patch, that is the question. No question about it, patch. And patch often. But wait, my application will not work with that new .net update! So, the struggle between security and operations continues. Many engineers would say that if it’s not broken, don’t patch it. This is a very dangerous practice as more and more security breaches are designed to harvest data or resources while not disrupting the network. While in the past, the intent was to bring the network down, cyber hackers now zero in on the company’s network resources and end users with the goal of data mining. Hackers can and will take advantage of these security flaws if patching is not done in a timely manner. As you can see, patching is extremely important and, if neglected, could put your systems and your clients’ systems at risk. This post explains the best practices so you can choose the right patch deployment method for your specific requirements.

Manual Deployment

The first method is the old-school way: manually deploying patches. Many small managed service providers continue to use this method today for many reasons. The main reason would be the ease of getting into the market. It has very little upfront cost. This method is very labor-intensive and slow. It is the ideal patching method for a small managed services provider. Applying patches in this way requires accessing each endpoint and conducting updates as needed. However, it’s not a method that allows a larger managed service provider to scale to a larger size or market. With that said, even with a large managed services provider, those “troublesome servers” remain within this patching strategy. This is primarily due to custom applications and other dependencies that will make patching a challenge. Another issue with this method is that it is pretty much “patch and pray.” You are relying on the vendor to release patches, and they won’t bring the network down.  As a result, labor spent on testing patches is not cost-effective due to the many different system configurations and the requirement of having those resources available for said testing. Combine the labor spent on testing with the labor spent to implement the patches, and things become cost-prohibitive for any managed services provider with more than just a handful of clients.  Most of your hard cost of goods will be in labor and will increase steadily as the endpoint base increases.

Advantages

  1. Low to no cost for system
  2. Very customizable to accommodate specific client needs

Disadvantages

  1. Labor intensive and requires larger workforce
  2. Time consuming when deploying patches
  3. Less scalable with limited potential for growth
  4. More risk in applying a “bad” patch
  5. Decentralized management requiring additional resources

Third-Party Patching Systems

This cannot be understated; you cannot build a cyber-resilient organization without involving every single person who works there. This starts with the basic awareness of asking someone unknown who isn’t wearing a badge in the office to identify themselves, and if the answer doesn’t stack up, calling security. When someone calls you claiming to be from the IT helpdesk and asks you to approve the MFA prompt you’re about to receive on your phone, don’t assume they’re telling the truth. Always double-check their credentials first to ensure that it’s a legitimate request. What you’re trying to foster is “polite paranoia”, making it normal to question unusual requests, and understanding the risk landscape and sharpening instincts. Most people who work in businesses aren’t cyber or IT savvy and weren’t hired for those skills. However, everyone needs to have a basic understanding of how identity theft works in our modern digital world, both in their personal and professional lives. They also need to have a grasp of the business risks introduced by digital processes, including emails. By having this context they’ll be able to understand when things are out of context or unusual and have enough suspicion to ask a question or two before clicking the link, wiring the funds, or approving the MFA prompt. And this isn’t a once-off tick on a form to achieve compliance with a regulation. Often, the long, tedious, and mandatory presentations that organizations conduct once a year or quarterly, followed by multiple-choice quizzes, are perceived as time-wasters by the staff. They want to rush through them quickly and typically forget any insights gained. Instead, the training program should be designed to be ongoing, consisting of bite-sized, interesting, immediately applicable, and fun training modules combined with simulated phishing attacks to test users. If any user clicks on a phishing email, they should be given additional training. Over time, the system should automatically identify users who rarely fall for such attacks and interrupt them with infrequent training, while the persistent offenders are given additional training and simulations on a regular basis. The other reason for ongoing training is that the risk landscape is continuously changing. Some months ago, malicious emails with QR (Quick Response) codes to scan were the exception, now they’re a very familiar sight, requiring ongoing awareness of staff not to scan them on their phones (outside of established business processes). Security experts often lament the priorities of staff, saying, “if they only took a second to read the email properly, they’d spot the signs that it’s phishing”, or “they just don’t take security seriously”. This is a fundamental misunderstanding of the priorities and psychology of the average office worker, clicking a link in an email will at most get you a slap on the wrist, not fulfilling an urgent request by the boss can get you in serious trouble or even fired. And this is why the entire leadership, from middle managers all the way to the C-suite must lead by example. If they do and communicate their understanding of the basics and secure processes, staff will follow suit. But if the CFO requests an exemption from MFA or bypasses security controls regularly because “it’s more efficient”, there’s no chance that his underlings will take cyber security seriously.

Advantages

  1. Decrease time in deploying patches with scripted patch delivery
  2. One-time cost of software and hardware

Disadvantages

  1. Decentralized management requiring additional resource
  2. There is no prior testing of patches before deployment
  3. Requires network resources as each client’s location

Cloud-Based Patch Deployment System

The last method is to deploy a cloud-based patch deployment system. Many current MSPs offer remote monitoring and management (RMM) platforms, such as Labtech, Continuum, and Kaseya, as part of their bundle of services. Some vendors, such as Kaseya, just provide the centralized delivery of the patches, while other vendors, such as Continuum, provide additional value by performing quality testing of the patches prior to implementation. This centralized method allows an MSP to manage patch deployment policies for multiple customers. An added benefit is maximized growth with less labor since the function is driven from one pane of glass and is well-automated. The burden of testing patches on a massive scale is shifted to the cloud-based vendor and away from the managed services provider. This reduces the managed services provider’s labor force needed to maintain this service offering because only after the patches pass the quality assurance testing of the servicer are they deployed to the endpoints. Like third-party patching systems, many cloud-based patch deployment systems are price-based, on tiers. This method normally decreases overall costs as the managed services provider enters higher tiers.  In short – As the managed service provider grows and scales, the cost of this service decreases. Thus, this method will generally benefit the managed services provider with lower costs while maximizing the use of their system. The second method would be to install a third-party patching system that would automate the installation of patches. Several third-party patching systems exist, such as Microsoft SCCM, GFI LanGuard, and Kaseya. However, this is a decentralized management method since the system’s administration is conducted in each client’s environment without a single pane of glass to manage multiple clients. Testing is still required for the proper patches to be installed. However, this method does eliminate the labor of applying patches individually.  Many vendors will have a tiered pricing structure as additional third-party patching systems are deployed. With each new client, there will be a dramatic increase in price. Many of these third-party systems are low-cost for the software. However, they require network resources and a labor force to implement, administrate, and remediate.

Advantages

  1. Centralized management of patch deployment
  2. Many services have patch testing prior to deployment
  3. Low labor cost as a smaller workforce is needed
  4. Less time consumed in testing and deployment

Disadvantages

  1. Higher cost and is normally a monthly expense
  2. Less customization for specific client needs

Which Patch Deployment Method Should You Choose?

Deciding on the right patch deployment method for managed service providers is a critical choice that hinges on various factors, including cost, scale, labor intensity, and specific client needs. Here’s a brief rundown to guide your decision: Manual Deployment:
  • Best for: Small MSPs or those just starting out due to low upfront costs and high customizability.
  • Considerations: Labor-intensive and time-consuming, suitable for limited-scale operations or those with specific, troublesome servers needing careful patching.
Third-Party Patching Systems:
  • Best for: MSPs looking to automate patch installation while maintaining some control over the process.
  • Considerations: Requires network resources and a labor force for administration. Decentralized management might complicate things, and there’s an inherent risk of untested patches causing issues.
Cloud-Based Patch Deployment System:
  • Best for: Larger, growing MSPs aiming for centralized management and reduced labor costs.
  • Considerations: Generally has higher upfront costs but is offset by the scalability and efficiency it offers. Pre-testing of patches by the vendor adds a layer of security and reliability.
To keep up to date with the latest articles and practices, pay a visit to our Hornetsecurity blog now.

Conclusion

In summary, your choice should align with your MSP’s size, growth trajectory, and the specific needs of your clients. Small providers might lean towards manual deployment for its low cost and customization, but as the business grows, the scalability and reduced labor intensity of cloud-based systems might become more appealing. Consider the trade-off between upfront costs, ongoing expenses, and the labor required for each method against your ability to manage and scale your operations effectively. Ultimately, the right choice balances cost, efficiency, and risk management to support your business’s growth and service quality.

FAQ

How can MSPs ensure minimal disruption when applying patches?

MSPs can ensure minimal disruption by scheduling patch deployment during off-peak hours, conducting thorough testing in a controlled environment before rolling out patches, and utilizing rollback plans in case of failures. Cloud-based systems that offer pre-tested patches also reduce the risk of disruption.

What criteria should MSPs consider when choosing a patch deployment method?

MSPs should consider the size of their client base, the complexity of their clients’ environments, the scalability of the solution, labor and resource availability, cost implications, and the specific needs for customization and control. Additionally, evaluating the security and compliance requirements of their clients can guide the choice.

How do MSPs handle custom applications that may not be compatible with standard patches?

For custom applications, MSPs often use manual deployment methods to apply patches selectively and avoid compatibility issues. They may also work closely with software vendors to obtain custom patches or updates and perform extensive testing in isolated environments to ensure compatibility before deployment.
Hyper-V vs. VMware – What is Best for Your MSP?

Hyper-V vs. VMware – What is Best for Your MSP?

Hello everyone! Today we’re discussing a subject that has garnered many articles and discussions over the last several years. That is, whether Hyper-V or VMware is better for your MSP toolbox. Many of you may already have a winner in mind, and that’s fine, I only ask that you keep an open mind. 

Additionally, you should note that I write this article with the assumption that in both cases you would have technicians that are fully trained and understand each product. It wouldn’t be a fair comparison if you compared a veteran Hyper-V engineer’s deployment vs a novice VMware Admin’s deployment. So, as we talk about both technologies below, engineering know-how will enter into the discussion very little. Without further delay, let’s start by looking at features!

Features


Features have become a part of the VMware vs. Hyper-V debate that has become much more difficult to cover in the past couple of years. This isn’t because one is far better than the other in this area. It’s the opposite! Feature parity between the two is basically a wash these days. For example, both have: Additionally, looking at what both vendors call configuration maximums (the largest amount of resource utilization/assignment the hypervisor/VMS can handle), it’s apparent that each vendor’s maximum is so high only the mega-corporations of the world risk running up to those limits as shown below. Hyper-V Host Maximums for Example hyper-v hosts VMware Host Maximums vsphere hosts As you can see, both options scale out to ridiculous heights, with both having the ability to serve up just about any virtualization need your customers could come across. If you’re interested in looking further into these config maximums, you can find the Hyper-V Maximums discussed here and the vSphere ones here. This hasn’t settled our debate, so let’s move on to the next section Manageability

Manageability


The manageability story for this comparison is a bit murkier than the features section above. Each vendor has a different management story and a slightly different way of doing things. If I had to break it down as quickly as possible with a short answer, I would say this: With a fully trained team, management of either product is effective for MSPs. However, vSphere is more forgiving for junior engineers and those who may not be familiar with virtualization. I say this with Hyper-V being my hypervisor of choice and due to the following:

In vSphere, you have a single pane of glass tool for managing the entire solution; the vSphere Client. You connect to the vSphere client on a stand-alone host or a vCenter instance, and the management experience is largely the same. With Hyper-V, you will use one of several possible tools, including:
  • Hyper-V Manager
  • System Center Virtual Machine Manager
  • PowerShell
  • 3rd Party Management Tool
  • Azure Front-End (If using Azure Stack)
While these different tools are highly effective, they are all used in different deployment types and scales, which can lead to confusion and frustration for new IT Pros. That difference aside, both of these products are well-suited for MSP management. Both have integrations with MSP RMM and reporting platforms, and both can be used in automation scenarios via PowerShell and PowerCLI.

Likely the determining factor here is going to be what your engineering team is comfortable with. If you’re automating as many functions as you can (and you should be), the numerous management tools for Hyper-V are likely a non-issue. So, from an MSP perspective, comparing these two tools, we’re still at an even stretch after this section. Let’s talk about pricing and cost next.

Pricing and Cost


At this stage of the discussion, I start to lean towards Hyper-V. From a pure engineering perspective (no talk of sales or margins involved), Hyper-V wins this section hands-down. And I would argue it’s due to one simple fact. With Windows Server licensing, you are given virtualization rights to run 2 VMs with a standard edition and the ability to run unlimited VMs with datacenter edition on a licensed piece of hardware. This is regardless of the hypervisor type. This requirement is the same whether you’re running Hyper-V or vSphere, and this is where the determining factor comes from.

The vast majority of your customers are going to be running Windows Server. That’s just a fact. If you want to run Windows Server on top of vSphere, you still have to buy those Windows Server licenses, and guess what? That Windows Server license comes with Hyper-V, and all you need to run a small to a mid-sized cluster already. So, it comes down to a simple question. Why would you pay for the extra licensing for vSphere when you already get what you need for most use cases with the purchase of Windows Server licenses that you must buy anyway? For a standard business (Engineering know-how aside), the answer is simple. For an MSP, a little less so. For the aspiring MSP, the decision to choose vSphere over Hyper-V comes down to three extra factors. 1 of which I personally don’t like.
  1. Adding vSphere to the deal adds extra profit margin for the MSP
  2. vSphere is already the defined virtualization solution in the MSPs toolbox.
  3. Chosen Hybrid Cloud Option.
I will concede that all MSPs have a mandate to make money. That’s how the business continues to grow and function, and everyone needs to put food on the table at the end of the day. However, I have an issue with selling a product (in this case vSphere) for the sole purpose of adding to my profit margin. If that’s the ONLY reason I’m choosing vSphere as an MSP, my customers should look elsewhere because it increases the cost on them for the sole goal of lining my own pocket. You’d be surprised how many times I’ve seen this. If this describes you, I would argue that when it comes to cost specifically (all other factors aside), doing a given project with Hyper-V will allow you to come in at a lower price point. Sure not as much margin, but long-term customer trust goes a long way.

As for item 2 on the list above, it’s never too late to change your toolset. If this is the sole resistance to changing your core virtualization choice, then I would suggest putting together a proof of concept and going from there. Item 3 is fairly simple as well. It’s no secret that Hyper-V has native integrations with Azure, and that VMware is closely aligned with AWS. If you have an affinity for one of those public clouds over the other, that may well influence your decision as well.

Is Hyper-V or VMware Better for MSPs?


So, we’ve looked at a few different things as part of this discussion, and I’ve found in my travels that these are the three most important areas for MSPs. Ready for the winner? My answer to which one is better? Surprise! It comes down to which one fits your company culture better. Are you a historically Microsoft-centric shop and want to use Azure? Then go with Hyper-V? Are you a fan of AWS? Then you likely want to go with VMware.

Are you looking for on-prem only and want the lowest cost for your customers? Choose Hyper-V. But please, for the sake of your customers, don’t be the MSP that chooses VMware just to get a little extra margin.
Whatever choice you make, train up your engineers and integrate it into your MSP stack, and your chosen solution will serve you well. Both are fantastic and mature products with large companies behind them ready to help if needed. What do you think? Agree with my assessment? Don’t agree with it? Thanks for reading!
How to Use Azure Automation Runbooks for MSP Customers

How to Use Azure Automation Runbooks for MSP Customers

Microsoft has made great strides in the hybrid cloud automation space with Azure Automation. For Managed Service Providers this is a great tool to take advantage of when managing multiple clients. We can now run our “scheduled tasks” on-premise with Azure Automation and get the following benefits:
  • Azure Log Monitoring – We can now configure alerts for scheduled tasks with Azure Monitor Logs. Now there is more visibility into our scheduled scripts that fail.
  • Encrypted Credentials – Azure Automation provides that ability to securely store credentials and call them via scripts. This one is huge, as we can easily call credentials without having to mess around with encrypted password files and certificates.
  • Hybrid Cloud Versatility with Scripts – We can choose whether to run a script either on-prem, in Azure, or both. This gives us more versatility to run our scripts anywhere.
Looking for general PowerShell Credential Encryption Guidance? See our guide on encrypting passwords with PowerShell! Looking for ways an MSP can get started with Azure? We have more resources to help MSPs get started with Azure!

Setting Up an Automation Account


  To get started using Azure Automation Runbooks, we need to have an Automation Account set up. If you don’t have an Azure account already, sign up for the free trial. Then login to the portal and search for Automation Accounts. Select the Add button to create a new account: Automation accounts Azure Fill out the required fields to create the Automation Account. Select Yes to create the Azure Run As account, we could create it manually if needed but the easiest route it to just have Azure create it when setting up the Azure Automation account: add automation account  

How to Create an Azure Log Analytics Workspace


  In order to use Azure Automation Runbooks on-premise, we will need to set up a Log Analytics Workspace. This a service in Azure that provides monitoring and logging for the various Azure services. In the Azure Portal search for Log Analytics Workspaces, select Add: log analytics workspace azure Fill out the required fields, the pricing for Log Analytics is based on storage, so your only paying for the storage to store your logs: Now we need to link our Azure Automation account with our Log Analytics Workspace. As of right now, this has to be done through PowerShell. So open up an administrative PowerShell window and run the following command to install the AZ module:
Install-Module AZ -Force
Then run Connect-AZAccount to connect to your Azure Subscription:
Connect-AZAccount
Now we need to get the resource ID for our Automation Account, we’ll use the Get-AZResource cmdlet and filter by resource type and our automation account name. In my example it’s LukeLabAA. We want to save the resource ID to a variable so we can use it shortly:
$AAResourceID = (Get-AzResource -ResourceType "Microsoft.Automation/automationAccounts" -Name "lukelabaa").resourceid
We will do the same for the workspace resource ID using the same cmdlet with the workspace resource type and the name of the workspace we just set up:
$WSResourceID = (Get-AzResource -ResourceType "Microsoft.OperationalInsights/workspaces" -Name "lukelabaa-LA").resourceid
To link the account with the workspace we will use the Set-AZDiagnosticSetting cmdlet and reference both resource ID’s:
Set-AzDiagnosticSetting -ResourceId $AAResourceID -WorkspaceId $WSResourceID -Enabled 1
To verify that the account is linked we can see in the output that JobLogs and JobStreams are enabled:

Setting Up the Hybrid Worker Node


  The Hybrid Worker Node is an agent that is installed on an on-premise server running either Linux or Windows. This agent is used to execute commands from the runbook to the on-premise environment. The image below from Microsoft’s documentation gives a good depiction on the high-level topology for the communication between the Hybrid Runbook Worker and Azure Automation. You can group Runbook Workers together to create a redundant solution for your Runbooks. Also, note the port 443 connectivity which provides us with a secure way of transferring data back and forth between on-prem and cloud:

In this example, we’ll configure a Windows Server 2016 Core node with the Hybrid Worker Agent. Currently, as this article is being published, there are two ways to set this up, there is a PowerShell script that can be downloaded from the PowerShell gallery and ran, however, it is using the AzureRM cmdlets and running Connect-AzureRMAccount on server core produces the “Unable to load DLL ‘IEFRAME.dll'” error. So we go over how to add the Hybrid Worker Node on Server Core using the manual process. First, we will need to run the following command with the resource group and name of our log analytics workspace that we set up. This tells our workspace to push the worker components to the agent computer when we add it to the workspace in the next steps :
Set-AzureRmOperationalInsightsIntelligencePack -ResourceGroupName LukeLabAA-RG -WorkspaceName LukeLabAA-LA -IntelligencePackName "AzureAutomation" -Enabled $true
Next, we will download the agent from our workspace. Navigate to the Log Analytics Workspace and select Advanced Settings on the left-hand side. Select Connected Sources and since we are setting up a Windows node we will choose Windows Servers. Select Download Windows Agent (64 bit) and transfer it to the Hybrid Worker. Also, make note of the Workspace ID and Primary Key, these need to be used in order to configure the agent installation to point to the Azure environment: When we run the executable click next through the wizard. Select Connect the agent to Azure Log Analytics (OMS) and click Next: Paste in the Workspace ID and Primary Key that we saw from the previous step, choose Azure Commercial and click Next, then Install: Wait a few minutes for the agent to show in the workspace When the agent installs the Hybrid Registration PowerShell module gets copied down to the Hybrid Worker. So, on the Hybrid Worker node navigate to “C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\<version>\HybridRegistration” and import the module:
Import-Module .\HybridRegistration.psd1
Then run the following command. The URL and Token are obtained from the Azure Automation account. Select Keys on the left-hand side and the Primary Key will be the token and the URL will be displayed. Also include the Hybrid Worker Group name that you would like to use if the one specified doesn’t exist it will automatically get created:
Add-HybridRunbookWorker –GroupName LukeLabOnPrem -EndPoint "https://eus2-agentservice-prod-1.azure-automation.net/accounts/d3d71ed2-e761-4333-b333-fce7b97e3333" -Token "0B/RNjlieKGSk2QjXmsuGoQtSQW0QVb6vfjqIY2342KJOiYOmedVP/vY+vpP8sfwdomliECn/GTasWmViJg=="
Now when we go to our Automation Account and select Hybrid Worker Groups we can see our new hybrid worker under the LukeLabOnPrem group we specified:

How to Use an Azure Automation Runbook


  Let test out running a Runbook through our new Hybrid Worker. I have installed the VMware PowerCLI module onto the node. We will run a simple script that will connect to our ESXi host and display a list of all the VMs. First, let’s add in some credentials. This is one of the coolest features of Azure Automation. Go to the automation account and select Credentials on the left-hand side. Choose the Add a Credential option and input some credentials, in this example I’m inputting my credentials to my VMware environment so we can use them in our runbook: credentials Now, let’s create a Runbook. In the Automation Account select Runbooks on the left-hand side and choose Create a Runbook: Runbooks Fill out the required fields, I am going to create a runbook called VMwareVMs, there can’t be spaces in the name: How to Use an Azure Automation Runbook Another slick feature to point out, while we are creating our scripts in the runbook editor, we can select Assets on the left-hand side and choose our credentials that we saved and select Add to canvas. This will paste in the exact command that we need to retrieve those credentials: Now that I have my quick script to retrieve VM info, I’ll Save and Publish the runbook: When we go to Start the runbook, we have the option to have it run from our Hybrid Worker. I also selected the LukeLabOnPrem worker group: The runbook will kick off on-premise and retrieve the VM information from the Get-VM PowerCLI cmdlet proving that our runbook is executing and connecting to infrastructure on-premise:

Wrap-Up


  Managed Service Providers should definitely take advantage of the hybrid worker option with Azure Automation Runbooks. It can be a great tool to have in the back pocket for not only clients that have hybrid cloud solutions, but also MSP cloud solutions that require an on-premise presence into client environments. Instead of setting up scheduled tasks in native Windows Server where there is no centralized reporting or visibility on the status of a failed task, consider using Azure Runbooks with the power of Log Analytics alerting.

Thanks for reading!