Team Foundation Server

I recently installed TFS Beta3 Refresh in a dual-server mode and also moved the code base (including Version Control) from an existing single-server installation (in Beta 3) in a different server. The install showed gaps in Microsoft documentation and moving of the code base was extremely hairy.
Here is the proper order of installation in the data and application tiers:
1. User Accounts
a. Create 3 domain user accounts, one for the setup, second for the service and third for the reports. These should be service accounts whose passwords do not expire. These should be created prior to starting the installation, because the setup account is needed to login.
b. The setup account and service account should be Administrators in the application tier. The setup account, the service account and the reports account should be admin in the data tier.
c. Note down the passwords of all these accounts as they are needed in different steps of the install.


2. Data Tier Checklist
a. Login to the data tier computer using the domain user account for setup.
b. Check if Windows 2003 SP1 is the OS version in the data tier. If not, install it.
c. Install IIS 6.0. (This is not mentioned in Microsoft documentation but it is necessary for Reporting Services.)
d. Install .NET Framework 2.0.
e. Now, check if the local user account ASPNET is created in the computer; you can check this by going to Administrative Tools->Computer Management-> Local Users and Groups and click on Users. If ASPNET is a user, you can proceed to step f. If not, proceed to step e.
f. Open a command window and navigate to C:\Windows\Microsoft.NET\Framework\. Run (from the command window) aspnet_regiis –i. This installs ASP.NET 2.0.
g. Start the Microsoft SQL Server 2005 install. Follow the install as suggested in Microsoft documentation (for TFS). Make sure to check Reporting Services in the list of services to install.
h. When prompted for the Reporting Services account choose “Use the built in System account” option. For the rest choose default options.
i. After install try accessing: http://localhost/ReportServer (assuming you installed in the default website). If it does not throw an error, continue.
j. Now you are read to install TFS (databases)
k. Follow Microsoft documentation for installing TFS (databases).

3. Application Tier Checklist
a. Login to application tier computer using the domain user account for setup.
b. Check if Windows 2003 SP1 is the OS version in the data tier. If not, install it.
c. Install IIS 6.0
d. Install .NET Framework 2.0.
e. Now, check if the local user account ASPNET is created in the computer; you can check this by going to Administrative Tools->Computer Management-> Local Users and Groups and click on Users. If ASPNET is a user, you can proceed to step f. If not, proceed to step e.
f. Open a command window and navigate to C:\Windows\Microsoft.NET\Framework\. Run (from the command window) aspnet_regiis –i. This installs ASP.NET 2.0.
g. Install Windows Sharepoint Services SP2. After installation, to reboot (even if it does not prompt you).
h. Check if WSS was installed correctly by navigating to Administrative Tools->Sharepoint Central Administration. If a web page comes up with configuration information, continue.
i. You can start the install of TFS (services) and follow it as given in Microsoft documentation.
j. At the end of the install, open Administrative Tools->Internet Services Manager. Expand the websites node and check that there is a web site called Team Foundation Server.

This completes the installation of Team Foundation Server. TFS can be managed using Team Explorer, which is part of the install package. Team Explorer can be installed either in the application tier computer or in a development computer.

Note: The only administrator account by default in TFS, after a fresh installation, is the domain account for Setup that we use during installation. Team Foundation Server administrators are a separate group from computer (server) administrators.


4. Client Tier Checklist and Information
a. Install Team Explorer by choosing client tools from the installer.
b. Now, ping the application tier computer mentioned above by name. Make sure it resolves.
c. For testing Team Explorer, open Visual Studio 2005. In the Tools menu, choose “Connect to Team Foundation Server”. Add the application tier server name.
d. For testing permissions etc, right click on the server (in Team Explorer) and choose Add an Existing Project and see if you can browse existing projects)
e. An administrator needs to add other users to a project or as admins by right-clicking on the server name in Team Explorer and choosing Team Foundation Server Settings -> Security->Group Membership.
f. For testing if the interaction with Sharepoint and Reporting Services works, after the above step, right click on the server (in Team Explorer) and choose New Team Project (This will only work if you have permissions to create a new Team project. Otherwise, choose Add an Existing Team project). Type in a test project name in the wizard and try creating it.
g. The project templates are big and over slow connections, it takes some time setting up a new project.


Version Control Move
Moving from a single server to dual server was extremely difficult. In my case, the existing server was also in a different domain.
There are a couple of Microsoft documents that talk about this:
Help in migrating from Beta 3 to Beta 3 Refresh
This one can be followed mostly, except that it applies for migrating on the same server - it does not apply when you totally shift the data tier and application tier servers.
This document deals with shifting the data tier server.
Here are a few pointers:
The Source server is the existing server. The Destination server is the new server.
When you restore the databases in the Destination server, make sure that the Application Tier computer has its IIS service shut down and Stop the TFSServiceScheduler service.
Before restoring the databases in the Destination server, make sure that you take proper backups of the existing (default) databases in the Destination SQL server. I just renamed them.
Restore the Sharepoint databases first. The STS_CONFIG database is the configuration database for Sharepoint. The STS_[servername]_1 database is the content database.
When you shift the databases, the STS_CONFIG database tables still have data pointing to the old server. There are not many tables, and going through them and fixing them may help. I don't know of any scripts that help in this process. Another choice is to keep the STS_CONFIG database as it is, and move just the Sites table from the source database. The problem is, the Sites table has a foreign key from the Database table. So you may have to copy the database key, paste it and then insert
into the Sites table.
After restoring the content database, you have to open the Sites table in the content database and repoint the Urls to the Application Tier server.
The most important thing is getting Sharepoint working. You can verify if it works when you type in http://[apptier server name]/sites/[project name]. If it throws an error, you got a problem. The other indicator that Sharepoint has an issue occurs when you choose Sharepoint Central Administration from Administrative Tools in the application tier computer.
Some of the issues could be related to security. Check the Security users and roles in the STS_CONFIG and the content database. For reference, check the renamed (older default) databases.
Once Sharepoint works, restore the other databases (except for TfsWarehouse). Remember to keep the service stopped in the application tier computer.
After you restore all the databases, the TfsIntegration database needs to be repointed. There are four tables:
tbl_registry_entry
tbl_extended_properties
tbl_service_interface
tbl_subscription
After changing them and restoring security, try connecting using Team Explorer.
If Sharepoint works and Security is duplicated, the application should work.