Wading Through

We had some developers wanting to use a Data View Web Part (DVWP) in a site and access information through a web service on the internet. They were able to connect to the web service WSDL but when they went to Show Data, they would receive the following error:

“The server returned a non-specific error when trying to get data from the data source. Check the format and content of your query and try again. If the problem persists, contact the server administrator.”

Well, the problem did persist, so they contacted us as instructed. :)  We spent quite a bit of time troubeshooting the issue. After lots of getting no where, we realized we weren’t in Kansas anymore (actually Missouri) so we opened a case with MS CSS. After several weeks, it was determined that is a bug and there was a work around. I am not seen any KB articles with this information so I wanted to review the exact setup that causes the issue, why it is broken, and how to work around it as learned from CSS.

First the setup that causes this issue.

• You have a standard web application setup with a url in the default zone, for our example, we will use http://default.mycompany.com.
• You add an additional URL for the web application through the use of alternate access mappings (AAM) to provide access to the same content through a different URL. For our example, we will use http://intranet.mycompany.com. In this case, you do NOT extend the web application. You only add an AAM.
• When constructing the data view web part using Designer, we do your development against the additional URL you added (http://intranet.mycompany.com). The DVWP fails to work properly.
• If you test against the default URL http://default.mycompany.com, the DVWP works properly.

So here is what is causing the issue. When you are using the http://intranet.mycompany.com URL, the DVWP code tries to go out to IIS on the server, find the web site for http://intranet.mycompany.com to verify if Kerberos is enabled, and that calls fails because there is no web site tied directly to this URL.

The Workaround: If you are needing to use Data View Web Parts and use multiple URLs through AAMs, you are going to have to extend the web application for each URL you had so there is a real IIS web site (with a seperate web.config) created. This will allow the Kerberos check to succeed.

We had the issue added to the bug list for SharePoint and it will be addressed sometime in the future. I will update this article as I see more information about this problem appear.