enrolment
121 TopicsZero-Touch-Registration is not available
Dear Community Members, We are currently encountering an issue with the enrollment of three recently acquired Samsung S23 devices. While we are able to successfully enroll other devices, these specific models are presenting a persistent problem. The error message displayed is as follows: "Zero-Touch Registration is not available. Check your internet connection and try again." To address this, we have attempted the following troubleshooting steps: Utilized mobile data from various carriers as well as Wi-Fi connections, yet the error persists. Formatted the devices. Completely removed the devices from the Zero-Touch portal (https://partner.android.com/zerotouch#) and subsequently re-added them. Attempted manual enrollment using the QR Code provided by Intune. Despite these efforts, the issue remains unresolved. Interestingly, we have successfully enrolled a Samsung XCover 5 without encountering any similar difficulties. We are reaching out to inquire if others in the community are experiencing similar challenges with Samsung S23 devices. Any insights or suggestions would be greatly appreciated. Thank you for your attention to this matter. Kind regards, ZackorySolved37KViews2likes71CommentsIntune Enrollment QR Code - Two connection types
Hi, all I'm trying to modify our original enrollment token (Intune - Fully Managed Device QR Code) so that the device can enroll using mobile data OR any wifi network. I managed to add this to an existing QR code android.app.extra.PROVISIONING_USE_MOBILE_DATA":true, Unfortunately, using such a QR code on a phone that does not have mobile data transmission means that the enrollment process no longer asks for the WIFI network and ends in failure. To sum up, I want to create an enrollment code that works as follows: 1. Allow enrollment using mobile data. 2. If mobile data does not work - ask for any WIFI.18KViews1like6CommentsHow to register to be a Google Partner?
Dear Community Members, We are considering registering to be a Google Partner. After submitting our application, we were declined without specific reasons. Are there any instructions on Google Partner requirements that we could follow? Any help would be appreciated.17KViews1like16CommentsDevice Owner Provisioning
Hi Team, I am trying to make my application as device owner app, I am trying to use QR code for provisioning. I am unable to acheive the result. When I scan the QR code which I have generated (Generated QR code without enrollment token) in a factory reset device I am getting an error stating " Couldn't set up your device, for help contact your IT admin. Could you please help me where I am going wrong. when I tried getting Enrollment Token using AMAPI I am getting the following error com.google.api.client.googleapis.json.GoogleJsonResponseException: 400 Bad Request POST https://androidmanagement.googleapis.com/v1/enterprises/%7B573991258109%7D/enrollmentTokens { "code" : 400, "errors" : [ { "domain" : "global", "message" : "Invalid enterprise id. Provide a valid id.", "reason" : "badRequest" } ], "message" : "Invalid enterprise id. Provide a valid id.", "status" : "INVALID_ARGUMENT" }Solved12KViews1like18CommentsMissing Apps in managed Play Store
We are enrolling devices as corporate-owned with work profile, as well as fully managed devices without work profile. All devices receive a device-based Google-Account via EMM registration on enrollment. Our EMM is Workspace One. The issue started around the end of July. On a few devices many approved apps didn't show up at the frontage catalog in the managed Play Store. The missing apps could still be found via search. After delete app-data for the Play Store the missing apps reappeared. Now a month later the issues seems to be getting worse. The issue is happening on nearly every device. Some devices are even unable to find the missing apps via search, even though they are assigned for that app. Deleting app-data for the Play Store does no longer bring back the missing apps. Even waiting for 24h or longer changes nothing. Sending an install command for a missing app from the EMM console to the devices installs the app without issues but still does not add it to the managed Play Store. Regarding devices, we are mainly using Samsung A-Series with latest patches. I also tested on a Fairphone 4 with Android 12 (August 2023 Patch) and Google Play system update of August 2022 which has the same issue and a Pixel 6a. There were no changes in our environment since that time. The only thing that changed is the security patch level for the devices and the Google Play Services. We are not sure if this is an issue with the devices OS, with the EMM or if Google is having troubles on their side. Can someone relate to this issue or know if and how this can be seen in Android Logcat or maybe other logs?Solved10KViews0likes9CommentsAndroid device enrolment issue - Third party MDM app is not being installed during the sign-in process
Hello Android Enterprise Team, We are experiencing a new issue with our Android device enrolments where the third-party MDM app(CyberArk MDM App) is not being installed during the sign-in process. App is configured in Android Management between our CyberArk tenant and Google domain, and user accounts are configured to do set-up for device owner enrolment. Previous device enrolments are still working as expected, and we first noticed this issue on 13-11-2023. No changes have been made to either the CyberArk configuration/device policy or to Google Admin. This issue is affecting all new Android device enrolments, even across Android versions (Android 10-14 affected). Could you please help to fix this issue? Thanks in advance Error Log: 11-24 14:35:49.411 3842 4105 I Auth : (REDACTED) [BroadcastManager] [BroadcastManager] Broadcasting bad device management=%s 11-24 14:35:49.414 3842 4105 I Auth : [AccountStatusChecker] Error when fetching package info [CONTEXT service_id=343 ] 11-24 14:35:49.414 3842 4105 I Auth : sdq: Invalid package signature for app=com.google.android.apps.work.clouddpc 11-24 14:35:49.414 3842 4105 I Auth : at sdr.c(:com.google.android.gms@234414022@23.44.14 (100400-580326705):190) 11-24 14:35:49.414 3842 4105 I Auth : at sdr.a(:com.google.android.gms@234414022@23.44.14 (100400-580326705):39) 11-24 14:35:49.414 3842 4105 I Auth : at sbq.a(:com.google.android.gms@234414022@23.44.14 (100400-580326705):221) 11-24 14:35:49.414 3842 4105 I Auth : at sbp.p(:com.google.android.gms@234414022@23.44.14 (100400-580326705):34) 11-24 14:35:49.414 3842 4105 I Auth : at sbp.q(:com.google.android.gms@234414022@23.44.14 (100400-580326705):8) 11-24 14:35:49.414 3842 4105 I Auth : at sbp.m(:com.google.android.gms@234414022@23.44.14 (100400-580326705):11) 11-24 14:35:49.414 3842 4105 I Auth : at sss.a(:com.google.android.gms@234414022@23.44.14 (100400-580326705):610) 11-24 14:35:49.414 3842 4105 I Auth : at ssy.b(:com.google.android.gms@234414022@23.44.14 (100400-580326705):94) 11-24 14:35:49.414 3842 4105 I Auth : at ssv.a(:com.google.android.gms@234414022@23.44.14 (100400-580326705):642) 11-24 14:35:49.414 3842 4105 I Auth : at slx.h(:com.google.android.gms@234414022@23.44.14 (100400-580326705):3) 11-24 14:35:49.414 3842 4105 I Auth : at ncu.n(:com.google.android.gms@234414022@23.44.14 (100400-580326705):284) 11-24 14:35:49.414 3842 4105 I Auth : at ncu.c(:com.google.android.gms@234414022@23.44.14 (100400-580326705):1087) 11-24 14:35:49.414 3842 4105 I Auth : at ncu.h(:com.google.android.gms@234414022@23.44.14 (100400-580326705):2) 11-24 14:35:49.414 3842 4105 I Auth : at ncu.fe(:com.google.android.gms@234414022@23.44.14 (100400-580326705):147) 11-24 14:35:49.414 3842 4105 I Auth : at mzt.onTransact(:com.google.android.gms@234414022@23.44.14 (100400-580326705):117) 11-24 14:35:49.414 3842 4105 I Auth : at android.os.Binder.transact(Binder.java:949) 11-24 14:35:49.414 3842 4105 I Auth : at bdrr.onTransact(:com.google.android.gms@234414022@23.44.14 (100400-580326705):10) 11-24 14:35:49.414 3842 4105 I Auth : at android.os.Binder.transact(Binder.java:949) 11-24 14:35:49.414 3842 4105 I Auth : at awwb.onTransact(:com.google.android.gms@234414022@23.44.14 (100400-580326705):147) 11-24 14:35:49.414 3842 4105 I Auth : at android.os.Binder.execTransactInternal(Binder.java:1056) 11-24 14:35:49.414 3842 4105 I Auth : at android.os.Binder.execTransact(Binder.java:1029) 11-24 14:35:49.414 3842 4105 I Auth : Caused by: android.content.pm.PackageManager$NameNotFoundException: com.google.android.apps.work.clouddpc 11-24 14:35:49.414 3842 4105 I Auth : at android.app.ApplicationPackageManager.getPackageInfoAsUser(ApplicationPackageManager.java:275) 11-24 14:35:49.414 3842 4105 I Auth : at android.app.ApplicationPackageManager.getPackageInfo(ApplicationPackageManager.java:244) 11-24 14:35:49.414 3842 4105 I Auth : at akut.e(:com.google.android.gms@234414022@23.44.14 (100400-580326705):7) 11-24 14:35:49.414 3842 4105 I Auth : at sdr.c(:com.google.android.gms@234414022@23.44.14 (100400-580326705):16) 11-24 14:35:49.414 3842 4105 I Auth : ... 20 more 11-24 14:35:49.414 3842 4105 I Auth : [AccountStatusChecker] Canceling DM notification because of DM suppression [CONTEXT service_id=343 ] 11-24 14:35:49.416 3842 4105 W Auth : [GetToken] GetToken failed with status code: ThirdPartyDeviceManagementRequired9.9KViews0likes15CommentsFactory Reset Protection and Captive Portals
A bit of background on this, we're currently moving to use COPE Enrolment for all of our devices after using BYOD Enrolment for devices purchased by our org. Utilising BYOD we had issues with users signing into their gmail accounts and leaving the business and we were locked out of the device by Factory Reset Protection (We've used Knox Mobile Enrolment to solve this). This all made sense as it was a BYOD device and for consumers etc it makes a lot of sense. The problem we've encountered is even with COPE enroled devices, if a user doesn't remove their gmail account from the personal profile before resetting the device when the device is used again you're unable to use a Captive Portal network for setup again and this error message is received - "Unable to sign in to Wi-Fi AP. An unauthorised factory reset has been performed on this device. the sign-in screen cannot be accessed." Even after enrolling the device using a WPA2/3 Network and signing in with the google account in question and manually removing it then resetting the device we still have this issue, it's as if the FRP flag gets set and isn't being removed for some reason. It seems odd any network and even cellular allows you to continue but a captive portal connection doesn't. Has anyone else encountered this issue? Thanks.Solved9.6KViews0likes12CommentsWidgets on COPE - MS Intune
Hey, Unfortunately there are no settings and/or no chance configure Widgets on COPE in MS Intune. There is specific setting in Intune restrictions config profile to allow/disallow Widgets for BYOD method. Is this problem tied only MS Intune or is this something for Google? Majority of our 10k fleet enrolled as COPE and it's a big gap not having widgets available for Work Apps. Thanks Jarmo8KViews0likes19CommentsCan you skip network connection in Android Enterprise Edition?
Hello community, We have Samsung XCover6 Pro Enterprise Edition sent to customer in May this year. (Android v.12) They have started the phone and then didn't enroll it. They have just started the phone and put it on the shelf and battery has died and now they have started the phone. There are two problems: 1. They can skip to connect to the Wi-Fi 2. Even if they connect to Wi-Fi the phone doesn't get enrolled, the enrollment phase never comes up, you can just continue to setup the normally If we remove the phone from Zero Touch Portal, hard wipe the device by connecting it to a PC and then upload it to ZTP and connect it to Wi-Fi. Then it starts with enrollment. So I wanted to test this myself. I took the exact same model of the phone Samsung XCover6 Pro Enterprise Edition from our shelf and started it and to my surprise I COULD NOT skip network connection. Now the only difference between the phone that I tested and the phone that we sent to the customer is that, we sent the phone to customer like 6 months ago. But my test phone purchased recently, like a month ago. I tested this with several different Enterprise phone models and got the exact same result! COULD NOT skip network connection. I had to connect to a network before continuing with the setup. This is exactly what I want because of the obvious reasons. So my questions: Isn't this policy / feature (that you MUST connect to a network) by default set to TRUE for all Android Enterprise? Or is it different based on Android version?Solved7.5KViews0likes14Comments- 7.5KViews2likes9Comments