Skip to content

[Feature Request] Native third-party software auto-patching #161

@Raphaelben976

Description

@Raphaelben976

Issue 1 — Third-party software auto-patching

Is your feature request related to a problem? Please describe.
As an MSP, keeping third-party applications (browsers, PDF readers, runtimes, productivity tools, etc.) up to date across hundreds of endpoints is a major security and compliance burden. Without a centralized patching mechanism inside the RMM, we have to rely on scripts, manual deployments, or external tools, which is time-consuming and error-prone.

Describe the solution you'd like
A native third-party patch management module inside NetLock RMM, with:

  • A curated catalog of common applications (Chrome, Firefox, Edge, Adobe Reader, 7-Zip, Java, .NET, VLC, Notepad++, etc.)
  • Per-client / per-group policies (auto-update, approval-based, exclusion lists)
  • Scheduling, maintenance windows, and reboot handling
  • Reporting on installed versions, pending updates, and patch compliance status

Describe alternatives you've considered

  • Custom PowerShell scripts pushed via the RMM (works but requires significant maintenance)
  • Third-party tools like PatchMyPC or Chocolatey (additional cost and integration overhead)
  • Datto RMM's built-in software management feature, which is exactly what we'd like to see in NetLock

Additional context
This is currently one of the main features keeping us on Datto RMM. Having it natively in NetLock would be a strong driver for migration.


Issue 2 — Peer caching for Windows updates

Is your feature request related to a problem? Please describe.
On client sites with multiple endpoints and limited or shared internet bandwidth, every workstation downloading the same Windows updates independently saturates the connection and disrupts users. This is especially critical for clients in regions with constrained connectivity (in our case, Mayotte / Indian Ocean).

Describe the solution you'd like
A peer caching / delivery optimization feature where the NetLock agent can:

  • Detect updates already downloaded by another agent on the same LAN
  • Share update payloads peer-to-peer between endpoints instead of each one fetching from the internet
  • Be configurable per client/site (enable/disable, bandwidth caps, cache size)
  • Fall back gracefully to internet download if no peer source is available

This could leverage Windows Delivery Optimization, BranchCache, or a NetLock-native mechanism.

Describe alternatives you've considered

  • Manually configuring Windows Delivery Optimization or WSUS at each client site (heavy and not scalable for an MSP)
  • Bandwidth throttling at the firewall (mitigates but doesn't solve the duplication problem)

Additional context
This is a real day-to-day pain point and would significantly improve the agent's footprint on client networks.


Issue 3 — Expanded catalog of monitoring sensors

Is your feature request related to a problem? Please describe.
The current set of native monitoring sensors is limited, which forces us to write and maintain custom scripts to cover common monitoring needs. This adds maintenance overhead and slows down our reaction time on incidents.

Describe the solution you'd like
A broader, out-of-the-box catalog of monitoring sensors, including:

  • Hardware (SMART status, RAID, temperatures, battery health)
  • Services and processes (specific Windows services, process running/CPU/RAM thresholds)
  • Performance (CPU, RAM, disk I/O, queue length, network throughput) with configurable thresholds
  • Windows event log monitoring with filters (source, ID, severity, keyword)
  • Backup status (Veeam, Windows Server Backup, Datto, etc.)
  • Certificate expiry monitoring (local store, IIS bindings)
  • Scheduled tasks status
  • Active Directory health basics (replication, FSMO, SYSVOL)

Describe alternatives you've considered

  • Writing custom scripts for each sensor (works but maintenance-heavy and inconsistent across techs)
  • Using a separate monitoring tool alongside the RMM (adds cost and breaks the single-pane-of-glass approach)

Additional context
The wider the native sensor coverage, the more value the RMM provides out of the box. This is one of the areas where NetLock could clearly differentiate itself.


Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions