Problem with GetUserProfileByName - InfoPath Dev
in

InfoPath Dev

Problem with GetUserProfileByName

Last post 03-02-2011 03:38 PM by Hilary Stoupa. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • 02-26-2011 08:21 PM

    Problem with GetUserProfileByName

    I'm fairly new to SharePoint and InfoPath. I've been reading a lot on it, and have made a bit of progress - you guys have been really helpful. 

    I'm having a bit of a problem using the GetUserProfileByName function to display a greeting with the user's first name. Everything works just fine when I test it locally within the network, but when I access the form from the web, I get an error message. This is what is logged:

    The following query failed: GetUserProfileByName (User: DOMAIN\sp_sql, Form Name: Hardware Support Requests, IP: , Connection Target: , Request: http://portal.domain.com/_layouts/FormServer.aspx?XsnLocation=http://portal.domain.com/Hardware Support Requests/Forms/template.xsn&SaveLocation=http://portal.domain.com/Hardware Support Requests&Source=http://portal.domain.com/Hardware%2520Support%2520Requests/Forms/AllItems.aspx&DefaultItemOpen=1, Form ID: urn:schemas-microsoft-com:office:infopath:Hardware-Support-Requests:-myXSD-2011-02-17T16-02-58 Type: DataAdapterException, Exception Message: The remote name could not be resolved: 'portal.domain.com'
    The remote name could not be resolved: 'portal.domain.com')

    I'm thinking it might be a problem with AAM, and to be truthful, I don't know too much about it. Everything I know so far I've read on my own or asked questions on here.

    For my mapping, I have http://servername in as the default zone, and http://portal.domain.com as the internet zone. I set up a DNS pointer from http://portal.domain.com to the static IP for the SharePoint server, but since I'm behind a firewall, I have the firewall accepting all traffic and pointing it to the SharePoint server.

     Is there anything I might be doing wrong? 

     

  • 03-01-2011 02:28 PM In reply to

    Re: Problem with GetUserProfileByName

     No one?

  • 03-01-2011 09:26 PM In reply to

    Re: Problem with GetUserProfileByName

    When you publish the form to the site, are you changing the domain name for the webservice to match the domain name of the site you are publishing to?
  • 03-01-2011 09:48 PM In reply to

    Re: Problem with GetUserProfileByName

     I'm a little confused on what exactly you mean. The site is available both internally and externally. When publishing the form, I publish it with the server name ie http://servername/

    Shouldn't the alternate access mapping take care of everything if the form is being accessed from the internet?

  • 03-02-2011 03:38 PM In reply to

    Re: Problem with GetUserProfileByName

    I asked Clayton Cobb what he thought, and he said:

    The error itself is saying that the data connection isn’t working.  When Forms Services goes to query, my guess is it’s querying http://portal.domain.com/_vti_bin/UserProfileService.asmx, but the server itself doesn’t know what that is.  Not sure what he meant by a DNS pointer, but DNS inside the firewall should have a Host (A) record for portal.domain.com that points to the SharePoint WFE’s IP.  That way, all servers inside the network know what to do when portal.domain.com is browsed.  The key here is that Forms Services runs on the WFE, so all data connection requests are made from the server instead of from the user’s machine, so the server must be able to make all the data calls.  I can only guess that the server isn’t able to resolve the portal.domain.com, and that can be resolved via DNS or a Hosts file entry.

    In general, you can’t use different zones for InfoPath.  It has to be the same zone on all sides of the communication path.  SharePoint is very finicky about AAMs, and then InfoPath browser forms exacerbate the issue.  The whole chain should use the same host name:

    • Publish location
    • Data connection path
    • Site being browsed when opening the form

    There should be no switching or re-routing. 

    Hilary Stoupa

Page 1 of 1 (5 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.