Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it!  Learn more

  • State Suggested Answer
  • Replies replies
    4
  • Answers answer
    1
  • Subscribers subscribers
    178
  • Views views
    498
  • Users 0 members are here
  • Locked Locked
Related
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NTCMD discovery running on two out of three probes

CrvenaZvezda

Hi!

I have three probes installed on identaical Windows Server 2019. The probes are in different zones. "NTCMD Host Resources and Applications by shell" is only running on two out of three probes. In adittion I have a test environment where the probe is running in the same zone/subnets as the production probe not running the NTCMD discovery. The probe in the test environment runs just fine and finds information that the production environment prode does not. 

If i look at discovered Windows servers in production I can se that for two of the probes at total of six discoevry jobs have been run, while for those belonging to the filing probe only runs three of the same jobs. 

I am out of ideas of how to trigger "NTCMD Host Resources and Applications by shell" for the last prudcion probe. Do any one have any kind of idea of what might be wrong? Too many subnets? Too many CIs? Discovery running in wrong order? 

TIA

Parents
  • 0  

    Hello,

    So the IPs are triggering for Host Connection by Shell on the third probe?

    Do you have results for them?

    If yes then do you have the Shell CIs in the trigger TQL for HRA job?

    Kind regards,

    Bogdan

  • 0 in reply to   

    Hi!

    Thanks for showing interest in this issue. 

    The IPs are triggering for 2 of 3 probes. Also the IPs are triggering for the single test probe. 

    The test probe works in the same subnet as the production probe that is failing. So I know with certainty that discovery is possible. 

    If I look at a single target I observe the following:

    Connecting with WMI works for test and production.

    Connecting with NTCMD works for test, fails in production

    Account used in all cases to connect and authenticate to the target is the same.

    I cannot find that the CI (ip address) in question is being triggered in the production environment. I do find the windows server and the IP as CIs in both productiond and test.  I have all probes selected,and still there is nothing.

    EDIT:

    I have done some more troubleshooting and it seems to me that the source error is in "Network Host Connection by Shell". It does not discover ntcmd and fails with:

    <log start="2022-11-28 04:16:24" severity="debug">Reporting error code 103 to framework.</log>
    <log start="2022-11-28 04:16:24" severity="debug">Error message is: NTCMD: Internal error. Details: Access is denied.

    The Access is denied is strange as long as test works, and as long as 2 of 3 probes in production succeedes using the same credentails as the failing probe. 

    BR,

    Jo

  • Suggested Answer

    0   in reply to 

    Jo;

    You should test with the command line from the probe.  Here's an older knowledge doc that has some NTCMD troubleshooting information:  support.microfocus.com/.../kmdoc.php

    -- Hope this helps!

    Keith Paschal

    UCMDB Worldwide Support Lead

  • 0 in reply to   

    Hi!

    Thank you for your suggestion. 

    I have tried  HPCmd.bat \\<problematic machine name or ip> /USER:<domain>\<username> /PWD:<password> on all four of my probes and they all fail with:

    Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/Logger
    at com.hp.ucmdb.discovery.library.clients.protocols.command.NTCmdDllWrapper.<clinit>(NTCmdDllWrapper.java:34)
    at com.hp.ucmdb.discovery.probe.util.HPCmdTool.main(HPCmdTool.java:102)
    Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
    at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
    ... 2 more

    It fails even on the probe that is executing all 6, and not just 3 of 6, discovery jobs. 

    BR,

    Jo

Reply
  • 0 in reply to   

    Hi!

    Thank you for your suggestion. 

    I have tried  HPCmd.bat \\<problematic machine name or ip> /USER:<domain>\<username> /PWD:<password> on all four of my probes and they all fail with:

    Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/Logger
    at com.hp.ucmdb.discovery.library.clients.protocols.command.NTCmdDllWrapper.<clinit>(NTCmdDllWrapper.java:34)
    at com.hp.ucmdb.discovery.probe.util.HPCmdTool.main(HPCmdTool.java:102)
    Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
    at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
    ... 2 more

    It fails even on the probe that is executing all 6, and not just 3 of 6, discovery jobs. 

    BR,

    Jo

Children
No Data

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.