Recovering Teams Chat and Copilot Chat History After an Azure AD Identity Recreation

Summary

This article walks through a real-world Microsoft 365 identity incident: an end user's Azure AD (Microsoft Entra ID) account was deleted and recreated with the same email address, which silently changed the underlying Object ID. Because so many Microsoft 365 services key off Object ID rather than the visible email address, this single action broke Outlook mail access, Microsoft Teams chat history, OneNote, Microsoft 365 Copilot chat history, and SharePoint access for the affected user. The post documents the diagnosis process, what worked, what didn't, and the recommended path forward — written from the perspective of the Microsoft 365 administrator who handled the ticket.

All names, email addresses, tenant identifiers, GUIDs, and ticket numbers in this article have been replaced with generic or synthetic placeholder values. Any resemblance to a real organization, user, or identifier is coincidental.

Background

A user we'll call Jane Example (jane.example@contoso.com) had her Microsoft Entra ID account deleted and immediately recreated using the same email address/UPN. On the surface this looks harmless — same name, same address, same license assignment — but Entra ID assigns a brand-new Object ID (GUID) to the recreated account. Microsoft Teams, Copilot, OneNote, and SharePoint permissions are frequently tied to that Object ID internally, not the UPN, so the recreation effectively orphaned the user from her own historical data:

• Outlook mail appeared empty
• Microsoft Teams 1:1 and group chat history was gone
• OneNote notebooks were inaccessible
• Microsoft 365 Copilot chat history was gone
• SharePoint site access (e.g., a Teams-connected SharePoint site) was lost

Quick wins: SharePoint and OneNote

Two of the five symptoms were resolved fairly quickly by the admin:

SharePoint access was restored by removing the old (now-orphaned) user profile entry from the site's People/Membership page (People.aspx for the relevant SharePoint site), which allowed the new identity to be re-added cleanly with correct permissions.

OneNote notebooks were recovered via the SharePoint admin center's old user profile management tools inside the Microsoft 365 admin center, which still referenced the correct document libraries.

That left two much harder problems: Teams chat history and Copilot chat history.

Why Teams chat and Copilot chat are harder

Both Microsoft Teams chat messages and Microsoft 365 Copilot chat/interaction history are not stored as a separate "chat database" — they live as hidden, non-visible items inside each user's own Exchange Online mailbox (in what's often referred to as the mailbox's "substrate" storage, outside the normal visible folder tree a user sees in Outlook). Because the new account has a brand-new mailbox (tied to the new Object ID), the old mailbox — the one that actually contains Jane's chat history — becomes orphaned once the account is deleted, even though the email address looks unchanged.

Step 1: Locate the old mailbox

Since the old Entra ID account had already been recreated (rather than restored from the recycle bin) by the time this ticket was picked up, the admin needed to check Exchange Online for the leftover mailbox using PowerShell:

Get-Mailbox -SoftDeletedMailbox | Where-Object {$_.PrimarySmtpAddress -like "jane.example*"} | Format-List DisplayName, ExchangeGuid, PrimarySmtpAddress, WhenSoftDeleted

This returned the old, disconnected mailbox as a soft-deleted mailbox (not a hold-based "inactive mailbox," which is a distinct Exchange concept that only applies when litigation hold or retention was active at time of deletion). Example (synthetic) output:

DisplayName        : Jane Example
ExchangeGuid       : 00000000-1111-2222-3333-444444444444
PrimarySmtpAddress : jane.example@contoso-legacy.com
WhenSoftDeleted    : <14 days before this check>

By default, Exchange Online retains soft-deleted mailboxes for 30 days before permanent purge, so timing mattered a lot here — this check happened around day 14, leaving roughly two weeks to act.

A useful gotcha encountered along the way: querying the new, active mailbox by its email address sometimes returned "matches multiple entries" errors in PowerShell, because Exchange had renamed the old, disconnected mailbox's internal Name/alias to a raw GUID string to avoid a naming collision with the newly created account. The fix was to always resolve identities by their unique ExchangeGuid rather than by email address/UPN, e.g.:

Get-Mailbox -Identity jane.example@contoso.com | Format-List DisplayName, UserPrincipalName, PrimarySmtpAddress, ExchangeGuid, WhenMailboxCreated

Step 2: Attempting a targeted mailbox restore

