Mirek S.

Hello, We are aware of this issue. Apple switched to virtual servers (which require TLS SNI) and this caused malfunction in all currently released versions of MDM. Please contact support for hotfix version HTH, M.

Hello, You can install MDM HTTPS certificate via MDM policy. https://help.eset.com/esmc_admin/70/en-US/admin_pol_for_mdc_apns.html HTH

Hello, MDM should register with EPNS on behalf of devices (devices themselves use FCM or APNS). The reason for this error is EPNS tokens did not make it onto ESMC server for some reason. Please verify MDM proxy can replicate to ESMC server and can connect to EPNS (epns.eset.com:8883/443), otherwise we will need high verbosity logs from MDM and MultiAgents - please create customer care ticket. As a sidenote this issue is "cosmetical" as communication between devices and MDM is triggered by new work for device (task) or by EESA when it has logs, we added EPSN only for "single paint of glass" feeling. HTH

Hello, Attached logs does not contain installation log - those are collected only during "component upgrade" task. Please use this method instead. https://help.eset.com/esmc_install/70/en-US/msi_logging.html HTH

I believe easiest option would be to redeploy via SCCM (with valid install_config). This will repair installation on all endpoints. Now this might get tricky if You are on SCCM 2012+ as it lost option to rerun, instead detection based on time of installation could be used. As a sidenote it seems to me like quiet installation without valid hostname should not succeed, at least I don't see any use-case for it.

Hello, As @Perry noted 3rd party certification authorities typically provide pem or pkcs#12 web certificate which does not contain root CA as that is not required for common webservers - this certificate is typically preinstalled on devices so that chain of trust can be established. MDM does a "bit more" than typical webserver - during enrollment we also install root CA to enrolled device to establish trust (we can't guess whether certificate is selfsigned or signed by CA already trusted by device) so we have extra requirement. I'll look into improving documentation wrt to 3rd party certificates as openssl command line how to convert between formats and appending root CA to existing certificates should help some users. HTH

To have "secure" as in trusted by browser, You need to purchase 3rd party certificate from common internet certification authority. One of such certificate authorities is let's encrypt who provide certificates for free. ESMC creates self-signed certificates which are not trusted unless their root CA is imported into device certificate store. @Command IT What You probably mean was certificate chain installation which was required till 6.5 due to TLS layer we used. In 7.0+ we use different TLS layer on windows (openssl) and PKCS#12 is newly required to contain entire certificate chain including root CA - system certificate store is not used anymore.

