Getting started with Chrome Enterprise Upgrade
Join our new webinar series, "Getting Started with Chrome Enterprise Upgrade" designed specifically for new customers and those on a free trial. This series is your essential guide to unlocking the full potential of Chrome Enterprise Upgrade within your organization. Our experts will walk you through everything you need to know, from initial setup and configuration to best practices for device management, security features, and app deployment. You’ll learn how to streamline IT operations, enhance security, and provide your team with a modern and efficient computing experience. Whether you're just beginning your trial or have recently become a customer, these sessions will provide the insights you need to get up and running quickly and confidently. You'll also have the opportunity to ask questions and get direct answers from our team.Getting started with Chrome Enterprise Upgrade
Join our new webinar series, "Getting Started with Chrome Enterprise Upgrade" designed specifically for new customers and those on a free trial. This series is your essential guide to unlocking the full potential of Chrome Enterprise Upgrade within your organization. Our experts will walk you through everything you need to know, from initial setup and configuration to best practices for device management, security features, and app deployment. You’ll learn how to streamline IT operations, enhance security, and provide your team with a modern and efficient computing experience. Whether you're just beginning your trial or have recently become a customer, these sessions will provide the insights you need to get up and running quickly and confidently. You'll also have the opportunity to ask questions and get direct answers from our team.Setting ChromeOS device policies
To manage your fleet of ChromeOS devices, you must be a Google Admin Console administrator. You can set policies for all devices in your organization or apply them to specific groups of devices using organizational units. Step 1: Access the Google Admin Console Sign in to the Google Admin console with your administrator account. Step 2: Navigate to Device Settings From the Admin console Home page, go to Menu > Devices > Chrome > Settings > Device settings. Step 3: Select an Organizational Unit On the left, select the organizational unit you want to apply the settings to. If you want to apply the settings to all devices, select the top-level organizational unit. Step 4: Configure the Policy Scroll to the setting you want to configure. Click on it, make your desired changes, and then click Save. Changes typically take effect within a few minutes, but it can sometimes take up to 24 hours. Top 10 practical ChromeOS device policies for enterprise While there isn't an official list of the "top 10 most used" devices policies, here are ten highly recommended and commonly used policies for enterprises, with a focus on security, productivity, and management. Forced Re-enrollment: This policy ensures that if a device is wiped, it automatically re-enrolls in your organization's account without a user's manual input. This is critical for device security and inventory management. Allow Guest Mode: Disabling guest mode prevents users from browsing the web without signing in, which can help ensure all user activity is tied to a specific account and is auditable. Sign-In Restriction: This policy allows you to restrict device sign-ins to only users within your organization's domain. For example, by allowlisting *@yourcompany.com, you prevent non-employees from using company devices. Device State Reporting: Enabling this policy allows administrators to collect and monitor real-time data on devices, such as serial number, model, and last time synced. This is crucial for fleet management and troubleshooting. Disabled Device Return Instructions: For lost or stolen devices, you can set a custom message that appears on the disabled device's screen. This message can include contact information, increasing the chances of the device being returned. Screen Lock: Automatically locking the screen on idle after a short period ensures that unattended devices are not left vulnerable. Safe Browsing: Enforcing Safe Browsing helps protect users from malicious sites by displaying a warning before they can access a potentially dangerous URL. Disallow External Storage Devices: This policy can prevent the use of USB drives and other external storage, which helps mitigate the risk of data exfiltration or malware introduction. Application Allowlisting: By setting the "Allowed Apps and Extensions" policy to "Block all apps and extensions except the ones I allow," you can maintain a high level of security and control over what applications users can run. This is a common and effective security measure. Automatic Updates: This policy ensures that the device's operating system and browser automatically receive and apply security patches and feature updates, keeping the devices secure and up to date without manual intervention. For more detailed explanations of the device policies available, check out this article in our help center: Set ChromeOS device policies
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.Setting ChromeOS user or browser policies
To manage your fleet of ChromeOS devices, you must be a Google administrator. You can set user policies to control the user experience when the user signs in with their managed Google account on any device. Step 1: Access the Google Admin Console Sign in to the Google Admin console with your administrator account. Step 2: Navigate to User Settings From the Admin console Home page, go to Menu > Devices > Chrome > Settings > User & browser settings Step 3: Select an Organizational Unit On the left, select the organizational unit you want to apply the settings to. If you want to apply the settings to all devices, select the top-level organizational unit. Step 4: Configure the Policy Scroll to the setting you want to configure. Click on it, make your desired changes, and then click Save. The policies will take effect the next time a user signs in with their managed account on a ChromeOS device. Top 10 practical user policies for enterprise While there isn't an official list of the "top 10 most used" user policies, the following 10 are highly valuable for enterprise customers to manage security, user experience, and device performance. Maximum user session length: This policy is critical for security. You can set an automatic sign-out time (e.g., 60 minutes) to ensure that unattended devices are not left signed in, reducing the risk of unauthorized access. Browser sign-in settings: To prevent data leaks and maintain control over user accounts, you can enforce that users can only sign in to Chrome browser with their managed work account. This prevents them from using personal accounts on company devices. High efficiency mode: This policy improves device performance by automatically discarding inactive background tabs after a few hours. For a large enterprise, this can significantly reduce the memory footprint and CPU usage across the fleet, leading to better device responsiveness. Exceptions to tab discarding: You can set a list of mission-critical web pages (e.g., a CRM dashboard or an internal ticketing system) that will never be automatically discarded. This ensures that essential applications remain active in the background. Wake locks: This policy gives you control over whether applications and websites can prevent a device from sleeping or the screen from turning off. This is particularly useful for devices used as kiosks or for digital signage, ensuring the content is always visible. Idle settings: This policy allows you to define what a device does when it's left idle or a user closes the lid. You can configure devices to automatically lock, sign out, or even shut down, which is essential for both power management and security. Spoken feedback (ChromeVox): Enabling this accessibility feature is crucial for creating an inclusive workplace. It provides spoken feedback for visually impaired users, allowing them to navigate the device and use applications effectively. High contrast: For users with low vision, this policy can be configured to change the font and background color scheme to make web pages easier to read. This is a practical and important accessibility feature for a diverse workforce. Custom wallpaper: This policy allows you to set a company-branded wallpaper on all managed devices. This is useful for building a consistent corporate identity and can be used to display important information like IT support contact details. Custom terms of service: Before a user can sign in for the first time, you can present them with a custom terms of service document. This is useful for ensuring all employees acknowledge and agree to company policies, such as an acceptable use policy. For more detailed explanations of the device policies available, check out this article in our help center: Set Chrome policies for users or browsers
[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 RouxChromeOS 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.Organizational unit structure
An Organizational Unit (OU) is a container within your Google Admin console that allows you to group users, devices, and other assets. The primary purpose of an OU is to apply policies and settings to specific subsets of your organization. Policy Inheritance: OUs operate on a hierarchy. Policies you set at a parent OU are inherited by all child OUs below it. This is a fundamental concept for simplifying management. For example, you can set a default homepage for all devices at the top-level OU, and it will apply everywhere unless you override it in a specific child OU. Users vs. Devices: A key best practice is to understand that users and devices can be in different OUs. A user's policies follow them regardless of the device they sign into, while a device's policies remain with the device, no matter who signs in. Best Practices for Structuring OUs The goal is to create a structure that is as simple as possible but as complex as necessary. Avoid creating OUs for every small group or purpose, as this can lead to an administrative nightmare. 1. Start with a Simple, Hierarchical Design Your OU structure should be logical and easy to navigate. Common approaches include: By Location: For organizations with multiple offices (e.g., North America > California > Los Angeles). By Department or Role: Useful for corporate environments (e.g., Finance, Marketing, Engineering). By Job Level: Role within the organisation (e.g. Executives > Managers > Individual Contributors (ICs) ). 2. Separate Users and Devices Only When Necessary While you can put users and devices in the same OU, it's often more effective to separate them to apply different policies. User OUs: Structure user OUs based on the policies you need to apply to people. This is for things like app access, content filtering, and user-specific settings. For example, an "ICs" OU might have restricted app access, while a "Exec" OU has full access. Device OUs: Structure device OUs based on the policies you need to apply to the physical hardware. This is for settings like network configuration, sign-in restrictions, and public session behavior. For example, you might have a "Laptops" OU for devices that travel and a "Kiosk" OU for public-facing devices. 3. Leverage Policy Inheritance to Simplify Management Set the most common, organization-wide policies at the top-level OU. Then, only create child OUs to apply exceptions to these inherited policies. Example: If 90% of your devices use the same Wi-Fi settings, configure those settings at the top-level device OU. For a specific set of lab devices that need a different Wi-Fi network, create a "Lab Devices" child OU and override the Wi-Fi policy there. This saves you from re-configuring the same settings repeatedly. 4. Use Groups for Cross-OU Policies While OUs are great for hierarchical policy application, Google Groups provide flexibility for applying policies to a specific set of users who are not in the same OU. When to use Groups: Use groups for temporary projects, special access to applications, or when a few individuals across different OUs need the same policy applied. For example, you could create a "Pilot Program" group and assign an experimental app to its members without moving them from their primary OUs. Key Takeaways Plan first: Before creating any OUs, map out your organizational needs and how they translate to policies. Simplicity is key: Use as few OUs as you can while still meeting your policy requirements. OUs for hierarchy, Groups for flexibility: Remember that OUs manage hierarchy and inheritance, while groups provide a way to apply policies to a dynamic set of users or devices. For more detailed explanations of how OUs and Groups work within the Admin Console, check out these articles in our help center: How the organizational structure works Managing group-based policiesThe "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
