Raynor

Member
  • Content Count

    119
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Raynor

  1. Works great and makes working with the console quite a bit more efficient. Thanks a lot! ☺️
  2. Thanks for the quick reply. We'll stay on 2020.07 for the time being.
  3. 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
  4. 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.
  5. 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
  6. 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. 😁
  7. 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.
  8. 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?
  9. 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.
  10. 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
  11. 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?
  12. 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 😊
  13. 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.
  14. Today I am again having problems receiving security codes. I just tried three times, no code received 😒 Are there any knows issues right now?
  15. Things are back to normal, just tried. Thanks πŸ‘
  16. 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 πŸ™‚
  17. 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
  18. 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 😍πŸ₯°πŸ˜πŸ˜‰
  19. Thanks a lot for your detailed reply. We have the permissions for normal users set to read-only acces (via EEC). Will the normal client PC users be able to confirm the dialog that appears before the switchover, or will we have to set user permissions to basic access/full access before making the switch?
  20. Right now, we are running EEC on Windows Server. I want to migrate step-by step (i.e. stress-free) to the Cloud Console without having to migrate/move all clients at once. 1) Can I create a workspace in my.emsisoft.com and start by only moving some clients to that workspace, while most other clients still remain connected to EEC? After creating the workspace, will the "legacy" clients that are still connected to EEC complain in any way, or will they just silently continue to work (and remain connected to EEC)? 2) What happens to the license key if I create a workspace? If I remember correctly, the key will be moved to the workspace as well. Will that create licensing issues for the "legacy" clients still connected to EEC, or will those clients still be able to use the now-workspace-assigned license key without any problem? 3) Is there a way to move the clients from EEC to Cloud Console without reinstalling the client software? (I don't have access to any client right now, so I can't check this myself.) Thanks for your help, Raynor
  21. Thank you. Everything looks good now on my workspace
  22. A small but persistent glitch that I can't seem to get rid off and that has been present pretty much since I started using the cloud console beta: The device count for the workspace top level constantly says "1", when in reality there is no device in this group. All my three devices are in subgroups... Please refer to the attached screenshot
  23. I have been beta testing the cloud console at home with three devices for some time now. Now I tried to remove one of the devices from the console, so that it won't be remotely managed any more. When I remove it from the workspace, at first it is correctly shown as "unmanaged" (red tag), and when I check the local EAM GUI on the device it does indeed say the device is no longer connected to the cloud. After I reboot windows, however, the device "automagically" returns to the cloud console (listed under new devices), and the local GUI shows that it is remotely managed. Do I have to uninstall EAM to really remove it from the cloud ? Is this a bug ? Right now, the cloud management seems to be a bit too overzealous/persistent/sticky πŸ˜„
  24. When I switch to downloading the installers with signatures, the download works OK. Has the download of the small packages without signatures been canceled/abandoned ? If so, can I safely manually delete the outdated "EmsisoftAntiMalwareSmallSetupXX.msi" files from "C:\ProgramData\Emsisoft Enterprise Console\Download\Server" and "C:\ProgramData\Emsisoft Enterprise Console\Share\Server" ?