Jump to content

j-gray

Members
  • Posts

    620
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by j-gray

  1. On-prem EP Console had a Server task for Agent Deployment. I'm not finding this option in the EP Cloud console. Is it no longer available? If no longer available, what are the options for deploying the agent and why was this functionality removed?
  2. Deleting the data.db file broke the sync entirely, so I restored it. I removed and recreated the ADScanner directory, which essentially cleared the cache, started fresh and got everything sync'd correctly. Unfortunately, it seems to have broken again and newly sync'd workstation objects are going into Lost & Found again. Still no errors and still does not appear to sync all the workstation objects that it's finding.
  3. Best I can tell, the sync appears to have broken, despite showing no errors in the logs. Any of the more recently migrated systems are going directly to Lost & Found. Is there a way to flush the cache and make it start clean? Can I simply delete the 'data.db' file and rerun the sync?
  4. @Peter Randziak I see that the documentation has been updated already. That's awesome! 👍
  5. I also just noticed that the Cloud console shows only 989 workstations total, while the adscanner log files show, "Loaded computers: 1662" I've made sure that no filters are active. Is there any way to tell why the missing 673 workstations aren't registered in the Console?
  6. We've just migrated to the cloud and implemented the Active Directory Scanner. I'm having an issue where around 180 enabled/active workstations are being sync'd to Lost & Found instead of the correct Cloud OU. Some of the workstations in 'X' OU are successfully sync'd to the correct corresponding 'X' OU in the Cloud. Others in the same 'X' OU are going to Lost & Found. The sync is running successfully. No errors are shown in the adconnector log file. I've run several manual syncs, as well but still no change. I've verified the hostnames and FQDN are correct between AD and the Cloud console. Is there any way to tell why some workstations are not going into the corresponding Cloud OU?
  7. @Peter Randziak Ok, if I understand correctly, you're saying that the Bridge can cache updates (modules, product updates), etc.) for OS X as long as the requests are via HTTP and not HTTPS? If that's the case, then great. The documentation is a bit confusing, then, as there's no mention of HTTP traffic and the only list of supported products I could find were Windows and specifically not OS X. Thanks again for you help. I appreciate your presence here, as well as the other ESET folks.
  8. @Peter Randziak Thanks for the reply. The document you linked looks like firewall info, so does not appear to be relevant. ESET's bridge documentation, lists support only for Windows platforms and states specifically, "ESET Bridge does not support HTTPS traffic caching for ESET security products (and their versions) not listed above—Linux/macOS security products and earlier Windows security products." I'm primarily interested in caching downloads and updates, but from everything I read, only Windows and Linux clients are supported. Meaning that we can't cache anything for OS X clients.
  9. Also curious why the AD Scanner requires the 'Agent GPO Deployment Script' in order to run? What purpose does it serve? For reference, here's the error presented when the file is not present: 2023-09-01 10:52:31.8371 ERROR ActiveDirectoryScanner Program failed with error System.Exception: Please ensure GPO configuration C:\adscanner\ActiveDirectoryScanner\install_config.ini is present. at ActiveDirectoryScanner.GPOScriptLoader.LoadConfigruation() in d:\jenkins\workspace\ADScanner\src\Products\RemoteAdministrator\Src\Tools\ActiveDirectoryScanner\ActiveDirectoryScanner\GPOScriptLoader.cs:line 187 at ActiveDirectoryScanner.Program.Main(String[] args) in d:\jenkins\workspace\ADScanner\src\Products\RemoteAdministrator\Src\Tools\ActiveDirectoryScanner\ActiveDirectoryScanner\Program.cs:line 294 2023-09-01 10:52:31.8682 INFO ActiveDirectoryScanner Program finished
  10. First time running the scanner throws a fatal error, "The required library hostfxr.dll could not be found." and directs to the .Net Core runtime page. So I downloaded the Core Runtime 7.0.10 version (documented as prerequisite). On the second run, I got the same hostfxr.dll error. Google indicated that the .Net Runtime 'Hosting Bundle' (not x64 package) install fixes this issue. After installing the 'Hosting Bundle', on the third run it finds the 7.x framework, but then I get, "To install missing framework, download..." This download link points to the .Net Core 3.1 runtime, which is flagged by Microsoft as end of life and no longer supported. Is this the case that Active Directory Scanner will only run with a deprecated version of .Net?
  11. Are there any plans to add OS X support for the Bridge? Or is there an alternate solution that allows caching for OS X clients? We had this functionality with Apache HTTP Proxy, but looks like that's being sunsetted and the functionality is removed from the new version.
  12. I'm seeing now that the latest EI Server version is 1.11.2882.0. But the OS X EI Connector install is a later version thatn the server: 1.11.2883.0 Is this expected and/or problematic?
  13. A new version of EI Server was just released, version 1.11.2882.0. The Windows client install task latest version is the same. However, the OS X client install task shows a later Connector version, 1.11.2883.0. The 1.11.2882.0 version is not available in the client task. Is it expected to have a later version of the Connector than what the server is running?
  14. So it turns out that the "RUN_LOOP_ERROR RUN_LOOP_TIMEOUT (2)" log entry is significant after all and apparently indicates a timeout in the license check process, and thereby successful activation (or not, in this case). Support indicated that 10s is the default timeout. I've had to increase the timeout to 90s for OS X clients to remain activated. So in the eiconnector.policy.ini file we added a line: EndpointLicenseRequestsTimeout=90s I'd really like to understand: Why does this issue only affect OS X devices and not Windows PCs on the same network? What is the client attempting to contact for the license request? Is it EI server, EP server, Internet? Why must the client check activation status multiple times every day? It seems excessive if it's already successfully activated and the license is good for however many months.
  15. @jimwillsher We're in the same boat and contemplating a move and beginning to look into it. I'm curious if there was a specific catalyst for your move? Aside from platform management, updates, etc. do you find any different features or advantages? Appreciate any feedback.
  16. We've been on .2872 for a few weeks, as well. I only noticed the update as it was flagged in the EP Console on the clients as having a newer version available, seen in each clients' list of "Installed Applications". And when I looked at the 'Software Install' tasks, the newer Connector version was available as an option to install. It has since been removed and is no longer available/visible in the EP Console.
  17. Yes, this is why I was looking for the server download. The clients all showed the update available but the server had not been updated. So what happens when auto-update causes the connectors to update before the server has been updated as in the case of @avielc? This is a perfect example of why we cannot rely on the auto-update feature.
  18. ESET Protect is showing a new version of the EI Connector and the software install tasks are also showing 1.11.2878.0 available. However, I'm not finding the updated server version on the download page. The latest available for download is 1.11.2872.0 Also, the changelog only indicates: Fixed: Performance issues Fixed: Reliability issues Are there any more specifics available for this version?
  19. @Peter Randziak I have a question that support hasn't been able to address. I'm frequently finding that on the systems that have failed to activate repeatedly, when I go through the steps to enable ECP logging, the same activation task completes successfully when ECP logging is enabled. Essentially, the steps are bootout com.eset.protection.plist, edit the two license files, pkill licensed then bootstrap the eset plist. Something in this process allows the activation to succeed. Any thoughts what specifically might affect this? Thanks again.
  20. Thanks @Peter Randziak Case #00444283. Still waiting for a reply so I can upload more log files.
  21. Yes, I've had a case open since October of 2022. Right now I've been waiting almost a week for support to provide a location where I can upload more logs.
  22. I see this repeated in the EI Connector logs every 1 to 4 seconds: Error while receiving LiveGrid data. Direct host: "c.eset.com", Direct port: 80, Proxy host: "", Proxy port: 0. Error code: 3. Network is down The workstation can ping c.eset.com and hit everything else I've tested on the Internet. Can anyone clarify what is the source of this error and how to rectify it?
  23. I would expect if you upgrade the agent to the latest supported version that everything will work as expected. EP v8.0 is already end-of-life. I would not expect an agent that old to work flawlessly with the latest version of EP. Per ESET release notes, "We recommend using the latest ESET Management Agent version to fully manage the latest version of ESET security products and their features." Is anything prohibiting you from upgrading the agents?
  24. Same here on a server. All three applications are outdated, though only one is flagged in yellow:
  25. @Marcos That is correct. And it is flagged yellow, as expected because it is outdated. However (and this is the issue) you may not have noticed that ESET Server Security is outdated, as well. Yet it is not flagged yellow.
×
×
  • Create New...