j-gray

Thanks @Peter Randziak  This issue presents during an upgrade cycle, which we've mostly completed (for now). Support recommended we bump our license purge to 30 days, so most duplicates have cleared by now.
I did share one log file I was able to find, but this instance doesn't look quite the same as what we typically see.

I've been working with support for around 8 months (#00521603) and haven't had much luck with two issues. Posting here in hopes of more visibility and hopefully some options.
Frequently, activated devices in EP Console are not found in EBA Console at all (neither device name, nor seat name). They are clearly activated and are licensed Is there a way to force these clients to update in EBA Console? OS X devices consume multiple licenses when upgraded Many times after and upgrade of either AV or EI Connector, the OS X clients consume a license for the previous version and the new version. So we'll frequently see an OS X device with a 7.3.x license and a 7.4.x license at the same time. So we frequently run out of licenses when upgrading. This is not an issue on Windows devices. Regarding #2, support indicated they were able to reproduce the license issue when upgrading from v6 to v7 and reportedly fixed this for this specific case. However, we found that the problem exists for other upgrade paths, as well, including the EI Connector.
It would make sense that this license issue is not version specific, nonetheless, support wants us to collect logs during the upgrade process. Unfortunately, this is not possible because 1) it is not consistently reproducible and we have no way of knowing what workstation might exhibit this issue, 2) there is no way to remotely start and stop log file creation to capture the process. Interactive login is required for log capture, which is not an option for remote sites and production systems, and 3) frequently systems can't be found in EBA Console so test cases are even more limited as we can't see what licenses are consumed.
I've presented multiple examples of the issue (see below), yet the onus for resolution seems to always be placed on the end-user to reproduce the issue, log the results, provide the log files, etc.
Here is an example of one device consuming 5 licenses for two products:

Hallo,
I wonder how to find proper device in EBA after I have changed local name several times.
I cannot remember every single change at all.
There are some very historical names i.e of machines which had been retired long time ago...
Which way are these 2 locations synchronized?

Hello together
I have updated my Eset inspect server to version 1.11.2872.0.
Since then I have had the problem that I am suddenly logged out automatically (and not after the automatic logout time).
The following error message then appears:
You're not authorized to execute this action (this user has admin rights).

It happens most often when I am in the detections or rules section.
I have then created a new user, also with admin rights, but the same thing happens there.
Before the update, this worked without any problems.
 
Can anyone help me?
Thanks

A very good feature I saw on LOCAL ESET PROTECT SERVER, where YOU HAVE A CHOISE to select WHAT WILL HAPPEN to Computer that were FOUND in AD, even if they were removed before from ESET LOCAL SERVER.
Why it was useful ?
+Easy to find a missing computer
+It would add computer to ITS CORRECT AD GROUP folder
+ AUTOMATION, you could chose what to do with it.

 
ESET CLOUD PROTECT DOESNT HAVE THIS OPTION:
Disadvantages: 
- ADScanner will miss removed computers, and you don't have any options, they will never be added back.
- Computers once removed, cannot be added back to where they BELONG, ITS IMPOSSIBLE TO AUTOMATE.
- You have to INSTALL agent on an OLD REMOVED COMPUTER so it WILL RE-APPEAR AGAIN in ESET PROTECT CLOUD.
- Even if you install AGENT on OLD Removed Computer, it will appear NOT UNDER ITS GROUP IN AD, but under: a standard Dynamic Group (Windows Computers) -> (No manageable security product).
- Next, you have to go in your AD, find that computer where it belongs to, and MANUALLY MOVE IT TO CORRECT GROUP.
 
Please do something about this, as its annoying and hurts our business, as we have many old, and many new computers and changes. We don't have time to manually do this. Thank you!

I Removed the auto upgrade feature just now, thanks for mentioning as it helped me understand it can be removed (or better yet, unassigned) 

Against my better judgement, we ran with the default auto-update policy setting when we migrated to the cloud and then almost immediately got bitten by the OS X 7.4 catastrophe.
So I'm back to manually managing the upgrade process. We just can't allow updates to proceed en-masse without sufficient testing first.

thank you for this thread.
we declared a major incident on Wednesday and experienced the exact same issue of macs with ventura and 7.3.3600 asking for a restart and then no browsing. 
We use jamf and had a pppc config profile targeting ventura macs to allow the web filtering. This config profile in effect means we accept (allow) the web filtering on users behalf. I found that by un scoping this config profile, users could then browse. Similar to what others have said about removing or turning off web proxy filter.
its just very coincidental that Mac OS Sonoma was released the same day.
I feel that Mac OS sonoma has changed some behaviour and eset has made a change to 7.3.3600 to preempt this , but it’s causing this unexpected blocking of the web filter proxy.
to be clear none of our macs were on sonoma.
I was really confused and unsure if it was a task I set to update to 7.3.3600 that caused this or a scan task that updated modules
but I think now eset have changed something preempting a change to Sonoma but lacked regression testing with ventura.
I have a call open with eset support and will be notifying them of this thread.

Hi we are affected by this issue, all of our macs with 7.3.3600 installed needed a restart after the reboot get the communication error popup and the console says Product is installed but it is not running.  Attempting to reinstall 7.3 or 7.4 fails from the console.

Hello @j-gray,
the Docu team was really fast, kudos go to them.
I passed your feedback to them, thank you.
Peter

Hello @j-gray,
Yes the ESET Bridge or any standard proxy with the caching enabled.
Well the documentation stats what is supported for the HTTPS traffic caching, I admit that the behavior for http / macOS might be not that obvious from it 🙂 
It is stated as 
"•Cache and distribute updates to client computers and installation packages to ESET Management Agent."
I submitted an improvement request for the Docu team to make the info more easy to understand.
Thank you for your very positive feedback provided, really appreciated.
We are also glad to have you, as a very active and cooperative user on the forum.
Peter

