Skip to main content

O-365 Login Data Not Populating

Summary

Microsoft has an ongoing Microsoft 365 service degradation, tracked as MO1481173, in which usage reports in the Microsoft 365 admin center and the Graph Reports API are delayed, incomplete, or failing. Cloud Access Monitor (CAM) pulls two of those usage reports during its Microsoft 365 login sync. When Microsoft's report call failed, the whole login sync run failed, and the run was left marked as still running, so no further Microsoft 365 sign-in data was collected for that tenant until the service was restarted.

ManagedMethods has shipped a fix so that a usage-report failure no longer stops sign-in collection. The fix is merged and in the current staging release. Until Microsoft fully restores its reporting pipeline, the Microsoft 365 usage figures in CAM may still lag; sign-in data is not affected once the fix is deployed.



What Microsoft announced

Microsoft 365 service health advisory MO1481173, "Admins may see multiple usage reports not updating in the Microsoft 365 admin center", has been open since 28 September 2026 and was still in progress as of Microsoft's 23 October 2026 update. Microsoft classifies it as a service degradation of the Microsoft 365 suite and Microsoft Teams.

Microsoft's stated root cause is an upstream process that manages user data and cannot process it as efficiently as expected, which delays the usage reports that depend on it. Microsoft reports that an infrastructure migration also produced corrupt file formatting in the reporting pipeline, and that a fix is being deployed but is "taking longer than expected" because of the volume of data requests.

Reports

Status per Microsoft

Microsoft 365 Apps Active Users, Overview, Forms

May show no data since 6 October 2026

Mailbox usage, Teams user activity, Microsoft 365 Group reports

Recovered 15 October 2026

Adoption Score, Multi-geo, Active user, Email Activity, Email Apps usage, Microsoft 365 Apps usage

Recovered 12 October 2026

These same reports back the Microsoft Graph Reports API (the reports/getOffice365ActiveUser* endpoints), so any product that reads them, including CAM, can receive delayed, empty, or failed responses while the advisory is open. Timeline details above are from Microsoft's updates as mirrored by Cloud Admin Hub; the authoritative record is the Service health page in the Microsoft 365 admin center.



How this affects Cloud Access Monitor

The visible symptom is Microsoft 365 sign-in data stopping for an affected tenant, even though the tenant's Microsoft 365 connection is healthy and other syncs (files, users, apps) continue. A secondary symptom is stale Microsoft 365 usage figures.

Customers with an affected tenant may notice:

  • Login Analyzer shows no new Microsoft 365 sign-ins after a certain date.

  • Accounts page "last login" time and IP for Microsoft 365 users stop updating.

  • Login-based policies (unusual location, blocked country, suspicious sign-in, and similar) stop generating new violations and email digests for Microsoft 365.

  • Summary tab active-user and Microsoft 365 usage graphs stop at an older date or show gaps.

Why it happens: CAM's Microsoft 365 login sync runs on a schedule. In one run it fetches the tenant's Entra ID sign-in events, then calls two Microsoft Graph usage reports (active user counts and active user details for the last 7 days), then checks licensing and saves the sign-ins. Before the fix, a failure from the usage-report call (for example a connection reset or timeout, which is what Microsoft's degraded reporting pipeline returns) raised an error out of the whole run. Two things then went wrong:

  1. The sign-ins already fetched in that run were discarded before they were saved.

  2. The run's "in progress" flag was never cleared, so every later scheduled run for that tenant was skipped as "already running" until the CAM service was restarted.

The longer a tenant stayed stuck, the larger the backlog of sign-ins to catch up on. CAM caps a catch-up at 29 days because Microsoft only serves 30 days of sign-in history. Fetching several weeks of sign-ins as one query could itself time out on Microsoft's side, which is why a second change (below) breaks the catch-up into one-day slices.



What ManagedMethods changed

Change 1: a usage-report failure no longer stops sign-in collection. The login sync now treats the two Graph usage reports as best effort. If either report fails, the error is logged, the sign-ins already fetched are still saved and evaluated against policies, and the run finishes normally. The "in progress" flag is now always cleared at the end of a run, whether it succeeded or failed, so one bad run can no longer block all later runs. Inside the report step, a failure of the active-user-counts report no longer skips the active-user-details report, so CAM collects whichever of the two Microsoft can serve. A unit test covers the connection-reset case.

Change 2: large catch-ups are fetched one day at a time. Once a stuck tenant is unblocked, the first run has to fetch up to 29 days of sign-ins. The follow-up change splits that window into one-day slices, oldest first. Each slice is fetched, saved, its sync watermark advanced, and its sign-ins evaluated against policies before the next slice is requested. If a slice fails, the run stops there and the next scheduled run resumes from the last saved slice, so no window is ever skipped and nothing is held in memory beyond one day of sign-ins. Daily login tables are rebuilt once at the end of a multi-slice catch-up, and the login violation email digest is sent once per run rather than once per slice. The license check for Entra ID P1/P2 now happens before fetching, so tenants without it skip the sign-in call entirely. A normal run's window (the scheduler interval plus a 30-minute overlap) still fits in a single slice, so day-to-day behaviour is unchanged.


What customers need to do

No action is required from customers. The fix is applied on the CAM service side and does not change the Microsoft 365 connection, permissions, or any customer settings.

What to expect once the fix is deployed to your CAM instance:

  • Sign-in collection resumes on the next scheduled login sync for each Microsoft 365 tenant.

  • CAM backfills the gap, up to the 29 days of history Microsoft retains. A large backfill arrives over several sync runs rather than all at once.

  • Policy evaluation runs on the backfilled sign-ins, so a burst of older-dated login violations and digest emails is possible during the catch-up.

  • Microsoft 365 usage figures (active-user counts and 7-day activity) continue to depend on Microsoft's reporting pipeline and may stay stale or show gaps until Microsoft closes MO1481173.

If Microsoft 365 sign-ins are still not updating more than a day after your instance has been updated, contact ManagedMethods Support with your tenant domain and the date sign-ins stopped.



FAQ

Is my Microsoft 365 data at risk, or was anything missed permanently? No data is at risk. Sign-ins that were not collected during the outage are still held by Microsoft for 30 days and are backfilled once the fix runs. Sign-ins older than that at the time of the fix cannot be recovered from Microsoft.

Does this affect Google Workspace? No. The Google Workspace login sync already caught report failures separately, and Microsoft's advisory is specific to Microsoft 365 reporting.

Why did only some Microsoft 365 tenants stop? Microsoft's degradation affected tenants unevenly, with "varying delays". A tenant was only stuck if one of its usage-report calls actually failed during a login sync.

Do I need Entra ID P1 or P2? Yes, as before. Microsoft only exposes sign-in events through the Graph API to tenants with an Entra ID P1 or P2 licence. Tenants without it never had sign-in data in CAM, and that has not changed.

Will CAM's usage graphs be wrong while Microsoft is still fixing reports? They may show gaps or stop at an older date. CAM stores whatever Microsoft serves; once Microsoft backfills its reports, the next sync picks up the corrected 7-day figures.

Who do I contact? ManagedMethods Support at [email protected].

Did this answer your question?