I recently attempted to create a TFS 2010 portal against a remote portal in SharePoint 2010. However, if you attempt to create this TFS 2010 Remote portal against a claims-based authenticated web application, you will typically get the following exception:
TF218017: A Sharepoint Site could not be created for use as the team project portal. The following error ocurred: Server was unable to process request. --> The User does not exists or is not unique --> The User does not exists or is not unique.The problem is the same as the one experienced here:
http://social.msdn.microsoft.com/Forums/en-US/tfsgeneral/thread/bd396f15-02d7-4431-9d75-005c8b63007e/
The error related to "Unique Users" so I had a look in the SharePoint Content database to see if there were duplicate users with the following query:
select * from userinfo
Indeed there are two active users with my loginid for the one web application. Both were active.
One loging was named (in the tp_Login column of the table) as you'd expect as:
DOMAINNAME\LoginName
Whereas the other was named with an unusual prefix "i:0#.w" like so:
i:0#.w|DOMAINNAME\LoginName
However, this didn't present a problem when creating sites within the site collection through the normal SharePoint 2010 user interface. I created sites with both my account, the setup account and service account - there were no errors releated to uninque users at all.
While this "i:0#.w" prefix on logins is not documented, it identifies a login as using claims-based authentication. Thing is that it doesn't make sense that there would be both claims-based and classic users both active for the one site collection - unless that behaviour is by design for backwards compatability. My theory - on the TFS side, the SharePoint object model is unexpectedly (from the TFS 2010 perspective) returning 2 accounts against the one login.
I used Wireshark and Fiddler to trace the calls that TFS Team explorer is trying to make when creating project sites, and it it was making a call to https://servername/_vti_bin/TeamFoundationIntegrationService.asmx. It is making a call to the "CheckUrl" method. An internal error (500) is thrown by the webservice - as per the screenshot of the Fiddler trace:
Upon further investigation, the physical webservice is in the following location on the SharePoint server:
%Program Files%\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\TeamFoundationIntegrationService.asmx
Looking inside the asmx, it points to the Microsoft.TeamFoundation.SharePoint.TeamFoundationIntegrationService class in the
Microsoft.TeamFoundation.SharePoint.dll assembly.
The SharePoint 2010 ULS Logs have only very basic information reiterating the error in Team Explorer - "The user does not exist or is not unique".
Looking for the CheckUrl method definition in Reflector, it runs many checks using the Office 12 object model - but nothing clearly erroneous in the code warranting further investigation. We could run something like the Visual Studio.NET plugin for reflector to step through the code - but I didn't think it was worthwhile continuing investigation into the problematic calls in the TFS object model.
I had another search and according to "Chris Co" from Microsoft (http://social.msdn.microsoft.com/Forums/en-US/tfssetup/thread/a2665904-ec35-4dff-a809-69c2c9316378) "This is something the product group is thinking about supporting in the future, but unfortunately, we currently do not support and will not be supported in SP1."
So for now, if you want your TFS Portal to be hosted in SharePoint 2010, your SharePoint 2010 web application will need to use Classic rather than claims authentication.
DDK
1 comment:
This was so great, I could not find this information anywhere else! Thank you, thank you!
Post a Comment