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.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 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.Your guide to smarter ChromeOS administration
The pace of innovation in Chrome Enterprise and ChromeOS continues to accelerate. Earlier this year, we launched a wave of powerful AI-driven features designed to fundamentally change how you manage your fleet and support your end-users. We’ve summarized the key developments below, focusing on the practical, day-to-day applications for your administrative work. Part 1: Empowering IT: AI in the Admin Console Updates focus heavily on simplifying the most time-consuming aspects of device management using Google AI and Gemini. New Feature Practical Day-to-Day Application 1. Chrome Admin Assistance (Gemini Chatbot) Instant, conversational support and task execution. Instead of navigating complex menus, you can simply ask the chatbot in natural language to perform an action. For example, "What is the status of device serial number X?" or "Initiate a remote reboot for device Y." This significantly cuts down on routine, manual administrative tasks. SIgn up as a trusted tester to avail. 2. Natural Language Processing (NLP) Search Find policies and devices instantly without precise keywords. No more guessing policy names or remembering exact search syntax. You can now use plain English for complex queries like: "Show me all devices enrolled last month" or "Find the policy for blocking USB storage." This makes fleet audits and configuration checks much faster. 3. Intelligent Recommendations (Related Settings) Ensure comprehensive and optimized configurations. When you’re viewing the details of one policy (e.g., microphone control settings), the Admin Console now surfaces other logically related policies (like audio output settings). This prevents overlooked settings and ensures a more complete and secure setup. Part 2: Powering end-users (and reducing your tickets) While your focus is on the fleet, these end-user-facing AI enhancements are vital because they impact user productivity and, ultimately, your support load. Gemini integration in Google Workspace: If your organisation does have Workspace, users now have powerful AI assistants in Gmail (summarizing threads, composing faster), Docs, Sheets, and Slides. As an Admin, you can easily pin Gemini to the Chromebook shelf, ensuring simple, centralized access for all employees. AI built into ChromeOS: Users gain productivity tools that work across any application, not just Google's. Features like Help me read and Help me write assist with comprehension and content creation in third-party or web applications. Furthermore, AI-enhanced video call controls and Live Translate directly on the device improve meeting quality and cross-lingual collaboration, leading to less friction and fewer support requests for connectivity/tool issues. Part 3: The Right Hardware To unlock these most advanced AI experiences, organizations should look to Chromebook Plus devices, which meet a higher standard for performance and memory. When planning your next refresh cycle, ensure the hardware can support the full stack of new AI capabilities to maximize user benefit. Ready for the Deep Dive? Be sure to read the full post: The IT Admin's Guide to Google AI.
