Google Devices

Google Admin knows every Chromebook enrolled in your Google Workspace domain: its serial number, model, org unit, the user an admin annotated on it, its Chrome version, when it last synced, and the Auto Update Expiration date that decides when it stops getting updates. Connecting Google Devices to schoolOS reads all of that into schoolAssets and keeps it current, so a Chromebook's record in schoolOS is as good as the one in Google Admin without anyone retyping it.

What the connection does:

• Brings Chromebooks in. Every ChromeOS device in your domain is matched to an asset you already have, or, if you choose, added as a new one or set aside for review.
• Keeps them current. A sync runs every night, and Sync now runs one on demand. Each field Google reports lands in the schoolOS field you map it to.
• Feeds Device Health. The record and, with Chrome Management telemetry, the Chromebook's battery, update state, memory and processor temperature drive the Device Health checks for ChromeOS.
• Acts on a Chromebook, if you let it. With device management on, a Chromebook's page can disable, re-enable, reboot, wipe or powerwash it, open a remote session, and workflows can do the same: disable, re-enable, reboot, update an annotated field, and, asking first, wipe users, powerwash or deprovision.

Google Devices also reads the phones and tablets listed under Google endpoint management (mobile devices) and treats them the same way, except that Google keeps no asset tag for a phone or tablet, so a new one gets the next schoolOS asset tag. Chromebooks are what it's for.

You need Manage integrations to connect it or change its settings, and Update assets to send a device action.

Connect#

A Google Workspace super admin signs in once. The permission Google asks for is decided at that moment, so read the next step before you select the button.

1. Open Admin › Account › Integrations and select Google Devices.
2. Decide on Allow schoolOS to manage devices. It starts off. Off, schoolOS reads your Chromebooks and can't change anything in Google. On, Google is also asked for permission to disable a Chromebook and update its annotated user, location, asset ID and notes, which device actions and workflows need. See Read only or two-way.
3. Select Connect Google Admin console and sign in as a Google Workspace super admin. Google shows what schoolOS asks for: your ChromeOS devices (read only, or read and write when you allowed device management), your mobile devices (read only), Chrome Management telemetry (read only) and your email address, so the page can say which account is connected. Accept, and Google sends you back to the setup page.

The person who selects the button has to be the one who finishes the sign-in, still signed in to schoolOS: a sign-in link opened by someone else, or after the session expired, is refused with "The Google sign-in expired, or started before the latest settings. Try connecting again."

Once connected, the Connection section shows:

• Sync Google devices. On. Turn it off to pause the nightly sync and Sync now without disconnecting; your settings stay.
• Device management, with On or Read only. On a read-only connection, Enable and reconnect sends you back to Google to approve the extra permission. Your devices and their sync history stay. Changing it is always a reconnect, because it's Google that grants it.
• Chrome Management telemetry, with Reconnect for telemetry, only when the connection was made before schoolOS asked for telemetry. See Chrome Management telemetry.
• Connected to the Google account's email address and the date it connected, with Disconnect. A connection made before schoolOS asked for the email address shows Connected without a name.

The tokens Google issues are stored encrypted and never shown.

Which should I choose: read only or device management?#

Read only is enough to keep your inventory current and for every Device Health check. Choose device management when you want to act on Chromebooks from schoolOS: a technician disabling a lost Chromebook from its page, a workflow that disables a device when it's marked lost, or a remote session from a ticket. Pick read only if your district's policy is that Google Admin stays the only place devices are changed; you can turn device management on later without losing anything.

For example, a district with 3,800 student Chromebooks connects read only on a Monday, lets the nightly sync settle its inventory, and two weeks later selects Enable and reconnect so its "Chromebook reported lost" workflow can disable the device the moment a status changes.

The setup page#

The page reads as a summary once connected: Connection stays open (fold it from its name), and each section after Device sync folds closed and shows its current setting, like Add to review queue for new devices. Open the one you need; the page remembers what you left open. Every section has its own Save changes.

• Connection. Above.
• Device sync. Last sync with its status, and Devices synced: how many were updated, created and unmatched in the last run, whether it pulled everything or only what changed, how many unchanged devices it skipped, and anything about duplicate serials. Sync now at the top runs one right away in the background; the page watches it for up to 30 minutes and you can leave at any time.
• Asset identifier matching. Which schoolOS field is compared with which Google field when a device isn't linked yet. See How a Chromebook is matched.
• New devices from Google. What a sync does with a Chromebook that matches no asset, the defaults new assets get, and the Review queue. See New devices from Google.
• Remote device actions. Shows whether this connection has Device management on or is Read only, and what that lets workflows do.
• Field mapping. Where each Google field lands in schoolOS. See Field mapping.

What syncs and when#

A sync runs on a schedule every night, and whenever you select Sync now. The nightly sync keeps its own work small: it asks Google only for the Chromebooks that synced since the last successful run (Google answers to the day, so the sync reaches back a day further than it needs to). Everything is read again once a week, after a failed sync, on a connection's first sync, and every time you select Sync now, so a Chromebook that was deprovisioned or edited in Google Admin without ever checking in is still picked up within the week. Mobile devices are small and are read whole every time.

A device whose Google record hasn't changed since the last sync is skipped: nothing is written to it or its asset, its modified date and timeline stay as they were, and Devices synced says how many were skipped as unchanged. Changing a field mapping or a matching setting makes the next sync go over every device once.

For each device the sync:

1. Finds its asset, by its Google device ID and then by your matching setting (see below).
2. Links them: the asset's MDM section shows the Google record, with Last check-in from Google's last sync time.
3. Writes the mapped fields onto the asset. Its Last WAN IP is filled from the device's last known network on every sync, whether or not that row is mapped. If the asset has no asset tag, the device's Annotated Asset ID fills it in.
4. Runs the Device Health checks on it.

Each run is summarized on the Integrations tab of Admin › Account › Logs, with its counts.

Field mapping#

Everything Google reports shows on each device's MDM section whether or not it's mapped; mapping a field to a schoolOS field is what makes it filterable, reportable and usable in workflows. The table lists every field of Google's ChromeOS device record in its groups: Device Identity, Organization, Status & Enrollment, Network & Hardware Addresses, Annotations, Operating System & Firmware, Usage & Activity, Diagnostics & Telemetry, Chrome Management Telemetry and Device Files & Screenshots. Search them, or filter by Group or by Sync (Pull into schoolOS, Push to Google, Off). The API reference link opens Google's own description of the record.

For each row, tick it to sync it, choose the schoolOS field (your own custom asset fields are in the list; + New custom field… creates one on the spot, if you can manage asset fields), and the arrow says which way the value travels. A row with a suggested target that isn't chosen shows Default: and the field, with Use default. Reset to defaults puts every row back; Save changes saves.

A new connection starts with these rows on:

| Google field | schoolOS field | Direction to start | | --- | --- | --- | | Model | Model | Pull | | Support End Date (AUE) | Support End Date | Pull | | MAC Address (Wi-Fi) | MAC Address | Pull | | OS Version (Chrome version) | OS Version | Pull | | Last Sync | Last Inventory Date | Pull | | Annotated User | Assigned To (Email) | Push | | Annotated Location | Location | Push | | Annotated Asset ID | Asset Tag | Push | | Notes | Notes | Push |

Worth knowing:

