JimChev3

Recently upgraded from the CentOS appliance to the Rocky appliance (version info below). Worked my way through a few problems but everything is up and running. Went to do some routine maintenance on it today and had it do a database backup. Worked fine, no errors occurred. When I went to download the backup file (used to be root/era-backup.sql), there was no backup there. Did some searching and found what appears to be the backup file, now located in opt/appliance/conf/db-backup.sql. To verify that this was the file, I performed another backup and rechecked the date and time stamp and it had updated accordingly. So first off, can you confirm that this is indeed the correct file that I was looking for. If so, is this an intentional and permanent change, or is this another issue with the Rocky appliance that is going to be rectified in a later release?

You are correct, thanks for correcting it! I'd do so in my post but the option to edit isn't there anymore.

Sorry this is a late response, I didn't see the notification. Prior to the fix from ESET, I wasn't even able to create the task because there was no server to select. After their fix, there was one item listed that I was able to select and create the task. I did NOT have to run the update though, as it wasn't showing any agents as being outdated. That being said, as I think you already saw from another thread I just posted in, there is yet another loginConnectionStateNotConnected error stemming from a mysql odbc driver update that will come down in an OS update that will kill connectivity to the web console again. As such, your advice to everyone on taking snapshots/backups before doing anything of consequence both in the terms of the upgrade itself and in maintaining the Rocky-based appliance moving forward after the upgrade would be HIGHLY recommended by me as well. It looks like the kinks are still being worked out.

Just adding some additional instructions for anyone that doesn't already know yum and versionlock (like me!) since versionlocking will be key to being able to install other updates until this is resolved by ESET. When I tried to follow Opapa's instructions on versionlocking the odbc connector, my first attempt was issuing a "yum versionlock mysql-connector-odbc*" command which failed because versionlock is apparently a plugin for yum that isn't installed by default. While looking for the syntax to install, I came across instructions on editing the yum.conf file (which is located in the etc folder) directly so I chose to do that. The file can be found and edited through Tools, File Manager within Webmin and all you need to do is add the line: exclude mysql-connector-odbc* After a bit, the rest of the updates showed up again in the web console, I installed them as usual and everything kept working afterwards. Has anyone seen any acknowledgement of the problem from ESET yet? It seems pretty easy to reproduce, although it can take some time as my Rocky-based appliance ran for days and this is my second update via console before it happened to me.

I'm not running into this. However, due to the problems with the original install, I opted to kill the previously started Rocky-based appliance (had never migrated any clients over to it), did the advanced protection/SHA-256 upgrade on my Cent appliance, and then just this morning did a fresh install of the Rocky-based appliance using the usual instructions in the migration document. All appears to be up and running just fine on the Rocky-based appliance now. I've been slowly migrating the clients over to the new appliance and so far, everything looks good. Since this has been a rather rocky migration (pun intended), I probably won't complete the migration until tomorrow just to make sure the clients I've migrated are still happy. As a side note, there has been no upgrade of the agent needed. I've already verified that the new appliance does allow me to set the new server as the reference (doesn't actually specifically pick a server, but there's an appropriate option to select there as seen below). However, it looks like there's no agent upgrade needed, at least the clients migrated over already aren't showing as out of date. That being said, if it were me, knowing a change of some sort has been made, I'd probably reboot the appliance, give it plenty of time to initialize after the reboot and then try again. Every time I've done any kind of update, reboots seem mandatory even if they aren't done automatically, and it does frequently take more time for connectivity to authentication sources to happen than it does for the logon prompt to be available. Otherwise, I don't really have any specific insight on your problem. Just wanted to report that the change that was made seems to have worked for me, although I think I came through a different route than you did.

While waiting on the fix for Rocky-based on-prem appliance, I am enabling advanced security on my existing CentOS-based on-prem appliance (Server v11.0.199.0, Web Console v11.0.193.0) and I'm almost done. I've created the SHA256 cert authority and used it to sign new server and agent certificates. I've also applied the new SHA256 agent certificate to all of the ESET clients via an agent migration policy, which pointed them to the same server, but using the new agent certificate. So I've finished all steps up to the last one, step 10. At the moment, the old Server certificate shows a 1 under "# of clients using", which I'm sure is the ESET Protect appliance although the Certificate Usage option is grayed out so I can't see for sure. There is also an "Agent certificate for server assisted installation" certificate which shows 1 client using as well, which I can see is the ESET Protect appliance. So, my first question is about the "Agent certificate for server assisted installation". Do I need to do anything about migrating this one? My second question is about the ESET Protect appliance itself. That's the one device listed under Computers that I have NOT applied the agent migration policy to. Should I apply the new agent certificate via the migration policy to the ESET Protect appliance before performing the last step (Step 10) in KB7930, which is where I change to the new certificate under More->Settings->Connection->Change Certificate->Open certificate list, or does the last step handle that? My last question is, once this is completed, should I remove the old certificates, or is it best to just leave them? Will they be left behind when I migrate to the coming Rocky-based appliance?

