This is the story of trying to get one Windows laptop talking SNMP so it could join the rest of the homelab in LibreNMS and how a five-minute task turned into a multi-hour forensic investigation spanning the Windows registry, the Component-Based Servicing engine and eventually a fact about remote sessions that nobody warns you about.

The setup

The plan was simple. Every other device on the network already reports into LibreNMS: pfSense, the Proxmox host, the managed switches, a small fleet of LXC guests, even the MacBook. This laptop was next on the list. Install the SNMP.Client Windows Capability, set a community string, done.

Add-WindowsCapability -Online -Name 'SNMP.Client~~~~0.0.1.0'

Add-WindowsCapability : Access is denied.

No further explanation. No hint. Just the Windows equivalent of a shrug.

Act one: assume it’s permissions

Access denied usually means exactly what it says, so the obvious first move was checking the registry ACLs around the Component-Based Servicing hives. This is where things got interesting. COMPONENTS, one of the hives CBS uses during servicing, was missing NT SERVICE\TrustedInstaller permissions entirely. Not reduced, not restricted. Just gone.

That is a genuinely alarming thing to find on a system you use every day. The working theory, based on timeline and known behaviour, points at a “PC cleaner” tool that had been running on this machine years ago and has since been removed. These tools have a bad habit of “optimising” registry permissions in ways that make sense to nobody, least of all Windows itself.

Fixing one hive felt like progress. Then the same pattern turned up on SOFTWARE. Then SYSTEM. Then HKEY_USERS\.DEFAULT. Then, for good measure, the user’s own NTUSER.DAT. Six hives in total, all quietly missing the one permission Windows Update depends on to do its job.

Each fix was verified properly this time, not just trusted on faith. Real ACL checks, before and after, on real subkeys. Genuinely fixed, every time.

The install still failed with the exact same error.

Act two: rule everything else out

At this point the obvious question was whether this was a registry problem at all, or something else entirely wearing a registry-shaped costume. A run through the usual suspects:

• General CBS corruption? No. Enable-WindowsOptionalFeature -FeatureName TelnetClient worked instantly. Optional Features and Capabilities are different subsystems under the hood and only one of them was broken.
• Network or source access? No. Forcing the install to use a local source only (-LimitAccess) produced a different error entirely, “source files not found”, proving the normal attempt was successfully reaching and downloading from Windows Update. The failure was happening after the download, not before it.
• Explicit deny rules somewhere in the ACL chain? None found.
• Corrupted CBS staging folders? Checked several. All fine.
• Process Monitor, to watch the exact failing operation live? Captured cleanly over a remote session. Exporting the results, however, got stuck at zero CPU indefinitely, an early sign of a pattern that would repeat.
• Windows Update Agent COM registration? Re-registered every relevant DLL. No change.

Each of these took real time to test properly and each one came back clean, which was somehow more frustrating than if any of them had been the answer.

Act three: the culprit

The breakthrough came from reading the CBS log with fresh eyes instead of grepping for the same error message again. Buried a few lines before the familiar access denied was this:

Failed to set interactive flag for search [HRESULT = 0x80070005 - E_ACCESSDENIED]
Failed to do Windows update search [HRESULT = 0x80070005 - E_ACCESSDENIED]

Add-WindowsCapability doesn’t just talk to a local package store. It calls into the Windows Update client and part of that call requires an interactive desktop session, a real window station with a real logged-in user sitting at it. A remote session, no matter how privileged, doesn’t have one. It never did.

This machine had already surfaced this exact limitation earlier in the session with GUI tools that silently refuse to do anything useful remotely. It turns out Windows Capability installation belongs to that same family of “secretly needs a desktop” operations. It just expresses the requirement as a generic access denied error instead of, say, telling you.

Turns out this is a known, if obscure, Windows quirk rather than something unique to this machine. It shows up under a few different names, “second hop problem”, “WinRM session limitation”, “requires interactive logon”, scattered across Microsoft’s own Q&A forums and the odd GitLab issue tracker, always with the identical symptom: works fine from a local or RDP session, fails every time over a remote one.

The fix, once you know it

$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-File C:\install-snmp.ps1'
$principal = New-ScheduledTaskPrincipal -UserId '<username>' -LogonType Interactive -RunLevel Highest
Register-ScheduledTask -TaskName SnmpInstallJob -Action $action -Principal $principal -Force
Start-ScheduledTask -TaskName SnmpInstallJob

Route the same command through a scheduled task configured to log on interactively and it works first try. Not “works better.” Works. The download that had failed instantly for hours now proceeded normally, slowly churned through Windows’ component-store bookkeeping (this machine has years of accumulated Feature-on-Demand cruft, so “slowly” meant a genuine ten minutes) and finished clean.

The companion capability, WMI-SNMP-Provider.Client, had one more trick left. It installed, but sat at Staged instead of Installed, even after a full reboot. The instinct was to reboot again. The actual fix was simpler: just run the same interactive install command a second time. No reboot needed, no further mystery, just Windows apparently wanting to be asked twice.

The reckoning

Six genuinely broken registry hives, found and properly fixed. Every documented failure mode for Add-WindowsCapability ruled out one at a time. A restart deployed as a diagnostic tool that, in fairness, didn’t actually fix anything but felt necessary anyway. And the real answer, the whole time, was that the command wanted to see an actual desktop before it would talk to Windows Update.

The registry fixes were not wasted effort. They were real defects and leaving TrustedInstaller locked out of half the registry is not a great place to leave a machine regardless of whether it explains this particular bug. But they weren’t the fix either. The fix was one flag on a scheduled task.

The laptop now reports happily into LibreNMS alongside everything else on the network. Total time from “this should take five minutes” to a green checkmark: measured in hours, not minutes and almost entirely spent ruling out things that turned out to be correct all along.

Signal, not noise.