As you all know, VSX R65 is out of support, and VSX R67 is about to be. Check Point is recommending customers to move to R7x versions as quick as possible. Here are some tips about the migration procedure:
1. Remember - there is no upgrade in place. To "upgrade" VSX one has to re-install with the clean target version and to run vsx_util upgrade/reconfigure on MGMT part.
2. Run lab trials of vsx_util part of operation. In every second case of my VSX upgrades MGMT part of migration fails or hangs. If this happens to you in production, you are doomed. Replicate your SMS or MDM in the lab and run vsx_util upgrade. Correct all the error on the way, if necessary.
3. Use multi-step upgrade on MGMT side, if you skip a version. In my practice, running vsx_util upgrade R67 -> R75.40VS and then again R75.40VS -> R77 is much safer than just going all the way up. In most of the cases vsx_util just hangs for half an our and then fails, if version is skipped.
4. Take extreme caution if you are going to replace your old cluster with new HW. In case of replacing open servers with Check Point appliances and vice versa one has to run vsx_util change_interfaces to rename all VSX interfaces before pushing configuration with vsx_util reconfigure to the new machine. In many cases you can successfully rename interfaces with the script, but old interfaces are not removed. If this happens, open VSX cluster object with SmartDashboard and remove them manually before running vsx_util reconfigure.
And the last tip. If you are reading this, and it does not make any sense, read through VSX administration manual and upgrade guides.
MDM and VSX are my favourite products with Check Point, but they are also the most delicate and fragile ones. Any mistake in the process can cost you dearly.
If you are interested, I am inviting all readers to my classroom to MDM and VSX training. We discuss the architecture of both products, best practices with them, maintenance and upgrade procedures. To get more information, send me a personal message here or just use our Training Center enquiry form
1. Remember - there is no upgrade in place. To "upgrade" VSX one has to re-install with the clean target version and to run vsx_util upgrade/reconfigure on MGMT part.
2. Run lab trials of vsx_util part of operation. In every second case of my VSX upgrades MGMT part of migration fails or hangs. If this happens to you in production, you are doomed. Replicate your SMS or MDM in the lab and run vsx_util upgrade. Correct all the error on the way, if necessary.
3. Use multi-step upgrade on MGMT side, if you skip a version. In my practice, running vsx_util upgrade R67 -> R75.40VS and then again R75.40VS -> R77 is much safer than just going all the way up. In most of the cases vsx_util just hangs for half an our and then fails, if version is skipped.
4. Take extreme caution if you are going to replace your old cluster with new HW. In case of replacing open servers with Check Point appliances and vice versa one has to run vsx_util change_interfaces to rename all VSX interfaces before pushing configuration with vsx_util reconfigure to the new machine. In many cases you can successfully rename interfaces with the script, but old interfaces are not removed. If this happens, open VSX cluster object with SmartDashboard and remove them manually before running vsx_util reconfigure.
And the last tip. If you are reading this, and it does not make any sense, read through VSX administration manual and upgrade guides.
MDM and VSX are my favourite products with Check Point, but they are also the most delicate and fragile ones. Any mistake in the process can cost you dearly.
If you are interested, I am inviting all readers to my classroom to MDM and VSX training. We discuss the architecture of both products, best practices with them, maintenance and upgrade procedures. To get more information, send me a personal message here or just use our Training Center enquiry form