Great, thank you!

As of 4/16/24, there still appears to be no fix for this for the on-prem appliance. It still require a server to be selected, and the selection dialog is still empty. Any idea when we might see a fix (which I assume would be an updated appliance)? Can't really move to the Rocky-based appliance until it is. Server v11.0.215.0, Web Console v11.0.193.0.

Any update on when this fix will be available for the on-prem VMWare appliance?

Hi Marcos, Have a few follow-up questions about this process that aren't covered in the article. I've created the new VM with the Rocky-based appliance, imported the database, done the intiial configuration with a new IP address and FQDN. Then had to detour to deal with the SHA1 certificate problem. On the Rocky appliance, I've created the new SHA2 CA as well as the Server and Agent certificates. That's as far as I've gone. As of right now, none of the preexisting clients have been migrated over (waiting for that fix tomorrow so I can update the agents properly). Also, no full disk encryption in use here. Question 1: Am I better off moving the clients over to the new server first, then waiting until they have all talked to the new server and picked up the SHA2 CA and certs, then change the connection certificate to the SHA2 server cert on the Rocky appliance, OR should I change the server certificate on the Rocky appliance first, revoke and remove the old SHA1 certificates, set the new SHA2 certificate as the connection certificate under settings and then migrate the clients over to that server (in other words, will they pick up the certificates from the new server when they are migrated over to it or does the certificate on the new appliance need to match the certificate on the old one for the migration to work properly)? Question 2: Under Peer Certificates, there are four certificates, all of which were created on the same day and time I set up the original appliance in here. Server, Agent, Proxy and "Agent cert for server assisted installation". As per the instructions, I've created SHA2 Server and Agent certs using the SHA2 CA. The documents that I saw did not mention the other two at all. Do I need to worry about the other two certificates? Question 3: Should I be deleting the old certs and CA or leaving them as-is? I'd kind of like to remove them at some point so as to be sure that nothing is using the old CA anymore. If not deleting, do I need to be leaving the old SHA1 CA intact and in place so those certs will continue to work, thereby punting that issue down the road to a further point?

Sorry to say, you've still got work to do. I've had some sporadic incidents one by one throughout the morning, but just got notified a few minutes ago that 10% of my computers had issues, and it is indeed the push notification service cannot be reached issue again.

I also just started receiving this notification this morning. A little less than half of our devices are currently affected since around 9AM this morning and still occurring. Glad to see you guys are on it. Update 4/25/23, 7AM Eastern Time: It appears to still be a problem, although less so than yesterday. None of my systems were showing the error when I got in this morning. However, I've had three pop up with it in the last 30 minutes or so. Rebooted the first two and so far, they're still OK, but they may just not have triggered the notification yet also. I'm not sure how long that takes.

I also just started receiving this notification this morning. A little less than half of our devices are currently affected since around 9AM this morning and still occurring. Glad to see you guys are on it.

As of this morning, 4/24/23, most of my environment has started showing that error. Windows clients (ESET Endpoint Security v10.0.2045.0) and servers (ESET Server Security v10.0.12010.0) alike. Ports 8883 and 443 are open to epns.eset.com and the firewall is not showing any denied traffic on those ports except for the rare, odd incoming traffic from IP addresses that are not on your list of ports and addresses document online. There were some TCP SYN checking issues on traffic coming from your push notification servers (tcp syn checking failed, expecting SYN packet for new TCP connections but received ACK FIN or RST instead), but even after turning that off and thereby seeing no more denied traffic for that, everything is still unhappy. I am running an ESET Protect virtual appliance here that everything is connected to. That appliance is reporting as server version 10.0.2133.0, web console version 10.0.132.0. As far as I can tell, everything is on the most current versions available. It's currently showing on 46 of 69 devices in my ESET console. I'm assuming most of the rest just haven't started reporting it yet as the number has been slowly climbing all morning. The only thing I've found on it so far by searching that I have not tried are the instructions at https://support.eset.com/en/kb8207-resolve-push-notification-service-servers-cannot-be-reached-alert-in-eset-endpoint-products. Largely because I'm not sure if these are even still applicable, and also because everything was working fine up until this morning, so I'm not sure why I would all of a sudden need to do this when it hasn't been needed before. I stand ready to provide any further information that I can, but I need some guidance on where to go from here please.

Ah, I was just asking it to scan the URL. I've forwarded all your information on to someone at that township. Again, thank you so much for your help!