• Support End Date (AUE) is the Auto Update Expiration as a date, read from autoUpdateThrough first, then the older autoUpdateExpiration, then Google's supportEndDate. Those three rows can't be mapped on their own; they say so and point at this one. It feeds the Support ending check. See Support End Date.
• Last Known Network can't be mapped either: its newest WAN address is saved to Last WAN IP on every sync, and the whole history shows on the MDM section.
• The four annotation rows start as Push, which means they aren't pulled. A sync only reads rows set to Pull, and a Google Devices sync doesn't write anything to Google: Google's annotated fields are written only by the workflow action. If you keep the annotated user, location, asset ID or notes in Google Admin and want them in schoolOS, switch those rows to Pull.
• Org Unit Path, Platform Version and Status aren't mapped to start with: an org unit like /Students/Grade 5 is rarely a building, the platform version is a different string from the Chrome version, and ACTIVE or DEPROVISIONED is an enrollment state, not a lifecycle status (the Not enrolled check reads it anyway).
• Model, Location, Status and the other reference fields are matched to a record you have, by name (or a location's code or abbreviation). A value nothing matches is skipped and the sync's log says so. A value a typed field can't take, like text in a date, is skipped the same way.
• Two rows pointed at the same schoolOS field keep whichever the sync reads last. Map one.

Which should I choose: map the org unit or not?#

Map Org Unit Path to Location only when your org units are your buildings (/Lincoln Elementary, /Jefferson Middle) and each one's name matches a location in schoolOS. If your org units are grades, cohorts or policy groups, leave it off, or map it to a custom text field like "Google OU" so you can filter on it without it fighting the location your technicians set. Annotated Location is the better source for a building when your admins fill it in.

How a Chromebook is matched#

The Google device ID is what tells devices apart; a serial number or an asset tag only finds the asset a not-yet-linked device belongs to. The full rules, including re-enrollment, the same device in two device managers and duplicate serials, are in How a device is matched. What's specific to Google:

• The device ID is Google's deviceId. Once linked, a Chromebook stays linked to its asset whatever its serial says.
• The serial number is Google's serialNumber, compared with the asset's Serial Number. A placeholder serial never matches.
• Asset identifier matching adds one more comparison for a device that still has no match: the schoolOS identifier (Asset Tag or Serial Number) against the Google field to match (Annotated Asset ID, Serial Number or Device ID). The page offers Asset Tag ↔ Annotated Asset ID first, which is right for a district that types its asset tag into Google's Asset ID field at enrollment. Until you save this section, the sync matches on the serial number alone.

A Chromebook whose serial is on more than one asset waits in the Review queue as Duplicate serial, where you choose the asset or give it its own.

Which should I choose?#

| Setting | Choose it when | | --- | --- | | Asset Tag ↔ Annotated Asset ID | Your enrollment process puts the schoolOS asset tag into Google's Asset ID field, so a Chromebook whose serial was mistyped on the purchase spreadsheet still finds its asset. | | Serial Number ↔ Serial Number | Your asset list came from purchase records with reliable serials and Google's Asset ID field is empty or used for something else. | | Asset Tag ↔ Device ID | Only if your asset tags are Google device IDs, which is rare. |

New devices from Google#

When Google has a device schoolOS doesn't decides what happens to a Chromebook that matches no asset:

| Option | What happens | Choose it when | | --- | --- | --- | | Do nothing (log only) | The device is counted as unmatched in the sync's log. Nothing is added. This is how a new connection starts. | You add assets another way, like an asset import from purchasing, and Google only fills in details. | | Add to review queue | The device waits in the Review queue below until someone approves it. | Your first sync, or a domain that also holds staff-owned or test devices you don't want as assets. | | Auto-create | The device becomes an asset right away, with the defaults below. | Google Admin is your list of record, like a 1:1 program where every enrolled Chromebook is district property. |

With review or auto-create on, two more settings appear: Default device type (new assets get this type) and Default location (where they're placed; leave it blank to use your account's default location, when you have one). Auto-create needs both: until they're set, new devices go to the review queue instead, with the reason Missing defaults. A new asset's name is the device name Google reports, or its annotated asset ID, or its model; its asset tag is the annotated asset ID, or a generated schoolOS tag when there's none.

Include inactive Google devices is off to start with. Off, a Chromebook Google reports as deprovisioned, disabled or inactive is recorded on the sync but never added, whichever option you chose above. On, those are added as inactive assets, with a retired status, so your records hold the devices you've already pulled out of service.

Assets are never deleted when a device leaves Google Admin. A Chromebook drops out of Google for a repair, a move or a deprovision, and deleting the asset would take its tickets and purchase record with it. Retire assets with a status change or a workflow instead.

The review queue#

Review queue lists every Google device waiting for approval, with its Serial number, Asset tag, name, model, assigned user, org unit and Why it's here. The reasons are summarized above the list: Review required by setting, Missing Device ID or Missing Annotated Asset ID (no usable identifier; these never auto-create), Asset tag already exists, Duplicate serial, Google device already linked, Missing defaults, Retired or disabled.

In a device's ... menu, Approve creates an asset with the defaults above and Reject leaves it out (a rejected device stays out on later syncs). A Duplicate serial item lists the assets with that serial: Link to one of them, or Create a separate asset when it's a different device. Tick several devices to approve them together, or select Approve all; the confirmation says the type and location they'll get. Bulk approvals run in the background and the page reports approved, created, linked, skipped and failed counts as they go. Refresh reloads the queue.

For example, a district connects Google Devices after importing its 4,000-row purchase spreadsheet. It chooses Add to review queue, sets Default device type to Chromebook and Default location to the district warehouse, and runs Sync now. 3,960 Chromebooks match by serial and fill in. The 40 that don't wait in the queue, where IT finds 32 spares never on the spreadsheet (approved), 6 with mistyped serials (Link to the right asset) and 2 staff-owned Chromebooks (rejected).

Chrome Management telemetry#

Google's device record doesn't carry the Chromebook's health. Chrome Management telemetry does: Google's battery verdict and the battery's full-charge capacity against its design capacity, whether a downloaded ChromeOS update is waiting for a restart, free memory, the hottest processor sensor, and its heartbeat. Every sync reads it beside the device records and attaches it to each Chromebook; it shows on the device's MDM section under Chrome Management Telemetry, and the Chromebook battery, OS update not applied, Low memory and Running hot checks read it. See Device Health.

It needs three things:

• The permission. Every connection made since schoolOS started asking for telemetry has it. An older one shows Reconnect for telemetry under Connection; select it, approve in Google, and nothing else about the connection changes.
• The reporting policy. In the Google admin console, the device telemetry reporting policy has to be on for the organizational units the Chromebooks are in. A Chromebook in an org unit without it reports nothing, and its telemetry checks read Not checked.
• A Chromebook that reports. Telemetry comes from the device itself, so one that hasn't been on in weeks shows its last report.

When telemetry can't be read at all (the permission is missing, or the API isn't available to the account), the sync carries on with the device records alone and notes it once in its log.

