I’ve spent the past few days setting up a Visual Studio 2008 Team Foundation Server machine in a small network I use for training classes and to research topics for articles I write for Microsoft’s MSDN Magazine. The installation process was not as smooth as it could have been so I figured I’d jot down some of my experiences to help out anyone who might be installing TFS 2008, and to record some of the details for myself to refer to when I install TFS 2008 again. To summarize, the installation document, which is embedded into the TFS 2008 setup.exe (if you launch setup you get a menu where one of your options is to view the installation guide), is fairly well-done but there are a couple of glitches that could catch you. I strongly suggest you go through the entire installation document before you begin installing because many mistakes are not recoverable in practice.
My environment is a small-scale TFS 2008 scenario where everything (TFS 2008, the backend SQL Server 2005, and SharePoint Services 3.0) is on a single machine, and security is not a major concern. First, start with a blank machine. Do not even think of trying to install TFS on a machine with any existing software. My machine is an old Dell Optiplex GX280 desktop with 512MB of RAM. This is severely under-powered and you really need at least 1.0GB of RAM for a realistic small-scale scenario. I installed Windows Server 2003, and associated Dell drivers (audio, video, network, chipset). Then I configured IIS 6.0 and ASP.NET on the server. After a reboot, I applied Windows Server 2003 Service Pack 1. Finally I joined the machine to my little research network, and then logged onto the machine as a domain administrator. No problems so far.
One of the more confusing parts of the installation instructions revolves around accounts and permissions. The documentation is inconsistent in several minor spots, but just enough to cause confusion. Anyway, I created domain accounts TFSSETUP and TFSSERVICE, and assigned them to the Administrators group on the local machine. The documentation says not to do this for account TFSSERVICE but security is not a major concern for me and security access problems can be nightmarish. This allowed me to skip going to Local Security Policy, User Rights Assignment, and messing around with log-on-as-a-service and allow-log-on-locally entries because Administrators get all that (and more of course). Also, forget about a separate TFSREPORTS account for SQL reporting services, and I didn’t need a TFSPROXY account because I’m putting everything on one machine. I logged off the server and logged back on as TFSSETUP.
The next step is to install SQL Server 2005. The installation guide is very good here. For Components I selected everything except for Integration Services and Notification Services. For Instance Name I accepted the default. For Service Account I used TFSSERVICE. For the Startup Services I selected all five of them. For Authentication Mode I selected Windows Authentication. For Collation Settings I accepted the default. Now in the Report Server Options be sure to select the non-default "Install But Do Not Configure". I did not select any of the Error Report settings. After SQL Server installation completed, I rebooted and applied SQL Server SP2 — I had very bad experiences with SP1 and strongly recommend SQL SP2 instead. After another reboot I was ready to install TFS 2008.
After installing SQL, I downloaded the KB925673 patch for MSXML 6.0 parser, but when I started its installation, the setup program told me I didn’t need the patch. (I think SQL SP2 upgraded the MSXML parser).
I was logged on as account TFSSETUP. After the splash screen and license agreement stuff, for Destination Folder I accepted the default. For Database Server I accepted the default, which was the name of the local machine and was automatically filled in. The System Health flagged my machine as being under-RAMed but didn’t block setup from continuing. For the Service Account I selected the non-default "Specify an Account" option and entered mydomain\TFSSERVICE and its password. For Reporting Services I selected the "Use Team Foundation Server account" option. For Windows SharePoint Services, I selected "Install SharePoint Services 3.0 on this computer". For the SharePoint Account I selected the "Use Team Foundation Server account" option. For Alert Settings, I did not check anything. With my fingers crossed, I clicked Install, and after some time got a Success message.
Next, after a reboot for safety, I installed Team Foundation Build. Here I followed the installation document exactly. After the Welcome, License, and System Check, for the Destination Folder I accepted the default. For Service Logon Account I typed in mydomain\TFSSERVICE and its password. After clicking Install, I eventually got a Success message. But on a reboot I received a One or More Services Failed to Start error message. By checking the System Event Log I noticed the error was something to the effect that a Server Scheduler could not contact the remote database. I tried various things without success. I suspect that, because both SQL and TFS are on the same machine, after a reboot TFS is looking for SQL which hasn’t started up yet. My work-around was to go to Services, and change the "Visual Studio Team Foundation Server Scheduler" service startup type from Automatic to Manual. Next I installed Team Explorer without incident so I can manage the TFS machine locally.
Well, there you have it. Once the TFS was up and running, I then created a Team Project, configured overall server group membership, added a Visual Studio Web Application Solution to the project (typically forgetting to do a View | Other Windows | Pending Changes and checking in the new files,) configured project membership, and manually created Workspace mappings on all the client machines in the training lab. But that’s another blog story.
== Addendum: Notes for Setting up a Web Project on TFS
Log on to the TFS server machine with the account used to install TFS. Connect to TFS using Team Explorer (Tools | Connect to Team Foundation Server). Add a few additional Server Administrators by right-clicking on the TFS server name in TE, and selecting Group Membership. Right-click on the TFS Server name and chose New Project. Accept all the defaults. The project takes about 5 minutes to create. Note: You can delete demo projects using the command-line utility tfsdeleteproject.exe with "/force /server:vtexxx ProjectName" arguments. After the project has been created, right-click on the project name and add a few accounts to the Project Administrators group, and add Domain Users to the Contributors group. Now go to some client machine and create a file system based Web project. Build the project. In general you’ll have files Default.aspx, Web.config, and a .sln file. You will have a Default.aspx.cs file unless you created a blank project and then manually added code and de-selected the default "place code in separate file" option. Connect to the TFS and select the appropriate project. Now do a File | Add Solution to Source Control. After that process be sure to do a View | Other Windows | Pending Changes and then Check In the files. Now, for each client machine, including the machine you used to create the Web project, you must create a Workspace. Note: a bogus Workspace will be created on the development machine. Go to File | Source Control | Workspaces. Delete any existing Workspaces because if they are mapped to the local directory you want to use you’ll be blocked. Note: this means that if you’re ever going to retire a TFS machine, you want to connect each client to the project and Remove any Workspaces before blasting the TFS machine away. In the source path, select the root of your project, not any sub-directories. In the destination path, select any convenient directory. Now you should be good to go. You can do a File | Source Control | Open From Source Control. TFS will warn you that you are going to overwrite existing files in your destination directory, but that is usually what you want.