locked
UserProfileService & (401) Unauthorized RRS feed

  • Question

  • Ok, I've gone through a lot of questions/fixes for similar problems but none some seem to fit my situation or resolve my issue.

    I have an Infopath form using UserProfileService.  It is published to be a web-form.  We use Kerberos.

    We have two 'Alternate Access Mappings' for our intranet (which becomes relevant to the problem below).  http:// sharepoint.<domain>.com and http:// sharepoint

    The problem is, a majority of users (including Farm Administrators) get a "Exception Message: The remote server returned an error: (401) Unauthorized." message on the User Profile Service when they load the form from the fully qualified http:// sharepoint.<domain>.com url.  However, when using the shortened version, the profile service works fine

    The UserProfileService connection is setup for the fully qualified <domain>, but I have changed it to use the short name, however the problem still only occurs on the fully qualified link. 

    On a couple of machines we get no error at all - regardless of who logs in or which URL is used the form works fine (in the browser - not loading in Infopath filler).  This leads me to think it is a setting local to the machine(s) rather than a 'permissions' issue. 

    I've ensured both URLs are included in the browser's Local Intranet zone.  I've compared DNS settings between the working and non-working machines.  We've tried the registry setting and HOSTS file suggestions as found here http://sharepointconnoisseur.blogspot.com/2011/04/how-to-resolve-401-unauthorized-error.html.  Thus far we've come up empty handed. 

    Any suggestions on settings I should look into in this situation? 



    • Edited by spi_shane Wednesday, October 3, 2012 2:51 PM odd urls
    Wednesday, October 3, 2012 2:48 PM

Answers

  • Thank you everyone for your help.

    We found the source problem to the issue.  The fully qualified URL had a typo in the HOSTS file on the server.  (I was working in the HOSTS file for the local machine - while troubleshooting and only glanced at the server HOSTs file previously and must had missed the typo). 

    The littlest things are always the hardest to find.

    • Marked as answer by spi_shane Monday, October 8, 2012 5:49 PM
    Monday, October 8, 2012 5:49 PM

All replies

  • Hi,

    I am trying to involve someone familiar with this topic to further look at this issue.  There might be some time delay, appreciate your patience.

    Thanks


    Daniel Yang

    TechNet Community Support

    Thursday, October 4, 2012 9:39 AM
  • As an update

    I've discovered playing with the HOSTS file that it appears to work on some machines and not others due to which Web Front-end server they hit.  #1 appears to work on http:// sharepoint/ and http:// sharepoint.<domain>.com, while the server #2 only the http:// sharepoint/ works.  I'm not sure why the default full URL wouldn't work, and the secondary shortened one would... 


    • Edited by spi_shane Friday, October 5, 2012 6:05 PM typo
    Friday, October 5, 2012 6:04 PM
  • I recall having something like this a while ago and it was caused by a double hop issue where credentials were lost due to jumping between WFEs.

    Have you added the BackConnectionHostNames registry key? Normally I do this and list all my web application urls. I tend to add host file entries on the WFE's pointing to themselves. 

    Does this thread help?

    http://social.msdn.microsoft.com/Forums/da-DK/sharepointinfopath/thread/ea355b62-9b3c-45f3-aaa2-2d09f63e2484

    Friday, October 5, 2012 8:48 PM
  • Thank you everyone for your help.

    We found the source problem to the issue.  The fully qualified URL had a typo in the HOSTS file on the server.  (I was working in the HOSTS file for the local machine - while troubleshooting and only glanced at the server HOSTs file previously and must had missed the typo). 

    The littlest things are always the hardest to find.

    • Marked as answer by spi_shane Monday, October 8, 2012 5:49 PM
    Monday, October 8, 2012 5:49 PM