Chromebook management is two jobs. Google Admin enrolls each device, places it in an organizational unit, applies policies, and deprovisions it at the end. Your inventory and helpdesk track the rest: who holds it, where it belongs, what broke, which loaner covers it, and when it retires.
We build a helpdesk and PSA (professional services automation) a small IT team can run alone. This guide covers the side of Chromebook management that lives in tickets and records.
What Is Chromebook Management?
Chromebook management is the work of keeping a school's ChromeOS devices configured, accounted for, and working, from purchase to retirement. It splits between two systems.
Google Admin
Configures the device and decides what it can do.
- Enrolls the device so your device policies apply
- Places it in an organizational unit (OU) whose device settings it runs
- Force-installs apps and extensions
- Disables lost devices and deprovisions retired ones
Inventory and helpdesk
Records who has the device and what happened to it.
- Assigns it to a student, a cart slot, or a school
- Logs repairs and damage on tickets
- Tracks loaners until they come back
- Runs audits, year-end collection, and retirement
Google Admin does hold some inventory data, with gaps a school has to fill.
| Field | What Google stores | What it doesn't tell you |
|---|---|---|
| Serial number | The serial entered when the device was enabled | Who has the device today |
| Asset ID | An ID an admin enters by hand | Whether it matches the label on the device |
| User | The username that first enrolled it, editable later | The student it's assigned to, unless someone types it |
| Location | One address or location, editable | Where it was last term |
| Recent users | The last users, up to 100, if tracking is on | Whether a sign-in was the owner or a borrower |
| Automatic updates until | When updates stop for that model | Nothing missing: copy it to the record for refresh planning |
| Status | Active, disabled, deprovisioned, and a few others | In repair, on loan, missing, or retired |
These fields describe the device as it stands today. Which student had it in March, and what its screen repair cost, are questions for the inventory. Our guide to school asset management software compares the tools that keep it.
Why Chromebook Management Needs A Record
A school Chromebook changes hands at fixed points: handout, repair, loaner, collection, and reissue. Each handoff is a moment the record can drift from the device.
Scale makes drift expensive. In CoSN's 2026 survey, 90% of districts run 1:1 in middle school and 88% in high school. And 38% expect reduced device funding in 2026, which CoSN says may lengthen refresh cycles. A device kept another year needs a repair history you can read.
Spares are where drift shows first. One r/k12sysadmin member described a school that said it had run out. The district's reply: "The inventory says you have 15 unassigned Chromebooks. And what about the students that left the district?"
Retirement is the other end. Google shows each device's "Automatic updates until" date. Our guide to IT support for schools covers the update policy and the summer refresh calendar.
What You Need Before You Start
If you manage Chromebooks across several schools, line these up before the summer sync.
- A Google Admin account that can enroll, move, and deprovision devices
- A device OU plan (by school or cart) and a user OU plan (by school and grade)
- An asset tag on every device, recorded once
- A student ID that never changes, from your SIS or directory
- A short status list everyone uses
- An inventory or helpdesk that syncs devices from Google
Agree on the status list first; our school asset guide linked above has a starter set.
The Chromebook Year, Step By Step
Each step pairs the Google action with the record change, so the two systems don't drift apart.
-
Summer: sync Google devices into the inventory
Pull every Chromebook from Google into the inventory before handout. Google identifies each device by device ID, serial number, and wireless MAC address. Use the serial number as the match key, since staff can check it against the device in hand.
Our IT asset inventory guide covers which source wins when two records disagree.
Example: Google lists 1,240 active devices, and 1,202 of them match a record. Before handout, sort the 38 unmatched serials into new purchases, repaired devices, and old typos.
Common mistake: matching on the asset ID. In Google it's a field an admin types by hand, so one typo creates a duplicate record.
-
Enroll new devices and place them in the right OU
Enroll each new Chromebook before anyone signs in to it, or you'll wipe it and start again. Devices land in the top-level organizational unit by default. Move each one to the OU whose device settings it needs. Apps and user policies follow the account that signs in, by the user's OU.
Example: a cart of 30 for a third-grade room goes into that school's cart OU. Scan each tag and serial together before the cart leaves the tech office.
Common mistake: expecting the device OU to set a student's apps. It sets device settings; the student's user OU or group sets the rest.
-
Distribute: assign each device to a student, a cart slot, or a school
Assign at the moment of handout, with the date. Where devices live in classroom carts, one district keeps it simple: "Cbooks are assigned to cart/slot". In 1:1 grades, assign to the student by an ID that won't change.
Why: damage and loss need a name. A solo technician with 1,400 devices assigns one per student. In that technician's words: "Things get taken care of a little better when we know who is the only suspect when it is damaged".
Common mistake: buying devices for each school by enrollment and letting the school hand them out. A district that works this way summed it up: "I don't recommend it".
-
School year: run repairs and loaners through tickets
Open a ticket on the device record for every repair, and issue the loaner against the same ticket. Both then show up in the device's history. The school asset guide linked above walks the full loop.
On the Google side, repair is the one case where a device you keep gets deprovisioned: Google says one that hasn't been can't be fully tested and repaired. When it comes back, check that an upgrade is available, wipe it if it wasn't factory reset at deprovisioning, and re-enroll it. Then confirm its OU and move the same record from in repair back to assigned.
Example: a district with a 7,000-device fleet runs a readiness check before testing. "Anything wrong they just write it down and put in a ticket. Makes test day go pretty well".
Common mistake: skipping the ticket for a two-minute fix. Repeat quick fixes on one device are the case for replacing it.
-
Year end: collect, count, and disable what didn't come back
Collect by grade or building on fixed dates, and scan each device in against its record. One district reports "about 98% of the devices back" over two days, and another swaps old models at lunch to get 99% "in a couple days".
For the rest, disable the device in Google so no one else can use it. A disabled device stays enrolled and keeps its upgrade, but the disable may not hold unless forced re-enrollment is on. It applies only once the device connects to the internet, so track it as pending until then. Set the record to missing right away, so the unreturned list is one filter. Then audit what students don't carry: carts, spares, and the repair shelf, against each school's list.
Example: the 98% district handles its last 2% in one line: "The ones we don't get back, we just disable".
Common mistake: deprovisioning a device that's only missing. Deprovisioning removes all policies from the device, the opposite of what you want for a device that may come back.
-
Retire: deprovision in Google and close the record the same day
Plan retirements from the "Automatic updates until" date Google shows for each device. When devices leave, deprovision them with the reason that matches, in groups by reason. Like a disable, it applies once the device is online.
The reason matters for licenses. For a same-model replacement, the upgrade from a standalone device can enroll another standalone device; an upgrade bundled with a device can't be transferred.
Example: for 300 devices, r/k12sysadmin members run GAM, an open-source command-line tool for Google Workspace admins under the Apache-2.0 license, against a CSV of serial numbers.
Common mistake: deprovisioning in Google and leaving the record active. Next year's count then includes devices in a recycling bin. Set the status to retired and keep the history.
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
- 14 days free
- No credit card required
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
- 15 minutes
- Your workflow, your questions
A live walkthrough tailored to your team.
A Checklist For Each Season
What To Look For In A Google Sync
| Question | Why it matters for Chromebooks |
|---|---|
| Which Google fields map to which record fields? | You need the serial number at least, to match the device you scan |
| Can you still add and edit devices by hand? | Devices that aren't enrolled yet still need a record |
| Does each sync leave a log on the record? | When details change, you can see when |
| How often does it run, and can you run it on demand? | Devices enrolled in August need a fresh sync before handout |
| Are your statuses separate from Google's? | Google's statuses include active, disabled, and deprovisioned; you also need loaner, in repair, missing, and retired |
| What happens to a record when Google disables or deprovisions the device? | A missing device shouldn't turn into a retired one without a person deciding |
Ticket and retirement checks are in the school asset guide linked above. For a shortlist of school helpdesks and how each handles devices, see our helpdesk software for schools comparison.
How To Measure It Worked
Chromebook management on the record side works when four numbers stay in range. Check them each term, from a Google CSV export and your inventory report.
- Match rate, both ways: each active Google device has one record in a fitting status (assigned, loaner, or spare). Each such record also has an active Google device. An active device with a retired record is an exception.
- Unassigned devices per school: compare with the spares you planned.
- Active devices past their update end date: each is a retirement waiting.
- Collection return rate: devices scanned in by the deadline, divided by devices due back. Count summer take-homes and the storeroom audit separately.
Example: in the step 1 fleet, 1,202 of Google's 1,240 active devices match a record in a fitting status. That direction's rate is 1,202 ÷ 1,240, or 97%, and the 38 exceptions are this week's work. Then check the record side. Swap in your own counts.
How this works in SherpaDesk
Chromebooks from Google, repairs on the record
You get a helpdesk and PSA a small IT team can run alone. Asset Manager is part of the High Camp plan. Google Device Manager syncs your Chromebooks into it, mapping serial number, MAC address, and device ID. Each synced asset gets a log record, and you can still edit devices by hand.
Each asset is assigned to a user and a location, and a repair ticket links to the device it concerns. Loaners carry Loaner or Daily Loaner status. An Asset Auditor assigned to a location verifies the devices there or marks them missing, and statuses include active, retired, and missing.
For K-12 schools and districts, pricing is based on student enrollment. Ask our sales team at sales@sherpadesk.com for a quote.
Who this isn't for
This isn't for a team shopping for the policy side of Chromebook management. Disabling devices, force-installing apps, and restricting YouTube or URLs stay in Google Admin. We build a helpdesk and PSA with no endpoint management. It also won't fit a district that requires self-hosted software, since our service is cloud-only.
Frequently Asked Questions
How do I manage apps on school Chromebooks?
In Google Admin. You can force-install specific Chrome apps and extensions for users, and users can't remove them. Set the policy on the top-level organizational unit for everyone, or on a child unit or group of users for one school or grade. For signed-in students, apps follow the account.
How do I block YouTube on school Chromebooks?
To block YouTube on managed devices, Google points admins to URL blocking. To limit it instead, Workspace admins choose strict or moderate restricted access, unrestricted access, or users who can approve videos. That setting applies by organizational unit or group, on Education accounts, school networks, and signed-in devices.
Should I disable or deprovision a lost Chromebook?
Disable it. Google says a lost or stolen device should be disabled so no one else can use it, and it stays enrolled. Check that forced re-enrollment is on; the disable applies once the device is online. Set the record to missing. Deprovision only for repair or retirement.
How many spare Chromebooks should a school keep?
Base it on enrollment swings and breakage. One small rural district orders "the enrollment count +~10% for breakage, loss, new enrollment". Another adds 25% to a three-year enrollment average: "Spares cover enrollment variation and device attrition over the 4-5 years we retain them". Give spares their own status.
How do you deprovision Chromebooks in bulk?
In Google Admin, select the devices and use the Deprovision action, grouped by reason. For hundreds of serial numbers, r/k12sysadmin members use GAM with a CSV. For retirement batches, retire the records too; devices out for repair stay in repair.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.
