Upgrade of r80.30 management to r80.40 - disk space

[iancollins]

Hi,

I recently asked some questions on how to do our cluster upgrade (R80.40 upgrade on Checkpoint management and firewalls).

Based on the answers, I am tossing up between a clean install and an in place upgrade.

Our cp management is on a virtual machine - which I have snapshotted in vmware.
Before I inherited it, I think it has been upgraded through quite a few versions... as opposed to having clean installs done.

For the in place upgrade, I have insufficient space to proceed..  

 

I can increase the volume size - but I don't think that the correct way to proceed in this case.   ????

and for both options, I'm not sure how to proceed with the migrate export?

The "CP_R80.30_Installation_and_Upgrade_Guide" says to,
cd $FWDIR/bin/Management Server Migration Tool/
./migrate_server export -v R80.30 [-l | -x] /<Full Path>/<Name of Exported File>.tgz

I don't have this folder or command on my machine?

Can someone advise on how I should proceed?

Thanks, Ian

[Vladimir]

No questions, the fresh install and migrate import is the option you want to take.

Follow the sk135172 instructions to export. Migration tool packages are on the same page.

[iancollins]

Thanks.

So... 

$MDS_FWDIR/scripts/scripts/migrate_server export -skip_upgrade_tools_check -v R80.30 /var/log/migrate_export_r80.30.tgz

The export operation will eventually stop all Check Point services (cpstop). Do you want to continue (yes/no) [n]?

Please excuse my paranoia (and ignorance) but... 

1. It is just the cpstop on the management server isnt it? - i.e. its not going to shutdown the cluster members? (probably a dumb question - but there are 200 people accessing the firewall). 
   
   
2. I then create a new VM of required size,
   • install the R80.40 management server
   • copy the tgz export file
   • and then run,
     
     $MDS_FWDIR/scripts/migrate_server import -skip_upgrade_tools_check -v R80.30  /var/log/migrate_export_r80.30.tgz

Ian

[Vladimir]

The process only stops check point services on the management server.

regarding the -v switch in this command: it is referring to the the target version.

After successful export, shutdown the old VM and keep it on ice until new one is proven stable.

Create new VM with ample resources and install new version of management server using IP and the hostname identical to the source.

Import

If error is encountered, download the import log file (you should be prompted with the location and the file name)

Reboot

Connect to it from new version of SmartConsole

Check if all is well

If not, kill the new VM and bring the old one back online.

Caveat: this is a new upgrade mechanism and I had no chance of going through it myself yet. Please read sk163814 and have it saved for references.

[iancollins]

Is there a preferred way to migrate licenses from the 80.30 to the .40 server?

I've created the r80.40 box and set it as a management server (same ip and hostname). The instructions say to install the licenses.

So it looks like I can download our service contract from the usercentre.

Or

on the r80.30 smartupdate, export all the licenses to a file and then import into r80.40.

Can you advise on whats the best way?

Thanks, Ian

[Vladimir]

Migrate import, the older method, was dragging the licenses with it.

I have just run the lab upgrade from 80.40 to R81 with evaluation licenses and, when I have attempted to re-attach the centralized gateway license (one tied to the management servers IP), got:

Trying to install license on CPGW ...

Operation failed. License is already attached

Still, if you have a moderately clean license environment, it would be prudent to export the licenses from SmartUpdate until we are sure how this new migrate_server export/import process works.

Do the cplic print in your R80.30 and repeat it in R80.40 to compare after import is completed to see if the licenses were included.

Even if you do not see them there right away, wait for a few minutes to check again, as your management server may vacuum them from the UserCenter on its own, if you have enabled the communication with CheckPoint during the FTW.

Contracts you can always re-download from the UserCenter.

BTW: the new import is not a speed demon: Just completed a small lab import on 4 core 8 GB VM and it took half an hour:

[iancollins]

Hi - I continued with the import and the licenses now match. (thanks so much for your help!!)

If I may ask one more question and I'll stop bugging you.  

We have a check point log server VM  (smartview) which is also on 80.30... would that be the same deal (create new vm, export and import) ?

Or is that simple enough to just do an upgrade on?

[Vladimir]

Happy to help.

Generally, unless there are compelling reasons for keeping the old logs and if you are running log servers and SmartEvent on VMs, my recommendation is to simply shut them down, rebuild anew, re-establish SIC and start using those.

That being said, 80.30 to 80.40 i a minor version upgrade and you should be able to perform CPUSE upgrade in place.

Download the 80.40 using CPUSE "Recommended packages" on VM, run the upgrade verifier.

If it does not complain, you have an option of in-place upgrade.

If you have some customization that worth keeping (log exporters, custom reporting and notifications, etc..), try the upgrade.

You can snapshot the VM beforehand to fallback if necessary.

Just remember that once upgraded, you'll have to change the version in the Log Server object and install database (from Global Properties). Same goes for the fallback.

If your VMs reside on NFS, do not keep the snapshot for long: the performance will deteriorate.

One more thing: If you do decide to go with the fresh VM, do Gaia "save configuration" <filename> on the old VM and download it using WinSCP.

Shut it down and build a new one, replicating FTW steps to get the same result as the old one.

Once the new one is deployed with the same IP and the hostname, transfer the saved Gaia config to it using WinSCP. Load the saved Gaia config using this procedure:

In clish:

set clienv on-failure continue

load configuration <filename>

set clienv on-failure stop

save config

to get the OS-specific settings transferred.

Change version in the object properties

SIC

Database Install

Policy install

Once again, This does not preserve logs, custom reports, forwarders, etc...

[iancollins]

Thanks again... looks like its the fallback new VM...

 No problems.