With our minds off the summer projects and hopefully user provisioning humming away without issue, School IT administrators attention turns to the next big annual milestone – testing. To assess where students start off at the beginning of the year and to get a baseline for growth throughout the school year. Although all schools have a state mandated test and platform, each of them have their setup instructions for the various platforms. For ChromeOS, most could be fit on a 2 page document, and it’s only 2 pages if you include large images to walk users through each step.
Yes, testing on a Chromebook is famously easy to set up, which is another reason that School IT administrators love them, but with ease of administration comes some pitfalls that one could easily fall into.
Pushing out kiosk apps
When you configure your testing app, whether it’s DRC insight, Pearson’s TestNav, NWEA’s map testing app, or even your own custom testing app, the IT administrator will push this application out as a kiosk app. This is a device setting, which means that it applies to the devices organizational unit, and is present regardless of who is sitting in front of the Chromebook. It’s easy to configure this setting at the root organizational unit, or for all devices. This will make it where the app is just sitting in wait at the login screen under the apps menu at the login screen.
While simple to set up, this brings us to the first issue. The intended behavior of these apps is to check and see whether there is an update to the application on boot, before populating the app menu, however that does not always happen. Many times the current app version and the installed app version have a discrepancy, especially if the app developer has been keeping up with security standards for their application. As a result, when the test taker launches the app from the menu, they get an error saying they need to update the test app version to the current version.
To update the version, the steps that need to take place are to remove the app from the Chromebooks that have an older version, and then re-add it. Once re-added, it will pull down the current version from the web store.
So as a best practice, administrators would only have the testing kiosk apps installed on OrgUnits containing devices that are actively testing. Not only will this keep the testing apps up to date, but it solves issue number two, config files.
You may find this in-depth article on using GAM to manage your Admin console useful
Updating config files
Some testing applications, like DRC Insight (App ID dfjigmapgofdlgieniibjdcddlaafick for anyone needing to search for it), require a configuration file to be uploaded to the application on the OrgUnit where it is configured. These configuration files typically point to local or cloud resources specific to your school and are used to identify the testing platform as coming from a valid testing location or present the application with the list of expected testers. When you have multiple configuration files for multipleOrgUnits, an interesting bug can arise if you move devices between these OrgUnits.
Chromebooks will cache these config files and will only update them after the application has been removed and re-added to the Chromebook. So, if you move a device from your middle school to your high school and have the same testing app with different configurations, even though it’s in the new OrgUnit, it will retain the old config file. There is a crbug issue for this found here, but it hasn’t received much attention as late. Please take a moment and star this issue if you’re using anything that requires a config file.
Auto-launching testing apps
The next common practice which leads to a false sense of security is relying on the auto-launch functionality for kiosk apps. It’s a trivial thing to make a Chromebook auto-launch an application when it boots up. You locate the setting in the Admin console and change the dropdown value to the test that you’re launching.
When you use this setting, be aware that users can bypass the app being launched by pressing Ctrl + Alt + S. This is also advertised to the user as the device is moving into the kiosk app. With this keystroke, users get to the normal ChromeOS sign-in screen.
The issue with this is that we often forget that allowing users to get to the sign-in, and subsequently an unrestricted browser in a room where testing is ongoing will invalidate the entire rooms test results, regardless of whether the offending individual was using the unrestricted browser to cheat or not.
As a solution, restricting who can sign-into the device should be configured on the OrgUnit containing devices that are testing. Entering either your email address or a fake email address into the configuration will stop any user from signing into the Chromebooks while they are this Testing mode.
Have a dedicated OrgUnit
With these 3 major settings, restrict Sign-in, auto-launch, available testing apps, it makes sense to create an OrgUnit that houses all your devices which are dedicated to testing. This can have several sub-OrgUnits depending on what tests your organization is required to administer to students.
As a preparation to moving devices you will want to take a “snapshot” of your devices current location so you can move them back. Gopher for Chrome can pull down the current location of your existing devices. Then, when testing is over, or when you need to move devices back to their daily usage mode, update Google from the sheet and devices location and policies will revert to what they were prior to testing. Remember that if you only need to update a portion of your devices, you can use the built-in Sheets filters to only update a subset of your devices.
Pinning OS versions
If you should choose to move forward with creating a dedicated testing devices OrgUnit, remember that whenever you move devices outside of that OrgUnit, the restrictions placed on these Orgs are no longer in affect. This is especially meaningful when you take into account the setting to limit ChromeOS Update to version at most. If you are moving your devices in and out of “testing mode”, and you choose to restrict, or pin, the OS version, make sure that the pinned version restriction is also applied to the devices normal OrgUnit. Moving a device that has updated into an OrgUnit that restricts the version does not roll the device back to the “highest version” but will stop any additional updates from rolling out to the device. That said, once your testing window has closed, remember to remove the OS version restriction to ensure that your devices are getting the most features and security settings for the operating system.
The Chromium developers have made testing on Chromebooks relatively painless and saved uncountable hours, though it has not been without introducing new sets of challenges. Our hope is that by bringing to light these challenges, along with proposed solutions, the next testing window will go over smoothly and without incident.
If you would like training for you and your team or hands-on assistance, book some time in with our technical services team by reaching out to support@amplifiedit.com. Learn more about the various ways we can help your team.
-
Stephen Gale
Technical Support Analyst -
About the Author:
Stephen lives in Utah and enjoys the puzzle of investigating users’ problems and finding potential solutions. A recovering/reformed gamer, Stephen throws himself into his passion for staying on top of all things Chrome OS and Chromebook related. Prior to joining Amplified IT, Stephen served as a Network Admin in a Therapeutic Boarding School and an IT director, where he implemented Google Workspace for Education. Stephen has studied computer science and security at Weber State University, Western Governors University. A self-anointed honor, Stephen likes Chromebooks more than almost anyone else in the world.