Reports

Reports (/reports) answers "what do I have, and what happened to it". Each tab is its own report at its own address, so a tab can be linked and bookmarked: /reports (Machines), /reports/hardware (Machines, by model), /reports/storage, /reports/relay-sites, /reports/certificates.

The Core-only tabs (Storage, Relay Sites, Certificates) are hidden on a relay.

Machines#

One dataset at two grains, chosen with the View selector at the top of the tab. Machines and Hardware used to be two tabs, and neither name said which grain you were about to get.

Every device#

The deployment roster.

• Summary strip - total, completed, failed, in progress, and the success rate across finished deployments
• Deployments per day - a 30-day trend line built from deployment history
• Autopilot - registered / pending / failed counts, shown only when any machine has an Autopilot status
• Filter bar - search (hostname, MAC, serial) plus status, recipe, manufacturer and model
• Family filter - All, Client (Windows 10/11) or Windows Server. It also applies to the Hardware tab, where the model table shows which family each model's machines are. The choice is kept in the address (?family=server) so a link opens the same view. A machine with no recipe has no family and appears only under All.
• Machines table - machine (hostname over MAC, linking to the machine's page), make/model with the serial number stacked underneath, RAM, disk, recipe, family (Client or Server, taken from the recipe's image), status, progress and last seen. Capped at 100 rows; the counter above the table only mentions the cap when the list is actually truncated ("Showing 100 of 243"), otherwise it just states the count.

Totals by make and model#

The same fleet counted rather than listed. Address: /reports/hardware, which is where the old Hardware tab's links land.

• Manufacturers - machine count and share per manufacturer
• Models - the 20 most common models with their manufacturer
• RAM distribution and Disk distribution - machine counts per size bucket

The roster's filter bar belongs to the device grain and does not apply to these totals, which is why they are a separate view rather than a panel under the table.

Storage (Core Only)#

Disk usage across images, drivers and ISOs, and - since 1.4.4 - across every relay site's own data drive. A breakdown bar leads, then one section per area, and every table ends in a total row - the question this tab is asked is "what is eating disk" and nobody should have to add a column up by hand.

Relay site disk#

One row per relay site, worst first, so a fleet of forty is scannable without opening any of them. Relays report their data drive on every heartbeat; Core projects what is committed on it against what is left.

Not reported is not zero. A relay older than 1.4.4 sends no storage at all, and Core shows that as "not reported" rather than drawing it as a full disk. Those rows sort above healthy sites and below failing ones: a gap in the data is worth knowing about, but it is not an emergency.

There is no image-cache size to configure. The cache uses the data drive chosen when the relay was installed, less what else is committed on it, so the figures here are facts about that relay rather than a number somebody typed. relay.json's MaxCacheSizeGB remains as an optional ceiling for an operator who wants one; 0 (the default) means "use the drive".

WIM Images and ISO Images are a row per item with its recorded size. Those libraries are small enough to read, so they stay a list.

Driver Packages are totals, not a roster. A real driver library is hundreds of packages, and a row each would bury the answer this page exists to give. Two cuts, side by side:

• By target - Deployment (Windows image) versus WinPE (boot media), the split that decides which build a package affects: WinPE drivers ride inside the boot image, the rest are injected with DISM during deployment. Both are always listed, including at zero, because "we have no WinPE drivers" is itself an answer.
• By manufacturer - biggest first. A package with no manufacturer recorded is grouped as Unspecified rather than dropped.

These are sizes, measured by walking each package's folder on disk, the same measurement the relay sync driver-size endpoint uses. A package whose folder cannot be read is counted and marked unmeasured rather than folded in as a zero that looks measured. Every row links into Drivers, which is the package-by-package list with filtering.

Relay Sites (Core Only)#

The one report about relay sites, complementing the Relay Sites page. Connected Cache used to be a tab of its own keyed on the same site, so one site occupied a row in each with the status repeated. A cache node is not a separate thing to report on: it is something a relay site is doing, so it is part of the site's row here. /reports/connected-cache redirects to this tab.

• Summary strip - total, online, unreachable, and how many relays are behind Core's version. When any site has a cache: Cache Running and Serving HTTPS, both out of the number of cache sites. Serving comes from a live probe of ports 80 and 443, not from what Core issued, because a node can be Running and provisioned and still serve nothing a client can use.
• Status across the fleet - breakdown bars
• Certificate authority consistency - one banner across the cache fleet. A client that cannot validate a node's issuer bypasses that cache silently and downloads from Microsoft instead, so a node whose issuer diverges from the rest is called out by name.
• Filters - search by site name, filter by site status, and (when any site has a cache) by cache state, including "Cache enabled" for every site that has one.
• Table - site name (linking to the site's dashboard) with its OS and group underneath, status, a Health cell (the same rollup the fleet page uses: the relay's reported health score, with an "outdated" note when its version is behind Core), synced image and driver counts, Connected Cache state, and one Last Activity cell holding both the last heartbeat and the last sync.

Connected Cache detail#

On a site that has a cache, the Connected Cache cell opens a detail row under it holding everything the Connected Cache tab used to show: cache size, the node certificate state (imported, and valid-to or expired), what the node is Serving on 80 and 443, who it is Served by (live) (the issuer the node actually presents, flagged when self-signed or expired), and when it last synced with Azure. It ends in a link to that site's cache settings.

Cache hit rate and bandwidth saved come from Azure's own Connected Cache monitoring, which FluxDeploy does not yet query.

Certificates (Core Only)#

Every certificate this system depends on, in one table, because they all fail the same way: silently, on a date nobody wrote down.

It used to be three stacked tables, and two of them - cache node certificates and relay HTTPS certificates - were both keyed on the relay site and both repeated Issuer, Expires and Status, so a single site had a row in each.

One row per owner. An owner is this server or a relay site, named once, however many certificates it holds. A site that has both a cache node certificate and its own HTTPS certificate is still one row, with the two certificates as aligned lines that read across the columns.

Sorting and filtering. The default sort is soonest expiry, so the whole fleet reads as one list of what needs attention first; a row sorts on its worst certificate, and a row with no dated certificate sorts last rather than first. Sort by name instead, search by owner, and narrow to Expiring or expired or Renewal failing.

The summary strip counts every certificate on the page - this server's HTTPS certificate, the certificate authority, each cache-node certificate and each relay HTTPS certificate - along with what is expiring within 30 days, what has already expired, and how many nodes have a renewal that keeps failing.

The cache node certificate verdict is rendered from the same component the Relay Sites tab uses, so the two views of one fleet cannot disagree about it.

Automatic renewal#

Cache-node certificates are issued for one year. FluxDeploy renews them automatically, by default 30 days before expiry - change that with the MccCertRenewalDaysBefore setting (clamped to 1-180 days).

Renewal asks the node for a new key and certificate request; the private key never leaves the node. The cache container is not stopped and keeps serving throughout. If a renewal attempt fails, FluxDeploy waits six hours before trying again rather than retrying on every heartbeat, and after three consecutive failures it raises a notification - a node that cannot renew will eventually stop serving Intune Win32 app content, which is worth knowing about while there is still time to fix it.

You are not notified simply because a certificate is approaching expiry. That is renewal working normally, and alerting on it would bury the message that matters.

History#

Every certificate issued or uploaded is recorded in the audit log - CERT_ISSUED when the organization CA signed one, MCC_CERT_UPLOADED when an admin supplied it. An issuance that failed is recorded too, as CERT_ISSUE_FAILED.

Navigation#

The old /machines and /devices addresses redirect to /reports. (/machines/{id} is still a machine's own detail page.)