rockshox

That isn't the case for us. Defender is disabled and only ESET is active. My personal work computer had the issue today and after fiddling around and rebooting several times have having the problem still occur I then, checked for Windows Updates, installed the latest BIOS for the PC then it just magically started working again. I honestly don't know what fixed it. We did however have multiple reports last week of weird lag issues and nobody could put their finger on the exact issue, but on suspicion of the AV this morning I came to the forums to see if anyone had reported similar and found they had. I'll try and get logs when the issue is reported again. My personal work computer appears to be fine now, I can't recreate the issue currently but I did just upgrade to 10.1.2046.

We are seeing something similar as well. I could not pinpoint what the issue was but had suspicion of ESET just due to the fact that anything web related lags out (Outlook freezes for long periods of time, or FireFox would just freeze and end up crashing). I came here looking to see if anyone else was reporting anything and sure enough, looks like we aren't the only ones seeing this. I will try 10.1.2046 and see if that helps. @Marcos is there any further information on this? Is ESET aware?

Marcos - Thanks for the reply. That would explain why it is missing, which is too bad as that is the primary way we have always deployed the agent and it works flawlessly for us. We will have to try out the other methods or just create the task from the Tasks menu.

I am curious on how ESET decided that versions of SQL below 2019 are "Outdated" components. From what I can tell of Microsofts product life cycle, SQL Server 2017, 2016 are still under support and will be for another 4-5 years. I think this notification should be re-evaluated and or give an option to turn it off.

Just to be clear on what I am referring to (and what I believe the OP is referencing) here is a screenshot what we used previously to deploy the agent. We would select the new client, then Deploy Agent, select "Server Task Agent Installation" and fill out the few fields needed for the task and deploy the agent. I found we can still get to the Server Task for Agent Deployment manually by going to Tasks, but it's missing as one of the options in the right-click Deploy Agent menu.

We appear to have the same issue. We've always deployed the agent using the wizard that created the task automatically, we entered credentials, selected the settings we wanted and the agent pushed out immediately. In version 9.1 all the Deploy Agent options are worthless as part of the Right Click menu. They all want to create downloadable installers, or scripts that can be deployed which I understand how that would work, but our techs all used the wizard and just pushed the agent straight out to the computer. I did find that I can find the old deployment interface by going directly to the Agent Deployment tasks and creating a new Server Task for Agent Deployment. Why isn't this available in the right click menu like it was previously?

@Peter Randziak The uPCU that was released, does the client need to be on version 9 already, or will version 8 clients be upgraded as well?

The majority of my ESET Endpoint Clients are on 8.1.2037.9, weren't they supposed to upgrade automatically to version 9? or did that not happen?

Has this been fixed in any of the hot fixes that have been released for ESET Protect or are we still waiting for a fix?

Marcos - You mentioned that this was for the Apache http proxy on Linux, but I checked our Windows installation of ESET Protect where we do run the Apache http proxy and can see that port 53535 is not in the AllowCONNECT list. I have suspicion this is due to the fact that we are on ESET Protect 8.0 and have not upgraded to 8.1 yet due to the Domain Login issue. Do I need to add 53535? Secondly, if port 53535 was missing from AllowCONNECT wouldn't that cause ESET Live Grid to not connect at all instead of the intermittent issue a lot of us are reporting?

Add myself to the list of people with this same issue. We also rolled out 8.1 to our users over the last couple months or so and get the "ESET LiveGrid servers cannot be reached" randomly on computers all over our network. Every day when I log into the ESET Protect console, there usually are 1 or 2 computers in the warning list with that alert, if I check awhile later the alert has cleared magically, all on it's own with no changes or intervention on our part. We have confirmed that all required ports are open in the firewall and can see the traffic leaving our network through the appropriate rules. We have redundant ISP connections and detailed alerting and can confirm we have not had any interruption in internet service to trigger the alert. Since the issue appears to be very random, it is somewhat difficult to enable logging and hope it does it again. I have two computers right now with the issue, one the end user just emailed me a screenshot of the issue. One computer is a desktop that does not move or travel between networks, no VPN and we do not use a Proxy server. The other is a mobile device that does roam between the network and other internet sources with VPN. I believe ESET needs to be taking a closer look at this as there are a lot of people reporting this issue. For as long as we have been running 8.0 I can only remember a few instances of ever seeing this error and usually there was a reason for it. Now I have seen it hundreds of times in the last few weeks. I will see about enable the advanced logging on some machines and see if get lucky and reproduce the issue and get some logs.

