3 comments
.NET 
With the upcoming release of Team Foundation Server RC announced by Jeff, we needed to make sure we could move to that release as soon as it comes available. Therefore we needed to migrate our current production environment that runs on Beta 3 of TFS to Beta 3 refresh, because that is supported as an upgrade path to RC and RTM.
Last Friday I did this upgrade, but a little different then described in the migration guide. Reason to do this was that we have experienced some problems with our server and we want to rule out the possibility of incorrect install of the OS. Therefore I decided that we needed to do a clean install of the machine from the provided installation media. So the main difference in my upgrade scenario was that I did not uninstall previously installed software, but just build the server up from the ground up again. I found this scenario to work almost flawlessly except for one thing that kept me busy for quite some while.
The Beta 3 refresh of TFS requires Share Point services Service Pack 2. For some reason I don’t know share point randomly selects a port number for it’s administration website during installation. This also includes the location of the administrative web services used by TFS. This is what broke my installation. Because my previous installation of Team Foundation Server had a different endpoint registered for its share point interaction, creation of new projects in the team explorer failed. I discovered this mismatch based on the log file created at project creation time and determined a miss configuration. The only question was how can you fix this?
What I did here was to determine the registered information by calling the http://localhost:8080/services/v1.0/Registration.asmx web service of Team foundation Server (just invoke it without any toolId specified). This returns you a list of all registration information kept in the TFS server. I discovered that the service endpoint for share point was incorrect and needed to fix this. I opened the TfsIntegration database and opened the table tbl_service_interface. In this table there is an entry with the name “WssAdminService”. This pointed to an incorrect URL that used the wrong port for my new share point installation. After altering the port in URL I was able to create new projects again. I guess hacking the tables of TFS is not a supported scenario, but I can imagine it can work for you as well as long as you don’t tell anybody J
3 comments
Out of curiosity, was there a doc somewhere that specifically listed Beta3 as not supported to RC/RTM for upgrade? It *should* be just as supported AFAICT – there weren’t schema changes between the two IIRC.
James Manning
James,
I got the information that the upgrade would only be from B3R to RC and RTM from the lecture we got at the devlab last august and this was confirmed to me by reading the following post at team foundation blogs (http://blogs.msdn.com/team_foundation/archive/2005/11/15/493188.aspx) HEre it states that the following upgrade paths are supported:
B3 to B3R Yes (reinstall)
B3R to RC Yes
B3R to RTM Yes
RC RTM Yes (should be a reinstall)
B2 to any No (blocked)
CTP to any No (blocked)
This made me asume that B3 to RC or RTM is not supported.
Thanks,
Marcel
marcel de Vries
I’ve talked with Allen, and it looks like it’s a bandwidth issue on our side – we don’t have the resources to also test B3 to RC, so while it may (and really, should) work fine, it’s not in our "supported" list unfortunately.
The one caveat I should include is CMMI – the B3 CMMI was pretty broken, so if you happen to be using that methodology, you should definitely get to B3R first before upgrade 🙂
B3R is an easier path for us to test since we had moved to the final bits for Whidbey and Yukon as well.
James Manning