Machine Detail

The machine detail page (/machines/{id}) shows deeper context for a single registered device: summary (MAC, last check-in, deployment status, assigned recipe, Windows family (Client or Server, from the recipe's image), source site, deployment timestamps, and, for machines that went through Autopilot, an Autopilot status row plus the Autopilot Sysprep verdict described below), hardware specs (manufacturer, model, serial, RAM in GB, disk), diagnostic bundles uploaded by the agent, and the most recent 50 deployment log entries. Deployments themselves are controlled entirely by the PXE agent, so there are no retry, reassign, or cancel actions here. Navigate to it by clicking a machine name on the Reports > Machines tab.

Autopilot Sysprep#

Classic Windows Autopilot does not finish when the deployment does. After the image is applied and the deployment is marked Completed, the machine boots into full Windows, registers itself with Intune, and then runs sysprep /generalize so it comes back up at the Autopilot OOBE. That last step can take another hour, and it decides whether the device is actually an Autopilot device or just a machine sitting on a bench.

The Autopilot Sysprep row appears only on machines that ran classic Autopilot, and shows one of four things:

• Running - the device reported that sysprep was starting and has not reported the result yet. Give it up to half an hour.
• Succeeded - the device is generalized and has restarted into the Autopilot OOBE. Nothing further is needed.
• Failed - the device is registered in Autopilot but was not generalized, so it will not run the Autopilot OOBE. This is the state worth acting on: Intune believes the device is enrolled, and the machine is still logged in as the first-boot temporary administrator. It is safe to log into. Look at C:\Windows\System32\Sysprep\Panther\setuperr.log on the device, or at the diagnostic bundle below (one is collected automatically for this failure), then fix the cause and re-deploy. The failure also appears as AUTOPILOT_SYSPREP_FAILED in the machine's status message, so it is visible on Reports > Machines and on Activity > Deployments without opening this page, and it raises a Deployments notification.
• No verdict - sysprep started on this device and no result ever arrived.

"No verdict" is not a failure. Generalizing a machine resets its network configuration, and the device restarts itself seconds after sysprep finishes, so a device that succeeded can still lose its last message. The honest answer is that we do not know, and that is what this says. Check whether the device reached the Autopilot OOBE; C:\Windows\Temp\fluxsysprep.log on the device holds the answer either way.

Device preparation and Autopilot for existing devices do not run a first-boot script and never sysprep, so this row never appears for them.

Diagnostic Bundles#

When a deployment fails, the agent collects a diagnostic bundle on the machine - logs, configuration and hardware facts, with secrets redacted - and tries to upload it to this server before offering the technician the USB copy option. Bundles that arrive are listed here with the time they were received, the error code and phase that produced them, and their size.

• Download fetches the zip. Read Only users may download - diagnostics are readable by every role.
• Delete removes the bundle and its file. Read Only users do not see this button, and the server refuses the action for them.
• The agent never deletes its local copy after a successful upload, so a technician standing at the machine always has the file too.

Bundles are pruned automatically by the daily cleanup: anything older than SupportBundleRetentionDays (30 by default) goes, and only the newest SupportBundleMaxPerMachine (5 by default) are kept for any one machine, so a machine stuck in a boot loop cannot fill the disk. Neither setting accepts 0 - there is no "keep forever" option. The server also caps a single upload at 64 MB and rate-limits how many bundles one machine can send per hour; a refused upload is never lost, because the bundle is still on the machine and the USB option is still offered. A bundle is text logs and normally arrives well under 5 MB, so the cap is deliberately far above anything legitimate: an upload that trips it means something on that machine produced an abnormal log, and is worth reporting.

Bundles from a relay site#

A machine deployed at a relay site posts its bundle to that relay - that is the server the agent was given. Nobody logs into a relay, so the relay forwards the bundle on to Core in the background, and the Source column tells you which one it came in through:

• This server - the agent uploaded it here directly.
• A site name - a relay carried it. The name links to that site.

The transfer runs beside the relay's heartbeat, never in front of it, so a large bundle cannot delay deployments or make a site look unreachable. It resumes from wherever it got to if the link drops or the relay restarts, and a bundle that is sent twice is never stored twice - the bundle's SHA-256 is what identifies it on both sides. While bytes are still moving, the bundle appears here as Transferring with no download link yet.

If a relay cannot deliver a bundle at all, it says so rather than dropping it quietly. The bundle appears as Not delivered with the reason - the server refused it as too large, the link never came back, or the relay's forwarding queue overflowed - and the same reason is written to the audit log as SUPPORT_BUNDLE_FORWARD_FAILED. The relay keeps its own copy in either case: retention on a relay never removes a bundle that has not reached Core, and only shortens to three days once Core has confirmed it. An undelivered bundle can still be collected from the relay's SupportBundles folder by hand.

If Core has never heard of the machine a bundle came from - a deployment that died before its first status reached Core - the bundle is still accepted and still attributed to the site it came from. It simply has no machine page to appear on; it is listed by GET /api/support-bundles.