Jump to content


  • Content Count

  • Joined

  • Last visited

Profile Information

  • Location
  1. Marcos FYI - After re applying all my policies to how i want them ( without ANY proxies ) previously as per above, I notice that when i went to create an Agent installer, the code of that Agent installer configuations is set to RE APPLY a proxy and a specific IP address. Are proxies configured elsewhere in RA? am i Doomed to foreever re configure any new clients i now create from from the RA installers because it has the proxy configuration i dont want, that after each new installtion i have to re apply another policy to undo the config applied by the installer? Think there may be a
  2. OK, after Marcos checked the logs, looks like this was failing due to being denied pass through from a proxy server. Funny thing is, i don't pass these through a proxy server and trying to pass traffic through a printer for some amazing reason was not reaching eset I am not sure yet how policies pushed from the RA applying to clients were set in the first place, however moral of this story............check for proxy
  3. Marcos Thanks, I have sent you three files: - eea_logs 1433 Full Diagnostic Activation fail.zip = All options as described and logs taken after an activation fail - eea_logs 1442 Diagnostic Informative fail.zip = Reversed with informative logging - eea_logs 1458 = Logs after MBAM uninstalled ( MBAM will only be indicitive to myself and will not be on all other clients that fail ) To reiterate, this error message only occurred once my license was renewed. License was successfully renewed and I did not have to apply anything in the Remote administrator, once the u
  4. OK Client -> Setup -> Advanced Setup -> Tools -> Diagnostics -> Enable Network Protection Advanced Logging = Yes/NO I have processed a local client activation attempt and a remote administrator one, which can both be seen in the logs ( which i have sent directly to you outside of this public post) at 12:45 + Cheers
  5. Has anyone Gone past the renewal date reported by the client? does the client still communicate with the server in the same fashion ( updates / signatures etc ) or does the client halt all updates because of its false belief its not licensed?
  6. MichalJ Unfortunately, this issue is still present for my clients: - Actual client will display a license expiring message - Remote administrator displays an alert for the client showing 'license expires' I am running this from a product activation task in Remote administrator, selecting my current valid license which I can confirm is a year ahead and specifies the correct date next year, however running this on clients fails, no details, just 'Task failed' on RA and on the client log file specifies 'Activation was not successful: Could not reach the activation server'
  7. Hi all, i renewed my license about a week ago and all is good in on the remote administrator specifying the next expiration date. However, I was expecting my clients to catch up, althoug, now i have all my users worrying their AV is going to expire, when in fact it wont, or will it since the client thinks it will and stop updating? Anyway I have tested applying an activation task from the remote administrator which then fails on the client with 'Activation was not successful, . Could not reach activation server' I have applied the same license on the product activation
  8. MartinK Ok, I am now all up to all clients connecting on the new ERA I am not convinced it was certificate after retracing the instructions, I added another step https://support.eset.com/kb6492/ II. Apply the Agent Certificate in a new Agent Policy on your new ERA server, Server Two in this example. and added the new ERA server on this step as technically this step only specifies adding the agent certificate ( even though the screen shot show otherwise under step 6 ( servers to connect to ). I am not sure if this was missing in the instructions or i inadvertently adding some
  9. MartinK Thanks for the reply and the heads up on the status.html. Yes indeed the clients are still connecting to the old ERA and as i can see in the Last-error.html, the policy applying the new ERA server has correctly served its purposed, but, yes I have done something ridiculous with the certificates because of the error 'CReplicationManager: Replication (network) connection to 'host: "***********" port: ****' failed with: Receive: NodSslWriteEncryptedData: Incorrect/unknown certificate or key format.' I will retrace my steps on the https://support.eset.com/kb6490/
  10. Hi all I have migrated my ERA server (6.5.522.0) to another server. followed https://support.eset.com/kb6498/?locale=en_US&viewlocale=en_US and proceeding instructions and all good. However, my clients in the new server only communicated once with the new server ( with or without the old server era service off ) and fail to speak to it, presumably I am doing something stupid here with the certificates. If i switch the old ERA back on clients revert to that even though i can see the correct policy applying to the client to divert to the new server. I will most pro
  • Create New...