Raynor

Member
  • Content Count

    116
  • Joined

  • Last visited

  • Days Won

    1

Raynor last won the day on January 29 2018

Raynor had the most liked content!

Community Reputation

3 Neutral

About Raynor

  • Rank
    Forum Regular

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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
  3. 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. 😁
  4. 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.
  5. 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?
  6. 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.
  7. 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
  8. 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?
  9. 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 😊
  10. 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.
  11. Today I am again having problems receiving security codes. I just tried three times, no code received 😢 Are there any knows issues right now?
  12. Things are back to normal, just tried. Thanks 👍
  13. 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 🙂
  14. 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
  15. Same here. Just repeatedly tried to login with both my personal MyEmsisoft account and my company's MyEmsisoft account (the accounts use two completely different email addresses with two different email providers). No verification code has been received on either of the two email addresses. Congratulations, you successfully locked out your customers 😍🥰😁😉