Am a keen follower of Microsoft's SharePoint Blog and proud to provide this direct from the Microsoft Tech Community:

Overview

Distributed Authoring and Versioning (DAV) is an extension of the HTTP protocol that allows the user to interact with and manipulate files stored on a web server. The Windows implementation of the DAV protocol as a mini-redirector is handled by the WebClient service. As a mini-redirector it allows native Windows applications to interact with the remote file system through native networking API calls similar to the local file system and other remote file storage servers (such as CIFS and SMB). This is typically seen by the user as mapped drives or a Windows Explorer view.

Note: Although Windows 7 and Windows Server 2008 R2 exited support Jan 14, 2020, there are still many machines that will not be upgraded so the information below will still reference issues and resolutions that may be relevant to those operating systems.

Following the re-writing of the service in Windows Vista, the feature set was considered mature and further changes were primarily bug fixes and security updates. The service consists of webclnt.dll, davclnt.dll and mrxdav.sys (minimum version in Windows 7 should be 6.1.7601.23542) but is also reliant upon webio.dll, winhttp.dll (minimum version in Windows 7 should be 6.1.7601.23375) and shell32.dll (minimum version in Windows 7 should be 6.1.7601.22498).

With those files at their latest versions, undesired behavior is typically due to a misconfiguration or a limitation of the implementation.

 

Common issues with Explorer view

A Root site must exist

There are certain circumstances where the WebClient will walk the path as it would for an SMB file share. Although the path segment does not have to allow WebDAV, it must be present. See https://support.microsoft.com/en-us/kb/2625462 – SharePoint: Office client integration errors when no root site exists

Action: If a Root site is missing, create one. The users do not necessarily need access and there does not even need to be a Site Template selected; it just needs to exist.

 

Requests issuing OPTIONS and PROPFIND requests must be responded to with a success or an authentication response.

If the OPTIONS call receives a 200 Success response, the Webclient (and Office client) will assume that WebDAV is supported (even if the returned list of Allowed verbs does not include WebDAV verbs).

The PROPFIND request expects a 207 Multi-Status response as a success.

A 401 or 403 response is an indication of inadequate authentication information. A valid 401 response will include WWW-Authenticate headers that identify the type of authentication that is accepted (i.e. Negotiate, NTLM, Basic, Digest, Bearer). If a 403 response is received normally that means the resource is present but there are inadequate privileges to interact with it. Unlike the 401 response, submission of additional authentication will not provide access. A few years ago the 403 status code began being used for responses where Forms Based Authentication (FBA) and claims authentication is used but the requesting agent is unable to process a 302 redirect to a login page (see the MS-OFBA Protocol specification).

If these are not the responses received by the client then typically the request is being blocked, either by the HTTP verbs setting of the Request Filtering in IIS, a URL-Rewrite rule or perhaps by a device in the middle. The most common alternate responses are 404 Not Found if the verb is blocked or a 302 Redirect to a login page for third party authentication providers that do not adhere to the MS-OFBA specification.

Action: Verify that the request is making it to the server with simultaneous network traces or check the IIS logs. If the IIS logs show the response is coming from the server, open IIS Manager and check the HTTP verbs tab in Request Filtering. If the verbs are not listed there, then you may need to collect Failed Request Tracing to identify the source of the response. The full list of WebDAV verbs that need to be allowed are referenced elsewhere on this page.

 

Client integration must be enabled at the web application level and the ‘UseRemoteAPIs’ permission must be ‘true’

If Client integration is not enabled, the OPTIONS request is not sent, and the client will assume WebDAV is not supported.

Action: Enable Client Integration (located at CA > Web Application Management > Authentication Providers > Zone ) and verify there is no policy disabling the ‘UseRemoteAPIs’ permission, See https://support.microsoft.com/en-us/help/2758444 – SharePoint 2013 Disable WebDAV use on SharePoint

 

WebDAV must not be enabled in IIS features of the server

If the WebDAV feature is enabled in IIS it will interfere with the SharePoint implementation of the WebDAV handler. See https://support.microsoft.com/en-us/help/2171959 – Explorer view does not work in some scenarios when the SharePoint farm is on Windows Server 2008 R2 or https://support.microsoft.com/en-us/help/2018958 – SharePoint 2007 or 2010: Office Documents open ReadOnly from SharePoint site

