That recording lives in the OneDrive of someone who no longer works here

At the end of September, whiteboards created from a Teams channel tab will stop being saved in the creator's OneDrive and will land in the channel's SharePoint site instead. Microsoft announced it on 16 March in message MC1253753; it is on by default and needs no admin action. It is a three-line note in the message centre and a fairly large admission: the team's work was sitting in one person's personal account, and that is why it kept breaking. What almost nobody has checked is how many other things are still exactly where they were.

The reason Microsoft gives in the notice is operational and sounds reasonable: storing them in the channel site avoids the access problems caused by sharing settings, information barriers or conditional access policies, and lets whiteboards inherit the site's Purview controls — DLP, sensitivity labels, retention, eDiscovery and audit logging. Every channel member gets the same access, based on channel permissions. There is one thing the notice does not say, and we are not going to assume it: what happens to whiteboards that already exist inside OneDrive. Treat those as what they are until Microsoft says otherwise: files living in one specific person's account.

The map almost no company has

The Teams documentation on recording storage was updated on 7 August, three days ago. It is worth reading in full once in your life, because the split is not intuitive and each row has different consequences the day someone leaves:

• Scheduled meeting or event: the recording goes to the Recordings folder in the organiser's OneDrive, even if the organiser did not attend. The same applies when a delegate scheduled it on their behalf.
• One-to-one or group call: it goes to the OneDrive of whoever pressed Record. On a call with someone outside the company, the other party gets no access at all unless you share it by hand.
• Channel meeting: this is the good one. The recording is stored in the team's SharePoint document library, under Documents/Recordings, and permissions are inherited from channel membership. Nobody owns anything personally.
• Meeting scheduled from a shared mailbox: the mailbox counts as organiser, but since shared mailboxes usually have no OneDrive, the recording ends up in the co-organiser's, or failing that, in the OneDrive of whoever started the recording. In other words: you thought it was in a service account and it is in a person's.
• Teams Room: when somebody hits Meet now from a room, the room is the organiser. If its resource account has a OneDrive licence, the recording is stored there and none of the participants has full permissions on the file. Microsoft's literal recommendation to avoid this is not to assign a OneDrive licence to the room resource account. That the official fix is to take storage away from a device sums up the underlying problem rather well.
• And if nobody has a OneDrive: the recording goes to temporary async storage, no upload retries are attempted and it is deleted after 21 days if nobody downloads it. As a size reference, the documentation itself puts one hour of recording at 400 MB.

Notice the pattern: of six cases, only the channel one leaves the file with the team. In four it ends up hanging off a person or a resource account, and in the last one it hangs off nobody and deletes itself within three weeks. None of those people decided to be the owner of the file: it fell to them because they scheduled the meeting or pressed a button.

The clock does not start when the person leaves

This is where most offboarding procedures we come across have a hole, and the reason is that the detail sits in a paragraph of the OneDrive documentation nobody reads. The OneDrive retention period starts counting when the account is deleted from Entra ID. No other action triggers it: not blocking sign-in, not removing the licence. The default is 30 days, and you change it from the SharePoint admin centre or with Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod.

During those 30 days, by default the person's manager is automatically granted access to the OneDrive and gets an email about it. If no manager is set in Entra, the notice goes to the secondary owner configured in the SharePoint admin centre under Setup My Sites. And if neither exists — which is what we run into often, because the manager field goes unfilled the moment somebody creates an account in a hurry — nobody gets access and nobody gets the warning. Seven days before the end a second email goes out, to the same non-existent recipient. After that, the OneDrive moves to the site collection recycle bin for 93 days: at that point nobody can reach content that was shared from it, restoring requires PowerShell and, because the recycle bin is not indexed, an eDiscovery hold cannot locate anything in there either. The nuance that works in your favour, and worth knowing: if that OneDrive was already under an eDiscovery hold beforehand, it is not deleted until the hold is lifted, and Microsoft 365 retention policies take precedence over this whole process, so they can delete before 30 days or retain well beyond it.

And now the industry habit, the one we have all applied: "we do not delete the account, we leave it blocked and unlicensed just in case". It is true that this does not start the 30-day clock. What almost nobody knows is what the highlighted note at the top of that same document says: every OneDrive account without a valid licence is automatically archived on its 93rd unlicensed day. While that archive is paid for, Microsoft says retention settings, retention policies, eDiscovery and all holds are still honoured. But after 12 months of unpaid archive storage, the data may be deleted regardless of all of it. Put another way: the account you left blocked ends up in a paid archive, and that archive has an invoice and a date.

"But we back up Microsoft 365"

It is the answer we get every time we raise this, and it is usually true: there is a tool, it runs nightly and the reports come out green. The problem is that a backup answers the question "can I recover this file?", and the one that hurts here is a different one: "whose file was this, and who will know a year from now that it needs recovering?". When you restore the OneDrive of an account that no longer exists, what you get back is an orphaned folder: without the permission structure of the team that used it, without the links people had saved, and with somebody from IT deciding at three on a Tuesday afternoon where to put it. It can be done and we have done it. It is slow, it is manual and nobody mentions it when selling you the backup.

For the record, you should back up Microsoft 365, and we already explained why Purview retention is not a backup. What we are arguing about here is what comes first: the backup is the net underneath, and this problem sits above it, in who owns the data while everything is fine. If the file was born in the team site, somebody leaving is settled with an HR form and fifteen minutes of an administrator's time.

What we do before touching the account

• Fill in the manager field in Entra ID for the whole workforce, and also configure a secondary owner under Setup My Sites for anyone who lacks one. And before anything else, check that Enable access delegation is ticked under My Site Cleanup: with it off, neither the manager nor the secondary owner gets anything.
• Raise the OneDrive retention period from the 30-day default to something that survives a financial close or a real handover. The caveat: that storage still counts against your quota and still costs, so the number comes out of a conversation with the business.
• Schedule recurring meetings from the channel instead of from one person's calendar. It changes exactly one thing — where the recording lands — and with that the committee's history stops having an individual owner.
• Review room resource accounts: no OneDrive licence, exactly as the documentation recommends.
• Move the team's material into the team site while the person is still there. The moment to move a file is while there is still somebody to ask what it is and what it was for. After that it is archaeology.
• Run a real restore, from an account that is already deleted, and time it. A recovery plan that has never been executed is an intention. The same goes for email, where deletion can also come from outside: we covered that when writing about cross-tenant message recall in Exchange Online.

Four of those six can be done in an afternoon. Moving the team's material takes time, and the restore test has to go in the calendar like a fire drill. What is left is the conversation with HR about what steps an offboarding includes, which is where this actually gets decided: the company procedure that technology exposes every time somebody leaves.

When we review a tenant, there is one question we ask early because it orders the rest of the conversation: show me the recording of the board meeting from two years ago. It almost never turns up first time, and the script repeats itself: the recording was in the OneDrive of somebody who left, the account was removed months later in a licence tidy-up, and the warning went out to an address nobody reads any more. Nobody deleted it on purpose and no backup failed: everything worked exactly as documented. That is precisely the problem.

We deploy and run Microsoft 365 for companies and we do not sell a miracle tool for this: what there is is procedure, data ownership and a backup somebody has actually tried restoring. That is what we build in our Microsoft 365 backup and modern workplace projects. If you want to settle the question without buying anything, take the last person who left your company and go looking for their files; if they do not turn up, get in touch and we will look at it with you.