Open for Voting

Pull serial numbers without need of UnPn

I know that we can create our custom pollers to pull info (like serial numbers) from our network devices.  However, as I have recently noticed, vendors do not all store the serial # in the same OID, and some even store serial # info in different OIDs for some of their device types.  Needless to say, pulling serial # from devices is far from my cup of tea.

As a matter of fact, I believe that serial collecting numbers should be part of what SolarWinds NCM pulls right out of the box, regardless of the vendor or model.  After all, NCM can login onto the devices via SSH and run all kinds of commands to pull any info.  If you also would like for NCM to provide serial numbers for all of your devices, regardless of vendor or model, please vote for this idea.  Many thanks and have a great day (or evening) everyone. emoticons_cool.png

mr.e
  • in reply to cahunt

    That's pretty much exactly what we already do.  Thanks.

  • in reply to rschroeder

    Chassis swap's using the same IP, I would rediscover then select the new interfaces. The rediscover updates the serial # in NPM, NCM Job that night updated the inventory report. I would keep the old interfaces there for a few days at least to showcase the improved performance and benefit of the refresh and all those bucks spent on hardware and man hours.  Then just delete the old/ghost interfaces when you are ready to move forwards.

    If you have hardware that is not having the Serial# pulled, consider setting up a custom property, which in turn would make the reporting easy.

    *There is some scripting to update the Serial# Custom Property, and might be a little fun to work with if you have to break down and use a UnDP for that serial#. But still the action could be put together so that it pulls the value from whatever table it can be found in, to fill in the Serial CP.

  • in reply to mr.e

    One can only ask. 

    Say "Hi!" to Wilbur!

  • in reply to rschroeder

    I just noticed that SolarWinds stores serial # for our  Cisco SM-ES3G-16-P under Chassis ID.  And the routers and WLAN controllers show the S/N in different fields. So, I am forced to run about 4 different reports for those, clean up and then merge the reports manually.  Needless to say, not very fun...

    I wish SolarWinds standardized the place where it stores the serial # so we did not have to run multiple reports.   Maybe I'll submit a Feature for this.  emoticons_cool.png

  • in reply to mr.e

    Well, that IS a way to do things, but as you say, deleting and re-adding is not a preferred process for me.  I only use that when replacing hardware and using the same IP address to manage that hardware.  For example, replacing an older model switch with a newer one.  Both have the same configuration parameters, but their interfaces are very different.  I've found that deleting the old node and re-adding the new one, even though the same IP address is used to manage both, is more satisfactory in the long run.

    Between the canned reports and the information available through mining the Solarwinds database with SWQL via the SDK, one would hope that simply clicking "Rediscover" on a node, and then perhaps manually polling it three times, would refresh your information without needing to delete the node and re-add it.

    Anyone else care to offer ideas?

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification Media Vault Link Accounts
About THWACK Blogs For Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2024 SolarWinds Worldwide, LLC. All Rights Reserved.