Harmony Endpoint Upgrade via SCCM Fails - Self Protection Suspected

[Aftermath1]

Hi Team

I'm currently trying to upgrade Harmony Endpoint Security to the latest recommended version using SCCM.

Previously, upgrades were performed through a Deployment Policy from the SmartEndpoint console, but we are now transitioning to SCCM-based deployments.

The upgrade package is being deployed successfully by SCCM, however the actual endpoint upgrade fails. After reviewing the logs and performing initial troubleshooting, there are indications that Self Protection may be preventing the installer from updating or replacing certain Harmony Endpoint components.

My questions are:

• Is there a supported method to temporarily disable Self Protection through a policy?
• If so, which policy settings should be modified?
• Is it possible to disable Self Protection only for the duration of the upgrade and then re-enable it automatically?
• Are there any specific best practices or prerequisites for upgrading Harmony Endpoint via SCCM?

Has anyone encountered a similar issue when deploying upgrades through SCCM?

Any guidance would be greatly appreciated.

Thanks.

[_Val_]

In your case, are you installing Endpoint on Macs? If yes, see https://support.checkpoint.com/results/sk/sk171012

[jorgeluiznim]

Hi @Aftermath1 ,

To answer @_Val_ 's question first: based on your description — SCCM, E88.72 → E89.10, previously upgrading via a SmartEndpoint Deployment Policy — this is Windows, not macOS. That matters, because sk171012 is macOS-only: it documents the cpSelfProtection utility, and that binary does not exist on Windows clients. So if you went looking for it on your endpoints, that's why you wouldn't find it.

On Windows, the supported mechanism is different:

Is there a supported method to temporarily disable Self Protection?

Yes — but it's not a policy setting, it's a Push Operation:

Asset Management > Push Operations > Create operation → Agent Settings → Enable / Disable Self Protection

Supported on Windows and macOS (not Linux). The same operation exists in on-prem SmartEndpoint.

Can it be disabled only for the upgrade and re-enabled automatically?

Yes — that's built in. The operation has three fields: Enable, Disable, and Timeout Command Expiration. Per the Administration Guide: "After the timeout, the command expires, and the self protection capabilities will be enabled automatically."

So you set Disable with a timeout that covers your deployment window, and protection restores itself with no follow-up action. It's also a genuine fail-safe: if an endpoint goes offline mid-window or the deployment fails, self-protection still comes back on its own. (You can also push Enable explicitly to close the window early.)

Best practices / prerequisites for SCCM

• Scope and sequence: in the Devices tab use Custom to target only the group matching your SCCM collection, and send the push operation before releasing the deployment — then confirm it actually landed. A push operation is a runtime command (no reboot or policy install needed), but the client must be online to receive it.
• Verify per endpoint: the push operation's per-device status in the console is the reliable confirmation — use it as your gate before starting the SCCM run.
• Confirm self-protection really is the blocker. Since it's "suspected", run the MSI with verbose logging and look at the actual failure:

  msiexec.exe /i <path>\EPS.msi /qn /l*v C:\Windows\Temp\eps_upgrade.log

  Search for access-denied / file-in-use / a failing custom action. Client-side logs (via the Collect Client Logs push operation) are in C:\ProgramData\CheckPoint\Endpoint Security\Temp on E88.31+.
• Uninstall password: make sure the organizational uninstall password is set and known (Client Settings) — replacing protected components during an upgrade can require it. Default is secret.
• Documented SCCM flow: Harmony Endpoint Administration Guide, Appendix A – Deploying Endpoint Security Client using SCCM. Note it's written around deploying the Initial client; management-driven upgrades handle self-protection natively, which is why the Deployment Policy path never hits this. If SCCM must own the upgrade as well, the push-operation window above is the supported way to make room for it.

FYI there's a closely related thread running in parallel ("Harmony Endpoint E88.72 → E89.10 Upgrade via SCCM – Best Practice for Uninstall Protection") — worth following both so the findings land in one place.

Hope this helps!

Best regards,
Jorge Dias Junior