nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

2026.1.1 Update & SNMP Hardware Health Sensors - RESOLVED

k1gaudineer

Greeting SolarWinds Community

We are investigating what appears to be a SolarWinds Platform 2026.1.1 issue involving Hardware Health polling on Additional Polling Engines (APEs), and I wanted to reach out to the community to see if others are experiencing similar behavior.

Environment:

Large distributed Orion / SolarWinds Observability Self-Hosted deployment
(32) Additional Polling Engines (APEs)
SNMP-based network monitoring
Hardware Health monitoring enabled
Issue observed after upgrade to 2026.1.1

What we are seeing:

Standard SNMP polling continues to work normally from APEs

Node status polling updates
Interface polling updates
Other SNMP statistics continue updating normally

Hardware Health SNMP polling does NOT update from APEs

We verified this with the following SWQL Query

SELECT 

    N.Caption,

    N.NodeID,

    N.EngineID AS [Poller],

    N.MachineType,


    COUNT(HWH.NodeID) AS [Total Sensors],


    SUM(CASE WHEN HWH.Status = 0 THEN 1 ELSE 0 END) 

        AS [Unknown Sensors],


    ToLocal(MIN(HWH.LastPollTime)) 

        AS [First/Only Last Poll Time],


    ToLocal(MAX(HWH.LastPollTime)) 

        AS [Last Poll Time],


    MIN(HWH.LastPollStatus) 

        AS [Min Last Poll Status],


    MAX(HWH.LastPollStatus) 

        AS [Max Last Poll Status],


    MIN(HWH.LastPollMessage) 

        AS [Poll Message]


FROM Orion.Nodes N


LEFT JOIN Orion.HardwareHealth.HardwareInfo HWH

    ON N.NodeID = HWH.NodeID




GROUP BY 

    N.Caption,

    N.NodeID,

    N.MachineType,

    [Poller]


ORDER BY 

    [Poller] ASC,

    N.Caption ASC,

    [Unknown Sensors] DESC,

    [Last Poll Time] ASC

The resulting dataset:

Hardware Health timestamps remain stale
Sensor values such as fan RPM never change
Poll results appear frozen at previous values

Rediscovery does NOT actually repair the issue
Initially it appeared that rediscovery repaired Hardware Health polling, however further testing showed this was a false positive.

What SolarWinds appears to be doing is reusing or copying the last successful Hardware Health polling values into the current display. This creates the illusion that polling succeeded, but:

timestamps do not advance
live sensor values do not change
Hardware Health polling is not actually occurring

Hardware Health polling ONLY works correctly from the Primary Polling Engine
If the exact same node is moved from an APE to the Primary Polling Engine:

Hardware Health timestamps immediately begin updating
live values such as fan RPM begin changing normally
Hardware Health polling resumes functioning correctly

Moving nodes between APEs does NOT change behavior
The issue is not tied to one specific APE.
Moving nodes:

APE → APE = no change
APE → Primary Poller = Hardware Health begins working

Port 17734 / gRPC investigation
We also investigated the newer 2026.x gRPC Feature Service communication changes involving TCP 17734.
In our environment:

all required firewall ports are open
TCP 17734 responds correctly on the Primary Poller
APEs are not listening on 17734, which is expected behavior by design

At this point we do not believe this is a firewall or basic SNMP connectivity issue.

Current conclusion:
The evidence currently points toward a problem specifically affecting Hardware Health SNMP polling execution or result processing on Additional Polling Engines after upgrading to 2026.1.1.

Has anyone else seen:

Hardware Health polling stop updating on APEs?
stale Hardware Health timestamps?
frozen fan/power/temperature sensor values?
Hardware Health only functioning from the Primary Polling Engine?

If so:

Did anyone identify a root cause?
Did rebuilding the polling engine or reassigning pollers help?
Is this affecting only Hardware Health or other poller types as well?

We do have an active support ticket with SolarWinds support but I was curious if anyone else has been experiencing the same issues.

Any feedback from other large distributed environments would be greatly appreciated.

Find more posts tagged with

snmpv2

network_monitoring

orion

npm

Comments

vinay.by

Hi @k1gaudineer ,

Maybe something is really broken post upgrade.

Can you do one test for me please, do a list resource of one of the devices on your additional poller, remove the hardware sensors at first, leave it for a few polls and readd the hardware sensors again, let me know how this goes.

I am still not on 2026.1.1 hence cant replicate this issue.

k1gaudineer

Yes.. We did perform that test. the procedure we used was

List Resources → Remove Hardware Health polling (Remove Check Mark) →submit
Once back at the 'Node Details' page manually 'Rediscover' the node
Manually poll the node (Poll Now) 5 or more times
Wait 10 minutes
List Resources → Select 'Hardware Health Polling' (Checkmark the box)
Once back at the 'Node Details' page manually 'Rediscover' the node
Manually poll the node (Poll Now) 5 or more times
Wait 10 minutes
Manually poll the node the node again (check the results)
Manually refresh the entire web page (F5 refresh) Check the results

