Description: 
We have an enterprise customer requesting the ability to keep the ChromeOS update images available for at least one year after its latest release to allow devices that cannot be updated to the latest stable to still update, especially new devices. Whenever a new device is unboxed, it usually contains a much older software version. For instance, AOpen Chromebase devices ship with ChromeOS 57. In the event that an organization cannot update to a newer stable release due to a bug, the expectation is that these devices should still update to the latest approved model while Google works on fixing the bug in an upcoming version.

Use case: 
Our customer experienced a USB HID bug introduced in Chrome m64, which prevented them from using touchscreens on their business-critical kiosk devices. Despite their collaboration with the Chrome team, this bug isn’t going to be fixed until Chrome m69 hits stable. In the meantime, they are pinned to Chrome m63 and cannot update any further without rendering their kiosks useless.

Google seems to remove the update files from the web after they are no longer pinnable. As a result, whenever new devices were being prepared for rollout, they could not update to any version past what was already on the device (Chrome m57).

Motivation:
While the customers work with Google on fixing bugs affecting the operating systems, they are not in control as to when these updates will hit production. This is more concerning given the fact that Google ships major releases every 6 weeks. If the bug is fixed past the cutoff, the customer will have to wait another 6 weeks until the next update.

To still allow enterprise customers to leverage and deploy the solution while a solution is met, Google needs to update its policies to allow all previous ChromeOS versions released in the past 365 days to be made available for updates and pinning in the cPanel.

Existing workarounds:
The only workaround that was acceptable for the customer was for the Chrome team to re-enable a very specific Chrome version for very specific devices on the backend. This isn’t scaleable and relies on manual processes, which may be overwritten at any time.

Another workaround that isn’t scalable for our customer, due to the very distributed environment with business-critical devices running in thousands of locations that do not have any on location IT support. That would be to receive a USB image from Google for the affected devices and load them onto USB stick to ship them to all locations that received devices with the factory ChromeOS version. This isn’t acceptable because they cannot ship USB sticks to restore the devices (not scaleable, the devices are impossible to manage,