Difference between filler and browser when calling GetUserProfileByName - InfoPath Dev
in

InfoPath Dev

Difference between filler and browser when calling GetUserProfileByName

Last post 03-12-2013 04:34 PM by Moises. 15 replies.
Page 1 of 2 (16 items) 1 2 Next >
Sort Posts: Previous Next
  • 02-05-2013 09:29 AM

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Difference between filler and browser when calling GetUserProfileByName

    OK, here's an interesting scenario.  When I publish an InfoPath Filler form to a form library on SP2010 using GetUserProfileByName, I can successfully retrieve attributes and data I need without issue.  However, the moment I change the form type to a Web Browser form, the data services call fails. The only difference is how it's published with compatibility either being a web browser form or InfoPath Filler form.

     What am I missing?

  • 02-05-2013 12:32 PM In reply to

    Re: Difference between filler and browser when calling GetUserProfileByName

    First thing to do is to look at the Design Checker in InfoPath which should tell you if there's an issue.

    My guess is that it has to do with the GetUserProfileService service existing on a separate machine in the same domain (because you have multiple front ends?). If so, try converting the data connectoin to UDC and see if that fixes it.

    Patrick Halstead
    Project Manager at Qdabra
  • 02-05-2013 01:28 PM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    After converting the data connection to a UDC, I now get the same error message, but a different number:

    "An erro occurred while trying to connect to a Web Service".  The log ID is 5566.  It was a different number earlier.

     I'll keep looking.

  • 02-05-2013 03:13 PM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    OK, from what I can tell from extensive searching, it looks like the issue is with SharePoint, most likely a permissions issue due to the root path having an explicit inclusion type.  I think this causes authentication issues in the data connection UDC file.

     Any ideas on how to get around this?

  • 02-06-2013 01:12 PM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    Here's the latest:  I installed and converted DBXL, using the aduserinfo.asmx web service and got it to work using Filler just fine.  The first time I tried to run my form in browser mode, I got an ugly error about cross domain forms allowed in InfoPath Forms Services and data connections that need to be in a data connection library.  I converted the connections to UDC files, republished the form, and then got this errpr:

    An error occurred while trying to connect to a Web service.

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

    Log ID:5566

    Correlation ID:8f147bc8-f568-4e8e-b758-d331f333c9d5

    I looked in the Windows Application logs under Applications and Services Logs/Microsoft/SharePoint Products/Shared/Operational and cannot find any instance of a 5566 error or the correlation ID.  Is there another place to look, and is this due to having 4 servers in the farm?

  • 02-06-2013 02:09 PM In reply to

    Re: Difference between filler and browser when calling GetUserProfileByName

    Can you check the SharePoint log files for the Correlation ID? You may want to just trigger the error again so that you can look in the most recent log file. Here's a post w/ the locations for ShP 2007 & ShP 2010.
    Hilary Stoupa

  • 02-06-2013 02:45 PM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    Unfortunately, I still get no hits for the error.  However, after much more research, I came across this: http://support.microsoft.com/kb/981684.  I tried method 3, the most unsecured way, and it works for specific credentials.  However, we need to impersonate authenticated credentials passing the users' creds.  I think by setting up a secure store service and modifying the UDC files accordingly, that might work.  We're waiting to see if we can restart the SharePoint server after creating the target application.

    I'll keep you posted.

  • 02-07-2013 07:56 AM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    OK, the latest.  I created a target application in Secure Service Store in SharePoint, with credentials being a service account that has access to the site.  I then modified the UDC files in the authentication section to include the following:

    <udc:Authentication><udc:SSO AppId='InfoPathWebForms' CredentialType='NTLM' /></udc:Authentication>

    InfoPathWebForms is the name of my target application.  Here's how that's set up in SSS:

    1. It is a target application type of Group, using Windows User Name and Windows Password.
    2. Members of the group, for now, are all authenticated users.
    3. In setting credentials, I use a service user account with appropriate permission.

    Now when I run the form, I just get the data for the service user, not the user logged in.  What am I missing?

  • 02-08-2013 06:41 AM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    I found the missing link!  Thanks to this blog, http://gordonduthie.net/2011/01/26/sharepoint-2010-claims-based-security-infopath-data-connections-and-getuserprofilebyname/ , I was able to narrow down how to get reliable user data using SSS and an anonymous user in the target application.  Specifically, for InfoPath Forms Services, when calling a web service for user information, whether using GetUserProfileByName or Qdabra's GetUserInfo, the parameter passed must be "concat("your domain\", xdUser:get=UserName())".  For my purposes, I set an onload rule for GetUserInfo, populating the username field under the queryFields node for the secondary data source.  Then I query the data source, and the correct user's data displays.

    The key points are to establish a target application in Secure Service Store on the target SharePoint server, store the data connections as UDC files, modify the files as listed in the above post, then instead of automatically gathering the data when the form loads, set rules to explicitly populate the username query field with the concat string mentioned.  You should use the UserName built-in function if you're polling data for the current user.

    Hope this helps others struggling with browser forms not working like their InfoPath Filler counterparts.

  • 02-08-2013 07:13 AM In reply to

    Re: Difference between filler and browser when calling GetUserProfileByName

    Thanks so much for posting the resolution for this - I'm sure this is going to be helpful for others. Glad you are up and running and have great day!
    Hilary Stoupa

  • 02-09-2013 05:39 PM In reply to

    Re: Difference between filler and browser when calling GetUserProfileByName

    Thanks Tom for your patience and perseverance. I'm sure others will benefit.

    Patrick Halstead
    Project Manager at Qdabra
  • 02-28-2013 02:34 PM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    OK, a new wrinkle has been added.  Yesterday, my forms solutions worked.  Today, I'm getting the dreaded 5566 error again.  I was finally able to find the relevant SharePoint log specific to the event.  Strangely enough, even when the form is published as full trust the error still occurs.  The error indicates an issue with the server not allowing the code to execute, and the only thing I know has changed are SharePoint 2010 timer services were restarted on each node of the SP farm.

    Here's the text of the error message:

    The following query failed: GetUserInfo (User: , Form Name: Adjustment of Charges, IP: , Connection Target: https://forms.corp.integris-health.com/eForms/eForms Data Connections/GetUserInfo.udcx, Request: , Form ID: urn:schemas-microsoft-com:office:infopath:Adjustment-of-Charges:-myXSD-2013-02-04T19-12-58 Type: DataAdapterException, Exception Message: The custom code in the form cannot be run. This functionality may be deactivated on the server. For more information, contact the server farm administrator.

    The custom code in the form cannot be run. This functionality may be deactivated on the server. For more information, contact the server farm administrator.)

    I'm using the web service call provided with DBXL, and it's published as a trusted UDCX file.  Again, working yesterday, today, not so much.

    One other thing, don't know if it's related, but the SP server is throwing low disc space errors on the page drive.  Disk space is doled out sparingly at our organization, and the farm is running on VM's exclusively.  Could this be the source of the issue?

     OK, I just found this from 12:43 today:

    The following query failed: GetUserInfo (User: , Form Name: Product Failure Report, IP: , Connection Target: https://forms.corp.integris-health.com/eForms/eForms Data Connections/GetUserInfo.udcx, Request: , Form ID: urn:schemas-microsoft-com:office:infopath:Product-Failure-Report:-myXSD-2013-02-04T19-12-58 Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error.

    System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.ArgumentException: The (samAccountName=) search filter is invalid.at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()

    at System.DirectoryServices.DirectorySearcher.FindOne()

    at Qdabra.ActiveDirectory.AdUserInfoImpl.SearchDirectory(String ldapPath, String filter, String[] propertyNames)

    at Qdabra.ActiveDirectory.AdUserInfoImpl.GetDirectoryEntryFromProperty(String path, String property, String value, String[] propertyNames)

    at Qdabra.ActiveDirectory.AdUserInfoImpl.GetDirectoryEntryFromAlias(String path, String alias, String[] propertyNames)

    at Qdabra.ActiveDirectory.AdUserInfoImpl.GetADUserInfo(String path, String username)

    at Qdabra.ActiveDirectory.AdUserInfoImpl.GetUserInfo(String username)

    at Qdabra.ActiveDirectory.AdUserInfo.Qdabra.ActiveDirectory.Services.IAdUserInfo.GetUserInfo(String username)

    --- End of inner exception stack trace ---

    The remote server returned an error: (500) Internal Server Error.)

    Can I safely assume that based on "System.ArgumentException: The (samAccountName=) search filter is invalid." that something changed in our AD environment?

  • 03-01-2013 06:49 AM In reply to

    • TomRenfro
    • Top 75 Contributor
      Male
    • Joined on 09-29-2011
    • Oklahoma City, OK
    • Posts 134

    Re: Difference between filler and browser when calling GetUserProfileByName

    Latest update:  our SharePoint farm had several services that had stopped that we weren't aware of.  This was likely caused by severe disk space issues on all nodes of the farm.  Our support staff cleaned up all they could and cleared up significant space. 

    One of the serivces, Secure Store Service, had crashed and was the likely cause of the form problem.  After the space issue was dealt with and services restarted on the farm, domain permission (qRules injected) forms work properly, no errors.

    For now, all is good.

  • 03-08-2013 03:57 PM In reply to

    • Moises
    • Not Ranked
    • Joined on 12-26-2012
    • Posts 3

    Re: Difference between filler and browser when calling GetUserProfileByName

    Buenos días Llevo 3 dias tratando de corregir el problema de Se ha agregado una entrada al registro de eventos de Windows del servidor. Id. de registro:5337 No se pudo realizar la siguiente consulta: GetUserProfileByName (usuario: SIGSA\moises.corrales, nombre del formulario: GASTOS COMPROBADOS WS, dirección IP: , destino de la conexión: , solicitud: DataAdapterException, mensaje de excepción: Error en el servidor remoto: (401) No autorizado. Ya hice todo el procedimiento como lo mencionan y desde código tampoco me puedo conectar al servicio web UserProfileService.asmx, en InfoPath en vista previa funciona bien pero cuando lo subo al servidor ya no funciona. Como puedo corregir mi error o alguna idea, para que salga de mi problema
    Filed under: ,
  • 03-09-2013 12:16 PM In reply to

    Re: Difference between filler and browser when calling GetUserProfileByName

    Tom: thanks, I'm guessing disk space issue was why it failed.

    Hi Moises,

    Google translated your post as follows:  Good morning took 3 days trying to fix the problem Added an entry to the Windows event log of the server. Registration ID: 5337 Failed to perform the following query: GetUserProfileByName (user: SIGSA \ moises.corrales, form name: WS audited expenditure, IP address:, connection destination:, request: DataAdapterException, exception message: remote server error: (401) unauthorized. already did the whole procedure as mentioned and since no code I can connect to the Web service UserProfileService.asmx in InfoPath preview works fine but when I upload it to the server no longer works . as I can correct my mistake or some idea, to come out of my problem

    If the form has no code in it (i.e. no sandbox requirements), you can convert the data connection to a UDCx file and that may solve your problem.

    If the form has code (my guess), you will need to admin approve it to allow impersonating of the user account. 

     

    Here's the Google translate back:

    Si el formulario no tiene un código en el mismo (es decir, sin requisitos de caja de arena), puede convertir la conexión de datos a un archivo udcx y que puede resolver su problema.

    Si el formulario tiene un código (yo creo), necesitará al administrador lo apruebe para permitir suplantación de la cuenta de usuario.

    Patrick Halstead
    Project Manager at Qdabra
Page 1 of 2 (16 items) 1 2 Next >
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.