EPP-Server 2608 / Client 2608.1.1.3

Endpoint Protector Endpoint Protector Discussions & Questions
1

Hello everyone,

I’m still using the Hyper-V Endpoint Protector Server 2510.0.1.0 under Hyper-V.
I’ve updated this system to version 2608.0.1.0.
Since a server change is planned, I created a system backup from this installation.
On the new Proxmox host, I then imported the VMware OVF image of version 2608.0.1.0. The VM starts and boots without any issues. After that, I adjusted the network configuration for the EPP server and restored the system backup that I had created earlier.
However, since then the new EPP system has been behaving unusually. Almost no clients are checking in with the EPP server anymore to obtain a license.
For a test, I updated 10 Windows 11 clients to the EPP client version 2608.1.1.3.
According to the EPP server, all 10 clients have received a license and a policy. On the clients, it also shows that devices are locked and when the last contact with the EPP server took place.

After that, however, nothing happens anymore.

A manual policy update fails every time. The displayed time remains stuck at the point of the first synchronization.

In addition, the EPP client can be uninstalled without a password, and all devices are
unlocked again afterwards.
On the EPP server, it shows that the client has received a license, while at the same time being
shown as “Offline”. However, the clients are not offline. I can successfully ping all affected clients.

Thanks in advance.

2

Hi Martin,

Thanks for the detailed write-up — that makes it much easier to help.

The symptoms you’re describing (clients showing “Offline” despite being reachable, sync timestamps stuck at first contact, policy updates failing) are consistent with issues we’ve seen after Proxmox imports, often related to time zone or time sync discrepancies between the EPP server and the backend.

Could you check the following:

  • The time zone setting on the EPP Server (both in the EPP Server web interface and at the Linux OS/backend level) — confirm they match and match your expected local time and time zone
  • Whether the system clock drifted at all during the OVF import/restore process
  • NTP sync status on the new Proxmox VM

If these check out and the issue persists, please raise a case with Netwrix Support so our team can dig into the logs with you directly.

Best regards,
Krzysiek

3

Hi Krzysiek,

I checked the following:

  • The web interface of the EPP server is set to Europe/Berlin and is synchronized via an NTP server.
  • Proxmox also uses the correct time zone Europe/Berlin and is synchronized via an NTP server.
  • I don’t have access to the Linux OS on the EPP level, because my access credentials don’t work there.

I already contacted support. The support engineer tried to solve the problem by working with two clients for about two hours.

During that time, he logged various things on the clients and installed a certificate. However, I didn’t understand why he installed the certificates via certlm.msc. The setup should actually configure the required certificates on its own, as long as they are needed.

In the end, the IP address of the EPP server was changed. After that, one client was switched over to the test IP, and there the policy update worked. His conclusion was therefore that the problem lies with the IP address of the EPP server.

What was strange, though, was that I couldn’t find any network conflict on the original IP address. Also, the error during the policy update occurred again after a few hours.

At that point I didn’t feel like contacting support again, so I tried to find a way to narrow down or fix the problem myself.

To that end, I made several attempts:

  • updated step by step an old backup to a newer version,
  • restored backups in different versions as a system backup,
  • tested various import settings in Proxmox.

Unfortunately, the error during the policy update still kept occurring.

In doing so, I basically stuck to the existing VMware data of the original VM and tried to transfer those settings to Proxmox accordingly.

So my hope was that, in this forum, I might find users who were able to successfully import the OVF into Proxmox and where the EPP server then also worked without any issues afterward. Maybe someone has already carried out such a migration and can tell me which settings and/or which virtual hardware was used in Proxmox.

Maybe, though, the cause is something completely different that was triggered by restoring the system backup.

I would basically also rebuild the system from scratch. However, for that I would first need to export the custom settings of the already released devices and then be able to import them into the newly built system. So it would also be interesting to know whether and how these settings—or the already released devices—can be backed up and restored on a newly built EPP server.

Regards,
Martin

4

Hi Krzysiek,

I’d like to briefly share my experiences.

It actually wasn’t caused by the OVF import into Proxmox. The import doesn’t produce any errors and EPP 2510.0.1.0 runs fine under Proxmox. :slight_smile:

I was able to rule this out for the following reasons:

I still had a created system backup of version 2510.0.1.0 that I had created back then under Hyper-V. However, I can’t import that backup into the current version 2608.x.x.x anymore.

So I created another VM in Hyper-V with EPP 2510.0.1.0 and imported the system backup there. What I can tell you now: During the import, this system backup must cause an error somewhere—possibly a corrupted database at a specific location or something similar.

After that, I installed 2511.1.1.3 on the two clients. However, the policy and/or the license is not transferred directly, no matter whether I reset the license or re-request the clients in the Cockpit.

Then I restored the snapshot before importing the system backup and requested a trial license. After that, I performed another fresh installation on the two clients with 2511.1.1.3. And see for yourself: The system was blocked immediately. Also, fetching the policies no longer causes any errors.

After that, I created a system backup from this test system, imported the OVF from 2510.0.1.0 into Proxmox, and then imported the test system’s system backup from Hyper-V into the Proxmox installation.

Here, the clients were recognized immediately again, the policy is present, and I can update the policy at any time without errors.

Since I currently don’t see any other way to transfer my Custom Classes from the old system to the new one, I’ll probably have to go through the trouble of copying the entries individually and then wait for the client to check in again or for the device to be plugged in again.

I don’t know to what extent you’re in contact with the development team, but I’d really like an export/import function specifically for the „Custom Class“ entries. That way, at least you’d have the option to back up these entries separately and import them again whenever needed.

Sorry, it turned out to be a bit more than I intended. :slight_smile:

Best regards
Martin