Raynor

Member
  • Content Count

    99
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Raynor

  1. Good. Thanks for the clarification. Then the info given by MS is false 😁... and this will not be as big an issue as I thought it might be. 👍
  2. 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 ?
  3. Upgrade to v1809 with EAM 2018.06 went fine, no issues. Thanks for your replies.
  4. 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 Raynor
  5. 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: https://www.wilderssecurity.com/threads/win-10-1803-core-isolation-and-memory-integrity.407342/#post-2776118 "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. https://support.emsisoft.com/topic/29479-windows-10-1803-kernisolierungspeicherintegrität/ Botom line: please make it compatible 😁 Thanks and best regards Ranyor
  6. With Win 10 v1809 around the corner and me using the delayed update feed (Version 2018.6 at the moment), I would like to quickly ask whether there are any known compatibility issues to be expected when upgrading to v1809 in the next few days. Thanks!
  7. 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 Raynor
  8. 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 Raynor
  9. 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 ?
  10. Dear all, is there any news on this issue? Did the logs provide any meaningful insights? I still got more workstatios to upgrade from 1709 to 1803, so I could gather more logs if needed. Thanks and all the best Raynor
  11. 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....
  12. 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: https://blog.emsisoft.com/en/31683/new-in-2018-7-improved-file-guard-performance/ 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 Raynor
  13. 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
  14. 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. But: 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 Raynor
  15. Thanks! By the way: The Surf Protection messages are also NOT read-only! ("always block" and "don't block" can be selected by the user) Best regards, Raynor
  16. I have now deployed EEC+EAM in our company. The read-only GUI setting works fine, but I really can't seem to find a way to make the behaviour blocker quarantine notifications read-only. Example: The behaviour blocker shows an alert because a suspicious program is trying to "change firewall settings". Users are told that the program will be quarantined after a couple of seconds, but are ALSO given the choice of clicking "Wait, I think this is safe"/"Thes program seems safe" (I can't remember the exact wording). I want to take that choice away from users, and NOT allow them to skip the behaviour blocker messages. They are the last line of defence, and I can guarantee that some users WILL allow new viruses to run by clicking "this is safe". So, please let me ask again: Is there any way to make the behaviour blocker prompts read-only without the option of skipping them ? I want them to work just as the normal "malware found" prompts (i.e. quarantining the program with no way around it). In there is no way, please let me kindly suggest again that an option to make these prompts read-only be added. Thanks and all the best Raynor
  17. On the topic of "playing around": I just installed a fresh copy of EEC (for pre-deployment testing purposes) in a fairly basic Windows Server 2016 virtual machine (VirtualBox), and stumbled over two obscure "Value does not fall within the expected range" warnings in the log. Again, quite basic & fresh Server 2016 VM, just installed EEC (2018.3.0.3338) a minute ago (first thing was taking a look at the logs). Any insights ? Best regards, Raynor
  18. Thanks, beta 2018.3.0.8528 seems to have fixed the problem. I had added an exclusion of the file VirtualBox.exe before, that helped as well. But with the recent beta, the exclusion is no longer required.
  19. Hi, starting yesterday (Friday 23-03-2018), VirtualBox always throws an error (see attached screenshot) when starting a virtual machine, be it an existing one or a new one. I was puzzled because I had extensively used VirtualBox just the day before (Thursday 22-03-2018) and everything worked fine (as it always had). This thread lead me onto the right track: https://forums.virtualbox.org/viewtopic.php?f=6&t=83791#p397261 "The "process has more than one thread" error implies, I think, that some other process was trying to access VirtualBox process memory. So, either malware or antivirus. [...] It would be something invasive: system monitor of some kind, developer debug environment, crash manager maybe." And indeed, If I shut down EAM, VirtualBox starts to work again just fine (no errors whatsoever ). So some very recent protection/signature update must have made EAM more invasive, thus causing this error. Please fix this. I am using EAM 2018.1.1 (delayed feed), Win 10 x64 v1709, VirtualBox 5.2.8. Thanks, Raynor
  20. Hmmm ... maybe with a BIG FAT "potential security issue" warning message ? Oh, and one more thing: The console window does not seem to remember its size and position, could this be fixed?
  21. PS: Could we please get a "remember password" checkbox in the EEC login/connection screen in the future? (no security risk for us, as only domain admins are allowed on the server anyway)...
  22. Thanks, yes, I had figured this out already. I only need to lockdown normal users (for now).
  23. 1) Other context menus seem to be a bit wonky, too: Under "User Policies", If you right click on "Default for admins", you get a greyed out context menu, and if you right-click on "Default for non-admin", you get a normal, not greyed out context menu, but the "Edit" and "Delete" menu items do nothing. "Clone" works. Suggestion: Add a "New" Button at the bottom , and make the behaviour for context menus on non-deleteable default groups consistent (i.e. consistently allow "clone" and grey out "edit" and "delete"). 2) Thanks, yes, that makes it clear. May I suggest that you rename this section from "Scanner Settings" to "Scanner settings for console-initiated scans" and/or add a little descriptive text like "These settings are applied when performing a manually initiated scan from EEC". This might save some confusion for future users. 3) Thanks, this makes sense! Best regards, Raynor