Highlighted
Super Contributor.. Super Contributor..
Super Contributor..
670 views

Agent Driven Inventory Discovery

I activated the Agent Driven Inventory Discovery job, however no CI's were automatically added to the triggered CI list.  When I manually added a UDA CI it failed with the following message:

"Server Processing Failure / Probe wasn't found for this CI.  Failed to parse probe name from override domain text"

Is there a setup step I missed? what is the override domain text?

Not sure where to go from here

Thanks

0 Likes
13 Replies
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Hello ,

 

Filter those CIs which associated with IpAddress having no probe name in trigger TQL.

 

Regards,

Melissa Carranza Mejias
Customer Support Engineer

If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation. “
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Discovery Probe Name should not be null on UDA CI. Not sure which job will populate that attribute.

Highlighted
Outstanding Contributor.
Outstanding Contributor.

I'm having the same issue that the UDA CI type does not have the Probe Name value set. I have run the Host Connection by Shell, UDA Status Collector, and Range IPs by ICMP. None of these jobs populate the Probe Name value.

How have you fixed the issue?

0 Likes
Highlighted
Respected Contributor.. Respected Contributor..
Respected Contributor..

Try this:

Go to the job, (Universal Discovery, Discovery Modules/Jobs) - find the job (Host Connection by Shell for instance).  Go to the Properties tab of the job.  

Under Trigger Queries, see if host_shell (or whatever is located there) has <<All Probes>> on probe limit.

My bet is they say <<Disabled>>.  Click on the icon with the three dots and select "ALL PROBES".

Save and re-run.

0 Likes
Highlighted
Respected Contributor.. Respected Contributor..
Respected Contributor..

Try this:

Go to the job, (Universal Discovery, Discovery Modules/Jobs) - find the job (Host Connection by Shell for instance).  Go to the Properties tab of the job.  

Under Trigger Queries, see if host_shell (or whatever is located there) has ((All Probes)) on probe limit.

My bet is they say ((Disabled)).  Click on the icon with the three dots and select "ALL PROBES".

Save and re-run.

0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

@Jason Connerthank you for the suggestion. The job Host Connection by Shell runs and updates attributes on the UDA CI but it doesn't populate the attribute Discovery Probe Name.

0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

@JohnCII would be interested in your input on this issue. Do you know what job will populate the attribute Discovery Probe Name on the UDA CI? This attribute is required for the trigger TQL of Agent Driven Inventory job.
ADID_Trigger_TQL.png

For reference see the Agent Driven Inventory Job in content pack documentation.

Tags (3)
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Hello John,

 

I've encountered the same problem in the past.

It's not a problem to populate the uda_probe_name attribute (known as Discovery Probe Name) as we can send it though the dispatch mechanism of HostConnection by shell and model it.

The real problem is what we do with flying devices? Those devices that often change their network location and will have to report to different probes.

I can't make a simple script patch for this and you can test it. What's your CP version?

 

 

Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success
0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi,

 

In this case I think that it is exactly the problem of not populating UDA's uda_probe_name attribute. 'Agent Driven Inventory Discovery Adapter', 'Advanced Agent Driven Inventory Discovery Adapter' and 'Basic Agent Driven Inventory Discovery Adapter' all have it as 'Override default probe selection'. And even if this attribute is ignored by the dispatch mechanism, then the trigger TQLs are not feeding UDA CIs to the job, since they have it as requirement in the statement as John stated. 

I've checked all the python script sources connected with Host Connection by Shell, the job which should be able to provide a value for it, but nowhere uda_probe_name is mentioned. This attribute seems to be a ghost from the past.

Regards,

Petko

Likes are appreciated!
Highlighted
Outstanding Contributor.
Outstanding Contributor.

@JohnCII will open a support case. As @popadiyski has pointed out, this workaround will not solve the issue that there is no current way to trigger this job since there is nothing populating Discovery Probe Name.

I am curious if anyone has this discovery job working at all. This has been available since 10.3x or 2018 when @Paul Meaders started this topic.

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

@John Goldstein 

I just read what is exactly the Agent Driven Inventory. In fact I think I was wrong. This is not a the normal job, where the Probe connects to UDA. It is when the UDA automatically executes the scanner on scheduled period and then sends the scanner file to the Probes API port. 

In this case you don't need to initiate connection from the probe, but just to initiate the XMLEnrichment workflow. 

I suppose the uda_probe_name is provided when such UDA with Agent Driven Flow is installed and sends its first scan file.

Check this documentation out

Likes are appreciated!
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.