ChromeOS Device Enrollment Essentials
This guide summarizes the mandatory steps to enroll devices, allowing your organization to enforce all device and user policies set in the Google Admin Console. 1. Prerequisites: Don't skip these Before enrollment, ensure you have: Administrator access: You must use an administrator account with the necessary privileges. Valid license/Upgrade: Enrollment consumes a valid Chrome Enterprise Upgrade, a bundled Chromebook Enterprise device, or Kiosk & Signage Upgrade license. Terms of Service (TOS) Acceptance: You must accept the TOS in the Admin Console (Devices > Chrome > Devices). Note: You must enroll the device before any end-user signs in. If a user signs in first, you must wipe the device and restart the process. 2. Enrollment methods [See video] A. Manual enrollment (The Ctrl+Alt+E Method) Use this for individual device setup or if zero-touch isn't configured. Stop at the sign-in screen: Power on the device but do not sign in. Initiate enrollment: Press the Ctrl + Alt + E shortcut (or select "Enterprise enrollment"). Sign in: Use an eligible admin or user account. Choose license: Select the correct license type (Enterprise or Kiosk & Signage) to ensure the right features are applied. B. Automatic enrollment This method significantly speeds up large-scale deployments: Zero-Touch Enrollment: For new ChromeOS devices purchased through an authorized reseller, the devices automatically enroll upon connecting to the internet. Flex Remote Deployment: The ChromeOS Flex Remote Deployment (FRD) is a solution that enables IT administrators to perform a zero-touch remote installation of ChromeOS Flex onto large fleets of compatible devices running Windows, followed by automatic enrollment. 3. Key admin controls & Best practices These policies, managed in the Admin Console, give you granular control over the process: Enrollment permissions: Control who can enroll a device. It's a good idea to restrict this to IT staff, or only allow re-enrollment of wiped devices to prevent unauthorized new devices from being added to your domain. Asset tracking: Set the Asset identifier during enrollment policy to allow the technician or user to enter the Asset ID and Location during setup. This is critical for accurate inventory management. Enforced enrollment: Use the Initial sign-in (Enrollment controls) policy to Require users to enroll device. This blocks a user from signing in to a non-enrolled device if they are eligible to enroll it, enforcing compliance. 4. Real-world deployment examples Manual setup (New staff): An IT technician uses Ctrl + Alt + E and enters the Asset ID and Location before confirming the enrollment, ensuring the device is correctly tagged and placed in the appropriate Organizational Unit (OU) from day one. Mass deployment (New office): Devices purchased with Zero-Touch automatically enroll upon network connection. Policies are instantly enforced, and the device is ready for the first sign-in without any manual IT intervention. Kiosk/Signage: When setting up a lobby display, the admin selects Enroll kiosk or signage device during the manual enrollment steps. This locks the device down for Kiosk Mode, preventing general user sign-ins as required by the license type. For more information check out the article in the Help Center: Enroll ChromeOS Devices And continue on through our Getting Started User Guides to the left.ChromeOS Device Management: The Enterprise IT Fast Track
We know you're busy, so let's get straight to the point on managing your ChromeOS fleet in an enterprise environment via the Google Admin Console. The foundation: Licensing and fleet access Centralized management is unlocked by a license. The article clarifies your three primary license options for provisioning a ChromeOS fleet: Chrome Enterprise Upgrade (CEU): This is the standalone license (annual) you purchase separately for any standard ChromeOS device to bring it under enterprise control. Chromebook Enterprise (CBE): These devices come with the CEU license embedded for the life of the hardware. This offers a zero-touch, perpetual management solution right out of the box, streamlining large-scale deployment. Kiosk & Signage Upgrade: This is designed specifically for ChromeOS devices used as single-purpose kiosks (like self-service terminals) or digital signage displays. The licenses can either be purchased separately (annual) or bundled with the device (perpetual). Once the appropriate license is secured, enrollment links the physical device to your domain, granting you the full suite of policy controls. 2. Core control: Policies, security, and networking The power of the Admin Console is the ability to enforce settings based on who is signing in and which device they are using: Security & data protection: Enforce enterprise-grade policies like Forced Re-enrollment (preventing unmanaged use after a wipe), remote device disablement for lost assets, and strict sign-in restrictions (e.g., only allowing users from your corporate domain). Seamless network access: Remotely push necessary Wi-Fi profiles, proxy settings, and VPN certificates directly to devices. This ensures employees connect securely to internal resources immediately upon sign-in, regardless of location. Software distribution: Maintain a secure and standardized environment by force-installing, pinning, or blocking corporate web apps, PWAs, and extensions. 3. Example Enterprise Use Cases ChromeOS devices can excel in a range of environments where the device has a dedicated, shared, or public-facing role: Kiosk mode: Dedicate a Chromebase or Chromebox to run a single, purpose-built application, such as a retail Point-of-Sale (POS) terminal, a corporate visitor sign-in app, or a dedicated inventory scanner in a warehouse. Managed Guest sessions: Control shared-use devices in environments like office reception areas, business centers, or hot-desking stations. Sessions are non-account based, with all user data wiped upon logout, ensuring privacy and a fresh, secure device for the next user. Logged in user: Allow individual employees to sign in with their managed enterprise account (e.g., Google Workspace), providing a personalized, secure, and fully managed desktop experience. User data and settings are synced to the cloud, enabling quick, seamless migration to a replacement device and ensuring all corporate security policies and access controls are enforced. Real-World Application The power of ChromeOS management comes from applying these policies dynamically across your organization: Deployment example: Imagine provisioning new corporate laptops. You use the Admin Console to force-install the VPN extension and push the corporate Wi-Fi profile to the Corporate Devices Organizational Unit (OU). The employee receives the device, signs in, and everything is instantly configured. For more information check out the article in the Help Center: About ChromeOS Device Management And continue on through our Getting Started User Guides to the left.
Intune - Swapping Managed Google Play Account with Devices enrolled in Device Administrator and AOSP
Hi All, My Intune environment is connected with an old-school gmail.com account - i access the managed store page by going to https://play.google.com/work to approved apps / etc. - This was an old solution that saw little to no use. We're now looking at requiring Intune enrollment on our android devices and it'll get a ton of use once we do that. I'd like to upgrade my account to an Android Enterprise account, but it looks like to do that I'll need to disconnect the Managed Google Play account from Intune. My understanding is that I will need to un-enroll all my android devices from the tenant before doing that. For personally owned devices with work profiles, that's not a problem - we only have 3 PoC users that I can unenroll. The only other two enrollment options we use are Device Administrator (For Yealink teams phones...) and AOSP (For.. newer.. Yealink teams phones). Will disconnecting Managed Google Play affect the enrollment of Device Administrator or AOSP? Thanks!
Common identifier between AMAPI & Require for setup app for validation
We are enrolling devices using AMAPI by generating a QR code with an assigned policy either for work profile or fully managed enrollment. During enrollment, the device prompts for a require for setup app, which, after configuration, returns RESULT_OK, marking the setup as complete and finalizing the device enrollment. Before returning RESULT_OK, To identify the enrolling device, the backend gets the device ID and enterprise ID from the Pub/Sub provisioning notification. The device ID (which matches the GSF ID) is then sent by the require for setup app to the backend for validation. This identifier is also used to enforce enrollment limits based on the enterprise license count. The Issue: Up to Android 14, retrieving the GSF ID was possible. However, in Android 15, it now returns null. Question: Is there an alternative identifier that can be used to identify the enrolling device—one that the backend can retrieve and that the setup app can also access during enrollment? Below is the information we receive from Pub/Sub when a device is enrolled: { "name": [*Hidden for privacy reasons] "managementMode": "PROFILE_OWNER", "state": "PROVISIONING", "enrollmentTime": "2025-04-04T06:17:02.751Z", "lastPolicySyncTime": "2025-04-04T06:17:02.817Z", "softwareInfo": { "androidVersion": "15", "androidDevicePolicyVersionCode": 10323580, "androidDevicePolicyVersionName": "128.32.3 (10323580)", "androidBuildNumber": "AP3A.240905.015.A2", "deviceKernelVersion": "5.15.149-android13-8-00010-gc2e0ba41ba85-ab12040008", "bootloaderVersion": "unknown", "androidBuildTime": "2025-03-11T13:26:50Z", "securityPatchLevel": "2025-03-01", "primaryLanguageCode": "en-IN", "deviceBuildSignature": "c9009d01ebf9f5d0302bc71b2fe9aa9a47a432bba17308a3111b75d7b2143456", "systemUpdateInfo": { "updateStatus": "UP_TO_DATE" } }, "hardwareInfo": { "brand": "Redmi", "hardware": "mt6835", "deviceBasebandVersion": "MOLY.NR17.R1.TC8.PR2.SP.V1.P51,MOLY.NR17.R1.TC8.PR2.SP.V1.P51", "manufacturer": "Xiaomi", "serialNumber": [*Hidden for privacy reasons] "model": "23124RN87I", "enterpriseSpecificId": [*Hidden for privacy reasons] }, "policyName": [*Hidden for privacy reasons] "memoryInfo": { "totalRam": "5865836544", "totalInternalStorage": "806965248" }, "userName": [*Hidden for privacy reasons] "enrollmentTokenName": [*Hidden for privacy reasons] "securityPosture": { }, "ownership": "PERSONALLY_OWNED" } *Updated by Community admin - removed due to privacy reasons 4 April
GSF ID not generated after device enrollment on Android 15
Hi everyone, We’re facing an issue with devices running Android 15 — after successfully enrolling them in our Android Enterprise setup (Device Owner / Fully Managed mode), the Google Services Framework (GSF) ID is not being generated. This issue did not occur on Android 13 or 14; the GSF ID was available immediately after enrollment. However, on Android 15, the GSF ID remains empty even after waiting and rebooting. We’ve already tried: Factory reset and re-enrollment Checking Google Play Services version Ensuring the device is connected to the internet Waiting for Play Store sync Despite that, the GSF ID is still missing. Could anyone confirm if there’s a known change in Android 15 related to GSF ID generation, or if additional permissions/configuration are required for enterprise-enrolled devices to obtain it? Any guidance or workaround would be greatly appreciated.
Android 15 Setup Wizard loops at “Accept Google Services” on Lenovo Tab M11 (TB311FU)
Hi all, I'm running into a blocking issue provisioning brand-new (and factory-reset) Lenovo Tab M11 - TB311FU devices on Android 15 with Android Management API (fully managed / dedicated, kiosk). On Android 14 everything worked fine with the exact same policy and enrollment flow. The issue only started after updating to Android 15. (this is my test device, i constantly factory reset it) Expected behavior: Standard QR (6-tap) provisioning to proceed past the “Accept Google Services” screen, install Android Device Policy, enroll to my enterprise, and apply the kiosk policy, install app, and done. What happens instead: After Wi-Fi and scanning the AMAPI QR token, Setup Wizard reaches “Accept Google Services”. Tapping Accept shows a spinner, then it returns to the same screen (loop). I simply cannot get past this point. If I reboot at this point, on the very first Welcome screen the device sometimes becomes unresponsive (neither 6-tap nor “Next” reacts) until I factory reset again. Is there a known Android 15 Setup Wizard issue that can cause a loop at “Accept Google Services” on Lenovo TB311FU? Any workarounds you'd recommend to get past the acceptance loop? When factory resetting, and setting up the tablet without scanning the qr code, i get past the Google Services no problem. When i install via qr-code on new fresh never used before tablets, that come pre-installed with Android 14, i don't have any issues. Same policy, same everything... except the Android version. Thanks in advance! /BIssues Intune and okta enrollment
Hi all, I could use some help or guidance from someone who has experience with using Okta as IDP and Intune as MDM. The problem: When going trough enrollment (COPE), the Intune login page shows up. When entering the email, it forwards to Okta as it should. But after verifying with Okta, you should get back to a Microsoft confirmation but instead it shows a page not found error. It used to work, nothing has changed as far as we know and the issue is present on devices ranging from Android 13 to 15, different brands but mostly Samsung. Apple and Windows enrollment work as expected, no issues there. I can't find any related logging details in Intune and lack the knowledge of Okta (will add a support ticket there as well). So i'm kind of lost as to what is happening. Where do I need to look for the return URL for example? There are multiple Azure enterprise apps but i'm not sure which one to check and don't want to mess to much with this. Thanks!
Tenant has been unbound from Google Play console (Intune)
Hey @Community, we have a strange issue with out MDM (Intune) - It seems like, the link between Intune and Google has broken. Trying to enroll new devices are failing with "Invalid code". Trying to add new applications via "Managed Google Play" fails also with the message "Tenant has been unbound from Google Play console". Intune-Support says, that we need to contact Google, but there is no option for creating a case. So we decided to write you here (and hopefully you can help us ;) ). We still have the access to the used Google-Account.Zero Touch Enrollment Network Specifications
Hello! I'm looking for information regarding the network specifications for the Zero Touch Enrollment as well as any phone-home network requests. Are there any logs we can pull from ZTE or the Android device during enrollment? The reason I'm asking: We have thousands of devices that have been enrolled in SOTI MobiControl over the last few years, and about 1000 of these were enrolled via ZTE. We've had no issues with this until early March. I can't find a rhyme or reason for this, but certain devices that were successfully enrolled, configured by an MDM, QC'd, boxed up, shipped to the end user, and then powered on will get the message below before the eSIM is activated. These are Honeywell CT47 devices with dual SIM cards (1 physical Nano SIM and 1 eSIM). The device above was added to ZTE using the IMEI number over a month ago and was successfully enrolled, but when powered on later and connected to Wi-Fi, it reset itself before the eSIM could be activated. This issue is only happening to devices that are factory reset while on-site and connected to the Wi-Fi only. My best guess is that the Wi-Fi network is blocking something during the enrollment process, as this reset issue is not happening on devices that have been enrolled and working for months. Thanks for your time!
