SOLVED

Syncing SharePoint sites with OneDrive

Iron Contributor

Hi all,

We're in the middle of migrating our network drives from our local storage to SharePoint Online. Our computers are windows 10 education with office 2016. We are about to change to windows 10 subscription with office 365. We also use MFA

We have a lot of problems using OneDrive sync (stuck on processing, office cache issues, errors like 0x80070185 open file the cloud operation was unsuccessful and more). We found that using SMB over WEBDAV seems to help but according to Microsoft support (which wasn't helpful btw) their engineers don't recommend it.

My question is: What is the best practice for such a case? is there a best practice regarding the hardware \ software \ antivirus in my case? I know there are limitations to what to sync but as an organization we try to follow those to make sure we can work with the client to the best of it's abilities

Thanks in advance.

10 Replies
My suggestion is to treat SharePoint more like online network drives and teach your users to use the sites and the cloud and not resort to old methods and syncing all those files across all devices so they look like drives.

My current company now uses Dropbox that way and never setup files on demand or whatever it’s called in Dropbox and anytime someone uploads 4000 files gigs on size that’s going out to everyone wherever they are. It’s just bad design. Files on demand makes this less of an issue but I’m moving the company to SharePoint and Onedrive and syncing these most definitely will not be the default. It’ll only be taught as an option for those that must have offline sync as an exception but large document libraries have sync turned off.

It’s a behavior change but you have to sell it with all the other features you get with it ( sharing links, alerting, coauthoring, anywhere access with web / client less editing, built in file render etc, file analytics, audit logs, version history.) the list goes on. There is just so much more to it than simple file shares and giving users that old way will just keep them using it as some basic file dumping ground.

It seems rough and you will get some pushback at first but you don’t want to reinvent the 25+ year old way of doing things, use the opportunity to change the thinking and the habits.

So you're suggesting to map those sites as network drives which will replace their old network drives.

Which means I'll need to figure out a way to make deploy those new network drives or in turn deploy a script that connects to the share and adds it as a quick access.

Also this means losing the search index ability to index the synced metadata to help the users find files more quickly.

No I’m suggesting don’t use network drives at all. The concept in general do away with it.
I must have completely read your original request wrong or it changed lol.

If you are using metadata the sync clients really don’t handle it very well. Turing off sync and forcing everything online is the way to go these days unless people just have to have offline sync capabilities then I usually try to tell them to copy files to their onedrives or use checkout and work on checked out files instead offline then check them back in.
Are you suggesting we use the web browser instead of the file explorer? This means using 2 different platforms for working with files. Web browser for SharePoint and file explorer for OneDrive and personal files.
it doesn’t have to be all web. If you make use of office clients when you open items they all show up in recent lists. Also you have access to all your SharePoint locations from within the clients. Also on the web. You can get to them many ways and search from office portal home etc.

Anyway just trying to say I stay away from sync or network shares via explorer or anything resembling old school work habits at all costs.

Hello @RahamimL,

 

I agree with @Chris Webb. Adopting modern work habits for modern tools is more desirable than maintaining the old school approach to document management.

 

SharePoint Maven has an excellent blog post - Solve all your SharePoint sync issues by using the new OneDrive Sync Client - that is worth reviewing and confirming settings in your tenant. 

 

I hope this helps.

 

Norm

 

 

I also agree with @Chris Webb. I just hope my manager would agree with me as well. It'll be hard to move someone from shared network drives to working on files from a web browser \ office apps and syncing only specific folders.

best response confirmed by RahamimL (Iron Contributor)
Solution
Don't focus on just the files part. Spin it as here is your Team in Microsoft Teams, if you have it, or SharePoint Team site, with news this and here are you're files, and this is how you can share them with other departments while maintaining privacy to just your department on the files etc.

This is just my opinion but I've always gone the approach depending on your org structure, is having a Public communication SharePoint site for Each departments News and "Global" file document libraries, where files that should be available to the org are, for instance, HR's comm site would have benefits documents etc. in them, where the whole org has access.

Then you have a Private Team site for each department where their own files are, if they need to share the file to just a few people as exceptions you have the Share button to use.

This is usually the approach I take, sense you usually have Global drivers with no security, and each department has a folder, and another "Private" drive where each department can only see / access their own folder, these get moved into Private Department / Team sites.

This leads more towards Team area's and less about just Files and folders.


But there is another wrench here, where if you have a repeatable type of document repository such as projects, or customers where documents are consistent across the board but separated by an entity you start to use a central single repository and use metadata, so that finding these files becomes much easier. But I'm kind of going off normal standard network driver migrations as most of the time, the use case is how I laid it out above.

I have to admit you convinced me with your first post.

If the way we want to use office 365 is with cross platforms devices (workstations \ mobile devices \ home computers), we need to make the user realize that the best way for him to work is: "How does it work on your mobile device". This means that since in your phone there is no file explorer to sync, they need to either download another app \ using the browser to get to the file they need to work on.

Also, like you said, there comes a time where the IT just stands on it's feet and says: "This is how you need to work and that's it!". We need to remember social media apps didn't come with any manuals. Yet, people swim in those apps like pros.

1 best response

Accepted Solutions
best response confirmed by RahamimL (Iron Contributor)
Solution
Don't focus on just the files part. Spin it as here is your Team in Microsoft Teams, if you have it, or SharePoint Team site, with news this and here are you're files, and this is how you can share them with other departments while maintaining privacy to just your department on the files etc.

This is just my opinion but I've always gone the approach depending on your org structure, is having a Public communication SharePoint site for Each departments News and "Global" file document libraries, where files that should be available to the org are, for instance, HR's comm site would have benefits documents etc. in them, where the whole org has access.

Then you have a Private Team site for each department where their own files are, if they need to share the file to just a few people as exceptions you have the Share button to use.

This is usually the approach I take, sense you usually have Global drivers with no security, and each department has a folder, and another "Private" drive where each department can only see / access their own folder, these get moved into Private Department / Team sites.

This leads more towards Team area's and less about just Files and folders.


But there is another wrench here, where if you have a repeatable type of document repository such as projects, or customers where documents are consistent across the board but separated by an entity you start to use a central single repository and use metadata, so that finding these files becomes much easier. But I'm kind of going off normal standard network driver migrations as most of the time, the use case is how I laid it out above.

View solution in original post