This week I tried to add a new project collection to our TFS 2010 Beta1 test system. All seemed to be going OK, the settings verified without issue but I got the error TF252005 when it tried to create the associated SharePoint site (on the WSS 3.0 instance on the TFS application tier).

Now unlike TFS 2008 this was not a blocking problem. On 2008 if any team project step failed, such as the team WSS site creation, then the team project was rolled back. It is a really nice feature of 2010 that if there is an error it does try to do as much as it can. So in my case, I ended up with TFS collection with no associated SharePoint site collections, not what I wanted but usable.

The detail of the error I got are shown below:

[10/6/2009 9:35:57 PM][Warning] TF252005: Configuration of SharePoint Products and Technologies failed with the following error: Server was unable to process request. —> User cannot be found.. Failed to create a path to the SharePoint site. Your account might not have the required permissions to create a sub-site on this server.
[10/6/2009 9:35:57 PM] Servicing step Configure SharePoint Settings passed, with warnings. (ServicingOperation: Install; Step group: Install.TfsSharePoint)
[10/6/2009 9:35:57 PM] Executing servicing step Create Test Management Database. (ServicingOperation: Install; Step group: Install.TfsTestManagement)

So the question was ‘what user could it not find?’

Upon further investigation I found that I could not give users rights on any of the previously created SharePoint sites on this WSS instance. The SharePoint People Picker said it could not find users or groups for the domain user accounts I entered. Also I noticed that if I entered the central admin it said that all my site administrators’ accounts were invalid (all underlined red in the configuration form). Basically it seemed my WSS instance could not find the domain controller.

I next checked that the Reporting Services instance on the same box, this had no problems resolving accounts, so I knew it was specifically a SharePoint issue.

So an investigation of SharePoint settings started. In the end it was Rik who found the root cause, and it was obvious with hindsight, the authentication provider was unset. Once this was set to Windows for all the zones everything leapt back into life.

The question remains how this setting could have become unset. We did have a domain controller hardware failure last week but I cannot see why this should cause this issue. Anyway at least it is fixed now.