The OneDrive that comes back — then leaves again

Someone forwards you a screenshot: they clicked a shared link to a former colleague's OneDrive and got a browser page that just says 404 FILE NOT FOUND. The question that lands in your lap is simple — "is this user's data still there, or is it gone?" — and the instinct is to read the 404 as the answer. It isn't.

This is a real recovery, anonymized. The data came back. The interesting part isn't the restore command — it's understanding that a 404 is not a state, and that bringing the site back doesn't fix what deleted it. Restore it carelessly and you'll be doing this again in a month.

01A 404 is not a diagnosis

The OneDrive URL can 404 for half a dozen reasons. Only one of them is "deleted."

A /personal/… OneDrive URL returns 404 FILE NOT FOUND in several situations that have nothing to do with the data being destroyed. Before you conclude anything, know which of these you're looking at:

What a 404 can mean	Is the data gone?
OneDrive was never provisioned (user never signed in to it)	Nothing to lose — it never existed
Account exists but is unlicensed / has no SharePoint license	No — data intact, just not reachable this way
Site archived into Microsoft 365 Archive	No — intact, read-only until reactivated
URL suffix is simply wrong (UPN ≠ path)	No — you're knocking on the wrong door
Owner account deleted → site in the deleted-site bin	No — recoverable for a limited window
Deleted-site window elapsed → purged	Yes — now it's actually gone

So the browser tells you nothing decisive. The authoritative answer lives in SharePoint Online, not in a URL. You have to go ask the service directly.

Mental model

A 404 on a OneDrive URL is a locked front door, not an empty house. The door being locked tells you that you can't walk straight in — it says nothing about whether the furniture is still inside. To find out, you stop rattling the handle and go check the property records.

02Ask SharePoint, not the browser

Connect to SPO and check three places in order: active sites, the deleted-site bin, then the user object.

Use Windows PowerShell 5.1, and connect with a real SharePoint Admin

The SPO module (Microsoft.Online.SharePoint.PowerShell) runs on Windows PowerShell 5.1, not PowerShell 7 — if Connect-SPOService is "not recognized," you're in the wrong shell or the module isn't installed. And note the split later: reading the deleted-site bin can succeed with lower rights, but restoring needs the SharePoint Administrator role. If restore throws "Attempted to perform an unauthorized operation," that's the tell — you're under-privileged, not blocked by a bug.

Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser -Force
Import-Module Microsoft.Online.SharePoint.PowerShell
Connect-SPOService -Url https://contoso-admin.sharepoint.com

Now work the three checks in order. First, is there a live site? Second, is it in the deleted-site bin? OneDrive URLs replace @ and . in the UPN with underscores, so [email protected] becomes …/personal/jordan_reyes_contoso_com.

# 1. is there an ACTIVE site? (a 404 in the browser often still has a live site behind it)
Get-SPOSite -Identity "https://contoso-my.sharepoint.com/personal/jordan_reyes_contoso_com"
#   -> "Cannot get site ..."  means no active site. Keep going.

# confirm there's no active personal site under that name anywhere
Get-SPOSite -IncludePersonalSite $true -Limit All -Filter "Url -like 'jordan_reyes'"
#   -> empty result = no live OneDrive for this user

# 2. is it in the DELETED-SITE bin?
Get-SPODeletedSite -Identity "https://contoso-my.sharepoint.com/personal/jordan_reyes_contoso_com"

In this recovery, the active lookups came back empty but the deleted-site query found it — with a deletion timestamp and a DaysRemaining countdown:

Url                                                            DaysRemaining  DeletionTime
---                                                            -------------  ------------
https://contoso-my.sharepoint.com/personal/jordan_reyes_...              23   8/08/2026 3:51 AM

That single row reframes everything. The data isn't gone — it's in the recycle bin for site collections, on a clock. A personal OneDrive lands here for one dominant reason: the owning user account was deleted. The account deletion is the cause; the OneDrive deletion is the downstream effect. Which means the browser 404 was real deletion — just recoverable deletion, for now.

Myth

The 404 means the OneDrive is permanently gone.

Reality

It's almost always in the deleted-site bin, fully recoverable — until the retention window elapses. The browser can't see the bin; only SPO can.

Myth

Restoring the site puts the user's OneDrive back to normal.

Reality

The files come back, but the owner doesn't — that user object is gone from the directory. You get an ownerless orphan, not a working account.

03Restore, then take ownership

Bring the site back from the bin and grant yourself site-collection admin so you can actually get in.

With SharePoint Admin rights, the restore is one command. Then confirm it flipped to active, and — because the original owner no longer exists — assign a living admin (you, or the data owner) so the site is reachable.

# 1. restore from the deleted-site bin
Restore-SPODeletedSite -Identity "https://contoso-my.sharepoint.com/personal/jordan_reyes_contoso_com"

# 2. confirm it's active again (give it a minute if it errors immediately)
Get-SPOSite -Identity "https://contoso-my.sharepoint.com/personal/jordan_reyes_contoso_com" |
  Select-Object Url, Owner, Status, StorageQuota

# 3. grant a real, living admin so the ownerless site is reachable
Set-SPOUser -Site "https://contoso-my.sharepoint.com/personal/jordan_reyes_contoso_com" `
  -LoginName [email protected] -IsSiteCollectionAdmin $true

A note on that login name: it has to resolve in this tenant. If you're a guest, the straight UPN fails and you need the external form (user_domain.com#ext#@tenant.onmicrosoft.com); if you're a native member, the plain UPN just works. Rather than guess, try the UPN first — success or "user does not exist" tells you immediately which identity type you are. Once the grant returns your name with IsSiteCollectionAdmin set, open the OneDrive URL in a browser and you'll land straight in the user's files as admin.

04The orphan trap

You restored the container. You did not restore the owner. The tenant notices.

Here's the part that catches people. The restore succeeded, the files are all there, you can browse them — problem solved, right? No. The user object is still deleted. Nothing you did re-created the account. So what you now have is a personal site with no valid owner: an orphaned OneDrive. And most tenants are configured to clean those up automatically.

# what's the tenant's cleanup window for ownerless personal sites?
Get-SPOTenant | Select-Object OrphanedPersonalSitesRetentionPeriod
# OrphanedPersonalSitesRetentionPeriod : 30

Thirty days. The restore didn't fix the root cause — it just started a new clock. Left alone, this OneDrive gets re-queued for deletion in about a month, and you're back where you started. The lesson is uncomfortable but clean: restoring an orphaned OneDrive buys you a window to extract the data, nothing more. It is not a place to leave data living long-term.

Route sensitive content to an authorized recipient, and log the privileged actions

A departed employee's OneDrive frequently holds sensitive material — finance records, client data, PII. Recovery isn't "grab it and go." Confirm who is authorized to receive it (the manager or data owner) before you move anything, send it to a real owned location rather than your own machine, and record the privileged-role activation, the restore, and the admin grant in your change ticket with the site's re-deletion date. On a client tenant especially, that paper trail is what protects you later.

05Close the loop — extract, then prevent the repeat

Move the data to a real home, dispose of the orphan, and fix offboarding so it never orphans again.

There is no setting that says "keep this ownerless OneDrive alive forever," and you shouldn't want one. The right move is to get the data off the orphan clock entirely by giving it a real owner somewhere else, then re-dispose of the empty husk:

# extract the data to a durable, OWNED location while the window is open:
#   - a department SharePoint document library (best: it has a real owner), or
#   - the manager's / data owner's OneDrive
# for large trees (thousands of items) prefer Migration Manager or a scripted copy
# over clicking through the browser.

# once the data is safely moved and confirmed, re-dispose of the orphaned site
# so you don't leave an ownerless personal site sitting active (an audit flag).

Then fix the actual failure. This whole exercise happened because the user was deleted with no data handoff. The prevention is an offboarding step, not a SharePoint command:

Prevention	What it does
Grant-manager-on-deletion (OneDrive setting)	Automatically gives the leaver's manager access to the OneDrive when the account is deleted, so data transfers before purge.
Retention policy (Purview)	Preserves OneDrive/SharePoint content independently of the account, so deletion of the user doesn't take the data with it.
Offboarding checklist	Make "transfer OneDrive to manager / archive to library" a required step before the account is deleted — the cheapest fix of all.

The one-line model

A 404 isn't a diagnosis — check the deleted-site bin before you conclude anything. And restoring an orphaned OneDrive brings back the files, not the owner: it buys you a window to move the data somewhere real, not a permanent home. Fix offboarding so the OneDrive is handed off before the account is deleted, and the orphan never happens.