MarkR 0 Posted January 19, 2022 Share Posted January 19, 2022 We recently upgraded to PROTECT version 9, and mass upgraded endpoints Network Agent versions to 9 as well. Last week whenever I sent a Wake Up Call to an endpoint and hit refresh the timestamp of when the machine checked in would update to that time immediately as it always has in the past. However, today whenever I send a Wake Up call to a client and hit refresh it does NOT check in, and the last connected timestamp remains the same. I now have to wait until the Agent policy check in time for the Last Connected timestamp to change. Anyone else experiencing this? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,259 Posted January 19, 2022 Administrators Share Posted January 19, 2022 First of all please make sure that both the ESET PROTECT server and clients can communicate with epns.eset.com on port 8883. Link to comment Share on other sites More sharing options...
MarkR 0 Posted January 19, 2022 Author Share Posted January 19, 2022 confirmed that communication works Link to comment Share on other sites More sharing options...
MarkR 0 Posted January 19, 2022 Author Share Posted January 19, 2022 I've even tried running a Wakeup Call to the PROTECT Server itself, locally, and even that doesn't update the Last Connected timestamp Link to comment Share on other sites More sharing options...
MarkR 0 Posted January 20, 2022 Author Share Posted January 20, 2022 ha - so all of a sudden today the Wake Up call is working fine - we didn't make any changes on our end. working perfectly now Link to comment Share on other sites More sharing options...
ESET Staff MartinK 383 Posted January 20, 2022 ESET Staff Share Posted January 20, 2022 Hard to say what was going on, but it is probable that after AGENT upgrade, re-synchronization of wakeup identifiers is required. In other words, once AGENT has upgraded, it will most probably get new identity from ESET's push notification service, and this identity has to be sent to ESET PROTECT Server (via standard replication connection) so that wakeup of this specific device can be targets. This normally takes quite a short time and that is why I am not sure this was the issue... Link to comment Share on other sites More sharing options...
MarkR 0 Posted January 25, 2022 Author Share Posted January 25, 2022 now the wakeup calls aren't working for some machines Link to comment Share on other sites More sharing options...
MarkR 0 Posted January 25, 2022 Author Share Posted January 25, 2022 this is really frustrating...some machines appear to be able to check in after a wakeup call just fine and others are not Link to comment Share on other sites More sharing options...
Administrators Marcos 5,259 Posted January 25, 2022 Administrators Share Posted January 25, 2022 I'd recommend opening a support ticket. A pcap log from the client with the network communication captured as well as an agent trace log created with trace verbosity may be needed for troubleshooting. Link to comment Share on other sites More sharing options...
TomTomTom 2 Posted January 26, 2022 Share Posted January 26, 2022 Hi, I have the same problem.... Wakeup call is no more working Link to comment Share on other sites More sharing options...
Administrators Marcos 5,259 Posted January 26, 2022 Administrators Share Posted January 26, 2022 9 hours ago, TomTomTom said: Hi, I have the same problem.... Wakeup call is no more working You might want to check agent's log with trace verbosity for possible epns-related errors. Also a pcap log might shed more light. I'd recommend opening a support ticket for further troubleshooting as advised above. Link to comment Share on other sites More sharing options...
TomTomTom 2 Posted January 27, 2022 Share Posted January 27, 2022 (edited) The locale support gave me the tip to disable the HTTP_Proxy. More > Server settings > advanced settings This was the solution for me. Now the wakeup call works again. However, I have not changed anything in the settings before. With the previous settings it always worked so far. Edited January 27, 2022 by TomTomTom Link to comment Share on other sites More sharing options...
Recommended Posts