This is my second, and hopefully last post detailing the work I did to upgrade TFS to 2008 Beta 2, move computers and change domains. You can read part 1 here. As it stands, the source control and work items are working, reports are almost working, SharePoint is on life support, and I should purchase stock in Pepsi given how much Mountain Dew I have consumed during the course of this adventure.

Work Items

All of our work items were assigned to users in the previous domain. Even if I had followed the instructions and added "throw-away" accounts in the new domain, they would still have to be updated. Using the built in support for viewing work items in Excel, made it pretty easy to change. Just open a query in Excel, and do a find/replace all for the user name. I only had 4 projects and 5 users, so it wasn't too bad. You do have to open up each project separately, so if you had allot of projects, it could become tedious, at which point I'd probably look to writing a SQL script to do the update for me.

Work Spaces

In TFS, you can only have a physical path on a specific computer, mapped to a TFS workspace once, regardless of the user or TFS server. In my case, a conflict arose because of the change in user names. There were plenty of hits on Google for the error message, but they all pointed to removing a xml file that caches workspace mappings locally. This didn't help me, as the problem was on the TFS server itself. Using the TFS command line tool tf, I was able to view all of those workspaces from my local machine using "tf workspaces /owner:*". The /remove option only seemed to work with the local cache file, and even after installing VS 2008 on the TFS server, the tf tool was no where to be found. This was because I installed as much as I could to E, and the environmental variable was set to C:

There doesn't seem to be an option to update the username for a workspace, if the user id has changed (which is what happened in our case). So I'm going thru and deleting the workspaces using "tf workspace /server:TfsServer /delete workspace;owner". There are allot of workspaces that no longer make sense due to computers no longer existing in the new domain. These can be removed outright, along with workspaces that have no pending changes associated with them. Since I had very few changes, and didn't care about them, I decided to delete my workspace to see what would happen. After recreating the workspace and doing a get latest, my changes were overwritten without any warning. I was hoping to have the option of merging, but unfortunately I did not. At this point I am going to have to have a couple of developers take a look at their pending changes and decide if they need to manually merge them.

While I was searching for a way to change a workspace owner, or what the effects were of deleting a workspace with a pending change, I came across a free set of tools that provide a GUI to some of the command line stuff. Check it out here.

Web Access

As long as I'm going cutting edge (Beta 2 with a go live license is cutting edge, not bleeding), I figured I'd install the CTP of the Web Access power tool. We have a couple of people who need to edit/view work items who are not developers, so avoiding an install of Visual Studio/Team Explorer is idea.

Other then requiring Team Explorer on the web server (which is already present since this is going on the TFS server), the Web Access is a pretty light weight install, and I have no fear of not being able to upgrade to the release version of the power toy. I originally tried to install it under the default web site with integrated authentication since this is used over a VPN only, but that failed with a trust issue. I then moved it to it's own virtual site running in it's own application pool, and it worked fine.

Reporting Services:

I fixed my permissions issue, it was a bad password on the OLAP data source. However, I have another problem. The warehouse does not seem to be getting updated, as there is no data in the reports. I also get an error message in the event log: "System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated." I can reproduce the error by directly invoking the warehouse thru the web service, so at least as I try fixes, I can verify quickly if they worked or not.

Doing some searching, I came across this article (which I've come across before), which is a step by step guide to identify issues with the warehouse. Given my symptoms, I decided to delete and rebuild the OLAP warehouse using the command line tool specified in the article, as well as the TFS migration guide. "setupwarehouse -o -s datfsp100 -d TfsWarehouse -c Warehouseschema.xml -a Domain\TfsService -ra Domain\TfsReports -v -mturl http://Server:8080 -rebuild". I then manually invoked the warehouse update from the web service, checked the application logs (clear), checked TfsWarehouse.CurrentWorkItems (actually had something), and checked the reports (they had data). My only remaining concern is that the warehouse updates on it's schedule (UPDATE: Everything is working normally after 1 day of monitoring).

SharePoint:

I was following the MSDN instructions (see previous post) for restoring SharePoint as part of the restore based migration. However, I ran into an issue in that I could re-add the content database. To recap, I restored the STS_Content_TFS database to the WSS_Content database. I then used Sharepoint Administration to remove the content database, and was trying to re-add it. When you go to add it, it tries to name is WSS_Content_Random, so remove the random stuff so you are left with just WSS_Content. I then had to grant DB_Owner permissions to the WSS_Content DB for my TFSService account, which is what the SharePoint admintool application pool was running as. After setting DB_Owner rights, I was able to add the WSS_Content DB as the content database, after which I went into Application Management\Site Collection Admins, and changed the primary admin from my old account, to my new account. I was then able to connect to share point sites so that I could start setting up the other user rights permissions. I was very happy to see Sharepoint working again, as I thought I was in for another all night battle.

I was having an issue whereby I could browse the site from computers that belonged to the new domain, but unable to browse to it from other computers. This is because the web app was talking my FQDN and turning it into just the host name, and the  computers outside of the domain could not resolve that. This was fixed by using SharePoint Administration to add a new external link for the intranet zone for the FQDN (this is done under alternate mappings). This issue was also present when trying to view reports from Sharepoint, as the links were redirecting thru a TFS helper page, which was not user the FQDN. I fixed this by editing the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\ReportServer\80\sites

Cleanup:

• System drive on the TFS VM was getting a little low, so I created a new 3GB virtual disk and moved the swap file over to it.
• Setup new backup schedules and cleaned up the log files from the restore 
• Event logs are looking pretty clean.

Final Thoughts

I don't think I used consistent formatting in either of my two posts, which probably is a violation of blogging etiquette, and will not win me and readers choice awards anytime soon. The Microsoft documentation was very helpful, and definitely saved me allot of time compared to either doing it on my own from scratch, or compiling a guide based on Google. I'd like to see the TfsAdminUtil changeaccount operation support changing user accounts instead of just service accounts. I expect the in place upgrade to TFS 2008 RTM will be easy, and hope to never have to migrate TFS again anytime soon.