Welcome to my blog, stay tunned :

SharePoint 2013

Migrating InfoPath Forms Services applications from 2010 to 2013 - Gotchas


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.

Happy Coding!

Rating System for SharePoint Foundation 2013


I've been asked a few times whether I'd migrate my rating system (MOSS 2007, SharePoint Foundation 2010) to SharePoint Foundation 2013. At first, I wasn't too enthusiastic as I'm doing that during my free time and I had many other things to do.
But it turned out that I've just finished my book on 2013 so I've had a little bit more time to handle that migration. So I did it!
I made a "as is" migration. It means that I didn't add any new feature nor did I make something specific for 2013. It's just working as before.
I had to perform some adjustements regarding the Site Definition & regarding the list view rendering since now, list views are based on Display Templates (JSLink) but that's it. So, installing this new WSP (Farm Solution) onto Foundation 2013 before (or after) having upgraded your 2010 databases should make it just fine!
However, rating discussion boards is now only partially supported, that's the only small difference. This is due to the change in rendering list views and the discussion board is a very specific one.
You can download this 2013 version on CodePlex http://sptoolbasket2013.codeplex.com/

Happy Coding!

Content Type Explorer App


I've just released a new SharePoint-Hosted App on CodePlex https://sptoolbasket2013.codeplex.com/releases/view/91909.
Sometimes we need to delete content types but we don't always know where they are used. Because you cannot delete a content type that is still in use, this App helps finding which lists and/or child content types make use of a given content type.

Here are some screenshots:

The App is localized in French & English and will be available soon on the SharePoint Store.

Happy Coding!