Jump to content


ESET Staff
  • Posts

  • Joined

  • Last visited

About madmaxoft

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location
    Czech Rep.

Recent Profile Visitors

835 profile views
  1. Hello jethro, You can do that, but then the certificate won't be trusted by default by the mobile devices, so upon enrollment every device's user will have to click "trust this certificate".
  2. No, just MDC, it will distribute the new certificate to all the devices on its own ("CertChange") and clear the warning once it's been done. Note that MDC will wait for all the devices to connect (because they need to update the certificate to be trusted); there's a timeout setting in the policy next to the HTTPS certificate that specifies when to apply the new certificate even if not all the devices have connected yet (in such a case, the devices that failed to connect will not be able to connect anymore and will need to be re-enrolled; for this reason it's smart to set the timeout quite large, the default is one month).
  3. Hello, based on your screenshot, I'd say there are two things wrong. @Marcos has pointed you to the wrong certificate - the one you should be modifying is "HTTPS certificate" in "General". And certificate you're trying to set is wrong - it says "Proxy certificate" (which is correct for the Connection's certificate - that's what's used for communication to the ESMC server, but it's wrong for the HTTPS certificate). You need to generate a certificate with hostname matching your MDC's hostname and set it as the HTTPS certificate.
  4. Sorry for the late answer. The hotfix has just been released. I thought we had instructed the documentation team to put the info in the docs, but I guess we weren't thorough enough. We'll fix that. If the CPU usage is higher than it used to be for you, then it's a sign there's something wrong, that's for sure. There shouldn't be any increase. You should contact the support in this case, as they will request more details that are not wise to share on a public forum. Anyway, as for the CPU usage, MDC is built in such a way that the CPU usage doesn't depend on the number of managed devices. So it may seem a bit too much for a few devices, but it will stay more or less the same even if you manage hundreds or thousands of devices. Of course nobody is perfect, so there might be a hidden edge case, a bug that you might have come across, so we would like to know and fix it. Having MDC on a separate system has a few benefits, so you should consider it anyway. The MDC machine must be visible from public internet, while ERA server could be hidden behind firewalls / NAT / ... . The MDC needs a hostname to work (so that the phones have a fixed address to contact), using the ERA hostname (or even worse, an IP address) binds your hands unnecessarily. Performance would be another point.
  5. The deltalogs growth will be fixed by the new release, the other tables are not performance-critical and shouldn't be cleaned up in any way. Note that the MDC is expected to have a high base CPU usage, and only very small increments in usage for each additional device managed. That's one of the main reasons why we recommend to not instal the MDC on the same machine as the ERA server. As long as the CPU is not constantly at 100 %, there's no reason to worry, really. Until you have the new version installed, it is very likely that no tasks and no logs will be delivered between ERA and MDC, so you should upgrade as soon as it's possible.
  6. There is a new version of Mobile DeviceConnector in the final stages of QA, it should be available within a few days. Please upgrade to it, once available, then re-run the DELETE sql query, just to be sure. If it still has a high CPU usage, please do contact the support, they'll ask for more information and will try to help you individually.
  7. That's a much better number. The CPU usage should gradually go down. Can you check if there are any more tables in the DB that have more than a 5000 rows in them? The following SQL query produces a list of tables and approximate row counts: show table status What is your exact MDM version?
  8. That seems like a failed cleanup. Please try executing this SQL query in the MDM DB, then check if the number of rows has decreased substantially: DELETE FROM tbl_ma_dataminer_deltalog WHERE KeyFrameNo < -10
  9. Hello, could you check the MDM database, the row counts in the various tables? Especially the tbl_ma_dataminer_deltalog table, how many rows does it contain, whether hundreds, thousands, tens of thousands. Thank you.
  10. Hello, sorry for the trouble, this is caused by an issue we had identified in the MDM code some time ago, we'll be releasing a hotfix for MDM soon.
  11. Hello, sorry for the trouble, we've identified an issue in the MDM code and we'll be releasing a hotfix for this soon.
  12. Hello, are you using a HTTPS certificate for MDM generated by ERA, or did you acquire one from a 3rd party (CA-signed) or is it self-signed? If it was generated by ERA, was it ERA earlier than 6.3, or a later version?
  13. I've received word from the Android app developers that the issue is fixed, but they haven't released a new version yet and they don't know when a new release will be available.
  14. The Android app devs promised to address this very soon in a service release. Until then, there's not much you can do, sorry.
  • Create New...