Action: Remove the WebDAV feature from IIS (this will require a reboot of the server).

• Windows Server 2008 R2 – In Server Manager go to Roles->Web Server IIS section, Click Remove Role Services and Uncheck ‘Web ServerCommon HTTP FeaturesWebDAV Publishing’
• Windows Server 2012 – Uncheck ‘WebDAV Publishing’ in Server Manager->Manage->Remove Roles and Features then Web Server IIS section->Web Server->Common HTTP Features
• Windows Server 2012 R2 – Uncheck ‘WebDAV Publishing’ in Server Manager->Manage->Remove Roles and Features then Web Server IIS section->Web Server->Common HTTP Features

If FBA/Claims authentication is being used, the site must be in an IE security zone where Enable Protect Mode is not checked (by default that is the Trusted zone) and persistent cookies must be used.

When Forms Based Authentication (FBA) or Claims Authentication is used, the client presents its authentication through a cookie. Since the WebClient service cannot show a login page, it must rely on the authentication cookie from the browser. Sharing cookies retained solely in memory (session cookies) between processes would be a security violation so, in order for the WebClient service to acquire the cookie, it must be created as a persistent cookie and stored in a location shared where other processes can access it.

A persistent cookie is one created with an expires time. This is observable in the response when the Set-Cookie header is sent from the authenticating server to the client. Frequently the cookie name is FedAuth, but it does not have to be. Normally an authentication cookie will be complex enough that it will look like a VERY long string of random characters. If the expires attribute is not on the Set-Cookie header it is a session cookie and not a persistent cookie. Making the cookie persistent is considered a security reduction but one that is necessary in order for the WebClient service to acquire it (there was a period where a callback function in MSO.dll shared session cookies with the service but it was not intended for that purpose, is unreliable and should not be happening in current products).

The WebClient service calls the InternetGetCookieEx function to read the cookies from the cookie jar (which is one reason why Explorer view only works with Internet Explorer). Applications can only share cookies if the site is not in a zone where Protect Mode is enabled. By default, that is the Trusted zone, but the configuration can be changed so always verify the Enable Protect Mode checkbox.

For more, see “WebClient service does not support Session Cookies” – https://support.microsoft.com/en-us/kb/2985898 . This is also documented in the Whitepaper Implementing “Persistent Cookies in SharePoint 2010 Products” https://download.microsoft.com/download/9/F/6/9F69FEBA-614B-483F-9CF2-60225D75E81E/persistent-cookies-whitepaper.docx

Action:

• Verify the cookie is persistent (you may need a Fiddler, netsh or another network capture to verify the Set-Cookie header).

The login form may have a “Keep me signed in” or “Sign me in automatically’ checkbox that the user must enable. If the user has no option, and if SharePoint is creating the cookie, then you may need to use the PowerShell to enable it from the SharePoint Management Shell:

$sts = Get-SPSecurityTokenServiceConfig

$sts.UseSessionCookies = $false

$sts.Update()

iisreset

 

• Verify the site is in a zone where ‘Enable Protect Mode’ is unchecked – see https://support.microsoft.com/en-us/help/932118 – Persistent cookies are not shared between Internet Explorer and Office applications

WebClient binaries need to be current, especially for Windows 7.

