locked
SNMP Discovery of Windows machine RRS feed

  • Question

  • I'm trying to install and configure the Netbackup management pack, which ultimately requires that you discover the windows machine that runs the Netbackup NOM Console as an snmp discovered device.    (the netbackup pack is essentially a trap converter).  

    My problem is that I cannot seem to discover the windows server using the snmp discovery wizard.   It just times out and says that the device was not discovered. I have discovered other SNMP devices, but this is the first time I've tried to discover a windows server via snmp.    Here's what I've tried and/or verified:

    - SQL Broker is enabled
    - SNMP service and snmp trap service are set to automatic start and are running
    - SNMP community strings are all "public" with read/create on both the NOM machine and the management server. 
    - "Accept traps from all hosts" is enabled.
    - I've tried both snmp v1 and v2 discovery in the wizard
    - I have verified that there is NO port blocking between the agent and MS.  (using the portqry utility).
    - Ping responses are successful to/from both nodes and name resolution also works fine.

    I've found several forum postings about snmp discovery and everything seems to be set correctly.

    Any other bugs or known issues about discovering windows server via snmp?   anyone every successfully deploy the netbackup management pack?

    Thanks
    What Gives?  

    Tuesday, July 14, 2009 6:40 PM

Answers

  • Looks like one of the Netbackup NOM services was interfering with the SCOM SNMP Discovery process.   On the NOM server, I stopped the "Symantec Authentication Service" and the "Netbackup Operations Manager Server" service,  and then SCOM SNMP discovery was able to complete.

    Would have been nice if Symantec included this little tidbit in the Netbackup management Pack documentation.

    • Marked as answer by StuartR Wednesday, August 26, 2009 4:19 PM
    Tuesday, July 14, 2009 7:41 PM

All replies

  • Looks like one of the Netbackup NOM services was interfering with the SCOM SNMP Discovery process.   On the NOM server, I stopped the "Symantec Authentication Service" and the "Netbackup Operations Manager Server" service,  and then SCOM SNMP discovery was able to complete.

    Would have been nice if Symantec included this little tidbit in the Netbackup management Pack documentation.

    • Marked as answer by StuartR Wednesday, August 26, 2009 4:19 PM
    Tuesday, July 14, 2009 7:41 PM
  • Hi Scott,
    Just wondering if there are any "special" tricks, beside the ones you mention above, for this to work?
    eg. Is the MP noisy? Does it need a lot of tweaking?

    Thankyou,
    John Bradshaw
    Tuesday, September 1, 2009 11:08 PM
  • John,
    Couple things - I think since I posted this thread that Symantec has released a newer version of NOM and the Netbackup management pack that had a couple fixes.      The SNMP blocking issue was caused by the NOM Server service and I believe there was a configuration section in the NOM console that allows you to change NOM's snmp port so that the Windows SNMP service can use port 161.  

    Even after making this change, I found that the Netbackup discovery views were not getting populated.   I found that the designated management server that the nom server was focused on was generating the following WMI error and I found that I had to add the default agent action account into the local administrators group of the NOM server.   This allowed the WMI queries to complete and allowed the discovery data to populate.     Other than this, we just defined the alerts in NOM that we wanted to be notified on and chose SNMP as the delivery mechanism - then the alerts showed up in SCOM.       Please note that the nom/scom integration components do no maintain state information - it's really just a basic SNMP trap forwarder.   So you will have to manually close any alerts that come from NOM into scom. 

    Event Type:       Warning

    Event Source:    Health Service Modules

    Event Category: None

    Event ID:           10401

    Date:                7/30/2009

    Time:                1:31:53 PM

    User:                N/A

    Computer:         SHR-SV0010

    Description:

    Module was unable to connect to namespace '\\NBU-PR-NOM-01\ROOT\CIMV2'

    • Proposed as answer by bradje Wednesday, September 2, 2009 8:23 PM
    Wednesday, September 2, 2009 7:00 PM
  • Thx very much Scott. Very helpful,

    John Bradshaw
    Wednesday, September 2, 2009 8:23 PM
  • I just started with this management pack today. It's not very good. The discovery is targeted against all network devices, so you get a ton of warnings on your management server. The default that your management server uses needs to be a local admin on the NetBackup server so the WMI query can run remotely...

    I'm not even sure this one is worth using unless your only network device is that single server, otherwise your logs will fill with errors for every WMI query that fails.
    Tuesday, October 27, 2009 10:07 PM
  • I've scrapped it and am making my own rules that target SNMP. The community string that comes from NOM is just that, NOM. Once you know that you can copy the OIDs the rules uses, make your own, and then delete this POS mp. I think Symantec should not make this available for download and either scrap it or create another one.

    The netbackup discovery needs to be scrapped and the directions should be to just populate the group manually.
    Wednesday, November 4, 2009 7:13 PM
  • Hi jb33zy,
    We only have one NOM server that manages multiple media servers, so we never had to deal with multiple NOM servers.       Like a lot of other snmp trap converter management packs,  it can be messy.    I concur that if you want to take the time to build your own snmp monitors, it ulimately might be cleaner than dealing with all the unnecessary noise from this pack.   SNMP monitors are a little tricky at first, but once you get the basic structure down and if you have a good vendor-supplied list of OID values,  it's pretty easy to reproduce the monitors in order to target specific events.

    Scott...
    Tuesday, November 10, 2009 2:02 PM
  • It's not multiple NOM that is the issue, it's if you have other network devices discovered, the discovery targets all SNMP devices. Terrible design! An AS/400 does not have WMI so there are error messages, IBM AIX doesn't have WMI, more error messages, etc...
    Wednesday, December 30, 2009 11:42 PM
  • Hi

    I am having a similar problem but with the HPStorage works MP for SCOM and I believe I have followed the MP to the letter and still not getting any alerts. I have sent test SNMP traps and have been using snmp catcher software and they appear to be getting to the scom server. I have set override to true. I have also tried add the nodes as network devices and they arrive into scom but then there is an error stating:

    The device is not responding to SNMP GET - unsure what this is.

    Make sure community string is correct and update the monitor- community string is correct but how do i update the monitor, i assume this is just a variable.

    Ensure can you ping - I can ping

    I am not getting any alerts from P4000 nodes but I am receiving snmp traps from other appliances.

    any ideas????

    Many Thanks

    C

    Thursday, September 15, 2011 2:18 PM
  • Modify a file on management servers: C:\Program Files\System Center 2012\Operations Manager\Server\NetworkMonitoring\rules\discovery\ic-post-processor.asl

    Search:

    ISWINDOWSHOST(systemObj) do {

    if (systemObj->Type == "HOST" && systemObj->Vendor == "MICROSOFT") {

    return TRUE ; /* change to FALSE */

    }

    if (SEARCHSTRING(systemObj->Description, "Windows")) {

    return TRUE ; /* change to FALSE */

    }

    systemOIDCheck = ".1.3.6.1.4.1.311.1.1.3.1" ;

    if (substring(systemObj->SystemObjectID, 0, sizeof(systemOIDCheck)) == systemOIDCheck) {

    return TRUE ; /* change to FALSE */

    }

    systemOIDCheck = ".1.3.6.1.4.1.99.1.1.3.11" ;

    if (substring(systemObj->SystemObjectID, 0, sizeof(systemOIDCheck)) == systemOIDCheck) {

    return TRUE ; /* change to FALSE */

    }

    return FALSE ;

    }


    William

    Thursday, January 8, 2015 7:54 AM