My attempts to retrieve UserProfile data for InfoPath form open all end badly with the same error so I have simplified down to one test case which I will try to describe below.

Symptom 1: Event ID 5566 is logged after clicking "Add document" in Forms library. Error Message from InfoPath Forms Services can be seen here in this .txt file

Symptom 2: When clicking Preview on the local .xsn file in the InfoPath 2010 Designer: Screenshot of this simple form and messages can be seen in this .png file.

Details: I am logged on locally as sharepointAdmin on the SharePoint 2010 Enterprise Server:

  • Farm Information - Configuration database version: 14.0.6117.5002 (SP1 & hotfixes)
  • All SP web applications configured to use Classic Authentication
  • An intranet test system with SQL2008R2 and Office 2010 Professional Plus on same PC

I created a simple Info Path 2010 form logged on as sharepointAdmin. I saved it on a local drive with this goofy but descriptive name (i.e. everything is on same PC):


It has 2 textboxes only which are trying to get data from the web method GetUserProfileByName according to Itay Shakury's blog. NOTE: There was a prompt for a string value to be passed to tns:AccountName but I read his blog advice as best to click NEXT and skip that so I did. I checked "Automatically retrieve data when form is opened".

When finished in the Data Connections wizard creating the formulas for retrieval from the web method, I clicked the Convert to Connection File button and stored it to a previously created Data Connections library as:


I uploaded this .UDCX file to my Google Drive which could be seen via this link:


I chose Connection link type labeled Relative to site collection (recommended) - rather than Centrally managed connection library (advanced).

I published the form itself to http://blacktip:81/mysites/sharepointAdmin/Forms

UPDATE with more info about a different simpler attempt at a workaround 05/29/2013:

One of the ideas below UNCHECKS "Automatically retrieve data when form is opened" in the data connection and adds 1 rule at Form Load. This workaround still fails but does NOT throw the Event ID 5566 anymore. Two artifacts about this attempt follow: Error from this technique Form2 for this technique UPDATE with ULS entries requested by Alexey Krasheninnikov 05/31/2013:

The 6 ULS records matched with one of the correlation ID values when the Event ID 5566 gets thrown. In ULSViewer, I found one of the correlations that matched and there were 6 log records which I selected and exported to a .txt file and uploaded to Google Drive here:


  • Sorry for the basic question, but just to confirm, did you go through the publish wizard? Or did do some other process to publish the form?
    – Mike2500
    May 21, 2013 at 18:04
  • Thanks for your interest! Yes, I clicked File then Publish (to the URL above). I guess that is the Wizard. I have since used Quick Publish since the URL is stored. He comes back with a "success" regarding Publish but when I browse the form it throws the 5566 event (error). Hope you can help me think of something. Can you confirm that the <udc:authentication element of the .udcx file is indeed to be left as comments? I interpreted Itay's blog to say that somehow the required parameter to the webmethod, tns:AccountName would be supplied at runtime. Can't get clarity on that issue.
    – John Adams
    May 21, 2013 at 20:57
  • Can you, by the way, provide a full correlation log with Verbose turned on? May 30, 2013 at 10:48
  • Can you also capture the SOAP messages and post them here? May 30, 2013 at 10:50
  • Alexey - see UPDATE with ULS entries requested by Alexey Krasheninnikov 05/31/2013 in the original post. File is simply .txt viewable in Notepad with WordWrap off. What tool should be used to capture the SOAP messages for this? Any advice on that? Thanks for your help and interest.
    – John Adams
    May 31, 2013 at 22:11

4 Answers 4


My apologies, this should be a comment, but I'm new to StackExchange and can't find the button for comments...

I can confirm that your .udcx file is correct - including the element. My .udcx file is identical, except for the server location - obviously. But RELATIVELY it is the same.

I've used Itay Shakury's method in the past, and just to confirm, I just now recreated what you were attempting, and everything worked perfectly (sorry to say).

I changed the default value of one of the text boxes, in an attempt to recreate your error, but I cannot. All mine does is just not show up in the box.

Do you think it may be an issue with your local log on? I'm never logged on locally; only with a network account. Since this data connection is looking at the "UserProfileService", maybe you should try logging in with a network account. I don't know - I'm grasping at straws, but I wanted to let you know that your .udcx file looked fine.

  • Maybe this is my incorrect terminology: I am logging on directly to the SP server using a domain account defined in our Active Directory on our domain controller. That is, the account used is a "network account" called OURDOMAIN\sharepointAdmin but I am using Remote Desktop to access the SP server machine directly. So, I guess strictly-speaking, I am NOT logged on locally.
    – John Adams
    May 23, 2013 at 19:41
  • comments can be added via the link called add comment which when clicked opens a text box for typing comments and exposes a button to the right with caption "Add Comment" for committing the comment. Also, are you stating that the udc:authentication element is commented out too? That is, that somehow the web method discovers the identity tns:AccountName at runtime?
    – John Adams
    May 23, 2013 at 19:46
  • Yes - the udc:authentication element is commented out in mine, too (I just realized it dropped "udc:authentication" from my previous post because I had it wrapped).
    – mattreed
    May 24, 2013 at 1:05
  • There was no Add Comment button available to me until after I posted. It's like that on every posting I view. The only one that has the button is my own posting, that I made today. Must be something about new accounts...
    – mattreed
    May 24, 2013 at 1:08
  • @mattered: yes that's correct, I believe you need about 50 rep or something like that before you can add comments.
    – Hutch
    Feb 18, 2014 at 16:20

