locked
Debugging network discovery rules (SCOM 2019) RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello everyone


    I'm currently debugging my SCOM 2019 network discovery rules. Since I'm a bit stuck, I hope someone can give me some helpful information, so that I can resolve this issue :).


    Scenario:


    2 seperate network segments; computer/server segment and management segment.


    The first segment contains my management servers (lets call them MS1 and MS2). The second segment contains two GW servers (which are part of the same MG and connected to MS1:5723, lets call them GW1 and GW2) and the network devices, I wish to monitor.


    These network devices are already monitored by our old SCOM env. My goal is now, to get them into the new env alongside the old one (multi homing). Monitoring is (for most devices) done via SNMPv3 with SHA Key and DES encryption.


    To be able to use somewhat redundant monitoring, I created a resource pool "RP1" with the members GW1 and GW2. Additionally I created a discovery rule, where server was "GW1" and RP was "RP1". I used explicit discovery and inserted some ~10 network devices. The settings for each device was "SNMPonly", SNMPv3. Beforehand I created a run as account with my SHA and DES keys (distributed to all MSs and GWs) and assigned the run as account to the SNMPv3 monitoring profile (all targeted objects). The exact same keys where tested with the paessler SNMP tester from GW1 and worked fine (destination was one of the network devices, as OID I used .1.3.6.1.2.1.1.2.0). This was the account selected for each device in the discovery rule. 


    After I saved the rule (schedule to manual), I ran it manually. The discovery rule seems to get started, since the task looks fine in SCOM. If I check the GW1 however, I don't see any discovery running (events 12001-12199). The internal discovery MP gets distributed to the server, but the discovery never runs. To confirm that, I used Wireshark with an SNMP filter. There were no packages what so ever.


    I already tried playing around with some settings, but to no availl. Has anyone had similar issues?


    Any tips are greatly appreciated!


    Regards 


    Simon 

    Friday, June 19, 2020 7:34 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Alright so I found the problem. The Run As Account profiles were configured slightly wrong. I assumed, I only needed to configure the SNMPv3 profile (SNMPv3 Monitoring Account) to utilise the SNMPv3 Account. 

    Like so

    After some testing around I checked the "normal"/general SNMP profile (SNMP Monitoring Account). It was configured to use the SNMPv2 Account for "all targeted objects". Once removed I selected the SNMPv3 Account for the same SNMP Community object, that was selected in the SNMPv3 profile. 

    Like so

    After that, I ran the discovery again and - voila, the correct run as account was shown. 

    Hope this helps someone with a similar issue.

    Regards

    Simon

    • Marked as answer by simonjaeggi Thursday, August 20, 2020 9:32 AM
    Thursday, August 20, 2020 9:31 AM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    Sali Simon,

    let me first say that I read carefully your description and the apprioach seems absolutely correct. What I would check is the distribution of your SNMP account..Is it distributed to tghe RP with both GW1 and GW2?

    The next step, part of the troublöeshooting is to make sure that the configs aree reaching your GWs and they are operating properly. I would clear the Health State folder oin both GWs and restart the Microspft Monitoring Agent, then examine the OPerations Manager event log for any warning or error events. 

    The nbext things to test sis the Firewall..I know that it semes that the GW do not run the discoevry, but the Firewall can also make it look like the dioscvery is not being run (out of experience). Just disable the firewall for testinbg purposes and test. Enable it afterwards of course. 

    Make sure port 161 is added as an exclusion to the FW of ypour GWs.

    Last, but not least Stefan Köll wrote an article about troubleshooting the network discovery. Some of the stuff you have already done (like Network trace), but can you please try with the logging, maybe you will find related information there. 

    Troubleshooting Network Discovery in SCOM 2012
    https://code4ward.net/2011/08/11/troubleshooting-network-discovery-in-scom-2012/

    Please post back with a short status update. 

    Greetings from Bern!

    Regards,

    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!) Blog: https://blog.pohn.ch/ Twitter: @StoyanChalakov


    Tuesday, June 23, 2020 2:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Stoyan
    I (finally) got some time on my hands, to debug this issue further. 

    What I would check is the distribution of your SNMP account. Is it distributed to the RP with both GW1 and GW2?

    Yes, the SNMP Account is distributed to both GWs individually as well as to the RP in which the GWs are in.

    I would clear the Health State folder in both GWs and restart the Microspft Monitoring Agent, then examine the Operations Manager event log for any warning or error events.

    After clearing the cache on GW1 the rule does start when triggered. I checked the Opsmgr eventlog (no errors or warnings whatsoever) and especially the discovery events (12001-12199). The rule seems to run seamlessly and discovers the specified network devices. The network devices are shown in the console, but are not SNMPv3 (yes, I made absolutely sure I changed every single one of them to SNMPv3 with the right account, no ICMP). The rule I used is a explicit discovery rule, so I can't understand why SCOM would change the SNMP version. 

    One thing I might mention is, I used the recursive discovery once to test how it worked. After seeing, that it wouldn't do for me, I deleted all the devices and the rule again. Could it be, that the devices or some info about them are still lying around somewhere in the OpsMgr DB? Can I do anything about that?

    Just disable the firewall for testing purposes and test. Enable it afterwards of course. 

    I disabled the FW on GW1, stopped the Healthservice, cleared the cache, deleted the network devices, used some different network devices, started the heatlh service on GW1, ran the discovery.
    The result is the same. The devices are shown in the console, but SCOM uses SNMPv2. At least I thought that up to this point.
    The thing is, as RunAs Account SCOM seems to use the SNMPv2 security string/account. Shouln't be possible right? Well SCOM seems to think otherwise. The Account is shown as SNMPv2 (I checked it, it really is a securtiy string), however when checking the device properties, SCOM tells me the SNMP Version is "3".

    I'm quite a bit confused. Firstly, why would SCOM use a different Account than specified in the discovery rule? Secondly, how can SCOM use SNMPv3 if it doesn't use the SNMPv3 credentials but a SNMPv2 community string? Maybe this is just some SCOM bug. Is there any way I can check which Account is actually used for the connection?

    Discovery rule

    Devices after being discovered

    Make sure port 161 is added as an exclusion to the FW of your GWs.

    I did. Additionally to my own rule, I activated the built in SCOM network discovery rules. 

    Edit:
    I checked the SNMP traffic on GW1 with Wireshark. SCOM does use SNMPv3, so I assume it uses the correct account afterall.  

    Best regards
    Simon



    • Edited by simonjaeggi Thursday, August 20, 2020 8:03 AM additional info
    Tuesday, August 18, 2020 9:18 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Alright so I found the problem. The Run As Account profiles were configured slightly wrong. I assumed, I only needed to configure the SNMPv3 profile (SNMPv3 Monitoring Account) to utilise the SNMPv3 Account. 

    Like so

    After some testing around I checked the "normal"/general SNMP profile (SNMP Monitoring Account). It was configured to use the SNMPv2 Account for "all targeted objects". Once removed I selected the SNMPv3 Account for the same SNMP Community object, that was selected in the SNMPv3 profile. 

    Like so

    After that, I ran the discovery again and - voila, the correct run as account was shown. 

    Hope this helps someone with a similar issue.

    Regards

    Simon

    • Marked as answer by simonjaeggi Thursday, August 20, 2020 9:32 AM
    Thursday, August 20, 2020 9:31 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hoi Simon,

    thanks for sharing.

    Strangely enough I was just about to post a reply and suggest to go over the basic config like accounts and profiles. I am glad you have figured it out. 

    Just a reminder: The new place for all SCOM related questions and requests is the Microsoft QandA. I hope to meet you there soon. 

    Regards,

    Stoyan

    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!) Blog: https://blog.pohn.ch/ Twitter: @StoyanChalakov


    Thursday, August 20, 2020 9:45 AM