How to Connect Microsoft 365 Logs to Microsoft Sentinel

Short answer: verify Microsoft Purview auditing first, then open the Microsoft 365 data connector in Microsoft Sentinel, select only the Exchange, SharePoint and Teams activity you need, connect the same-tenant source, generate a harmless test event and prove ingestion with an OfficeActivity query. The connector is not finished until each selected workload produces recent events and an owner has reviewed retention and downstream detections.

This guide is the practical follow-on to the site’s Microsoft Sentinel vs Splunk for Microsoft 365 logs comparison. It covers Microsoft 365 audit activity in the OfficeActivity table. Microsoft Entra sign-in logs, Defender XDR raw events and Azure activity logs use different connectors and tables.

What the Microsoft 365 connector collects

The Microsoft 365 connector, formerly called the Office 365 connector, sends supported audit activity for Exchange, SharePoint, OneDrive and Teams into the Sentinel workspace. The destination table is OfficeActivity. Its documented fields include TimeGenerated, OfficeWorkload, Operation, UserId and workload-specific fields.

The OfficeActivity schema reference is the source of truth when a KQL field used by an older blog post no longer exists.

Prerequisites, roles and cost boundaries

Microsoft currently lists Microsoft 365 Office audit data as a no-charge Sentinel data source for SharePoint activity, Exchange admin activity and Teams. That does not make the whole workspace free. Entra raw logs, some Defender data, retention beyond included periods, Logic Apps, Functions and other connectors can be billable. Use the current Sentinel billing model rather than a hard-coded per-GB figure.

1. Define the collection and validation plan

Write down what the connector must prove before touching it. A useful pilot has one test user, one SharePoint test site, one Teams test team and an approved Exchange administrative action. Do not generate test records in a production mailbox or team that users depend on.

• Workloads: Exchange, SharePoint and Teams.
• Destination: the named Sentinel workspace and subscription.
• Expected table: OfficeActivity.
• Test window: a recorded UTC start and end time.
• Success: at least one recent, attributable record from every selected workload.
• Rollback: disconnect the source without deleting the workspace or turning off tenant-wide auditing.

If this is a portfolio lab rather than a business deployment, the site’s system administration project guide shows how to turn the connector, queries and recovery notes into evidence without publishing tenant identifiers.

2. Verify Microsoft Purview auditing

Open Exchange Online PowerShell with an account authorised to read the audit configuration and run:

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

A value of True confirms that audit ingestion is enabled. Microsoft warns that running the same cmdlet from Security & Compliance PowerShell can show the property as false even when auditing is active, so use Exchange Online PowerShell for this check.

If it is disabled, an account with the Exchange Online Audit Logs role can start recording from the Microsoft Purview Audit page or run the documented command below. Enabling it is a tenant-wide logging change, so obtain approval and record who authorised it.

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Microsoft says enablement can take up to 60 minutes and audit events can take several hours to become searchable. The Purview audit enablement guide documents both the role and the SMB default.

3. Confirm the Sentinel workspace and access

1. Open Microsoft Sentinel in the Microsoft Defender portal if the workspace has been onboarded to the unified experience, or use the Azure portal experience currently associated with the workspace.
2. Confirm the exact subscription, resource group and Log Analytics workspace name.
3. Use Advanced hunting in the Defender portal, or Logs in the Azure portal. A small query such as print QueryTime = now() checks the query interface without searching every table; use the scoped OfficeActivity checks below to validate actual source access.
4. Confirm the change account has workspace read and write permissions plus the tenant’s Security Administrator role or equivalent.
5. Record the current pricing tier, daily ingestion and table-retention settings before connecting a new source.

Microsoft has announced that Sentinel support in the Azure portal ends after 31 March 2027. That date is not a reason to delay a 2026 connector, but new documentation and menu labels increasingly lead through the Defender portal. Use Microsoft’s current connector reference when the gallery location differs.

4. Open the Microsoft 365 data connector

1. First ensure the solution containing the Microsoft 365 connector is installed from Content management > Content hub. If needed, have an authorised Microsoft Sentinel Contributor install it in this workspace.
2. In the Defender portal, open Microsoft Sentinel > Configurations > Data connectors. In the Azure portal, open Configuration > Data connectors.
3. Search for Microsoft 365. Some older interfaces and documentation call it Office 365.
4. Select the Microsoft-supported connector and open its connector page.
5. Read the prerequisite and status panels before selecting a workload.
6. Confirm the displayed tenant is the Microsoft 365 tenant that owns the audit data.

Microsoft’s data-connector setup procedure requires the relevant solution to be installed before configuring its connector. The Content hub guide documents the resource-group role. The API-based Microsoft service procedure then requires read/write workspace access, Security Administrator or equivalent tenant permission, and the same-tenant relationship for Microsoft 365.

5. Select workloads deliberately and connect

Select the Exchange, SharePoint and Teams workloads required by the test plan, then use the connector’s apply or connect action. Do not add every nearby Microsoft connector because it shares a brand name. Each extra connector changes tables, permissions, cost and incident behaviour.

• Microsoft 365 connector: activity records in OfficeActivity.
• Microsoft Entra ID connector: directory audit and sign-in tables such as AuditLogs and SigninLogs; sign-in ingestion requires Entra ID P1 or P2.
• Microsoft Defender XDR connector: incidents, alerts and selected advanced-hunting tables.

Save the change record with the selected workloads, administrator, UTC timestamp and destination workspace. If the connector page reports an error, stop and resolve the permission or audit prerequisite rather than repeatedly reconnecting.

