Skip to content
All articlesSharePoint

OneDrive Quota Enforcement July 2026 (MC1310684): What to Do

From July 2026 Microsoft will put OneDrive users over their licensed quota into read-only state. What MC1310684 means and how to prepare before the cutover.

5 June 202611 min read
OneDrive Quota Enforcement July 2026 (MC1310684): What to Do

OneDrive Quota Enforcement July 2026: What Changes

Starting in early July 2026, Microsoft will begin enforcing licensed OneDrive for Business storage quotas - users whose OneDrive sits above the licensed amount will be placed in a read-only state until storage is reduced or the user is upgraded. This is Microsoft's correction of a long-standing inconsistency where admin-set quotas could be applied above the user's license entitlement during a quota refresh. The change is tracked in Microsoft 365 Message Center post MC1310684, rollout begins in early July 2026, and completion is expected by mid-July 2026.

Microsoft has framed the change as a bug fix rather than a policy change, and notes only "a small percentage of users" are affected. In practice the impact is concentrated on three groups: tenants where an admin previously raised a quota above what the SKU entitles, departed users whose OneDrive is still consuming space on an active license, and a small number of genuinely large-footprint users. Government cloud deployments were excluded from scope when the message was updated in June 2026.

This post covers what MC1310684 actually says, what the read-only state looks like to end users, who is at real risk, and what to do in the four to six weeks before enforcement starts. It also covers the related SharePoint-quota question - sites that report as over quota but still appear to work - because the two stories are often confused.

What MC1310684 Actually Changes

Today, an administrator can set a per-user OneDrive quota above the license entitlement using Set-SPOSite or the SharePoint Admin Center. Until now that quota would persist through subsequent quota refreshes even when the user's licensed entitlement was lower. The MC1310684 change aligns the applied quota with the licensed entitlement on the next refresh. After the cutover, any over-license quota is brought back down to the entitlement, and any storage already over that line is the user's problem to remediate.

The rollout window in MC1310684:

  • Action deadline: May 26, 2026
  • Rollout begins: Early July 2026
  • Rollout completes: Mid-July 2026

The action deadline has passed, but the rollout has not, so there is still time to identify and remediate. Microsoft published a PnP PowerShell script in the original message that enumerates users currently exceeding their licensed storage. Running that script against your tenant is the single most useful thing to do this week - it tells you exactly how many users you have, who they are, and how much each is over by.

What the Read-Only State Looks Like

When a user's OneDrive transitions to read-only after enforcement:

  • The user can still open and read existing files in OneDrive, Teams, and Office apps.
  • New file creation, uploads, and saves to OneDrive are blocked.
  • OneDrive sync clients on Windows and Mac will show sync errors and refuse to upload new files.
  • Files shared from that user's OneDrive remain accessible to recipients - read access is preserved.
  • Office autosave will fail to OneDrive, prompting users to choose a different save location.

The user is not locked out of Microsoft 365 - email, Teams chat, and SharePoint access continue as normal. The block is scoped to writes against that user's own OneDrive. Once storage drops back under the licensed quota, or the user is moved to a higher-tier license, the read-only state clears on the next refresh.

For a helpdesk team this is a manageable but visible incident pattern. Users notice immediately because their everyday "save to OneDrive" stops working. Expect tickets within hours of enforcement starting against a given user.

Who Is Actually at Risk

Three cohorts account for most of the real exposure:

1. Admin-elevated quotas. Tenants where an admin raised a user's quota above the licensed entitlement at some point in the past - often years ago, often to unblock a one-off migration, often forgotten. These users are the most likely to be surprised by the change because the configuration looks deliberate.

2. Departed users on active licenses. A common pattern: an employee leaves, the account is disabled but the license is left in place "for now" to preserve the data, and the OneDrive keeps consuming space against that license. If the OneDrive is large and the license is at the lower end of the tier ladder, the account can sit over quota indefinitely. Today that has no consequence. In July it does. This is also the cohort with the cleanest remediation path: the data should not be living on an active OneDrive license at all.

3. Genuine high-footprint active users. Users with very large local sync footprints (CAD, video, research datasets) whose actual storage need exceeds the licensed tier. These are the cases that will need either a license upgrade or a workflow change - moving large reference data into a SharePoint document library, Azure storage, or a dedicated file service.

The first two cohorts are common across enterprise tenants. The third is rarer but harder to remediate quickly.

The SharePoint Sibling: "Over Quota But Still Working"

A related question comes up often in M365 admin circles: a SharePoint site reports as over its allocated quota in the admin center, yet users can still upload to it. This is the inverse confusion of the OneDrive story.

SharePoint Online site quotas have historically functioned as soft caps in many tenants - the over-quota signal is generated, alerts fire, but writes are not always blocked. Tenant-level storage is the real ceiling, and individual sites can exceed their per-site allocation as long as the tenant total has headroom and Storage Management is configured to manage tenant storage automatically. This is not a bug; it is how the per-site quota was designed to behave when tenant-managed storage is enabled. The behaviour can be tightened by setting per-site quotas to a hard cap or by switching the tenant to "Manual" storage allocation.

