Data Connections

Re: Difference between filler and browser when calling GetUserProfileByName

Moises — Tue, 12 Mar 2013 23:34:10 GMT

I researched more about the error and you create a file with multiple UDCX guide me http://itguru.asia/?cat=5 manuals like this and still does not work, so try from code, I am not the central administrator, then I have little for which to configure. Any idea? Thank you very much for taking the time to answer Keep checking the same error Error al intentar conectarse a un servicio web. Se ha agregado una entrada al registro de eventos de Windows del servidor. Id. de registro:5566 Id. de correlación:7bf7f13b-176e-439f-9fea-4f6375a4d47b No se pudo realizar la siguiente consulta : GetUserProfileByName (usuario: SIGSA \ moises.corrales , Nombre del formulario : WS gasto auditado , IP dirección : , destino de la conexión : , petición : DataAdapterException , mensaje de excepción : a distancia server error : (401)

Re: Difference between filler and browser when calling GetUserProfileByName

Patrick Halstead — Sat, 09 Mar 2013 20:16:56 GMT

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.

Re: Difference between filler and browser when calling GetUserProfileByName

Moises — Fri, 08 Mar 2013 23:57:00 GMT

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

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Fri, 01 Mar 2013 14:49:47 GMT

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.

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Thu, 28 Feb 2013 22:34:48 GMT

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?

Re: Difference between filler and browser when calling GetUserProfileByName

Patrick Halstead — Sun, 10 Feb 2013 01:39:17 GMT

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

Re: Difference between filler and browser when calling GetUserProfileByName

Hilary Stoupa — Fri, 08 Feb 2013 15:13:17 GMT

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!

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Fri, 08 Feb 2013 14:41:10 GMT

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.

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Thu, 07 Feb 2013 15:56:34 GMT

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:

It is a target application type of Group, using Windows User Name and Windows Password.
Members of the group, for now, are all authenticated users.
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?

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Wed, 06 Feb 2013 22:45:40 GMT

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.

Re: Difference between filler and browser when calling GetUserProfileByName

Hilary Stoupa — Wed, 06 Feb 2013 22:09:51 GMT

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.

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Wed, 06 Feb 2013 21:12:20 GMT

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?

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Tue, 05 Feb 2013 23:13:35 GMT

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?

Re: Difference between filler and browser when calling GetUserProfileByName

TomRenfro — Tue, 05 Feb 2013 21:28:57 GMT

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.

Re: Difference between filler and browser when calling GetUserProfileByName

Patrick Halstead — Tue, 05 Feb 2013 20:32:50 GMT

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.