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

Microsoft
44 Replies

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.  

 

IT AINT BROKE, DONT FIX

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.