Windows 7 support is ending, what are you doing about it?

January 14, 2020 is the last day of support for Windows 7 from Microsoft. It’s almost a year away, so why is that important? Well, upgrading a large environment of laptops and workstations isn’t exactly easy and as an MSP you’ll want to start thinking about your strategy in dealing with this change early.

Microsoft has your back

Windows 7

One of the first steps should be socializing this event with clients. Let them know about this deadline and its implications. In this case, Microsoft is helping you with creating awareness. KB4493132, a recent patch to Windows 7 release will create a notification window on Windows 7 machines letting them know about the end of support. These notices will start to appear mid-April, so be prepared for client questions about these pop-ups.

Help clients plan for change

It’s your responsibility as a technology partner to make sure the clients are aware of what this loss of support will mean. It means that Windows 7 will no longer receive security updates after January 14, 2020. This is a big deal for two reasons. On average 40% of deployed workstations are still running Windows 7. Given that security updates play a critical roll in protecting your client environments from cyber attacks, it’s important to have a plan to upgrade all Window 7 machines soon.


After you’ve created awareness about the need for this change you need to discuss budgeting with your clients. If you’re not doing budgeting as a part of your Technology Business Review (TBR) meetings, this is a great opportunity to start. Schedule meetings with your client to chat about their assets, how many Windows 7 machines they have, a high-level budget to replace the hardware, and a project to do the work. Clients often don’t have tens of thousands of dollars laying around for these types of events, unless you’ve been doing active budget planning with them already. This is why talking to them early about the need for this upgrade in the future is important. Work with them and allow them to budget for the coming project. They will appreciate your proactive involvement and you’ll appreciate their willingness to move forward with the project in a predictable and coordinated approach. The additional project revenue doesn’t hurt either right?

Hardware Scoping

The hardware and resource requirements are not dramatically different, for Windows 10, but you should consider all machines that are off warranty (older than 3-4 years), as ideal candidates for an upgrade. Do a hardware asset inventory, determine the warranty status of all the desktops and laptops.

If you haven’t felt the pinch already there is a CPU shortage in the industry right now, so be cautious as you are scoping hardware. Considering AMD CPUs or using pre-built SKUs from the distributor to ensure the units you quote/scope are going to be available.

Software Scoping

You may have clients that run a custom line of business (LOB) software package. This stuff is notorious for causing upgrade issues. In fact, you probably have a handful of XP machines still deployed at a couple of client sites for this same reason. ;)

As a part of the client planning take the opportunity to discuss these software packages, ensure they are supported on Windows 10 and look for modern replacements if it’s practical to do so.

Next Steps

  1. Collect a client asset inventory.

  2. Determine where there are high numbers of Windows 7 assets deployed.

  3. Call the business decision makers at those clients. Ask for 30 minutes of their time to discuss their IT hardware strategy.

  4. Follow up with an email suggesting 3 times to meet.

  5. Book the meeting and deliver a compelling proposal for them to approve budget for the upgrade project in next 6 months.

Get out there and get those upgrades moving!


MSP Documentation Systems

Love it or hate it, documentation is critical for effective IT support. Techs having access to documentation about the infrastructure they support will dramatically reduce the time it takes them to resolve issues. Documentation will also increase the quality of support by creating repeatable procedures.

Like many things in business and technology, there is a spectrum of maturity in how organizations approach documentation. On the low maturity end groups may just create a bunch of folders and documents on a file share or maybe they are sharing a Onenote page with loose notes. Here is a list of documentation systems that can help get your documentation from a messy garage full of unorganized junk to an F1 garage where you could eat off the floor and everything is in its place.

IT Glue

My favorite tool is IT Glue. If you run a managed service provider (MSP), IT Glue should be the frontrunner for your documentation platform. It is purpose built for MSPs with powerful features like built-in sync to your PSA and RMM tools, like Connectwise, Autotask, Labtech, and Kaseya.

IT Glue interface

IT Glue interface

Some of my other favorite features of IT Glue is that everything in the system can be linked together. When you open an asset like a Virtual Server, it will show you what Host the server sits on, what network switch that server is attached to, standard operating procedures (SOPs) related to those systems and passwords you may require when working on those systems. All of this information is at your fingertips, hyperlinked together. There are other subtle, but powerful features, like the completeness page. This page shows each client and the percentage of their documentation that is completed. This is useful when onboarding a new client and you can see how much of the documentation you have captured. Another key advantage of IT Glue is that you can share the documentation with the client online. You can also produce physical runbooks to print out, but only if you have the enterprise package.

There are dozens of other powerful features in IT Glue, if you’re not familiar check out their webinars for more details.

