Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Mike

  1. Thanks Marcos. WIll keep an eye out for that. What about ESMC client v7.0.447.0 (eg the other half of my question)? Is that OK, or does that need a newer version for compatibility with next MacOS version too? Might be worth an overview help page which has compatibility for all ESET products and lists the minimum versions that will work with next MacOS without problems. That way we can see at a glance the latest status, (eg currently wait for the next product version) and then when that product is released, it will state the exact version that is minimum required. Otherwise each time
  2. A Mac user is still getting the same warning on Eset Endpoint AntiVirus v6.9.60.0 I assumed this would be fixed in the v6.9 product line, as you said it would be fixed in the next version after v6.8 (or do you mean the v7 product line?) Equally, whilst I'm assuming that the warning is coming from Eset Endpoint, I guess there is an equal chance it is coming from the ESMC client (which is on v7.0.447.0). Any info on what are the minimum versions of both Endpoint and ESMC client are required for use with the next version of MacOS would be much appreciated.
  3. My guess is that it happened because the agent is designed to be upgraded using the Remote Administration upgrade task (it is called something like that), and because it was a fresh install (even though it was installed on top of the old agent), it has been detected as a fresh computer. I can't find the instructions for updating right now, but if you hunt around the knowledgebase you should find what you are looking for. You basically run an upgrade on the Remote Administration as though you are going to upgrade the ERA server itself , but you select all the computers you want to get the n
  4. Where is the database stored? (same machine or separate server?) What OS does your server have? How frequently are the agents set to 'phone home' to ERA?
  5. We've had problems with Eset Mail Security for Exchange v6.2 so it would appear not all v6.2 products are fixed yet.... (although Eset are yet to respond to my thread, so as yet unconfirmed) but turning off Protocol Filtering appears to have worked for me on EMSXv6.2 although it'll take another week of no reboots to be sure. Protocol Filtering is in the Web & Email section of the Advanced Settings. If you go to the Main Header for this, there is an On / Off slider button for this feature. (I also disabled Outlook Integration on mine in the email section - since it is on a Mail Server n
  6. Because I was nervous about installing the Hotfix without proof that it: a) works on SBS2008, and b) was likely to help the problem anyway; .... instead I've disabled the Protocol Scanning features for Web and Email in EMSXv6.2 (as I don't think they were enabled on the previous EMSXv4.5) and that was an alternative solution offered by Marcos in the other thread: I'll have to wait now to check whether that has helped my server regain stability or not. I am surprised though, as the Eset KB article suggests that the latest products shouldn't need to use this hotfix: Y
  7. Hi, I'm having problems with our SBS2008 since we installed Eset Mail Security for Exchange v6.2 (6.2.10009.0) last week, where the server repeatedly has become unresponsive and required a hard power off with the power button. (at least 4 times in the last week at random times on a previously very stable server) I have been unable to find the culprit for the problems, so can't prove it is EMSX v6.2 that is at fault, although that is the main thing that has changed on the server recently. (The other being some Windows Updates which could also be the cause). I would roll back to EMSX
  8. I'll start my own thread to discuss my server as that would appear to be more helpful than cluttering this thread with a potentially separate problem. But I'll leave discussion of this Microsoft Hotfix to this thread, so that info all stays together:- Is this Microsoft Hotfix definitely safe to install on SBS2008? It isn't on the list of applicable systems on the Microsoft Hotfix page.
  9. Does this hotfix problem apply to Eset Mail Security for Microsoft Exchange v6.2? I've had multiple system freezes in the last week necessitating the system (SBS2008) to be hard powered off with the power button. Cause as yet unknown, but Eset Mail Security is my current guess as that is the main thing that has changed on the server just before this issue started.
  10. Glad to hear it is official. Why has it not been announced here and stickied yet? Is it a deliberate soft-launch?
  11. Hi, I have seen Eset Mail Security for Microsoft Exchange (EMSX) v6.2 is in the Beta forum, where I was asking about release date. I know see that it is available for download on your main website and is mentioned as supported by the new ERAv6.2..... but it isn't announced yet in the sticky threads here... So I was wanting to know is this officially released now, or is it still in beta.... or is it half way between these, sort-of having a soft launch maybe? The reason I ask, is that I had a nightmare day with EMSX v4.5 yesterday, which resulted in 24 hours of no virus or spam protection fo
  12. Marcos. Glad to hear this info. Helps us better appreciate the vision for the changes. Would love to hear more of this stuff, as it helps us understand the long term goal, and therefore endure the short term pain whilst we get there! Looking forward to finding time to install v6.2 Thanks. Mike
  13. I'm pretty excited to see v6 of Mail Security for Exchange coming. The announced features look great! How is this beta test going? Roughly how long do these Beta tests last?
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. @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
  22. 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
  23. 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
  24. 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
  25. 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
  • Create New...