We had some developers wanting to use a Data Form Web Part (DFWP) 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 DFWP fails to work properly.
- If you test against the default URL http://default.mycompany.com, the DFWP works properly.
So here is what is causing the issue. When you are using the http://intranet.mycompany.com URL, the DFWP 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 Form 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.
4 responses so far ↓
Links (6/12/2008) « Steve Pietrek - Everything SharePoint // June 12, 2008 at 8:13 pm
[...] Data View Web Part, Web Services, & AAMs…oh my [...]
Woody // November 13, 2008 at 1:50 am
Interesting bug catch. Is this specific to installations where Kerberos is being used? What if you explicitly add the alternate URL to the host header list for the primary web application in IIS?
J.D. Wade // November 13, 2008 at 10:07 am
No…it is not specific to the use of Kerberos. In fact, in this deployment, the client was using NTLM. The check for Kerberos fails though just because there is no underlying IIS web site.
And the host header was added properly in IIS on all WFE servers in the farm so the page would resolve fine and work properly through the browser.
It only effects your deployment if you are trying to use the Data Form Web Part with Web Services on the alternate URL but should fail with any form of authentication.
Woody // November 13, 2008 at 11:14 am
Thanks for the response!
SharePoint interprets the host headers on its own, and so doesn’t normally set the host headers in IIS. Thus, IIS doesn’t know about the AAM settings. I suspect that’s why the error is occurring. That’s why I asked if explicitly setting the header in IIS (so the IIS API knows about the header) might also work around the problem.