One of the key negatives about IT Glue that people note is its price. Also, IT Glue used to have a 5 seat minimum, but they recently changed this policy.

  • Price - $19/user/mth (Basic) to $39/user/mth (Enterprise)

  • Pros

    • Mature platform

    • API & Integration with PSA/RMM/etc.

    • Domain Tracking

    • Linked asset and documents

  • Cons

    • Limited customization

Recognizing that IT Glue may not be for everyone, here are some alternative platforms to review.


If you have more time than money, Confluence might be a useful alternative for you. The major plus of Confluence is that it’s dirt cheap for small teams. $10/mth for up to 10 users.

Confluence is a great wiki and it’s highly customizable, but it will take a serious investment of time to build the basic structure of your documentation platform.

Confluence Interface

Confluence Interface

Confluence has a large community so you can find templates and plugins that may help you replicate some of the more advanced features in other platforms, but it will take an investment of time and the additional plugins cost can quickly add up. One other warning, the SaaS version of confluence can be a bit slow, so I would suggest you get the self-hosted version after you’ve tested it out.

  • Price - Cheap!

    • Cloud

      • 10/mth for <10 users

      • $5/mth/user >10 users

    • Self-hosted

      • $10 one time <10 users

      • $60/user one time with scaling discount

  • Pros

    • Cost-effective

    • Highly customizable

  • Cons

    • No RMM/PSA Integration

    • Requires a lot of time to setup and customize

    • Cost goes up as you have to buy additional add-ons for features

IT Boost

IT Boost is a newer entrant to the market and shows promise as a mature solution. IT Boost seems to have a lot of feature parity to IT Glue and their dev cycles are very fast. It’s worth tracking their development and position in the market.

  • Price - $50/user/mth

  • Pros

    • Documentation + business dashboards + customer satisfaction surveys

    • PSA/RMM Integration

    • VOIP integration

  • Cons

    • Pricey

    • Fast dev. cycle comes with bugs.

IT Boost Ticket Portal?

IT Boost Ticket Portal?

Passportal docs

Passportal is a well established solution for managing passwords for MSPs. Recently they have been working on a documentation solution. It’s still early days of the development of the documentation platform, but it will be worth watching them to see what the solution develops into.

  • Pricing - $15 - 20

  • Pros

    • Combine Passportal Ocular functions with documentation

  • Cons

    • Younger in its dev cycle. Not as feature rich as others

SI Portal

The last noteable solution in the field SI Portal. Honestly, this one needs some work. The basic structure of the platform is similar to IT Glue, but consistent industry feedback says that it’s “unpolished.”  This is reinforced by the fact that when I browsed around on the demo portal it throws all kinds of errors and appears broken. It doesn’t exactly engender trust.

  • Pricing - $15/mth/user

  • Pros

    • Integration to PSA/RMM

    • Cheaper

  • Cons

    • Mixed market feedback

SI Portal Interface

SI Portal Interface

Honorable Mention

  • Stella - Syncs with Connectwise, like a pre-structured confluence.

  • Bizdox - Connectwise solution, which apparently has come back on the CW roadmap. Keep an eye out for future announcements.

  • Docuwiki - DIY, Open Source, Free.

Regardless of the direction, you go. Investing in a documentation platform is worth your time and money. Using a standard system will drive standardization and improve your team's results.

Just remember that documentation is a cultural process, you must be ready to drive the cultural change necessary to sustain a documentation culture. You will fail if you just buy the platform and expect people to use it. Training time, project work, and targets are required to get the team using the system in a way that will drive the results you hope to see.

How MSPs Achieve Great Service Level Agreements

If you are a mature Managed IT Service Provider (MSP) a Service Level Agreement (SLA) is a key metric to measure.

Why? An SLA commits your business to an acceptable level of service to your clients.

Few things drive a client crazier than submitting a ticket and having it disappear into a black hole. Non-responsive or ad hoc support are short roads to dissatisfied clients. Agreed upon SLAs helps frame expectations and communication helps manage these expectations.

Once you have SLAs in place you are also in a position to work towards consistently exceeding them in order to wow your clients with world class service!

Why are SLAs important to your customers?

An SLA is typically written into the contract, and in some cases, the contract may have a cost claw back.

In the IT service space, this is often not the case because of the general unpredictable and limited control that the service provider has in dealing with another company's infrastructure. Regardless, the SLA is a contractual obligation and repeated breach of this agreement is cause for termination of the agreement.

The importance of having an SLA is to have the client and provider agree on what the expected turnaround times for support should be.

Typically this is:

  • 8hrs for most support issues
  • 4hrs for urgent issues
  • 1hr for emergency issues