I read somewhere that the problem is related to "Classic Authentication" (exactly i don't know where was it) , Try this one.



Why is GetUserProfileByName from InfoPath Forms Services with claims authentication failing?

  • Thanks Behrouz for your ideas. I read Link 1 above and my settings for Authentication are already "correct" compared to what he said fixed his problem. I read Link 2 above and there is lots of pain described with only 1 idea worth exploring which I did. Namely, I simplified my form even more and UNCHECKED "Automatically retrieve data when form is opened" in the data connection and added 1 rule at Form Load. It still fails but interestingly does not throw the Event ID 5566 in Windows Event Log. Link 3 above does not apply - I do not use Claims Authentication. Will try to post screenshot too.
    – John Adams
    May 29, 2013 at 21:05
  • See UPDATE in the original post where attempt to follow one of your guesses above (Link 2) was tried and I describe the slight change in the failure.
    – John Adams
    May 29, 2013 at 21:21
  • did you check "Compatibility" in Form Option ? i had problem to get user from that service and after i set Compatibility to "http:// Name of your Site /_vti_bin/userProfileService.asmx.asmx", everything work.maybe instead of this ,you see "http:// Name of your Site /_vti_bin/FormsServices.asmx"
    – behrouz
    Jun 1, 2013 at 15:58
  • Edit : i should say that i never used .UDCX file, so try to test with no .UDCX file.Create Form Library in sharepoint and Publish your Form (Design with Blank Form) via Site Content Type and then go to Form Library and change Content Type and see result
    – behrouz
    Jun 1, 2013 at 17:10
  • I set Compatibility exactly as you described above and then I redid the whole form (this time without .UDCX file) and published to new Forms library. Now I get "cross domain" error (yet I already enabled Cross Domain in Central Admin). Here is what happens when I browse form (see next comment).
    – John Adams
    Jun 3, 2013 at 18:31

Your problem may be related to service account settings. An indication to that could be if the Form runs fine in Filler Preview and fails when published to the Forms Services.

Try monitoring the HTTP traffic on your farm with NetMon/Wireshark, and correlate ULS records with the presence or absence of requests in IISW3C logs (the IIS logs ex_YYMMDD.log under %SystemRoot%\Inetpub\LogFiles\W3SVC).

We had a complex environment where requests from InfoPath data adapter tried to loop back through a proxy which didn't let it go back to the farm servers or required authentication. If you use client certificate authentication, it also sometimes produces 500 errors on reverse proxy, so try to eliminate that as well.

The classic Loopback issue might also affect you.

  • Thanks Alexey BUT the original post states in Symptom 2 above that PREVIEW does NOT run fine (screen captures show error). So your 1st paragraph seems like a guess that does not apply (e.g. what service account(s) besides the current account I describe?). I would not know what to look for in your 2nd idea. I ran Fiddler and all it shows is the HTTP 500 error with no reason codes, nothing useful. I am not using a proxy nor client certificate authentication. I am using Classic Authentication in all SP web applications. Loopback issue as described is NOT happening on my server. Thanks for trying
    – John Adams
    May 29, 2013 at 17:52
  • I wrote my answer with a purpose to add food for thought for other troubleshooters to face such problems on this or other SharePoint versions. The InfoPathDA usually runs under the w3wp.exe process, so, look at the WebApp Application Pool account's internet options for proxy, etc. Fiddler is not the tool for troubleshooting the communication from the server process to itself or another instance of this website in the farm. May 30, 2013 at 10:46

This is a good example, I think, of how badly wrong things can get over relatively simple things. Here is my best summary:

When entering the URL of the webservice, I typed according to documentation that proscribes:


However, all my work with InfoPath is on our mysites web application which is on port 81 not port 80; that is, http://blacktip:81/mysites/sharepointAdmin

Thus, when I entered this:


I get this mess of an error message:

"A query to retrieve form data cannot be completed because this action would violate cross-domain restrictions. If this form template is published to a SharePoint document library, cross-domain access for user form templates must be enabled under InfoPath Forms Services in SharePoint Central Administration, and the data connection settings must be stored in a UDC file in a data connection library in the same site collection."

As stated above, I enabled cross-domain restrictions but the AND in the stupid error message led me down the rabbit hole....no need for a UDC file ! This only complicated matters and led to all sorts of bad leads.

All I had to do was to eliminate the UDCX file and connect to the web service via:


Sometimes, it just pays to call for help directly at Microsoft Product Support.

Your Answer

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

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