Merging two SmartCenter servers, quick HOWTO

Sometimes customers want to merge two or more SmartCenter servers into a single management server. The reasons for that are usually operational. I can't say I am a fan of this idea in general, but let's face it, from time to time we have to do something we do not like.

So, here is the way to do it right.

You will need:

• Two SmartCenter Servers - provided by customer
• VMware workstation or ESX server - find it yourself
• Check Point installation media or ISO files and HFA files - download them in advance from Check Point site
• Standard evaluation licenses (optional) - ask you partner

You will NOT need:

• tools like ofiller or Confwiz. Wee will only use one classic Check Point DB utility

Things to take into consideration before you proceed:

• SMC server versions. 

If servers are on different versions, you need some additional steps on the way. The best is to have them on the same version and HFA level, if possible.

• Local users and user groups. 

They cannot be merged. Ones on the target machine will remain. The source machine's users and groups will be lost. Choose your source and target wisely, because you will have to recreate these settings manually.

Users and usergroups are merged by using fwm export and fwm import commands on the source an target SMC servers respectively. Thanks to Tore Solberg for pointing this out on LinkedIn.

• VPNs

You will have to tune both Site to site and Remote Access VPN definitions during the migration. basically, keeping VPNs intact in many cases even more difficult then taking care of the users and groups.

Migration steps:

• Backup everything. Then backup again.
  
• Prepare DB export files on both SMC servers with upgrade_export
  
• Install two new SmartCenter servers on your VMware. Choose any IP address you want. Use exact versions of your actual machines, so you could import DB later without any issue.
  License them with evaluation licenses, if you cannot use actual production IP addresses.
  
• Import two databases on both VMware machines using upgrade_import. Check they are running, and you can connect to them with SmartDashboard without any problem.
  It is important you have both servers functional before you start messing around.
  
• Now it is a good time to decide who will be the target machine, and who is to be source.
  It is all about complexity. Less FWs managed, less users defined, less policy packages configured. In some cases customer says you in advance, which SMC will be decommissioned. Choosing the right approach is important because you will have to redefine manually all local users and user groups from source SMC.
  
• On target SMC prepare the files. You will need to copy Objects_5_0.C file to a certain folder. Then use cm_merge utility to export all policy packages you need. Usually there are more of them, so consult with your customer about things he wants to keep.
  
• Copy these files (DB file and policies) to the target SMC. Use the same cp_merge to merge the objects. Then use it again to import all policy packages. Easy, right? By the end of this step you should have in on your VMware one operational SMC with merged objects databases and all necessary policy packages. Reminder: users and usergroups should be created before this step.
  
• Export DB from this machine with upgrade_export utility. On this point you are done with labs and simulation, it is time to change your production systems.
  
• Import DB prepared in the previous step to your target production server. Run regression tests. Its own FWs should continue sending logs. SIC should work, you must be able to push policy on those FWs.
  
• Now it is time for more interesting task. You already have FW objects from your source SMC, but they are not responding. Reset and re-establish SIC with them. Voila!
  
• Take care about VPNs. Tune communities, change all needed parameters. It might not be as easy as it sounds, but it is not different from building a new VPN system, so you will manage.
• Once you have all GWs operational, all VPNs up and all logs coming, it is time to clean your database. Remove old source SMC object from it and, if necessary, double objects.

Please let me know if you have any further questions.

Stay tuned.