Once defined it is important that the SLAs are communicated to the primary client contacts as well as the users. This leveling of expectations can curb issues where someone submits a ticket and 1 hour later goes storming off to their boss's office when it hasn't been fixed yet.

Never make your customer wait!

As an IT provider, managed or not, you are a service organization first and a technology company second!

How long a person waits for service is a very tangible measure of the quality of service a person receives. Think of all the places that are notorious for poor services, the DMV, Call-Centers, food service. "We've waited 15 minutes and no one has come to the table." "I'm number 214. They are currently seeing number 167." "We are experiencing higher than normal call volumes." I have a question, when are they not experiencing higher than normal call volumes? The theme is the same, people hate waiting. People especially hate waiting when they have no feedback to manage their expectations.

Communication is critical to effectively managing expectations around SLAs. If you are a ConnectWise user, Brightgauge has a great visual guide on setting up SLAs, and provides a great monitor of SLA performance.

Always work to overachieve on your SLAs

World-class IT service companies achieve SLA >90% of the time.

Average SLA achievement is 75%.

Underperforming companies are around 50% and below.

With this as a reference, let's explore strategies to help you overachieve in the eyes of the client!

1. Manage the psychological contract

If a user is upset about how long something took to get fixed, NEVER dismiss their concern saying, "This was completed within the SLA." The SLA is only ever useful before a problem exists or in an after-action review.

Communication is the key to managing the psychological contract with the user. Acknowledging a support request with an auto-responder does little to dampen the client’s concern, it only acknowledges that an email or ticket submission was received. Auto-responders should not be used as a measure of response time.

Direct contact is a far better measure. It may look something like this, "Hi Jane, I understand from your ticket that you're having trouble opening an attachment. I've scheduled a tech to review your request and you should hear back from them in 2 hours." You've now acknowledged the issue and scheduled time for follow-up. This allows the user to expect when they will hear from someone.

The trick to this is maintaining that expectation and following through with the communication. Regular updates will buy you grace from the user, but not indefinitely. One of the best ways to manage this accountability to tickets is a dispatcher. Someone that can focus on juggling support requests, who those requests get delegated to and assisting with client communication.

2. Repeatable process

First call resolution is the best way to streamline your techs time and your clients time. The most powerful way to manage this is with well-structured documentation and standard operating procedures (SOPs).

Most of the issues that techs face are not some rare event that no one has ever seen before. In fact, most support issues are recurrences of a previous issue. Having a clean and easy to navigate documentation system like IT Glue™ drastically reduces the burden on techs of searching for the information.

SOPs act as a script for resolving typical issues or executing procedures. So rather than each tech re-inventing the wheel for each problem, a repository of information exists for them to reference. This is especially important in:

  • system builds (server/laptop/desktop)
  • application installation
  • user creation/decommission

These procedures get done a lot and have detailed requirements. Just allowing staff to wing it on each one will inevitably lead to error, which increases the time required through re-work or escalation. Missing details from a SOP can also create a poor perception with a client. "You guys have done this dozens of times. How come you get it wrong so often?"

Distill the knowledge from your team's experience into SOPs. This will reduce the time spent looking for a solution and therefore the resolve that issue.

3. Escalation path

A defined escalation process is important to ensure someone doesn't end up burning a bunch of time on an issue that might be out of their capability. Staff should know how long they should spend on an issue before asking for help or passing the issue up to the next support tier.

Great team members will often hold a high degree of personal accountability for the issues that they are given. They truly want to be able to solve the problem and help the client.

The dispatcher also plays a support role in keeping the team accountable to the escalation times and ensuring communication to the client. The service manager should be reviewing the tickets that miss the SLA and determine if there is an opportunity to update or create a SOP that would make that type of ticket easier in the future.

4. Low costs, high value

Some issues will require escalation, but a focused effort on reducing the number of escalations is important to drive up your “first call resolution” numbers. This strategy will facilitate hiring more entry-level (tier 1) technicians.

Here are the costs to demonstrate why this is important:

Tier 3s cost $75,000 - $80,000 a year. They tend to deal with complex issues and thus close fewer tickets in a day, say 5-8 tickets.

Tier 1s cost $35,000 - $40,000 a year. They should be closing 15-20 tickets a day.

Therefore: 2 x Tier 1 techs who cost no more than $80,000 = 40 Tickets per day!

This means the tier 1 approach is guaranteed to drive better results and help achieve your SLA goals.

