Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Raynor

  1. 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 


    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) 😋

  2. On 6/3/2020 at 8:13 AM, GT500 said:

    It's been a long time, however I think there's a possibility of the core isolation feature causing crashes in Emsisoft Anti-Malware. I know it used to cause BSoD's, however from what I am seeing that appears to have been fixed at some point, and about a year ago QA confirmed EAM could run with the option enabled.

    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.

  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) ?







  4. Quote

    by default, and it always has been like this: the permissions tab is hidden for regular windows users. it is visible for local admin users

    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.



    did you wait till EAM started an update ? Only an update triggers the switch

    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...



    Where did you see this ? did you check it on the clients ?fyi and maybe obsolete:
    * Protection policies are computer/device based
    * Permission policies are  user based.

    How did you run the webinstallers on devices with windows user accounts ?  did you run it under the user context in elevated mode ?

    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. 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


  7. 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?


    5 hours ago, GT500 said:

    It looks like you were able to log in later in the day. I assume you were finally able to receive the security code?

    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 😊

  9. 5 hours ago, GT500 said:

    @SeriousHoax and @Raynor were the accounts you were trying to log in to using the same e-mail address as your forum accounts? If not, then please send me a private message and tell me the e-mail address of the account you were trying to log in to. We can check and see if there were any errors sending security codes.

    Note that there have been a few outages during the day, so there's a possibility that those may have caused the issues you ran in to.

    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 🙂

  10. On 12/28/2019 at 7:24 PM, Raynor said:

    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?

    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?


  11. 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 đŸ˜đŸ„°đŸ˜đŸ˜‰

  12. 21 hours ago, Frank H said:

    2. As soon as you assign a license to a workspace, all EEC connected devices will automatically disconnect from EEC and connect to ECC -new computers' group. Users will see a dialog where they need to confirm the switch to ECC, for security reasons.


    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?


  13. 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,

  • Create New...