Bigfix Inventory 10.0.5.0 Bug with VM Manager Deployment Mode

Wanted to get a thread going for informative purposes in case anyone else may be running into this. We previously had BFI setup with a VM Manager in a Central Deployment Type. Post upgrading from 10.0.4.0 to 10.0.5.0 there seems to be an underlying issue/bug that caused the Deployment Type to switch from Central to Distributed. We did notice the below item on the Release Notes

Support for BigFix platform Server Based Computer Groups

    BigFix 10.0.4 introduced Server Based Computer Groups which require dedicated support. If BigFix Inventory import was already run with previous version of BigFix Inventory (lower than 10.0.5) then there is a need to resynchronize computer group definition, for details please see documentation.

We attempted the resync as described to no avail. Our VM Manager is still successfully scanning/operating correctly, however we are unable to manage it.

With that said, we currently have a support case with HCL and will keep this thread updates as we progress with that case.

Hello, do you use Plugin portal?

Hello! Yes, we do leverage Plugin Portal. Seems that is the direction the support folks are going as well. I will say we checked a few items there and the computer IDs all match up via BFI/Console.

Right, the issue will be similar to what I found. Because of computer corelation there are multiple IDs of BigFix server machine instead of expected one when you use plugin portal. This leads to issue with identification of BigFix server machine which is needed to figure out if VMMan is central. Try to remove corelated computer if you can (maybe in test env) and see if that helps.

1 Like

Thanks for the feedback. The VM Manager is still functioning/scanning successfully it’s just that we cannot manage it. We will most likely wait for support to come back to us since the VM Manager is our root BES server and I am not 100% of the ramifications of removing the correlated computer for the root BES server.

@Austin4778, thanks for sharing cause this is extremely concerning cause we have like 900 VM managers, if they break and become unmanageable that will be a nightmare! Please keep us posted.

Btw, looking at the notes for the group resyncing requirement it states “Upgrade BigFix Inventory before you create server based computer groups. If you create a server based group in BigFix Platform before installing BigFix Inventory 10.0.5 or higher, you might need to enforce full synchronization of DataSource Group membership information. Execute the below query to reset the sequence in the BigFix Inventory database”, so it seems that this is something that you need to do ONLY IF:

  • You upgrade Platform to v10.0.4 before upgrading BigFix Inventory to 10.0.5
  • Have created “server-based computer groups”

Just don’t seem to see any relevance between this and VM Manager connections… Did Support confirm that the two are in fact related?

1 Like

@ageorgiev they have not confirmed anything yet as I am still waiting to hear back from them.

The TIp provided via https://help.hcltechsw.com/bigfix/10.0/inventory/Inventory/planinconf/t_setting_up_computer_groups.html is applicable to us as we’ve had server based groups long before 10.0.4 version. We attempted this as well, but to no avail. Ill keep this thread updated as soon as I hear back from support

1 Like

@Austin4778, when they are talking about “server-based groups”, they are talking about the NEW type of automatic computer groups that reside on Root Server only and are not sent to clients. It’s a new functionality that was only released within the Platform v10.0.4 last week, so unless you had some kind of pre-release/beta version with that functionality OR you upgraded the Platform immediately and started creating such groups, you really shouldn’t have such groups…

image

2 Likes

Thanks for the insight. Either or, our issue still remains with BFI VM Manager switching from central to distributed.

1 Like

@Austin4778, not sure if you got this response through Support yet but I got it from our Lab Advocate. The issue is caused by Plugin Portal only in the event if the BES Root Server itself has a proxy record, In our case that is not the case - we have the Plugin Portal but it runs only plugins for public cloud, not for VMware. According to the information, the official fix will be in 10.0.6 but I am sure they will continue to work with you to see how to fix the issue in the interim.

1 Like

@ageorgiev they actually just came back wanting to setup a webex for tomorrow. I’ve informed them of your previous comment. Greatly appreciate your feedback here!

1 Like

Just got off the call with the support folks… our specific issue is in-fact tied to the correlated computer ID of the VM Manager endpoint. We were able to validate by looking in the sam.vm_manager_tools table within the temadb database. We updated the “is_central” value for our VM Manager Tool and were able to successfully add, edit, and test our existing VM Manager. This is a temporary workaround as after a import the VM manager table is switched back to the previous value… As every environment is unique in itself, support HIGHLY recommends that you open a support case if you are dealing with this issue.

With that said, support did state there is no formal fix/defect for this particular issue yet. I will be keeping the case opened and when a formal fix/defect article is provided I will update this thread.

3 Likes

FYI - HCL has posted a defect article for this.

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0092644

1 Like