Upgrading Standalone SMS

[ma_gorkhali]

Hi All,

Planning to upgrade CheckPoint standalone SMS from R81.20 to R82 .

What is the best way to do it ? 

Upgrade directly from the GUI or do an advanced upgrade ? 

We are managing Maestro + SGW running VSX as well one standalone oepn server.

and also for backup system backup and snapshot I believe should be more than enough ?

Thank You !

[Tal_Paz-Fridman]

Hi

When you use the term "Standalone SMS" are you referring to a machine that is just a single Security Management Server? Reason I am asking is that the term Standalone also refers to a machine running a Management and a Gateway.

I would start by going over the R82 SK:

https://support.checkpoint.com/results/sk/sk181127

Go to - Downloads and Installation section

I would also follow all the best practices in R82 Installation and Upgrade Guide:

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_Installation_and_Upgrade_Guide/Con...

[ma_gorkhali]

It is standalone management server 

Also one more thing

Thank you Vincent for replying back. I was told by a PS to do as an advanced upgrade.

Since the new server needs an IP for SSH and file transfer, should I:
- Build it with a temporary IP, perform the import, and then switch to the production IP during cutover?
- Or should the old management server be disconnected from the network from the beginning so I can use the same IP?

What is the recommended approach/best practice?

Thanks in advance.

[simonemantovani]

Hello

I spoken with some Check Point PS in the past, and some of them prefer the advanced upgrade; so you'll use migrate export to export all the configuration and database, perform a fresh install of a new management server in R82 and the import everything exported.

But using the CPUSE is more or less the same, because even during the upgrade with CPUSE, a migrate export is performed; in this case you don't have to create a new management server but everything happens in place.

As I told you, some PS prefer Advanced Upgrade; I usually performed upgrade using CPUSE (because in my case, I'm not free to create new VMs to install R82 from scratch) ... If, in your case, is easy to create a new management server in R82 with fresh install then you could follow the Advanced Upgrade procedure (in any case ii could be a good exercise).

[WarrenJ1]

@simonemantovani Have you compared the downtime and rollback options between the Advanced Upgrade and CPUSE methods to determine which approach minimizes risk for your environment?

[simonemantovani]

Honestly I never compared the downtime between the two methods; with CPUSE method, if it fails it revert to the previous version (R81.20).

Every time I performed an upgrade, I always performed a VMware snapshot of the management (because it was a virtual server), just to quickly rollback.

In the past I performed an upgrade using CPUSE for an MDS with 17 domains and several thousands of objects and it took about 5 hours to complete the whole procedure (migrate export, upgrade, migrate import).

[ma_gorkhali]

Thank You for replying

Since the new server needs an IP for SSH and file transfer, should I:
- Build it with a temporary IP, perform the import, and then switch to the production IP during cutover?
- Or should the old management server be disconnected from the network from the beginning so I can use the same IP?

What is the recommended approach/best practice?

[PhoneBoy]

It's safe to perform the import on a system with a different IP.
Nothing will change on gateways until policy is pushed.

[the_rock]

I usually do it from web UI, just make sure to expect database transfer to take some time.

[Martijn]

Hi,

Make sure you are using the latest version of the Deployment Agent and migration tools.
I always perform a verify of the database so I can fix any issues before upgrading.

I would perform an advanced upgrade when the SmartCenter has gone through a lot of upgrades and hotfix installations.
If this is a fresh R81.20 installation with some hotfixes, you can choose to do a CPUSE upgrade.

Martijn

[Vincent_Bacher]

I would always and without exception opt for the Advanced Upgrade (using export and import to a new VM created from scratch) and wouldn’t recommend anything else. Especially if you’re running a management system on VMware, it’s the only option in my view.

[ma_gorkhali]

Thank you Vincent for replying back. I was told by a PS to do as an advanced upgrade.

Since the new server needs an IP for SSH and file transfer, should I:
- Build it with a temporary IP, perform the import, and then switch to the production IP during cutover?
- Or should the old management server be disconnected from the network from the beginning so I can use the same IP?

What is the recommended approach/best practice?

Thanks in advance.

[Vincent_Bacher]

This is the procedure I've used reliably across multiple customer environments during my history at solution providers. It keeps your production environment untouched until the very last step.

Preparation

1. Perform a migrate export on the production management system, then implement a change freeze (using the pre-upgrade verifier, etc.).
2. If not already in place, create a dummy VLAN (switches) in VMware, running completely separate from the production environment.
3. Copy all necessary packages to a Windows VM + transfer the migrate export from the production Check Point management to this VM + install SmartConsole on the VM.
4. Connect this Windows VM to the dummy VLAN, configure an IP from the same management subnet as the management interface of the Check Point management.

Build & Validate the New Management Server

5. Create a new VM for the new Check Point management system, connect it to the dummy VLAN.
6. Run the First Time Wizard and use the same attributes/configurations as in production.
7. Install Jumbo HFA and, if necessary, the private hotfix.
8. Connect to the management system using SmartConsole from the Windows VM.
9. If this works, close SmartConsole and transfer the migration export to the new management system.
10. Perform migrate import.
11. Reconnect to SmartConsole and visually check the policy packages.

Cutover to Production

12. At a suitable time, either shut down the production management system or disconnect the network connection of the management interface.
13. Change the network connection of the management interface from the new management server to the production VLAN.
14. Reconnect to SmartConsole, perform a visual check, test policy installation, test logs – the usual checks.

Tip: The beauty of this approach is that you build and validate everything in an isolated environment first. Production stays untouched until step 12, and your rollback is simply powering the old management back on.

I hope that helps, and I hope my memory hasn’t let me down, because at my current workplace, a colleague always does this in collaboration with Check Point PS, and I haven’t done it myself for a while.

[Oliver_Fink]

I think, that is the best way to do it.

But if you do not want to build a twin VLAN, this is what I would do:

Get 2 additional IPs (IPb and IPc) in the SMS LAN with actual SMS (IP: IPa).

1. Set up a new SMS on IPc.
2. Verify with Migration Tools on old SMS (IPa).
3. Fix problems on Old SMS (IPa).
4. Export with Migration Tools on old SMS (IPa).
5. Transfer data to new SMS (IPb)
6. Import with Migration Tools on new SMS (IPb).
7. Do some Tests on new SMS (IPb). Maybe try "Install Database" in SmartConsole after you changed the IP of the SMS object to IPb. DO NOT INSTALL POLICIES! But you should see the state of the VSes in SmartConsole. Remember to change IP of SMS obejct back to IPa before next steps.
8. On old SMS (IPa) do "fw logswitch; cpstop" to rotate actual log away from "fw.log" to log with time stamp.
9. Change old SMS (IPa) to a new IP (IPc).
10. Change the new SMS (IPb) to a new IP (IPa).
11. Do an "Install Database" in SmartConsole if you changed it in Step 7. It is not wrong to do that in any case.
12. I would recommend to install all Policies step by step to the VSes with intensive testing.
13. If errors occur you can still switch back to the old SMS with switching new SMS back to IPb and old SMS back to IPa.
14. Otherwise transfer logs from old SMS (IPc) to new SMS (IPa) if you do not use separate log servers.
15. Initiate log indexing following sk111766 and undo the settings if indexing is finished.
16. Delete the old SMS (IPc) after some days if everything works fine.

[Vincent_Bacher]

Exactly. But setting up a new VLAN/Switch in vCenter is just a matter of a few clicks. It doesn’t need to be accessible from the outside, so there’s nothing else to do. You just use the VMs via the VMware console. 😊

But of course, your to-do list is spot on. 👍