After fiddling around with this more, I believe I have found the problem. I have found that there is a registry key WebClientComputerName located at HKLM\SOFTWARE\ESET\ESET Security\CurrentVersion\Info that is not updated to the new computer name but contains the old computer name. The key must be protected by ESET as I am unable to change it manually even having permissions. I found that if I uninstall ESET Endpoint Antivirus and re-install, the key now has the correct value and EBA now shows the correct Device name. One other thing I noticed was there was a computer we renamed two days ago that the value did update in EBA. In looking through all the licenses in EBA that I know we renamed the computers in the last few weeks, the computers that had ESET Endpoint Antivirus 8.0.2028 appeared to update the Device name in EBA correctly. Computers that were renamed with ESET Endpoint Antivirus 8.1.2031 did not. Uninstalling 8.1.2031 and then re-installing fixed the bad Device name in EBA.

The Device Name in EBA is not updating after a computer has been renamed. When staging a computer we quite often have the computer named differently than it's final name (ie, snoopy1.domain.com). When we put the computer into production it would be renamed to snoopy.domain.com. EBA still shows the Device name as "Snoopy1.domain.com" and the Seat Name as "Snoopy1.domain.com". In the past the Device name has updated to reflect the new name while the Seat name still shows the previous name and EBA would then allow us to update the Seat Name and everything would match. I have computers in EBA that were renamed just a few months ago and the Device name updated as expected. However the computers that we replaced in the last month the Device name has not updated in EBA. I have tried removing the computer completely from ESET Protect, deactivated the license in EBA, de-activated and re-activated the license numerous times, re-synced the licenses in ESET Protect and it doesn't seem to matter what I do the wrong Device name ends up in EBA. What is the trick to getting the Device name to update correctly in EBA? We have not upgraded to ESET Protect 8.1 yet, maybe I should upgrade to 8.1 and try again.

Marcos - Is TCP/UDP 53535 a new requirement for version 8.1? We have never had that port open on our firewall previously and ESET Live Grid has always been functional.

@MichalJ - To answer your questions: - Yes. After I do a synchronize in EP, but EBA and EP show the same thing. Sorry the numbers keep changing, but due to the fact we are rolling out new PC's, I've been juggling removing and adding the PC's so we don't max out at 250 during the swaps. With the shuffle, right now both EP and EBA show 229/250, so they do match each other even though it appears to be the wrong number. - When I view the main dashboard in EP, it shows I have 242 Managed & Protected devices. That is correct. I exported the Computers table to Excel and confirmed 242 devices in the list. EBA currently shows 240 Activated Devices. They are close, but not the same, and neither of them match the 229/250 number that is displayed in other locations. I will send you the PLID in a PM.

MichaelJ - To answer your questions: - I checked the "Multiple products" groups in EBA, the devices are all Microsoft Surface Pro or Surface Book devices, there are also two Panasonic tablet devices. All Microsoft Surface devices are using the Surface Dock. In our department, we have a single MS Dock that we use for imaging and deploying software before installing the equipment. We do not normally unbox each and every dock to image our computers which is why multiple machines are imaged and software (ESET is installed after imaging) is installed. While we could unbox each dock and use it with the device it is assigned too, it doesn't seem we should need to do that just to have ESET licensing report correctly. - All devices that are grouped have either 7.3 or 8.0 installed. We have some groupings with all devices on 8.0. We have one group that has one 7.3 and one 8.0 device. - I am attaching a couple screen shots from EBA and ESET Protect. Both locations seem to be somewhat confused by the grouping of Multiple Products. The actual Device count that EBA shows on the dashboard and ESET Protect shows on the dashboard usually match. We have a 250 count license that is almost full as we are in the middle of swapping equipment right now. However, if I look at the License Management page in ESET Protect, it shows a different number. EBA also shows the same number in the Product Usage section of the Dashboard.

