Microsoft/Third Patching with Reports

Feature Requests
1

It would be great if there was a TAB dedicated for the Microsoft Windows/Third party Patching.

Providing records on patching status such as successful/unsuccessful patching, previous issues where manual input was required (previous tickets/historical), some commands to auto-heal the patching, and critical/unsupported windows builds

Failing the auto attempts of resolving the patch status, it auto generates a ticket for the ‘team’ who is responsible to resolve the issues.

This would result with automation, less tech time initially spent on the basic repairs/fixes.

2

Totally agree. We’re working on a feature right now that allows our Windows Update/Dell Command/HP Image Assistant/Lenovo System Update tasks to create individual actions for each update they find.

Actions already have a MaintenanceType column which is an enum containing the following:

public enum MaintenanceType
{
  GlobalSoftware = 0,
  LocalSoftware = 1,
  WindowsUpdate = 2,
  ChocolateySoftware = 3,
  NiniteSoftware = 4,
  LocalMaintenanceTask = 5,
  GlobalMaintenanceTask = 6,
  AgentUpdate = 7,
}

Currently WindowsUpdate is only used when you have ConnectWise Automate integration and you create a schedule and check the “Apply Approved Windows Updates Through Supported Providers” box.

To best leverage this, I propose the following:

  1. Before we release the ability to create child actions, ensure that you can specify that an action is a Windows Update and require an ID to prevent our Automate logic from attempting to run the same update later in the session.
  2. Group these Windows Update actions into the proposed “OS Patches” tab on the computer screen
  3. Make it easy to create a Dashboard with OS Patches

I’m concerned, however, that this proposal won’t fully satisfy @Josh_Buckley or the problem at large.

Let’s say @Josh_Buckley has a meeting with Client X next week.
He needs a report that says

  • 93 of your 100 machines are fine.
  • We need to replace Pam, Sue, John, Bob, and Matthew’s machines because they were purchased in 2016 and lack a TPM which is required for Windows 11.
  • David the engineer has a full hard drive preventing Windows updates
  • Bill the sales guy is forever on airplanes and never leaves his machine on at the hotel room so we need management to have a conversation with him about not “forgetting” to do this.

Let’s work backwards from here. If we start from a patch level approach, we introduce a lot of noise. What we need to step back and consider is that almost all RMM patching mechanisms you see today were developer BEFORE Microsoft started releasing Cumulative updates. If a client asks me if their machines are patched, I simply show them how many have the latest cumulative. The only reason I ever manually approve individual patches are to push high CVSS remediations. There is the occasional patch from Microsoft that we try to block but it’s rare that I’ve had to take action.

Anyway, I know that’s a largely incoherent block of text, but the direction I’d like to go with this is what changes would need to be made with the existing dashboard to provide a report like I described, and do those changes actually necessitate Immy having a first party understanding of what a patch is?

1 Like
3

Sorry for late reply.

I understand your response and comments.

I appreciate, that you’ve taken time out to respond with detail.

I would personally would like a technicial team member to have access to approve the upgrade/update feature for software and a pue chart which could pick up out of date software to bring it to a technician/manager/CSM for reporting side of things as everything so far whxih you and your team have accomplished is extremely clear and forward which is fantastic and something i appreciate.

I would love to hear more about what you have in the pipeline/planned for this :slight_smile:

1 Like