chrome://policy sync error - what is "fetch attempt", how does it differ from "policy timestamp", and how can we check it on the GAC?
Good morning, We have run into a real head-scratcher with a partner in the industry who deployed a massive amount of brand new Chromebooks to one of their customers. A significant amount of the Chromebooks that were enrolled - for some reason - encountered some kind of error with policy sync; and the result is thousands of Chromebooks that cannot connect to the end customer's wifi network (failure rate about 40%) The customer uses "DeviceOpenNetworkConfiguration" to push profile info for a WPA-PSK wifi network. Most of the chromebooks got this policy. Other chromebooks did not get this policy. And yet other chromebooks got this policy, but the policy value was missing the critical JSON block which adds the wifi profile to the device. All Chromebooks were enterprise-enrolled using an enrollment account, and all Chromebooks were allowed extra bench time to make sure that they synced & populated fields like "osVersion" and "macAddress" to the GAC. We have observed that both "good" and "bad" units appear identical within the GAC. "lastPolicySync", "enrollmentTime", "provisionStatus", "osVersion", and "macAddress" were all accounted for and valid. Here's where our confusion starts. On affected devices, we used "Browse as Guest" to open up Chrome & navigate to chrome://policy to check policies (this is how we learned that the DeviceOpenNetworkConfiguration policy was either absent or partially provided). Looking at the "Status" fields, something caught our eye: Last fetch attempted: Never Last policy timestamp: 29 days ago (corresponds with "lastPolicySync" in GAC) Error: Managed user or device has no policy loaded. The "fetch attempted" is a new field to our eyes. We could not find a counterpart in the GAC CSV export. The error is also highly concerning. We (and the industry partner in question) use the "enrollmentTime" and "lastPolicySync" fields to validate that a customer's devices have properly enrolled. But this project would prove that it's not that simple. We have the following questions: What is the "fetch attempt"? What sets it apart from the "policy sync timestamp"? / What is the difference between "fetch attempt" and "policy sync"? What is the meaning of the error? Can somebody shed some light on more of the technical details surrounding the implementation of ChromeOS policy syncing? We are hoping to understand it on a deeper level to prevent this situation from emerging in the future. In short, how can we be absolutely sure that a Chromebook has synced with Google and pulled all of the policies that it should? Thank you for your insight
How to change the keyboard layout in managed chromebooks?
We currently have around 100 Chromebooks that we use for exams. I have now been asked to make it possible for participants to change the keyboard layout. Most use the German keyboard, but a few want to write with an English or French layout. What do I need to set in the management console so that participants can change the layout on their devices?
Standardised fleet or multi-vendor strategy: where do you land in 2026?
Hey everyone, In a recent discussion, we talked about how teams are using automatic enrollment to deploy and scale ChromeOS fleets more easily — whether that’s zero-touch for new devices or Flex for existing hardware. That got me thinking about another decision many admins are navigating right now: how they’re thinking about fleet strategy as they plan for 2026. Some organisations prefer a highly standardised fleet, sticking to one vendor or model to keep things predictable — from user experience and support, to lifecycle planning. Others lean towards a multi-vendor approach, mixing devices (and sometimes ChromeOS Flex) to stay flexible on procurement, optimise costs, or extend the life of existing hardware. Both approaches can work well on ChromeOS, but the trade-offs are something to take into consideration. I’d be interested to hear from the community: Do you lean more towards a standardised fleet, a multi-vendor strategy, or a mix of both? What factors tend to drive that decision in your environment (scale, cost, supply chain, sustainability, support)? Has your approach changed over time as ChromeOS and Flex have evolved? As always, there’s no one-size-fits-all answer — it’d just be great to learn how others are thinking about this for the year ahead.Update: Device Enrollment Limits - OU Level
Hi everyone, Back in November, we introduced the Device Enrollment Limits TT, designed to help admins better manage ChromeOS license consumption by setting enrollment caps at the Organizational Unit (OU) level. Since then, the feature has continued to evolve, so I wanted to share a quick update with what’s changed. A quick recap LimitOU (Device Enrollment Limits) allows IT Admins to set specific device enrollment caps at the Organizational Unit (OU) level. This prevents a single OU from exhausting the organization's total license pool. What’s new? Delegated admin support - Originally a Superadmin-only tool during the Q3 2025 Trusted Tester (TT) phase, the feature now supports delegated permissions. The Help Center for the TT has been updated accordingly. Granular control - Admins can now manage enrollment limits without requiring full system-wide administrative privileges. Allowlist Requirement: Due to the complexity of the Admin Console integration, the feature requires manual enablement for specific customer domains so members can just respond to the post and request to be added to this trusted tester if they wish. How to Apply Once more, if you are an administrator and would like to be included in this Trusted Tester program to try out Device Enrollment Limits and provide valuable feedback, please simply post a comment below to express your interest!
Join the ChromeOS Device Enrollment Limits TT
We are excited to announce an opportunity to join a new Trusted Tester program for a feature coming to ChromeOS that will help administrators manage device licensing more effectively: Device Enrollment Limits. What is the Feature? Currently, there is no easy way to prevent one team or organizational unit (OU) from consuming too many device licenses, which can leave other parts of your organization short. The ChromeOS TT for Device Enrollment Limits is designed to give you, as an administrator, more control over license consumption within your OUs. This pre-General Availability (GA) pilot will allow you to: Set specific enrollment limits per OU. Ensure fair access to licenses across your organization. Optimize resource allocation and prevent overconsumption. Once you request to be part of the TT (more details below) and we set you up for it, you'll find and manage this feature in the Google Admin Console under Devices > Chrome > Reports. For more information, head on over to our Product Hub for a Q&A blog post on this Trusted Tester. How to Apply If you are an administrator and would like to be included in this Trusted Tester program to try out Device Enrollment Limits and provide valuable feedback, please simply post a comment below to express your interest! We will reach out to you directly with the next steps.Limitless Control: Join the ChromeOS Device Enrollment Limits TT
We are excited to announce an opportunity to join a new Trusted Tester program for a feature coming to ChromeOS that will help administrators manage device licensing more effectively: Device Enrollment Limits. Further to our discussion post on this recently launched trusted tester, we also wanted to share some more information on this feature and how it works. What is the "Device Enrollment Limits" feature and what problem does it solve? It's a new functionality in the Google Admin Console that allows administrators to set specific enrollment limits for each Organizational Unit (OU). It's designed to give administrators greater control over ChromeOS license consumption across their organization, ensuring fair access, optimizing license allocation, and preventing overconsumption. Where can administrators find and manage the "Device Enrollment Limits" feature in the Google Admin Console? You'll find it by navigating to Devices > Chrome > Reports. The feature is nested under Device enrollment limits on that page. How do administrators set an enrollment limit for a specific Organizational Unit (OU)? The basic steps are: Navigate to Devices > Chrome > Reports > Device enrollment limits. Click the specific OU you want to configure. In the dialog, turn on the toggle for the desired license type (Chrome Enterprise/Education Upgrade or Kiosk & Signage Upgrade). Enter a numerical value for the available enrollment slots in the "Device enrollments remaining" field. Click "Save". (Setting the limit to 0 prevents that OU from enrolling devices.) What types of licenses can be managed with this feature, and are there any exceptions? You can set limits for perpetual and annual Chrome Enterprise/Education Upgrade (CEU) and Kiosk & Signage Upgrade (KSU) licenses. Yes, bundled or packaged licenses cannot be adjusted using this feature. When an OU has both perpetual and termed licenses, perpetual licenses will be utilized first before tapping into termed ones. How can I quickly see which OUs have reached their limit? On the "Device enrollment limits" page, use the "Add a filter" button and select "Device enrollment limits reached". You can also choose filters to show only OUs with "0 remaining device enrollments for CEU" or "0 remaining device enrollments for KSU". What happens when an OU reaches its set limit? New devices will be unable to enroll in that specific OU. The Admin Console will show "0" remaining slots, and users attempting enrollment on the Chromebook will encounter an error. This prevents overconsumption Will the "Device Enrollment Limits" be manageable through the Chrome Policy API? No, management and configuration of these limits will be exclusively through the Google Admin Console user interface. What are the minimum requirements to participate in this pre-General Availability (GA) pilot program? To be a trusted tester, your organization must: Have a managed domain Have devices and licenses that are managed by the Google Admin Console. Ideal candidates are those who are also expected to provide good and consistent feedback within a short timeframe. How to Apply If you are an administrator and would like to be included in this Trusted Tester program to try out Device Enrollment Limits and provide valuable feedback, please simply post a comment below to express your interest! We will reach out to you directly with the next steps.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.
