This post will outline challenges that I’ve experience when migrating a SharePoint 2010 classic mode web application to claims authentication.
First of all, the process that needs to be followed for claims migration is documented on TechNet here:
NOTE: Be sure to review the “Additional migration guidelines” section at the end of the above article”.
Challenge #1 – InfoPath Browser Based Forms
In our deployment we have hundreds of InfoPath forms. These forms make use of two items that break when moving to Claims; username() function and web service calls.
InfoPath username() function
This function is used within InfoPath to retrieve the current users account. In a classic mode web application this function will return “domain\userid”. Once the web application is migrated to claims, the updated format is the claims encoded value of “i:0#.w|domain\userid”.
This change is easily resolved by changing instances of username() to substring-after(xdUser:get-UserName(), “\”).
InfoPath Calling Web Services
We have many forms that make use of the User Profile web service to retrieve user information. After the migration to claims, these web service calls were failing. After some research, I found a couple of different methods to resolve this issue.
Option 1 (Watch out with this solution)
Check out the “Ensure IIS Authentication is Correctly Configured” section. Once I made this change in IIS, the web service calls to the user profile web service were now working.
This option also breaks SharePoint Designer from being able to connect to SharePoint sites in the web application.
Update data connections to web services in InfoPath forms to be UDC files AND configure the authentication for the web service connection to use static credentials OR retrieve an account from a Secure Store Target Application.
There are many examples of this online, but here is a detailed post on the entire process:
Ideally, I’d prefer option 1 above, but since this solution breaks deleting files from document libraries, this is not an optimal solution.
Option 2 works and is supported, but the fact that we will have to update hundreds of forms that call web services does not sit well with me.
Challenge #2 – Workflow Issues After Claims Migration
The next issue that we encountered after our test migration was complete was an error with workflows. After the migration to claims, when clicking on an in progress workflow instance, the following exception would be thrown:
“Invalid WorkflowInstanceID parameter in URL”
The next logic step to troubleshoot was to try and take a look at the Workflow Association for the running workflow. When clicking on the Workflows button on the ribbon for the library, the following exception was thrown:
“User cannot be found”
After running through many more upgrades and re-validating the upgrade steps, we found that the build of SharePoint 2010 we were on apparently causes these issues. The farm version we ran into these issues was on build 14.0.6117.5002 which is the Feb 2012 Cumulative Update. Knowing that we were preparing for the June 2013 Cumulative Update (14.0.7102.5004), the update was applied to our test farm. After upgrading the claims migration process was run again and both of the above issues were resolved. All in-flight and new workflow instances work as they should.
It appears at some point MS has fixed these issues, however, I’m not sure which CU it was fixed in.