Jump to content

zhopkins

Members
  • Content Count

    17
  • Joined

  • Last visited

  • Days Won

    2

zhopkins last won the day on July 28 2016

zhopkins had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Marcos, the clients in question are all servers. They are online 24/7 and check-in every few minutes to ESMC.
  2. Martin, We restarted the ESMC server late last night, in hopes it would help the task to run at its scheduled time this morning. That did not help. However, restarting the client machines that were supposed to run the task, did help. Once restarted, the client machines immediately began to run the task. I also verified that the task UUID shows up in the trace log, and sure enough, it was right there on every single one (showing "generate a tick for a missed event", timer registration for the next occurrence, and the actual task execution). Your note about this being more like
  3. Even when changed from a CRON expression to just a weekly event, the clients are still not running this weekly task. I can manually select any client, and add the task with an "As soon as possible" trigger, and the client will begin execution immediately, so the overall task is fine, its just that the reoccurring task simply doesn't run on a random portion of the assigned clients. If anyone has any suggestions at all, it would be much appreciated!
  4. MichalJ's suggestion worked for us. We marked all of the related firewall alerts as resolved, and then modified our server policy to have the Log, Block, and Notify options set to "No", and it has been quiet ever since. B-G, just to confirm - if you open the File Security client on one of your machines and check its setup, I assume that you can see your desired IDS configuration there, with all of the options set to No? (Just making sure that it received the corrected policy)
  5. Yes, we're seeing this behavior too. After setting the first batch of alerts in ESMC, I found this post. I then added the policy exception (any alert, with a specific remote address, all other options at default), and marked the old threats as resolved. 24 hours and another Nessus scan later, and the alerts are back.
  6. We've setup a client task to install OS updates on a weekly basis to a select group of servers, but for several clients this task still shows as planned, never executed. We've gone through two weeks now, and the task still hasn't executed, with seemingly no explanation as to why. The client task runs the "Operating System Update" task. "Automatically accept EULA" is checked, "Install optional updates" is un-checked, and "Allow reboot" is checked. The trigger is applied to 25 individual clients, with a CRON schedule, "0 0 3 ? * FRI *" (Every Friday at 3am), no random delay, "Invok
  7. Has anyone else seen this warning message from Google Chrome? The message could be closed by typing in a different web address or re-launching the browser. The machine in question is running Windows 10 Education (1703), Eset Endpoint Antivirus 6.6.2072.4, and Chrome 67.0.3396.87. We're still testing Windows 10 build 1803, which won't go out for another month or so. We're also testing Eset 6.6.2078.5, which should be pushed out within 2 weeks, but I'd like to make sure that we're not about to get bombarded with a headache. Thanks!
  8. While the instructions provided in KB6512 work to manually enable the System Extension for Eset, are there any plans to automate this process for new installs or upgrades from ERA? We have 200+ computers running MacOS and the end users do not have administrative rights by default. We'd like to be able to push out the latest version of Eset Endpoint Antivirus (6.5.432.1) from ERA as folks transition from earlier versions of MacOS and Eset, but if they're going to be prompted to do something that they don't have rights to do, then that puts us in a bit of a pickle, adding additional work a
  9. For reference, the agent status page on macOS is located at /Library/Application Support/com.eset.remoteadministrator.agent/Logs/status.html.
  10. For reference, we've seen similar results in our environment. Most Mac clients would show up in ERA with a ".local", while a few would show up with the FQDN. We also had the added issue that some of our Macs were missing local configuration options, and while they would allow for Active Directory logins, their hostname (via command line) would not always match what was configured via the GUI, nor would they always show the FQDN. The quickest workaround that I found to eliminate duplicate computer accounts in ERA for our Mac clients was to alter the task on the ERA server that renamed syn
  11. If you're looking to upgrade the management agent on your clients, or the server components on your server, there is a built-in task to do this. The "Remote Administrator Components Upgrade" client task will upgrade these items for you. When applied to a regular client (a workstation or file server), the ERA agent will be upgraded to match your ERA server. When applied directly to your ERA server, it will download and install the latest server components from Eset. It usually takes a few minutes for the clients to upgrade, depending on your connection interval, but the last server upgrade
  12. It took a little bit of fiddling, but I've been able to get Regex working in several of our templates. I've built most of my RegEx strings through sites like regexr.com or regex101.com, with some slight modifications to signify the beginning and the end of the strings. 1) Looking for clients that have some point-release of a version 5.x client installed (i.e. any 5.x version): "Installed software.Application version" → RegEx → "^5.\d.\d{4}.\d$" 2) Looking for clients that do not have "Server" in the operating system name: "OS edition.OS name" → RegEx → "^(?!.*Server).*$"
  13. We have several dymanic templates for machines without Eset installed. This allows for our technicians to install the ERA agent, and then the actual antivirus installation is handled automatically by the server. As an example, here is a template for computers that do not have the Eset Endpoint Antivirus Client installed. This can easily be adapted for Eset's other products. I have not specifically seen anything that would allow for the detection of failed installations, following an install attempt from this dynamic group, though maybe others have found ways to do this.
  14. Has anyone heard of plans to release an updated version of Eset File Security for Linux? Running on CentOS 7, the ERA v6 agent seems to run fine, but none of the settings from ERA are applied to the antivirus program, nor am I able to get the real-time file scanning working. Thank you!
  15. Unchecked, you say... It was checked in our policy. Looking back, I see that there is not a matching check box for the Windows antivirus clients. Since it was present for the Mac clients, I figured it had to be checked in order for that section of the policy to be active. Whoops! Thanks for your help!
×
×
  • Create New...