Windows Client 1.6.2.4 – Volumes and BitLocker Plugin fixes, Cisco MAC addresses, and more

Rolling out to all subscribers starting Tuesday, May 5, 2026 (1400 UTC / 9:00 AM Central)

Auto-update connectivity fix

Earlier this year our load balancer infrastructure dropped support for TLS 1.0 and 1.1 in line with current security standards. The Monitoring Client’s auto-updater (a third-party component compiled against .NET 4.0) defaulted to those older protocols and could no longer download update manifests on systems without certain Windows registry hardening applied. 1.6.2.4 ships an update.exe.config and self-healing logic in the agent so the updater always negotiates TLS 1.2. After this release lands, future updates will go through cleanly even if your endpoints don’t have SchUseStrongCrypto set in the registry.

Improved network adapter detection

The MAC blocklist used by the agent to identify physical vs. virtual/ephemeral adapters has been expanded to include:

• Cisco AnyConnect VPN virtual adapters
• Cisco Network Software virtual adapters

If you’ve seen flaky beacon/IP-address reports on machines that frequently connect through Cisco VPN, those should stabilize.

Volumes and BitLocker plugin crash fix

Both plugins read the system’s drive list from a registry JSON blob. When that JSON ended up malformed on certain endpoints (rare but reproducible after some Windows feature updates), the plugins would crash and produce no output. The plugins now fall back gracefully when the JSON can’t be parsed, so you’ll continue to get drive-level monitoring even on systems with the corrupted registry state.

Code signing migration

Starting with 1.6.2.4, all Monitoring Client binaries are signed with our SSL.com EV Code Signing certificate issued to Sacramento Labs LLC. Previous releases used a different certificate that’s now retired. The old certificate was an OV Code Signing certificate, and upgrading to “EV” instead of “OV” should better prevent UAC prompts and false-positives from AV scans. 

⚠️ System requirements change: .NET Framework 4.8

This is the most important compatibility note. Starting with 1.6.2.4, the Monitoring Client targets .NET Framework 4.8 instead of .NET 4.0. This brings access to newer cryptography, performance, and platform APIs — but it means the agent now requires .NET 4.8 to be installed on the endpoint.

For most of your fleet, this is already the case:

• Windows 10 version 1903 (May 2019 update) and later — .NET 4.8 is included
• Windows 11 — .NET 4.8 is included
• Windows Server 2019 / 2022 — .NET 4.8 is included or available via Windows Update

You may need to manually install .NET 4.8 on:

• Windows 7 SP1 and Windows 8.1 — supported but require a manual install of .NET 4.8 from Microsoft
• Windows 10 versions older than 1903 — should be on Windows Update by now
• Windows Server 2012 / 2012 R2 — same situation as Win7/8.1

The .NET 4.8 redistributable is available at https://dotnet.microsoft.com/download/dotnet-framework/net48. If an endpoint is missing the prerequisite, the auto-update will not apply and the agent will continue to run on its current version until .NET 4.8 is installed.

If you’re unsure which endpoints in your fleet need attention, a quick check is the Operating System plugin’s reported OS version against the list above. We’re not currently auto-flagging missing-prerequisite endpoints in the dashboard, but that’s on our radar as a follow-up.

Just the beginning

This was the first Windows Agent update we’ve completed since Sacramento Labs acquired Watchman Monitoring from Syncro. Now that we’ve completed one update, we’re going to be releasing far more updates to the Windows agent. You’ll see plugin fixes and improvements, as well as new plugins. If you have any requests, please let us know!