A useful solution should solve a specific challenge, so let’s first look at the challenge.
One of the most important components in BigFix is the Agent which is installed on the devices you want to manage and can remediate the configuration that is not in line with the target. The Agent can also figure out the configuration of individual devices. Let’s say you are a VMware user; with the introduction of the Plugin Portal (and the Proxy Agent earlier to that), you query the VMware hypervisor and view all the VMs in BigFix. You can also see the status of VMs and other properties directly on the BigFix Console without having to hop through multiple interfaces.
Now here comes the challenge: if you have a VM in vSphere with the BigFix Agent installed on your Console, you will see an entry coming from the BigFix Agent and another one coming from the Plugin Portal. However, both the entries are simply different aspects of the same VM! The difference is just that the BigFix Agent reports the status as seen from within the VM, while the Plugin Portal reports the status as seen from a hypervisor perspective – you still find two distinct entries on your devices list.
What if there was a way to group such devices together to make it obvious that they are simply the same entity seen from two different points of view? That’s where the “correlation” feature introduced in BigFix version 10 comes into play! The Correlation feature helps you identify that two entries are from two different views of the same entity and group them together.
The “virtual device” aka correlation device
A group of devices representing different views of the same entity is shown as a “virtual device” with its own ID that you can use as you would do with any other device on the Console or REST APIs.
For example, the following screenshot shows the correlation device and its multiple representations:
This is called a “virtual device” because it acts as a normal device but aside from its Computer ID, it inherits all its properties from a member of the group. It is not tied to any real BigFix Agent or entity discovered by the Plugin Portal. Hence, when you query the value of a property of a correlation device, it returns the first available value from the various representations. “the first available value” implies that there is an order of some sort. The significance of a representation is controlled by the author of the Plugins in the Plugin Portal and is represented by a number - the lower the number the more important the representation is.
As of today, all you have to remember is that the native BigFix Agent has the lowest value, so if in a correlation device there is a native representation, most of the properties are inherited from it. This mechanism of priorities was put in place keeping in mind future cases where there might be situations in which OSs do not allow processes to have all the control that the BigFix Agent now has and it would be better to consider the MCM representation the most valuable.
Nothing is changing behind the scenes
All that the Correlation feature does though, is to help you recognize that multiple representations of the same entity exist and group them together. In BigFix, the “client” component is the one that “decides” most of what should happen, be it a native BigFix Agent or a proxied device coming from the Plugin Portal. If a condition expressed as a relevance should return true or false is always decided by the client; the same holds true for the membership in an Automatic Group or a site subscription based on relevance.
The Automatic Group is one place where this is more evident than the other. Given the “client” component can decide if it is a member of an Automatic Group or not, what happens if a group is created where the membership relevance is something that only the native representation can evaluate to true? Let’s look at this scenario with an example:
You implement a tagging mechanism where you write a tag in a text file and you create an automatic group based on the content of the file. The group would be something like the following:
The definition can be evaluated only on the native representation because you need access to the file system which only the native representation has right now. So, how do correlation devices behave with regard to group membership? Simply as earlier - only the representations reporting as having the membership relevance evaluating to True will be members of the group. In this particular case however, it would mean that only the Native representations will be part of the group.
The following picture shows an example:
The correlation device is still visible because from the point of view of the operator in the deployment, the correlation device exists but in the specific view of the group, only the native representation is shown as part of the correlation device.
How about Actions?
A correlation device accepts actions but dispatches them to a representation that can actually perform the submitted Action. For example, let us consider a correlation device which is composed of a BigFix Native Agent and its MCM representation. When you do a Take Action regarding the application of a profile targeting the correlation device, the server parses the action and see that only the representation coming from MCM could perform it and dispatch the Action to the Plugin Portal to be run.
Instead, if an Action regarding the deletion of a file comes in targeted at the correlation device, the server dispatches the Action to the Native representation because it is the only one that can perform the specified commands.
When in doubt, the Server dispatches to the first representation in the order of priority which at least for now, is the Native representation - which essentially means, you’re still in control!
We can hear you say “Hey I’m an operator managing my deployment. I want the tool to assist me not to decide for me!”. Fret not, this is just another efficient way of interacting with less friction when you have different representations of the same entity. All the representations – the BigFix Agents or the Proxied version coming from the Plugin Portal – are still present and you can address them as you were doing before the concept of “correlation” made its way into the product.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Author
Andrea Cedraro is a staff software engineer working in the BigFix Platform projects at HCL Software. He's been around since he joined IBM in 2015 right after his graduation. He contributed to the development of the device correlation feature to the most part.
Review and editorial credits
Shivi Sivasubramanian is a senior-level technical author and editor with a demonstrated history of working in the technology industry. A firm believer in the magical power of words, she loves helping the community deliver expressive, minimalist, and user-friendly content. Shivi currently leads a team of information developers in BigFix.