- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hi everyone,
My name is @Eran_Habad and I’m a manager in Check Point’s R&D. My group is responsible for the core I/S and APIs of the Management Server.
Following several recent conversations with customers, I would like to provide some information and shatter few myths regarding the JHF of the Management:
I’m also tagging @Tomer_Noy, R&D Director of Management Products and @Miri_Ofir, R&D Group Manager responsible for Customer Success & CFG.
All of us would be happy to answer any further questions regarding the Management JHF and to get ideas for improving the JHF adoption and installation.
Regards, Eran
The gateways / clusters can be updated to a new JHF gradually without any dependency on updating the Management / MDS.
You can have gateways / clusters with different JHF builds between different domains, and even within the same domain.
You can have different JHF builds for the gateways and for the Management.
The comment about having the same JHF is only for the Management MDS & MLM machines. If you have multiple MDM servers, you need to have the same JHF build on them.
I hope this clarifies things.
Hello -- Great information. sincere thanks for the post. Note: we in region exclusively use term "HFA" vs "JHA".
topics...
Thanks -GA
Great info! Thank you for sharing.
Please answer this: If I recall correctly, some of the Ongoing JHFAs are required to be uninstalled before the next version is installed. Why not include removal of the intermediate Ongoing JHFA in to the installation logic of the next one?
Regards,
Vladimir
Note that there were some recent improvements in the CPUSE DA JHF installation.
In the past, installing a new JHF involved uninstalling the current JHF in the background. This had several drawbacks such as extra time to perform the uninstall and potentially going back to the vanilla GA if the new JHF failed to install.
Another drawback was that if you installed an private / specific HF that depended on a certain JHF build, we couldn't uninstall the existing JHF in order to install the new one. That was the case even if the private HF fix was included in the next JHF. The customer still had to manually uninstall the private HF to allow the JHF installation to proceed.
In the new mechanism, the next JHF is installed on top of the existing JHF without uninstalling it. This means that if a private HF fix is included in the next JHF, you don't need to uninstall it manually anymore. We will recognize the situation and let you proceed. Also, uninstalling a JHF will bring you back to the JHF you had before, instead of to the clean vanilla state.
This was great work by @Tsahi_Etziony and @Lior_Manor .
The DA is auto-updatable, so everyone should get it automatically (assuming they didn't turn off the auto-update).
Hi Tomer and thank you for this info.
These are welcome changes indeed. I have noticed the DA becoming Auto Updatable or giving us the opportunity to do so from Web UI manually.
As to compatibility with custom or private HFs, this seems to be a work in progress. As per sk113410:
"Future Jumbo takes might include content that will conflict with this Hotfix. Installing such a Jumbo take on a system with this hotfix, will fail with an appropriate error. In such a case, please contact Check Point Support."
Hello Eran,
Thank you for the very clear and informative post.
In my environment I have Multi-Domain Server with R81.20 Jumbo Hotfix Take 41 and so are my firewalls exactly on same version. I have to upgrade Firewalls at least to Jumbo Hotfix Take 65. Good if can go ahead with individual Open Servers one by one but not at once "since you had mentioned above in point 4 - all Management machines to have the same JHF take".
With respect to point no 4 and my organizations Checkpoint environment(pics attached). I have MDS and have around 10 domains in it. But we also have individual Domain Management Servers(Open Sever) in each Domain apart from Gateway and twin Cluster members(2nd Pic).
Now my question is with respect to point 4 - Can I target individual domains ''one by one" and update HF of cluster members and its individual Domain Management Servers(Open Sever) in each Domains to Take 65 ?
And not ALL Management Servers in one go as, the 4th point states that all management machine need to be on same JHF take?
Thanks
MVS
Do you know that you have posted a reply to a post that is 5 years old ? Did you expect any answer ?
Both @Eran_Habad and myself are still in Check Point 😀
(different positions though)
So it's fine, and we'll be happy to answer.
The gateways / clusters can be updated to a new JHF gradually without any dependency on updating the Management / MDS.
You can have gateways / clusters with different JHF builds between different domains, and even within the same domain.
You can have different JHF builds for the gateways and for the Management.
The comment about having the same JHF is only for the Management MDS & MLM machines. If you have multiple MDM servers, you need to have the same JHF build on them.
I hope this clarifies things.
Hello Tomer,
about
The comment about having the same JHF is only for the Management MDS & MLM machines. If you have multiple MDM servers, you need to have the same JHF build on them.
so if have 1 MDM and 1 MLM and 1 SmartEvent, i need to upgrade all of them to same JHF ? any problem if i upgrade only one of them?
Ideally they should all be on the same JHF level.
Whether there are actual problems if they’re not will depend on the nature of the fixes included.
It's indeed recommended to have the same JHF take on all Management machines. With MDS and MLM, it's important because having different JHF takes will not allow synchronization (HA) between machines, including the system domain (which exists on both MDSs and MLMs). Since updating JHF is not instantaneous, you can get by without sync for a short while and the machines will be operational (receive logs, ...), but it's not a healthy state for a long duration.
SmartEvent machines are a bit more flexible and usually will be OK on a different JHF level. That said, it's possible that a certain fix will be important to align on SmartEvent as well, so it's not a general guideline that will always work.
Hi Tomer,
thank you very much for your feedback
I always suspected that some kind of HA stuff happens between MDS and MLM; i was pretty sure about same JHF between two MDS in HA, but not 100% sure for MLM also.
Anyway i think this kind of information should be written in some sk/faq page
thank you again!
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
5 | |
5 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
2 | |
2 |
Wed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasMon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasMon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY