A while ago I made the classic mistake of installing the Beta2 of TFS on our live servers after seeing posts that it was reliable enough for production use. I had stupidly assumed that there would be an upgrade path to the RTM; there usually is from the last beta, but not this time.
TIP: Don't ever do this yourself, only use beta's in places you can throw them away without any issues.
So to fix this problem you have to remove the beta before you can install the RTM. We run a dual server configuration with the application tier on a VPC so I backed up the TFS DBs on our central SQL server, made a copy of the VPC and enabled the undo disk. I then tried to remove the beta 2, and it failed with a message DepCheck indicates Microsoft Visual Studio 2008 Team Foundation Server Beta 2 - ENU is not installed.
I had a search and found some similar reference to the error in http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2048187&SiteID=1 that suggest running
"C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Microsoft Visual Studio 2008 Team Foundation Server Beta 2 - ENU\GetCurrentTfsProperties.exe" "%TEMP%\TfsProperties.ini" "Config"
Which as expected reported it could not find all the properties required.
So I had a problem, I could not de-install the old version to put the new one on. But then I got to thinking - I am trying to get this server back to a clean empty state - why not just create a new one? Just like a disaster recovery situation.
So I...
- Built a new server and added to our domain.
- I install WSS3 manually so that I could set the DB location to our dedicated SQL server.
- I installed SQL reporting services and patched it, again pointing it to our SQL server.
- I then ran the TFS 2008 installer, giving it the location of our DB server, as if just adding a new application tier.
The problems then started. I got a TF220065 RS WMI RPC Server is unavailable error - which sounds like a reporting server install problem (which it is I suppose). When you check the logs it turns out the installer has looked on the db tier for the URL of the AT reporting services location. The db still thought I was using the old AT server, so was getting an error the old server could not be found (because it was off). You can this fix by hand by editing the entry in the tfsintergration.tbl_service_interface table on the DB server. Once this is done the install runs OK until you get TF53007 & TF50801 errors. I guess there is a manual fix for this, but the better solution is to use the proper tool for registering the new server name, which fixes the follow-up errors as well. You can run this from the old TFS AT server, or I guess any PC.
TfsAdminUtil activateAT <New AT COMPUTERNAME>
Once this was run the setup ran to completion.
Now this meant I had a new AT pointing at our old DBs, so I could see all our old team projects, I could access work items,reports and source control. However, for each team project I could not access the site portals or document repositories, but I expected this as I had recreated the whole of the WSS system with a new content DB. This was not an issue for us as we had chosen to use our main company MOSS 2007 system for documents, not the WSS install within TFS (the main reason for this choice being for TFS2005 the portal was a WSS2.0 install and we had already moved to SP2007).
If you want to recreate the TFS portal sites go into the WSS Central Admin and create a site with the right name e.g. http://mysserver/site/project1 and an appropriate template. You then have to give the new site appropriate user rights and all will be OK i.e. you can see the portal and documents from within team explorer. Of course you could also restore a backup of your old install if you had important data.
So I was quite pleased with myself by this point, I had worked all this out by myself. I thought it was all working until I tried to create a new Team project, this failed at creating the SharePoint site point of the wizard. It failed irrespective of the template chosen. The error on the wizard dialog was TF30217 but checking the detailed log it showed the real error was
TF30267: Exception: System.Web.Services.Protocols.SoapException: Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.Event Description: TF30162: Task "SharePointPortal" from Group "Portal" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: The Project Creation Wizard encountered an error while uploading documents to the Windows SharePoint Services server on [my server]
Exception Details: The Project Creation Wizard encountered a problem while uploading documents to the Windows SharePoint Services server on [my server]. The reason for the failure cannot be determined at this time. Because the operation failed, the wizard was not able to finish
Now this proved to be a nightmare to fix involving many hours of fiddling and calls to Microsoft support. As with so many of this type of problem the fix was trivial when we spotted it. The problem turned out to be due to alternate access mappings in SharePoint. In effect when TFS creates a new site this is equivalent to the STSADM command
stsadm -o createsite -url /sites/projectsite">https://<server>/sites/projectsite -ownerlogin DOMAIN\user -owneremail user@domain.com -sitetemplate _GLOBAL_#1
The key issue was if I used the url https://realservername/sites/projectsite it work, but if I use the full alias url (which I need so the correct SSL wildcard certificate can be used) e.g. https://tfs.domain.co.uk/sites/projectsite it failed even though tfs is a cname alias for the host realservername on our DNS server. They should be equivalent.
Now I knew SharePoint/IIS needs to know about any extra names you give to servers. I had put an alternate access mapping in SharePoint to cover just this issue (via Central Admin, Operations), but I had made a mistake. I had added the alternate mapping as http://tfs.domain.co.uk - oops should have been https. Once this tiny change was made it leapt into life.
I have to say the error in the TFS create log were not that helpful, neither was the output of the new TFS Best Practice Analyzer. In the end it was found by creating many sites with STSADM.
I must say thanks to the persistence of Microsoft Developer Support in both India and the USA in getting this last issue sorted.
So now I have a fully working TFS 2008 install, I can start to have a look at the TFS to Project Server connector.