WebUI Cloud Plugin Correlation

[cstoneba]

With cloud plugin correlated devices, I see this in the BigFix Console as an example:

When I run a session relevance query, I get only one result (the correlated devices).
(name of it, id of it, agent type of it, correlation flag of it) of bes computers whose (name of it as lowercase starts with "ip-10-174-8-59")

ip-10-174-8-52.8844.redacted, 3764596660, Native, True

In the WebReports UI, I get a single computer that has both native agent and proxy computer properties, but the computer ID, Computer Name, Agent Type, etc is that of the proxy agent, not the correlated computer.

Shouldn’t WebReports return the correlated device as the primary result such as the BigFix Console, WebUI and the session relevance does?

[ageorgiev]

To be honest I never really noticed this and now that you’ve mentioned it - maybe it should be displaying the ability to actually view the children records (Native & Proxy) in Web Reports. That said, I confirmed WR does display the correlated record and when I say correlated I mean the “parent” record as it has all the data from both records. Pay attention to the “ID” property you have in your screenshots as it’s easy way to visualize it.

As far as the session relevance, will default to correlated devices (again, like WR the “parent”) and you would only see proxy records IF you have machines that are uncorrelated for whatever reason BUT you can tweak it to display the actual children records if that’s what you want. Try this:

(name of it, id of it, agent type of it, correlation flag of it) of bes computers with extensions whose (name of it as lowercase starts with "ip-10-174-8-59")

OR you can do it in a nested fashion within the parent record, you can do it this way too:

(name of it, id of it, agent type of it, correlation flag of it, (if (exists management extensions of it) then ((id of it as string, device type of it, name of it) of management extensions of it) else ("N/A","",""))) of bes computers whose (name of it as lowercase starts with "ip-10-174-8-59")

[cstoneba]

That is true for session relevance and works. But for WebReports UI screenshot above, why does it only return the 1 device as proxy?

Update: I was testing this again and I got the same WebReports UI result as my screenshot above. I then added the Agent Version, Agent Type and Agent Installed columns and then it changed the result to show the correlated computer. It’s as if it loaded some new data and now it won’t show me the proxy computer. Correlated device is the expected result but I cannot explain why only the proxy was showing up early.

[ageorgiev]

I think this is the current design of Web Reports (just how it works unfortunately). I am seeing the exact same thing on my side. I would agree with you that it really should be displaying it better/similar to console & WebUI but unless you raise it officially as case (or it may even need to be RFE), don’t think it will change.

[cstoneba]

I’ve opened a support case with HCL.
thanks

[cstoneba]

Is it just my setup or has anyone else noticed that session relevance queries against WebReports or against the Root API:52311/api/query returns only the Proxy agent computer for Non-Master Operators but a Master Operator gets back the Correlated computer and the proxy computer when issuing the call (name of it, id of it) of bes computers with extensions whose (name of it starts with "xxxxx")

This is causing issues with our automation because a non-MO account is used to get back computer information and now that it is only getting back the proxy computer, it obviously doesn’t have all the property values the correlated or native computers do.

[ageorgiev]

That’s not what I am seeing, I get back both Native & Proxy with or without NMO. I guess go down the list of standard things to check:

• What permissions does NMO account has? Can it see the correlated devices?
• In some case the Native & Proxy records do NOT have the same names, so are you sure if you are using “name” filter that you are NOT filtering out the “Native” record?
• What is permission propagation set-up on the Plugin server? _BESPluginPortal_ManagementRights_MinRefreshInterval

That aside, what exactly are you trying to achieve (what is your use case)? If we are producing specific reports using custom properties I would just filter out ANY “Proxy” records by default (I wouldn’t even care to dig into “bes computers with extensions” because just “bes computers” will give me the top/parent level correlated record that has the data and from there filter out ANYTHING that is “Proxy” at that level: bes computers whose (agent type of it = "Native").

[cstoneba]

I have automation that (with a non-MO account) gets back property values of bes computers by hitting RootAPI:52311/api/query. It has worked fine until now when I have enabled the cloud plugin. Now I only get back the proxy. The non-MO is granted access to All Computers but it doesn’t return a computer result in a query targeting bes computers or bes computers with extensions with hostname containing xxxx or even computer ID = xxxxx.

I am running BES infrastructure v10.0.6.
example:

I run this query: (name of it, id of it, agent type of it) of bes computers with extensions whose (name of it starts with “ip-10-0-148-84”) against :52311/api/query?output=json&relevance=

1. returns this for a non-master operator:

{
“result”: [
[
“ip-10-0-148-84”,
1624909558,
“Proxy - Amazon Web Services”
]
],
“plural”: true,
“type”: “( string, integer, string )”,
“evaltime_ms”: 268
}

2. and returns this for a master operator:

{
result: [
[
“ip-10-0-148-84”,
1624909558,
“Proxy - Amazon Web Services”
],
[
“ip-10-0-148-84”,
3772393206,
“Proxy - Amazon Web Services”
]
],
plural: true,
type: “( string, integer, string )”,
evaltime_ms: 266
}

However, the correlated ID returned from MO says the type is proxy but from the Console, it says Native. It’s very odd.

Here are the permissions the non-MO has. Are they the same as yours?

[JasonWalker]

If you don’t have a support ticket open yet, I’d suggest opening one. This isn’t the behavior I’d expect.

I’d also check on both the Correlated and Native computer in the Console, and be sure your API account is listed in the “Client Administrators” property. Subscribing to a non-master-operator is an Action that has to run on the client, and if this is a new operator or a new computer, it’s possible the action hasn’t run yet to assign the operator account on the endpoint.

I’d also check in Web Reports that the computer is listed correctly for the API user account (the /API/query REST endpoint is redirected to Web Reports to execute the query and get results)

[cstoneba]

I do have a case open for this.

the non-MO is listed in the Client Administrators property of all 3 computer objects in the Console.
the Non-MO doesn’t have a WebReports account. Calling /query aginst the Root API as the Non-MO has the Root internally issue the session relevance call against WebReports.

bigfix dev environment (working as expected):
MO:3 computers (correlated, native, proxy)
non-mo:3 computers (correlated, native, proxy)

bigfix prod (broken):
MO:2 computers (both reported as agent type of Proxy)
no-mo:1 computer (proxy)

[cstoneba]

I removed the datasource from WebReports and re-added it and now the WebReports UI and session relevance queries return the correlated computer as expected. I’ll still work with HCL on the opened case incase there is a bug in v10.0.6