![]() If the coiokie info Office uses doesn't meet the server's Auth If there are no cookies, Office makes the OPTIONS call anonymously. Office will try to use any auth cookies it can from the users machine when making the OPTIONS call to auth with SharePoint. When not using forms based auth, Office expects one of 2 responses to it's OPTIONS call: HTTP 200 or HTTP 401. Next it will make an OPTIONS call to establish what network methods it's allowed to use with the SharePoint server (GET, OPTIONS, POST, HEAD, PROPFIND, etc).įor Forms based Auth, the OPTIONS call is what is important. Office will make a CONNECT call to SharePoint to start the network conversation. After the Office client application starts, ALL of the network traffic related to opening the file from SharePoint happens in the Office MS WORD 2016 CANNOT OPEN DOC FILES CODEWhen a User opens a file from SharePoint, their is code on the SharePoint page that starts the Office client application. If you have problems opening files from SharePoint On-Prem after switching to Forms Based Authentication, it's likely your Authentication form isn't configured for MS-OFBA (Microsoft Office Forms Based Authentication). ![]() This is the same as unchecking the "Use Office applications to sync Office files that I open" setting in the current OneDrive client. If you set FSSHTTPOff=1, then you're forcing Office to use WebDav. Office has two processes it follows when interacting with files stored in SharePoint, WebDav and the Simple Object Access Protocol (SOAP). We have tried all settings in trust center, trusted locations, adding the Sharepoint site to local intranet zone, trusted sites zone, clearing cookies, but nothing seems to make a difference.įSSHTTPOFF is never a solution of any kind. This differs from previous versions of Word which send the cookie with all requests, as would be expected. Therefore the server returns 401 Unauthorised, and Word shows the error "Sorry, we could not open.". ![]() But then Word calls a POST method on /_vti_bin/cellstorage.svc/CellStorageService,Īnd does not send the FedAuth cookie in the HTTP header. On subsequent requests to open documents using ms-word URIs, log files show that Word calls the OPTIONS method on the document, sending the saved FedAuth cookie, which works fine. It appears that once the user clicks "Enable editing" to leave protected mode, changes a document, saves the document back to the Sharepoint server, and closes Word, the problem starts happening. The first time they open from a Sharepoint site, they see the Forms auth window, login (with "Remember me"), and can access the document successfully. Users attempt to open files using ms-word URIs. This is affecting us for Word on Sharepoint 2013 Foundation with Word versions 1812 through to current insiders fast version 1901 (build 11220.20008) too. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |