Remote Administrator not connecting to PROTECT Server - INTERNAL_ERROR

[jurekk 0]

Hi,

some of our clients have problem to connect to ESET Protect Server. We have tried so far to reinstall the agent several times, check FW openings from client to server TCP 2222, reboot of client computer, remove the computer from console. Please advise.

 

ESET PROTECT On-Prem (Server), Version 11.1 (11.1.756.0)
ESET PROTECT On-Prem (Web Console), Version 11.1 (11.1.144.0)
Agent version: 11.2.2076.0

Error: SendRequestAndHandleResponse: Rpc message response INTERNAL_ERROR. Error message: . RequestId: 6c14ff89-4159-4b19-9c3b-ddfd3129f305

• Task: CStaticObjectTask
• Scenario: Automatic replication (REGULAR)
• Connection: uhesmc01.skba.synot.local:2222
• Connection established: true
• Replication inconsistency detected: false
• Server busy state detected: false
• Realm change detected: false
• Realm uuid: b22c3654-6681-486c-9a56-ba1d6bdbedc5
• Sent logs: 0
• Cached static objects: 1
• Cached static object groups: 1
• Static objects to save: 79
• Static objects to delete: 1
• Modified static objects: 0
• All replication attempts: 13

trace.log status.zip

[Marcos 5,241]

Please raise a support ticket for further troubleshooting. It appears that a connection was established but some replication attempts are failing for an unknown reason:

• Successful replications: 2
• All replication attempts: 12

[Sigi 0]

Yes, there seems to be a bug in the new Eset center. Updating existing clients works, but creating a new client doesn't complete. The client is added to the center but does not send hardware and operating system data. This happens with Mac and Win clients as well as with different agent versions. This means that the client does not receive a policy because the operating system is not recognized in the center.

Best Sigi

[Marcos 5,241]

50 minutes ago, Sigi said:

Yes, there seems to be a bug in the new Eset center. Updating existing clients works, but creating a new client doesn't complete. The client is added to the center but does not send hardware and operating system data. This happens with Mac and Win clients as well as with different agent versions. This means that the client does not receive a policy because the operating system is not recognized in the center.

Please do not hijack someone else's topic but create a new one. Besides that, also raise a support ticket.

[linzhou 0]

I also encountered this issue, and after restarting EP Service, the problem was resolved.
But this solution is not realistic.

[AlexH2 0]

4 hours ago, linzhou said:

I also encountered this issue, and after restarting EP Service, the problem was resolved.
But this solution is not realistic.

Thank you for this. Didn't even think of rebooting the server (which I did do after upgrading to latest PROTECT release) and it's now called in correctly. 

Do i need to do this with each install on new machines? 

Have logged a support ticket, but not heard back as of yet

[Martin_L 2]

Chiming in to report that I encountered the same issue today. Restarting ESET PROTECT Server service has helped for the moment. Has anybody tested if this comes up every time a new agent was installed?

I have also raised a support ticket (Case #00799086).

[Marcos 5,241]

This is currently tracked as a bug. As you have found out, restarting the ESET PROTECT Server service helps.

P_EP-30618

[Vimes24 2]

Unfortunately, this problem has become very acute for us now. We are using the ESET Protect On Prem Appliance (Rocky Linux 9.4) and the newest Release ESET PROTECT 11.0.215.0. Rocky OS and all ESET products are patched to the newest version on the appliance.
At first the posted workaround worked for us: When the clients reported, that Port 2222 was not reachable we restarted the service of the appliance via console command:

systemctl restart eraserver

This worked for 1 or 2 days until the service became unresponsible at port 2222 again.
But since monday the service at port 2222 "dies" within 5-10 minutes. A restart of the service helps, but only for 5-10 minutes.
We are in the process of rolling out new windows-clients and agents (around 50 systems) and at this point the appliance is not usable anymore. Restarting the whole vm or just the service doesn't matter. After 5-10 minutes the service is not reachable at port 2222.

Is there a workaround that prevents the service from becoming unresponsive so fast? Or is there an ETA for the new ESET PROTECT version wich fixes this?

We searched the trace-log from eraserver, but no warnings or errors were logged.

[Marcos 5,241]

I assume that the hotfix version of ESET PROTECT server 11.1.762.0 will be released soon and should address this issue but you'd better raise a support ticket to make sure that the fix it contains is 100% for the issue that you've run into.

[Vimes24 2]

We raised a support ticket and a workaround fixed our problem for now.
The errors stopped with this workaround and the appliance is stable now for 4 days.

The variable "DefaultLimitNOFILE" was set to "65535" (Default 1024) in systemd system.conf and user.conf.
It can be easily set and rolled back:

First create backup-files of the configs:

sudo cp /etc/systemd/system.conf /etc/systemd/system.conf.backup
sudo cp /etc/systemd/user.conf /etc/systemd/user.conf.backup

Set the variable:

sudo sed -i "s/.*DefaultLimitNOFILE=.*/DefaultLimitNOFILE=65535 /" /etc/systemd/system.conf
sudo sed -i "s/.*DefaultLimitNOFILE=.*/DefaultLimitNOFILE=65535 /" /etc/systemd/user.conf

Then reboot the appliance.

To roll back this change, just delete config files and rename "*.conf.backup" to "*.conf" and reboot again.

[TN LMG 8]

I am also experiencing this issue. As described by Vimes24, running a restart of the server got things going.

systemctl restart eraserver