Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Raynor

  1. I'm not saying / implying that 2022.01 or 2022.02 are having GUI or stability issues. I just wanted to know whether the delayed branch still being on 2021.12 ist due to a conscious decision on your part or whether this is due to a bug. ☺️ You said the delayed feed should indeed be on 2021.12, so I assume there is no reason to worry. Thanks for the quick reply!
  2. It seems like the delayed feed is still on 2021.12 (as of today, 05/Apr/2022). I was just wondering if this is on purpose (i.e. some stability issues in 2022.01 / 2022.02 that make these versions unsuitable for enterprise use), or if the delayed feed is stuck on 2021.12 by error. The delayed feed being stuck happened some time ago already, that's why I ask πŸ€—. Thanks! Raynor
  3. For quite some time now, I've been seeing heaps of false "Incidents" displayed in the management console's incidents panel. "msedge.exe", "rundll32.exe" and "winword.exe" are listed as having shown "suspicious behaviour" or "blocked activity". Please note that these are definitely the normal, valid, non-infected executables running on various non-infected PCs in our company network. See attached Screenshot. It seems to me that the incident reporting is a bit overzealous... 🀨 I know that especially "rundll32.exe" can be abused by malware, but this is all fake stuff. The PCs are clean, run-of-the-mill office PCs. Any insights on this? Thanks! Rayonr
  4. 0 Day see here: Does EAM protect against this? I'm curious because MS Defender seems to block this threat using its extended EDR mode (not enabled by default). Seems like a bad one, updating / honing the behaviour blocker (if necessary) to catch this asap might be prudent πŸ€—
  5. We use the management console to set all our domain PC users to "read-only" access level (admin group AND normal users alike), so that users cannot modify any UI settings or dismiss any warning dialogs. In Version 2021.5, this setting/policy is broken. All program settings can be accessed in the UI without being prompted for the EAM admin password, and the checkboxes etc. in the settings section are not grayed out anymore (i.e. can be clicked/modified at any time). Please note that the user's permissions are still correctly listed as "read-only access" under Settings -> Permissions in the UI, but the access level is not enforced correctly. With 2021.4, behavior is as expected (settings grayed out, prompt for EAM admin password appears as expected). I can easily reproduce this behavior by switching back and forth between delayed branch (2021.4) and stable branch (2021.5). Switch to 2021.5, read-only-access breaks, switch back to 2021.4, everything is OK again. Please do not promote 2021.5 to delayed branch before this is fixed (we use delayed branch on all PCs), or skip 2021.05 altogether for delayed branch. We rely on our users not being able to mess with settings and/or dismiss any warning dialogs. Promoting 2021.5 to delayed branch and breaking read-only access would considerably weaken our company's security level. Thanks 😊 and best regards Raynor PS: Please stop messing with the read only access policy, if I remember correctly, this is the second time this setting breaks, the first time was two years ago (or so) πŸ˜‹
  6. Is it possible that the selected columns and horizontal column order are not saved when saving a custom view? I have repeatedly noticed that whenever I login to the console, my selected extra columns are not remembered and loading my previously saved custom view (which was saved with the custom colums enabled/selected of course) does not help either.
  7. I have just enabled Memory Integrity on both of my home PCs, and can confirm that EAM now works well with this feature enabled. Please keep it this way. πŸ˜‰ Compatibility with this feature has become a basic necessity anyway, as brand-new PCs from big hardware manufacturers tend to come with this feature enabled by default when Windows comes pre-installed. Back in 2018, when I first tried enabling Memory Integrity, EAM was indeed incompatible and caused a big fat BSoD on each reboot after enabling the feature (i.e. Windows was rendered unbootable). This is no longer the case. Thanks for making EAM compatible. πŸ‘ PS: For those who are confused right now: "Memory Integrity" is a subset of the "Core Isolation" feature in recent Win 10 versions. While "Core Isolation" is automatically enabled by default on PCs that are at least fairly recent, "Memory Integrity" has to be manually switched on. Unless, of course, you buy a brand new PC from a big manufacturer that comes with Windows 10 pre-installed. These PCs must have this feature switched on by default because Microsoft requires this for some logo/certification stuff.
  8. Works great and makes working with the console quite a bit more efficient. Thanks a lot! ☺️
  9. Thanks for the quick reply. We'll stay on 2020.07 for the time being.
  10. Yesterday I wanted to switch our company network's EAM update feed from the stable feed (2020.07) back to the delayed feed (2020.05) using the policy settings in ECC. After the switch, the clients correctly switched back from 2020.07 to 2020.05. But the connection to ECC was immediately lost on al 2020.05 clients, with the remote management GUI section in settings showing "connection to ECC lost" and a reconnection timer. Waiting through several reconnection attempts did not help, neither did a reboot or triggering subsequent manual updates. I then tried switching ECC back to the stable feed. After triggering a manual update on the clients, 2020.07 was installed again and the connection to ECC was immediately restored. I tried this procedure several times to verify that it could be reproduced consistently. Switching from stable to delayed causes EAM to lose its connection to ECC, switching back from delayed to stable restores the connection. Now my question: Did you guys change something in 2020.06 / 2020.07 that prevents a switchback to 2020.05 (i.e. that would cause the ECC connection to drop when switching back) ? Thanks, Raynor
  11. I'm also seeing the WSC tray icon yellow exclamation mark issue on some of our company PCs with EAM 2020.06. The message in WSC is the same message marko got (see marco's screenshot above): "Cloud-delivered protection is off. Your device may be vulnurable." This issue is definitely new and connected to the 2020.06 update.
  12. A little feature request: It would be nice if the cloud console remembered the sorting order of its list view as well as the number of devices displayed per screen (25, 50 or 100) that was last chosen by the user. πŸ™‚ Best regards Raynor
  13. According to Frank, the read-only permission issue has been reproduced and fixed. The fix will be available in EAM 2020.5. Thanks again for the support! This concludes our successful migration to ECC as this was the only remaining issue in our migration path. 😁
  14. OK, so that clears that up. Nearly all of our domain PC users are regular users with "normal" (i.e. limited) user permissions, so it comes as no surprise that the permissions section vanished from those PCs. On my own work PC, I'm an admin (my domain user has been manually added to the LOCAL admins group), and I can correctly see the permissions panel on my PC. Well, I believe we clicked on "update now" on several clients, in fact, I'm about 90% sure, but I can't really say that with 100% confidence... The read-only permission policies were not applied to any of the clients we checked. We checked about 15 of our client PCs, none of them had read-only permissions applied. We verified this by directly checking the EAM UI on each of the the client PCs. What I did was I started a manual scan. The scan was started without me being asked for the EAM admin password set in the cloud console. Normally, read-only users are always prompted for the admin password before being able to initiate a scan. On top of that, I checked the permissions panel in the settings UI on my own work PC (where I am a local admin, see above). The permissions panel showed my user as having "full access", which was also not the expected permission level , as I have set the permissions to "read-only" in the cloud console for all users (i.e. for non-admins as well as for admins). The webinstallers (downloaded from the cloud console) were run on each client PC using the normal limited domain user account. We were then prompted for admin credentials (as expected), and entered the credentials for the local admin user in order to get elevated permissions for the installer. The installation then went smootly (again, as expected). Summing up, I am very confident that we did not do anything wrong during the installation of the clients. After all, they all show up correctly in the cloud console, the local EAM UI correctly shows "managed by workspace XXX", and, very importantly, all protection policies are applied correctly. Just the permission policies are not applied, all clients use the defaults: "basic access" for normal limited domain users (verified by being able to start a scan without being asked for a password) and "full access" for users with local admin permissions (verified by looking at the permissions panel in the EAM UI). Could the support maybe try to connect a test PC to our console and see if the behaviour could be reproduced? When I'm back at work next week, I will try connecting a freshly installed PC that never had EAM installed before and thus also had never been connected to our old EEC server console. I have a slight hunch that there must be some leftovers from the old EEC server console connection that cause some interference with the permission policies. But then again, that hunch could be way off the mark. As I also mentioned above, I can't reproduce this behaviour with my three private home PCs that are connected to another (private) workspace. At home, the read-only policy is applied correctly to all three PCs.
  15. Another interesting observation that might help to track down the bug mentioned above: I tried changing the permission policies with my private home MyEmsisoft account, and with my home workspace, changing the permission levels works as expected. So something must be different with our company's workspace or with our company's client PCs. As we uninstalled and re-installed EAM on all company PCs, i find it hard to imagine that something is wrong on the PCs themselves (but who knows for sure). What's funny and strange at the same time: After re-installing EAM on the company PCs via the webinstaller (see step 4 in the post above), the whole permissions section vanished from the Settings UI of the clients. I saw this behavior on every PC that I checked. In other words: when you click on "Settings" you normally have a "Permissions" tab/section in the settings section. That tab/section completely vanished as soon as the clients were connected to the cloud console... πŸ™„ On my home PCs, this section stays visible at all times, so everything works as expected there. Could there be any interference from the old EEC server console that is still running on our Windows Server 2016? Note: The client entries are still there in EEC, and they all show "offline" as the status for the clients (as expected because the clients are no longer connected to EEC). I haven't deleted the entries from EEC yet, nor have I uninstalled EEC so far. Could there be any remnants in the registry that cause an interference and that are not removed by uninstalling EAM?
  16. OK, thanks. Then I'll create an additional ECC account for my co-admin so that he can also use an authenticator app on his own phone.
  17. Well, It turns out the migration did not work out completely stress-free after all 😐 What we did: A few days ago, I moved my own work PC to a new workspace using the webinstaller provided by the cloud console. As indicated by Frank above, this moved my PC to the cloud console workspace and assigned a trial licence. So far, so good - the test went well. Today, we migrated all our company's work PCs from the old local enterprise console (EEC) to the cloud console (ECC). This is what we did and the hurdles and issues we ran into: 1) First, we assigned our real license key to the workspace that had been created a few days ago. No confirmation messages appeared on any of the client PCs, and so none of the PCs were automatically moved from EEC to ECC. πŸ˜ͺ 2) Then we manually ran the small webinstaller provided by ECC on each PC. This worked, the PCs were successfully moved to ECC. 3) Important Note: I had all user permission policies (i.e. for all user groups, both admin and non-admin) set to "full access" in EEC (the old server console) before the switchover, just to be safe. This was done to ensure that any confirmation messages that might appear could be successfully confirmed. In ECC (the cloud console), all permission policies were set to "read-only", as this is the setting we want to use for all users, regardless of whether they are admins or normal users. After the switchover (see step 2), the permissions for client PC users remained set to "full access". The permission settings from the cloud console were not applied. All other settings (i.e. protection policies) were applied correctly. 4) Being slightly baffled, we took more radical measures. We uninstalled EAM on all client PCs and reinstalled it using the webinstaller provided by ECC. This again worked fine, the PCs were instantly connected to the console, and all protection policies were applied correctly. At first, it even seemed like the "read-only" permission policies were applied too, as all of the settings in the UI were grayed out. But the we realized that this was not the case: On PCs where the local user had admin permissions (we have a very small number of PCs where this is the case), the user could change all settings, and in fact his permission level was "full access" (which happens to be the default for admins). On PCs with normal users (most of our PCs), the user could still start scans manually, so the real permission level was "basic access" (which happens to be the default for normal non-admin users). Bottom line: We found a rather annoying bug. While protection policies are applied correctly by the cloud console to the clients, permission polices are never applied. The connected clients always stick to the default permission policies (full access for admins and basic access for normal users), even if "read-only" is explicitly specified in ECC as the permission level for all user groups. Please note that the "read only" permission policy worked absolutely flawlessly with the old EEC server console. Please fix this πŸ˜‹ All the best Raynor
  18. Argh, how can I add another authenticator app instance for the same console account? I added both my iPad and my iPhone (using the Microsoft Authenticator app) a few days ago (as I said above, I was going to do that πŸ˜€). Today at work, we tried to add a third authenticator app instance for our cloud console account on my co-admin's iPhone. We did not find a way to do so. In the console account settings there is only the button "Disable Authenticator" and can't find a way to have another QR code displayed. How the heck did I add my two devices in the first place - I can't quite remember. But I definitely did not dream that I added both devices. Just checked again, and the authenticator was working on both devices, showing the same code. Did you recently (in the last few days) change anything in the direction that it is not possible anymore to add more than one authenticator app instance per console account?
  19. Actually, no πŸ™ƒ None of yesterday's codes (4 attempts) has been reveived so far. I just tried again for the fifth time, and today the code arrived within seconds, so I was just able to login correctly. I will definitely setup an OTP-App as backup straight away 😊
  20. Just tried again for the fourth time, no luck. The email address used for My Emsisioft works fine for other external emails, I just tried sending some test emails to it from other external addresses. All my test mails arrived within seconds, so the address itself is in fine working order.
  21. Today I am again having problems receiving security codes. I just tried three times, no code received 😒 Are there any knows issues right now?
  22. Things are back to normal, just tried. Thanks πŸ‘
  23. The codes arrived some hours later. I have sent you an PM with the email addresses used, maybe that helps if you want to do some more in-depth checks πŸ™‚
  24. Could I please get a reply on this one, the planned switchover date is approaching, and I need to start preparing. So, do I have to set user permissions to full access to enable our users to confirm the "Switch to Cloud Console" security confirmation message you mentioned? Thanks Raynor
  • Create New...