6. Generate harmless, traceable audit events

Use a lab user and test resources. Record the exact UTC time and object name for each action so the event can be distinguished from normal activity.

• SharePoint: upload a text file to a test library, rename it, then delete it.
• Teams: add the lab user to a test team, change a test channel setting, then reverse the membership change.
• Exchange: perform an approved administrative change on a test object and reverse it. Do not modify transport rules or production mail flow merely to make an event.

Do not paste real user names, message subjects, file names or tenant IDs into public screenshots. A useful validation note contains the workload, test action, UTC time, anonymised actor and matching Sentinel record ID.

7. Validate OfficeActivity with KQL

Start with a workload count and latest event time:

OfficeActivity
| where TimeGenerated > ago(24h)
| summarize Events = count(), LastEvent = max(TimeGenerated) by OfficeWorkload
| order by Events desc

Then inspect recent rows without expanding potentially sensitive audit payloads:

OfficeActivity
| where TimeGenerated > ago(24h)
| project TimeGenerated, OfficeWorkload, Operation, UserId, RecordType
| order by TimeGenerated desc
| take 100

Finally, narrow the time window and test actor for each controlled event. Validate all selected workloads; a healthy SharePoint result does not prove Exchange or Teams collection. Microsoft’s OfficeActivity query examples include file access, uploads, forwarding-rule activity and per-user searches.

8. Add visibility before adding detections

After raw events arrive, use the workbook and analytics templates supplied by the already-installed Microsoft 365 solution. The Microsoft 365 workbook can provide workload-level visibility across SharePoint, OneDrive, Teams and Exchange. A workbook is useful for exploration, but it is not proof that every critical audit category is present.

• Run each analytics rule query manually over a representative time range before enabling it.
• Document the expected entity mapping and incident owner.
• Start new scheduled rules in a test or low-noise mode where the workflow permits.
• Avoid creating the same incident from both a Defender XDR connector and a separate product alert rule.
• Record the rule’s data dependency so a future connector change does not silently remove coverage.

The current Sentinel workbook list describes the Microsoft 365 and Workspace Usage Report workbooks.

9. Set cost and retention guardrails

1. Capture the workspace’s daily ingestion before and after connecting Microsoft 365.
2. Confirm the selected OfficeActivity data remains covered by Microsoft’s documented no-charge data-source classification; review Cost Management separately for other tables, retention and services.
3. Review analytics and total retention for every security table, not only OfficeActivity.
4. Create a budget and alert for the subscription or resource group that owns the workspace.
5. Review Logic Apps, Functions, automation rules and other connectors for separate charges.
6. Repeat the usage review after enabling workbooks, analytics rules or additional sources.

Purview audit retention and Sentinel retention are separate. Microsoft states that Purview auditing commonly retains audit records for 180 days, subject to licences and retention policies. Once records are ingested into Sentinel, the workspace’s table and tier settings control their Sentinel retention.

Rollback and safe disconnection

Disconnecting the Microsoft 365 source stops future ingestion; it does not erase existing OfficeActivity rows. Before disconnecting, list every workbook, analytics rule, hunting query, automation rule and investigation process that depends on the table.

1. Disable or retarget dependent scheduled analytics rules to prevent misleading failures.
2. Record the last ingested event time by workload.
3. Use the connector page to disconnect the selected Microsoft 365 workloads.
4. Wait through the normal pipeline delay and confirm no new events arrive after the expected cutoff.
5. Leave Microsoft 365 auditing enabled unless a separately approved governance decision requires it to be disabled.
6. Retain historical data according to the documented retention and investigation requirements.

Do not delete the Log Analytics workspace as a shortcut for removing one connector. Microsoft warns that removing Sentinel does not delete its workspace, and a remaining workspace can still incur charges.

Troubleshooting missing Microsoft 365 logs

Frequently asked questions

Are Microsoft 365 audit logs free in Sentinel?

Microsoft lists Office 365 audit data for SharePoint activity, Exchange admin activity and Teams as no-charge Sentinel data sources. Other tables, retention, automation and connected services can still be billable, so verify the actual workspace meter.

Does this connector include Entra sign-in logs?

No. Use the Microsoft Entra ID connector. Microsoft requires Entra ID P1 or P2 for sign-in log ingestion, and other per-gigabyte charges can apply.

Why are there no events immediately after connection?

Purview audit enablement and Sentinel ingestion are not instantaneous. Microsoft says audit enablement can take up to 60 minutes and events can take several hours to become searchable. Use a recorded test window and check again before rebuilding the connector.

Should I connect both Microsoft 365 and Defender XDR?

They serve different data needs. Connect each only when its tables support a documented use case, and review incident-creation settings so the same security alert does not become two incidents.

Bottom line

Connecting Microsoft 365 logs to Sentinel is straightforward; proving that the right events arrive is the real work. Verify Purview auditing, connect only the intended workloads, generate attributable test actions, validate each workload in OfficeActivity, then add detections and retention with an owner and a budget.

Sources reviewed 10 September 2026 against Microsoft Learn. Validate each selected workload in an authorised test workspace before relying on the connector.

Primary Microsoft sources

• Connect Microsoft services through API-based connectors
• Microsoft Sentinel data connector reference
• Turn Microsoft 365 auditing on or off
• OfficeActivity table reference
• OfficeActivity sample queries
• Plan Sentinel costs and understand billing
• Send Microsoft Entra ID data to Sentinel