none
InfoPath 2010 form working in Client, not working in browser, using GetUserProfileByName SOAP Data Connection

    Question

  • I have recently made a very simple form to get the current user and the current user's manager.

    I have setup the data connection and verified that this works in the preview of InfoPath 2010.  After I publish this to my SharePoint 2010 Enterprise environment, I get the following errors:

    There has been an error while processing the form.
    Click OK to resume filling out the form. You may want to check your form data for errors.
    An error occurred while trying to connect to a Web service.

    An entry has been added to the Windows event log of the server.

    The further details on the server provide me with this:

    The following query failed: GetUserProfileByName (User: 0#.w|DOMAIN\USERNAME, Form Name: Template, IP: , Connection Target: , Request: https://WEBAPPLICATION/departments/it/Lists/Hardware Request Form/AllItems.aspx, Form ID: urn:schemas-microsoft-com:office:infopath:list:-AutoGen-2012-03-07T00:33:33:413Z Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error.  Server was unable to process request. ---> Attempted to perform an unauthorized operation. The remote server returned an error: (500) Internal Server Error.)

    I have been struggling with this for awhile now.  Any help offered would be much appreciated.

    Thanks,

    Jesse

     


    Jesse A. Brandenburg

    Friday, March 16, 2012 8:21 PM

Answers

    1. Identity Providers are the identity sources that provide identities to your web app.  In 2010, we have Claims Mode web apps that can utilize one or more identity providers in the same zone.  If you are using more than one in the same web app, then InfoPath browser forms are unable to figure out which one to use for authenticating to built-in web services.  It's not related to SSL certs.  You can see the selected identity providers at Central Admin > Manage Web Applications > Highlight the relevant web app > Click Authentication Providers in the ribbon > Look to see which identity providers are selected
    2. You cannot automatically retrieve data with this web service in a claims mode web app using a browser form, because it will use the app pool identity instead of the current user.  Do not automatically retrieve in browser forms in Claims mode web apps.  Query on-demand in your Form Load rules.
    3. As I said, if you have one WFE, then it has no choice but to browse itself.  The built-in loopbackcheck security feature blocks this, so you have to make a choice.

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    Friday, March 23, 2012 2:26 AM
  • Still a little off on all 3:

    1. Not talking about zones, but rather authentication providers.  Need to make sure exactly how many and what types of authentication providers are being used.  # and types of zones is a different topic.  Click on the word "default" to see the authentication providers in use.
    2. Still missing the point here.  The whole point is that setting it to automatically retrieve causes it to query on form load and use the current/default user.  However, in a browser form in a Claims Mode web app, that "user" is the app pool identity instead of the actual user.  That's why you are turning this off and instead replacing it with an on-demand query of the data connection AFTER setting the AccountName query field to userName().  If you don't tell it to query the actual real user, then it will query based on the app pool identity, which is no good.  What we're trying to do here is query the real user, not the app pool identity.
    3. Spence explains this in detail in the article you referenced earlier.

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force


    Sunday, March 25, 2012 8:44 PM
  • Real Answer (In addition to the other things mentioned in this article.  

    Make sure that in IIS Authentication - ASP .NET Impersonation is disabled.

    After digging and digging and digging, this resolved my issue and I am able to utilize SharePoint web services.  Whew!

    Thanks again to Clayton for posting all of the valuable information.

    Jesse


    Jesse A. Brandenburg

    • Marked as answer by 1brandeja5 Wednesday, May 30, 2012 2:38 AM
    Wednesday, May 30, 2012 2:38 AM

All replies

  • Hi Jesse,

    is disableloopbackcheck off, are AAM all nice?

    Anything in the ULS log?


    Regards, Chris

    Sunday, March 18, 2012 7:52 AM
  • Thank you for your response.  When you say disableloopbackcheck off, I currently do not have an entry in the registry for this.  

    Per this article:

    http://www.harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx

    and this one:

    http://support.microsoft.com/kb/896861

    It sounds like this is not a recommended procedure. AAM appears to be setup fine.

    Thanks,


    Jesse A. Brandenburg

    Monday, March 19, 2012 1:49 PM
  • Do you have any further thoughts on what to try?  I have been struggling with this for quite some time.  I cannot think of any other configuration settings to change to make this work.

    Any help is appreciated,

    Jesse


    Jesse A. Brandenburg

    Wednesday, March 21, 2012 2:04 PM
  • It must be done one way or the other if you are going to use browser forms with one WFE, because the server can't browse itself otherwise, and that's what happens when you query any SharePoint web service from within a browser form.  If you have load balanced WFEs where the call is made from one server to another, then you must have Kerberos enabled.

    You for sure have to address this before worrying about anything else.


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    Friday, March 23, 2012 1:58 AM
  • Looks like a Claims mode web app:

    • Does this web app have more than one identity provider in use?
    • Are you auto-querying on form load with the box checked for "automatically retrieve data" in the data connection?  In a claims mode web app, browser forms retrieve the identity of the app pool, not the current user.  You have to manually set the query value to userName() in the Form Load rules when working within a Claims mode web app
    • How many WFEs in the farm?  Loopbackcheck must be addressed, and for multiple WFEs, Kerberos must be addressed if you don't address loopbackcheck.

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    Friday, March 23, 2012 2:01 AM
  • Please forgive me, as I am a bit of a newbie, but I believe I have the information you are looking for...

    Yes-it is claims mode

    -As far as identity provider's, I have added each level of the certificate to the trusted relationships, as we are using SSL.

    - I have tried automatically retrieve data. I can get the userName() function to work properly. Do I need to use this value instead of filtering "Value" based on "AccountName" or "FirstName" or whatever I am trying to populate?

    -There is one WFE in the farm-do I need to add the DisableLoopBackCheck entry to the registry? I have tried both in my dev environment.

    Thank you very much for your assistance, Clayton.

    Jesse


    Jesse A. Brandenburg

    Friday, March 23, 2012 2:16 AM
    1. Identity Providers are the identity sources that provide identities to your web app.  In 2010, we have Claims Mode web apps that can utilize one or more identity providers in the same zone.  If you are using more than one in the same web app, then InfoPath browser forms are unable to figure out which one to use for authenticating to built-in web services.  It's not related to SSL certs.  You can see the selected identity providers at Central Admin > Manage Web Applications > Highlight the relevant web app > Click Authentication Providers in the ribbon > Look to see which identity providers are selected
    2. You cannot automatically retrieve data with this web service in a claims mode web app using a browser form, because it will use the app pool identity instead of the current user.  Do not automatically retrieve in browser forms in Claims mode web apps.  Query on-demand in your Form Load rules.
    3. As I said, if you have one WFE, then it has no choice but to browse itself.  The built-in loopbackcheck security feature blocks this, so you have to make a choice.

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    Friday, March 23, 2012 2:26 AM
  • Clayton-

    This is extremely helpful I must thank you again for taking the time to explain some of these concepts.  I am learning everyday! (Which is why I love this job!)

    1-Understood-There is only 1 zone (Default) and it is claims based authentication

    2-I will remove the automatically retrieve data and attempt to do it on demand.  Will I still need to use the userName() function? Or at this point does the browser form know who the current user is at the form load point

    3-I will make sure that I have disabled loop back checking-Any particular reason this security function is built in in the first place (if the boss asks?)

    Thanks again,

    Jesse


    Jesse A. Brandenburg

    Friday, March 23, 2012 2:41 AM
  • Still a little off on all 3:

    1. Not talking about zones, but rather authentication providers.  Need to make sure exactly how many and what types of authentication providers are being used.  # and types of zones is a different topic.  Click on the word "default" to see the authentication providers in use.
    2. Still missing the point here.  The whole point is that setting it to automatically retrieve causes it to query on form load and use the current/default user.  However, in a browser form in a Claims Mode web app, that "user" is the app pool identity instead of the actual user.  That's why you are turning this off and instead replacing it with an on-demand query of the data connection AFTER setting the AccountName query field to userName().  If you don't tell it to query the actual real user, then it will query based on the app pool identity, which is no good.  What we're trying to do here is query the real user, not the app pool identity.
    3. Spence explains this in detail in the article you referenced earlier.

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force


    Sunday, March 25, 2012 8:44 PM
  • I apologize for my misunderstanding.  

    1) It appears that under claims authentication types, enable windows authentication and Integrated windows authentication are checked.  Under Integrated Windows authentication (NTLM) is selected in the dropdown box.  Client integration is enabled. Anonymous Access is disabled. (Hope this helps)

    2)Now I believe I understand the query portion more.  Uses the app pool account unless you tell it to use the UserName() function.  

    3)I read his article in further detail-thanks.

    Again thank you for your help.

    Jesse


    Jesse A. Brandenburg

    Tuesday, March 27, 2012 7:56 PM
  • Hi Clayton-

    I am referencing your article:

    http://blogs.msdn.com/b/mvpawardprogram/archive/2012/03/12/mvps-for-office-365-pre-populating-infopath-2010-forms.aspx 

    and I am currently looking for how you are assigning "AccountName = . "

    I have a field called SubmitterID that has a default value of userName(), I have tried assigning AccountName to SubmitterID to pull more information in about the current user.

    As you know I have a claims based authentication web app so my username being returned "i:0#.w|DOMAIN\USER"

    Do I need to do something special if this is the case?

    Thanks-

    Jesse 


    Jesse A. Brandenburg

    Wednesday, March 28, 2012 4:42 PM
  • Real Answer (In addition to the other things mentioned in this article.  

    Make sure that in IIS Authentication - ASP .NET Impersonation is disabled.

    After digging and digging and digging, this resolved my issue and I am able to utilize SharePoint web services.  Whew!

    Thanks again to Clayton for posting all of the valuable information.

    Jesse


    Jesse A. Brandenburg

    • Marked as answer by 1brandeja5 Wednesday, May 30, 2012 2:38 AM
    Wednesday, May 30, 2012 2:38 AM