The next instinct was to use New-MailboxRestoreRequest to copy content from the old soft-deleted mailbox into the new active mailbox, specifically targeting the hidden folder where Teams chat data lives. Several attempts using a special folder alias token (referencing the mailbox's hidden "non-IPM root") failed outright with an "invalid folder alias" error — that particular syntax wasn't accepted in this tenant's cmdlet version.

Enumerating the old mailbox's folder structure directly also wasn't possible, because Get-MailboxFolderStatistics requires a live, connected recipient object and cannot target a soft-deleted mailbox.

Step 3: Full mailbox restore (partial success)

As a fallback, the admin ran a full mailbox restore with no folder restrictions at all, letting Exchange copy everything it could into a new folder in the active mailbox:

New-MailboxRestoreRequest -SourceMailbox 00000000-1111-2222-3333-444444444444 -TargetMailbox 99999999-8888-7777-6666-555555555555 -TargetRootFolder "Recovered_Full" -AllowLegacyDNMismatch

Progress was monitored with:

Get-MailboxRestoreRequest -TargetMailbox 99999999-8888-7777-6666-555555555555 | Get-MailboxRestoreRequestStatistics

This completed successfully and did restore normal mail folders (Inbox, Sent Items, Drafts, Calendar, etc.). However, checking the folder statistics afterward showed the "Team Chat" folder (under Conversation History) restored with zero items, and no Copilot-related folder appeared anywhere in the hierarchy at all.

This turned out to be an expected technical limitation rather than a misconfiguration: Microsoft deliberately excludes Teams chat and Copilot interaction data from standard mailbox export/import tooling as a compliance boundary. That substrate data can only be retrieved through Microsoft Purview eDiscovery (Content Search), which has specialized backend access that ordinary mailbox restore/export operations do not.

Step 4: The eDiscovery permission wall

Attempting to use Purview eDiscovery Content Search surfaced a separate, important lesson: Purview eDiscovery permissions are managed through their own role groups, independent from Exchange admin roles and independent from generic Microsoft Entra ID admin roles. Having strong Exchange permissions (e.g., Organization Management with Legal Hold and Mailbox Search rights) does not grant eDiscovery Content Search or case-creation access.

Checking Purview → Settings → Roles and scopes → Role groups → "My permissions" showed the admin's account mapped only to Global Reader and MailFlow Administrator — neither of which allows creating or running a Content Search or eDiscovery case. Attempting to create a new eDiscovery case failed with a generic error until this was understood to be a role gap rather than a transient issue.

Neither eDiscovery Manager nor eDiscovery Administrator were available as eligible, self-activatable roles for this account, which meant PowerShell-based Compliance workarounds weren't viable either (they enforce the same underlying role-based access control).

Recommended path forward

At the time of writing, the practical options identified for completing this recovery were:

1. Have a Global Administrator directly assign the eDiscovery Administrator role (distinct from making it merely PIM-eligible), which would unlock Content Search across both the Teams chat and Copilot interaction content types for the affected mailbox.
2. Loop in a colleague who already holds an eDiscovery Administrator/Manager role to run the search or add the requesting admin as a case member.
3. If neither is quickly available, open a Microsoft Support case — Microsoft's internal tooling can, in some cases, directly assist with substrate-level recovery beyond what's exposed to tenant admins, and can advise on extending the soft-delete retention window if the 30-day clock is a concern.

Lessons learned

A few takeaways worth sharing with other Microsoft 365 admins:

• Never delete-and-recreate an account to "fix" something if the same identity can be restored instead. Restoring the original Entra ID object from the Deleted Users recycle bin (available for 30 days) preserves the Object ID and avoids this entire class of problem. Deletion should be reserved for genuine offboarding.
• Exchange soft-deleted mailboxes and "inactive mailboxes" are not the same thing — inactive mailboxes require an active hold at time of deletion and persist indefinitely; soft-deleted mailboxes default to a 30-day window regardless of hold status. Know which one you're dealing with early, since it changes your urgency and your available tooling.
• Always resolve mailbox identities by ExchangeGuid, not email address, once an address has been reused by a new account — ambiguous-match errors are a strong signal this has happened.
• Standard mailbox restore/export tooling cannot recover Teams chat or Copilot chat data. Only Purview eDiscovery Content Search can reach that substrate content; plan your access accordingly before an incident occurs.
• Audit who holds eDiscovery Administrator/Manager rights before you need them. Discovering a permissions gap mid-incident, against a 30-day data retention clock, is a stressful way to find out.

Disclaimer

This write-up is a sanitized account of a troubleshooting process for educational purposes. All identifiers — names, email addresses, domains, tenant names, GUIDs, and ticket numbers — are synthetic and do not correspond to any real person, organization, or system.