The above procedure was used while the node was actively being polled on its original APE (additional polling engine) and we performed that same routine after moving the same node to a different APE. In both cases Hardware Health did not return. In fact when running the query to check for successful polling timestamps the values in SolarWinds.DB were now shown as NULL since I removed the checkmark. However when the node was moved from an APE to the Primary Polling Engine, 'Rediscovered', and manually polled 5 times Hardware Health displayed as expected. We left that node on the primary poller for a couple of hours and monitored the timestamps for successful polling with the SWQL query. The time stamps were current with the polling frequency. Lastly when the same node was moved from the Primary Polling engine to any other APE Hardware Health polling stopped. We verified that by running the SWQL query and verifying the time stamps for last completed polls were not current.

chad.every

@k1gaudineer , I'm not aware of any known issues with HWH on the version you're running. Can you let me know your current support case (in a reply or DM). I'd like to follow it internally.

k1gaudineer

Chad

Good afternoon. Thank you for the reply my current case number with SolarWinds is 02126774.

k1gaudineer

Good Morning Chad,

We did hear back from SolarWinds support. A troubleshooting step they asked us to take was to repair the Collector Service and the Job Engine. following the 2024.1 and above steps outlined in this KB article Repair a failing Job Engine and Collector Components . We followed those steps for on one of the APE's (EngineID 27) yesterday evening Monday 5-11-2026. What I find interesting today, several hours after working through the KB, is that the C:\ProgramData\Solarwinds\Collector\Data\PollingController.db and PollingController.db-journal files have not grown in size. Both files still show a 0 kb for size. I even viewed a node on that APE manually 'Rediscovered' it and then manually polled it (Poll Now) several times. Waited 15 minutes and checked the file sizes again the file size still shows 0 kb. Is this expected behavior?

k1gaudineer

This is a Bug…..

After several days of investigation, we have confirmed this is a legitimate SolarWinds bug referenced internally as Jira OO-51486.

The issue appears related to the removal of the Web folder from Additional Polling Engines (APEs), which breaks Hardware Health polling functionality on APEs and potentially other functionality utilizing the RootResourceManagerRegistrar class.

SolarWinds previously believed this issue was resolved in 2026.1.

Our environment was upgraded from:

SolarWinds Observability Enterprise Self Hosted 2025.4.3
to:
SolarWinds Observability Enterprise Self Hosted 2026.1.1

Environment:

Large distributed deployment
32 Additional Polling Engines
~4,000 servers
Several thousand network devices
~10,000 application monitors
Long-time SolarWinds customer (20+ years)

Network Device Symptoms

What makes this such a serious bug is that SolarWinds continues displaying Hardware Health elements as UP even when Hardware Health polling has not successfully completed in days or weeks.

What Orion appears to be doing is reusing the last known successful Hardware Health polling results and displaying them as current values in the web console.

This creates a very dangerous operational condition because:

the web console continues showing Green / Healthy status
stale values appear valid
alerts never trigger
failed environmental conditions go undetected

What initially led us down this path was an outage involving an edge data closet where cooling failed.

Prior to 2026.1.1:

we monitored switch temperatures
fan RPM
environmental conditions
and could receive early warning alerts when cooling performance degraded

Normally we would see:

fan RPM increase
temperatures slowly rise
early warning alerts trigger before equipment failure occurred

After upgrading to 2026.1.1 this behavior stopped functioning correctly.

In this particular incident:

no early warning alerts occurred
the web console continued showing Hardware Health as Green
we were unaware of the environmental issue until we received Critical alerts that all network devices in the closet were down

The root cause of the outage was overheating equipment.

However, when we reviewed the Hardware Health history:

fan RPM values remained constant for days
temperature values remained constant for days
Hardware Health timestamps had not updated
yet the web console continued displaying everything as healthy

At first I believed this was an isolated issue.

I deleted and re-added the affected node.

When I rediscovered and imported the node:

all normal SNMP polling worked correctly
Interface polling worked
VLAN polling worked
multicast/topology polling worked
but Hardware Health remained Unknown

Even after repeated manual polls:

Hardware Health polling never updated on the APE
timestamps remained stale
values never changed

This same behavior occurred with:

newly added switches
newly added routers
existing monitored devices

After running the SWQL query posted earlier in this thread, we discovered:

Hardware Health polling across the environment stopped immediately after upgrading to 2026.1.1

Application Monitor Symptoms

We are also seeing similar behavior with Application Monitors.

The applications typically:

remain Green
then suddenly transition to Unknown when a failure occurs

Because many environments (including ours) do not alert on Unknown status:

application alerts never trigger correctly

Additionally:

recreating the application monitor does not resolve the issue
newly created monitors often remain Unknown permanently

Workaround

We discovered that moving nodes and applications to the Primary Polling Engine restores proper functionality.

When moved to the Primary Poller:

Hardware Health polling immediately resumes
timestamps update correctly
live values change normally
Application Monitors begin functioning again

