Job Status with Management Extender Configured

Content Authoring BigFix.me
1

Has anyone ever come across this issue before and if so how did you fix it?

We’ve configured the management extender for the ESXi which means that each endpoint now has more than one ID (consolidated ID, host ID and ESXi ID).

For every action we run now, it kicks off two jobs:

<ActionResults Resource="https://bigfix-server.local:52311/api/action/178714/status">
<ActionID>178714</ActionID>
<Status>Open</Status>
<DateIssued>Wed, 26 Feb 2025 12:37:28 +0000</DateIssued>
<Computer ID="2686605814" Name="blah">
<Status>The action executed successfully.</Status>
<State IsError="0">3</State>
<ExitCode>15</ExitCode>
<ApplyCount>1</ApplyCount>
<RetryCount>1</RetryCount>
<LineNumber>3</LineNumber>
<StartTime>Wed, 26 Feb 2025 12:37:29 +0000</StartTime>
<EndTime>Wed, 26 Feb 2025 12:37:29 +0000</EndTime>
<Computer ID="13806264" Name="blah">
<Status>The action executed successfully.</Status>
<State IsError="0">3</State>
<ExitCode>15</ExitCode>
<ApplyCount>1</ApplyCount>
<RetryCount>1</RetryCount>
<LineNumber>3</LineNumber>
<StartTime>Wed, 26 Feb 2025 12:37:29 +0000</StartTime>
<EndTime>Wed, 26 Feb 2025 12:37:29 +0000</EndTime>
</Computer>
</Computer>
</ActionResults>
</BESAPI>

The two computer ID’s seen are the consolidated ID and the ESXi ID which suggests that as BigFix has no idea which of those ID’s it needs to send a job to (as you use a hostname rather than an ID when creating a job) that it executes the jobs on both in the hope that one of them will work.

The problem this causes though is that there is no way then to filter for the status for the consolidated ID for each job and if (like us) you parse that data into another place then you end up with mixed results.

The API call I’ve been using is:

https://bigfix-server.local:52311/api/action/178714/status

I’ve also tried using the filters as found here Action | BigFix Developer but they don’t work when you are running a MAG

I’ve also tried using query for the job but as you all know, my relevance skills are shocking :smiley: so I can’t get it to work.

I did try multiple variations of this but couldn’t find anything that would work:

((names of it, id of it, states of it) of bes actions whose (id of it = 268660581) of bes computers)

Any thoughts and help would be much appreciated - I do have a case open for this too.

2

Are you using both VMware CloudPlugin and ESXi management extender?
The ID 2686605814 seems to be a correlation one.

1 Like
3

Correlation’s always a bit confusing.

What I believe this particular thing is showing is that this action was run only by the ESXi instance of the computer.

Note that these are not two separate results at the same level - but that the for the ESXi instance is a child node of the for the Correlated instance.

That’s similar to the Console view, where for an action result you can see at the top level the correlated computer, and you can expand that correlation result into a tree showing the child computer node for the specific agent or plugin that ran the action.

Whether the action gets run by an extender agent or the native agent could depend on a combination fo the source site (and which agent types are subscribed to the site), as well as the fixlet/baseline relevance, and the targeting (static or dynamic). Does that give any clue as to why this was only executed by the ESXi agent and not the native one? It might also be useful to check the action configuration from https://bigfix-server.local:52311/api/action/178714 particularly the <Target> node from the action.

4

@Davide_11 yeah both are configured as we have multiple ESXi’s

@JasonWalker it ran against the actual BigFix agent and not the ESXi connection.

I still haven’t had a reply from HCL on the ticket but I’m struggling and have had to write a python based workaround to do it but it’s messy and resource hungry so I’d rather move away from it.

5

@FatScottishGuy In your case, we have three representations of the same device: native, proxy (they correlate each other), and ESXi. If you run the action using targeting by name, the RootServer doesn’t know toward what representation it needs to send the action because the device name will be the same for all of them. This is expected. You could use targeting by property, choosing “AgentType” as Native, for example.

6

Are we suggesting then to target the devices by ID?

I mean it would make sense but it’s also a pain :smiley:

7

You can define a custom property to identify the native toward which you want to run the action (as a new client setting value, for instance), then use this as a filter to find your devices. Take a look at this page
Action: Target, section “Dynamically targeted by properties”

8

Generally I’d handle this by making the Fixlet/task only relevant to the native agent or to the extender agent depending on where I want it to run. That’s either through the relevance or the site computer subscriptions to the site in which the content exists.

Then you can just target by computer name as usual, and the action is ignored by whichever agents don’t need to run it.

1 Like
9

I hadn’t thought about this tbh and most of our custom fixlets don’t have that in there so now it’s time to add it all then we won’t see the problem :slight_smile:

10

I take it all back :frowning: it did’t fix the problem

I modified a fixlet to have:

(exists true whose (if true then (exists (if exists true whose (if true then in proxy agent context else false) then "Proxy - " & data source else "Native") whose (it as string as lowercase = "Native" as lowercase)) else false))

When it ran - the fixlet ran against all 3 ID’s :frowning:

  1. The correlated one (Native Client)
  2. The agent (Native Client)
  3. The Proxy - VMWare (Proxy - VMWare)

So even when I change the relevance it’s not stopping it running the action against the proxy ID and when I look at the job status using the API it’s only showing the correlated ID and the agent ID but realistically I only want whichever one of those two is going to be true to the action.

11

@FatScottishGuy Which Content are you deploying - External or Custom? If External, can you please provide some example.

Does your end goal is to get the Status of the Action / Sub-Actions per Computer that reported back?

Computer1, Sub-Action1, Fixed… etc?

And of course you want to target only the Native Agent

12

Either :frowning: the same problem occurs with both External and Custom content.

The goal is to just see a single CI (correlated) in the status.

I can use the filter but the minute I add multiple endpoints / fixlets and create a MAG the filter stops working.

I can’t target just for native agent as both the correlated and the agent come back as native.

14

At the top-level, it is showing the correlated status. Note that you don’t have three <Computer> nodes at the same level, you have the Correlated <Computer> node at the top level and the other two computers are child nodes of the correlated <Computer> node.

Just as in the Console, you see the Correlated result at the top level, but if you like you can drill-down beneath the correlation to see statuses for the individual computer nodes that make up the correlation if you like.

15

Yeah, I can see that but trying to filter out the noise is the harder part :frowning:

The other <Computer> node’s bear no relevance as nothing runs against them :frowning:

16

It was not obvious to me that there’s a childe node in the xml, since I don’t work with it very much. Can the query be written to include only the parent node?

17

What about if you try to use session relevance?

curl -k -u user:pw https://<my server IP>:52311/api/query?relevance="(status+of+results+of+(bes+actions+whose+(id+of+it+=+178714)))+as+string"

1 Like