Upgrade Experience: Log Server & Management Server from 81.20 → R82.00

[Fabien88920]

Hi everyone,
We recently upgraded our Log Server and Management Server from 81.20 to R82.00.
Has anyone else done this upgrade? Any issues or best practices to share? 

Anyone Upgraded to R82.00? Looking for Feedback

[the_rock]

I did that in the lab few months ago. Did not see any issues at all, went very smooth, no problems. I did generate show config and backup prior, yes, took some time for the upgrade, because after reboot, it still needed to "reimport" all the database etc, so whole process can take 2-3 hours, so you would need to be patient. I recommend to do it either on the weekend or later at night, just to be on the safe side.

Otherwise, just install recommended jumbo as well.

Thats my honest advice.

[Bob_Zimmerman]

I personally do management upgrades and updates during the business day. I want them stable on weekends and at night in case I get paged to deal with some weird issue, but my team is usually fine being unable to stage new changes for a few hours. 😉

And yeah, management updates (installing a jumbo) are normally very fast, but management upgrades (like R81.20 to R82) take a long time. I've had an MDS take over six hours to upgrade before.

[the_rock]

I get your logic...its just sometimes even though its management, better be safe than sorry 🙂

[Bob_Zimmerman]

From my perspective, doing the upgrade during the day is the safer option.

We even do some firewall upgrades during the day. The logic there is the upgrades are too important to do while sleep-deprived. We want everybody sharp so any issues are noticed quickly and we can figure out what's going on. Sleep deprivation affects thinking and judgement on par with being drunk. We would never consider requiring admins liquor up before a change, so why would we require people to be up for >20 hours straight before changes?

Doesn't work for everybody, but it sure works for us.

[the_rock]

In my experience, it really depends on the customer. Just to always be on a cautious side, we always recommend doing this after hours.

[Vincent_Bacher]

We are an end customer, and we are not allowed to upgrade our environment (which includes 4 MDS and 9 MLM) on a weekday — nor would we do so even if it were allowed. 🙂
We usually do that on weekends. First weekend MDS and weekend after MLM.

[Alex-]

Totally. And you get direct feedback from the business and can direct resources where needed more easily than calling on-duty teams left and right, or finding out the next working day.

[Duane_Toler]

There is one issue on a management server I have encountered several times now:

You need to make sure you have the IPS CRC marker file.  If this isn't present, the pre-upgrade verifier will tell you in the report, but if you are doing a Blink upgrade then you might not find out until it's too late.  The file is $FWDIR/conf/SMC_Files/asm/crc_marker_db.fws.  This is (now) covered in sk175089: https://support.checkpoint.com/results/sk/sk175089

If the file does not yet exist for some reason, you can create the zero-byte file as discussed in the SK.  If you ignore the verifier warning and proceed with the upgrade, the database import will fail and your R82 server will be destroyed; you will have to start over with the R81.20 source.  Be warned!  (i had this happen to a management server, learned the hard way)

Otherwise, gateway upgrades have gone well thus far, and other management servers have also gone well (after accounting for the above warning).  Post-upgrade, R82 has thus far performed rather well, which is what I expected.  Kudos to R&D on this one!

[the_rock]

Definitely good advice...personally, never had that issue myself.

[Duane_Toler]

Good!  You don't want to endure that. 🙂 Thankfully I was doing the advanced migration for the customer, moving to a new Azure CloudGuard server, so I had the original source host still available.

[the_rock]

Yea, guess depends on the actual process 🙂

[Bob_Zimmerman]

