Migrating Team Foundation Server 2010 Beta 2 to new servers

Disclaimer : It worked for me, and I hope it works for you, but do so at your own peril. Make sure everything is backed up and I’d suggest testing on a spare machine first before doing it for real.

We’ve been looking at changing our infrastructure at work and moving from VMWare for our virtual servers to using Windows Server 2008 and Hyper-V. The main server which needed to be moved/converted/migrated between the two different virtualisation technologies was the TFS Server; and hence my domain.

I started off by trying to convert the vmdk file to a vhd file which seemed to work well and could be mounted and the data on it read. However; I was unable to boot from it. After spending, way, too much time trying to get it working I decided to look at the migration exercise. And to be honest it was essentially a disaster recovery exercise as we’d have to go through the same steps if it all went wrong so the time wasn’t wasted.

So after doing a test run on a spare virtual machine we had before the server was taken down I fired up the install for SQL Express and started on the path to setting up TFS. After doing some Googling, and finding loads of different articles which seemed to do bits but not all of it I thought I’d post my findings to hopefully help someone in the future. These are the steps which I came up with. I have also now deployed TFS into the new virtualised production system and it seems to work fine (not got automated builds working yet tho).

Here we go:

1. Backup databases from old TFS. This includes the Tfs_Configuration databases and any project collection databases.
2. Build/patch new VM with Windows Server (or other OS)
3. Install SQL Express 2008 with tools
4. Restore databases, with the same names, into your new SQL Server instance
5. Install Team Foundation Server 2010 Beta 2 (and reboot when required)
6. Run the following command – making sure that you have the correct details in the right places
   
   c:\Program Files\Microsoft Team Foundation Server 2010\Tools>tfsconfig accounts /add /accountType:applicationTier /account:"NT Authority\Network Service" /sqlInstance:.\SqlExpress /databasename:tfs_configuration
   
7. Create a local user named after the server name. So for example if your server is called “TFS” then create a local user called “TFS$” (without quotes)
8. Fire up the Team Foundation Server admin, go to configure installed components and run the Application Tier only upgrade wizard
9. Once in the wizard point it to the SQL instance locally and it should find the configuration database, select it and continue.
10. Finish the wizard and it should be pretty happy. Next thing to do is update the server urls on the main server details page to point to the new server name (as it’ll have the old server name in it)
11. Start up the project collection(s) and throw in a server restart for good measure.
12. Done!

You should now be able to connect to the server through Visual Studio as before. You will need to add in the new server details (and remove the old). I found all the workspaces where fine and all was good to go.

With a big team its probably wise to get everyone to shelve all their changes over a weekend or evening and make sure nothing is checked out. But this is down to preference and may need to be tested.

Hope this helps someone in the future :-)

TFS 2010 Beta 2 unit testing automated builds

I’ve been setting up Team Foundation System 2010 Beta 2 at work over the past couple of days. First starting off with doing it on a virtual machine locally to do some testing, but then deploying it into the virtual server environment we’ll be using it in for every day development.

I was initially very impressed by the ease of setup of the system. Talking to people and ready some blogs about setting up previous versions of TFS it was a complete pain with caused serious issues with server setup, permissions etc. TFS 2010 is soooo simple in comparison. Microsoft have thought about this side of things a lot and made setting it up very simple.

We went for the basic setup as we don’t need a lot of power or more than source control, automated builds and work item tracking.

Anyway, setup of the machine was fine and enabling communication between the tfs server and my laptop running Visual Studio 2008 sp1 was fine (just needing to make sure that Team Explorer is installed, followed by running the VS SP1 setup again, then the forward compatibility patch) and the first solution of code was checked in. A small utility dll project and associated unit test project. As the plan is to use this utility in all future development, a “tool kit” as you would, it made sense that this should be setup to have an automated build. It would also enable me to learn how to setup automated builds.

Enter first issue, no reference issues relating to “Microsoft.VisualStudio.QualityTools.UnitTestFramwork.dll”. Due to this issue the test project could not build as it had references to a namespace it couldn’t find.

C:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.Common.targets: Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

To resolve this initially I installed the C# components of Visual Studio 2010 Beta 2 on the server. I had originally just done the unit testing parts but this didn’t resolve the issue. The obvious issue with this is that we don’t want to have the full version (or any part of) Visual Studio installed on the server so I did this on a VM locally to see if resolved the issue … it didn’t :-(

Break through

After doing some more search on Google, I found this post from Grumpy Wookie about the location of the gacutil in the SDK, and another link (which I can’t seem to find in my history, sorry) relating to the fact that there aren’t the correct versions installed in the GAC on the server. So after checking the versions and seeing there weren’t any there …

I copied the following dll from my dev machine (with VS2008 on):

Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

To

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5

I then opened a cmd prompt on the server and navigated to where the SDK resides and ran the following cmd:

C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin>gacutil.exe /i "C:\Program File
s (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.Visua
lStudio.QualityTools.UnitTestFramework.dll"

This loaded version 9 of the UnitTestFramework into the GAC. This allowed for the automated build to run and to run the unit tests in my solution. Only issue now is the fact that it seems to be running with v10 MSBuild/MSTest with the v9 unit test assemblies and because of that it doesn’t like the one test which is using the ExpectedExceptionAttribute. At the moment I can live without this test being run on the server … but roll on march when the full version of TFS/VS 2010 come out and I can upgrade my development environment.

Hope this helps.

Team Foundation Server 2005 - adding files when offline

I've recently been given a laptop at work to be able to work on the commute between my home (Leamington Spa) and work (Reading) and here comes the issue, TFS doesn't like it much when working disconnected.

I've done some research online and found that some of the issues which TFS has in 2005 version are addressed in 2008, but as we won't be uprading for a while I need to live with 2005.

This morning on the way to work I needed to add a new workflow activity to my project so I could carry on with work, obviously right click > add new item > activity, TFS client moans about not being able to connect to the server (no really?!) and VS adds the file with no source control bindings. The file is added and I can edit it, compile etc and work away fine on it. However the issue comes to making sure it gets added to source control for when I check it in it doesn't break the automated build. Due to this issue I decided that if I added / edited a file when offline I'd make a note of which and to add it / check it out when I got into the office.

I got in this morning and connected the wireless, went to source control viewer to add it in and couldn't find the folder where it exists (even though its in an existing folder) ... hmmm strange. So, found the file in solution explorer, right click > ... no "Add to Source Control" which is a bit rubbish. However there is a really simple solution ...

If you right click on the file in question and exclude it from the project, save the project file, click on the "Show all files" button at the top of solution explorer and find the file in the greyed out version, right click and add to project ... it gets added to source control :-)