MichalJ - I tried as you suggested. I deleted the computers that comprised the "Multiple prodcuts" group, and confirmed they did not show in EBA any longer. From ESET Protect, I then pushed a "Product Activation" task to each computer. The computers then showed back up in EBA grouped together again. I tried two different groups, 6 different computers that all did the same thing. I know for certain these computers are in different locations, different docks and one computer is being used from home today. They still all went back into EBA and grouped back up automagically. What else can I try? I'd really prefer that the licensing in EBA matched the installs I maintain in ESET Proect.

Hello - I can see this question has been asked numerous times, but without a clear way to fix the issue. In reviewing licenses in ELA and now EBA, I have several places where devices are grouped as "Multiple products". Many threads point out this is caused by the same hardware being renamed. However in our case, each computer is a separate hardware device, but the dock used for setup was the same. All the devices that are grouped under "Multiple Products" are mobile Surface or Lenovo products that were all imaged and software installed on the same dock. Due to the dock having the same hardware and mac address it most likely causes this issue. What is the process to fix this? How do I separate the devices so that each have their own seat? or do I just get free licenses when it groups them together like this?

MichalJ - Thank you for the info. I was able to find it in the reports as you suggested.

I found that if I trigger a Scan from the ESMC console and then dig into the task, I can see the Execution Details from the Scan which is basically what I was looking for. I don't really need the full log, just the high level metadata, Just so I can see the scan actually ran, how many files were scanned and everything was clean. However, what triggered the question in the first place is the fact that we have a scheduled weekly scan that runs at the same time every week on all computers. Those scans seem to be invisible to ESMC. I can login to a client, check the "Computer Scan" logs and see the scan ran, how many files were scanned etc.., but I can't see that high level information in ESMC anywhere that I have been able to find for the scan we have setup in the Scheduler.

Where do I view computer scan logs in ESMC 7? In ERA 5 it was pretty simple, but I am unable to locate it in ESMC 7. Thanks

Ah ok. Well I'm running a Windows server with standalone install of ESMC so slightly different, but I'm sure the same issue. I believe the Virtual Appliance is running CentOS, so it would require modifying the correct config file and increasing the TimeOut value, but since it's the Virtual Appliance I can't direct you to exactly where that would be. Maybe someone else can chime in here that knows where the config file is for the Apache HTTP Proxy on the virtual appliance.

Are you running the virtual appliance or standalone Windows/Linux server?

FYI - Confirmed the TimeOut value is being used. I pushed the Endpoint client to a very slow T1 link, the task failed with the same error. Checking the debug log showed the timeout occurred after exactly 2 minutes. I changed the TimeOut value to a much larger number and was able to successfully deploy the Endpoint client to the remote location with the slow link.

I checked the httpd.conf for the Apache HTTP Proxy service and found that they already had the ProxyTimeout set to 900 seconds, but that clearly didn't seem to be working. After looking around on Google, I modified httpd.conf and added "TimeOut 120". My thought was to see if the timeout now happened after 2 minutes so that I could confirm which timeout value was being used. Surprisingly after adding "TimeOut 120", I've been able to successfully push the installer multiple times to one remote location. I'm not sure if this is coincidence, or if that was enough time to solve the timeout issue. In httpd.conf, near the bottom you will find a ProxyTimeOut 900. I added a Timeout 120 right above it and restarted the service. ThreadLimit 1500 ThreadsPerChild 1500 CacheLock on CacheLockMaxAge 10 TimeOut 120 ProxyTimeOut 900