Replies posted by jasonbayton

Only 4 years? Microsoft is really turning that ship around 😂 Well done mate, good job persistently pestering them!

Something to consider - on Pixel and other devices Google Photos is _the_ gallery app, while Samsung uses their own version. This can explain why some devices have it enabled by default while others show installed but inaccessible.So you’ve got Google Photos deployed as a Public app from within intune, that should remove any other obstacles I can think of.. do you have the ability to pull a bug report? Perhaps MHS itself is falling over for some reason.If you’re only using MHS for kiosk (no SSO, intune features) you can try your kiosk experience through my kiosk app generator here - https://gen.bayton.org - you can build a kiosk experience from scratch and deploy it as a private google play app. If that works as intended, you’ll know it’s something with MHS.

+ in the GCP console, error messages, etc. Lots can be done to make this suck less indeed.

Unfortunately it's not hidden, it's just not obvious enough in the right places to properly surface the requirements to new partners/orgs. https://developers.google.com/android/management/permissible-usage#quotas_and_restrictions  

Sorry for the delay, email alerts are rubbish  Have you got pubsub hooked up? If not, you’ll need to poll AMAPI for updates. You should also ensure your enterprise subscribes to the relevant topics. This little setup guide may help you. 

I had a quick whip over their documentation but didn’t see anything explicit on self-hosting, but my assumption is they’re making you tie in your own Google Cloud Project?If so, that’ll be why - these are 0-quota by default and you must provide a business justification to Google to have your project granted any quota. More here: https://bayton.org/android/android-enterprise-faq/amapi-device-quota-limits/ If it’s just a personal use project you’re after, DM me and I’ll sort you out with management.

@w4lter I’m chatting with Samsung also, can I check if you’re using any other Knox services, and if the user tried disabling all other active Knox admin apps?

@gaoyu1 yep an activation code is required in both cases, the code determines whether it's importing a profile or just pointing at the server 

@gaoyu1 a and b are the same process for you, the only difference is the activation code used. In a the EID isn't on SMDP, so you provide a full profile for the esim with the LPA URL, in b you provide an LPA that just points to sm-dp. Sm-dp gives the device the profile on connection to it.  Does the operator have experience with MDM?

Take two videos,  First use an activation code in the command with a full esim profile and set it to activated, show the device installing it silently Second use an activation code that just points to the sm-dp+ where the device has already been assigned a similar based on it's EID, set it to active, record it installing on the device

Related: https://www.androidenterprise.community/android-enterprise-general-discussions-3/activating-device-owner-in-android-16-1434

Via https://www.androidenterprise.community/android-enterprise-general-discussions-3/activating-device-owner-in-android-16-1434 ​@Kirk 

Google will usually point back to their family link option as *the* parental control offering they support. In terms of the documentation, their permissible use page explicitly calls out monitoring outside of enterprise management. You can’t really have a parental control app that doesn’t monitor the user, as that’s the fundamental USP for it.> Solutions developed exclusively for the purpose of device or user monitoring, fingerprinting, or eavesdropping, independent of enterprise management. Source. Normally I’d have suggested switching to a custom DPC, however more recently these rules were applied to that, also Which leaves you effectively abusing special permissions and working around the limitations these rules impose for family management, which I agree is detrimental to the ecosystem compared to embracing the use case and carefully guiding it through the device owner management route; no one will stop developing this given the demand simply because one avenue becomes untenable

@Kirk FWIW I can’t replicate on my projects, ​@Sreekanth if you’re in the Partner Portal, raise it there also. (emm.androidenterprise.dev)

Yes, I’ll link to device trust because that’s clear on the API available: https://developers.google.com/android/management/device-trust-signals Device Security Patch Level SoftwareInfo#getDeviceSecurityPatchInfos() returns the current security patch level of the device for different updatable components: SYSTEM KERNEL SYSTEM_MODULES (also known as Android's mainline modules)   And also available to DPCs - https://developers.google.com/android/work/security-posture-signals A DPC or application (because it’s not restricted) can also query the version of com.google.android.modulemetadata to get the device mainline version. This is what I do for Managed Info.

AMAPI's AddEsimParams.activationCode is mandatory by Google's design. I’m not sure I draw the same conclusion as you from the docs.. The activation code is the destination from which the profile is downloaded, it can either be a full profile or a partial profile, in the latter you don’t provide an activation code with a full eSIM configured, but rather point to an SM-DP+ server that has device identifiers mapped to an eSIM config on that end. If you want the admin not to type a code, the EMM has to fetch one via direct integration with the carrier. The EMM then calls AMAPI's AddEsim with the carrier-supplied code and the user sees nothing. I’ve implemented this a couple of times to date, perhaps these references will help:netlify/functions/_lib/amapi-command.ts (ADD_ESIM validation) - ADD_ESIM throws AmapiCommandValidationError('ADD_ESIM requires params.activationCode') if the field is missing. src/components/device/CommandModal.tsx (Add eSIM form) - the UI marks activationCode as requ

@w4lter can I check, in your system do you use Knox Service Plugin? Samsung from what I recall added an auto-block for DA apps when that was in use.. I wonder if that was left over? The screenshot is not complaining about COPE per-se, it’s not blocking Intune enrolment because there’s a device admin, there’s a leftover restriction on DA apps by the looks which should have been removed when the device was relinquished.. which makes me believe it’s a Samsung bug. They’re in pastures-new now, so I wouldn’t bother them asking for logs or debugging.. but it’s definitely something I’d want to get to the bottom of.

Oh that’s interesting. I can’t comment on this specific scenario because it’s not something I’ve personally tested.. but it surprises me that a device admin would block Intune enrolment. Device admin apps aren’t rare. Did they share a screenshot or log/error with you?

Relinquishing is the process of fully removing control from MDM without a wipe on a company-owned device. A couple of linked-service artefacts aren’t really justification for fully wiping a device when all trace of MDM has been removed; consider if they hadn’t removed it from KME, that enrollment service app would trigger after the wipe too :) 

Enrollment service is tied to KME, it is 1,000% a Samsung app & something Samsung preloads on their devices. Because you’ve relinquished ownership rather than wiped the device, it’s expected it would still be showing enabled; KME and EMM are two different solutions essentially, with limited knowledge of one another. You’ve removed the device from KME so the service isn’t in use, I wouldn’t personally worry, and would reassure the end user it’s a preloaded app, but fully disconnected from your control.

Because I’ve been Google Workspace/G Suite for 10 years now, I’ve never had access to Google Family, Google One, etc.. EMM policies combined with custom-developed applications effectively replace Google Family for devices here.  I also have various desk/wall mounted kiosk tablets under kiosk policies doing their required jobs, including one outside directing delivery drivers and such :)   Wellbeing doesn’t suit the use case across the board, and since I’m not a fan of disparately setting up different methods of management, centralising it all to EMM is the obvious choice for me.

Howdy, Google isn’t taking away Gmail signup. They’ve left it part of the signup flow intentionally and this isn’t changing. I like your use case, I do similar with my devices (as well as several other use cases), but I own my domain so the move into a workspace environment was not a concern for me.  ME’s guidance is incorrect, perhaps that’s something the team can reach out to them to correct ​@Lizzie?  But the short of it is, you can carry on with Gmail. You’re encouraged to move to a workspace but even if you do, you don’t have to validate the domain etc. It just means there’s a chance someone could buy a domain in future and look to claim it themselves.