Device actions and workflows#

With Device management on, two things open up. A read-only connection offers neither: a device action says the connection can't change anything in Google, and a workflow step is skipped with the reason "the Google integration was connected without device-management permission — reconnect it in Admin → Integrations to grant it".

On a Chromebook's page, at the bottom of its MDM section, Google's device actions sit in one row; each is explained when you hover it, and one the device can't take is disabled with the reason. Each opens a dialog that says what it does, sends it when you confirm, then reports whether Google queued it or refused it until you close it. Sending one needs Update assets.

| Action | What it does | The device must be | | --- | --- | --- | | Request Remote Session | Opens a Chrome Remote Desktop session so you can see and control the screen. The Chromebook has to be online; someone signed in sees that an administrator is connecting, and the link lasts a few minutes. | Active | | Reboot Device | Restarts it. Google applies it only to a Chromebook in a kiosk or managed guest session, or one that's signed in. | Not deprovisioned | | Disable Device | Locks it to a full-screen message with your return details. Reversible: the right action for a device reported lost or stolen. | Active | | Re-enable Device | Lifts a disable. | Disabled | | Wipe Users | Removes every user profile and its local data. The device stays enrolled. Anything synced to the user's Google account is untouched. | Not deprovisioned | | Powerwash Device | Factory-resets it, removing all local data. It stays in your domain and re-enrolls on setup. | Not deprovisioned | | Deprovision Device | Releases it from management and returns its license. You choose the reason Google records: Retiring the device, Replacing with the same model, Replacing with a different model or Upgrade transfer. Re-enrolling it later uses a license again. | Not deprovisioned |

