Microsoft Word attempts to save to Sharepoint instead of local drive

Hi All,

The issue has already been escalated to the escalation team. They are actively working on it. I understand it is inconvenience for all of you regarding this issue. We will let you know the progress once we receive any updates from them.

Thanks for your patience.

Sky

Just to confirm, at the time of posting:

Regardless of Office Sync opt-out settings, all Office 2016 applications are exhibiting one of two opposite behaviours when opening and saving files directly from / to a local instance of a OneDrive folder, depending on whether the file is created inside or outside of that OneDrive folder:

Steps to reproduce:

Case 1: Office file is created outside of the local instance of a OneDrive folder and moved into it.

   1.) Create and save an Office document in any local folder outside of the local instance of a OneDrive folder.

   2.) Using Windows Explorer, move the file into the local instance of a OneDrive folder.

   3.) Open the file <- Only the local instance is accessed, not the online instance.

   4.) Save the file <- Only the local instance is accessed, not the online instance.

This is the expected behaviour: all syncing is performed as a background task by OneDrive.exe, not the Office application.

Case 2: Office file is created within the local instance of a OneDrive folder.

   1.) Create and save an Office document directly within the local instance of a OneDrive folder.

   2.) Close the file.

   3.) Open the file <- Only the online instance is accessed, not the local instance.

   4.) Save the file <- Only the online instance is accessed, not the local instance.

This is completely undesired behaviour. Office Sync opt-out settings are being ignored and all syncing is being performed at the time of opening and saving by the Office application, not OneDrive.exe.

I don't hold out much hope for a fix for this issue, as I believe it is a feature not a bug. I suspect that it is related to the new so-called 'AutoSave' feature which is built into the most recent versions of Office 365.

The following quotes are taken verbatim from the Office support webpage (https://support.office.com/en-us/article/what-is-autosave):

• "What is AutoSave? AutoSave is enabled when a file is stored on OneDrive, OneDrive for Business, or SharePoint Online. It automatically saves your changes to the cloud as you are working."
• "Can I turn AutoSave off? No. However, you can turn AutoSave Off for a file, and the program will remember to keep it off every time you reopen that file. If you switch it back on for a file, it will remember to keep it on for that file."

AutoSave enforces precisely the same behaviour we are now experiencing (Case 2 in my above posting above), whenever an Office 365 application performs any file operation to or from a OneDrive folder (either the local or online instance):

• Within the Office application, the user must be signed-in (with their OneDrive folder credentials).
• All file operations are performed directly to or from the online OneDrive folder instance (via the internet).
• Online file changes are then synced back to the local OneDrive folder instance.

In addition, AutoSave continuously monitors user activity within the Office application (e.g. text entry, formatting, etc) and immediately saves an updated version of the file directly to the online OneDrive folder instance (via the internet) as soon as any such activity is detected.

AutoSave cannot be globally disabled. You may be asking yourself why such a privacy-invasive feature cannot be globally disabled. I suppose that depends on your point of view. An optimist might say: "This AutoSave feature is so awesome, MS figured no one could ever want to disable it", whereas a cynic might say: "AutoSave provides MS with real-time, detailed usage monitoring tied to a known user account, and usage data is the new oil". You can join the debate here: https://office365.uservoice.com/forums/264636-general/suggestions/19082773-disable-the-new-autosave-by-default-as-it-can-lea

In light of the above, our quest for a fix to this current issue is bound to be short-lived. MS is clearly shifting Office towards the 'Google Docs' business model, and that change is coming down the road whether we like it or not.

The good news is: AutoSave CAN be deactivated on a per-file basis, and I can confirm that once it has been disabled for a particular file, then all Office applications once again respect the opt-out setting in the 'Use Office 2016 to sync Office files that I open' checkbox for that file, and it is possible to open and save that file directly to or from the local OneDrive instance. OneDrive then syncs the file in the background, just like it used to.

At the time of posting, AutoSave is only available to Office 365 users on the Monthly update channel (current Office version = 1801). It is not available for users on the Semi-Annual update channel (current Office version = 1708). You can check which update channel you are on by looking in the Product Information section of the Account page.

I suspect that the reason some of us are seeing strange behaviour is because we are stuck on the Semi-Annual update channel, in a scenario whereby the latest version of OneDrive (or FileCoAuth.exe to be exact) is enforcing online-only file operations, and yet our current version of Office 365 (1708) does not give us the option to disable this behaviour per file.

To remedy the situation, I can offer 2 optional workarounds:

1.) Force an Office 365 update.

These steps will force your Office 365 to update itself to the latest version from the Monthly update channel, after which you can simply disable AutoSave on a per-file basis:

• Open a command prompt with administrator privileges and execute the following commands:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration /v CDNBaseUrl /t REG_SZ /d "http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60" /f

reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration /v UpdateUrl /f

reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration /v UpdateToVersion /f

reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Updates /v UpdateToVersion /f

reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Office\16.0\Common\OfficeUpdate\ /f

"%CommonProgramFiles%\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user

• Note: system admins should simply be able to switch update channels centrally at the company level, or else deploy these commands as a script on remote machines as needed.

2.) Create an intermediate virtual network drive.

Regardless of which Office version you're on, this trick creates a local virtual network drive which points to the local instance of your OneDrive folder. When you access an Office file from this virtual drive, it fools Office into thinking it's accessing a normal (non-OneDrive) folder, and so it will just open and save the file locally rather than enforcing any online syncing. However, the OneDrive client will continue to perform online syncing in the background as normal. The virtual drive is persistent, i.e. it survives reboots. Create the virtual drive as follows:

• Open a command prompt (without administrator privileges) and execute the following command, substituting your [Desired Virtual Drive Letter], [Current OneDrive Drive Letter], and [Current OneDrive Path] as appropriate (without the square brackets):

net use [Desired Virtual Drive Letter]: "\localhost[OneDrive Drive Letter]$[OneDrive Path]" /persistent:yes

• For example:

net use P: "\localhost\C$\Users\MyUserName\OneDrive" /persistent:yes

• To get rid of the Virtual Drive, you can just right click it in Windows Explorer and select Disconnect.

Cheers

Jeff

Hi Everyone,

We have checked with Onedrive team and this appears to be a known issue for which fix is created and would be rolled out in future release after testing internally. Please always keep your OneDrive in the latest version. 

Regards,

Sky

Are you saying this is a currently known issue with a known fix that will soon be rolled out, or that it's a know issue but a fix will need to be created, tested and rolled out?