We upgraded all of our managements and log servers from R81.20 to R82 about a week after it became the generally recommended version. A few false starts with Blink cost us several hours. When we switched to a two-step upgrade (upgrade to the major version, then update to the jumbo as a separate step), it worked. Our management environment is four MDSs (two HA pairs), four MLMs, four SmartCenters, and two log servers (two of the SmartCenters aren't big enough to need separate log servers).

We've also upgraded eight clusters to R82 with a ninth in a few days. Those have gone smoothly.

[Tomer_Noy]

@Bob_Zimmerman - can you please share what issues you encountered with Blink?

I'm glad that eventually the upgrade worked for you in two steps, but I want to make sure that the Blink option will work as well.

[Bob_Zimmerman]

It just failed with no message. I tried it on three managements: a SmartCenter+log server, a SmartCenter which doesn't handle logs, and a log server with no policy management. No secondary managements in either environment. All three ground for an hour, then failed and took me back to R81.20.

[Gregory_Azratz]

Hi @Bob_Zimmerman ,

if by any chance you have the logs from the failed attempts or a way to reproduce it - it will be great
We would like to investigate this and hopefully find the root cause which caused this bad experience.

Gregory

[CheckPointerXL]

this is something that needs to be clarified

into admin guide is stated only that management needs to be upgraded first of all

but in my experience, update it + install a jumbo on top, and then try to update a log server it triggers a failed upgrade on log server (Automatically roll back to previous vesrion)

so it seems that it's correct to say "upgrade first the management ONLY to the major version (no jumbo, no blink) then rest of infrastructure, and then finally the jhfs)

is this confirmed in r82?

[the_rock]

I would agree with that statement @CheckPointerXL 

[Natan_Chamilevs · Accepted solution]

Hi @CheckPointerXL,

My name is Natan Chamilevski, and I manage the team responsible for Management upgrades.

You are correct that the Secondary Management Server / Log Server (including MDS/MLM environments) must be upgraded to the same version and the same Jumbo Hotfix Take (JHF) as the Primary Management Server.

This requirement exists because during the import phase, HA synchronization is performed, and successful synchronization requires that both machines run identical software versions and JHF takes.

In practice, this means:

• If the Primary Management Server has a JHF installed after upgrading to the target version, the Secondary Management Server / Log Server must be upgraded to the same version and have the same JHF installed.

• If the Primary Management Server does not have a JHF installed, the Secondary Management Server / Log Server must not be upgraded using Blink.

There are several supported upgrade paths using CPUSE:

1. Upgrade all Management Servers and Log Servers using Blink via CPUSE.

2. Upgrade all Management Servers and Log Servers to the new version first, and only after the upgrade is completed, install the JHF on all machines via CPUSE.

3. Upgrade the Primary Management Server to the new version and install the JHF manually, then upgrade the Secondary Management Servers and Log Servers using Blink.

For Advanced Upgrade, before running the import operation on the Secondary Management Server / Log Server, it must already have the same JHF take installed as the Primary Management Server (or no JHF installed, if none exists on the Primary Management Server).

The same rules and upgrade paths apply to MDS and MLM deployments as well.

Best regards,
Natan Chamilevski

[CheckPointerXL]

Hi Natan,

thanks for your feedback and to have confirmed that.

I think a (!) Note about avoiding any JHF misalignment during major release upgrades could be helpful in the admin guide

Thanks again and br

[yura_k]

Hi Natan! Could you please tell us does the CRL issue from sk184766 affect the procedure for updating the management server to version R82?

[Duane_Toler]

I can confirm that,  yes, it will.  I did an R81.20 -> R82 upgrade on a gateway this week.  This upgrade was CloudGuard so the Blink image could not be used.  As such, the upgrade was to R82 and no jumbo HFA.  After the initial upgrade, the Gaia deployment agent could not download update packages from Check Point.  I had to manually copy over Jumbo HFA 60, install it, then manually copy over the post-JHF hotfix, and install that.  That made everything work.

In addition to being CloudGuard, this gateway was managed with Infinity Portal Smart-1 Cloud.  This CRL issue also meant that the cloud management service was unable to reconnect until I did the Jumbo HFA and hotfix.

Even though your upgrade is for a management server, be sure you have a way to copy the Jumbo HFA and hotfixes to your host.  If you have R82 gateways with your R82 management server, you need the hotfix on all management servers and gateways (or do the CRL validation grace period extension).

[yura_k]

This week, my colleague complained that he had failed at management server upgrade from version 81.20 to 82 via the CPUSE, because after rebooting, in the detailed upgrade report, some CRL check did not complete for a long time, and then the server rebooted again and Gaia rolled back to the previous version.

[Oliver_Fink]

This could be "sk184766 – Certificate and CRL validation fails from March 1, 2026". R82 and R82.10 are affected.

If this is the case, then you will have to do advanced upgrade. In inplace upgrade you cannot patch within the upgrade process. 🤔

[Duane_Toler]

I you have the option, you could try the Blink upgrade with JHF 60 included, but you still need to install the post-JHF hotfix for it.  Soon, Check Point will have an update Jumbo HFA with this fix included along with a Blink upgrade for gateways and management.

[Ofer_Barzvi]

Hi @yura_k ,
Yesterday we published https://support.checkpoint.com/results/sk/sk184782 about upgrade failure of Multi-Domain Log Server which wasn't seen in other management machines, but suggest to verify that latest upgrade tools (referenced in https://support.checkpoint.com/results/sk/sk135172) are installed on management machines before doing another upgrade.

I also would like to take a look on the upgrade failure that you got , so please email me (or send link to a shared folder) latest /var/log/upgrade-export*.tgz and /var/log/upgrade-import*.tgz from one of the failed machines .

Thanks,
Ofer Barzvi
barzvi@checkpoint.com

[Alex-]

On top of what was already said, if you use VMWare, you might consider an advanced upgrade on a new virtual system. You can then define it as RH8 with Paravirtual which sensibly improve I/O compared to previous versions.

Edit: it's really easy, you disconnected the network to the R81.20 one, create a new VM with these settings, stage it with the same IP, FTW, JHF, import and you're set with better performance.

[the_rock]

Excellent advice Alex.

[Chris_Atkinson]

Further to this please ensure you pay attention to the vNIC type, avoid "flexible" also E1000 support will be ending.

[the_rock]

I always use xmxnet3 in eve-ng.