Deploy auto-updates for Chrome devices
This document describes best practices for IT administrators managing auto-updates of Chrome devices.
Note: We recommend that you keep most of your users on the Stable channel, and 5% of your users on the Beta channel. We also recommend you keep your IT team on the Beta or Dev channels.
By default, Chrome devices update to the latest version of Chrome when it’s available. There’s a new release of Chrome approximately every 6 weeks. In addition, there might be security fixes or software updates. We recommend that you keep the default auto-update settings for Chrome devices in the Google Admin console. That way, devices automatically update when the new release hits the Stable Channel.
Peer-to-peer automatic updates
Chrome devices running Chrome version 40 or later can use peer-to-peer (P2P) automatic updating. This helps reduce external network traffic. Enrolled devices automatically update from nearby devices, if they’re the same model. Your organization’s network needs to allow P2P connectivity. In addition, multicast DNS (mDNS) shouldn’t be filtered or blocked on the local area network (LAN). If P2P automatic updating fails or isn’t possible on your network, devices update through normal channels instead.
Scattered updates—Recommended if bandwidth is an issue
The average full Chrome OS software update is 400 MB and minor updates are approximately 50 MB. If your organization is deploying thousands of Chrome devices, or if you have network bandwidth considerations, you may consider scattering updates. We recommend that if you scatter updates to choose the fewest days possible (such as over two or three days), because if you choose to scatter updates over a two-week period, it’s possible that some of your users could fall more than one version behind.
After an update has been applied to a Chrome device, users must restart for the update to take effect. They’ll get a notification prompting them to restart. However, they might not restart the device for some time. If you want devices to restart sooner, you can set a policy to sign users out when the device lid is closed. So, if a user doesn’t restart a device after an update and then closes the lid, user sign-out performs a quick device restart and completes the update. Be sure to let users know so that they don't lose their work when they close the lid.
Organizations should create a test plan and test each new Chrome release on 5% of your organization's devices by keeping them on the Chrome OS Beta Channel. You can do this using the Release Channel setting. Using the Beta Channel gives your IT personnel a 6-8 week window to see if any issues arise with the latest version in your organization before it’s released to the Stable Channel. Additionally, we recommend you keep your IT team on the Beta or Dev channels to test each version of Chrome OS in your organization before it hits the stable channel.
Pinning Devices—Not Recommended
We recommend users be on the latest version of Chrome, but we understand that some organizations may want to pin their users if they have special requirements or find a critical issue while testing devices on the Beta Channel. However, version pinning should be avoided if possible, because if you forget to unpin your users’ devices, they can fall behind on critical security updates and miss out on new features in Chrome. If you need to pin versions, see Restrict Google Chrome version to at most.
Google Cloud supports only the latest version of Chrome OS.
Guidelines for changing default settings
For enterprise users, the Admin console provides multiple controls to manage the updates on their devices. For specific tips on how to configure the settings, see the auto update settings in Manage device settings.