However, moving the workload back to an APE causes the issue to return.

Unfortunately this is not a realistic long-term solution for large environments.

Our deployment uses 32 APEs specifically to distribute polling load, and the Primary Poller cannot absorb all network and application polling responsibilities.

Still Curious About One Thing

As a long-time SolarWinds customer, I am curious whether:

other long-standing enterprise deployments experienced this issue after upgrading
vs.
newer clean installations of 2026.1.1

I suspect this may primarily affect:

large distributed deployments
environments utilizing many APEs
upgraded environments rather than fresh installs

Single-poller environments may never encounter this issue.

I would be very interested in hearing:

whether others experienced this behavior
whether SolarWinds provided a hotfix
whether anyone identified additional affected polling components
whether 2026.2 addresses this issue internally even though it is not currently called out in the release notes

muhammad.osama

What I Suspect Internally

Most likely one of these:

Hardware Health polling queues not initializing on APEs
Feature Service registration failure
Broken post-upgrade poller subscriptions
gRPC feature synchronization issue
Job Engine serialization issue for HardwareHealth entities

The “stale copied values” symptom is the biggest clue:

Orion is displaying cached DB values while no fresh polling is occurring.

That usually means:

polling execution pipeline broke,
not SNMP connectivity itself.

Strong Recommendation

Open escalation with SolarWinds and specifically request:

escalation to Orion Core Engineering,
known defects for:
- 2026.1.1
- HardwareHealth
- APE polling
- Feature Service / gRPC.

Also ask them for:

hotfixes,
private builds,
or known defects not yet public.

k1gaudineer

Hardware Health Polling Not Completing – Resolved

Our issue with Hardware Health polling not completing has been resolved. I want to give a shout out to the SolarWinds Support, Development, and Engineering teams for their excellent effort, time, and collaboration throughout this troubleshooting process.

Root Cause:

With the release of 2026.1, the following folder was removed from all Additional Polling Engines (APEs):

C:\Program Files\SolarWinds\Orion\web

As mentioned previously in this discussion, we are long-time SolarWinds customers and over the years SolarWinds has occasionally provided us with "Buddy Drops" to help resolve issues encountered in the past. These Buddy Drops sometimes required replacing existing .dll files. Our standard practice was to rename the original file to .old or .bak before placing the updated .dll into the folder.

This ultimately turned out to be the root cause of our issue.

During the 2026.1.1 upgrade, the installer expected to remove the:

C:\Program Files\SolarWinds\Orion\web

folder from the APEs. However, if unexpected .old or .bak files existed in that folder, the removal process would fail and the folder would remain behind.

As a result, when the APE attempted to perform Hardware Health polling, the polling process would still attempt to reference specific .dll files within the leftover web folder. If the folder did not exist, polling would continue normally. However, in our case the folder still existed but only contained old backup files, so the polling agent could not locate the required files and the polling process would terminate with an error before Hardware Health polling could complete successfully.

Resolution:

To resolve the issue we:

manually removed the leftover:
C:\Program Files\SolarWinds\Orion\web
folder from the APEs
stopped the SolarWinds Collector Service
restarted the SolarWinds Collector Service

Within just a few minutes Hardware Health polling returned to normal operation.

This resolved:

all Network Hardware Health polling issues
all related Application Monitor polling issues we were experiencing

Lessons Learned / Takeaway:

Going forward, we are updating our Buddy Drop deployment process. We still strongly believe in maintaining backup copies of replaced files, however instead of storing .old or .bak files inside SolarWinds application folders, we will move those backup files to a separate archive location outside of:

C:\Program Files\SolarWinds

For other long-time SolarWinds customers planning upgrades to 2026.1.1 or later, I would recommend reviewing the:

C:\Program Files\SolarWinds\Orion\web

folder on Additional Polling Engines to ensure no unexpected backup files remain that could interfere with the upgrade or polling process.

superfly

Glad it was resolved. I'm not sure when I'll upgrade but I will keep this in mind. Thanks.

Quick Links

Alert HTML Content
Alert Cleared.htmlHello, I would like to share the HTML template details we have prepared so that Solarwinds alarms can become more meaningful. It can list alarm object details and connected device details separately in HTML template. Except for object and device details, you can easily add custom property information…
Cisco ASR Devices
Cisco ASR Devices.pollerCisco ASR Devices
Basic SWQL Syntax
SWQL is built on the framework of SQL and as such supports most of the standard clauses as part of a query. A very simple example query is: SELECT Caption, IPAddress, Vendor, ResponseTime FROM Orion.Nodes Dissecting this query is relatively straightforward: show some fields (Caption, IP address, Vendor, and Response Time)…
Cisco ASA SSL Tunnels
Active SSL Tunnels-ASA.UnDPThis poller *should* display the number of Active SSL VPN (Anyconnect) Tunnels currently connected to your box. However, I tried it with my 5520 running 8.0.4 and for some reason I get a OID Not Supported. Here's my post in the forum: *EDIT* This is confirmed working with at least Interm release…