I've recently been involved in migrating a series of InfoPath Forms using SharePoint Forms Services from 2010 to 2013.
I've suffered a lot to make a successfull migration and this was mainly due to security and Claims-Based authentication. Here are the problems I noticed and their possible solutions.
Classic mode to Claims => Forms Services web services failures
One of the biggest change when migrating SharePoint 2010 to 2013 is the authentication mode. As you might know, 2013 is based on Claims-Authentication by default while 2010 is based on Windows Authentication, the so-called classic mode.
While classic-mode is still possible in 2013, this is not a recommended approach anymore. Microsoft even recommends migrating the 2010 to Claims before performing the actual migration to 2013. Also, you have to migrate the stored user credentials to Claims as well using PowerShell (easy to do).
Which impact does Claims have on Forms? Well, the impacts are quite huge. The forms that are using SharePoint web services and/or FRPC calls will not work anymore.
So, if you have a form calling listdata.svc or OSSSVR.dll, they will not work anymore. The reason is easy : when Claims-Authentication is enabled, Forms Services is not able to retrieve the user credentials (SAML token) and reverts to IUSR (anonymous) to perform the web services calls.
This ends-up in a 403 (Access Denied)....because SharePoint is expecting authentication, at least for non anonymous web apps. This was actually already the case in 2010 but since most of the 2010 farms are still based on classic mode, you don't even notice that "problem".
Something you'll notice when you create a SharePoint webapp in Claims mode from the Central Administration is that the corresponding IIS webapplication will have anonymous access enabled+Forms authentication enabled as well. This is in this exact scenario that Forms Services stops working with extra web services calls.
However, if you create a webapp in Classic Mode, anonymous access isn't enabled at IIS level. If you switch that webapp to Claims afterwards via PowerShell, it's not changing IIS anonymous settings and Forms Services keeps working fine with web service calls even in Claims...However, I wouldn't recommend that approach since it might have some side-effetcts and you'd better chose the right authentication mode at creation time.
So, what's the solution?
It seems that the only possible solution to avoid anonymous requests is to use the Secure Store Service, map users and/or groups to some Windows Credentials and then reference the Secure Store Service SSO in your UDCX connection file. That way, Forms Services will use the SSO to connect to the web service. However, this is only usable in situations where you can afford to use a technical account to consume your web service. This is not a passthrough authentication but rather a kind of revert-to-self auth.
If you're calling custom web services (not SharePoint ones), it is also possible to allow anonymous calls...depending on your security requirements.
Don't trust the preview mode
While this was also valid in 2010, don't trust the preview mode of InfoPath if you plan to use Forms Services. Indeed, with the preview mode, the web service connections will work just fine as opposed to Forms Services. This is because when you make a preview, this is the rich client that performs the requests, not Forms Services.
InfoPath Designer 2013
While at last InfoPath Designer 2013 isn't based on VSTA 2005 anymore (it was really time!), the bad news is that the 2010 projects fail to convert properly. This failure results in InfoPath Designer not being able to load the custom code...it throws an error such as "the specified path cannot be found...". Even remapping your form to the project doesn't help...The only solution is to remove the code and recreate the project from scratch at the time of writing.
I hope that Microsoft will fix that since it's really a pain in the a..
Of course, any other component that would be manipulating users login names needs to be claims-aware as well. Except that, I didn't notice other troubles with Forms Services but as you can see, you'd better take this into account when planning your migration.
One technique to localize InfoPath forms is explained on MSDN at the following address. Basically, the idea is to embed your resx files into the form, associate a default one with a XML data connection and then, dynamically load the right resx file corresponding to the current locale of your SharePoint site.
However, what this article doesn't mention and what I couldn't find anywhere is that there is a small trap when using this technique. Indeed, if you do as specified in the article, you'll be facing a silly error and switching from one language to another will just not work.
It will work from the InfoPath Designer previewer but not from Forms Services (once published to SharePoint). This problem is because the path determined by the FileLocation property is not the same...In InfoPath Designer, it contains only the name of your resx file, say myfile.en-US.resx while in Forms Services, this path is prefixed by x-soln:///...
Therefore, in your code, say the loading event, you'd better add this check and adjust the path accordingly:
if (Application.Environment.IsBrowser) ResxFilePath = "x-soln:///"; dc.FileLocation = string.Concat(ResxFilePath,"your file","the dynamic locale",".resx"); dc.Execute();
Recently, I've been involved in migrating InfoPath web browser 2007 electronic forms to a SharePoint 2010 forms server.
Although, most of the forms work "as is", I lost a bit of time on a specific form since I kept getting the following error:
Value does not fall within the expected range.. Type: System.ArgumentException. StackTrace:
at Microsoft.SharePoint.SPWeb.GetFile(String strUrl)