A missing item does not automatically identify a culprit
A message disappears from a shared mailbox, a Teams folder is missing, or a user account no longer exists. First establish what happened: deletion, a move, changed permissions, an automated rule, or a synchronization problem. Then investigate the identity associated with the event.
This guide provides a focused collection workflow for Exchange Online, Microsoft Purview, and Microsoft Entra ID. Commands read the services; exports only write to the administration workstation. Dates, addresses, and identifiers are fictional. A full investigation may require additional evidence, particularly where account compromise or a dispute is involved.
1. Define the scope and preserve initial evidence
Record the search interval in UTC and retain the original local time. An overly narrow window can miss delayed synchronization; a months-long search can bury useful events. Start with a reasonable interval and document any expansion.
- Open an incident record: reporter, discovery time, last known presence, time zone, and operational impact.
- Identify the target: mailbox and message details, full file URL and library, or the user's Entra object ID. A display name alone is insufficient.
- Capture the current state, recycle bin, and errors without purging or moving data. Preserve logs before their retention expires.
- Separate investigation access from recovery permissions. Assign a change owner so two administrators do not restore the same content simultaneously.
2. Choose the log for the object
A file displayed in Teams may live in SharePoint or OneDrive: identify its actual location. Deleting an account and deleting a message are different operations. Entra sign-in logs alone do not explain a missing email.
| Object | Starting point | Keep separate |
|---|---|---|
| Exchange Online message | Purview Audit: MoveToDeletedItems, SoftDelete, HardDelete | Affected mailbox, acting identity, and logon type |
| SharePoint or OneDrive file | Purview Audit: FileRecycled, FileDeleted, and recycle-bin events | File, parent folder, move, and version deletion |
| Entra user | Entra ID > Audit logs: Delete user | User or application initiator, target, and result |
3. Permissions, licensing, and retention windows
For Purview searches, use a role group granting View-Only Audit Logs, such as Audit Reader, with the appropriate scope. Audit cmdlet access must also be assigned in Exchange. The configuration checks below require their corresponding Exchange RBAC permissions; log-reading access does not necessarily authorize Get-Mailbox.
Audit Standard normally retains events for 180 days. Longer retention depends on licensing and policies. E5 or eligible add-on entitlements apply to the user generating the event in relevant scenarios; licensing the investigator does not automatically extend every record. Check the effective policy rather than relying on the subscription name.
Entra audit logs have a separate window: seven days with Free and 30 days with P1/P2. Previously configured exports can provide an external history. Entra retention does not determine Purview retention. Changing licensing cannot recreate records that have already expired.
4. Check Exchange auditing without changing settings
Run Get-AdminAuditLogConfig in Exchange Online PowerShell: the same property can report False in Security & Compliance PowerShell. UnifiedAuditLogIngestionEnabled describes ingestion, while AuditDisabled concerns organization-level mailbox auditing.
Review Owner, Delegate, and Admin operations alongside DefaultAuditSet. Customizations or audit bypass exceptions can explain gaps. AuditEnabled alone does not demonstrate that every required action was logged. A healthy current configuration does not prove the historical state at incident time.
# Read-only tenant checks; requires ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled
Get-OrganizationConfig | Select-Object AuditDisabled
Get-Mailbox -Identity 'support@contoso.com' |
Select-Object DefaultAuditSet, AuditOwner, AuditDelegate, AuditAdmin,
RetainDeletedItemsFor5. Search for the message and distinguish deletion stages
In Purview > Audit, select the UTC interval and relevant operations. Leave the user filter empty when the actor is unknown: the mailbox owner may differ from the delegate who acted. Inspect result details before drawing a conclusion.
MoveToDeletedItems moves an item into Deleted Items. SoftDelete moves it into Recoverable Items. HardDelete describes a purge from Recoverable Items; its name alone does not establish every recovery or preservation possibility.
For a one-time extraction, this block pages through a bounded interval. It keeps the session identifier and stops at 50,000 results. If that ceiling is reached, split the interval and repeat; do not describe the export as complete. Results are not necessarily sorted.
# Fictional UTC interval: replace with the incident window
$start = [datetimeoffset]::Parse('2026-10-20T12:00:00Z').UtcDateTime
$end = [datetimeoffset]::Parse('2026-10-20T14:00:00Z').UtcDateTime
$operations = @('MoveToDeletedItems', 'SoftDelete', 'HardDelete')
$session = [guid]::NewGuid().ToString()
$rows = [System.Collections.Generic.List[object]]::new()
$query = @{
StartDate = $start; EndDate = $end; Operations = $operations
SessionId = $session; SessionCommand = 'ReturnLargeSet'
ResultSize = 5000; ErrorAction = 'Stop'
}
do {
$page = @(Search-UnifiedAuditLog @query)
foreach ($row in $page) { $rows.Add($row) }
} while ($page.Count -gt 0 -and $rows.Count -lt 50000)
if ($rows.Count -ge 50000) {
Write-Warning 'Limit reached: split the interval and repeat with new session IDs.'
}
# Preserve $rows before filtering; an empty response is not proof of no deletion.6. Preserve the raw export before filtering
Prepare a case directory restricted to authorized investigators on protected storage. Record the tenant, collection account, command, interval, filters, row count, and warnings. Exports contain personal information; do not place them on a public share or paste-sharing service.
The raw CSV retains AuditData. The derived view below targets the fictional support@contoso.com mailbox without confusing MailboxOwnerUPN with UserId. Some events group multiple items: inspect nested objects instead of treating each row as one message.
A SHA-256 hash can reveal later file changes if the reference hash is protected. It certifies neither the person behind the action nor collection completeness. Keep the original intact, analyze a copy, and document evidence recipients.
# LOCAL WRITES ONLY. Use an existing, access-restricted case directory.
$caseDir = 'C:\Cases\INC-2026-042'
if (-not (Test-Path -LiteralPath $caseDir -PathType Container)) {
throw 'Create and secure the case directory before exporting.'
}
$stamp = [datetime]::UtcNow.ToString('yyyyMMddTHHmmssfffZ')
$rawPath = Join-Path $caseDir "ual-$stamp.csv"
$rows | Export-Csv -LiteralPath $rawPath -NoTypeInformation -Encoding utf8
Get-FileHash -LiteralPath $rawPath -Algorithm SHA256 |
Export-Csv -LiteralPath "$rawPath.sha256.csv" -NoTypeInformation
# Derived view; the original AuditData JSON remains in the raw export.
$records = @($rows | ForEach-Object {
$_.AuditData | ConvertFrom-Json -ErrorAction Stop
})
$records | Where-Object { $_.MailboxOwnerUPN -eq 'support@contoso.com' } |
Select-Object CreationTime, Id, Operation, ResultStatus, UserId,
MailboxOwnerUPN, LogonType, ClientIP, ClientIPAddress |
Format-Table -AutoSize7. Investigate a SharePoint or OneDrive deletion
Search Purview for file and folder operations within the chosen period. A parent-folder deletion, move, or deletion propagated by the OneDrive client can explain multiple missing files. If initial filters return nothing, include related operations and previous URLs.
FileRecycled records a move into the recycle bin. FileDeletedFirstStageRecycleBin and FileDeletedSecondStageRecycleBin help investigate later stages. Include folder or version variants where relevant.
Actually replace the operations list in the collection block; do not simply display the previous Exchange results. Preserve the new export and rebuild $records. Inspect ObjectId, the acting identity, time, and available application details. A system identity or app@sharepoint requires contextual investigation rather than attribution to an arbitrary person.
# Replace $operations in the search block, then rerun it in full.
# Its new session ID must not be reused from the mailbox search.
$operations = @(
'FileRecycled', 'FileDeleted',
'FileDeletedFirstStageRecycleBin', 'FileDeletedSecondStageRecycleBin',
'FolderRecycled', 'FolderDeleted'
)
# After searching and preserving the raw records, decode AuditData again.
# Example narrow view; adapt the path to the actual recorded ObjectId.
$records | Where-Object {
$_.ObjectId -like 'https://contoso.sharepoint.com/sites/Finance/*'
} | Select-Object CreationTime, Id, Operation, UserId, ObjectId, ClientIP8. Investigate user deletion with Microsoft Graph
Start in Entra ID > Monitoring & health > Audit logs with the Delete user activity. Check the target and result, then the initiator. For an account synchronized from on-premises Active Directory, continue through the source logs and synchronization process: the cloud event may describe a downstream effect.
For Graph v1.0, AuditLog.Read.All is this API's least-privileged read permission. Delegated access also needs a supported role, such as Reports Reader, and approved consent. Microsoft.Graph.Reports supplies the cmdlet. This block requests no directory write permission.
The filter targets the initial Delete user operation. If nothing matches, broaden the search to UserManagement activities in the interval and recheck the target ID rather than assuming no deletion occurred. -All handles pagination; a narrow time window reduces volume.
Retain TargetResources, InitiatedBy, Result, and CorrelationId in the full JSON. Application display names are not unique: use AppId and ServicePrincipalId for follow-up. Hash this export using the same approach as above.
# Requires Microsoft.Graph.Reports and approved delegated consent
Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome
$targetId = '11111111-2222-3333-4444-555555555555' # Fictional user object ID
$filter = "activityDateTime ge 2026-10-20T12:00:00Z and " +
"activityDateTime le 2026-10-20T14:00:00Z and " +
"activityDisplayName eq 'Delete user'"
$events = @(Get-MgAuditLogDirectoryAudit -Filter $filter -All -ErrorAction Stop)
$matches = @($events | Where-Object { $_.TargetResources.Id -contains $targetId })
$matches | Select-Object Id, ActivityDateTime, ActivityDisplayName, Result,
CorrelationId, @{n='ActorUPN';e={$_.InitiatedBy.User.UserPrincipalName}},
@{n='ActorUserId';e={$_.InitiatedBy.User.Id}},
@{n='AppId';e={$_.InitiatedBy.App.AppId}},
@{n='ServicePrincipalId';e={$_.InitiatedBy.App.ServicePrincipalId}}
# LOCAL WRITE: same protected case directory as above
$events | ConvertTo-Json -Depth 30 |
Set-Content -LiteralPath (Join-Path $caseDir "entra-$stamp.json") -Encoding utf89. Attribute the action without overstating the evidence
Fictional example: a Finance file is recorded as deleted under Alice's account, while her synchronization client was active on two computers. The initial finding is 'deletion recorded under this identity,' accompanied by corroborating evidence and unresolved questions. Suspicious sign-ins also warrant account-compromise investigation.
- Named account: an event associates an identity with an operation. It does not independently prove that the account owner was at the keyboard.
- Shared mailbox: separate the mailbox owner from the delegate. An account shared by several people severely limits individual attribution.
- Application or automation: identify the service principal, job, owners, and execution logs. Do not substitute a person's name for a technical identity without evidence.
- IP address: correlate available sign-ins, devices, and timestamps. A VPN, proxy, or intermediary service may prevent identification of the originating workstation.
- Result: distinguish attempts from successful actions. Automated retention processing requires examination of its policy and supporting records.
10. No results: check before closing the case
Microsoft describes typical availability of 60–90 minutes for core-workload events, without a guaranteed deadline. An empty result immediately after a test is therefore inconclusive. Enabling auditing afterwards does not add events that were never collected.
| Check | Diagnostic action |
|---|---|
| Wrong time or target | Recheck UTC, object ID, URL, and possible renaming. |
| Actor filtered too early | Remove the user filter; locate the target in record details. |
| Ingestion delay | Repeat later and document collection time. |
| Expired retention | Check previously configured archives and alternative evidence. |
| Audit or permission gaps | Review role scope, audited operations, and exceptions. |
| Limited extraction | Split the window and check pagination and errors. |
11. Handle recovery as a separate change
Choose the appropriate recovery mechanism, approve the exact target, and preserve evidence before making changes. An audit record is not a recoverable backup of the message or file. Legal preservation and operational recovery serve different purposes.
Where possible, test on a noncritical object first. Record changes and plan how to correct a restoration to the wrong location without deleting evidence. Never release a hold or purge a recycle bin merely to simplify troubleshooting; involve the appropriate owners where preservation obligations apply.
| Target | Window or check | Post-change validation |
|---|---|---|
| Recoverable Items: 14 days by default, configurable up to 30; preservation mechanisms can change the scenario. | Content, folder, recipient, and duplicates. | |
| SharePoint file | Recycle bins: 93 days total from initial deletion, subject to purging; not two separate 93-day periods. | Version, location, permissions, and business-owner access. |
| User | Normally restorable within 30 days; assess deletion state, conflicts, and hybrid identity. | Identity, access, licences, and associated workloads; do not assume complete recovery. |
12. Prepare for the next investigation
In an authorized test mailbox and site, create and delete a disposable item, record identity and time, allow for ingestion, and confirm the event can be found. This pilot changes test data: plan restoration and controlled cleanup. It validates the collection path without guaranteeing every production scenario.
Separate observed facts, hypotheses, limitations, and actions in the final report: affected object, operation, technical identity, result, exported sources, evidence gaps, and recovery decision. Establish suitable retention before the next incident.
Microsoft 365 security assessment and backup consulting services can help validate permissions, logging coverage, and recovery scenarios. This focused diagnostic provides a starting point; it does not replace a complete security investigation.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →