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 browsersSetting 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 policiesOrganizational 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 policies
