Running patch 4 (released last week) and get:
Anyone else seen this yet?
Case was opened.
Quality Assurance seems to be a lost art these days.
Thank you for reporting it and working with support via a case.
I have not seen other reports of this issue yet.
Same here. FYI - the 11.0.4 Capcacity Scan & Upload is working on physical on-prem hardware, it is failing on virtualized servers (VMware & Azure).
It appears to be mostly Windows boxes. Not sure on the on-prem v. cloud on my end. For me it’s everywhere.
When you have some time, https://bigfix-ideas.hcltechsw.com/ideas/BFLCM-I-317
That would be helpful.
The error is in this block of code. There is an extra ‘if’ inside the relevance susbstitution of the failed line.
// START PUBLIC CLOUDs on Windows - OLD APPROACH!!!
...
Failed if {if ((exists setting "ILMT_SUA_public_cloud_name" of client) and (exists value of setting "ILMT_SUA_public_cloud_name" of client) and not ((exists setting "ILMT_SUA_fixed_processor_rate" of client) and (exists value of setting "ILMT_SUA_fixed_processor_rate" of client)))}
That’s what Grok told me too and I was not sure.
HCL Hint: We should never ever see delivery of action script like this. There should always be checks before any updates are sent.
Perhaps this:
Since there is no If/then/else inside the relevance, I presumed it was extraneous.
It is line 369 of the action script.
Agreed
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Yes, this part was confirmed as incorrect relevance. Team was testing the solution within the lab in the last hours to assure no other issues. Once confirmed the fix will be shared through the support case and the fixlet site will be refreshed as a next step. Thank you for bringing this to our attention. Indeed we need to assure this will not happen again.
2 Likes
What will the version number be of the site with the fix? My “Bigfix Inventory” site is currently sitting at 8.
Running test task sent from L3. I see completed statuses on 871 windows thus far and no failures.
I would say update the site and push version 9.
Was the extra “if” the only issue?
I am seeing rc=2 failed and rc=0 failed (100% failure rate) for Run Capacity Scan and Upload Results (11.0.4.0) on FedRAMP but will have to open a case over there.
The waiting is we try 3 times on the baseline that this task is running in and then fail.
We also have to clone this content because this and all HCL content tries http first and in fedramp, that will fail, hence the idea https://bigfix-ideas.hcltechsw.com/ideas/BFLCM-I-305 and HCL Software - Sign In
HTTPS (Hypertext Transfer Protocol Secure) was introduced in 1994 by Netscape Communications for its Netscape Navigator browser. It built on HTTP by adding SSL (Secure Sockets Layer), later replaced by TLS (Transport Layer Security), to encrypt data between the client and server, ensuring secure communication. The first version, using SSL, aimed to protect sensitive data like financial transactions online.
You would think by now, all vendors would use https as a default, but in this case, we live with the weakness.
Sure would like to know why a status of failed and return code of 0 is acceptable. I think we all agreed in the 80’s when computers and the software running on them would issue a return code of 0, that would be considered a success.
We would like to address the recent issues with fixlet ‘Run Capacity Scan and Upload Results (11.0.4.0)’ that you have been experiencing after updating to version 11.0.4.0. Thank you for all your reports and feedback on this matter.
After a thorough analysis, it appears the problem is multi-faceted, and resolving it will require more time to identify and fix all potential root causes.
To restore correct functionality as quickly as possible and ensure the stability of your environments, we have decided to revert the contents of fixlet ‘Run Capacity Scan and Upload Results (11.0.4.0)’ to the contents from version 11.0.3.0. After this operation the fixlet name will remain ‘Run Capacity Scan and Upload Results (11.0.4.0)’
This action will allow you to resume critical scanning processes smoothly and will give us the necessary time to prepare a permanent fix that comprehensively addresses all identified issues in version 11.0.4.0.
We apologize for any inconvenience this has caused. We will keep you updated on our progress toward a final solution.
Thank you for your patience and understanding.