This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

EOC, SWQL AgentManagement tables not accessible to EOC

 I left any custom properties out for the example:  How can I get this information in an EOC report. in 2020.2  This SWQL query works at the Orion Server level.

SELECT
N.NodeId
,AMA.Name
,AMA.AgentVersion
,AMA.AutoUpdateEnabled
,AMA.RuntimeOSDistro
,RuntimeOSVersion, RuntimeOSLabel, OSLabel
FROM Orion.AgentManagement.Agent AMA
Inner JOIN Orion.Nodes N
ON AMA.NodeId = N.NodeID
AND AMA.OrionSite.SiteID = N.OrionSite.SiteID

I understand that when I scroll through Orion.AgentManagement.Agent  using SWQL studio the information is empty at the EOC level because the EOC does not have Agents.

  •  - unfortunately from a look at the Agent Management schema that data is not federated as of yet and therefore not possible to query from EOC.  We will take this as a feature request. Can you elaborate a little on your use case and the report you are trying to obtain just so we are aware of the end goal?

  • Thank you for your response. 

    At the Orion Server layer I have A Dynamic Query Builder Report that gives similar information and I could probably get it all the fields from there. The reason We want this in the EOC. In our Gov't environment, currently, we manage multiple installations of SolarWinds, whichroll up in to the EOC product. We have various modules with more on the way. However, Since the group I am in does not control the server configurations, we often need to explain to various commands, customers and security, why agents are not at the latest versions. We cannot auto upgrade because changing software on another system without authorization is in violation of various security and command policies. Therefore updates and upgrades are scheduled and approved.  If we the agent set to auto update that could violate that directive and get us in trouble. I made that rookie mistake in the past, not a fun week. 

    The number one reason for a server not having the latest agent is .net requirements.  At this time SCM is a near future purchase item but date unknown, therefore in conjunction with the above information  a SAM check using PowerShell gathers the.net version.  These two reports are manually combined. The agent Orion.AgentManagement.Agent federation offers the ability to create command and security a single report, or be part of a bigger  a view.   The .Net report I can do at the EOC.  Additionally federating  Orion.AgentManagement.Agent opens up the possibility for my team to stream line agent checks that we are responsible across the enterprise.  We have several thousand servers with more customers on the way.

    I could live with a roll up tile with numbers ( I forget the widget name), although prefer to have more information.  In my query I did not provide my where statement to filter down because the problem was within federation.

    This is not the first time I have run into a non federated field issue. I wish that all these fields would be federated. We get all kinds of requests, and many fall into this problem as many of the report request are coming from NON IT managers trying to automate various reporting tasks.  I also think we use EOC slightly different then what the intent was, but not by our design, it was how we interpreted Enteprise Console.  I know our representative has a white paper from us on various topics with the EOC, fortunately 2020.2 solved several of those in our development environment (soon to be prod released).

    My explanations are never short.

    I appreciate your time and am willing to discuss in any format.

  • Great feedback - and appreciate your use cases as well. Getting more data federated and more management and monitoring of the remote Orion Installations are certainly critical items we hope to accomplish.