1

Here’s a perplexing one. Small M365 shop with less than 10 users. They are an engineering firm, so in addition to the standard M365 suite they also have some specialized software. This issue surrounds Bentley MicroStation, which creates drawing files with the .dgn extension. They’ve been on M365 for 5 years. Just last week, this problem began.

All users are Windows 11, full up to date. All users have access to a folder in SharePoint, and they are syncing it to their desktop file explorer using the OneDrive sync client app. This has been working fine - of course they cannot concurrently have the same .dgn file open, but they understand this and instead they take turns working on a file…one user makes changes, saves and closes, and then another user opens it up to review the changes, make more changes, etc.

So, here’s the scenario:

User A makes a change to a .dgn file, saves, and closes. In file explorer he watches the file’s icon change to the circular arrows indicating syncing for just a couple of seconds before it switches back to a green checkmark. We can then go into the browser and see the latest version of the file in sharepoint, with the “last modified” column saying “a few seconds ago.” The file has synced up to the cloud.

User B goes into file explorer, to the same folder, and he doesn’t see the latest version of the file, in spite of his OneDrive client running, saying “your files are synced.” Even if User B waits for a period of time, even half an hour, the file doesn’t sync. User B opens the file he can see, makes changes, and of course now we have contention, so we end up with 2 versions of the file, with user B’s name appended to the filename on the one User B saved.

Now, if we quit the OneDrive desktop client and restart it, it detects the changed file and syncs it up.

What’s weirdest is that User B can then open the file, make changes, and click save, and by the time I get back down the hall to User A’s computer, User A’s computer has already synced the changed file down. So User A’s OneDrive client is somehow picking up the change and syncing it down, while User B’s computer just sits there and doesn’t sync when the file gets changed.

Any idea how to force the OneDrive client on User B’s machine to more vigilantly be on the lookout for changes to files in SharePoint?

9 Spice ups
2

Are both user A and user B syncing exactly the same SharePoint content?
Or is user A syncing (say) one sub-folder of a document library, and user B syncing the whole library?

Have you tried resetting the OneDrive sync app for user B?
(This isn’t really an answer or explanation, but it’s a common cure-all.)

5 Spice ups
3

Both are syncing the same, whole document library, yes.

Good idea on resetting the OneDrive sync app. We’ll try that.

3 Spice ups
4

Unfortunately this is a common behaviour of the OneDrive client. There’s no permanent fix (that I’m aware of), but a user can force the issue by clicking on the icon in the system tray, hitting the settings (gear) icon at the top right, and then Pause Syncing (doesn’t matter what duration) then immediately resume syncing. This effectively does the same thing as closing and re-opening the OneDrive client, but anecdotally seems to be a bit quicker.

There was a previous issue with OneDrive (that as far as I know has been fixed) where it would randomly write some bad NTFS data, which would cause various issues including evaluating what needed synced. This could be corrected by running chkdsk, so if you’ve been running OneDrive for a couple of years without a wipe and reload, this may still be a lingering issue. You’ll see entries like this in the chkdsk output:

Attribute record (C0, "") from file record segment 77D27
is corrupt.

It’s also worth running the following commands just a matter of course since windows updates seem to introduce image issues way more of late:

sfc /scannow

dism /online /cleanup-image /restorehealth

It used to be the case that everyone recommended running sfc /scannow, and 99.9% of the time, it never did anything. These days, more often than not I see the message “sfc found corrupt files and repaired them”.

5 Spice ups
5

I agree with @chris-kelly, the Pause sync and then unpause seems to do the trick for my users as well. Doesn’t make a ton of sense but then again not much does these days.

2 Spice ups
6

How big is the SharePoint library? We’ve seen issues with very large (over 100,000 files) librariess syncing slowly. While we have clients with Microstation, they use Lucidlink for file storage rather than SharePoint

2 Spice ups
7

I tried the pause/unpause and this didn’t seem to give it the kick it needed to sync.

2 Spice ups
8

62k files in the doc library - so not exceeding 100k. Thanks, though.

1 Spice up
9

Thanks, we’ll go down that rabbit trail if we can’t find anything else. As I mentioned in another reply, pause/unpause doesn’t seem to force it to sync up.

1 Spice up