This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

No volume size for windows server node

Hey everyone,

I have a problem with one of our windows server nodes. The node doesn't show any volumes sizes although the volumes are all up.

pastedImage_0.png

(descriptions in german)

I already deleted the node and re-added it.

The node is managed via snmp, which also connects succesfully (testing the snmp community string).

I can't figure out what's the problem.

Does anyone have an idea?

Regards

Stefan

edit: switching to WMI polling shows all the volume informations. However I need to monitor this node via SNMP.

Nachricht geändert durch Stefan Achterholt

  • 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! emoticons_happy.png 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? emoticons_happy.png

  • 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)

  • 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..

    Need OID for M drive - Windows 2008 R2

    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 emoticons_happy.png

    Create a Universal Device Poller (UnDP) - SolarWinds Worldwide, LLC. Help and Support

  • Weird!

    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 (1.3.6.1.2.1.25.2.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.

  • Thank you for your detailed answer emoticons_happy.png

    So I SNMP walked the hrStorageTable as mentioned by yaquaholic and heres the result:

    .1.3.6.1.2.1.25.2.3.1.1.1 = INTEGER: 1

    .1.3.6.1.2.1.25.2.3.1.1.2 = INTEGER: 2

    .1.3.6.1.2.1.25.2.3.1.1.3 = INTEGER: 3

    .1.3.6.1.2.1.25.2.3.1.1.4 = INTEGER: 4

    .1.3.6.1.2.1.25.2.3.1.1.5 = INTEGER: 5

    .1.3.6.1.2.1.25.2.3.1.1.6 = INTEGER: 6

    .1.3.6.1.2.1.25.2.3.1.1.7 = INTEGER: 7

    .1.3.6.1.2.1.25.2.3.1.1.8 = INTEGER: 8

    .1.3.6.1.2.1.25.2.3.1.1.9 = INTEGER: 9

    .1.3.6.1.2.1.25.2.3.1.2.1 = OID: 1.3.6.1.2.1.25.2.1.5

    .1.3.6.1.2.1.25.2.3.1.2.2 = OID: 1.3.6.1.2.1.25.2.1.4

    .1.3.6.1.2.1.25.2.3.1.2.3 = OID: 1.3.6.1.2.1.25.2.1.4

    .1.3.6.1.2.1.25.2.3.1.2.4 = OID: 1.3.6.1.2.1.25.2.1.4

    .1.3.6.1.2.1.25.2.3.1.2.5 = OID: 1.3.6.1.2.1.25.2.1.4

    .1.3.6.1.2.1.25.2.3.1.2.6 = OID: 1.3.6.1.2.1.25.2.1.4

    .1.3.6.1.2.1.25.2.3.1.2.7 = OID: 1.3.6.1.2.1.25.2.1.7

    .1.3.6.1.2.1.25.2.3.1.2.8 = OID: 1.3.6.1.2.1.25.2.1.3

    .1.3.6.1.2.1.25.2.3.1.2.9 = OID: 1.3.6.1.2.1.25.2.1.2

    .1.3.6.1.2.1.25.2.3.1.3.1 = STRING: "A:\"

    .1.3.6.1.2.1.25.2.3.1.3.2 = STRING: "C:\ Label:LABELNAME  Serial Number XXXXXX"

    .1.3.6.1.2.1.25.2.3.1.3.3 = STRING: "D:\ Label:Label:LABELNAME Serial Number XXXXXX"

    .1.3.6.1.2.1.25.2.3.1.3.4 = STRING: "E:\ Label:Label:LABELNAME  Serial Number XXXXXX"

    .1.3.6.1.2.1.25.2.3.1.3.5 = STRING: "F:\ Label:Label:LABELNAME  Serial Number XXXXXX"

    .1.3.6.1.2.1.25.2.3.1.3.6 = STRING: "P:\ Label:Label:LABELNAME  Serial Number XXXXXX"

    .1.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Y:\"

    .1.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Virtual Memory"

    .1.3.6.1.2.1.25.2.3.1.3.9 = STRING: "Physical Memory"

    .1.3.6.1.2.1.25.2.3.1.4.1 = INTEGER: 0

    .1.3.6.1.2.1.25.2.3.1.4.2 = INTEGER: 4096

    .1.3.6.1.2.1.25.2.3.1.4.3 = INTEGER: 4096

    .1.3.6.1.2.1.25.2.3.1.4.4 = INTEGER: 4096

    .1.3.6.1.2.1.25.2.3.1.4.5 = INTEGER: 4096

    .1.3.6.1.2.1.25.2.3.1.4.6 = INTEGER: 4096

    .1.3.6.1.2.1.25.2.3.1.4.7 = INTEGER: 0

    .1.3.6.1.2.1.25.2.3.1.4.8 = INTEGER: 65536

    .1.3.6.1.2.1.25.2.3.1.4.9 = INTEGER: 65536

    .1.3.6.1.2.1.25.2.3.1.5.1 = INTEGER: 0

    .1.3.6.1.2.1.25.2.3.1.5.2 = INTEGER: 14852095

    .1.3.6.1.2.1.25.2.3.1.5.3 = INTEGER: 15727871

    .1.3.6.1.2.1.25.2.3.1.5.4 = INTEGER: 19660031

    .1.3.6.1.2.1.25.2.3.1.5.5 = INTEGER: 262143231

    .1.3.6.1.2.1.25.2.3.1.5.6 = INTEGER: 13106431

    .1.3.6.1.2.1.25.2.3.1.5.7 = INTEGER: 0

    .1.3.6.1.2.1.25.2.3.1.5.8 = INTEGER: 1079592

    .1.3.6.1.2.1.25.2.3.1.5.9 = INTEGER: 262136

    .1.3.6.1.2.1.25.2.3.1.6.1 = INTEGER: 0

    .1.3.6.1.2.1.25.2.3.1.6.2 = INTEGER: 4659818

    .1.3.6.1.2.1.25.2.3.1.6.3 = INTEGER: 5890291

    .1.3.6.1.2.1.25.2.3.1.6.4 = INTEGER: 656495

    .1.3.6.1.2.1.25.2.3.1.6.5 = INTEGER: 245360294

    .1.3.6.1.2.1.25.2.3.1.6.6 = INTEGER: 13104977

    .1.3.6.1.2.1.25.2.3.1.6.7 = INTEGER: 0

    .1.3.6.1.2.1.25.2.3.1.6.8 = INTEGER: 526948

    .1.3.6.1.2.1.25.2.3.1.6.9 = INTEGER: 158556

    .1.3.6.1.2.1.25.2.3.1.7.1 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.2 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.3 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.4 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.5 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.6 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.7 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.8 = COUNTER32: 0

    .1.3.6.1.2.1.25.2.3.1.7.9 = COUNTER32: 0

    So, according to this, I think I have to open a support case with SolarWinds. emoticons_grin.png

    I will post the solution as soon as I have it.

    Thank you all for your assessments. emoticons_happy.png

  • Hi everyone,

    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. emoticons_happy.png

    Even SNMP walk has no timeouts anymore.

    I'm sorry I took your time for this.

    But thanks again for your suggestions! emoticons_happy.png