Hey Peter,
Can we ask the Dev Team \ product to provide some release notes prior or when a new version is out?
I don't mind being listed for a spam of emails for every minor version that comes out. but I want to know. 
To give a small analogy from a "small" company (Blizzard) when they messed up their first update, they decided to publish release notes almost a week prior to actually patching. 
This is extremely important for any client base and community, ESET should be no different.

Another option I thought about: 
We have RSS feed in the web Console.
I'm sure there are other options to make sure admins can receive information in a visible and clear manner.
 
Thanks

No in this case, as for the macOS version the dev team needed to fix an issue so they incremented the version number for that fixed build. So this versions of EI server and connector are meant to be used together.
Generally in is recommended to upgrade the EI server first, later the connectors.

I manage a few on-prem networks with ERA, and one with the cloud version. The cloud version offers pretty much identical functionality to the on-prem, and whilst we've never had any issues with the on-prem setup, the price differential makes it worthwhile looking at the cloud option now. For the cloud network I manage we have 900 seats and everything works well.
 
Jim 

You can download the MSI file from repository: [removed the link due to found issues, see post below]
 
As to why it is not available on download page & more info about the changelog, I'll leave that to one of the official ESET forum members

We're encountering two issues with v.7.3 upgrades:
As with some previous versions, despite the fact we have the same policy set to not display or report Web Protection and Anti-Phishing Protection being disabled, the GUI shows an error state for these two disabled components. We've intentionally disabled these components and do not want it reported in the GUI. This seems to get broken with every other upgrade. The Web&Email proxy is again breaking the Internet connection during installation. This of course generates a number of support calls.

We have started to see this issue with internet access being broken.  We don't have auto update enabled and our devices have started to install it.  So far a reinstall of the product seems to fix the issue.  Is there a fix coming to 7.3?  How can I stop the auto updates we haven't enabled?

We've had a case ongoing since October of last year. Unfortunately, OS X just doesn't seem to be a priority at all.

We are experiencing the same exact issue: EEI on mac has a critical error, "Product not activated."  One if the machines worked itself out but another machine didn't.  Our team has run the gamut on uninstall/reinstall, reboots, and activation tasks - we've been working with ESET support for weeks (case #00515008).  The EEI agent is up-to-date (1.10.2672.0) on the failing machine.
Please patch this ESET or please acknowledge the bug now while you figure out the patch - this way we can stop worrying about it.

In case anyone is following this, support was able to reproduce the issue and it is currently being investigated by developers.
This will impact anyone who is short on licenses when upgrading OS X clients.

I've found a comment by developers regarding the message "RUN_LOOP_ERROR RUN_LOOP_TIMEOUT (2)". It is not really important, it's possible that EEA took longer than we expected and that the check timed out and will be retried. It should not have effect on the overall functionality. As I understand, the issue is that the EI connector remains not activated even after several re-tries.  Will discuss this with Peter and devs tomorrow and will update you with latest news, it's late night here already.

Hi @emilota
It is indeed in Eset PROTECT but I wrote about Eset BUSINESS ACCOUNT. Today I have another example of why I need it.
In the EBA i see a device named for example: "ST-2020-XX-1". However, I do not see such a computer in my Eset PROTECT. At the moment I do not even know if it is a computer connecting from my network, but under a wrong name, or if someone has activated the license outside the organization. I have nothing to identify the device. The name is not enough. 
Second example from EBA - I see duplicate device (both make connections). However, I only see one device in Eset PROTECT. I don't know if it's a bug or again - someone is impersonating one of the devices and using the license illegally. I don't have a MAC address (I still mean EBA) so I don't know if both entries refer to the same device. I can't see the connection addresses so I don't know if they are in the same location.

Well.... I just found the issue. The upgrade process populates the EI admin logon and password. It just so happens that it was populating the admin account in a case-sensitive manner, as the account exists in the EP console (e.g. CAPAdmin).
When I used the login id capitalized as it exists in EP console, the user is blocked. When I enter the login id in all lower case, the upgrade was able to complete.
I confirmed the same logging into the EI console; account as configured in EP is CAPAdmin. Log into EI console with CAPAdmin = user is blocked. Log into EP console as capadmin = successful login.

@avielc; thanks for the thoughts, I appreciate it.
Clean/new installs don't seem to be an issue, at least initially; we image, rename, join to AD, then script the agent install with JAMF. Once installed, dynamic triggers add the AV and Connector.
Specifically in the case of our Windows servers, the connector upgrade caused the EI connector corruption, noted by the 1969 year in the newly created log entries.
NTP is not an issue. Our hierarchy is solid and we'd know pretty quickly if there was any significant time skew. And of course, all of our Windows EI Connectors are working fine with no activation problems (aside from the Server issue mentioned). The majority of the OS X clients seem to behave, but 20% failure rate is still not acceptable.
I'm back to working with support again, so we'll hope to make some progress.

@avielc; thanks for the thoughts, I appreciate it.
Clean/new installs don't seem to be an issue, at least initially; we image, rename, join to AD, then script the agent install with JAMF. Once installed, dynamic triggers add the AV and Connector.
Specifically in the case of our Windows servers, the connector upgrade caused the EI connector corruption, noted by the 1969 year in the newly created log entries.
NTP is not an issue. Our hierarchy is solid and we'd know pretty quickly if there was any significant time skew. And of course, all of our Windows EI Connectors are working fine with no activation problems (aside from the Server issue mentioned). The majority of the OS X clients seem to behave, but 20% failure rate is still not acceptable.
I'm back to working with support again, so we'll hope to make some progress.