SharePoint and OneDrive both run on the same underlying storage, but they’re built for different jobs — SharePoint for shared team/organizational content, OneDrive for individual work. Mixing them up is the most common source of “why can’t my team find this file” complaints.
In this post: What happens when someone leaves · Extending the 30-day window · Under the hood, OneDrive is a SharePoint site · Forcing the issue: Known Folder Move · SharePoint best practices · OneDrive best practices · When would you actually use this? · Related reading
What happens when someone leaves
This is the real reason the SharePoint-vs-OneDrive distinction matters, not just findability. SharePoint content stays accessible to anyone with permission regardless of who created it or whether they still work there — the file just keeps the original creator’s name in its metadata. OneDrive content is time-limited: when an account is deleted, the manager gets automatic access for a default 30-day window to move anything important out (to their own OneDrive or a SharePoint site) — after that, without action, it’s gone. A project’s working files living in someone’s personal OneDrive is a real business continuity risk, not just an inconvenience.
Extending the 30-day window
The 30-day manager-access window flagged above as a real business continuity risk isn’t fixed — it’s a tenant setting, and 30 days is genuinely tight for anything beyond “someone remembers to check the departing employee’s files in time.” Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod extends it, up to a year:
Connect-SPOService -Url https://contoso-admin.sharepoint.com
# Extend to 90 days (max supported is 365)
Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod 90
Two things worth knowing before assuming this alone solves the risk: the new value only applies going forward, to the next user deleted after the change — it doesn’t retroactively extend the clock for anyone already inside their 30-day window. And even after this period ends, the OneDrive isn’t gone outright — it moves into the site collection recycle bin for a further 93 days, recoverable only by a SharePoint admin via PowerShell, not self-service. So the real safety margin for a departing employee’s files is the tenant retention period plus that 93-day recycle window, not just whatever number is set here — but the number set here is still the part that determines how much runway a manager actually has to notice and act before recovery starts needing admin involvement.
Under the hood, OneDrive is a SharePoint site
This explains a lot of the overlap between the two: every user’s OneDrive is, technically, its own SharePoint site collection, provisioned from a personal-site template the first time they access OneDrive. That’s why the same admin center manages both, why the same REST/PnPjs APIs work against a user’s OneDrive as against any other SharePoint site, and why permission concepts (sharing links, external access settings) behave identically in both places. The practical difference is entirely about storage allocation and intended use, not the underlying platform: OneDrive gets its own per-user storage (1TB base, extendable per license, separate from the shared SharePoint site-storage pool covered in Managing SharePoint Storage Limits), while regular SharePoint sites draw from that shared tenant-wide pool.
Forcing the issue: Known Folder Move
“Keep it for individual work” in the OneDrive best practices below assumes someone’s actually using OneDrive for their local files in the first place — a lot of users never do, and just keep working out of their PC’s local Desktop and Documents folders, backed up nowhere. Known Folder Move (KFM) is the enterprise fix: an Intune (or Group Policy) setting that redirects Desktop, Documents, and Pictures into the user’s OneDrive automatically, so whatever they save locally is actually syncing to the cloud without them doing anything differently.
Deployed through Intune’s Settings Catalog as a set of OneDrive policies — silently redirecting the known folders, plus a separate “Prevent users from turning off Known Folder Move” setting to stop someone from opting back out once it’s applied. Worth pairing the two rather than deploying the redirect alone: KFM without the opt-out block just becomes a one-time nudge that a user can quietly reverse, which defeats the actual goal (business continuity, not a one-time migration). This is also what actually closes the gap the “what happens when someone leaves” section above describes — content that would otherwise be sitting unsynced on a departing employee’s laptop ends up in their OneDrive instead, where the standard 30-day retention/reassignment window can actually do its job.
SharePoint best practices
- Organize with metadata, not deep folder trees — folders don’t scale, views and metadata do.
- Turn on version history for an actual audit trail and the ability to revert.
- Use SharePoint groups for permissions, not individual grants.
- Automate the repetitive parts — approvals, notifications, archiving — with Power Automate.
- Use Hub Sites to connect related sites instead of leaving them isolated.
OneDrive best practices
- Keep it for individual work — team content belongs in SharePoint, not scattered across personal OneDrives.
- Use Files On-Demand to avoid local storage bloat — files stay in the cloud until actually opened.
- Install the sync client for offline access rather than manually downloading/uploading.
- Be deliberate about external sharing permissions — this is the most common accidental-leak vector.
- Clean up periodically — old files accumulate quietly.
Team content belongs in SharePoint, not scattered across individual OneDrives — that’s the single most common cause of “why can’t anyone else find this.”
When would you actually use this?
- A file only one person can find, because it’s sitting in their personal OneDrive instead of a team library — that’s the SharePoint-vs-OneDrive line, made concrete.
- You’re deciding where a new working document should live — if more than one person needs it, SharePoint; if it’s yours alone (for now), OneDrive.
- External sharing needs to happen and you want to avoid an accidental leak — review permissions deliberately rather than accepting the default link type.
Related reading
- OneDrive vs. Google Drive: Which One Should You Use? — how OneDrive stacks up outside the Microsoft ecosystem, once you know how it relates to SharePoint.
- OneDrive Cloud and Sync Limitations — the practical limits worth knowing before you lean on OneDrive the way this post describes.
Hope it helps — shout in the comments if you get stuck.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning


