jkknight

Just a bit of an update - I have turned off the proxy settings for both the server and the clients to force it to connect to the ESET update servers. The IP it is trying to connect to is 38.90.226.39 (um10.eset.com) - our trace route is below. traceroute to 38.90.226.39 (38.90.226.39), 64 hops max, 72 byte packets 1 internal gateway 0.727 ms 0.299 ms 0.320 ms 2 external IP 2.635 ms 1.843 ms 1.826 ms 3 xe0-0-1-0.agr01.chrx01-nc.us.windstream.net (169.130.167.181) 1.772 ms 1.846 ms 1.771 ms 4 xe5-3-3-0.pe07.chrl01-nc.us.windstream.net (40.130.35.235) 1.846 ms 1.800 ms 1.798 ms 5 et8-0-0-0.cr02.chrl01-nc.us.windstream.net (40.128.248.160) 1.994 ms 1.873 ms 1.857 ms 6 ae8-0.cr02.atln02-ga.us.windstream.net (40.132.59.32) 6.668 ms 6.884 ms 6.748 ms 7 atl-bb1-link.telia.net (80.239.194.9) 9.330 ms 6.900 ms 7.227 ms 8 cogent-ic-332070-atl-b22.c.telia.net (62.115.157.143) 7.496 ms 7.030 ms 7.108 ms 9 be2848.ccr42.atl01.atlas.cogentco.com (154.54.6.117) 7.345 ms 7.144 ms 7.220 ms 10 be2690.ccr42.iah01.atlas.cogentco.com (154.54.28.130) 25.962 ms 26.054 ms 26.013 ms 11 be2928.ccr21.elp01.atlas.cogentco.com (154.54.30.162) 48.273 ms 48.148 ms 48.334 ms 12 be2930.ccr32.phx01.atlas.cogentco.com (154.54.42.77) 57.055 ms 56.960 ms 56.720 ms 13 be2941.rcr52.san01.atlas.cogentco.com (154.54.41.33) 57.064 ms 57.313 ms 57.108 ms 14 te0-0-2-3.nr12.b036483-1.san01.atlas.cogentco.com (154.24.24.186) 57.663 ms 57.534 ms 57.488 ms 15 38.88.58.18 (38.88.58.18) 57.646 ms 57.685 ms 57.940 ms 16 um10.eset.com (38.90.226.39) 57.239 ms 57.650 ms 57.257 ms The client still says that the download is interrupted... I can ping that IP address from inside our network so I know it's not an issue with the connection being made. I am actually able to watch the ekrn.exe process make the connection over HTTP and then it kicks off several HTTPS connections to several different IP's which I assume are where the modules are to be downloaded from?

I am having this same issue with EPS for Windows, but we are not using the mirror function as recommended. The last successful update for this machine was Aug 3 which was the last time it was used. Just installed 6.62086.1 on a machine that had the previous version and was getting module updates fine. After upgrading to newest release the "updating product" just sits as if it's trying to connect to the server and will eventually fail (or time out). I've cleared the update cache under UPDATE>GENERAL, changed UPDATE>PROFILES>BASIC>update type to pre-release, uninstalled and reinstalled EPS, made sure that UPDATE>PROFILES>BASIC>UPDATE SERVER was set to choose automatically and checked that the Firewall was not blocking anything important. The Event Logs show that the download was interrupted by user NT AUTHORITY\SYSTEM Is there anything I am missing to double check?

are they part of an Active Directory Domain? I've noticed that my Mac's have some interesting behavior in our AD domain and I have only been able to pin it to 'stale records' cleanup in DNS. The name records get stuck with a specific IP address and do not get flushed - so in a reverse look up query the DNS reports the Mac's FQDN with the stale name records. I wonder if the same kind of thing is happening with your DHCP server? I do have the same thing happen with some of our Mac's at times. Most of them resolve after a little while, but some do not. I have one newer MBP that will only report its IPv6 address even though the IPv4 address shows in it's detail page.

