Forum Widgets
Latest Discussions
Files On-Demand for macOS QA
Hello there! 2.24.22 UPDATE: We've been listening to your feedback, and we've made some design changes. We're releasing a new version that addresses the most common themes and makes it easier to achieve the previous experience. Please read the latest blog post for more details. Two weeks ago, we posted an update about Files On-Demand for macOS and have received overwhelming feedback from the community. We have spent a lot of time reading your comments and concerns to understand how we can improve your experience on macOS. To address some of the common issues and doubts we have updated the blog with a FAQ. If you still have more queries feel free to reach out to the team directly on this thread. Thank you for your constant support and partnership! Team OneDrive Jack_Nichols gacarini Carter_MSFTMy experience with the new OneDrive Team Site Sync
Microsoft announced at Ignite that the new preview OneDrive client would sync full Team Sites, link here: https://blogs.office.com/2016/09/26/sharepoint-online-sync-preview-headlines-ignite-announcements-for-onedrive/ Shortly after this, I got an email from a CEO of one of my clients threatening to do bad things to me if I didn't make his SharePoint repository easier to access via his desktop, so I decided to pilot the new sync client with him. After downloading the new sync client and putting in the reg key, be sure to open the new client at least once so the association with the "Sync" button in Team Sites is made, otherwise OneDrive for Business will continue to be the default app when you press Sync. Once I cleared this hurdle, the Sync button brought up the new client. I was guided through the normal OneDrive wizard of selecting which folders I wanted to sync (useful when you have a 120Gb Team Site). Once done the folders started to fly in to the OneDrive local folder. Some Xs appeared on files and folders with a - (dash), once I renamed them they synced up. When you go to Settings on the new OneDrive app, it now shows all the different doc libraries you have synced and you can reselect which folders you would like to sync. Overall the speed and functionality of the new OneDrive app is excellent, and for those long suffering folks with half solutions making doc libraries accessible on desktops, I'd strongly recommend it.
Files shared with Anyone sometimes prompt users to request acccess to the file
My company is experiencing an intermittent problem where sometimes a OneDrive for Business file shared with the setting "Anyone with this link can edit" prompts the user the file is being shared with to request access. If the user tries to open the file a second time, they can then access the file without requesting access. We're wondering why that access request prompt sometimes happens and how to prevent it. It doesn't happen consistently, so we're having trouble reproducing and troubleshooting it. Has anyone seen this before and know how to fix it?
OneDrive Client, Files on Demand and Syncing large libraries
I thought I'd post some observations regarding the OneDrive sync client we've observed that aren't documented anywhere but we needed to figure out when planning a massive move to SharePoint from on-premise file servers: Limits: Microsoft documents that you shouldn't sync more than 300,000 files across all libraries that the client is connected to, but there was no documentation about Files on Demand limits, and we have observed the following: The OneDrive client will fail when the dat file that stores object metadata reaches exactly 2GB in size (%localappdata%\Microsoft\OneDrive\settings\Business1). Now, while Microsoft says you shouldn't sync more than 300,000 files, you can connect using files on demand to libraries that contain more than this. The trick here is that in this case, the total number of files and folders matter, lets call them collectively "objects". (Interestingly, when you first connect to a library and the client says "Process changes" and gives you a count, "changes" is the total number of objects in the library that it's bringing down using files on demand and storing in the dat file.) My suspicion is that since the OneDrive client is still 32bit, it's still subject to certain 32bit process restrictions, but I don't really know. What matters in this case is that up until build 19.033.0218.0009 (19.033.0218.0006 insiders build), the client would fill up the dat file and reach the 2GB limit after about 700-800,000 objects. After build 19.033.0218.0009, it appears that the client has been optimized and no longer needs to store quite as much metadata about each object, "increasing" the upper limit of files on demand. (It seems that in general, each object takes up just over 1KB of data in the dat file, putting the limit somewhere just under 2 million objects). Keep in mind, this is not per library, this is across all libraries, including OneDrive for Business (personal storage), SharePoint Document Libraries, etc. Performance: The client has made some significant improvements in performance quickly as they refine each new build, but there are some things to be aware of before you start connecting clients to large libraries: It. takes. forever. The more objects in a library, the longer it's going to take for the client to build it's local cache of files on demand copies of all the items in the library. It seems that in general, the client can process about 50 objects per second, if you were connecting to a library or multiple libraries that had 1.4 million objects, it will take around 8 hours before the client is "caught up". During the time that the content is being built out locally, Windows processes will also consume a large quantity of system resources. Specifically, explorer.exe and the Search Indexer will consume a lot of CPU and disk as they process the data that the client is building out. The more resources you have, the better this experience will be. On a moderately powered brand new Latitude with an i5, 8GB of Memory and an SSD OS Drive, the machine's CPU was pretty heavily taxed (over 80% CPU) for over 8 hours connecting to libraries with around 1.5 million objects. On a much more powerful PC with an i7 and 16GB of memory, the strain was closer to 30% CPU, which wouldn't cripple an end user while they wait for the client and Windows to finish processing data. But, most organizations don't deploy $2000 computers to everyone, so be mindful when planning your Team-Site automount policies. Restarts can be painful. when the OS boots back up OneDrive has to figure out what changed in the libraries in the cloud and compare that to it's local cache. I've seen this process take anywhere from 15 minutes to over an hour after restarts, depending on how many objects are in the cache. Also, if you're connected to a large number of objects in the local cache, you can expect OneDrive to routinely use about a third of CPU on an i5 processor trying to keep itself up to date. This doesn't appear to interfere with the overall performance of the client, but it's an expensive process. Hopefully over time this will continue to improve, especially as more organizations like mine move massive amounts of data up into SharePoint and retire on premise file servers. If I had to make a design suggestion or two: - If SharePoint could pre-build a generic metadata file that a client could download on first connection, it would significantly reduce the time it takes to set up a client initially. - Roll the Activity Log into an API that would allow the client to poll for changes since the last restart (this could also significantly improve the performance of migration products, as they wouldn't have to scan every object in a library when performing delta syncs, and would reduce the load on Microsoft's API endpoints when organizations perform mass migrations) - Windows to the best of my knowledge doesn't have a mechanism to track changes on disk, i.e. "what recursively changed in this directory tree in the last x timeframe", if it were possible to do this, Windows and SharePoint could eliminate most of the overhead that the OneDrive client has to shoulder on it's own to keep itself up to date. Speaking to OneDrive engineers at Ignite last year, support for larger libraries is high on their radar, and it's apparent in this latest production release that they are keeping their word on prioritizing iterative improvements for large libraries. If you haven't yet started mass data migrations into SharePoint, I can't stress enough the importance of deeply analyzing your data and understanding what people need access to and structuring your libraries and permissions accordingly. We used PowerBI to analyze our file server content and it was an invaluable tool in our planning. Happy to chat with anyone struggling with similar issues and share what we did to resolve them. Happy SharePointing! P.S., shoutout to the OneDrive Product Team, you guys are doing great, love what you've done with the OneDrive client, but for IT Pros struggling with competing product limits and business requirements, documenting behind the scenes technical data and sharing more of the roadmap would be incredibly valuable in helping our companies adopt or plan to adopt OneDrive and SharePoint.
