madmaxoft

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

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

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.

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.

The hotfix has just been released.

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.

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.

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?

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

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.

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.

Hello, sorry for the trouble, we've identified an issue in the MDM code and we'll be releasing a hotfix for this soon.

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?

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.

The Android app devs promised to address this very soon in a service release. Until then, there's not much you can do, sorry.

Hello, could you try installing any app on that device (in any way - through market or manually or by ERA)? That should cause a new app list to be sent to ERA, which should then show the correct version. You can uninstall the app afterwards. This seems like an oversight in the Android app reporting, I'll reach out to the app devs to verify that.

Thanks for the follow up and the solution. It seems indeed possible to come into such a bad state, when a device is enrolled (from MDM's point of view) and the device itself is deenrolled (uninstall app (Android) / remove enrollment profile (iOS)) without being able to report that to MDM. Trying to re-enroll such a device will hit an error; however, MDM should report the old enrollment to ERA, so you should have seen a "ghost" device in the ERA webconsole; executing a "Stop managing" task for that device should fix things altogether - re-enrollment should start working again, because MDM would have deleted the device from its DB.

Hello, just in case, are you using the latest Android app? When you try to enter the connection manually into the app, do you get one edit box for the entire enrollment URL, or two editboxes, for server name and port? (The app with one editbox is the newer version, needed for enrolling to 6.4 MDM)

Hello, this should not happen in your version, so there is something wrong going on. I suggest you contact the support and provide details to them. As a quick and dirty solution, it is possible to remove the device manually - go to MDC's database and remove the device's row from the Device table - you can identify the device by the DeviceID column (contains the IMEI or MAC for Android devices, UDID for iOS devices). After deleting the row, restart the MDC service and then remove the device from ERA webconsole. It should not reappear anymore. However, we would really appreciate if you first contacted support so that we can fix whatever has caused the issue in the first place.

Hello, we've just updated the KB on the APNS certificate to clearly say which file goes where, have a look (step 9) and just make sure that it's what you've been doing - basically the file downloaded from the Apple portal needs to go into the APNS certificate field, and the private key downloaded from the webconsole goes to the APNS private key field). hxxp://support.eset.com/kb5771/#MDMSignedAPNCert I can see one additional problem in the log, not sure if it was due to your editing. The hostname given to MDM needs to be resolvable from the device. If you want your MDM to work on devices that leave your company network, that means the hostname needs to be publicly accessible. The one you're using, "xxx.yyy.local", is unlikely to be accessible from the outside internet. Let me know if any of this helps. Mattes

Hello, did you install the MDM server just once, or have you ever reinstalled it (for example for testing)? There's a known issue that after a reinstall, it takes some time (~30 minutes) for the new MDM server to correctly report to ERA, in the meantime the server may give out QR codes for enrollment that are invalid. If you try to add one of the failing devices once again (using a new enrollment link / QR code), does it still fail? When you enter the main MDM URL ( https://mdmhostname:9980, where mdmhostname is the hostname you configured in your MDM settings) into the device's browser, does it display the "MDM is up and running" page? Is there a browser certificate warning displayed before that?

Hello, the phone needs to see the MDM server at all times, otherwise it will not be able to report anything. Therefore you need to make sure your MDM server is available to the outside, either by putting the entire server in public internet (DMZ), or port-forwarding the two ports used for connections (9980 and 9981 by default). The hostname that you provide in the MDM configuration needs to be reachable from the phone, so if you set it to "mdm.yourcompany.com", you need to make sure that "mdm.yourcompany.com" is indeed visible from the public internet and ports 9980 and 9981 are open for MDM connections. I suspect that you set your DNS entries in your internal network only, so the MDM server is only visible from your internal network (you tested with nslookup from a computer inside, didn't you? That says nothing about the availability from the phone). The enrollment process via the QR code is in essence equivalent to setting the connection manually via app's Settings -> Remove Administrator. The QR code is just a means of simplifying it on the device, so that you don't have to type in the entire URL. So you do either the QR code enrollment, or the manual one via app's Settings. Note that you will need to add the phone identification through ERA webconsole first in either case. Enrollment via IP address is supported, but is discouraged - if the IP address changes for any reason, you will need to re-enroll all the devices. On the other hand, if you enroll via host name, if the underlying IP address changes, the hostname can be reconfigured on the DNS so that the same hostname points to the new IP address, and MDM will continue working without any further changes. "Cannot contact DNS server" is most likely a problem with your network configuration, it has nothing to do with MDM as such.

The logs are in UTC, so that (among others) the timestamp is immune to timezone and DST changes. There is no way to set any other behavior.

Hello, the logs don't seem to indicate any problem. In the /var/log/eset/RemoteAdministrator/MDMCore/trace.log file, is there any mention of the string "New command from AgentConnector"? It indicates when the task from ERA webconsole reaches MDMCore to be relayed to the mobile, and is present in up to "Information" verbosity. The log times are in UTC, hence the offset. The "<?>" in the SQL query is the parameter substitution symbol, the SQL engine binds parameters using this placeholder (and thus avoids SQL injection).