Upgrade steps document says that “during the upgrade, the versions of the different components must respect this rule: server version >= relay version >= client version”
I have several 11.0.4.60 Linux agent talking to 11.0.2.125 server, don’t see any issues.
A) Do you think this is supported?
B) What kind of problem I should expect from running in this configuration (other than that new functionality is unavailable)?
My rationale: 11.0.4.60 supports Red Hat 10, I want to deploy it before upgrading the BigFix server.
Yes, as per the documentation, the recommended approach is to maintain the same version level across components; however, there is no strict technical enforcement that mandates this.
A) From a support standpoint, this configuration is not considered supported. If any issue arises and you engage the HCL Support team, the first observation will likely be the version mismatch between the server, relay, and clients, and you will be asked to align versions before further troubleshooting.
B) Practically speaking, there are usually no immediate functional issues, other than newer features being unavailable on older components. In my experience across multiple organizations, similar mixed-version scenarios have run without problems. That said, there is always a risk of encountering an edge-case or unknown issue, especially during upgrades, troubleshooting, or when using newer capabilities that assume version parity.
We have encountered a similar situation in the past where the Unix team faced permission-related issues with BigFix 11.0.1. After troubleshooting and discussions with HCL Support, the issue was resolved by deploying BigFix 11.0.2 on all RHEL endpoints, even though the rest of the infrastructure (server/relays) remained on 11.0.1. This mixed-version setup functioned without operational issues.
As per documentation, if RHEL 10 is officially supported under BigFix client version 11.0.4.60 (I didn’t validate), then deploying the client ahead of the server upgrade is acceptable.
Key considerations:
Operating systems that are not officially certified may still install and function, but they are not covered under standard HCL Support until formal certification is announced.
Running on an uncertified OS may expose you to edge cases or unexpected behavior, particularly due to OS-level library or permission differences compared to supported RHEL versions.
Also, it is a very common scenario to upgrade some set of clients to the latest version before upgrading the server. Even without OS-enabling limitations, it's always good to test first on some clients that are easier to reinstall if needed.
And when we say some configuration is 'not supported', that doesn't mean that we are ever looking for an excuse to not help. I hate having to say that, but I've seen that in practice from some vendor. In a context like this, all it means is that if you had some problem with the 11.0.4.60 client, communicating to an 11.0.2.125 server, that was caused by some weird edge case or bug that existed in 11.0.2 (note: this is not a real issue as far as I know), then -- we probably would not create a new hotfix for you on 11.0.2; we might ask you to upgrade your server deployment to see whether the issue still exists (if it's something we haven't seen before and cannot recreate on our side); and we might create a hotfix against a higher server version and ask you to upgrade to that release as part of fixing the bug.
In general we like to stay within a major version, (11.x clients talking with 11.x server), or with higher version on the root (10.x or 9.x clients might be the last supported version for some older client OS).