Wipe Users, Powerwash Device and Deprovision Device erase or release the device, so the dialog asks you to type ERASE and the asset tag first: check the tag on the device in front of you against the one on screen. Every action is queued with Google and applied when the Chromebook is next online, so schoolOS reports it as queued, not done, and the asset's timeline records it. On a device linked to a ticket, the same actions are under the device's Apps: Remote session starts a Chrome Remote Desktop session so a technician can look at the screen from the ticket, and Google Admin has the rest, with the same confirmation. Each one sent from a ticket also goes on the ticket's timeline. Moving a Chromebook to another organizational unit is still done in the Google Admin console.

In workflows (Admin › Account › Workflows), the Google Devices actions group works on assets linked to a Google device: Disable the device, Re-enable the device, Reboot, Update an annotated field (writes Annotated User, Annotated Location, Annotated Asset ID or Notes, copied from the asset, like the assignee's name, or as a fixed value), and Wipe users, Powerwash and Deprovision (with the reason Google records). On a read-only connection the group is grayed out with a link here to turn on device management. Wipe users, Powerwash and Deprovision can't be undone, so a workflow with one asks first: the person whose change starts it types ERASE and the asset tag (or the number of devices) before it runs. The templates Lost Chromebook: disable it, Found Chromebook: re-enable it and Retired Chromebook: deprovision it are a quick start. Nothing else in Google Admin changes. See device actions in workflows.

For example, a middle school tech gets a ticket that a student's Chromebook was left on the bus. In the card of the ticket's linked device she opens Google Admin under Apps and selects Disable Device; the lock screen with the district's phone number appears the next time it's opened. When it turns up in the lost and found, Re-enable Device puts it back in service.

Disconnect#

Select Disconnect under Connection, or use the row's menu on Admin › Account › Integrations, and confirm. Syncing stops and the stored Google tokens are cleared, along with this page's settings (matching, new-device handling and field mapping), so reconnecting starts from the defaults. Your assets stay, with every detail already synced onto them, and each device's MDM section keeps its last record. Nothing changes in Google Admin. To revoke schoolOS's access for good, also remove it from the connected account's third-party access in Google. See Disconnect an integration.

Troubleshooting#

• "The Google sign-in expired, or started before the latest settings. Try connecting again." The sign-in link was finished by someone other than the person who started it, after their schoolOS session ended, or after the setup page's settings changed. Start again from the setup page, signed in.
• "Google sign-in didn't finish: access_denied." The Google account declined, or isn't a super admin. Sign in with a Google Workspace super admin.
• The sync fails with "The saved OAuth token was revoked or expired. Disconnect and reconnect this integration." Someone removed schoolOS's access in Google, or the admin account was deleted or changed its password with "sign out everywhere". Disconnect, then connect again.
• "The connected account does not have the required device read permissions." The account that connected isn't a super admin anymore, or the permission was revoked. Reconnect as a super admin.
• "Google rejected the Workspace customer context." The account that connected doesn't belong to the Workspace domain that holds the devices. Reconnect with a super admin of that domain.
• Device Health shows Not checked for the battery, update, memory or temperature checks. Either the connection predates telemetry (select Reconnect for telemetry), or the telemetry reporting policy is off for the device's organizational unit in the Google admin console.
• A Chromebook in Google isn't in schoolOS. With Do nothing (log only) it never will be: choose Add to review queue or Auto-create. A deprovisioned or disabled Chromebook is skipped unless Include inactive Google devices is on. A device with no device ID or, when matching on tags, no annotated asset ID waits in the review queue as missing its identifier.
• A workflow step says the device was skipped. The asset isn't linked to a Google device (it's linked to another device manager, or to nothing), or the connection is read only. The step's run history gives the reason.
• A device action is grayed out. Hover it: the device is already disabled, deprovisioned, or hasn't reported a status yet. A device that hasn't reported recently can be sent an action, with a note that its state is unknown.
• "A sync is already queued or running." One sync at a time per connection; Sync now waits for it instead of starting another.
• Sync now says it's still running after 30 minutes. The page stopped watching, not the sync. Refresh later; Last sync shows its result.