Jump to content

Mirek S.

ESET Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Mirek S. last won the day on January 17 2020

Mirek S. had the most liked content!

Profile Information

  • Gender
  • Location
    Czech Rep.

Recent Profile Visitors

2,302 profile views
  1. Hello, Please contact customer care, this is nothing we can solve over forum and without logs. What comes to mind is that previous versions did not have MariaDB installation prevented and it caused issues "like" this. Thanks, M.
  2. Hello, To my knowledge there is no restriction of VPN used with EESA as EESA does not care for internet/intranet connection (now) and it's main point of interception is filesystem. HTH, M.
  3. Currently there is only anti-phishing protection it's settings are in EESA policy. Web control is in plan for future however is currently not available. You can post in EP feature requests if You have something specific in mind. HTH, M.
  4. If You mean RAM - no, AFAIK only total RAM can be displayed. If You mean disk space (SSD/internal flash etc...) 8.0 added this for iOS devices. 8.1 will probably add it for Android. Cloud MDM already has this implemented for both OSes.
  5. * Create static group named "MDM Device Enrollment Managers" * Move Agent installed next to MDM into this static group * Create permission set "MDM Device Enrollment Managers" ** In "Static Groups" add "MDM Enrollment Device Managers" Group You created in previous step. ** In functionality enable at least "Read" for "Groups & Computers" * Assign this permission set to user who You want to be able to see enrollment links. NOTE: This user will also require write rights to some other static group which can come from other permission set so he can actually cr
  6. Hello, Your user must be able to see MDM server Agent in EP console to have access to that MDM enrollment links. AFAIK that is the only protection there currently is in place. HTH, M.
  7. @ChrisC Hello, after testing addition to ABM via Apple Configurator 2 we found some quirks in process. * Device must have internet connectivity during erasure phase (You can't input it manually on device). For devices without data SIM this can be archieved by installation of WiFi profile (including valid authentication) via APC2. * Checkbox "Activate and complete enrollment" must be disabled in APC2. * Device must be assigned to MDM server on ABM side before any progress on device is made after reset. * MDM must synchronize with ABM before any progress on device after reset
  8. The state could persist due to "currently used" certificate, essentially worst error is reported which might not be best idea for these cases. If You try to request configuration from MDM You should be able to see if there is issue with new certificate. New certificate should be applied on MDM HTTPS interface when all devices install new trust (newly applied certificate root CA). This process is required as we support self-signed certificates and process for using already trusted 3rd party certificates never got in (yet) as most customer use self signed certificates from console. Since ne
  9. As an explanation why this protection state happens. * Apple decided to follow CA/B rules for browsers (which is quite good for security reasons) * We (ESET) have existing userbase and as we honor our customers previous installations and configurations have to work for some time. * Prefered action for this protecion state is to actually create new certificate either via webconsole or via 3rd party CA and setting it to MDM. Disabling notification via policy is there just for extreme reasons, like our implementation issues etc... * Since EP 8.0 some parts of validation are en
  10. @Christian Stück Nothing is in stone yet, but it's the direction ESET is currently pushing forward. In any case if this happens there would be transitional period and a way to move devices from EP to EPC. @ChrisC I will update this thread once we are able to test and figure out how it should work. However it will likely require release. The ASM issue is different as device is already in Apple remote profile (ASM/ABM sync part is similar) - MDM knows it's serial number so it allows enrollment.
  11. Thanks, We will definitely checks this. Seems like information on our side is outdated and Apple now supports adding devices not purchased via ABM/ASM into ABM/ASM. This actually helps us as well as we have multiple devices not purchased via ABM not usable for ABM testing...
  12. Currently no, And as we now have cloud MDM, there is not much of chance this will ever happen with on premises version.
  13. Hello, I believe this is different case, can You elaborate a bit why You need to run Apple Configurator 2 on devices (for supervised mode) ? Also as far as I know it's impossible to add devices not bough via ABM into ABM. M.
  14. Hello, We currently do not support ASM, only ABM is supported. IIRC main reason was EP is device centric while ASM is user centric but I might be wrong on that one. M.
  15. Hello and sorry for late response. You actually have two issues there, 1. License fails to activate. 2. APNS fails to verify peer (Apple Push Notification Server) certificate so it refuses connection. Please contact support we will need more logs to identify reasons for this behaviour. Sorry for inconvenience, M.
  • Create New...