Forum Discussion
OneDrive Client, Files on Demand and Syncing large libraries
Update:
I recently got to have a conversation with some people from the OneDrive engineering team regarding an issue we were having that stemmed from a recent code update to SharePoint that impacted the way OneDrive handles document library content (our tenant is on First Release).
In short, our permissions model was specifically designed to take advantage of client behavior wherein, if a user had access to content, but NOT the parent folder, OneDrive would not try to represent that content in the local Files on Demand cache file and would only process the data that the user could navigate to.
We had various reasons for doing this, from effectively hiding content that was stale or archived, reducing load on OneDrive iOS clients, as well as reducing workload on the OneDrive Windows clients.
This behavior was driven by what Microsoft apparently saw as a problem that they referred to as Gap Folders, folders whose permissions had a gap from the parent, and because of this, the Sync Client couldn't synchronize content that had a gap in permissions.
Well, they recently pushed a code update to Sharepoint that addressed this issue, allowing the Client to have an understanding of all content in a library that a user has permissions to, which undoubtedly solved sync issues for many customers. Unfortunately this introduced a huge issue to us, as over 80% of our content is considered Archived and should never be synced locally, even though it's routinely accessed for historical content and we had taken advantage of the SharePoint permissions model and the client to manage this is a way that to us was an elegant and easy to manage solution.
If you're using gapped permissions in a similar manner with clients actively deployed, be aware that there are code changes coming down the pike that could cause clients to get overloaded and fail if they are suddenly presented with significantly more data that had been planned for.
They are actively evaluating this issue now, but I don't have an update yet on what the path forward will look like, as there are legitimate use cases for both wanting the client to see gapped content and not.
- dustintadamMar 29, 2019Iron ContributorNot at the moment no, though it’s on our roadmap. We are in early planning stages for an RMS rollout, part of the problem is that we are leveraging a wide number of other Microsoft technologies such as Cloud App Security, and we want to make sure that we take advantage of the full ecosystem across CAS, Azure RMS, SharePoint, Windows Information Protection, etc. I’m sure once we get that far I’ll have more to share :)
- Fernando MeloApr 23, 2019Brass Contributordustintadam This is a great write up. I am wondering if there is a way to prevent users from syncing libraries with the ODFB client, or maybe a way to limit what libraries are ok to sync with and others not.
Document library cleanup is something i have been dealing with for years. my thought is that if you have large libraries with so many objects in them, that it would make sense to start moving stale content to a different library?
Now that I am thinking about it, would creating an active document library and an archive document library serve you? For example, you could technically use the Information Management Policies to move documents that haven't been touched in X amount of time to an archive library, thuse freeing up the total amount of objects? With the new persistent urls in SPO, you wouldn't need to worry about links breaking.
Perhaps i am completely oversimplifying the complexity of your library. But if microsoft isn't providing a way to limit what you can sync to, then we would have to macgyver this out?
Nando- dustintadamApr 23, 2019Iron ContributorHey Nando;
As it happens I managed to get in contact with the product development team and they’ve been working with us over the last month or so regarding sync and large libraries.
Long story short: they are actively making changes to the sync client based on our feedback and use case that will see the upper limits raise fairly substantially. In addition, there is a neat little trick we learned from the SharePoint product team:
If you don’t want to restrict sync for an entire library, but only a subset of content inside a library, you can set “Restricted View” permissions on a parent folder, yet still add higher permissions lower down in the tree. This causes the sync client to ignore all content below the Restricted View permission, effectively allowing you to segregate content inside a library that you want to allow the local sync client to bring down.
We have an NDA with Microsoft so I can’t disclose any detail, but large library sync will be getting better within the next few months, with more to come later in the year.