Data Form Web Part, Web Services, & AAMs…oh my


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.

About J.D. Wade

Senior SharePoint Consultant, husband, active in community theatre, love watching movies, have been described as “quirky”, aka “KB Man”
This entry was posted in Microsoft SharePoint, Microsoft Office SharePoint Server 2007 (MOSS 2007), Microsoft Windows Server, Windows Server 2008, Windows Server 2008 R2, Windows 2003, Windows Server 2003 R2, Windows SharePoint Services 3.0 (WSS 3.0), IIS, IIS 6.0, IIS 7.0, IIS 7.5 and tagged , , , . Bookmark the permalink.

11 Responses to Data Form Web Part, Web Services, & AAMs…oh my

  1. Pingback: Links (6/12/2008) « Steve Pietrek - Everything SharePoint

  2. Woody says:

    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?

  3. J.D. Wade says:

    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.

  4. Woody says:

    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.

  5. Stig Stavik says:

    Just to clarify – you need to drop the AAM and create a new site in IIS instead. Then extend your webapp in central admin to point to your newly created IIS-site. (“Use an existing IIS web site” and select it from the dropdown menu)

  6. Martin says:

    But how do you do this workaround if your AAM has to be an IP address, as your SharePoint site is being accessed over the internet?

    • J.D. Wade says:

      Martin,

      First, if you are exposing SharePoint to the Internet through a firewall and you are using one name externally (http://outsidename) and a different one internally (http://sharepoint), then you need to follow the advice in this article to properly configure your AAM

      Secondly, if you are just trying to do some testing externally and need to use a different IP address to go the URL you are testing, you can temporarily make an entry in your hosts files (c:\windows\system32\drivers\etc\hosts) to map an IP to a name for testing. Just using an IP externally will cause things like Content Query Web Parts to break.
      JD

  7. Martin says:

    Actually I’ve managed to get round the above problem by using dyndns.com to create a domain name for my IP address.

    • J.D. Wade says:

      Awesome, glad you got it working. My second piece of advice about the hosts file would work easily if you were just doing testing on one machine. Multiple machines would be better fixed by using DNS like you did.
      JD

  8. Amy Grossman says:

    Hi JD,

    So what are you supposed to do if you’re working off of a site collection that is hosted through a corporate SharePoint farm (routed through a dual proxy)? I don’t have access at all to the servers. Thanks in advance.

    Amy

  9. Mimosa803 says:

    Hi every body,

    I have a big problem when using a Data View WebPart with a public url of my intranet zone. In fact, I used SP Designer 2007 to show data with xslt by calling Sharepoint Web Service. In local, every thing works fine and I can retrieve Data with my Data Source, for example :

    <SharePoint:SoapDataSource runat="server"
    SelectUrl="http://server:8082/site1/_vti_bin/Lists.asmx&quot;

    I want to display my Web Part to user for intranet zone who are connected by FBA (I extended my WebApp) but I obtained an error :

    Unable to display this Web Part. To troubleshoot the problem,
    open this Web page in a Windows SharePoint Services-compatible HTML editor such
    as Microsoft Office SharePoint Designer. If the problem persists, contact your
    Web server administrator.

    I opened my page with SP Designer with the public url of intranet zone and I changed the data source like this :

    <SharePoint:SoapDataSource runat="server"
    SelectUrl="http://domain.com/site1/_vti_bin/Lists.asmx&quot;

    But I didn't resolve the problem ! I hope to know what I'm missing.

    Best regards

Join the discussion by leaving a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s