Cannot Edit And Save Documents In Client Program or Open From Explorer SharePoint 2013

The users complain from 2 problems, so let's describe the situation:

Problem 1: Document Edit/Save in client doesn't work

When user clicks on a document link in document library to open in edit mode (through a browser popup or from client program), the client program (for example MS Word) opens the document. However, user will not be able to save back to server, because when he clicks on ‘Save’ button, it will display the ‘Save As’ dialog box where user can only select local destination to save the file. Also, if it was a Microsoft Office document, user can click on File tab and sees that the document is in ‘Read Only mode’ even though he opened it with edit mode.

Problem 2: Open With Explorer doesn't work either!

Here are the environment details:

• This is a fresh SharePoint 2013 installation (Out-of-box)
• Some Web Applications are on port 80 (http) while others are on port 443 (https)
• WFE Servers configurations: Installed Desktop Experience feature on WFE servers, enabled WebClient service to run automatically, library contribute permissions are set correctly. Users tested as site members and as site collection administrator, removed all Office 2013 products from WFE servers including SharePoint Designer 2013.
• Client machine configurations: Office 2010 installed, added site to Trusted Sites zone, installed Add-ons for IE

Errors in logs:

Digging into ULS resulted in finding the following errors for w3wp.exe process:

Failed to get document content data. System.ComponentModel.Win32Exception (0x80004005): Cannot complete this function     at Microsoft.SharePoint.SPSqlClient.GetDocumentContentRow(Int32 rowOrd, Object ospFileStmMgr, SPDocumentBindRequest& dbreq, SPDocumentBindResults& dbres)     cda7da9c-4e98-509a-9976-8129b3f554cb
Could not get DocumentContent row: 0x80004005.
Failure when fetching document. 0x80070012


Root Cause:

Actually this is is really about one thing: the SharePoint WebDav. Both features 'Document Edit/Save'  'Open In Exporer' depend on it.

Document edit mode uses SharePoint WebDav http calls to upload the document back to target location (i.e. Document Library) when document is saved in client program (such as MS Word). 
When user clicks 'Save' button in client program, the client program has to discover if server supports required protocols including WebDav service (this is called Office Protocol Discovery). The client program checks first for cached info (called Office Protocol Discovery Cache) in client machine. This depends if there was a prior successful call to the same resource (i.e. the Doc Library). The cache is a windows registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\[Version]\Common\Internet\Server Cache

If there is no value for the target location folder in that key , then browser will try to initiate an http OPTIONS request to ask for folder info, and will require separate authentication. Otherwise, if there is a sub-key value for the target location folder, then no need to initiate OPTIONS request and automatic logon will proceed automatically. 

When client program initiates an OPTIONS request (and in some cases it needed to initiate PROPFIND requests too), The OPTIONS request is getting rejected. This is because of an IIS settings coming from IIS-lockdown script that disallow the ‘OPTIONS’ http verb from being processed. As a result, SharePoint never received the call for edit and assumes the default Read-Only mode. The client program will get an HTTP 404 (not found error).

Refer to the following useful links for more info:

• http://support.microsoft.com/kb/838028
• http://support.microsoft.com/kb/2019105
• http://sharepointinterface.com/tag/webdav/
• http://blogs.msdn.com/b/javaller/archive/2013/07/30/client-integration-with-sharepoint-2010-gotcha.aspx

 Solution:

IIS must allow the ‘OPTIONS’ http verb to be used.

For a specific web application, check if IIS is blocking ‘OPTIONS’ verb (the ‘Allowed’ value is set to false).  To fix this, remove the ‘OPTIONS’ entry from Request Filtering section in IIS, this will affect web.config file for target web app only. You must do this for all WFE servers where the web applications are available.

The same change can be applied for the entire farm, and this will affect applicationhost.config file.

Now both saving from client and 'Open with Explorer' features work!

Example:

I used Fiddler to show the inner data of what's going on for a sample document inside Shared Documents library: /sites/IIbraheemTestSite/Shared%20Documents/TestDoc.docx

	Before Change	After Change
OPTIONS request	Failed	Succeed
Registry folder sub-key in client machine	No data stored	Data stored

Hope that helps!

Digging on Could not find this Item error in SharePoint

I worked on this error a while ago when I was trying to replicate what was happening to a client's environment. When you want to upload EXE and DLL files to a document library in SharePoint using Explorer View, the operation fails with the following annoying error msg:

"Could not find this item
This is no longer located in \\sitename\DavWWWRoot. Verify the item's location and try again."

Of course uploading these types of files into SharePoint is highly not recommended due to security reasons, this is why they are on the blocked file types in Central Admin but for some companies it is a requirement.

You can find the complete error description and solution here, thanks to Stanislaw Delost!

But I wanted to see for myself what is the 'item' that is not being found as indicated by the error msg.

So, I built a small Windows program to imitate the exact operation of Explorer View's operation of copying the wanted files from a source folder into the desired doc library's WebDav folder.

And the error stack trace:

System.IO.FileNotFoundException was unhandled

  Message=Could not find file '\\dev\DavWWWroot\test\AERotatorWebpart.dll'.
  Source=mscorlib
  FileName=\\dev\DavWWWroot\test\AERotatorWebpart.dll
  StackTrace:
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
       at System.IO.File.Copy(String sourceFileName, String destFileName)

The code is simple. I used the program to copy normal document files and images and it worked just fine. When I used it to copy EXE and DLL files the program crashed. As you can see the exception msg in .NET is "Could not find file "\\ServerName\DavWWWroor\DocLibName\FileName.DLL"

and the exception is of type FileNotFoundException.

It looks like that it couldn't find the file that we want to copy in the first place..weird!!

Explorer View operation uses WebDav protocol and agents that get installed with SharePoint.

When WebDav detects a file of type .EXE or .DLL, it runs 2 handlers in IIS: CGI-exe (for EXE files), and ISAPI-dll (for DLL files). My guess is that these programs are trying to access our files from the doc lib folder (destination) before the copying operation completed, so it will not find the file and an error occurs. 

As mentioned in details in Delost's blog, the solution is to prevent the CGI-exe and ISAPI-dll handlers from running in IIS by removing the EXECUTE permission in Hanlder Mappings in IIS.