Jump to content

j-gray

Members
  • Posts

    620
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by j-gray

  1. 12 minutes ago, avielc said:

    Could it be related to the EEA\EES installation?  (Can't figure why you would run into the issue still. 

    Quite possible. With all the constant upgrades (agent, endpoint, connector), plus OS patches and upgrades it's a wonder anything actually works.

    On the random handful I've checked, all seem to report the previous issue with RUN_LOOPERROR RUN_LOOP_TIMEOUT. And I just noticed the 'Event Statistics, From:, 1969-12-31 17:00:00'

    This is what I was encountering on my Windows Server upgrades. I was able to reliably reproduce this with each EI Connector upgrade on the servers. However, Engineers couldn't/didn't produce a fix. Appears it's happening on my OS X clients now, too.

    The Server fix was uninstall/reboot reinstall the connector. Not sure what is causing the corruption. Would be great to know.

  2. 21 hours ago, avielc said:

    I'm trying to think if something like communication to external network could be an issue for computers in your network? 

    After some testing, it seems the EI connector will now install successfully with the license file specified, so that's good.

    I don't believe the other issues are network related, as the clients are fully functional otherwise -meaning they run all ESET tasks, get definition updates, check in regularly, and appear as normal in the EI Console.

    And, at least in the case of my OS X device, it is activated and happy for some time, but then fails with the following:

    0x70000a021000 Error: License check failed. License no longer active. Failed to process a request to/from ESET Endpoint Security/Antivirus. RUN_LOOP_ERROR RUN_LOOP_TIMEOUT (2)
     

    Typically a reboot will resolve this error, but it still remains a recurring issue. I'm still in the process of troubleshooting, but those that won't activate run the activation task successfully but refuse to activate.

    Troubleshooting is difficult, as systems are at other sites and may be in use or powered off and I can't continually disrupt our clients' work to uninstall/reboot/reinstall/reboot, etc.

  3. @avielc Thanks for the info. In our environment, we've not touched the server.xml file, nor do we use a proxy.

    If I include the license file with the EI Connector install task it runs for quite some time, then eventually reports failed on OS X clients, even though it completes successfully. For this reason, we run the activation task after the EI Connector install.

    We currently have a mix of v6 and v7 OS X installs and are in the process of upgrading all to v7. The issues we're experiencing affect both versions, however.

    For EP Console, we're running the latest version along with the latest agents. We have zero issues with Windows clients (thankfully).

    I'm curious if your ESET Inspect license usage is reported accurately in EP Console? For us, we show 675/1600 whereas EES licenses are 1517/1600, which is more accurate.

  4. Unfortunately, I can't say there is any improvement from my side:

    1. I have ~150 OS X clients that show EI Connector is not activated.
      • EI Connector upgrade succeeds, but activation task either completes but does not successfully activate OR runs for 24-hours and times out with unsuccessful activation.
    2. I have ~150 OS X clients where EP Console shows EI Connector is not installed even though it is installed (usually shows EI Connector is not activated.
      • EI Connector upgrade succeeds, but EP Console still does not list the application or show that it is installed. They also remain in the dynamic group where EI Connector is not installed, despite being installed.
      • In these cases EI Connector may or may not be activated. If not, EI activation tasks typically runs for 24+ hours before failing.

    There still appear to be issues with licensing, as ESET license management shows less than half of my EI licenses consumed, despite having a full install base.

    The short of it is that one third of our OS X fleet is still sideways.

  5. Well... still seems to be a mixed bag. We still have ~150 OS X clients that refuse to activate. And some that have successfully activated in the past and have been activated for some time become inactivated.

    Any activation task seems to run for at least a day before it times out. Other tasks run without issue. Uninstalling and reinstalling the connector does not resolve the issue.

    I'd also hazard to guess that the EI licensing is still not working properly --we're currently still using only 655/1600 Connector licenses where we should be closer to the full 1600.

  6. It's odd, because the the icons (eg Desktop, Agent, Connector) are displayed correctly next to the computer name indicating the component is installed, but it doesn't show in the application list and of course (negatively) affects dynamic groups that group computers without the component installed.

    I was hoping that upgrading the connector to the latest version would update it in the console, but no luck there, either.

    Is this another known issue that might be addressed in future releases?

    Otherwise, I'll have to see if I can find a way to reliably automate clearing the cache via the EP console. 170+ clients is too many to address manually.

  7. So far, the activation issues have been cleared up for the most part.

    I'm still faced with the following OS X issues, however:

    1. EI Connector installation still reports failed if/when license is specified in the install/upgrade task.
    2. Activation issues appear to be somewhat better, though quite a few activations still fail
      • Typically this shows as Task Started > Task Finished Successfully > Task Timed Out. In these cases, product activation fails.
      • Frequently, EI Connector activation task shows running for 24+ hours
    3. EI Connector does not show as installed under Installed Applications in client details even though it is installed.
      • I was hoping the upgrading the EI Connector would get it to register again, but no luck
      • We have approximately 160 clients where EI Connector is installed but EP Console does not reflect this.
    4. We seem to have a huge increase in failed agent and connector installs and upgrades for OS X only due to repository inaccessibility with the following: Failed to synchronize package repository. See trace message for more details. GetFile: Cannot connect to host 'repository.eset.com' [error code: 20003]

    Not sure why the recent connectivity issues. They seem quite random, yet persistent.

  8. I have about 175 OS X clients (mix of v6 and v7) with the latest agent (10.0.3091.0) that do not show EI Connector installed in EP 10 Console when displaying the list of installed applications. This also throws them into a dynamic group for clients w/o EI Connector installed.

    EEI Console shows the EI Connector installed and functional. Subsequent EI Connector activation tasks run and complete without error.

    And, in fact the 'EI Connector' icon appears next to the hostname along with the Agent and Desktop icons that indicate the product is installed. For some reason it does not appear in the list of applications and lands in the dynamic group as if no EI connector is installed.

    What is causing these clients to appear to not have the EI Connector installed when it is, in fact installed?

  9. Just to add some further information. If I run the PROTECTAgentInstaller.sh task manually, I can see it attempting to connect and download from: hxxp://repository.eset.com/v1/com/eset/apps/business/era/agent/v10/10.0.3091.0/agent_macosx_x86_64.dmg

    However, eventually it returns:

    curl: (28) Connection timeout after 300004 ms
    Failed to download installer file

    Again, these systems can all ping repository.eset.com they just can't download the file (or definition updates, for that matter).

    So far this seems specific to OS X v7 clients.

    Any idea what might be getting in the way of this connection?

  10. I updated the OS X agent upgrade task (as always after an EP upgrade) to update the reference server to the new v10 instance. Since the EP Server upgrade, the majority of OS X agent upgrade tasks have been failing with either one of the errors below:

    GetFile: Host 'repository.eset.com' not found [error code: 20002]

    GetFile: Cannot connect to host 'repository.eset.com' [error code: 20003]

    If I terminal to any of those systems, they all get a ping response from repository.eset.com. This has been happening for about a week.

    Win10 and Windows Server agents upgrades are running around the same timeframe and are installing successfully and without errors.

    Any ideas as to what may be causing this?

  11. 4 hours ago, Peter Randziak said:

    I checked it with the support guy and the assumes, that the licensed hasn't been killed.
    Can you please check if you have killed it as stated at the line 4. "kill licensed service > find its PID via ps aux | grep licensed and kill -9 PID" ? 

    It seems that the steps to create the ECP log files are working for @avielc as he was able to obtain them.

    @Peter Randziak I ran through the steps again, paying close attention to step #4; grep returns two licensed processes. I kill both and rerun the grep command to ensure no other licensed processes are spawned. None are returned. As soon as I issue the 'sudo launchctl start com.eset.protection', two new .json files are generated with logging set to false (and of course read/write permissions removed).

    And, same as before, the Activation task reports completed successfully within seconds. The log files look the same as above with the "license state check started" (but no reported results) and the same "unknown connection id received" errors.

    EP console still does not report an EI activation error state, however.

  12. ...in addition; problem with the license files. After changing the logging to 'true', the files are recreated (I assume when the ESET process is restarted) and new file are generated with logging set to 'false'.

    In the debug logs, I can see now that the licensing attempts are failing again with the RUN_LOOP errors, but EP console still does not show error/inactivated.

  13. Hi @Peter Randziak I'm afraid I didn't have much luck. I followed the steps outlined. After 30+ minutes, the EI Connector does not report as inactivated in the EP Console. However, log files indicate that check 4 of 5 failed, then I see this repeated:

    2023-01-31 14:36:13 0x700002f43000 Debug: LicenseStateManager: license state check started
    2023-01-31 14:36:21 0x7000031d2000 Debug: Control Checker received HTTP status response (408).
    2023-01-31 14:36:31 0x700002819000 Debug: Periodic task FullDiskAccessCheckerTask is starting
    2023-01-31 14:36:31 0x700002819000 Debug: Periodic task FullDiskAccessCheckerTask has finished in 0.0 seconds
    2023-01-31 14:37:14 0x700002f43000 Debug: LicenseStateManager: license state check started
    2023-01-31 14:37:15 0x70000314f000 Debug: Unknown connection id received (28850) for event EVENT_PROCESS_IP_CLOSE
    2023-01-31 14:37:31 0x700002819000 Debug: Periodic task FullDiskAccessCheckerTask is starting
    2023-01-31 14:37:31 0x700002819000 Debug: Periodic task FullDiskAccessCheckerTask has finished in 0.0 seconds
    2023-01-31 14:37:32 0x70000314f000 Debug: Unknown connection id received (28233) for event EVENT_PROCESS_IP_CLOSE
    2023-01-31 14:37:51 0x7000031d2000 Debug: Control Checker received HTTP status response (408).
    2023-01-31 14:38:14 0x700002f43000 Debug: LicenseStateManager: license state check started
    2023-01-31 14:38:14 0x70000314f000 Debug: Removing stale connections: 1/393 removed
    2023-01-31 14:38:27 0x70000314f000 Debug: Unknown connection id received (29658) for event EVENT_PROCESS_IP_CLOSE
    2023-01-31 14:38:31 0x700002819000 Debug: Periodic task FullDiskAccessCheckerTask is starting
    2023-01-31 14:38:31 0x700002819000 Debug: Periodic task FullDiskAccessCheckerTask has finished in 0.0 seconds
    2023-01-31 14:38:37 0x70000314f000 Debug: Unknown connection id received (28716) for event EVENT_PROCESS_IP_CLOSE
    2023-01-31 14:39:14 0x700002f43000 Debug: LicenseStateManager: license state check started
    2023-01-31 14:39:21 0x7000031d2000 Debug: Control Checker received HTTP status response (408).

     

    In addition, I do not find an 'ecp' folder under /licensed. Just the two .json files along with two corresponding .lf files.

    And to confirm, all products are activated via network, nothing offline.

  14. @Peter Randziak Thanks for your help with this -I greatly appreciate your time and efforts.

    1) EI connector shows Inactivated in EP Console. Both EP and EI consoles show connected within the last minute, however, EI Console shows last event over a day ago when it started throwing the RUN_LOOP errors. Just FYI; it does show events sent successfully to the EI server, it's just that there are zero events listed.

    2) In the 'licensed' folder I have license_cfg_112.json from the reboot on 01/25 and license_cfg_322.json from yesterday (12:02 a.m.) when the errors began occurring. The files are slightly different (see attachment).

    3) The '322' file is the one created when the RUN_LOOP errors began.

    image.png.0807c8c7fa9b1b108b051090e4e1d93d.png

  15. 6 hours ago, avielc said:

    Hi Peter, 
    I might be missing something  here in the logic. 
    Basically when removing everything, and installing from scratch, EPv10 (Console) reports everything is working right. 
    After a while the "EI not activated" status appears. - Assuming this is the same issue with RUNLOOP
    The solution you mentioned doesn't seem to be effective at all, as Sending activation task from EP makes the task get stuck \ fail. Even if it succeeds, the machine still has the "EI not activated" status.

    I'm seeing the same; activation task has been running for 10 hours.

    Interestingly, a reboot clears the error/activation state for a number of hours. It looks as if it's good/activated until another license check is triggered, at which point it reverts to the RUN_LOOP_ERROR cycle and becomes inactivated again.

  16. @Marcos -Thanks for the reply.

    1) We run a typical v7 install task via the EP Console. For the most part, right now we're only running v7 installs on systems that are new and have no AV installed. In some test cases that already have v6 installed, we run the v7 install task without the reboot option. Rebooting does not seem to resolve the critical status issue.

    If we manually remove the Web&Email network service, then reboot, ESET prompts again to install the network service. In that case, the warnings clear. Again, this isn't really a viable process with 800+ clients.

    2) Yes, statuses look exactly as displayed in your screen-cap.

    I gather that the recommend upgrade process may be 1) uninstall v6, 2) reboot, 3) install v7?

  17. 1 hour ago, Marcos said:

    You should be able to remove Web and email protection by running:
    sudo /Applications/ESET\ Endpoint\ Antivirus.app/Contents/Helpers/ESET\ Web\ and\ Email\ Protection.app/Contents/MacOS/ESET\ Web\ and\ Email\ Protection --uninstall

    After a reboot close the window asking about extension installation.

    Unfortunately, not a viable solution for 800+ OS X clients.

    We don't have this issue with Windows clients that have Web & Email protection disabled. I'm curious why the issue is specific only to OS X?

    If the policy is set to not display the those statuses on the endpoint, why does it still display those statuses on the endpoint? Would this be considered a bug?

  18. 5 hours ago, Peter Randziak said:

    Hello @j-gray,

    So you have the latest EEA for macOS v7 and EI server and connector on the latest versions too? 
    The product specialist is trying to reproduce the issue.
    With EEA from macOS 6 latest and EI connector 1.9 everything works without any issues.
    If it will stay this way, an upgrade to EEA for macOS to v.7 will be performed to see how it behaves on it...

    The hotfix mentioned above is on QA now, hopefully it will address most of the issues reported

    Peter

    Yes, this is specific to OS X with EP v7 and latest EI server/connector v1.9. EI Connector is successfully activated for some time, then reverts to inactivated with the 'RUN_LOOP_ERROR RUN_LOOP_TIMEOUT' errors logged repeatedly.

×
×
  • Create New...