You enrolled Windows Update for Business reports. The Azure workbook still says Waiting for Windows Update for Business reports data. Or the Microsoft 365 admin center Software Updates > Windows tab is blank. Or Log Analytics has no UCClient rows after two days. The usual first moves are to unenroll and re-enroll, raise telemetry to Optional on every device, or blame "Azure delay" forever.
Hold off. WUfB reports are a short chain: Azure subscription + workspace enrollment → viewer permissions → clients send Required (or higher) diagnostic data → devices are Entra joined/hybrid, supported edition, and active → data lands in UCClient (and related UC* tables) → workbook/M365 tab can draw it. Most "no data" tickets die in permissions, diagnostic policy, or devices that never send. This post walks them in order. Every step below only reads until the change table at the end.
If you need how to build rings, feature-update policies, or expedite a quality update, stop here and use the related posts linked at the bottom. Those cover shipping updates. This one assumes updates may already be flowing and you are debugging why the reports stay empty.
TL;DR
- Waiting for Windows Update for Business reports data usually means incomplete enrollment, wrong Log Analytics / Entra roles, or no clients sharing data — Microsoft documents checking those three before you loop unenroll/re-enroll.
- After a successful save, wait 48 hours for first rows; active online devices often appear within about 72 hours, less-active ones up to 14 days. Testing at hour 6 is a common false negative.
- Clients need at least Required / Basic diagnostic data (
AllowTelemetry≥ 1), plus recommended opt-in UX locks and Allow device name in diagnostic data if you expect names (not just IDs). - Proof of life is Log Analytics:
UCClient | summarize count() by TimeGenerated. Empty table = devices are not reporting (or enrollment never finished) — the workbook cannot invent rows. - Workplace-joined-only devices, Windows Server / Hub / IoT, and (currently) some Enterprise multi-session cases are out of scope for WUfB reports even when Intune looks healthy.
Where in the chain did it break?
| Step | What happens | Typical symptom when it breaks |
|---|---|---|
| 1. Azure enrollment | Subscription + Log Analytics workspace mapped; save succeeded | Never finished Configure Settings; 400 "resource already exists"; 403 on enroll |
| 2. Viewer permissions | Entra role that can enroll/view + Log Analytics Reader/Contributor on the workspace | You see Waiting forever; colleague with Contributor sees data; UCClient has rows you cannot open |
| 3. Client diagnostic policy | AllowTelemetry ≥ Required; opt-in UX locked; device name allowed if needed | Policy missing/Pending; users lowered telemetry; device name shows as null(#) |
| 4. Device eligibility + activity | Entra joined or hybrid; supported Win10/11 Pro/Edu/Ent; online + scanned recently | Workplace join only; Server/IoT; powered off for weeks; no Microsoft Update scan |
| 5. Connectivity / OneSettings | Diagnostic and WU endpoints reachable; services not disabled | Proxy/firewall blocks *.events.data.microsoft.com / settings-win.data.microsoft.com; DisableOneSettingsDownloads |
| 6. Evidence in Log Analytics |
UCClient (and alerts) ingest daily |
Workbook empty and UCClient empty; or UCClient has data but workbook blank (role) |
| 7. Missing-device alerts |
DeviceDiagnosticDataNotReceived / MinimumOSBuildNotMet explain gaps |
Fleet partially visible; KPI Missing devices lists the same GUIDs |
Sample a pilot group you can walk to (or RDP) before you change tenant-wide telemetry. If three lab devices populate UCClient and production does not, the problem is assignment or network — not the workbook.
Step 1: Read enrollment state and the Waiting message
Microsoft's FAQ lists three usual causes for Waiting for Windows Update for Business reports data:
- You do not have the correct permissions to display the data.
- Initial enrollment is not complete yet (setup can take up to 24 hours after save).
- Devices are not sharing data (after 48 hours with a successful save, run the configuration script / verify client policy).
Read-only checks:
| Surface | What to confirm |
|---|---|
| Azure workbook for WUfB reports | Enrollment completed; subscription + workspace still selected |
| Microsoft 365 admin center > Health > Software Updates > Windows | Same workspace mapping; Waiting vs blank vs partial |
| Azure Activity / your change ticket | Who enrolled, when, which workspace resource ID |
If you see 400 Bad Request: The specified resource already exists, the service already has a subscription/workspace mapping. Microsoft's guidance: wait a few minutes, refresh, and do not hammer Save. Unenroll/re-enroll is a last resort and costs another 24–48 hours.
If you see 403 while enrolling, confirm you hold an enroll-capable role (Intune Administrator, Windows Update deployment administrator, or Intune Policy and profile manager where applicable) plus the right Azure RBAC on the workspace. Intune RBAC alone does not grant Microsoft 365 admin center access.
Step 2: Separate "no permission to see data" from "no data exists"
| Role combination (examples from Microsoft's matrix) | Enroll | Display workbook | Notes |
|---|---|---|---|
| Intune Administrator + Log Analytics Contributor | Yes | Yes | Can create workspace |
| Windows Update deployment administrator + Log Analytics Reader | Yes | Yes | Cannot create workspace |
| Log Analytics Reader only | No | Yes | Fine for viewers once data exists |
| Global Reader + Log Analytics Reader | No | Yes | M365 center access; no enroll |
If your account sees Waiting but a teammate with Log Analytics Reader on the same workspace sees devices, fix RBAC — do not recreate policies.
If nobody sees data and UCClient is empty (Step 6), permissions are not the story.
Step 3: Read the Intune diagnostic configuration profile
WUfB reports need clients to send diagnostic data at least at the Required level (formerly Basic). In Intune, Microsoft documents a Settings catalog profile (System category) or a Custom OMA-URI profile.
Settings catalog (preferred read)
In Intune admin center > Devices > Windows > Configuration profiles, open the profile you intended for WUfB reports and confirm:
| Setting (System) | Want for reports | If wrong |
|---|---|---|
| Allow Telemetry | Basic / Required or higher | 0 / Security / disabled — no report payload |
| Configure Telemetry Opt In Settings Ux | Disabled (recommended) | Users can lower telemetry under the floor |
| Configure Telemetry Opt In Change Notification | Disabled (recommended) | Noise; not usually the empty-table cause |
| Allow device name to be sent in Windows diagnostic data | Allowed (if you need names) | Device ID present, name shows as null(#) for up to ~21 days after fix |
Assignment must hit the devices you expect (device groups for device-scoped System settings). Profile status Succeeded on a pilot device is not the same as "already in the workbook" — ingestion still lags.
Custom OMA-URI equivalents (read-only)
| Purpose | OMA-URI | Integer want |
|---|---|---|
| Allow Telemetry (Required minimum) | ./Vendor/MSFT/Policy/Config/System/AllowTelemetry |
1 or higher |
| Lock opt-in UX | ./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx |
1 |
| Allow device name | ./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData |
1 |
| Opt-in change notification | ./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInChangeNotification |
1 |
On a pilot device, after sync, confirm the effective CSP / registry story matches the profile before you raise telemetry tenant-wide. If GPO sets a lower diagnostic ceiling, Intune Succeeded can still lose.
Also remember: Intune Windows update compliance reports are a different product with different prerequisites. Device counts will not match WUfB reports 1:1 even when both are healthy.
Step 4: Confirm device eligibility and activity
From Microsoft's prerequisites and FAQ:
| Requirement | Healthy | Common miss |
|---|---|---|
| Join | Microsoft Entra joined or hybrid joined | Microsoft Entra registered only (workplace join) — not supported |
| Edition | Win10/11 Pro, Education, Enterprise (desktop client) | Windows Server, Surface Hub, IoT — not compatible |
| Multi-session | Known issue: Enterprise multi-session may not display | AVD / multi-session fleets look "missing" |
| Servicing CU | Feb 2023 cumulative (or later equivalent) for diagnostic processor changes | Very stale images fail MinimumOSBuildNotMet-style checks |
| Activity | Powered on, internet, scanned Microsoft Update; seen in last ~28 days | Laptops in drawers never appear; "unknown" update state |
On one missing device (authorized):
dsregcmd /status
Read AzureAdJoined / DomainJoined (hybrid) and that you are not workplace-join-only. Then confirm the device can reach Windows Update and has been interactive recently.
Step 5: Connectivity, OneSettings, and the configuration script
Devices must reach the diagnostic and Windows Update endpoints Microsoft lists for WUfB reports (examples include *v10c.events.data.microsoft.com, settings-win.data.microsoft.com, login.live.com, and the Watson/OCA endpoints — use the current Learn table for EU Data Boundary hostnames). Proxy SSL inspection and "block telemetry" firewall rules are frequent silent killers.
DisableOneSettingsDownloads (services configuration / OneSettings) can leave client data incorrect or missing. If a hardening baseline turned it on, read that before blaming AllowTelemetry.
Microsoft's Windows Update for Business reports configuration script is optional for Intune-configured fleets but useful as a pilot troubleshooting tool: it checks required services and endpoint connectivity and writes local logs. Deploy it as a Win32 app to a few devices you can access; do not treat a fleet-wide silent deploy as proof until you can read those logs.
Step 6: Prove ingestion with UCClient (and related tables)
In the enrolled Log Analytics workspace:
UCClient
| summarize DeviceCount = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated desc
| Result | Meaning |
|---|---|
No UCClient table / zero rows after 48+ hours |
Enrollment incomplete or no configured active devices are sending |
| Rows appear, workbook still Waiting/blank | Almost always Log Analytics Reader (or equivalent) missing for the signed-in user |
| Rows for some DeviceIds, not others | Client policy, join, network, or activity on the missing set |
Useful follow-ups (read-only):
// One device by Entra device ID
UCClient
| where AzureADDeviceId has "01234567-89ab-cdef-0123-456789abcdef"
// Alert subtypes for missing diagnostic / build prerequisites (when present in your workspace)
UCDeviceAlert
| where AlertSubtype in ("DeviceDiagnosticDataNotReceived", "MinimumOSBuildNotMet")
| project DeviceName, AzureADDeviceId, AlertSubtype, StartTime, Description, Recommendation
| take 50
Table cheat sheet:
| Table | Use when |
|---|---|
UCClient |
One row per device; overall presence / OS build / compliance-style fields |
UCClientUpdateStatus |
Per-update history (multiple rows per device) |
UCUpdateAlert |
Actionable update failures / recommendations |
UCDeviceAlert |
Device-level gaps such as diagnostic-not-received |
Default workbook views often cap around 1000 rows — "I cannot find this device in the grid" is not the same as "not in Log Analytics." Export or open the query blade before you reconfigure the fleet.
Step 7: Missing devices vs null names vs Unknown state
| Symptom | Prefer reading | Usually not |
|---|---|---|
| Entire workbook Waiting | Steps 1–2, then UCClient
|
Rewriting every update ring |
| Some devices missing | Join type, telemetry profile assignment, activity, endpoints, UCDeviceAlert
|
Raising telemetry to Optional on healthy devices first |
| Device ID present, name null(#) |
AllowDeviceNameInDiagnosticData (+ up to ~21 days) |
Re-enrollment of WUfB reports |
| Update state Unknown | No recent update record / inactive / cannot scan WU | Immediate unenroll |
| DO data Unknown | Delivery Optimization DownloadMode empty/invalid | Diagnostic AllowTelemetry (different column) |
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Enrollment saved < 24–48 hours ago | Wait; re-check UCClient daily |
Unenroll/re-enroll every afternoon |
| You lack Log Analytics Reader; teammate sees data | Grant Reader on the workspace | Recreating the Intune telemetry profile |
| AllowTelemetry missing / Security-only | Assign Settings catalog Required+ to a pilot group | Tenant-wide Optional "just to be sure" on day one |
| Users can lower telemetry | Set Configure Telemetry Opt In Settings Ux = Disabled | Fighting per-user Settings clicks |
| Names null(#) | Allow device name in diagnostic data; wait | Wiping devices for a display name |
| Workplace-join only | Move to Entra join / hybrid join if reports are required | Expecting WUfB reports to invent support |
UCClient empty after 48h + policy Succeeded |
Config script on 3 pilots; endpoint/proxy review | Blind unenroll as first fix |
| Need ring/expedite process, not reporting | Use rings / feature-update / expedite articles + patch pack | Treating empty reports as proof updates are not installing |
FAQ
Why does the page say Waiting for Windows Update for Business reports data?
Microsoft documents three causes: permissions, enrollment not finished yet, or devices not sharing data. Confirm save time, your Log Analytics role, and UCClient before you change policies.
How long until first data?
Initial enrollment display can take up to 24 hours. After clients are configured, wait about 48 hours for first ingestion; active devices often fully show within about a week (commonly under 72 hours); less-active devices can take up to 14 days.
Intune shows the device compliant and syncing — why is it missing from WUfB reports?
MDM sync ≠ diagnostic upload into the WUfB pipeline. Confirm AllowTelemetry, join type, endpoints, and UCClient. Intune update compliance reports are separate and will not match counts.
Why is the device name null(#)?
Allow device name in Windows diagnostic data is not enabled (CSP System/AllowDeviceNameInDiagnosticData or the matching GPO). After you enable it, Microsoft notes it can take up to 21 days for names to backfill on active devices.
UCClient has data but the workbook is empty — what now?
Grant the signed-in user Log Analytics Reader (or higher) on that workspace. Contributor is only required to edit queries/workbooks or create the workspace.
Related posts
- Windows Update rings for Intune pilots — pilot vs broad, deferrals, and why "minimum OS" compliance fails first
- Intune feature updates - ring deferral vs a Feature updates policy vs Windows Autopatch (which one actually controls the version?)
- Expedite a Windows quality update in Intune - prerequisites, the real timeline, and why "expedite" sometimes does nothing
- Company Portal can't connect / device not syncing — a 10-minute triage order for Intune admins
Free checklist
Empty update reports often show up in the same week you tighten Conditional Access or compliance before enforcement. Before you flip related identity controls, the free Conditional Access pre-enforcement checklist keeps break-glass, pilot groups, and report-only review on one page:
If you want the broader ring topology, Patch Tuesday runbook, pause/rollback habits, and break/fix cards that sit next to healthy reporting, the Windows Update Rings & Patch Ops Pack pairs with this triage: https://cashflow4375.gumroad.com/l/windows-update-rings-patch-ops-pack?utm_source=hashnode&utm_medium=article&utm_campaign=aps_first_sale&utm_content=windows-update-for-business-reports-no-data
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 only read. Pilot any telemetry or enrollment change on a scoped group first, and check current Microsoft docs for WUfB reports prerequisites, endpoints, and Kusto table names.
Top comments (0)