Retrieving User Information in InfoPath without Code – One solution to ‘Value cannot be null. Parameter name: serverContext’

InfoPath, SharePoint and Web Services are becoming sparring partners for me of late. 

In order to retrieve user information in my InfoPath form I followed the instructions at itaysk’s blog, as I wasn’t aware I could use a SharePoint Web Service to get profile information.  Sweet – I thought.

I then immediately got:

The User Profile Manager object could not be loaded. —> Value cannot be null. Parameter name: serverContext

This was an error noted by quite a few people, but with very few solutions.

I then got out Fiddler as I do, to see what was going on, and remembered that InfoPath tends to expand url’s into their fully qualified domain names (FQDN) – so you may have entered http://mylocalnetworkserver/_vti_bin/etc.asmx but if you’re on a corproate network or anywhere with DNS happening then you’ll suddenly find yourself calling http://mylocalnetworkserver.some.other.domain.gumph/_vti_bin/etc.asmx.

Why is this important you ask?  – Well I then thought ‘I’m sure there wouldn’t be anything logged on the server?’  – well SharePoint probably logs a lot more than most realise, but the error in this case was staring me in the face in the Event Log:

A Windows SharePoint Services Error – Event ID 8214.

A request was made for a URL, http://mylocalnetworkserver.some.other.domain.gumph, which has not been configured in Alternate Access Mappings.  Some links may point to the Alternate Access URL for the default zone, http://mylocalnetworkserver.  Review the Alternate Access mappings for this Web application at http://mylocalnetworkserver:1234/_admin/AlternateUrlCollections.aspx and consider adding http://mylocalnetworkserver.some.other.domain.gumph as a Public Alternate Access URL if it will be used frequently.  Help on this error: http://go.microsoft.com/fwlink/?LinkId=114854.

Well blow me down.  All the other web services I call from InfoPath don’t care about this because they’re not hosted in SharePoint, and SharePoint manages the allowed paths into the application. 

Once I went to the Central Admin site –> Operations –> Alternate Access Mappings, and edited ‘Public Zone URLs’ to add the FQDN to the intranet zone (probably could choose any zone), it just started working.