j-gray

But ESET apparently changed something. I have another support ticket in for in-place EEI Connector upgrades on Windows servers. They are unable to activate the connector license after the upgrade. So far, the only solution is to uninstall/reinstall the connector.

@avielc Thanks for the update --I haven't heard back from support after providing more logs on 11/21. Unfortunately, OS X doesn't seem to get much attention. We've had a case (00291733) opened almost a year now where the licensing issue was recognized as a bug. On the plus side, we have lots of free licenses!

Thank you, I appreciate it.

No updates since 10/28. Sent several emails to support on 10/31 and 10/04 and no reply. It would be great if we could get a status update. Even better if we could get this working on servers and Mac clients.

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.

@JamesR I ran those commands to export, then delete the registry key. The password was blanked out during the upgrade process as you indicated, but after typing it in I still get the same 'blocked user' error.

@JamesR Thanks again for your help. I verified again that the EI Admin account is enabled, does not require a password change, and does not have 2FA enabled. I followed your steps for re-ordering columns, etc. but that did not change any of the values. In recent upgrade attempts, I rebooted both the EP server (effectively stopping and restarting all services), as well as the EI server. This did not resolve the issue. I followed the steps provided for the two servers, stopping/starting in the order specified and still not change. I did look at the logs and as you indicated, those authentication errors are being logged as 'blocked'. The account password was reset in late-October due to expiration. I'm wondering if the old password somehow got retained/cached somewhere I don't know why else would be getting blocked: 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Socket accepted. Remote ip address: EIserverIP remote port: 59687 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Resolving ip address: EIserverIP 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Receiving ip address: EIserverIP from cache 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Successfully received ip address: EIserverIP from cache 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Socket connection (isClientConnection:0) established for id 15758 2022-11-09 18:15:27 Information: CReplicationModule [Thread 2810]: CReplicationManager: Received notification of non-replication connection from 'host: "EIserverFQDN" port: 59687' (product type: 4) 2022-11-09 18:15:27 Information: ConsoleApiModule [Thread 1d38]: 15758 Initializing new network connection. 2022-11-09 18:15:27 Information: SchedulerModule [Thread 2548]: Received message: RegisterSleepEvent 2022-11-09 18:15:27 Information: ConsoleApiModule [Thread 20fc]: 15758 Login request received [UserName=EIaccount] 22281, Reported address: :0, Connection (webserver) address: EIserverFQDN :59687 2022-11-09 18:15:27 Information: CServerSecurityModule [Thread 255c]: Authenticating user EIaccount 2022-11-09 18:15:27 Information: CServerSecurityModule [Thread 255c]: Checking native user password 2022-11-09 18:15:27 Error: CServerSecurityModule [Thread 255c]: CUserAccessLimiter::CheckAccess(): User EIaccount from EIserverFQDN was blocked. 2022-11-09 18:15:27 Error: ConsoleApiModule [Thread 20fc]: 15758 Error while sending AuthenticateUser request [UserName=EIaccount] CUserAccessLimiter::CheckAccess(): User EIaccount from EIserverFQDN was blocked. 2022-11-09 18:15:27 Information: ConsoleApiModule [Thread 20fc]: 15758 Login request received [UserName=EIaccount] 22282, Reported address: :0, Connection (webserver) address: EIserverFQDN :59687 2022-11-09 18:15:27 Information: CServerSecurityModule [Thread 255c]: Authenticating user EIaccount 2022-11-09 18:15:27 Information: CServerSecurityModule [Thread 255c]: Checking native user password 2022-11-09 18:15:27 Error: CServerSecurityModule [Thread 255c]: CUserAccessLimiter::CheckAccess(): User EIaccount from EIserverFQDN was blocked. 2022-11-09 18:15:27 Error: ConsoleApiModule [Thread 20fc]: 15758 Error while sending AuthenticateUser request [UserName=EIaccount] CUserAccessLimiter::CheckAccess(): User EIaccount from EIserverFQDN was blocked. 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Connection closed by remote peer for session id 15758 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Forcibly closing sessionId:15758, isClosing:0 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Removing session 15758 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: Closing connection , session id:15758 2022-11-09 18:15:27 Information: ConsoleApiModule [Thread 1d38]: 15758 Deinitializing network connection. 2022-11-09 18:15:27 Information: NetworkModule [Thread 272c]: There are still pending sends for sessionId:15758

