Versioning update to Document Libraries in team sites in SharePoint Online and OneDrive for Business

Roger Gu
43 Replies
Got to agree with this, and honestly, I think the defaults should be set higher with Auto-Save in the fold it doesn't take long to fill up that 500 :P.

Absolutely agree with that, the amount of versions generated by AutoSave is simply ridiculous. Goes to show you how much the dev team actually uses Office applications...

What is the reasoning behind making it impossible to disable versioning?


I have quite a few use cases in which versioning is turned off ...

So does versioning still count towards site quotas and used space against the overall SP quota?


While i agree, the autosave has hit the versioning counts hard, i dont agree with Microsoft forcing versioning on, or forcing the number to 100 (especially if you have it set lower)... make the minimum an option an admin can set at the very least... unless this doesn't count towards my space allocations.

It seems like this could cause a storage quota issue for team sites, and possibly ODFB users, with a large number of very large files that are updated frequently.  I think site managers and global administrators should be able to limit the number of versions as they deem appropriate.

Thanks for all the feedbacks. 


We understand customers may have their scenarios where versioning needs to be turned off. We will continue to support it through CSOM APIs. The ability to configure the versioning settings does not change.

Totally agree, it's ridiculous to stop us from disabling version control or to set the minimum to say 10 major versions.  There are situations where some libraries will contain large files and not necessarily Word documents.  We don't want our storage space used up by these previous versions.

Just one more headache to contend with when considering rolling out OneDrive to people, and give's us another reason to continue to use SharePoint on-prem.

Wow, this adds to a recent line of "making business level decisions on behalf of customers". (Like trying to provision o365 groups for direct reports). I feel that should be out of bounds.

I don't disagree with the idea, but like others mentioned you shouldn't change anything in my environment. You can change the defaults on NEW things. But many decisions have been made already based on that and there are business reasons in some cases for less than 100 including no versions.

It may be helpful to also reference the recently announced Storage increases to license bundles. 



Today we are announcing a 20x increase in the SharePoint Online per user license storage allocation. This will increase to 1 TB plus 10 GB per user license purchased, up from 1 TB plus .5 GB per user license purchased. Note this does not include SharePoint Online kiosk plans including Office 365 F1 and Microsoft 365 F1

Not sure I agree with this. We have had a recent experience with versions of large media files causing the quota limits on one of our libraries to be breached. It also means paying for more storage than we would like.

Thanks James, this does reduce my concern with this change a bit... but raises the question of why this change is storage space didn't go onto the O365 admin message center. I had no idea this was happening, and i watch the message center daily, and come to this site occasionally.


With that said though, i still dont want Microsoft changing settings i already have in place. If they want to role this out and change defaults thats fine by me (given the storage change), but dont touch my existing settings, and dont take away my ability to turn it off all together if i choose to in the GUI.

Doesn't seem totally right. It would be OK to change the defaults for new libraries. It would be good to allow a tenant admin to switch that on for all libraries in a said tenant with one button. But just changing it for everyone might be a disaster.

I can sense "Purging sharepoint library versions with PowerShell CSOM" will have its 5 minutes in popular google searches...

While I can see the technical and support-focused rationale for making this change, I have to agree with the others here who have said that this is an overreach by Microsoft: it encroaches into an organization's ability to make business decisions regarding content management.


Fine, ensure versioning is turned on in new libraries by default and up the default number saved to 100.  But don't set the floor at 100, and don't restrict the ability to turn off version history to an API trigger.  This will hurt content managers' ability to configure according to business need, and would obscure the ability to understand the full configuration of an otherwise standard document library when examining its settings.

In my organization, we've had a lot of issues with co-authoring documents when version settings are set low. This is a huge plus along with the recent increase in storage capacity.
The auto-save frequency needs tonned down a bit, that thing will save a cursor move sometimes. That would help a lot as well.

As an ex-MS I get frustrated when they do dumb-things, and with O365 releases this is more frequent than I'd like, but removing the ability to control versioning on libraries is out-an-out infuriating and idiotic move.

What this means to our content control and operational mgmt

Lets start in the basement...


Resetting version floor, and disabling controls on existing site libraries breaks all the business rules agreed and applied by organisations already in practice


Firstly each incremental version retained immediately adds to blow-out storage consumption across a site - because despite SP being able to handle differential updates on files Microsoft does not enable this on Office 365. 


Why? Well document size on avg is trending 20 - 50mb per item; images, PowerBI reports, GIS data-sets for mapping and videos are all into Gigs -  and SPO Modern UI notes every typed change in display-panel as a version - I can go on


