Answers for district IT
Do districts need an MDM beyond the Google Admin console?
For a district that is entirely on ChromeOS, the Google Admin console with Chrome Education Upgrade licenses is a complete device management platform, and adding a general-purpose MDM on top usually buys nothing. The question becomes real the moment the fleet stops being uniform — a Windows lab, staff laptops, iPads in the primary grades, a handful of Macs in the art wing. Then you are choosing between managing each platform in its own native console and consolidating some of them into a cross-platform tool, and the honest answer for most districts is a mix. What is worth separating out early is that none of these systems is an asset management system, and expecting one to be is the mistake that produces the reconciliation problem three years later.
What the Google Admin console actually manages
For ChromeOS, the Admin console is the management plane, and it is a capable one. Enrolled devices enforce policy centrally: network and Wi-Fi configuration, which applications and extensions may be installed, sign-in restrictions, kiosk and managed guest sessions, update behavior, printing, and per-organizational-unit differentiation so a high school and an elementary building can have genuinely different rules. It also handles the operations that matter for a 1:1 program — disabling a lost device remotely and displaying a return message on its screen, wiping, and moving devices between organizational units in bulk.
That management requires a Chrome Education Upgrade license per device. Unenrolled Chromebooks are consumer devices; the license is what makes a Chromebook a managed asset. In the education edition these are typically sold as a perpetual license per device covering the life of that device, which lines up with how districts budget hardware. Buying devices without the licenses and planning to add management later is a well-worn way to end up with a fleet you cannot control.
The console also holds the inventory data everything else keys on: serial number, model, enrollment status, assigned organizational unit, last sync time, last known user, and a set of editable annotated fields for an asset ID, a location, and a user. Those annotated fields are important and frequently underused — they are the hook that lets a district's asset identifiers live alongside Google's.
For Chrome browser on non-ChromeOS machines, the console manages the browser rather than the device through Chrome Browser Cloud Management, which is a genuinely different scope. It sets browser policy and extension controls on Windows and Mac endpoints; it does not manage the operating system, patching, disk encryption, or anything else about those machines. Districts sometimes conflate the two and conclude they are managing their Windows fleet when they are managing its browser.
When the Admin console is not enough
The clearest trigger is a second platform. Windows and macOS endpoints need operating system patching, configuration and security baselines, disk encryption key escrow, software deployment, and inventory of installed applications — none of which the Google Admin console does. Microsoft Intune is the common answer for Windows, particularly in districts already licensed for Microsoft 365 education tiers where the entitlement may already exist. Jamf is the long-standing choice for Apple, and Apple School Manager plus an MDM is effectively required to manage iPads and Macs at all, since enrollment, app licensing, and supervision run through it.
The second trigger is depth on ChromeOS itself. Some districts want capabilities the console does not natively provide: richer reporting and analytics across the fleet, automated response workflows, integration with a security operations toolchain, or unified policy expression across platforms so a single compliance baseline can be stated once. Third-party tools including Jamf and various unified endpoint management platforms offer ChromeOS coverage for exactly this reason.
The third trigger is organizational rather than technical. If one team manages all endpoints, a single console with one policy model and one report reduces real cognitive load, even when each native tool is individually better at its own platform. If instead ChromeOS and Windows are managed by different people in different departments, native tools per platform are often the pragmatic answer and consolidation is a solution to a problem you do not have.
What is rarely a good reason is a feature checklist. Cross-platform MDMs advertise ChromeOS support, and the depth of that support varies; some manage ChromeOS by integrating with the Google Admin API rather than replacing it, which means you still need the licenses and still have the console. Ask specifically what a tool does natively versus what it proxies before assuming consolidation removes a system.
Running a mixed fleet without running four disconnected systems
The realistic end state for most districts with more than one platform is native management per platform — Google Admin console for ChromeOS, Intune for Windows, Jamf or another Apple MDM for iPads and Macs — with a layer above that unifies inventory and workflow. That is not a compromise so much as a recognition that native tools track their platform's capabilities as they change and cross-platform tools lag them.
The unifying layer is where the asset record lives. Each management console knows the devices it enrolls; none of them knows which student has the device, what it cost, which grant paid for it, what its warranty terms are, what it has been repaired for, or when it is due for replacement. Those are the questions a district actually gets asked, and they span platforms. Pulling device inventory from each console into one asset system, matched on serial number, is what makes them answerable.
Matching on serial is the right key and it needs a plan for failure. Serials collide with existing records, arrive in inconsistent formats, or belong to devices nobody has yet recorded. An import that silently creates a duplicate for every unmatched serial produces an inventory that is wrong in a way that is very hard to detect later; routing unmatched devices to a review queue instead keeps the failure visible.
Decide deliberately which system is authoritative for which field. Enrollment status, last sync, and organizational unit are the management console's to own — it is the live truth. Asset tag, assigned user, funding source, purchase order, warranty, and location are the asset system's. Write-back into the console's annotated fields is genuinely useful, since it puts your asset ID in front of whoever is looking at a device in the console, but it should be a controlled one-directional push with a preview of what will change, not a continuous two-way sync that lets each system overwrite the other.
And keep a device's history when it leaves the management console. A retired or wiped device disappears from the console; it should not disappear from the inventory, because disposal documentation and audit trails outlive enrollment.
Licensing and cost, without the surprises
Chrome Education Upgrade is per device and, in its education perpetual form, covers the device for its life, which makes it a hardware cost rather than a subscription. Confirm at purchase whether the license is included with the devices you are buying, since resellers bundle inconsistently and a batch delivered without licenses is an unpleasant discovery at deployment.
On the Microsoft side, education tenants frequently already hold Intune entitlements through their Microsoft 365 education licensing, and districts sometimes buy a separate management tool while holding an unused entitlement. Check what you already have before you evaluate alternatives; it is a common and expensive oversight.
Apple management has an unavoidable structural cost: Apple School Manager is free, but an MDM is required to do anything meaningful with supervised devices, and the app and book licensing model is its own workflow. Budget for the MDM as a permanent line item rather than a project cost.
When comparing cross-platform tools against native management, compare against zero rather than against a list price, because native management on ChromeOS and Windows may already be paid for. The question is not whether a unified tool is reasonably priced; it is whether what it adds beyond the consoles you already own is worth its cost.
Count the staff time on both sides of the ledger honestly. Running four consoles has a real ongoing cost in context switching and in training coverage when someone is out. Migrating to a unified tool has a real one-time cost measured in months, and unified tools sometimes require keeping the native console anyway. Neither number is usually written down, and both should be.
MDM is not asset management, and the difference matters
This is the distinction that most often gets discovered too late. An MDM answers what a device is doing right now: is it enrolled, is it patched, what policy applies, when did it last check in, what is installed. An asset system answers what the district owns and what happened to it: who has it, what it cost, which funding source bought it, what its warranty covers, how many times it has been repaired and for what, when it must be replaced, and what became of it at disposal.
The practical test is to imagine the questions you get asked and ask which system holds the answer. An auditor asking for every device purchased with a specific federal grant, with current location and disposition. A principal asking which of her students has an unreturned device. A business office asking what the district spent on repairs by building. A board asking how many devices fall past auto-update expiration in each of the next three years and what that costs. No management console answers any of those, because they are not questions about the operating state of an endpoint.
The second reason they must be separate is coverage. Roughly a third of what a district owns never enrolls in an MDM at all — projectors, document cameras, interactive panels, printers, network gear, calculators, band instruments, science equipment. If your inventory is whatever the management console reports, none of that exists on your books, and it is a substantial share of the capital you are accountable for.
The third reason is time. Devices leave management before they leave the district and long before they leave the audit trail. A device wiped and deprovisioned in June and stored in a closet until disposal in November is invisible to the console for five months during which it is very much still district property.
So the right architecture is not a choice between them. It is native management per platform for control, an asset system for ownership and lifecycle, and a reliable join between them on serial number so neither has to be maintained by hand.
Common questions
Is the Google Admin console an MDM?
For ChromeOS, effectively yes — with Chrome Education Upgrade licenses it enforces policy, controls applications and extensions, manages network configuration, differentiates by organizational unit, and handles remote disable and wipe. What it does not do is manage Windows or Apple operating systems; Chrome Browser Cloud Management covers the browser on those platforms, not the device.
Do we need a Chrome Education Upgrade license for every Chromebook?
For every Chromebook you intend to manage, yes. The license is what makes an enrolled Chromebook a managed device; without it you have a consumer device. In education it is typically sold as a perpetual per-device license covering the device's life, so confirm at purchase whether your reseller included it — bundling is inconsistent.
When does a district need Intune or Jamf?
When the fleet includes Windows or Apple endpoints. Those platforms need operating system patching, security baselines, disk encryption escrow, and software deployment, none of which the Google Admin console provides. Check your Microsoft 365 education licensing first — many districts already hold Intune entitlements they are not using.
Should we consolidate everything into one cross-platform MDM?
Usually not for management itself. Native tools track their platform's capabilities as they change; cross-platform tools lag, and some manage ChromeOS by integrating with the Google Admin API rather than replacing it, so you keep the console and the licenses anyway. Consolidate inventory and workflow above the consoles instead.
Isn't our MDM already our device inventory?
No. A management console knows a device's operating state — enrolled, patched, last checked in. It does not know who has it, what it cost, which grant funded it, its warranty terms, its repair history, or its disposal record. It also does not know about the projectors, panels, printers, and lab equipment that never enroll at all, which is a large share of what a district owns.
How do we connect an MDM to an asset system?
Import device inventory from each console and match on serial number, which is the one identifier every platform agrees on. Have a plan for unmatched serials — route them to a review queue rather than auto-creating records, or you will build duplicates that are very hard to detect later. Keep write-back into the console's annotated fields one-directional and previewed.
Which system should own which fields?
Give the management console enrollment status, last sync, and organizational unit — it is the live truth for those. Give the asset system the asset tag, assigned user, funding source, purchase order, warranty, location, and disposition. Deciding this explicitly is what prevents two systems from overwriting each other.
How Chalk approaches this
Chalk ingests ChromeOS devices from the Google Admin SDK, matches them to asset records by serial, and routes anything unmatched to a queue instead of auto-creating duplicates; Intune and Jamf connectors feed the same records, so a mixed fleet lives in one place. Write-back to the annotated fields, organizational unit, and status goes through a diff preview with typed confirmation for destructive changes. Devices that never enroll anywhere — projectors, panels, lab equipment — live on the same asset records with purchase order, funding source, warranty, and disposition, so the inventory covers what the district owns rather than only what a console reports.