Clean and logical documentation is critical to ensure the tier 1 technicians are being set up for success. It starts with team member onboarding. One of the reasons more seasoned technicians can resolve issues is that they know where to look. A good documentation system will ensure techs have a clear view of the client environment, assets, dependencies and other related information. There are a number of options available such as Dropbox, Google Drive, using your RMM or PSA, or IT Glue.

The on-ramp time for new people that have access to the collective knowledge of the team will also be dramatically higher. This is preferable to new folks having to rely on a steady drip of experience with each environment.

Finally, since the team knowledge is captured,  the tier 1s are more likely to be able to close issues on the first call. These quick closes mean SLAs are exceeded, clients are happy that they don’t have to wait and high-performance team members feel the success of blasting through issues while getting high-quality feedback scores on their work.

This post orginally appeared as a guest blog on the IT Glue website.

SaaS - How cloud application delivery is changing

This article originally appeared in the Annex Consulting Group Newsletter.

Cloud is becoming a familiar term in business. In recent years, the adoption of cloud services for business has accelerated at a breakneck pace. Instead of replacing physical servers at the end of their life, businesses are opting to move their computing needs to a cloud provider. This shift in approach carries the benefits of reduced risk, lower capital costs, and greater flexibility.


The next phase of cloud adoption is represented by the adoption of the software as a service model (SaaS). Traditional applications have to be installed on your computer making them difficult to deploy, support, upgrade, and access. The SaaS model puts those applications in a web browser and on your smartphone, making them accessible from anywhere, anytime, without complications. Email, finance, CRM, file sharing, project management, from simple to complex, these apps are being delivered over the web.

IT has a seat at the table

This whole evolution is changing the role of the IT group in a business. If there are fewer servers and applications to look after how does this affect the role of IT? In many cases, the result is a positive shift that elevates the role that IT plays in the business. With the wide range of applications and integrations available, businesses require more guidance in matching their needs with an integrated solution stack they can operate their business on.

Vendor management and performance management also play a much greater importance. Network reliability and stability become critical in this new model. Traditionally if there was an internet outage, browsing would be affected and email would stop flowing temporarily, but staff could still work. The risk in the SaaS model is amplified since so many more work functions are impacted by a network outage. This is why many organizations are looking at redundant internet providers for their office. One primary line as well as a backup in case there is an outage.

Business Continuity

In some organizations, their business continuity plan relies on the ubiquitous availability of the applications. If there was a flood or fire at the office location people would still be able to work from home using personal computers or work laptops. This availability also extends to facilitating remote work. In fact, large enterprise companies like IBM, Microsoft, Telus, and others are saving millions by having their workforce based at home, reducing the need for large office spaces. 

This enhanced partnership between the business and IT allows for greater opportunities for innovation, efficiency, and productivity. A business may start by moving email to a SaaS-based platform like Office 365, then adopt Salesforce or CRM online, then move finance to Dynamics online or Xero. With each success, productivity increases, support costs go down, and user satisfaction goes up. Pretty soon the business is reviewing all of the workflows in the organization and asking IT, “What about these parts? Can this be integrated, templated, and optimized?”

Digital Transformation

Businesses are increasingly becoming more digital and not just tech companies. Data is often the lifeblood of any organization, regardless of the work being done. The SaaS model of application delivery is changing the way organizations see, understand and work with that data. Future organizational success will likely be determined by how progressive the business relationship is with IT. 

Happy and Grim Anniversary


If you've been in IT for more than 16 years you may remember a little worm called "ILOVEYOU." That event was 16 years ago today.

I vividly remember running from office to office on our floor violently unplugging machines from the network ports on the wall. As I heard more people call out "What the hell?!" I changed approach and rushed into the server room and unplugged the core switch.

This worm was nasty. One of the worst impacts before Stuxnet. In fact, "ILOVEYOU" was credited with $5.5 Billion in losses. For anyone who never saw this and are curious you can watch a video of a guy replicating the attack here on YouTube.

The worm mailed itself to everyone in your contact list with a title of "ILOVEYOU." When people opened the email it replicated itself again like wildfire. With shocking speed, mail servers were overwhelmed and people's inboxes around the world were flooded with these messages. It was quickly modified to attack certain file types and overwrite data in order to replicate itself.

IT departments were being crushed trying clean and protect against the tidal wave of malware flooding their desktops, servers and email systems. In some cases companies were kept offline until certain countermeasures were put in place.

What we learned

The silver lining to this story is that it was one of the early events that demonstrated to businesses how serious cyber security was. We humans are often great at ignoring the risk around things that we can't see, touch, or otherwise visualize. On occasion, we need these events that shock us from our norms and ensure that we understand the impact of our assumptions and standards.


