Purview Audit / Unified Audit Log backend appears unhealthy for the tenant.

Hey—this error pattern usually points to a backend validation/mapping problem for the tenant’s Purview/Unified Audit Log ingestion context, not to mailbox access or basic tenant recognition.

Based on the provided docs, here are the key things to check and what they imply:

What the symptoms suggest

• In the Purview portal, Audit → Search fails with a generic “having trouble figuring out if activity is being recorded.”
• PowerShell Search-UnifiedAuditLog fails with HTTP BadRequest in Sync Search mode.
• The third-party integration fails with Microsoft.Office.Compliance.Audit.DataServiceException: Tenant <Tenant Number> does not exist.

Those specific failures are consistent with a situation where the Unified Audit Log / Purview audit search backend can’t find or validate the tenant in the audit-search service, even though:

• the tenant exists in Microsoft identity services (your OIDC discovery test passes),
• the tenant’s basic audit settings look enabled (AuditDisabled: False, AdminAuditLogEnabled: True, UnifiedAuditLogIngestionEnabled: True),
• the account can retrieve mailboxes,
• the Purview account shows Active.

Most likely categories (from the provided documentation)

1) Licensing / feature availability mismatch

The docs emphasize that audit/search and sign-in visibility depend on licensing and that some data isn’t available for some tenant types/editions.

From the provided documentation:

• Sign-ins are only available for Microsoft Entra ID P1 or P2.
• Data retention/visibility also varies by license tier (examples mention P1/P2 vs Free/Basic).
• Activity reports in Microsoft Graph require that the feature is licensed.

Even if you’re on “Microsoft 365 E3 assigned (trial)”, confirm what license the tenant actually has for the audit/search capability the third party is using (and not just what you intended to assign).

2) Audit log data isn’t available in the expected pipeline yet (latency / “no backfill”)

Your troubleshooting includes configuration being enabled, but it’s possible the data isn’t present yet or only becomes available after routing/configuration.

The docs note:

• For Microsoft Entra logs: there’s no backfilling—audit logs are available only from the time you configured routing.
• Latency may be expected and should be compared to documented latency windows.

So even with ingestion enabled, Purview search may fail if the backend doesn’t see expected ingestion events during the query window, or if ingestion isn’t truly flowing end-to-end.

3) Diagnostic/auditing infrastructure or export/config issues (Purview troubleshooting)

The Purview-focused troubleshooting article you provided lists common causes for auditing/diagnostics issues, including:

• Incorrect or insufficient permissions
• Misconfigured diagnostic settings / log profiles
• Role assignment issues (e.g., missing required roles like Log Analytics Contributor/Reader depending on what’s configured)
• Network connectivity / firewall
• Ghost/non-existent diagnostic settings
• Azure Diagnostics components disruption (DiagnosticsPlugin / MonAgentCore) for certain paths

Even though your case is “Unified Audit Log ingestion enabled,” this checklist is still relevant because Purview’s ingestion/search experience is sensitive to backend pipeline health and configuration consistency.

What you can tell the customer to do next (practical checks)

1. Confirm licensing for the exact audit/search capability
   • Verify the tenant is actually licensed for the relevant audit/search features (and not only that E3 is assigned “on trial”).
2. Try a broader date range and confirm whether any records exist
   • The docs emphasize latency and no backfilling for routed logs.
3. Validate auditing/diagnostics pipeline health
   • Check role assignments and diagnostic settings for the involved resources/targets.
   • Ensure there are no deprecated/legacy log profile issues.
   • Look for “ghost” diagnostic settings if applicable (the docs explicitly call this out for Azure Monitor diagnostic settings problems).
4. Collect evidence for support escalation
   • Purview portal error screenshot (Audit → Search)
   • PowerShell output for Search-UnifiedAuditLog (including full error text and exact date range)
   • Whether the third-party app is using Microsoft Purview / Unified Audit Log APIs and which endpoints/Graph calls it makes (so support can match the tenant validation step that says “does not exist”).

Follow-up questions (so we can narrow it down quickly)

1. For the trial, is the tenant actually licensed for Purview Audit Search/Unified Audit Log ingestion at the time the integration was attempted (and not just “E3 assigned (trial)” as shown in portal)?
2. What date/time window did you use for Search-UnifiedAuditLog when it failed?
3. Has any audit activity definitely occurred in that window (for the categories your third party queries)?
4. Is the third-party integration using Purview compliance portal audit search APIs or Microsoft Graph auditReports endpoints (and which one)?
5. Are there any diagnostic settings configured for auditing/exports in Azure Monitor / Purview-related resources, and do any of them target a workspace/storage with network restrictions?
6. Are there any guest identities / cross-tenant access involved (even indirectly) during onboarding?
7. Do you see the same “Tenant does not exist” error if you test with a different service principal/app registration?

Reference list (from the provided documents)

• Microsoft Entra audit logs in Azure Monitor (recommended steps, P1/P2 availability, no backfill, latency guidance): https://docs.microsoft.com/azure/active-directory/reports-monitoring/concept-activity-logs-azure-monitor
• Microsoft Entra Activity Logs Latency: https://docs.microsoft.com/azure/active-directory/reports-monitoring/reference-reports-latencies
• Learn about auditing solutions in Microsoft Purview (Audit solutions overview): https://learn.microsoft.com/purview/audit-solutions-overview
• Microsoft Entra audit logs API overview (license/feature availability concepts): https://learn.microsoft.com/graph/api/resources/azure-ad-auditlog-overview?view=graph-rest-1.0

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Hi @Rukmini

Practical checks...
1: I verified using azure CLI that license unit is consumed
2: I did and search always result to Failed to load data. Please try again later. and Sorry, we're having trouble figuring out if activity is being recorded. Try refreshing the page
3: azure diagnostic shows no error
4: uses graph because I checked in enterprise application that is actually created and I see the permissions included as given microsoft graph permissions

follow up questions:

1. few hours after
2. 1 day
3. did outlook email send, sharepoint site creation, onedrive upload
4. Microsoft Graph
5. Azure Monitor shows no result for diagnostic settings
6. no
7. I tried outlook, onedrive, and the original purpose (sharepoint), all returned with the same error, however different vendor succesfully integrated just fine

Hello @aolab

We will investigate the issue and update you with the findings. Thank you for your patience as we look into this.

Hi @Rukmini Thank you, I hope that there's a way to solve this.