[there's some real-world examples below for those interested]


Second is more insidious, Microsoft is forcing an organisation to bare an operational risk on unnecessary retention of information *after business rules have been put in place*.


The combination of this arbitrary increase of versions and change in control, coupled with AutoSave defaulting to on cause every document opened to be versioned and retained (unless specifically locked).


What this means Microsoft are putting your company at risk of breaching data-disposal rules for critical items - by reset modified dates and versions kept, forces items to now be included in available set of documents and content admissible in a discovery, or required to be handed over in event of a legal hearing. Thanks MS


Q: Who in Microsoft has contacted each company using their service, and got a written approval to change their retention policy and sign off the operational risk profile for the organisation?

Basic Storage Mgmt Examples

Simple working example 1: I upload load a short-video as .mp4 (~300MB).

In modern library ui I add

  • a Title (v1),
  • business function data (v2),
  • select 3 publishing key-words - (v3 - 6),
  • presenter (v7)
  • and publish.

Total storage consumed is 7x 300MB = ~2200MB or 2GB.


Actual working project example 

Project - average document turn-over in medium sized business change-mgmt project

  • 500 - 700 items + evidentiary emails and comms.
  • Approx. 68% of items are collaboratively edited
  • avg no. versions in history 22 -but not retained
  • Average size (Word = 28MB, PowerPoint = 60MB, Excel = 15MB, PDFs = 19.5MB, support content >100MB per item)

Project site setup

  • 4 libraries, 
  • Minimum of 6 metadata attributes added to items.
  • 3 inherited automatically; 3 required in life-cycle stages
  • library versioning tuned to 10 major vers, 8 minor;

FastForward: Apply this global reset to 100 versions, compound issue with applied Office AutoSave on by default...


Q: How long do think the increase we're getting will last?


The cynical side of me says this is an easy way to gouge for storage fees, because you can guarantee the tenant storage increase wont be sufficient with average file-sizes and Microsoft saving full-copy for every change in metadata.


I have other great examples where this combined with AutoSave would breach record controls, and create a massive legal risk to businesses


In short - this is beyond dumb.

Hi Jonathan,


Is it not changed that it only increments with the changes and not the full size anymore? 

Else i completely agree with your statement. But i thought this changed.


This is not agreeable. We are a small non-profit, and increasing the limit to 100 is an overkill.


OTH I am also unable to understand why the version is bumped when a document is opened? When I open a document from a synced folder on my PC, just to view it, and then close it, it saves it and version bump occurs. The site then shows the history as me having edited the document and people start calling me on why did I change it, when I haven't actually. This is getting insane. 


Also, could someone help me understand how minor vs major versioning occurs on auto-save?

Technically you are correct (and I should probably amend my posting to reflect the following) - Shredding and differentials were introduced in SP2013. It is enabled in the database. SPO shows and provides full details as though item in the versioning and history is complete item - hence storage reporting in version history and on site-dashboard reflects equiv. of full copies retained.


Unfortunately your storage quota reflects this usage too *not* actual data-storage (I did some checking on last year to be sure of what is saved vs what is shown).  What is happening is a disconnect in representation *and* behaviour of the apps dealing withe the documents :(


..I'd already written a large entry - I didnt want to muddy waters with long detailed waffle on actual vs registered on reporting.

Not sure I understand when Office AutoSave does this either but I've seen this in all my customers since it was introduced earlier this year -  it is causing havoc with processes where the preservation and tracking of last-accessed and modified is important.


SP has more advanced features around locking items as records (in-place) and other controls which can be applied like AIP/DLP *but* we shouldn't have mitigate behaviours by introducing yet more services and tools for something that should not happen i.e. if i make open a document, but make no changes  when it's open, it should not update version and the modified date.


The only way to guarantee it does not happen appears to be force check-in/out and (or) have mandatory metadata in a library - this locks the document prior to committing edits, and then you can 'discard check-out' and have no impact *but* then you lose the ability to coauthor on any document in said library :(

It is my understanding as well that there is a disconnect between storage reporting and storage usage. What I haven't seen answered is whether you pay based on the reported storage use or the actual storage use.

Anyone with the answer?

I can't see how Microsoft have the right to amend a library versioning settings to a new default, IF the users have amended the value from the default to meet their specific needs. 

We have a number of projects that have large files and in some cases the Project Managers have reduced the version limits to 10 to save space. That is their business decision. 

Following this change will I need to notify all our Site Owners to re-review their Version settings (no small task for a company of 40,000 employees.

This is a significant issue for us, we have viable use cases and policies which support no versions.  


Why are you enforcing technology on to business process?  We do not plan on using apis.  


This is bonkers, please reconsider before you disrupt and break things you have no business touching.  



For commoners that don't use APIs.....?


Why make this a tech based hack?  Service folk are busy enough.  


Please reconsider this insanity before it is too late

Given the way auto-save works would it be better to use Major and Minor versioning by default. That would increase the version capacity to account for auto-saves.


Major/minor versioning is for publishing rather than the capacity of versions. Publishing a minor version to a major version is a workflow, that requires user's explicit action and may have specific permission requirement.

To keep our experiences great, we … will no longer support the ability to disable versioning or configure it to retain fewer than one hundred versions.”
--> It’s “great” to lose control of our existing environment! :(

So, we can hire devs, to write custom code, to put our settings back the way we had them. How about *your* devs just leave those UI controls in place? Easier for both of us that way.

Yes, better defaults are an excellent idea!
Yanking admin control on existing systems is not.
Data deduplication tech on SharePoint storage would help alleviate some of the concerns, but for compliance / privacy issues. etc. still needs to be an easy way to disable. Maybe even a flow that sends owners of sites a list of libraries and an option to enable etc.
Why remove users their choice? The default to 100 fine. but shouldn't my users be enabled to turn it off wishing to do so? shouldn't they be able to reduce or increase the number if wishing to do so? Great that there are improvements , but they should lean more towards flexibility over inability.

Mixed feelings.

If thinking of the main idea of protecting information and way of guarantee that users can't disable versioning and therefore we may always support them recovering data (great for onedrive), we have some use cases where we centrally disable (or reduce) versioning. For example, on the site assets library: This is where the default notebook is created, and we had several problems with big notebooks versioning.

Quotas fill up extremelly quicly in this case.

It's important that there is an easy way to manage versioning on sharepoint sites, groups and teams, or even disable it by the site owners. 100 versions is an aggressive number with high impact on quotas, let us at least specify tenant wide a minimum number of versions to enforce.

In various articles I read about this, including this one, "all Document Libraries" eventually changes to "all libraries".  Is this versioning going to strictly be limited to Document Libraries?

This change only applies to Document Libraries that are in Team Sites(both Groups-connected and not connected). In other words, other types of libraries or Document Libraries in other types of sites won't be affected.

Though I think you miss my point. Major and minor does not need a workflow. It generates capacity. Items like autosaves should be minor versions. Easy to purge a batches.

The problem is that minor versions have a limit. When it hits the limit, users have to "publish" to a major version in order to continue to save. Depending on the client application that saves on behalf of the user, the publish gesture may not always be available for the user in the middle of save. Then the user will get stuck.

OneNote is a tricky one because it has it's own versioning and controls, ignoring SharePoint really, and the file-format is a compressed series of XML files and folders presented as .one.

Suffice to say that you never have forced check-out on libraries with OneNote files, and its best practice to leave library versioning as major only (or completely turned off) on library it is in.

OneNote (and its content format) act like a wiki with instant last character save, and multi-user editing options - it does not understand the concept of publish major/minor versioning or strong document mgmt. controls.

[saying that I love OneNote, it's a fantastic app and works really nicely - as long as you let it do its own thing and don't try to override using SP DMS controls]

Not sure I would agree with this assertion Roger, because fundamentally all libraries are based off the common root library template. Microsoft as deprecated and removed many of the branching variations of libraries over the last couple of years and have standardised on one multi-purpose library.

In new Communications sites and Modern Teams site templates you only have 1 library option available (until you re-enable or create a new one - which you can't do via the UI anymore) - so it's easy to say that it's likely to only be in site based on Modern site-template, but not guaranteed, because its the same root template as std document library in any site - including Classic site templates. So the options on global changes are script to a single set of specific site-templates (unlikely, because we know they will do at least 3 - communications, modern teams and OneDrive) *or* update the root app - which impacts all inheriting from it.

I suspect they'll go global, because its marketed as "enable great experiences"...

OneNote versioning works differently from other documents regardless the library setting, so this change won't affect OneNote.


I'm also not convinced that the site assets library (which is a doc lib) won't be updated to default forced versioning and thow us back in a situation of over consumption of quotas due to files in this library (as the default group onenote).

Despite Onenote having it's own versioning control, this was never taken in consideration on sharepoint doc libs, hence our actions to limit versioning on site asstes library - which we could do easily. 

Will we be able to use Information Management policies to remove existing versions and retain the final document for archive purposes?  We'd like to offer this as an archiving solution for our users who may not want all previous copies of a final document.  Thank you.

I am not sure about the information management policies you mentioned. Depending on your scenarios, there are a couple of options I think:
1. if there is an approval process that contributors(users who upload and edit files) need to be involved, then why not just ask them to remove old versions.
2. if you want the library to have versioning off and contributors have no option to have versions(they need to make sure what they save is what they want to keep, no way to recover), you can either create doc libraries outside team site, groups and OneDrive for Business, or create a tool using CSOM to turn off versioning.
In essence you are confirming that:

Firstly - That there is no longer an option to chose and apply appropriate business rules, and that Microsoft is changing information and retention management policies (the business decision kind of policy, not your technical implementation kind) for all companies using this service

Secondly - customers now have to get a developer to build tools to re-apply a business decision (i.e. The appropriate level of versioning) on all new sites.

Q: Please confirm if this will be applied to sites running classic site templates or not?
Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
How to Prevent Teams from Auto-Launch
chenrylee in Microsoft Teams on
29 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
9 Replies