User Profile
Moombas
Level 4.4: KitKat
Joined 3 years ago
User Widgets
Contributions
Re: [Day 3] Dedicated to Dedicated: Non-negotiables for EMM/MDM in Rugged Android Deployments
Just want to add to this one: That situation is all too common but can be prevented with the right EMM/MDM strategies. Not only EMM/MDM strategie, but also app strategie. Many apps are sadly not available as apk's to provide them the "safe" way but only via playstore or unsecure sources. This is also often a pain. And the company doesn't choose apps to be used based on that but on functionality ofc. Thats why i often ask for a change in app deployment from MGP (and i remember i wasn't alone with it) side or even enhancing the controls we get from there. I could also think of, instead of the devices having the MGP connection, the EMM/MDM getting it. So the EMM/MDM downloads every assigned apk stored locally by app version so the admin gets a version control over there or anything similar.Re: [Day 1] Mobile Devices With a Sixth Sense: What Android Can Learn From Detection Dogs
I prefer it myself but the larger or wider spread the devices are in use and the more different use cases you have, the harder it is to get this noticed. But if a user reports a problem and you investigate it, always have in mind, this could affect others as well. So, not investigating for this single user but think in a larger scale. And if it turns out the issue, the user reports could hit other users as well, think about if we could prevent this and if yes, do so if the effort is worth the possible impact. So, you always rely on the endusers but often also on other support staff noticiing and highlighting things. And sometimes you detect some yourself when have a run through the current setup, especially if you updated the MDM and get new/improved functionalities.Re: [Day 1] Mobile Devices With a Sixth Sense: What Android Can Learn From Detection Dogs
There's no "one way" to handle it in my opinion. But it's a lot of monitoring and keeping eyes and ears open especially to the users. Like: Noticing devices running into full RAM because they never reboot and (especially on older Android OS versions) maybe it's worth to reboot them pro actively instead of letting them run into an issue because of this. Also to be open minded/flexible is important, so not staying in "this solution is the one and only one".Re: [Day 2] Mission Intune : When Migration Becomes a Mission (Almost) Impossible
Nice article and again a statement which we see here so often: Intune is not a real "goto" solution but more like a "have to" solution when forced by procurement as it's cheaper than other solutions (which also work way better from my experience and what i read here from others). I'm not a fan of calling any product bad but Intune really made it through a lot of hands with same opinions. Never heard of someone telling "Intune is nice" or so.Re: [Day 1] Mobile Devices With a Sixth Sense: What Android Can Learn From Detection Dogs
And some issues need a reboot to fix it (memory running full over time). But in general, yes, I'm definitely on the proactive side as well. Ideally noticing an issue and solve it proactively before users complain about it (or just a few).Re: Enable ADB debugging is grayed out - This setting is managed by your administrator
I don't know the end point but in our MDM at least for Android you can enable/disable ADB via a feature control profile: So, there must be a setting available to allow/disable it. But I'm pretty sure it's this one (as said for Android): https://developers.google.com/android/management/reference/rest/v1/enterprises.policies?hl=en#DeveloperSettings So, not sure about Chrome or even Chrome OS or Chrome admin console but i found this one: https://help.mobileguardian.com/hc/en-us/articles/360010957200-How-Do-I-Disable-Developer-Mode-in-ChromeRe: Samsung Devices: Can't call from a personal app
...because the workaround to reboot the devices was easier for endusers than having the issue and work with us to get all the data needed for further investigation... Yeah we see this as well quite often ;) That's why we try to provide as less as possible workarounds but in your case it was definitley needed.Re: Zero Touch phones randomly wipe themselves
The important thing is here when they enroll from company network and there the ZT was not detected entirely correct (why ever) ofc on their unrestricted home wifi it does and triggers the wipe. Please try if devices enrolled not using the company network (so: mobile data or completely unrestricted wifi) show the same issue.Re: [Product Update] RCS Archival is now available on managed Android devices
Yes and ideally more. In my opinion if an app provides managed app config (which should be at least for the Google ones the case), it should provide the possibility to set every setting available in the app and (if some additional may make sense in case of enterprise, even more). So, for the current example, everything you can find here and below for the messaging app (Always like: True/False/Let user decide) + the option to disable the ability that other apps may be able to read messages (the option to define an app for it is already there):Re: [Product Update] RCS Archival is now available on managed Android devices
Intersting to read but will the configurations of this app being extended regarding this? For example, what if i don't want this function to ensure no external app at least can do this (reading the text messages,...) or other settings available in the app (for RCS and way more).Re: Zero Touch phones randomly wipe themselves
Andrius Not sure what you meant about this one (i don't see my post from the past here) but i would really like to know if someone complains on my experiences or trying to help as such an "opinion". It's a fact that Android devices registered into the ZTP and enrolled without being able to contact the ZTP correctly ((partially) limited wifi,...) but later can, the device triggers a device wipe (default set to 2 hours) because it thinks it wasn't enrolled as it should. Ofc devices enrolled without registered in ZT don't have this (security) behavior. That doesn't mean that this is the case here but it means that something is issuing that this doesn't get detected correctly but the config provided. Do the devices use always the same network (the issuing ones) and did you try if you see the same using mobile data during enrollment instead?
