Promoting a secondary SC to be the primary SC

[pnorman821]

Hi All,

I am trying to run through a process to promote the secondary SC server to be the primary SC server in the MGMT HA cluster. This is R80.20 Take 103 on both members.

I have just started the process and have encountered a question/issue:

[Expert@[hostname_of_sec_mgmt_server]:0]# cd $FWDIR/bin
[Expert@[hostname_of_sec_mgmt_server]:0]# ./promote_util
Binding to localhost...Done
Opening database... Failed to open database in R/W mode (Management Server is not active)

Is the above an expected response or is it something that needs to be fixed before continuing?

I know that this is the standby mgmt server in the cluster, later on in the process it asks you to make it the the primary

The procedure  is from the R80 Security Mgmt Administration Guide

Thanks, Paul Norman

[mdjmcnally]

Are you wanting to promote the Secondard SC to be Primary SC or do you simply wish to make the Secondary SC be the Active SC.

They are not the same thing.

You would only normally promote your Secondary SC to be Primary when you have lost the Primary SC and have no Backup that can restore too.

As such when you promote the Secondary SC then it would normally be the Active SC and the Database would be R/W

Your Secondary SC is currently in Standby indicating that you still have a working Primary SC that the Standby can see.

Hence my question as if you want to promote or simply make active.

[pnorman821]

Hi

I definately want to make the secondary SC the primary server and am aware of the difference between active/standby and primary/secondary with regards to MGMT HA. The SC is being moved from one environment/domain to another. Once this secondary mgmt server has been made primary + active and everything is working then the plan is to decom the secondary SC..

My question was mainly around whether the output from running the promote utility is expected or not?

Thanks

Paul Norman

[pnorman821]

The documentation is very low on detail:

Promoting a Secondary Server to Primary

The first management server installed is the Primary Server and all servers installed afterwards are Secondary servers. The Primary server acts as the synchronization master. When the Primary server is down, secondary servers cannot synchronize their databases until a Secondary is promoted to Primary and the initial syncs completes.

Note - This is the disaster recovery method supported for High Availability environments with Endpoint Security.

To promote a Secondary server to become the Primary server:

1. On the Secondary Server that you will promote, run:

   #$FWDIR/bin/promote_util
   #cpstop

2. Remove the $FWDIR/conf/mgha* files. They contain information about the current Secondary settings. These files will be recreated when you start the Check Point services.
3. Make sure you have a mgmtha license on the newly promoted server.

   Note - All licenses must have the IP address of the promoted Security Management Server.

4. Run cpstart on the promoted server.
5. Open SmartConsole, and:
   1. Make the secondary server active.
   2. Remove all instances of the old Primary Management object. To see all of the instances, right-click the object and select Where Used.

      Note - When you remove the old Primary server, all previous licenses are revoked.

   3. Install database.

[pnorman821]

Hi,

I have had some success on this by making the Secondary SC the active SC in the cluster. I was then able to run the promote_util command and the process has completed successfully.

I think this should be documented properly that this step is necessary otherwise the promote_util does not work? The documentation is very low on this detail/

Can I request this to be done?

Thanks

Paul Norman

[mdjmcnally]

As I said you would only expect to be promoting the Secondary SC to be Primary if lost the Primary and no Backup to restore.

At which point you would expect that the Secondary SC would be the Active SC hence most likely why the documentation doesn't state to make it Active.  The presumption being made that if doing this then the SC will already be Active.

So yes what you were seeing is expected behaviour if trying to Promote a Standby SC to be Primary.

If having difficulties then would suggest that disconnect the Primary from the network, so therefore it is not visible from the Secondary.  Thus making the situation where would expect to be promoting a Secondary SC to Primary.

Make the Secondary Active

Promote the Seondary to be Primary.

Relicense Gateways to the newly promoted IP.  Should be licened to Primary SC IP.

Delete references to Orginal Disconnected Primary

Build a NEW Secondary SC at the new Domain/Environment.

Ensure communicating with Gateways

Make the New Secondary SC at new location active

Disconnect the Existing SC at that previously promoted

Make the New SC at the New loctaion Active

Promote that to be Primary

Relicense Gateways to the New Primary IP

Delete References to SC that was the origional Secondary.

You will then be left with a Single SC at the New Location that is Primary,

However someone from Check Point ( I don't work for them ) may see the request and request that it is updated.  Alternatively contact your Check Point Support Partner ( if not using direct support ) and they should be able to request that the document is updated.

[G_W_Albrecht]

Just give that as feedback in the sk114933 !

[Zoltan_Bogdan]

*Sorry for warming up this rather oldish Thread.*

I basically used the described method to move a standalone deployment to a distributed one as also described in sk154033.
What differed from the SK was that after promoting the new mgmt to primary I was able to simply remove the Management Blades from the former Standalone Object while keeping the gateway functions.

What I expected was that after completing Step2 the MGMT HA was removed but it wasn't. The new management server still complains that the old one's missing althoug it isn't a management server anymore.

has anyone done somethin similar?

Thanks
Zoltan

[DDiaz]

Hi.

I had the same issue following the SK sk114933, opened a case with the TAC involved. Looks like this is the expected behavior when you need to migrate R80.x standalone management environment to a distributed environment (sk154033). I can confirm the procedure works OK, but this  complains that the old one's missing is always there. Hope this help you