05-12-2017 08:56 AM
05-12-2017 08:56 AM
We are running an on-prem Sharepoint 2013 standard edition and we recently upgraded our users to O365 Office 2016. Soon after the Office 2016 upgrade, many users are reporting that they are having problem with saving files back to Sharepoint after editing them. When a user tries to save a document after editing, an "Upload Failed" error message gets triggered - "This file is checked out by another user" - the error message also shows a user ID that essentially is the user that is trying to save the file back to Sharepoint. It seems that somewhere in between, the session was lost and Sharepoint cannot recognize that the user who is trying to save the file is the same user that started editing (or checked out) the file. The frequency of this issue is intermittent but seems to happen more with power users that have many MS Office document opened at the same time. We have been in contact with Microsoft team for months, but so far no resolution.
Has anyone experienced this issue and care to share the resolution?
10-26-2017 02:46 AM
Did you ever figure this one out?
11-15-2017 03:51 PM
11-15-2017 03:51 PM
Our office recently updated to o365 and we are seeing this same issue. We thought this was network vs remote employees but one of our network employees is having an issue with a file that is shared among a large number of users. All users have read only access to the file except a single person and the file also has a editing password embedded into it. If you open it in Teams you don't get the password prompt but opening in the windows application you must respond to the password prompt or click read only to view the contents of the file. The file owner can go an entire week without issue but then all of sudden it starts giving the error every time they try to save. I have not been able to figure this one out either.
11-15-2017 11:51 PM
Regarding this issue we found “in our case” that upgrading Office release to (1705) from in many cases 1609-1611 and probably even older in some cases somewhat decreased this happenings.
However the problem still remained for many and @ this time we encountered another issue in our environment an actual error, our “group policy” did not apply as it should, the start page got the right zone “Local intranet” but as soon as users moved on to another site in the farm these sites where executed in “unknown zone”.
After some tests and listened to rumors we found that or domain just where to short so adding the whole url in our gpo did the trick, we always used like *.domain.com and this never been an issue before but this farm only has two chars in the domain name so our gpo where like *.xx.com and rumors told us that it should be more chars for stability so we entered more chars in our case the whole url: intranet.xx.com & problem gone.
Hope this can help at least someone out there.
01-24-2018 04:02 PM
We bypassed riverbed for all sharepoint traffic and it seems to have fixed it.
08-24-2018 08:28 AM
We have a similar problem, but it is intermittent. Occasionally a user cannot save a document back to SharePoint after editing it in Office. SharePoint (or Windows?) forces the user to save an Excel, Word, or PowerPoint document under a different name, or in a different location.
We end up with multiple copies in SharePoint with different names, or else the user saves it offline and sends it to me to enter their changes in the SharePoint version. Does anyone else have this problem, or can you suggest a fix? I am recommending users edit in the browser as much as possible, but occasionally they need the full power of the Office application.
We have also noted that when editing a SharePoint Excel document in Excel, the "Save" icon does not have the Shared indicator--the circular arrow on the icon. Usually it saves just fine, but occasionally we get the error and cannot just "Save" but must "Save As."
We don't use Riverbed. We are on SharePoint online using Office 2016 or Office 2010.