@JamesR I've tried replying to your PM several times, but it doesn't appear to go through. The EI Admin account belongs to the 'ESET Inspect server permission set' and there is only one server permission set (see attachment). I noticed in the audit logs that the EIAdmin account attempts to log into EP 11 times every 30 minutes and gets "Access Denied". The audit logs don't indicate the source of this attempt, so I'm not sure what's actually doing it. Just to reiterated, I can log into both EI and EP consoles successfully with the EI Admin account, so I know it's working and the credentials are correct.

I've never encountered this error before, and now only when I'm attempting the upgrade to 1.8.2214.0.

@Marcos I do the upgrade logged into the server with Admin rights, as I always have in the past (5+ successful upgrades). There is an EI user (admin) dedicated to communication. The same account that we have been using since we set up Eset Inspect. As noted above, 2FA is not enabled and I can log into the EP console successfully with that account.

@JamesR Thanks for the reply. Unfortunately, no luck Rebooted EP server, re-ran install - same error Rebooted EI server, re-ran install - same error I verified again that I can log into both EP and EI console with those credentials. I checked the account in the EP console and it shows enabled (and 2FA is disabled).

Just tried upgrading to the latest release, 1.8.2214.0. During the upgrade process when prompted for 'Data connection to ESET Protect, which is pre-populated correctly, I get error message, "User was blocked. Please try again later". With the credentials specified (same as used in current and previous versions), I can successfully log into both the EP Console and the EI console. Any thoughts as to why this is happening? I have not encountered this in any previous upgrades.

I wish I could edit my response, as I didn't see the entire product list. In addition to ESET Endpoint Antivirus or ESET Endpoint Security for Windows we also use ESET Endpoint Antivirus or ESET Endpoint Security for macOS ESET Server security products ESET PROTECT (on-premise) ESET Inspect (on-premise) We usually have pretty good luck with helpful responses in the forums, though the ESET Inspect forum is pretty dead. I do appreciate ESET Devs and support staff presence there. We're still waiting on a fix for an EI Agent bug from back in January. Reference #00291733; almost a year later and EEI Agents on Macs still do not support licensing, which seems like pretty basic functionality. The EI product seems quite buggy, still. Honestly, my biggest complaint is with support and the support process. Wait time on my last chat was almost an hour. I had a case opened (#00444283) on 10/27, had a remote session on 10/28 and have not gotten any responses since. I've emailed several times requesting additional information and providing additional information, but have gotten no responses or even confirmation of receipt. Response times are typically very slow and it's frustrating to get no replies, have no follow up, etc. I appreciate the opportunity to provide feedback.

Support Case #00444283 For the record, we've determined that the activation failure occurs on: Windows Servers running Server Security when upgrading EI Connector to v.1.8.2211.0 Subsequent activation tasks fail Uninstall/reinstall or repair of EI Connector fixes the issue OS X workstations running Endpoint Antivirus v7 Upgrade to v7 breaks activation for v.1.8.2211.0 as well as previous version 1.7.1991.0 Subsequent activation tasks fail Uninstall/reinstall does not resolve the issue. Have not had any follow up from support yet.

Also just confirmed that a clean install succeeds, so something specific to the upgrade is causing the failure.

The esets_daemon file does not exist in this directory, so throws a "command not found" error.

Thanks, @Marcos I'm using the same install task as I've used for the past several upgrades, and it's using the same license as it's used for all previous upgrades. The install task when created automatically chooses the correct license file. So if the product is activated, an upgrade to the product using the same license will require a re-activation? I'll work on collecting the logs.

