Endpoint client migration from one management server to another using different ip-address

[Bruno_De_Feyter]

Hi,

We are facing the following issue …

We have been setting up a new Management server for the Checkpoint Endpoint as we had to change the VLAN (ip-address) of the server.

We have moved from ip 192.168.176.80 to 10.155.41.12 and have successfully migrated the policy’s and licenses.

We are now facing the issue that the clients who have already installed an endpoint client and which were connected to the old management server (192.168.176.80) are still connected to this old server.

When we upgrade the checkpoint endpoint client version of the client pc’s from older version to newer version, the checkpoint endpoint client on the pc keep on connecting to the old management server (192.168.176.80) instead of the new management server (10.155.40.12).

The endpoint client on the pc is getting upgraded but the ‘configuration’ is not getting changed.

So we are struggling to get our clients migrated to the new management server.

When we deploy the endpoint software to a machine who did not yet have an older client installed.

How can we adapt the old client so they make the connection to the new endpoint management server.

We would like to avoid end-user impact, actions.

Regards,

[G_W_Albrecht]

sk65451: Changing the Endpoint Management Server's IP Address

[Bruno_De_Feyter]

Hi,

I just opened a case for this.

Thanks for redirecting us to 

sk65451: Changing the Endpoint Management Server's IP Address

This in fact not what we are trying to achieve.

We have 2 Endpoint management servers

old = 192.168.176.80

new = 10.155.41.12

Goal is to swap the clients for old to new avoiding user impact like reboots and de & re-installation of the client sw.

We noticed that just doing the ugrape of the client with the package build from new server does not overwrite the actual (old) configuration on the endpoint client and so it still connects to the old server

[Kilian_Huber]

I'm not sure on your statement that "the clients are getting upgraded but their configuration is not changed". How exactly are the clients being upgraded? I mean if you change software deployment policies on the "new" management server and the clients are actually downloading and installing this new version, there is a connection to the "new" endpoint management server - otherwise, the software deployment policy would not reach the clients.

As an ugly hack (if your environment allows this - and I don't know if it works but in theory it should): create a static NAT rule which translates access from the clients to the IP of the old server to the IP of the new server. Clients then should be able to connect to the new server and get the new policy which contains the IP address of the new server.

[Sean_Van_Loon]

Hi, I'm currently having the same situation.

I'm coming from a R77.20 Server, dedicated for Endpoint Management.

And have a new server which is running R80.20, but with a new IP address.

How did you resolve this?

Thanks!

Kind regards,

Sean

[Bruno_De_Feyter]

Hi Sean,

It's just a matter of running the 'reconnect.exe' on the clients.

This reconnect.exe can be build from the new Managment server were a config.dat should be build when a new SW-pachckage get's build exported on the new management server.

With this config file which you should download to a machine were you have installed the smartconsole.

From that machine you should run the 'MakeTool.bat' which then generetaes the 'Reconnect.exe'.

Regards,

Bruno

[Sean_Van_Loon]

Hi,

Thanks for the feedback.

I talked about it with TAC and they discouraged me to move all endpoints to a new mgmt with a new IP due to FDE being used.

They said that there was a big risk that could render each device useless if it failed to connect to the new mgmt.

Thus, I'm now reusing the IP address and hostname out of precaution, but with the down side that you need to swap between the MGMT servers due to IP address already being in use.

What blades did you have activated on your clients?

Thanks!

Kind regards,

Sean