Our company currently has no device management, so our phones are essentially unrestricted. We have roughly 50–100 devices, mostly Samsung, and want to introduce mobile device management now, with Windows laptop support as a possible next step. Cost is important, and we do not currently have Microsoft business accounts, although we do run an Exchange environment.
I have been testing ManageEngine but have run into several problems. The interface has been difficult to navigate, and although the restriction policies seemed to work, self-enrolled devices did not consistently receive the correct applications or connect properly to the managed Google Play Store.
My biggest concern is BYOD management. On both a Samsung and a OnePlus phone, I was able to use lost mode and lock the entire device even though the phone was not company-owned. I am not sure whether that behavior is expected or whether I configured it incorrectly.
Ideally, company-owned phones would support supplier-based enrollment or QR-code setup, automatically receive the user's profile and required settings, and allow the company to enable lost mode, remotely wipe the device, and provide remote support. Personally owned phones should use a work profile enrolled through an invitation or QR code. Those devices should only enforce security for the work profile or require a suitable password, allow the work profile to be removed remotely, and keep company data separate from personal data.
I am new to MDM, so I would appreciate advice on suitable products, enrollment testing, Samsung-specific setup, and how to avoid locking or wiping an employee's personal phone.
4 Answers
Test the enrollment experience before comparing feature checklists. Try the complete process on several devices: enrollment, user assignment, policy delivery, application installation, managed Google Play access, and removal. If enrollment is unreliable or confusing, the product will be frustrating to operate every day, even if its policy controls look good. Test both fully managed company devices and Android work-profile enrollment for BYOD.
Since most of the phones are Samsung, set up Samsung Knox Mobile Enrollment early and ask your hardware suppliers to associate future purchases with it. New company-owned Samsung devices can then automatically connect to the selected MDM during setup instead of being handed to users as unrestricted personal devices. For the broader platform, Google Workspace may be worth evaluating because its Android management is relatively native. Samsung also offers its own management options, but those may be less suitable if you need strong support for other manufacturers and Windows later. Either way, licensing and implementation costs are unlikely to be zero.
First separate the requirements for company-owned and BYOD phones. A company-owned device can generally be fully managed, locked, located, or wiped. A personally owned device should normally use Android Enterprise work-profile management, where the organization controls only the work container and its data. If your testing allows lost mode to lock the whole personal phone, check whether you enrolled it as a fully managed device instead of a work-profile device. That distinction is more important than the product name.
For the setup you described, make sure the MDM supports two distinct enrollment modes. Company-owned phones should use Samsung Knox Mobile Enrollment or QR-code provisioning and be enrolled as fully managed or corporate-owned devices. BYOD phones should use an invitation or QR code to create an Android Enterprise work profile. The work profile can receive required apps, enforce work-related security settings, and be wiped independently without removing the user’s personal data. Also verify exactly what “remote wipe,” “lost mode,” and remote support mean in each enrollment mode before deployment; those controls can affect the entire device on corporate enrollment but should be limited to the work profile on BYOD.
That makes sense. I’m currently testing Miradore and ManageEngine, so I’ll focus more on the actual enrollment and app-delivery process rather than just checking whether a feature exists.