Why Is OfficeActivity in Sentinel but Not in Defender XDR? The Layer Question Behind the Table Name

A security engineer went looking for the OfficeActivity table in Microsoft Defender XDR advanced hunting and could not find it, while the same table was available in Microsoft Sentinel. The recollection was that this data used to be queryable in Defender, which raised the obvious follow-up: had Microsoft moved or removed something?

The question looks like a missing-table problem. It is worth taking seriously precisely because both products speak KQL and both show data about the same mailboxes, sites and users. When two consoles look that similar, a difference in table names reads as an inconsistency rather than as a boundary.

The responses moved quickly from the table to the products behind it. The recurring point was that Defender XDR and Sentinel are not competing tools: Defender XDR is an extended detection and response platform focused on Microsoft workloads such as endpoints, identity, email and cloud apps, while Sentinel is a cloud-native SIEM and SOAR platform that collects from effectively any source, supports custom detections, playbooks, automation and long-term retention.

A second thread pointed out that OfficeActivity in Sentinel is a subset of the Microsoft 365 Unified Audit Log rather than a one-to-one copy, which explains why some searches return less than expected.

A third thread turned to cost. Several participants argued that the Unified Audit Log is simply too large to push into a SIEM wholesale, and that cheaper storage plus occasional retrieval is the more sensible pattern. Others pushed back, arguing customers should be able to decide for themselves which audit logs land where.

Running underneath all of this was a complaint about inconsistent schemas: Defender uses Timestamp where Sentinel uses TimeGenerated, and device identity appears as DeviceName, Computer or Hostname depending on where you look. ASIM came up as the intended answer, with the consensus that it helps but does not remove the underlying problem.

The documentation resolves the original question in a way the thread does not. Office 365 activity is available in Defender XDR advanced hunting — it sits in the CloudAppEvents table, which contains events involving accounts and objects in Office 365 and other cloud apps. In the Microsoft Purview DLP guidance the same table is described as containing audit logs across locations including SharePoint, OneDrive, Exchange and devices.

There is a prerequisite, and it is the likely reason the table looked empty or absent: CloudAppEvents is populated by Microsoft Defender for Cloud Apps. If that service is not deployed in Defender XDR, queries against the table return nothing. Population also requires the Microsoft 365 activities checkbox under Settings, Cloud apps, App connectors.

On the Sentinel side, the OfficeActivity table reference describes it as audit logs for Office 365 tenants, including Exchange, SharePoint and Teams logs. That is the shape of the subset the thread noticed: it is what the Microsoft 365 connector collects, not an arbitrary sample of the Unified Audit Log.

The cost argument deserves a correction. The Sentinel billing documentation lists Office 365 audit logs among the free data sources, including all SharePoint activity, Exchange admin activity and Teams, and names OfficeActivity (SharePoint), OfficeActivity (Exchange) and OfficeActivity (Teams) explicitly as free data types. Ingestion cost is therefore not what limits this particular table. The same page draws the line that does matter: alerts from Defender XDR and the Defender products are free, while the raw logs behind several of those data types are paid.

On normalisation, ASIM parses and normalises at query time. Parsers are KQL user-defined functions that transform existing tables into a normalised schema, and they are built into every Sentinel workspace. You query the parser instead of the table name.

The most useful correction here is that nothing is missing. Office 365 audit data exists on both sides of the boundary, under two names, collected by two different mechanisms, for two different jobs. CloudAppEvents reaches Defender XDR through Defender for Cloud Apps and serves investigation inside the Microsoft estate. OfficeActivity reaches Sentinel through the Microsoft 365 connector and serves correlation across everything else. A team that concludes "Defender cannot do this" will build a workaround for a problem it does not have.

"The table name is not an inconsistency to be fixed. It tells you which layer you are standing in."

That reframing changes what the schema complaint means. Timestamp versus TimeGenerated is not two teams disagreeing about a column name. TimeGenerated is the Log Analytics ingestion-time column that every table in a workspace carries, because Sentinel inherits the platform underneath it. Timestamp is an event property in the advanced hunting schema. The difference is a consequence of the storage layer, which is also why it will not simply be harmonised away.

ASIM is the right tool for this and it is worth being precise about what it buys you. Because parsing happens at query time as KQL functions, ASIM does not restructure stored data and costs nothing at ingestion; it also means a query written against a parser keeps working when a new source is added behind it. What it does not do is give the two portals one shared taxonomy. Normalisation is a query-time convenience, not a merge of the two models, which is exactly why the thread's verdict — helps, does not solve — is accurate.

The cost correction has a real design consequence. Because the three big OfficeActivity workloads are free, the usual reflex of holding audit data out of the SIEM to protect the budget is aimed at the wrong target here. The expensive decision in this estate is not Office 365 audit data; it is raw Defender logs, which are paid where the alerts are free. That is the trade-off worth spending an architecture conversation on: alerts and incidents into Sentinel for correlation, raw device and mail telemetry queried in place through advanced hunting unless there is a specific reason to duplicate it.

Which leaves a practical routing rule. If the question is "what happened to this mailbox, this device, this identity, inside Microsoft 365", it belongs in Defender XDR, where the data is already correlated into incidents and querying it costs nothing extra. If the question spans sources Microsoft does not own — firewall, network, a non-Microsoft identity provider, another cloud — or needs retention beyond the advanced hunting window, custom analytics rules or an automated response, it belongs in Sentinel. Most enterprises need both, and the mistake is not choosing wrong; it is assuming one of them should have made the other unnecessary.