There have been several updates to the WebClient binaries over the years. See the Overview on this page for the list of binaries and recommended minimum versions. Some critical changes have been regarding cookie handling and TLS support. In some versions of Windows 7, persistent cookies were not passed until a 401 or 403 response was received. This broke the login process for third-party authentication providers who did not differentiate between browser and non-browser user agents. Also, the Windows 7 WebClient used default security protocols that maxed out at TLS 1.0 (see issue #9 below). Another issue that was fixed was the use of Server Name Indicator (SNI) – see #8 below.

Action: verify that the WebClient DLLs (and those supporting them) are current. See the Overview above for more but this is becoming less of an issue as the latest security updates generally have the necessary files.

 

If the site is using Windows authentication and the host name is FQDN, then credentials are not passed

The WebClient service does not leverage the Internet Settings Zone Manager to identify when it is safe to automatically send credentials so by default credentials were automatically sent to only sites without periods in the host name. Since companies frequently use fully qualified domain names (FQDN) internally as well, another method was created to allow administrators to identify when it was safe to automatically send credentials. This is done by using the AuthForwardServerList registry key under the WebClient service hive. See https://support.microsoft.com/kb/943280 -Prompt for credentials when you access WebDav-based FQDN sites in Windows.

Note: This KB applies to all versions of Windows after Windows Vista SP1

Action: Add the site to the AuthForwardServerList. This is a client-side registry key. Also be sure that the Multi-SZ reg entry has a return at the end – some versions of Windows will allow adding the entry without a return but without the return the key is not read properly

 

If Server Name Indication (SNI) is enabled anywhere in the IIS bindings, then the client cannot connect (Windows 7 only).

If multiple certificates are used for different web applications on the IISSharePoint server then either the server must bind the web application to different IP addresses or implement SNI. Some good reading on SharePoint and SNI can be found at https://blogs.msdn.microsoft.com/sambetts/2015/02/13/running-multiple-sharepoint-ssl-websites-on-separate-ssl-certificates-using-server-name-indication

Windows 7 did not initially implement support for SNI but this was corrected when the service changed the way WinHTTP was called in MS15-089: Vulnerability in WebDAV could allow security feature bypass: August 11, 2015

Action: Update the client to a supported version or disable SNI in IIS.

 

Explorer view fails if the TLS handshake cannot complete (most commonly Windows 7).

If only TLS 1.1 and/or 1.2 are enabled (and earlier versions disallowed), then Windows 7 clients will need the latest WebClient and WinHttp binary updates as well as the registry edits for WinHTTP that change the default security protocols to allow TLS 1.1/1.2 – https://support.microsoft.com/en-us/kb/3140245

Initially the Windows 7 WebClient service set the list of available security providers when opening the connection through WinHTTP but it had a maximum value of TLS 1.0. Later, the service stopped setting a specific list and just took the WinHTTP system default security settings (https://support.microsoft.com/kb/3076949 – MS15-089: Vulnerability in WebDAV could allow security feature bypass: August 11, 2015). Unfortunately, this did not help since the default was SSL 3 and TLS 1.0 (the system default beginning with Windows 8.1 includes TLS 1.0, 1.1 and 1.2). This limitation was removed when an update came out that allowed the ‘system default’ settings be changed – https://support.microsoft.com/en-us/help/3140245 – Update to enable TLS 1.1 and TLS 1.2 as a default secure protocols in WinHTTP in Windows.

Action: Ensure the client and server systems have the necessary registry settings and binaries to allow a common TLS version (the higher the better). In addition to checking the SCHANNELProtocol client and server settings, check for the WinHttp registry settings in Internet Settings as these will be used as override values in updated Windows 7 machines and all supported operating systems. Updated client binaries include WinHTTP/WebIO in addition to the WebClient files. See the Overview above for the list of files and minimum versions for Windows 7.

Note: The update 3140245 has registry entries that also need to be set.

 

There can be no certificate errors. The site name must match the certificate, not be expired and be trusted.

This affects all versions of Windows clients. The WebClient service has no tolerance for certificate errors. Use the browser to see if the certificate is reporting errors. Alternatively view the certificate to verify the certificate is in the valid date range, has a trusted certification path and has a Subject or Subject Alternative Name that matches the site.

Action: Replace the certificate with a valid certificate.

 

If the server has custom IIS headers, the custom header name cannot contain spaces.

Custom headers are an excellent tool for troubleshooting through load balancers. And a custom header with a unique value on each WFE and then the traces can tell you which server responded in the farm. However, be careful that the custom header name does NOT contain any spaces. The UI will allow them and there is no documentation that states they are prohibited but spaces will cause a client-side failure while processing the response. This was discovered when OPTIONS and PROPFIND calls were failing; the client terminated the session after receiving the first packet of the response even while additional packets were being sent.

Action: Remove or rename the custom IIS header. A suggestion would be to either remove the space or replace it with an underscore; the underscore is typically a more aesthetic change.

 

PROPFIND and PROPPATCH responses must contain valid XML and not be Content-encoded (g-zip)

If the WebClient service receives a response to a PROPFIND or PROPPATCH that does not contain a valid XML structure it can result in unusual behavior possibly even generating undesired credential prompts (see https://support.microsoft.com/en-us/help/2019105 – Authentication requests when you open Office documents).

The WebClient service cannot handle a response that has GZIP encoded the body. This was discovered in a case where an Akamai router/load balancer was GZIP encoding the response (it worked when Fiddler was used because Fiddler was decompressing the file). This will almost certainly be a device in the middle (it is unconfirmed if enabling IIS compression on a SharePoint server will cause this.

Action: Identify the device doing compression and disable compression for PROPFIND/PROPPATCH requests.

 

Unable to create new files or folders

When the WebClient service creates a new file or folder it will first check for the presence of an existing order to prompt for an override if necessary. If a custom 404 handler has been put it place it may intercept the necessary 404 response and the WebClient service will fail to create the new file or folder..

Action: The custom 404 handler must either be removed or updated ignore the WebClient requests. Modifying the custom handler to not engage when the User Agent string is Microsoft-WebDAV-MiniRedir is one way the requests can be filtered.

 

Verbs needs for WebDAV to work

For WebDAV communication to work properly, the WebDAV verbs (also called Methods) must be allowed by the server. The RFC 4918 internet specification includes: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK. In addition to those, the HTTP methods of OPTIONS, HEAD, PUT and DELETE are frequently associated with the WebDAV protocol and should be allowed as well.

 

UNC paths

When the WebClient service translates between the HTTP protocol to UNC the conversion is fairly straightforward. A path like http://server/site would become serversite . HTTPS adds an additional suffix – https://server/site becomes server@sslsite.

If the WebDAV share is at the root, the UNC will need a virtual share (UNC requires a servershare minimum). The ‘virtual share’ is DavWWWRoot. Example: http://server would be serverDavWWWRoot .

 

Configuration changes needed to support large file uploads

When configuring an environment to support large file uploads to SharePoint through Windows Explorer, there are four settings to adjust:

On the server:

• Increase the SharePoint Maximum upload size on the web app (max of 2047 mb)
• Increase the IIS Connection Time-out to a value longer than the time needed to upload (default of 120 seconds – max of 65535 or 0xffff ).

On the client:

There are two settings under the WebClient service registry (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters):

• Increase the FileSizeLimitInBytes (default of 50 mb – max of 0xffffffff or 4 gb) https://support.microsoft.com/en-us/help/2668751 
• Increased the SendReceiveTimeoutInSec to a value longer than the time needed to upload (default of 60 seconds – max of 4294967295 0xfffffff).

Calculating the time needed to upload a file via Explorer view

Performance of file uploads via a mapped drive to SharePoint or Explorer view is limited by the WebClient service. The approximate maximum throughput is 8 kb per RTT.

Throughput is amount of data divided by time.

 

If the server allows a ping, you can get an average RTT with the following PowerShell:

$rtt = (Test-Connection -ComputerName myservername | Measure-Object -Property ResponseTime -Average).Average

 

Note: if the server does not allow a normal ping or if you want a more exact RTT measurement, you can use the PSPing utility from SysInternals – https://technet.microsoft.com/en-us/sysinternals/psping

 

The amount of time it would take to upload a 2047 Mb file with an average RTT of 1.75 ms would be:

Filesize / 8kb * RTT

2,146,435,072 bytes / 8,192 bytes * .00175 seconds

or approximately 459 seconds

 

Library contents do not display in Explorer view

This issue can occur for a couple of known reasons.

First, if there are too many files in the library folder, the Explorer view display as an empty folder. This problem can occur if the size of all the file attributes (the PROPFIND response) returned by the WebDAV server is larger than expected. By default, this size is limited to 1 MB.

The client registry value FileAttributesLimitInBytes can be increased to accommodate the amount of properties returned (the suggested estimate is approximately 1k per file so for 20,000 files, use a value of 20000000). For more details, see https://support.microsoft.com/en-us/help/912152 – “You cannot access a WebDAV Web folder from a Windows-based client computer”.

The preferred resolution would be to reduce the number of files in a folder; SharePoint performs best with less than 5000 item in a view but Explorer view will request all files and possibly exceed the normal view settings.

Second, if the combined length of path and filename of any file in the folder exceeds the maximum supported by the Windows Explorer (approx. 255), then no items will be displayed until the folder and/or filename is shortened. You may have to use the SharePoint web interface to make the change.

 

Consider using a diagnostic to examine the client

Here is a diagnostic script that can help identify the current configuration and some common problems (do a ‘Save Target as’ on the [Raw] button) : https://github.com/edbarnes-msft/DrDAV/blob/master/Test_MsDavConnection.ps1

 

The above is kindly provided by the Microsoft Tech Community!