The MC1310684 change does not touch SharePoint site quotas - it is OneDrive-specific. But the two stories often appear in the same admin conversation because both involve "quota numbers that did not seem to mean what we thought they meant." If you are auditing OneDrive quotas this month, it is a reasonable time to audit SharePoint site quotas in the same pass.

What to Do in the Next Four Weeks

A practical checklist for the rollout window:

Step 1: Run the audit. Use Microsoft's PnP PowerShell script from the MC1310684 message to list every OneDrive in your tenant where used storage exceeds the licensed quota. Capture the count, the worst offenders, and the total over-quota volume.

Step 2: Triage by cohort. Split the list into the three groups above. Departed-user OneDrives are the cheapest to remediate. Admin-elevated quotas are the most likely to need a stakeholder conversation. Genuine high-footprint users need a workflow decision.

Step 3: Clean up departed-user OneDrive footprint. Any OneDrive that belongs to a former employee should not be holding an active license open. The standard pattern is to capture the data to a preservation store and reclaim the license. Chipmunk automates this for Microsoft 365 - it pulls OneDrive, Exchange, and Teams data into your own Azure storage and removes the source so the license can be released. For the broader strategy and Microsoft's deletion timelines, see Microsoft 365 departed user archiving.

Step 4: Audit SharePoint storage in the same pass. While you have the storage-audit conversation running with stakeholders, look at SharePoint site quotas and tenant-level storage. Inactive sites, oversized libraries, and old project workspaces are the largest single source of tenant-storage pressure in most enterprise tenants. Squirrel moves cold SharePoint content into your own Azure Blob Storage and leaves stub files in place so users still see and one-click restore the files - the site stays live, the bytes leave SharePoint. See SharePoint Online archiving - the complete enterprise guide for the broader pattern.

Step 5: Decide on license upgrades for genuine high-footprint users. For the small group of active users whose storage need is real, the choice is between a license upgrade (more headroom per user) and a workflow change (move bulk content out of OneDrive). Both are legitimate; the answer depends on how the data is used.

Step 6: Prepare the helpdesk script. Brief the service desk on what read-only state looks like, how to identify it from a ticket, and what the remediation steps are. Pre-write the user comms - the first ticket will arrive within hours of enforcement starting in your tenant.

Where Chipmunk and Squirrel Actually Fit

This change does not have a single product fix, and we are not going to pretend otherwise. An active employee with too much OneDrive data needs either more license or less data - no third-party tool can give them headroom they have not paid for.

Where the SmiKar products genuinely help with the work this change forces onto admin teams:

  • Chipmunk is purpose-built for the departed-user cohort. If a sizeable portion of your over-quota OneDrives belong to former employees still on active licenses, Chipmunk captures the data into your own Azure storage, lets you release the licenses, and gives you a clean audit trail. It deploys from the Azure Marketplace into the customer's own tenant.
  • Squirrel is the SharePoint half of the storage conversation. It does not solve OneDrive quotas, but enterprises auditing storage this month commonly find that SharePoint sites are the largest reclaimable footprint. Squirrel moves SharePoint content to customer-owned Azure Blob Storage with stub files left in place. Your data, your Azure subscription, your encryption keys.

Both products are deployed as a dedicated per-customer instance, not multi-tenant SaaS, and both write into the customer's own Azure storage account. There is no SmiKar-hosted copy of the customer's data.

Frequently Asked Questions About MC1310684 and OneDrive Quota Enforcement

When does the OneDrive quota enforcement in MC1310684 start? Rollout begins in early July 2026 and is expected to complete by mid-July 2026. The original Microsoft action deadline was May 26, 2026, but the rollout window is the operational date that matters - any tenant that has not remediated by early July will see affected users transition to read-only state during the rollout.

What does read-only state mean for an end user? The user can still open and read files in their OneDrive, but cannot create, upload, or save new files there. Office autosave to OneDrive fails. Sync clients show sync errors. Email, Teams chat, and SharePoint access are unaffected - the block is scoped to that user's OneDrive writes.

Does MC1310684 affect SharePoint sites or only OneDrive? The MC1310684 change is OneDrive for Business only. SharePoint site quotas are governed separately and behave differently - they can appear over quota while still accepting writes if tenant-managed storage is enabled.

Are government cloud customers affected? No. Microsoft updated the message in June 2026 to exclude government cloud deployments from the rollout.

How do I find out who in my tenant is over quota? Microsoft published a PnP PowerShell script in the original MC1310684 message that enumerates OneDrive users currently exceeding their licensed storage. Run it against your tenant to get an exact count, the per-user overage, and the total over-quota volume.

Can I just raise the quota again after enforcement? No. The change brings admin-set quotas back in line with the licensed entitlement on each refresh. The pre-enforcement workaround of setting a quota above the license stops working. Headroom now requires either a higher-tier license or less stored data.

What is the fastest way to reduce OneDrive storage for departed users? Departed-user OneDrives are the cleanest cohort to remediate. The standard pattern is to capture the data into a preservation store you control, then release the license. Chipmunk automates this for Microsoft 365 - OneDrive, Exchange, and Teams data is captured into the customer's own Azure storage and the license is released.

Will my external sharing links break when a user goes read-only? No. Existing share links remain readable. The block is on the source user's write activity, not on recipients reading shared content.

Ready when you are

Cut your Microsoft 365 storage bill - keep your data in your tenant.