• Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Raynor

  1. 2 hours ago, Jonathan Starr said:

    Hi Raynor, we're also suffering from it too so you aren't alone.

    Thanks for this confirmation Jonathan. I thought I was going crazy.

    @Emsisoft: Please let me kindly ask that the process of verifying the client certificates is reviewed with regard to EEC's/EAM's behaviour
    after upgrading to a new semi-annual Windows version. I would really appreciate if this issue could get squashed once and for all. Thanks ☺️


  2. 14 hours ago, Frank H said:

    EAM will check this when the browser is  started.

    The notification shows you 3 options

    install now - later - Don't show again

    Please also add a configuration option to Emsisoft Enterprise Console
    to allow supressing/disabling this prompt. I wouldn't want it to be shown
    to the users in the company I work for, as we use other means for malicious website protection.

    Thanks ☺️

  3. *Bump*

    Sorry for being so persistent 😀, but I find it hard to believe that we are the only ones suffering from this issue.
    Why ? because our Server 2016 is totally run-of-the-mill, nothing fancy, no special configuration at all.
    Just one server (fresh install, about one year ago), acting as Domain Controller for a bunch of workstations,
    and as a file server, and hosting the EEC. No additional firewalls/proxies/security appliances running in the network.
    As I said, no fancy stuff 😆

    Please let me reiterate my question: If the "Server certificate verification" fails according to the EAM log on the clients
    after upgrading Windows to a newer semi-annual build, something on the clients must have changed in a way that the
    certificate is no longer valid.

    I don't think that the server could be the culprit, as nothing whatsoever has changed on the server side.

    Again, any help would be greatly appreciated, as the current situation is quite unsatisfactory.


  4. On 11/15/2018 at 9:20 PM, GT500 said:

    They tested on Windows 10, and Emsisoft Anti-Malware has an issue on Windows 10 where the first update can take an abnormally long period of time to initialize (it doesn't happen 100% of the time, but I expect that it must have happened in their test to have not achieved a perfect score).

    Uh, any plans / ETA for a fix ? Speedy updates after the computer starts are very important IMHO...

    You know, people tend to start checking their emails right after startup, opening all kinds of attachments
    with viruses in them 😋

    Thanks 🤗

  5. We have just started upgrading a few clients from v1803 to v1809 for testing purposes.

    At the moment they are running EAM 2018.8.1 (delayed feed). Our Server 2016 is running the latest EEC version.

    The issue still persists. Clients are losing connectionto EEC after upgrading to v1809.
    Manually reconnecting the clients from the EAM User Interface is necessary and works flawlessly and instantly...

    The EAM Logs say:

    Connection with Emsisoft Enterprise Console SERVERNAME:8082 failed.
    276: Server certificate verification failed. Connection aborted.

    Any insights ? What could cause the certificate verification to fail ?
    We really need to get this fixed, we can't run around manually reconnecting each and every client
    from now until forever 😪




  6. Unfortunately I don't have a test environment up and running at the moment, sorry.

    But thanks for the heads-up about the surf protection. I might disable it using the
    enterprise console as an extra security measure. But the issue of the surf protection interfering
    with SQL connections must really be thouroughly solved before switching the delayed
    feed to a newer version (see above).


  7. An das Emsisoft-Team:

    bitte stellen Sie sicher, dass die SQL-Verbindungsprobleme und alle anderen
    Netzwerkverbindungsprobleme 100% vollständig gelöst sind bevor der verzögerte Updatefeed
    ("delayed feed") von 2018.6 auf eine neuere Version umgestellt wird.

    SQL-Datenbankverbindungen sind für uns in der Firma von größter Wichtigkeit, und
    selbst kleinste Störungen in dem Bereich würden dazu führen, dass ich wie ein Depp
    . Warum ? Weil ich derjenige war, der sich dafür eingesetzt hat, unsere vorheriges
    Antivirus mit EAM zu ersetzen, indem ich überall erzählt habe wie toll und problemfrei EAM doch sei.

    Softwarestabilität ist für uns von äußerster Bedeutung, daher benutzen wir auch nur
    den verzögerten Updatefeed. Und wenn der auf eine problematische Version ungestellt wird,
    dann gute Nacht! Dann müsste EAM sofort verschwinden von allen Rechnern.

    Liebes Emsisoft-Team, bitte lasst mich nicht im Stich 🤗

  8. On 10/19/2018 at 1:59 PM, jedsiem said:


    Since 2018.9 I see network-related issues around applications under Windows 7x64. No frozen EAM or Malware. Just disconnection of SQL connections or other network-connection between different applications. Still investigating if it really is EAM causing these issue or a different installation which replaced runtimes.

    There are more reports of SQL disconnection issues in the German forum even with v2018.9.2.8988 .
    The delayed feed version 2018.6 is reported to work fine.


    Please make sure that all these issues are fully and thoroughly fixed before even considering
    switching the delayed feed to anything newer than 2018.6!

    SQL server connections are mission-critical in our company, and we depend on software reliability.
    This is why we are useing the delayed feed.

    If the delayed feed was switched to version that causes SQL connection issues, my bosses would
    pretty much kill me leading to me probably having to ditch EAM as a security solution altogether.

    I put my reputation on the line by telling everybody how great EAM was and that we should
    therefore switch to EAM as our security suite.  Please do not let me down 😥


    Network related issues should have been fixed.

    This does not seem to be the case unfortunately...



  9. Fair enough, but what's with fresh installations of v1803/v1809 ?

    According to MS, the memory integrity feature is always switched on
    on qualifying modern PCs (with virtualization support, UEFI and stuff)
    when Windows is installed from scratch.

    Wouldn't then "average" users be greeted by a big fat blue screen when they try to install EAM ?
    Or am I missing something here / am I getting something wrong ?

  10. Thanks for the confirmation and the quick reply.

    This should be documented somewhere to save others the hassle.
    E.g. in the release notes, as a sticky in the forum, or as a message
    in the installer.  I was unable to find this info, which led to me being puzzled
    and wasting quite some time.

    Not a biggie at the moment, but compatibility with this feature  would certainly
    be welcomed for the future. Other AV vendors (Kaspersky comes to mind)
    are also struggling with this feature, but they have been communicating
    it more openly.

    Thanks again

  11. There is a new security feature in Win 10 v1803 / v1089. It is called "Core Isolation". It can be found
    in the Windows Security Center under "Device Security". The core isolation feature includes a
    sub-feature called "Memory Integrity" (clicking on "core isolation details" reveals a switch that can be used
    to turn this feature on). It is enabled on fresh Windows installs, but not for existing installations that have been
    upgraded to v1803 or v1809. According to MS, these users can opt-in using the switch.

    For me, the switch turns on fine (no driver  incompatibility warning given), but the required reboot ends with a
    blue screen
    KERNEL_SECURITY_CHECK_FAILURE. The welcome screen is shown for  few seconds, then
    the BSOD is shown. I had to go into the BIOS, turn off virtualization, reboot and then disable the memory integrity
    setting in the registry.

    This happens on BOTH my PCs (main work PC - recent hardware, Z270 chipset - and my small Intel NUC7i5
    media PC with no special stuff installed). Tried it under Win 10 v1803 a couple of months ago
    and now again yesterday with v1809 (x64). Same results always.

    After pulling out some hair, I decided to uninstall EAM. And behold, the feature turns on successfully on BOTH PCs.

    Trying to re-install EAM with Memory Integrity turned on immediately causes the above mentioned BSOD
    during the installation
    (i.e. not on reboot, but immediately while the EAM installer is running).

    Here is another user reporting exactly the same  issue:


    "With Core Isolation and memory integrity turned on I got a green screen of death trying to install Emsisoft
    and could only recover using Macrium Reflect backup. Turned off memory integrity and EAM installed fine."


    The information given in the German section of the Emsisoft forum that it "should" be compatible
    is obviously FALSE. While EAM is certailny compatible with the basic "Core Isolation" feature,
    it does NOT work when the memory isolation sub-feature is switched on.


    Botom line: please make it compatible 😁

    Thanks and best regards

  12. Dear all,

    I have one little improvement suggestion. Recently, I had do add quite a few program paths (mostly to .EXE files) to the exclusions in EEC
    (Exclude from monitoring) because the Behaviour Blocker behaved a bit overzealous on our client PCs.

    The problem with that was that most of the EXE files and paths that I wanted to exclude did NOT exist on our Windows Server 2016,
    as they pointed to programs that were only installed on (some) client PCs. But when adding an exclusion path in EEC, you are only
    given the chance to pick an existing file (in this case on the server).

    So I always need to use a workaround: First pick a file that exists on the server (e.g. "C:\Windows\notepad.exe" or whatever) and then
    manually change the path by clicking on it in the exclusions list and typing the real/desired path. This works as intended, the file is
    correctly excluded from scanning on the Client PCs. But all this is a bit cumbersome.

    So please let me kindly suggest that an option like "Manually add path" that allows to type in (or copy+paste from a textfile)
    any path (even to files that do not exist on the server)
    is added to EEC.

    Thanks and best regards


  13. We have bought 50 EAM keys for our corporate network.

    Not surprisingly, we have to decommission old PCs and replace them with new ones
    from time to time.

    Is it necessary to somehow remove the EAM license from the old PCs, or can
    the license key simply be reused on new PCs without us running out of activations
    (provided that, of course, the total number of PCs in operation at a given time does not
    exceed 50) ?

    Thanks and best regards

  14. On 7/26/2018 at 10:39 PM, Frank H said:

    The issue has been fixed in the upcoming EAM 2018.7 release.

    Regarding this:

    I just have tested this in EAM 2018.6 stable) and i do not see those 2 options when i visit a site that sit in our blocklist. i.e. malwaretest.emsisoft.com

    I was logged in as a standard windows user and had 'read-only' permissions in EAM.




    Thanks for fixing!

    About the second issue:

    I saw these two options logged in as a local admin user with read-only permissions :)


    By the way: Is there any behaviour blocker test file/exe available, similar to the

    EICAR  AV test file ?

  15. OK, fair enough, I guess it comes down to personal preference. Everybody is entitled to their opinion,
    and I just wanted to express that I personally absolutely do not like the recent interface changes.

    Again, it's intended as constructive criticism, even if my wording might indeed have been a bit harsh (sorry about that 😇).

    But on a factual level, I stand by my opinion 🙂

    To give two concrete examples:

    1) The behaviour blocker program list in the protection section is in itself a scrolling list,
    so now we have a scrolling list view within a scrolling preferences list.

    2) The navigation tabs at the top (Behaviour Blocker, File Guard, Surf Protection) are still there,
    creating the illusion of a tabbed preferences window. But clicking on the tabs only scrolls down the
    view to the appropriate section. This just does not feel consistent/logical to me....

    • Upvote 1

  16. Well,

    the new scrolling settings view in 2018.06 already annoyed me (as well as many others), but back then I didn't feel the need
    to speak up because it was just one window. Now, with 2018.07 the scrolling view has been added to the "protection" section
    of the Interface as well.

    The usability of this scrolling view is HORRIBLE in my opinion, it is jumpy, makes you dizzy, and just somehow feels wrong.

    And as a bonus, I have added a little treat (see attached screenshot). On one of my PCs, I have increased the DPI scaling because I need bigger fonts.
    Now the main window is just a tiny little bit too large to fit the screen, which results in the rightmost scrollbar. But because of the scrolling settings,
    I now have TWO scrollbars. Now isn't that cute... no, wait, it isn't. The whole thing is just an abhorrent abomination.

    Bottom line: Please  stop making the UI worse. There has been criticism by other users about the scrolling settings view in 2018.06 already.
    In fact, telling from the comments, nearly nobody seems to like it. Which is not surprising, because it's a bad design decision.

    The new On-Demand scanning default in 2018.07 is also a change to the worse, as Piotr has rightfully pointed out
    in his comments (especially in the second one) below the following article:


    Sorry for the scathing criticism (it is intended to be constructive!), but these recent changes indeed feel a bit like like making changes just for the sake of change... 😰


    All the best and best regards

    Two Scrollbars.png
    Download Image

  17. Thanks for your reply.

    I'm puzzled, because our whole domain  setup is pretty much run-of-the-mill, nothing fancy...
    EEC uses its default ports, there are no fancy firewall settings in place, nothing.
    We use the update proxy (default port 8080) and that works fine as well.

    Some weeks ago, I installed EEC on the Server 2016, added the PCs, created manual deployment packages
    (we don't use remote deployment), installed them on the Win 10 v1709 clients via "Install.bat", and the connection
    to the Server worked flawlessly. On the clients no windows settings have been changed / no preparations have been made
    prior to deployment (if I understand correctly, preparations are only necessary for REMOTE deployment).

    Everything has worked fine for the last couple of weeks.

    Today, I upgraded some client PCs to v1803 through Windows Update (by removing the feature update deferral policy we had in place before),
    the upgrade itself went fine, but after that the clients all showed "connection" failed. Manually reconnecting was necessary and immediately
    worked fine (see above).

    I have just sent a mail to support asking for further instructions.

    I will be upgrading more clients tomorrow, so lots of logs will be there I guess :)

  18. System environment:

    Windows Server 2016 Domain
    About 40 domain-joined PCs, some Win 7, some Win 10
    EEC 2018.06 on the DC
    EAM 2018.05 (delayed feed) on the workstations


    First of all: installing and initially connecting EAM to EEC worked fone on all PCs.


    I have just upgraded a couple of our company's Win 10 v1709 PCs to Win 10 v1803
    using the normal Windows Update installation process.

    On all of the upgraded PCs, the connection to EEC is lost after the upgrade.

    This is annoying. After all the connection problems in the past (see this forum)
    I thought that these issues were a thing of the past. Obviously not.
    Connection stability sill seems iffy and unreliable, at least after upgrading
    domain-joined workstations from v1709 to v1803.

    I had to manually disconnect the PCs (using the interface within EAM itself, not
    from the server console) and then manually reconnected them (also from within EAM).

    After that, the connection was back up again.

    Still, unacceptable behaviour in a coroprate environment 😪


    Thanks and best regards