10 Tips to Optimize Your Chromebook Fleet Before Testing Season

March 11, 2020

Each year we discover more and more schools are turning to their Chromebook devices to administer state or provincial testing to students. While managed devices can certainly streamline the testing process, they can present a unique set of challenges as well. Below you’ll find 10 tips that can help your school prepare for testing on Chromebooks and avoid some common pitfalls that often plague schools this time of year.

1. Find out if your testing app requires a specific OS version for optimal performance.

First and foremost, all other tips below rely on this first step – understanding any Chrome OS limitations for your testing app. Each year and each app is different, so you’ll want to make sure you check the testing support site to verify which versions of Chrome OS are able to launch the app. For example, this year Pearson TestNav 8 is supported on Chrome OS 74-79, so any devices on OS 80 may need to be reverted before testing time (OS 80 is currently being tested as of early March 2020).

2. Speaking of OS versions, check where your fleet stacks up.

Once you know the optimal range or version for your testing app, check your fleet to see which devices will need to be updated (or reverted). You can do this in the Admin Console, but will be limited by pagination. You can also pull a device list via GAM or Gopher for Chrome.

Gopher for Chrome Inventory Sheet showing OS version and number of versions behind.

3. Manually update devices that are behind.

After you have your “hit list” of devices that are way behind (and/or ones that need to be reverted from a more recent version) you’ll want to ensure you’re planning an appropriate amount of time to physically update these devices (likely via USB). Depending on the size of your school, and the size of your tech team, this can take up some time, so it’s best to plan ahead as much as possible. Or…

4. Bulk disable devices to force users to bring them in for updates.

If you want to “force” your end users to come to you, you could consider bulk disabling (via GAM or Gopher for Chrome) chronically behind devices in order to incentivize your students into bringing the device in for updates. You can configure a custom message to appear on the screen for disabled devices that lets the student know where to bring the device in order to turn it back on. This isn’t totally foolproof, as you’ll still have users who won’t bring the devices in, but it can make a big difference. Either way, you’ll want to keep a keen eye on your device list to make sure you’re making progress on the OS updates.

5. Pin OS version.

In order to prevent devices from updating beyond a certain OS version, like 80, you can pin the maximum OS version in the admin console. This is especially important if your testing app is not supported beyond a certain OS version. One thing to remember – after testing time you’ll likely want to unpin the version, so set yourself a calendar reminder to take this off later.

6. Check Your Update Settings

Most schools have auto-updates enabled for Chrome devices, and it’s generally not necessary to turn them off during testing time, especially if you are pinning an OS version in the admin console. One thing you may want to consider ahead of testing time is to change your update settings to roll out over a specific schedule, rather than the randomly scattered updates over X days. When this feature is selected and expanded (as seen below), it gives you more granular control over your updates, as you can specify both the days after release and the percentage of devices to update by that specified time.

7. Check the Chromebook AUE (Auto Update Expiration).

This one may seem obvious, but it can trip people up. You want to make sure the devices that you are using for testing have not reached AUE as these devices may not be able to update past a specific OS version. After devices reach their AUE date, Google does not guarantee an update package for the device. If you have some post-AUE devices in your fleet, they are still perfectly usable, but it’s recommended to avoid using them for testing. Check out the complete AUE list by device manufacturer to be sure. If you want to review the AUE for all your devices, the Gopher for Chrome auto-refreshing AUE reports offer a great holistic view.

 

8. Ensure device settings are optimal for testing.

There are several ways that schools choose to administer testing, and with each come their own potential pitfalls. We wrote up a blog post on common testing settings faux pas last year that still rings true and walks through the settings for common testing preparation in the admin console.

9. OU organization.

With the above settings in mind, you’ll want to ensure that all devices used for testing are located within OUs that have been configured for testing. Inevitably, you may find that you have rogue devices that will need to be moved in order to inherit the testing settings, and equally important, the testing app. You can use the inventory list from Tip #2 to get a handle on your device OU organization, and depending on which method you used to pull that information, you can also bulk update any stray devices in the same manner.

10. Consider using a designated Testing OU.

Last but certainly not least, we find that a lot of schools may choose to use a designated testing OU this time of year in order to push out the testing app and configure device settings for testing time. This is a great solution if you have a lot of OUs that would need to be granularly configured, or if you want to ensure the original settings are not “lost” after testing is complete. One thing to keep in mind as you move devices from their original OU into a testing OU is that you’ll need to move them back once testing is over. You can use the Notes field to capture the original OU prior to bulk updating the devices, which then tells you exactly where you need to move them back after testing is over.

  • Melanie Long
    Data, Implementation, and Engagement Consultant

  • About the Author:

    Melanie lives in Virginia and is based in Amplified IT’s home office located in Norfolk. One of the first members to join the Amplified IT team, Melanie has worn many hats at the company.  She most enjoys interfacing with customers and helping them implement tools that solve common pain points and frustrations. Today she leads the onboarding and interfacing with Labs tool clients, making lives easier and breezier one implementation at a time.