@Marcos I will try. I haven't had much luck with Level 1 support in the past. I'm also finding the same issue on Windows Servers now, too. The upgrade from 1.7.1991 to 1.8.2211.0 is successful, but then the license check immediately fails, causing the product to become deactivated. I see the following in the EIConnector logs: 02fd4 Error: Failed to enable additional hashes or clean metadata cache in endpoint. Request to ESET Endpoint Security/Antivirus failed. Error PERSEUS_E_EI_DISABLED_IN_CONFIG_ENGINE (21803) followed by 2022-10-26 15:31:39 0276c Error: License check failed. Try 1 out of 5. Request to ESET Endpoint Security/Antivirus failed. Error PERSEUS_E_EI_NO_LICENSE (21801) 2022-10-26 15:31:39 0276c Error: License check failed. Try 2 out of 5. Request to ESET Endpoint Security/Antivirus failed. Error PERSEUS_E_EI_NO_LICENSE (21801) 2022-10-26 15:32:39 0276c Error: License check failed. Try 3 out of 5. Request to ESET Endpoint Security/Antivirus failed. Error PERSEUS_E_EI_NO_LICENSE (21801) 2022-10-26 15:32:39 0298c Error: Failure to obtain banned hashes version. Request to ESET Endpoint Security/Antivirus failed. Error PERSEUS_E_EI_NO_LICENSE (21801) 2022-10-26 15:32:39 0298c Error: Error while sending control request to server at "xxx.x.xx.x:8093". banHashes: Request to ESET Endpoint Security/Antivirus failed. Error PERSEUS_E_EI_NO_LICENSE (21801) 2022-10-26 15:33:10 0298c Error: Failure to obtain banned hashes version. Request to ESET Endpoint Security/Antivirus failed. Error PERSEUS_E_EI_NO_LICENSE (21801)

This happened last time I tested v7 on an OS X client. v7 was an earlier release and the EEI connector was an earlier version, as well. I just ran an OS X AV upgrade from v6 to v7 with EEI connector 1.7.1991.0. The AV upgrade completes successfully, but the EEI connector goes into a 'not activated' state. I can run an activation task, it completes successfully, but EEI connector still shows not activated even after several reboots. Is this a known issue?

Thanks for the follow-up. It did finally complete successfully after a little over 2 hours. This was an upgrade from just the version prior (1.7.1991.0). And the fifth upgrade we've done. Never had one take anywhere close to this long. Makes me wonder if some database maintenance is needed and what that might look like.

How does one monitor the activity on the database side? The database_install_log file last entry only shows the following: "q":"CALL proc_execute_update_procedures('1.8', '2022-06-16', 'update_processes_table')" That last entry was over an hour ago.

I've a feeling it's stuck. Past upgrades have usually taken less than 15 minutes. This one still hasn't moved in over an hour. There are no updates to the server log file, nor the database install log file since the start of the installation. I will let it go for now with fingers crossed.

How long is the upgrade expected to take? Ours has been stuck at 92% for about 40 minutes: "Updating database: 92% (Creating partitions for process table)." I'm a little hesitant to cancel, but it doesn't appear to be going anywhere.

I'm mainly curious where the agent pulls this information from? The list of 'Installed Applications' is more inclusive than what is present under the /Applications folder. Where does this information come from? TIA

I've got 50 Windows servers, all getting the same ESET policies and AD group policies. Ten servers are not updating their license status and show expiring. I apply the same license to all devices, but for some reason these servers did not pick up the new license in several weeks' time. I upgraded the agent to the latest version and this made no change to the status. For several, I ran the 'Activate Product' task. For some, the tasks are still running after 40+ minutes, though the 'History' details on the task shows it has finished successfully and the license has updated. However, those with updated/correct licenses are still flagged with a warning due to expiring license for some reason. On several others, the activation task has completed successfully, but the license is not updated. Everything looks fine in EBA. I can't tell 1) why some are not pulling the updated license, and 2) why those that do pick up the correct license still report expiring license.