Looking after 1,400 devices
Mangrove Market's stores run on about 400 tills and about 1,000 handheld scanners. You cannot walk up to each one, so you manage them from one console. This lesson shows how to keep that fleet known, configured, patched and safe without breaking a trading day.
By the end you can
- Keep a device inventory that tells you what exists, where it is and whether it is healthy
- Explain how enrolment, configuration profiles, check-ins and kiosk mode work on a managed device
- Choose a patch cadence from severity, and schedule updates outside trading hours
- Roll an update out in waves with health gates, and pause or fix forward when a gate fails
- Handle devices that were offline for weeks, compliance reports, remote support and lost or stolen devices
The everyday picture
Think of a company that runs 1,400 delivery vans. Nobody at head office drives them, but the fleet manager knows every van by its number plate: which depot it belongs to, when it was last serviced, and whether it came back last night. Each van has a logbook, and each evening the drivers report in.
When the manufacturer recalls a part, the manager does not fix all 1,400 vans on the same morning. A few vans at one depot get the new part first, then a bigger group, then the rest. If the new part makes a van stall, the work stops with only a handful of vans off the road. A van that has not reported in for a week gets a phone call, and a stolen van gets its fuel card blocked at once.
Device management is the same job for tills and scanners. The logbook is your inventory, the evening report is the device's check-in, the recall is a patch, and the careful order of depots is a rollout in waves.
The fleet and the inventory you can trust
Mangrove's 320 stores have about 400 checkout tills (one or two per store) and about 1,000 handheld scanners running the Store app (about three per store), plus back-office laptops. The store box from Linux from the command line is managed like a server, so this lesson is about the end-user devices.
Everything else in this lesson depends on one list: the device inventory. For each device it records a few fields that you will use every day:
- Identity: an asset tag, the maker's serial number, the model and the purchase date.
- Place and owner: the store (its
site_id), and for laptops the person it is assigned to. - Status: in service, spare, in repair, lost, or retired.
- Health: operating system version, Store app build, and the time of the last check-in with the management server.
The hard part is keeping the list true. Devices break, get swapped between stores, sit in a drawer, or get stolen. Three sources tell you about a device, and they often disagree: the purchase records (what you bought), the management server (what has enrolled and checked in), and the network (what appears on the store Wi-Fi). Compare them every week, by serial number. A device that was bought but never enrolled is sitting somewhere unmanaged. A device on the store Wi-Fi that is not in the inventory is either a phone on the wrong network or a device nobody recorded.
Treat the inventory as the source of truth: when a scanner moves from store 142 to store 57, the inventory changes first and the console follows. If people fix only the console, the two drift apart within months.
Quick check
Your weekly comparison finds a scanner serial number in the purchase records that has never checked in with the management server. What is the most likely meaning?
A device that was bought but never checked in was never enrolled, or was reset and not enrolled again. It gets no updates and no settings, and nobody can lock it if it goes missing, so you find it. A server data loss would show up as many devices missing at once, not one.