Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Mike

  1. In the last couple of weeks, I've seen multiple posts from Eset saying it'll be ready in a fews days. As a result I've been checking-in multiple times a day in the last 10days, but no sign of it yet. Most recently they are now saying "soon", which I'm hoping means imminent (and therefore shorter than a few days?).... rather than it signalling a delay has arisen and so it will be longer than a few days. As others have said the real answer is "when it is ready". Here's hoping it is imminent... Mike
  2. I can understand this info being kept in a log of historic problems... but the system should definitely detect resolved problems (especially connection ones!), and not show them once cleared. This should apply to virus definitions and OS updates too, as these are only really useful whilst current! Once system is updated, ERA should show as green for these machines instantly. Is this coming in ERA v6.2? Mike
  3. I have found that when creating a live installer, that putting the routable URL in the optional "address of server as seen from client" box does work. I had tried that on a early test and not got it to work, so hadn't pursued that further. There must have been something else broken on that first attempt that threw me off the scent! So I've managed to connect some new clients externally using that method with the live installer. I've also successfully used the policy method to fix some already deployed agents. So I am least working now... Ok. I'm still interested in whether there is mer
  4. I tried option 1 tonight, and mine is still reporting OS out of date warnings from 2 weeks ago... despite the update task completing successfully tonight, and the agent concerned reporting in many times in the last few hours since the update completed. Really feels like a crucial piece of the software reporting logic needs fixing urgently for this feature to be any use. Here's hoping it comes in v6.2 in the coming days.... Mike
  5. Nosing around the SQL tables, I found: tbl_servers which only has one row in my table, which has an entry for: server_name.local-domain.lan Can I edit that row to have the externally routable version of that URL instead? I would be tempted to just try it to see, but I wasn't sure what the "server_mask" column was there for, and therefore if it would break something if I changed the URL in that table. Anyone any thoughts about that? Keen to change the default somewhere, so that everything that references the default URL for Eset Rempte Admin gets the correct one, without
  6. Thanks for that. Not sure how I didn't find that before. What I discovered was that the server URL set in those policies was actually set as "" which surprised me! (Wasn't even the machinename.localdomain.lan)! I'm presuming it wasn't actually using this setting, as that wouldn't find the correct server even locally on the office network, so presumably there is another setting somewhere, which was being used to route the agents to the correct server internally... just not from out on the internet. Anyway.... forcing out a policy with the correct externally routable URL has wor
  7. Hi, Foolishly I set the URL for my test install of ERAv6 as one that is only internally routable (i.e. era_server_name.local-domain.lan) and I am now rolling it out wider, I realised my mistake. I now want to enable agents to connect via an externally routable URL (i.e. era.external-domain.com) instead, but unsure where to change this? Is it in a profile setting somewhere, or in the agent itself? (I want to both change already connected agents/machines so they phone home when outside our lan, and also change the default so that new machines I rollout the agent to out in the field can
  8. @michalp Thanks for the info. They are the conclusions I was coming to, but couldn't find in the documentation to prove either one. If there was a way to re-run the startup wizard routine, that might be useful to reimport the settings from a changed OVF file. It would also be great if these permitted locales were listed in the config help document for that OVF file. Thanks Mike
  9. Yeah, we only have about 30 clients here, so running a dedicated CentOS VM is possibly overkill anyway. Ironically, the reason I jumped to the pre-made CentOS VM in the first place was because of problems getting it working on SBS2008 (which eventually ESET support have resolved anyway - but after I'd already removed it from that machine!). The reason I persisted with the CentOS VM despite my initial problems, was that I decided that SBS2008 was probably the wrong place for it, even though ERAv5 had been happily running on that machine for several years. I think that dropping it onto a
  10. Hi, I was trying to install ERA v6 on an SBS2008 server and had a few issues, so I abandoned that route completely, and decided to use the supplied VM file to install the CentOS based system VM into Hyper-V (running on Server 2012R2). I kept failing to get the system to deploy and I incorrectly thought it must be incorrect values in the OVF config files, so in the end I ran the OVF config using the barest minimum to get it working (just the new password and en-NZ as locale - everything else as default). Turns out the problem was actually caused by an external network problem in Hyper-V
  11. Hi, I have questions about this feature too. So I want to capture false positives for my own domain: exampledomain.org This domain is allowed to send mail from our ISP's mail server, but also a few other places, so there will be maybe 5-10 separate IPs to allocate. Do I put the exampledomain.org in the From box? Then how do I handle adding all the different legitimate servers to accept mail from? Do I make multiple line entries each with exampledomain.org in the from box? What do I put in the score box? Is this a number that gets added on to the rest of the score calculat
  12. WilliamT, Is there any news on these more flexible processing rules? Has anyone managed to look into this yet? I'm more than happy to talk to someone if they need more info. Thanks Mike
  13. I just heard (in this thread) that ESET have supposedly fixed this issue in the latest release version of EMSX (4.5.10015). I haven't tried installing this update yet, but maybe the first person who gets it installed, and confirms it has indeed solved the problem, can report back here for everyone. I will certainly be glad to be able to strip out my transport rules as I never managed to tweak them to get exactly what I wanted without some unintended implications! Thank you ESET. I was starting to think that with the Microsoft aspect to the problem, it might never get fixed! Mike
  14. Awesome! It always struck me as a little bit odd that ESET went to the trouble of defining all the categories of spam, probably spam, probably clean, and clean, BUT then to only allow treatment and tagging of the SPAM category. If there is a way to allow treatment at all those the different levels, that would be great. If you want to talk it through some more, then feel free to get in touch. I'll look into the 4.5.10015 update as have a proper solution to the BLANK SENDER issue will be great! Thanks Mike
  15. Hi, I have been frustrated by the limited options for dealing with Spam in Eset Mail Security for Exchange for a long time. (I outlined my frustrations a couple of years ago in this thread). The summary of my frustration is that ESET Mail Security allows us to define really accurately levels for Spam, Probably Spam, Probably Clean, and Clean with a granularity of 1 to 99 scoring. However the Quarantine/Deleting/Tagging module is very crude in only allowing us to deal with only the "Spam" category defined above - the others being ignored! This seems daft to me.... The suggested work-a
  16. I've checked with ESET, and their solution is basically a rehash of mine: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3346 They suggest text filters for keeping hold of Out of Office, and delivery failure notices. I might still keep my SCL=1 in there, as at least this will allow any SCL=-1 entries to pass through unblocked (which seemingly many Out of Office messages are). So it looks like no further progress has been made on this, however I am guessing the problem lies with Exchange, so ESET might not be able to do much about this other than offer workarounds. I'll try som
  17. I'm getting some of them with a SCL of 1 now. That seems ridiculous! Looks like my rule is now picking up some genuine delivery failure messages too, which is a pain as the user doesn't know their email failed to get through. Will need to tweak the rules if I can to allow them through, or I'll have to manually pass delivery failure messages back to the intended recipients. Ideally ESET would have their own solution in place by now, any news on this? This was meant to just be a temporary bandaid solution... Mike
  18. Glad this has helped others too. Just to report back, that I've had mails slipping through with a SCL of 3 which seems pretty low to me. Of course the ESET scoring isn't available since it can't write to the headers, so we'll have to live with that. Fortunately most "Out Of Office" messages appear to have a confidence level of "-1" so it would appear we can set this rule down that low without causing any OoO messages to be lost. I'll be testing that new low value from today. Other than this most recent spam that slipped through, the rule has been owrking perfectly for me. Mike
  19. We have been having the most annoying spam problem for the last week with "Eset Mail Security for Exchange" (EMSX from here onwards) and Exchange 2007 (on an SBS2008 server). The spams started last Friday, and are typified by having a "Return-Path" in the header as: "<>". EMSX correctly identifies all these emails as spam, and says it has shifted them to the Quarantine as we have configured it to do. However the offending emails with a blank return path sender are actually being delivered to the end user's mailboxes instead of the quarantine! I spent several days faffing with vario
  • Create New...