Scheduling to WebDAV with Web Intelligence

Binary Adventures

A newly created schedule of a Web Intelligence document in BI4 to a SharePoint WebDAV share kept failing. For a publication, this is the error message that is returned:

Distribution to destination CrystalEnterprise.DiskUnmanaged (//sharepoint.server.com@SSL/DavWWWRoot/teams/Reports/XXX/report.xlsx)  failed. Recipient: Administrator, Document Scope: Report : 7580074 (Excel) : (AND ). source file error. [[File System] ([1]/[1])]: [Invalid argument] (FBE60013)

A schedule will return the following error:

source file error. [Invalid argument]: [CrystalEnterprise.DiskUnmanaged]

C0120B624235D60AE7787F660CCB1B9A.png

Cause

According to Microsoft KB article 943280:

In Windows Vista, Internet Explorer uses the Web Client service when you use Internet Explorer to access a WebDAV resource. The Web Client Service uses Windows HTTP Services (WinHTTP) to perform the network I/O to the remote host. WinHTTP sends user credentials only in response to requests that occur on a local intranet site. However, WinHTTP does not check the security zone settings in Internet Explorer to determine whether a Web site is in a zone that lets credentials be sent automatically.

If the URL contains periods, the server is assumed to be on the Internet. The periods indicate that you use an FQDN address. Therefore, no credentials are automatically sent to this server unless a proxy is configured and unless this server is indicated for proxy bypass.

If the URL contains no period in the server’s name, such as in the following example, the server is assumed to be on a local intranet site.

A server can be indicated for proxy bypass either through the bypass list or through the proxy configuration script.

Thus, the Web Client service doesn’t recognize the URL \\sharepoint.server.com@SSL\DavWWWRoot\teams\XXX\Reports as an Intranet site and doesn’t automatically authenticate. Normally, an authentication pop-up would appear, but as this is a (non-interactive) server process, the access request will be denied.

Solution

In order to recognize the URL as an Intranet Site, we need to add it to the AuthForwardServerList registry entry.

Create a registry entry AuthForwardServerList of type REG_MULTI_SZ (Multi-String Value) in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\ and add the URL (or a wildcard).

DC49D678E9A2532CB3C4FDC033284C60.png

Reference