If you have a Report Server e.g. as Part of a TFS 2010 Setup, and attempt to access your site locally (e.g. https://servername/Reports/) , you may get the following exception:
User 'DOMAIN\UserName' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed.
When creating a new project in TFS, you may also have the same problem accessing the Report server when the TFS 2010 new project wizard attempts to create a new reporting site. You may even be able to access the site remotely but just not on the local box.
To fix the problem, you can just go to Internet Explorer>Tools>Options>Trusted Sites>Sites and add the site experiencing the problems to the Trusted Sites zone.
Full details are here (Point 7 and 8):
http://support.microsoft.com/kb/934164
Note that you will need to restart Visual Studio for it to pick up the above changes in the TFS 2010 new project wizard.
DDK
Wednesday, 4 May 2011
Monday, 2 May 2011
Integrating TFS 2010 with SharePoint 2010 using SharePoint 2010 Claims Based Authentication Mode
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
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
Subscribe to:
Posts (Atom)