0

I have an InfoPath 2010 form on my SP2010 farm using Form Services which doesn't call an XML file or web services correctly. I'm trying to get list data by calling:

https://sp.domain.com/_vti_bin/owssvr.dll?Cmd=Display&List={d2b0b951-9673-4c59-b294-803ab6994b8d}&XMLDATA=TRUE&noredirect=true

And the form errors as seen below

Request Types XML file error System.Net.WebException: The form cannot run the specified query. ---> Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterException: The form cannot run the specified query. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterXmlFile.GetXmlFileStreamThroughHttpRequest(Uri fileUri, DataAdapterCredentials credentials)
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterXmlFile.<>c__DisplayClass4.<ExecuteNonSolutionFile>b__0(Boolean differentIdentity)
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterUtil.Impersonate(DataAdapterInformation adapterInfo, String userName, String userDomain, String password, CodeToRunUnderImpersonation codeToRun)
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterUtil.Impersonate(DataAdapterInformation adapterInfo, String userName, String password, CodeToRunUnderImpersonation codeToRun)
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterXmlFile.ExecuteNonSolutionFile(String fileUrl, XPathNavigator output, Document document, DataAdapterCredentials credentials, Boolean useDcl, Int64& auxDomSize)
   --- End of inner exception stack trace ---
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterXmlFile.HandleExecuteException(Exception exception, String safeMessage)
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterXmlFile.ExecuteNonSolutionFile(String fileUrl, XPathNavigator output, Document document, DataAdapterCredentials credentials, Boolean useDcl, Int64& auxDomSize)
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterXmlFile.Execute(String fileUrl, XPathNavigator output, Document document, DataAdapterCredentials credentials, Boolean useDcl, Int64& auxDomSize)
   at Microsoft.Office.InfoPath.Server.DocumentLifetime.DataAdapterXmlFile.ExecuteInternal(XPathNavigator output)
   at Microsoft.Office.InfoPath.Server.DocumentLifetime.OMExceptionManager.ExecuteOMCallWithExceptions(OMCall d, ExceptionFilter exceptionFilter)   LogId: 5566 Details: The remote server returned an error: (401) Unauthorized.
   --- End of inner exception stack trace ---
   at Microsoft.Office.InfoPath.Server.DocumentLifetime.OMExceptionManager.ExecuteOMCallWithExceptions(OMCall d, ExceptionFilter exceptionFilter)
   at Microsoft.Office.InfoPath.Server.DocumentLifetime.OMSecurityContext.ExecuteOMCall(Solution solution, SecurityLevel methodSecurityLevel, ExceptionFilter exceptionFilter, OMCall d)
   at RequestForm.FormCode.FormEvents_Loading(Object sender, LoadingEventArgs e)
request type location is https://sp.domain.com/_vti_bin/owssvr.dll?Cmd=Display&List={d2b0b951-9673-4c59-b294-803ab6994b8d}&XMLDATA=TRUE&noredirect=true

When loading the form from the two web front ends, it works great. Running it from the app server or a client machine, it errors. If I run the XML URL from the app or client machine, it downloads the file with data. Each instance I've logged in as the farm account.

Any ideas?

Improve this question

1 Answer 1

Reset to default
3

What kind of authentication are your running? From the error you are getting it seems like you have currently NTLM set up. Using NTML it is not possible to make another hop. Using kerberos will allow the user authentication to be forwarded to another server. You can find great information on technet:

http://technet.microsoft.com/en-us/library/ff829837.aspx

I'm not sure what options you have, while configuring the datasource inside of infopath. Maybe you can change to a technical account, but i won't recommend that. Getting kerberos up an running is worth the efforts.

Improve this answer
1
  • 1
    I think you're right about the Kerberos vs NTLM, we are using NTLM. HOWEVER, we are also using a load balancer on the URL and that appears to be related to the issue as well. When we access the site via http instead of https, it works great. Very odd. We will try out Kerberos for the https and see how that runs. Thanks!
    – David Lozzi
    May 9, 2011 at 15:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.