Skip to main content

📊🪟 WUfB Reports - Setup

What this page is for 📊​

Not a policy. The setup guide for Windows Update for Business Reports, the Azure-side surface that turns your Update Ring policies into something you can actually look at. 👀

Without WUfB Reports, the rings are silent. Devices are getting updates, deferrals are being respected, deadlines are being enforced. And you have no way to see any of it short of running gpresult /h on individual devices like it's 2011. With WUfB Reports, all of that lights up in Azure Log Analytics with dashboards, queries, and alert rules.

This page covers the prerequisites and the onboarding flow. The Microsoft documentation walks through the click-by-click. What you'll find here is the MKB-specific shape of the work and the gotchas that aren't in the official guide. The kind of stuff you only learn after onboarding tenant number seven. 🎓

What WUfB Reports gives you 🎯​

Once onboarded, every device in the tenant reports update state into a Log Analytics workspace. The reports surface:

  • Update compliance per ring. How many Fast devices have last month's quality update. How many Production devices are still behind. Who's stuck.
  • Time-to-install distribution. How long it actually takes a quality update to reach 95% of devices per ring.
  • Driver installation state. Which devices got which approved drivers. Which are still pending.
  • Failures and rollbacks. The small percentage of devices that failed an install or rolled back, with error codes you can actually search.
  • Active alerts. Pre-built alert rules that fire when a device fails the same update three times, or when a ring's compliance falls below threshold.

This is the signal the rings produce. Without onboarding, the rings still work. You just can't see them working. Which is fine until someone asks "are we patched?" and you have to say "probably." 😬

Prerequisites​

Before onboarding, confirm:

  1. AllowTelemetry = Required on all reporting devices. The hard floor. See ⚙️🪟💻CP - Reporting & Updates - Diagnostic Data. Devices below Required will not appear in the reports.
  2. AllowDeviceNameInDiagnosticData = Allowed. Without it, devices show up as opaque IDs instead of names. Operationally useless. Same Diagnostic Data policy covers this.
  3. An Azure subscription in the tenant. WUfB Reports lives in Log Analytics, which requires an Azure subscription. Business Premium does not include one. The customer needs an active pay-as-you-go or other Azure subscription (the spend for WUfB Reports specifically is minimal, see Cost below).
  4. A Log Analytics workspace in a supported region. As of late 2025 the supported regions include the major EU, NA, and APAC regions. EU customers should pick an EU region (West Europe / North Europe / Sweden Central) for GDPR comfort. Telemetry stays in the chosen region. 🇪🇺
  5. Microsoft Entra global reader or workspace contributor permissions on the user running onboarding.

Onboarding flow​

The clicks happen in three places: Azure Portal, Microsoft Update Admin Center, and Intune. Order matters.

1. Create the Log Analytics workspace (Azure Portal)​

  • Resource group: a dedicated one for management telemetry (rg-wufb-reports or similar)
  • Region: pick the one the tenant data is allowed to live in
  • Pricing tier: Pay-As-You-Go (per-GB). WUfB Reports data is small. Typically under 100 MB per device per year, even on a chatty fleet.

2. Add the WUfB Reports solution to the workspace​

  • In the workspace: Solutions → Add → WaaSUpdateInsights (the marketplace name for the solution)
  • Wait for the solution to deploy (~10 minutes)

3. Enroll the tenant in the Microsoft Update Admin Center​

  • Sign in at https://aka.ms/mucadmin
  • Configure → Microsoft 365 admin center delegation
  • Link the Log Analytics workspace from step 1
  • Accept the agreement (the customer's Azure tenant admin needs to do this once)

4. Configure the Intune side​

  • Microsoft Intune admin center → Reports → Windows updates → Windows Update for Business reports
  • Confirm the workspace shows up as linked
  • Toggle the "Allow data sharing with Microsoft Update for Business" setting On

5. Wait​

First-time data ingestion takes 24 to 72 hours. Don't panic if the dashboards are empty the same day. Compliance numbers stabilize about a week in once enough devices have reported in. Go have lunch. 🥪

Cost expectations 💰​

WUfB Reports per-device telemetry is small. For a typical MKB tenant:

  • ~50 devices, 1 year of reporting: under 5 EUR/month in Log Analytics ingest cost
  • ~300 devices, 1 year of reporting: under 25 EUR/month
  • The data retention default is 31 days. Keeping 90 days is fine and rarely doubles the cost.

Compare to the operational cost of not knowing whether updates are landing. Easy win. 🏆

Dashboards and queries​

The WaaSUpdateInsights solution ships with pre-built workbooks under Log Analytics → Workbooks:

  • Quality Updates. Per-device install state, time-to-install percentiles.
  • Feature Updates. Same shape, longer cadence.
  • Drivers. Per-driver install state across the fleet.
  • Devices. Per-device detail, drill-through from any other workbook.

For custom queries the underlying tables are UCClient, UCUpdateAlert, UCDeviceAlert, UCDOAggregatedStatus and friends. KQL syntax. An MSP-side dashboard that surfaces "which tenant has the most non-compliant devices this week" is one or two queries, not a project. 📈

Caveats ⚠️​

Not a substitute for compliance reporting. WUfB Reports tells you whether updates landed. It does not tell you whether devices are compliant with the security baseline. Pair this with Intune compliance reporting for the full picture.

Per-tenant onboarding. No multi-tenant view by default. An MSP running 30 tenants needs to either onboard each tenant individually (correct but tedious), or centralize ingest in an MSP-owned workspace via Azure Lighthouse (more setup, scales better). The decision is operational, not technical.

Don't expose the workspace to the customer admin by default. WUfB Reports surfaces device names and update state. Some customers consider that operational data they want access to; some consider it MSP-internal noise. Default to MSP-internal. Expose explicitly on request.

Workspace deletion is destructive. If a customer offboards, the Log Analytics workspace can be archived or deleted. Archived is safer for the first month post-offboarding in case the customer needs to look something up. Deleting it is irreversible, and "irreversible" tends to look bad in a postmortem. 🗑️

💡 SuperVision tip​

This is operational infrastructure, not policy. SuperVision should:

  • Track which tenants have WUfB Reports onboarded (binary: yes / no)
  • Flag tenants where Required telemetry is configured but onboarding is not done (= rings are silent for no good reason, fix it)
  • Surface "ring compliance below threshold" alerts from Log Analytics into the SuperVision dashboard for the operator on shift

The onboarding itself is one-time per tenant. The value is in the queries you run afterwards. 🔁

🔗 Related​

Configure once. Monitor forever. And remember: a ring you can't see is a ring you can't trust. 🔭