Today is also a great anniversary in geek history. May the 4th celebrates "May the 4th be with you" An annual day to celebrate our love for the star wars universe.




The Panama Papers - How were they hacked?

The Panama Papers. The largest data leak in history. How did such a massive breach occur on a law firm dealing with high profile politicians, celebrities, and sports stars? Was it a sophisticated attack? Did it require months of planning and a super smart secretive hacker team? The truth is a shocking negligence to manage IT basics. In most cyber-security breaches, the attack vector is actually a known vulnerability. In the case of Mossack Fonseca, the firm where the data was pulled from, a hacker would have had a wide range of vulnerabilities to choose from. As noted in this wired article, their exchange server hadn't been patched since 2009, their corporate portal was very poorly configured and was also not being securely maintained. Mossack Fonseca has confirmed that this attack, was not an inside job and that the likely attack vector was through the poorly maintained Exchange server. Their corporate portal hadn't been updated in months and the configuration allowed you to browse the backend folders if you guessed a folder name. Small and mid-size businesses often do not give sufficient thought to what would happen in the event of a security breach on their infrastructure. In some cases they do not believe they are at risk as a target, others simply do not understand the level of risk that is presented. It's shocking that the law firm at the center of the Panama papers was not more aware of the risk being presented by their lack of due-diligence in managing their IT infrastructure. A law firm deals with a laundry list of private information and not taking effective action to defend that information is inexcusable. Businesses that are mindful of their security risk, often think too big about their needs. As demonstrated by the Panama papers, the risk is often much more elemental than people think. Having sophisticated intrusion detection, advanced digital rights management, and encryption doesn't address a simple issue like patching your systems regularly. It's like installing laser trip wires and steel reinforced doors on your house, but leaving the garage door open. Fancy measures won't protect you when you ignore the basics. 


Technical Debt Creating Risk?

At a recent meetup for Tech Vancouver, a speaker was presenting on the idea of technical debt. Technical debt is the act of sacrificing quality for speed or convenience.  For coders, this means that certain parts of the code are not as clean or stable as they should be. Hence, you are indebted to that shortcut with both risk and the commitment to revisit it later. The implications for this practice and risks will become more severe in the future.
Agility Problem?
Agile methodology is a progressive form of code development and tends to support these practices as well. Agile development helps to break down the work into more manageable chunks. The issue is that these chunks are intended to be iterative. There is no assumption that the work product would be 100% on the first or even the second pass. The software will have numerous iterations before it is even close to considered complete. This removes the burden of perfection and time issues on the delivery of a viable product but also increases the risk for errors. Agile is not a bad practice it is very common. However, it does require more strict quality control.
Patch, Patch, Patch
With the connected world, patching is a given. In the early days before the wide reach of the internet, you couldn't ship a piece of software that was faulty. There were no effective means of patching that software if there was an issue with the quality or reliability of the code. A poorly released product could mean a failed product or even a failed company as a result. This is still a risk, but the bar to what is acceptable in a release seems to be much lower than before.
Forever Beta
Beta release of a product used to be done with a select group of customers to ensure bugs were caught before the release and also that the features worked in the way that suited the users. Presently the role of a beta release seems to have expanded. Beta releases act as a wide release to capture many of the issues that should arguably be fettered out in quality control. There is an old ideology in IT that you never adopt version one of a product. Let others test it out, let the software company fix the major bugs in an x.1 release, then you can adopt the release. Some software seems to be in a perpetual state of beta where nothing is ever complete. If there are no patches being released, there are new features, that will then need to be patched. In some cases, this reality is driven from the marketing department. Delivery dates for a product or a release are set well in advance. All efforts are made to hit that date even if it means in some cases that an inferior product is the result. After all, we can just patch it right? 
Risks exposed
One of the arguments for open source development is that you can't hide bad code. Everyone can read, review, comment, and correct issues. The argument is that the risks are lower since the code has already been vetted. Therefore, the code should be fewer errors and vulnerabilities. In private sector development, the idea of public code is not practical. So how will this problem be managed in the future? With the rise of cybercrime, the need for lower risk software is rising. In a recent interview with Lachlan Turner of Arcinfosec, we talked about the growing risk of cyber terrorism. Losing your data to encryption is a serious problem for a business, but losing control of pressure in a gas pipeline could be catastrophic. We may see more legislation to ensure some standards are in place with code. For example, standards guide for code implementation when dealing with high-value assets. No one should assume that these controls would eliminate risk, but certain standards for software are a likely progression from manufacturing practices that ensure our physical products do no harm. The future is a connected world where everything is hackable. The exposure of physical risk will become a more prevalent issue as software plays a more visible role in our physical worlds, beyond the digital world.