I can't believe I'm derailing my own thread... UPDATE: to the original machine issue.. I spoke with the user this morning - she stated that she shuts down her machine at the end of everyday and starts it up when she first gets into the office. So yesterday the product was reporting the error - today it started up and is reporting as normal. I guess the place for me to start is to see if the daemon is starting correctly as part of the startup daemon. Or is the ESET Agent/Client daemon starting up outside of the startup daemon (ie. not connect to)?

We are running ESET Endpoint Antivirus 6.5.600.1 from https://www.eset.com/us/business/endpoint-security/mac-antivirus/ ? machine is running macOS 10.13.4

Thanks Martin good to become aware of all of those contexts. There doesn't seem to be much documentation for the things you listed out... thus the reason for creating this topic. Regarding this specific issue - I have had this happen on other Mac's, one of which is my test machine. To remedy the issue only thing that was done was to restart (actually sometimes took multiple restarts) the machine and the client started up normally. There have been a few instances where restarting the machine does not actually auto-start the ESET daemon. I'm still trying to figure out why this is the case. But, the problematic machine discussed above was running an older version of macOS when the ESET Agent/Client was installed and only recently had been upgraded to the latest macOS 10.13. So, unless one has to manually approve the ESET kernel after an upgrade (I have not experienced this - only occurs if ESET is being installed on top of macOS 10.13) I have to wonder if there is some type of corruption going on. Which would seem strange since ESET has been running on this machine for close to a year with no 'known' issues. This is why I thought maybe the daemon did not start correctly or needed to be restarted...

Ok, so just had a pretty specific scenario where a managed Mac has Endpoint Antivirus installed, but is throwing off an error "Product installed but is not running"(see below). So I got to thinking there is a way, via creating a task, to run a command on the remote machine by which I could force the ESET client to start. But, what commands to run... would you just simply run the ' open -a ESET Endpoint Antivirus ' or run a command to start the ESET daemon - ' launchctl load -w /Library/LaunchDaemons/com.eset.esets_daemon.plist ' . And I assume that last command would need to be ran as the ' root user ' ie ' sudo ' ? Does anyone have some experience in running an ERA 'run command' task on a remote Mac client? Are there any other useful commands that can be used for the remote client?

Thanks Peter - With ERA being a sudo MDM has anyone figured out if there is a way to create a valid MDM profile on remote Mac's via ERA? Are ESET's extensions "properly-signed"? I'm not utilizing imaging to distribute ESET - I send an email for everyone to install the Remote Agent (.tar file and Terminal) for me and when I see them in ERA I then remotely install Endpoint Antivirus.

Yeah not really the workaround I was hoping for... I had already used that option and we didn't want to leave ourselves open to a new vector just because our users were getting annoyed. I'll keep trying out different exclusion arguments until I find one that works I guess. Thanks Fo

I have excluded these 2 directories so far with no luck

I'm having the same issue as I am currently deploying ESET Antivirus client to all Mac's in our environment. I have the Remote Agent installed and then push the AntiVirus install but it never reports back after successful installation because of the 'ESET extension block'. This kinda defeats the purpose of me installing remotely since I now have to go around and touch each machine to 'Allow' the extension. Is there not a way for you guys to submit your software keys to Apple so that the OS does not think this is a rogue program? All our Mac's are set to 'Allow App Store and identified developers' - seems like an easy solution since only Mac's that are running the latest macOS High Sierra are the ones experiencing this issue. Machines running macOS Sierra and below install/run fine.

Would really like to know what the workaround is for this issue. I just spent 10 minutes clicking through about 50 windows that were from yesterday / overnight snap shots... I also have other Mac users now coming after to me because they are having to do the same.

Can I get the work around posted for this issue? I made some changes to our policy for the Macs and now every hour the warning window pops up and I can not figure out how to exclude it via the policy.

We do not need to use these functions of Endpoint Security (we run a server-side SaaS Reflexion) that does this for the client, so I disabled these in the policy. But now every client has a security alert warning that I can not seem to remove. We have noticed that the ESET plugin for Outlook 2016 caused some clients to not be able to connect to our Exchange server so we decided to disable that function via policy (Outlook is the only email client allowed). Is there a way to remove these warnings without having to enable those functions? Am I missing a control button somewhere?