is there a reason why you use snmp to monitor a windows node?
I would only monitor a windows node via snmp as a last resort wmi being first then agent then snmp.
I think this has grown historically due to our firewall rules.
But to be honest, this has not been a problem so far.
We manage over 800 windows nodes over snmp, this node is the only one that has a problem.
But thanks anyway for this tip! I will definitely consider changing this!
When you List Resources on the device, can you see the drives listed?
Were the drives discovered with WMI, then you switched polling to SNMP?
If so then it appears that your snmpd.conf isn't providing volume/disk information.
Yes the drives are listed when I List Resources while polling through SNMP.
Exactly, I discovered the drives successfully (incl. Volume Size) with WMI and then switched polling to SNMP, after that the drives are marked as "UP" but no Volumesize is shown.
Ok, so do I have to configure the config file or replace it? Or is there another solution you would suggest?
I would try removing the volumes (delete from Manage Nodes) and then rerun the list resources and make sure your not using a cache version to add the volumes back in.
Thats exactly what I thought, I already did this twice but without success. (no cached version of list resources)
I now have a maintenance window to restart that specific Node. I figured out that the server has a very long runtime...
I'll notify you when the reboot is done. (13th of October)
If the drives are being listed, when you List Resources, then it appears that your snmpd.conf is fine.
grantallenby's suggestion of examining the hrStorageTable (18.104.22.168.22.214.171.124.3) is a good start.
If that is populated with with disk size/utilisation data, then it looks like time to raise a ticket with SolarWinds Support.
Have you tried using UNDP to test the Volume OID's directly?
You can create a device poller and test to see what results come back. This might help with the OID's What object IDs (OIDs) does NPM poll for volume information? What types of volume information does NPM poll? - SolarWind…
And this one from the window froum..
If not SNMP walk the Server to return what OID's its using for Volume metrics. It could be the SNMP service is corrupt or wrong for that server or that Solarwinds is just displaying the data incorrectly. If you test using just the OID for the C drive for example and it returns metrics you know is a Solarwinds bug, If its displays 0 its a corrupt SNMP Service.
This will help if you have never used UNDP
Thank you for your detailed answer
So I SNMP walked the hrStorageTable as mentioned by yaquaholic and heres the result:
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 1
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 2
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 3
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 4
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 5
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 6
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 7
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 8
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 9
.220.127.116.11.18.104.22.168.22.214.171.124 = OID: 126.96.36.199.188.8.131.52.1.5
.184.108.40.206.220.127.116.11.18.104.22.168 = OID: 22.214.171.124.126.96.36.199.1.4
.188.8.131.52.184.108.40.206.220.127.116.11 = OID: 18.104.22.168.22.214.171.124.1.4
.126.96.36.199.188.8.131.52.184.108.40.206 = OID: 220.127.116.11.18.104.22.168.1.4
.22.214.171.124.126.96.36.199.188.8.131.52 = OID: 184.108.40.206.220.127.116.11.1.4
.18.104.22.168.22.214.171.124.126.96.36.199 = OID: 188.8.131.52.184.108.40.206.1.4
.220.127.116.11.18.104.22.168.22.214.171.124 = OID: 126.96.36.199.188.8.131.52.1.7
.184.108.40.206.220.127.116.11.18.104.22.168 = OID: 22.214.171.124.126.96.36.199.1.3
.188.8.131.52.184.108.40.206.220.127.116.11 = OID: 18.104.22.168.22.214.171.124.1.2
.126.96.36.199.188.8.131.52.184.108.40.206 = STRING: "A:\"
.220.127.116.11.18.104.22.168.22.214.171.124 = STRING: "C:\ Label:LABELNAME Serial Number XXXXXX"
.126.96.36.199.188.8.131.52.184.108.40.206 = STRING: "D:\ Label:Label:LABELNAME Serial Number XXXXXX"
.220.127.116.11.18.104.22.168.22.214.171.124 = STRING: "E:\ Label:Label:LABELNAME Serial Number XXXXXX"
.126.96.36.199.188.8.131.52.184.108.40.206 = STRING: "F:\ Label:Label:LABELNAME Serial Number XXXXXX"
.220.127.116.11.18.104.22.168.22.214.171.124 = STRING: "P:\ Label:Label:LABELNAME Serial Number XXXXXX"
.126.96.36.199.188.8.131.52.184.108.40.206 = STRING: "Y:\"
.220.127.116.11.18.104.22.168.22.214.171.124 = STRING: "Virtual Memory"
.126.96.36.199.188.8.131.52.184.108.40.206 = STRING: "Physical Memory"
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 4096
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 4096
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 4096
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 4096
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 4096
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 65536
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 65536
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 0
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 14852095
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 15727871
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 19660031
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 262143231
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 13106431
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 0
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 1079592
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 262136
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 4659818
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 5890291
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 656495
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 245360294
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 13104977
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = INTEGER: 526948
.220.127.116.11.18.104.22.168.22.214.171.124 = INTEGER: 158556
.126.96.36.199.188.8.131.52.184.108.40.206 = COUNTER32: 0
.220.127.116.11.18.104.22.168.22.214.171.124 = COUNTER32: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = COUNTER32: 0
.220.127.116.11.18.104.22.168.22.214.171.124 = COUNTER32: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = COUNTER32: 0
.220.127.116.11.18.104.22.168.22.214.171.124 = COUNTER32: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = COUNTER32: 0
.220.127.116.11.18.104.22.168.22.214.171.124 = COUNTER32: 0
.126.96.36.199.188.8.131.52.184.108.40.206 = COUNTER32: 0
So, according to this, I think I have to open a support case with SolarWinds.
I will post the solution as soon as I have it.
Thank you all for your assessments.
I am finally able to respond to this post.
After I opened a support case with SolarWinds, the support and I came to the conclusion that this has something to do with the system itself.
The SNMP walk wasn't successful and always timed out.
Sometimes the simplest solution is the best: RESTART the faulty system...
I had to schedule the restart of the system for the weekend. After that I deleted the volumes and added them back. And voila now they are back with UP status and the volume sizes.
Even SNMP walk has no timeouts anymore.
I'm sorry I took your time for this.
But thanks again for your suggestions!