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!
[Bug Report & Solution] Root Cause of Grayed-Out ADB Debugging on Debian 13 (Trixie): Broken Google Repository
Hello Chrome OS Engineering Team, After extensive troubleshooting regarding the "Enable ADB debugging" toggle remaining grayed out on managed devices, I have isolated the root cause. It is not an Admin Policy issue, nor a user error. The issue is a missing dependency in the Google Package Repository for Debian 13 (Trixie), which prevents the installation of cros-guest-tools. Without cros-guest-tools, the Chrome OS Host cannot verify the container's integrity or establish the necessary bridges, leading the OS to lock developer features (ADB) as a security fallback. Here is the technical breakdown and the required fix. 1. The Environment Host: Chrome OS (Version 131+) Guest: Debian 13 (Trixie) - Current Stable. Repository Config: /etc/apt/sources.list.d/cros.list deb https://storage.googleapis.com/cros-packages/142 trixie main 2. The Error When attempting to install or update the integration tools via sudo apt install cros-guest-tools, the package manager fails with a hard dependency error: The following packages have unmet dependencies: cros-guest-tools : Depends: cros-im which is a virtual package and is not provided by any available package Running sudo apt search cros-im confirms that this package does not exist in the trixie RELEASE of the repository. 3. The Diagnosis The cros-guest-tools meta-package depends on cros-im (Input Method integration). In Bookworm (Debian 12), this dependency is satisfied (likely by cros-im-default or similar). In Trixie (Debian 13), the cros-im package has not been published or linked in the repository index. 4. The Solution (Action Required from Google) The repository maintainers need to push the missing input method packages to the Trixie DIRECTORY immediately. Required Action: Please ensure cros-im-default (or the architecture-specific equivalent) is added to: https://storage.googleapis.com/cros-packages/142/dists/trixie/main/ Once this dependency is resolvable: cros-guest-tools will install correctly. The Host<->Guest handshake will complete. The "Enable ADB Debugging" toggle will unlock in the Chrome OS Settings. Please escalate this to the Cros Packaging team. Best regards, Christophe RouxThe "Enable ADB Debugging" Maze: A Call for Architectural Clarity, Unified Nomenclature, and UI Improvements
Hello Chrome OS Enterprise Community and Google Product Team, I am an administrator and developer using a managed Chromebook for Android development. For over a month, I have been unable to toggle "Enable ADB debugging" in the Linux (Crostini) settings because it remains grayed out, despite my having full admin access. After weeks of back-and-forth with Google Workspace Support, it has become clear that this is not just a bug, but a profound architectural issue regarding how managed Chrome OS handles policy dependencies and how we navigate the Admin Console. Technical Environment & Stability Context It is important to note that my development environment is not a fresh install, but a long-running, stable workspace. I have been using the same Crostini container for over a year, and recently performed a successful dist-upgrade from Debian 12 (Bookworm) to Debian 13 (Trixie), which is the current Stable release. The fact that Crostini handled this major OS upgrade without requiring a reinstall demonstrates the high quality and robustness of the Chrome OS platform. However, this longevity raises a diagnostic question: Is the ADB toggle logic failing specifically on containers that have migrated through major versions? The Current Situation: A Maze of Hidden Dependencies Support has provided numerous potential fixes, suggesting that the "ADB" feature is not controlled by one switch, but is the result of a complex calculation involving multiple policies scattered across different menus. I have re-checked all the following solutions proposed by Support between Nov 7 and Dec 11, 2025. None have solved the issue: Date Policy Name Exact Admin Console Path Action Taken Nov 7 Developer tools Devices > Chrome > Settings > Users & browsers > Content > Developer tools Set to "Always allow use of built-in developer tools." Nov 21 Linux virtual machines Devices > Chrome > Settings > Users & browsers > Virtual Machines > Linux virtual machines Set to "Allow usage for virtual machines needed to support Linux apps for users." Nov 24 Untrusted sources Devices > Chrome > Settings > Users & browsers > Android applications > Android apps from untrusted sources Set to "Allow" (Required for sideloading). Dec 3 Developer Tools (Refined) Devices > Chrome > Settings > Users & browsers > Content > Developer tools Set to "Allow use of built-in developer tools, except force-installed extensions..." Dec 10 ADB Sideloading Devices > Chrome > Settings > Device settings > Virtual Machines > ADB sideloading Set to "Allow affiliated users of this device to use ADB sideloading." Dec 11 Unaffiliated VMs Devices > Chrome > Settings > Device settings > Virtual Machines > Linux virtual machines for unaffiliated users Set to "Allow usage for virtual machines needed to support Linux apps for unaffiliated users." The Architectural Problem Administrators are currently guessing which combination of "User Settings" and "Device Settings" will result in the feature unlocking. There is no visibility into which specific policy is overriding the others. Furthermore, the UI itself makes locating these settings inefficient. Proposal 1: A "Computed Policy View" We need a diagnostic view in the console. When an Admin looks at a locked setting (like ADB Debugging), the console should display: Status: LOCKED Blocked By: Device Policy > ADB Sideloading OR User Affiliation Check Failed. Proposal 2: A Standardized Nomenclature for Admin Options The Google Admin Console contains thousands of options. Support tickets often fail because describing the path to an option is tedious and prone to error. I propose implementing a Unique Identifier System: Menus/Tabs: assigned a 3-letter nickname. Sections/Options: assigned a numerical ID. Example: Instead of describing a long path, we could simply reference ID: DEV-CHR-DEV-VMS-042 DEV: Menu (Devices) CHR: Product (Chrome) DEV: Tab (Device Settings) VMS: Section (Virtual Machines) 042: Option (ADB Sideloading) Entering this ID into the search bar should take the admin directly to the specific toggle. Proposal 3: Collapsible Sections (Fold/Unfold UI) Currently, settings pages (like Users & browsers) are massive vertical lists. To reach a section near the bottom, an admin must scroll past hundreds of irrelevant options in previous sections. Even when using the "search on page" function, the visual clutter is overwhelming. I propose adding a Fold/Unfold feature: A "Collapse All / Expand All" button at the top of the settings page. Clickable section headers that allow us to hide large blocks of settings we are not currently editing. Conclusion We cannot manage what we cannot find or understand. The current "trial and error" approach to enabling standard developer features is hindering adoption in the enterprise sector. We need better mapping, a precise language (nomenclature), and a more efficient UI to navigate this complex environment. Best regards, Christophe Roux
URL blocking and use of wildcards
Morning all, I'm a bit stuck with a policy configuration issue - I have a managed device/user where access to websites is strictly controlled and so i have blocked access to URL's unless whitelisted, but its painful keep adding variations of these websites....I have played with the wild card option to allow full access to a URL but cannot get it to work for me. Has anyone successfully used this policy before in the way I have described? Any pointers/tips would be gratefully received.Enable ADB debugging is grayed out - This setting is managed by your administrator
This issue was documented in 2021 but with no solution. My Chromebook is managed by my company and I am the manager. But Google tries to find the managed option to unlock for this to work in the administration interface for more than 15 days without success. By the way there are thousands of options in the admin interface it could be a clever feature to number them. If you are in front of the same issue please add your comments to this post. I hope that Google support will succeed to solve the issue soon because I developed my first app for Android on my Chromebook with Android Studio and I was able to download it to my phone before these 15 days.
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.New user guides: ChromeOS policies
Hey everyone, Just wanted to let you know we've published two new articles in the User Guide section of the community, designed to help you master ChromeOS policies! These new guides dive deep into the specific steps for applying policies across your fleet: Setting ChromeOS device policies: Learn how to configure policies that apply to your managed ChromeOS devices, regardless of who is signed in. Setting ChromeOS user and browser policies: Get the details on configuring policies that apply to specific users when they sign in, as well as policies for the Chrome browser across different operating systems. All comments and feedback are welcome! Please let us know if these guides help streamline your policy setup. What other ChromeOS topics would you like to see covered in our next user guides?Chrome OS Flex AUE in Google Admin
Hey. The admin console has a fantastic feature where you can see the AUE of your devices pr year. It makes it easier to plan budget for replacing devices going out of support and planning execution. https://admin.google.com/ac/chrome/devices/?sf=2&so=2&tab=dashboard However - you can only see Chrome OS devices since the "Automatic updates until" field in Google Admin is not populated as in the example below. Obviously this information is available somewhere to be displayed, but it is currently not. I would really like to avoid exporting inventory to a spreadsheet, use the certified model list (https://support.google.com/chromeosflex/answer/11513094?hl=en) to populate the empty field in the spreadsheet and keep track of it there. How do others plan inventory replacements? Has anyone else tried to reach out to the Chrome OS team pointing out this flaw?New user guide: Organisational unit structure
Hey ChromeOS Customer Community, Hope you're all having a great week. Just a heads-up that a new article has been published in the User Guide section of the community! It's all about ChromeOS Organizational Unit Structures. The article provides a detailed guide on how to effectively use OUs to manage users and devices, covering key concepts like policy inheritance. It also offers best practices for creating a simple, logical OU structure, such as organizing by department or location. The guide even includes tips on when to separate user and device OUs and how to use Google Groups for more flexible policy application. You can check out the full article here: Organizational Unit Structures All comments and feedback are welcome. What other topics would you like to see covered?
