Machines

Deployment monitoring lives on Reports > Machines (/reports) - the roster of active and completed deployments - with per-machine detail one click away at /machines/{id}. The old /devices and /machines addresses redirect to the roster.

There is no separate live-console page. Everything a machine has to say is either a row on the roster or a panel on its own detail page.

The roster#

Reports > Machines opens with a summary strip (total, completed, failed, in progress, and the success rate across finished deployments) and a 30-day deployments-per-day trend line. An Autopilot row of registered / pending / failed counts appears only when at least one machine has an Autopilot status.

Filter bar#

• Search - hostname, MAC address or serial number
• Status - Pending, In Progress, Completed, Failed
• Recipe - the assigned deployment recipe
• Manufacturer and Model - both populated from what agents actually reported, so the lists only ever contain hardware you own

The counter on the right of the bar states how many machines match. It mentions the 100-row display cap only when the list is genuinely truncated ("Showing 100 of 243").

Table#

Fleet-wide hardware distribution - manufacturers, models, RAM and disk buckets - is its own tab, Reports > Hardware, because the roster's filters do not apply to it and mixing the two made both harder to read.

Machine detail#

/machines/{id} is read-only. Deployments are driven entirely by the PXE agent, so there is no retry, reassign or cancel here.

• Summary - MAC, last check-in, deployment status, assigned recipe, source site, deployment start and completion timestamps, and an Autopilot status row that appears only for machines that actually went through Autopilot.
• Hardware - manufacturer, model, serial, RAM (GB), disk size, applied drivers.
• Recent Deployment Logs - the last 50 log entries for this machine, newest first, colour-coded by level.

Get logs (relay-deployed machines)#

Machines deployed through a relay carry a SourceSiteId. For those, the Get logs action in the page header fetches the relay's own log trail for the machine and shows it in a searchable, copyable dialog. The relay is identified from SourceSiteId and authenticated with its API key; the MAC address is the join key, because machine IDs differ between the Core and relay databases.

The button explains itself when it cannot run: for a Core-deployed machine it is disabled with "This machine was deployed directly by Core - no relay to pull logs from."

How logs get here#

The agent's Serilog pipeline includes a ServerConsoleSink that batches log output and posts it back roughly once a second during deployment. Those entries are what the Recent Deployment Logs panel reads. They persist, so the panel is just as useful after a deployment finishes as during one.

Retention#

Machines are purged automatically after a configurable number of days (default 7, set in Settings > General > Data Retention). MachineCleanupService runs daily and deletes machines not seen since the retention cutoff that are not actively deploying. Set retention to 0 to disable auto-purge.

A machine's deployment history (the list of past deployments on its page) is kept separately under Deployment History on the same tab: entries older than that many days are removed by the same daily cleanup, 365 by default, 0 to keep forever. The rows also go with the machine when the machine itself is purged. Finished ISO detection jobs follow the Job History retention, like driver downloads and WIM jobs.