Technical · Course T7Lesson 3 of 4
Operating at scale
8 min read- Apply commands, tags, app upgrades, and policy transfers in bulk
- Build the CSV files bulk operations expect
- Run PowerShell and batch scripts across a Windows fleet
Everything in the previous lesson works one device at a time. That's fine for triage and useless for a rollout. Scale changes the tool.
Bulk actions from the device list
Select devices with the checkboxes on the Devices page and the bulk action toolbar appears. Four action types exist, and their platform coverage is uneven in a way you should quote accurately:
| Action type | Android | iOS | Windows |
|---|---|---|---|
| Commands | Yes | No | No |
| Update Tags | Yes | Yes | Yes |
| App Upgrade | Yes | No | No |
| Policy Transfer | Yes | No | No |
Bulk commands cover Admin Lock (with the same custom message and optional scheduling as the single-device version), Admin Unlock, Uninstall WeGuard, and Delete Device — the last requiring confirmation and unavailable to Reseller Observer accounts.
For very large sets, the CSV path beats clicking: upload a file keyed on IMEI
(required, minimum 7 characters), with optional Admin Tagged Name, ID1,
and ID2 columns.
Tags: the thing that makes a fleet searchable
Tagging looks like housekeeping and behaves like infrastructure — tags are what the device list filters on, so an untagged fleet is an unsearchable one. Four fields are available:
| Tag field | Android | iOS | Windows |
|---|---|---|---|
| Admin Tagged Name | Yes | Yes | Yes |
| User Tagged Name | Yes | No | No |
| Assigned To | Yes | Yes | Yes |
| Inventory ID | Yes | Yes | Yes |
Bulk tag updates take a CSV keyed on Device ID (again, 7+ characters) plus one
column per tag field you're setting. The advice worth giving every customer at
deployment time: decide the tagging convention before the first hundred devices
enroll — Assigned To and Inventory ID are what make a fleet auditable against
their asset register later.
Windows shell commands
Windows gets something the other platforms don't: arbitrary script execution.
Shell Commands (main navigation, or the per-device tab) runs PowerShell
(.ps1) and Command Prompt (.bat) scripts across the fleet, and it's
plan-gated plus permission-gated (ShellCommands read for history, write to
execute).
The flow is four decisions:
- Execution level — Account Level hits every Windows device; Policy Level opens a grid of Windows policies you toggle on and off.
- Command type — PowerShell or Command Prompt. Switching type clears any
uploaded file so you can't send a
.batto the PowerShell engine. - Upload the script — drag-and-drop or file picker; only the matching extension is accepted.
- Execute — online devices run immediately, offline devices queue and run on reconnect.
The Command History tab retains per-device results for everything you've sent, which is both your debugging surface and your audit answer when a customer asks what ran on their endpoints.
This is the capability that turns "we manage your devices" into "we remediate your endpoints" — one script, one policy, three hundred laptops patched before the customer files a ticket.