Hello, As a sidenote there was also added option to supress Apple related protection states (as many of our users don't use Apple devices). It's in MDM policy "General" > "Send iOS related application statuses". However as Apple only conforms to CA/Browser _consortium_ it's best practice to conform to these rules as well. HTH, M.

Hello, Hostname is stored in MDM configuration. We sadly removed configuration option for hostname in policy (as some users broke their MDM by changing it), so currently only supported way to change hostname is reinstallation (or repair). HTH, M.

Hello, Based on error, it seems like application does not have connectivity to MDM. If You are sure MDM site is accessible from phone You can submit customer care ticket from application (which will include all relevant logs) HTH, M.

Hello, Can you please provide output of 7.1 Agent's Diagnostic.exe action 5) - ActionDumpRegistryKeys. Dump product's registry keys. This should have been fixed in late 7.0 and 7.1, however as we realized only for english installations. If You used localized UI installation or TRANSFORMS=":insert language here" argument of installer in the previous installation the issue is still possible. Please note that Self Defense will prevent creating diagnostic data inside Agent directories so output should be set somewhere not protected. HTH, M.

Hello, Anroid devices should by default "poll" MDM server every 20-30 minutes even if they don't have "work to do". As this seems like EESA issue I suggest raising ticket over built-in funcionality in EESA - there is menu option to send customer care incident which will include logs. Customer care should reach you out if more logs are required. HTH, M.

I'm not aware of command line tool to edit policies, and policies are somewhat blackbox so supporting such tool would take some effort which isn't my decision to make. Please post suggestion into customer feedback or contact Your local customer care. HTH.

There is ServerAPI which allows for some level of automation. I believe we have pythonian interface for it as well, however unsure if it's published (if you are interested in it I'll check with guys who created it if it's in stable enough state to be published). Last but not least there is customer feedback topic which is watched by PMs. HTH.

Unsure we can solve this here, better option would be customer care ticket Some possible issues preventing new certificate being applied coming to mind. - connectivity between MDM management Agent and Server (policy was not applied) - you have some devices enrolled into MDM which causes previous certificate being still used. You can enforce immediate certificate switch via timeout in policy (next to HTTPS certificate upload in policy editor). Premature change could however break connectivity for devices which don't manage to update their trust settings with MDM server. What is possible is "-in" openssl argument of pkcs12 works differently across different openssl versions and didn't actually add chain (but only certificate). Please verify that there are 3 certificates printed out with "openssl pkcs12 -in yourpkcs12.pfx" HTH, M.

Hello, Your chain is missing root CA - in this case it's "DST Root CA X3". https://www.identrust.com/dst-root-ca-x3 You can simply append it to your chain and convert to PFX again. For "simplicity" we decided both root CA and chain have to be in configured PKCS#12 (PFX) as most customers use ESMC generated certificates. This added some overhead for those who have their certificates signed by third party certification authorities as those usually don't include root CA (there is no reason to for them) in files they provide to their customers. HTH, M.

Hello, Please upload fullchain.pem. I'll determine which root CA is missing (one vendor can have multiple CA) and write here step by step guide. M.

Hello, MDC requires root CA certificate (and entire chain) within PFX file (Certificate authorities usually don't add their root CA). You'll need to convert PFX to PEM, append CA certificate to this PEM and convert it back to PFX. This is required due to fact we need to install root CA onto devices and we have no idea if there is pre-established trust. This changed on v7 where having root CA in windows certificate store was "good enough".

It's actually "feature"... We had customers who reconfigured this and lost connectivity so this setting was removed around v 6.5

Hello, You must go through the ESMC wizard which generates certificate signing request and private key one more time and use new files generated for Apple servers. Previous CSR was generated with expired vendor certificate. HTH, M.

Hello, The issue is fixed on our backend now, please create new APNS/DEP certificate and retry the Apple signing process. Sorry for inconvenience. M.

Hello, "2019-06-28 10:57:16 W [14036] Enrollment from iOS requested but no APNS certificate provided. Enrollment profile not sent." This means MDM does not have configured (or configuration failed to apply) APNS certificate. Ensure you have policy assigned to MDM and it's actually applied. You can check via Configuration -> Get on device on which MDM is installed. "AdminConnector: Connected: true" means connection between managing Agent and MDM works (it's the chanel policy is delivered over). If this is correct change something in policy (log level etc..). Agent sadly does not attempt to send policy multiple times, so it's possilble failed delivery attempt caused this state. If you can't figure out why policy isn't applied please contact support instead, we can't request relevant log files over forum. Please also check You meet HTTPS certificate requirements, they differ for Android and iOS. https://help.eset.com/esmc_install/70/en-US/mobile.html https://help.eset.com/esmc_install/70/en-US/?certificate_mdm_https_requirements.html https://support.eset.com/kb6368/#CreateMDMCert https://help.eset.com/esmc_install/70/en-US/?mobile_connector_installation_windows.html HTH, M.

Hello, Those requirements are there mainly because iOS devices as we use built-in iOS. What iOS devices accept as trusted differs per iOS version and we described _most_ restrictive rules which should work always. (There are other requirements like RSA2048+, SHA256+ etc... for iOS described elsewhere in documentation) So in the end Your certificate may work (it will definitely work for Android devices), however when Apple brings some update to their trust validation it might stop working. HTH, M.

Hello, MultiAgent(s) trace log verbosity is determined by MDMCore trace log verbosity. It's also possible support directed You to create traceAll file which overrides this configuration (so just delete it) As a sidenote (and possibly solution) there was issue with ScanLog processing which produces periodically multiple errors inside MultiAgent logs, this is fixed in service release - AFAIK this was released into repository so You can upgrade via component upgrade task. HTH.

Hello, It's possible CloudFlare incorrectly caches some parts of configuration editor and returns out-of-date data causing this. Please create HAR log @PavelP mentioned it might help us determine whether issue is with CloudFlare or webconsole itself. Ideal would be to have tomcat access log paired with this log to determine which requests made it to server and which did not. Thanks.