Grant Thompson's Blog

When installing Team Foundation Server 2008 using an existing MOSS deployment we ran into the following error:

TFS2200401: The specified Windows SharePoint Services site URL (http://server) is not the default site collection site: (). The default site collection site might have been renamed or removed. Make sure that the site exists and verify the correct URL, and then attempt installation. If the problem persists, you can choose to install and configure Windows SharePoint Services as part of the Team Foundation Server installation process.

I looked at the install log file: dd_install_vstf_at_90.txt and found:

wsschecker.exe : Another site already exists at http://server. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.

I tried a few different things with no luck.

Resolution:

In the end I created a new site collection (interesting the existing site collection was at http://server and not http://server/sites/x). When I created the new site collection I was given the default http://server/sites/ option and filled in a new URL. TFS installed fine from there.

Now we have to integrate the TFS site collection into the client's existing site collection or migrate their old site collection to the new one. J

I've seen a lot written about this particular issue. We just ran across this yesterday and here is how I solved it.

Symptoms:

Logging in to the MOSS/WSS Central Administration web site works fine from the local machine (MOSS central admin server) but when logging in from remote machines an NTLM prompt is presented and domain admin, domain farm admin, etc. accounts are "not authorized". The typical behavior of the NTLM prompt coming up three times before the error page (401.1) is displayed.

However, I found that if I logged in as the local machine administrator (of the MOSS server) it worked fine. For example DOMAIN\Administrator fails but SERVERNAME\Administrator works.

Troubleshooting:

It was clear to me that this was an authentication problem and had nothing to do with MOSS. To test my theory I created a simple web site in IIS and turned off anonymous access. Then I tried connecting to that site remotely and it worked. I had actually expected it to fail. Next I set my test web site to use the same application pool as central admin. This time my test site behaved the same as central admin. The common thread here is Kerberos authentication was not working when run using the central admin app pool user account.

I ran SetSPN (you can download this from www.Microsoft.com/downloads if you don't have it) –L domain\moss central admin account (in this case domain\MOSS_CA). Sure enough there were no entries.

Resolution:

Run SetSPN –A http/server.domain.local domain\MOSS_CA (remember that you need to substitute your server, domain and account).

Next open Active Directory Users and Computers (with access to your domain's AD) and find the domain\MOSS_CA account (whatever your central admin app pool is running under) and open properties. Click on the Delegation tab and choose "Trust this user/computer for delegation to any service (Kerberos)".

At this point I had to reset the password on the service(s) using the account and update the account's permissions in SQL Server. Then I rebooted and everything was working properly.

If you need additional information (i.e. more details about where to find your Central Admin app pool account, etc.) leave a comment and I'll do my best to get back to you.