InfoPath: The SOAP message cannot be parsed.

A client wanted to use SSL across their SharePoint 2010 platform internally.  As part of that work, all of the InfoPath forms need to be updated.  There were three environments – Development, Test and Production.

The Production environment worked fine, but whenever I updated the data connections in Development or Test, I received the message:  “Unable to connect to the SharePoint site.  The SOAP message cannot be parsed.”

InfoPath_SOAP1

I struggled with this for awhile, and couldn’t work out what the problem was.  Whenever I reverted to non-SSL, I did not have any problems.  I initially thought that InfoPath did not like the self-signed certificates on Dev or Test, and I even tried domain trusted certificates similar to the Production environment, but to no avail.

I turned up full diagnostic logging on SharePoint, and it stood out that for some reason it was making requests to the non-SSL URL.  Whenever I tried it directly (eg http://xxtest01.xxx.internal/_vti_bin/Webs.asmx) I was redirected to HTTPS and received a valid response.

InfoPath_SOAP2

Finally, I took a look at the alternate access mappings, and discovered the problem – the public URL was not set to use HTTPS on Dev or Test, but was set to use HTTPS on Production.

InfoPath_SOAP3

As soon as I changed the public URL to https://xxtest01.xxx.internal, my problems in InfoPath disappeared and I was able to setup the data connections with SSL.

Diagnosing Problems with SharePoint Incoming Email

I was recently looking through some old notes about problems I had with incoming email with SharePoint. We had a process of scanning physical mail to departmental document libraries, and we had a success rate of just over 50%. Through a week of tweaking and testing, we sustained 100% successful delivery for several months.

I was using SharePoint 2010 and Exchange 2010, but I think the settings should apply for earlier versions. At the time of writing, I don’t have access to an Exchange installation to confirm settings. These are my rough notes, hopefully of some help.

  1. Check that the document library and contact is set to allow from all senders (network scanners were not regarded as authenticated users)
  2. Check the size limits on the SharePoint send connector (Exchange -> Hub Transport -> Send Connectors -> Properties -> Maximum message size (KB))
  3. Check the size limits on SMTP receiver on SharePoint (IIS 6 Mgr -> Properties on SMTP Virtual Server -> Messages tab -> Limit message size, Limit session size)
  4. Turn off SharePoint reading RTF documents from Exchange (Exchange -> Hub Transport -> Remote Domains -> Format of original message sent as attachment to journal report: -> Exchange rich-text format -> Never use)
  5. Check for potential mail routing problems (Exchange -> Hub Transport -> Accepted Domains -> Add domain for INTERNAL RELAY) – we noticed a couple of times the scanned mail tried to go external through our mail gateway – this was the last 1% of our problems.