May 15 2018 05:35 PM - edited Jul 12 2018 11:22 AM
The announcement has been moved to New Updates to OneDrive and SharePoint Team Site Versioning.
May 15 2018 06:08 PM
May 16 2018 12:08 AM
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...
May 16 2018 07:16 AM
What is the reasoning behind making it impossible to disable versioning?
I have quite a few use cases in which versioning is turned off ...
May 16 2018 01:40 PM
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.
May 16 2018 01:50 PM
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.
May 16 2018 02:25 PM
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.
May 17 2018 12:34 AM
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.
May 17 2018 05:28 AM
May 17 2018 05:38 AM
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
May 17 2018 05:39 AM - edited May 17 2018 05:42 AM
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.
May 17 2018 05:51 AM
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.
May 17 2018 06:19 AM
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...
May 17 2018 07:42 AM
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.
May 17 2018 08:19 AM
May 17 2018 09:07 AM
May 17 2018 08:08 PM
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.
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?
Simple working example 1: I upload load a short-video as .mp4 (~300MB).
In modern library ui I add
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
Project site setup
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.
May 17 2018 10:21 PM
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.
May 17 2018 11:06 PM
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?
May 17 2018 11:42 PM
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.