-
-
I've done a few lab-based upgrades to TFS SP1 and one production upgrade. I definately recommend you upgrade when you can fit it into your production support schedule. Although there are already many posts about the upgrade experience I will relay my few notes here...
- Make sure you have backups. I didn't in my lab upgrades and did for my production roll but thankfully didn't have a need for them.
- Install the Quiescence GDR on your TFS. This will make sure the TFS services aren't listening to requests during the upgrade process and avoid corruption.
- Install the TFS SP1 on your TFS. Note that the VS2005 and TFS SP1 installers are multifaceted; they will install updates for all of the related (in this case TFS) products that are covered by the service pack. The Team Explorer service pack is part of the VS2005 service pack and not the TFS service pack.
What happens if there is a problem? Hopefully there isn't but let me point you to a few problems that have been reported as well as my own added notes.
- Dave Glover has documented a potential issue when upgrading TFS Workgroup Edition. Basically, make sure you free up some Licensed User slots before you start the upgrade.
- Anthony Borton has more detailed instrcutions than my summary including things like uninstalling beta releases of the service pack.
- There are numerous different posts with problems and solutions to the SP1 upgrades in the TFS Setup Forums. One of them deals with TFS instances that have changed domains since the initial install - which indirectly helped my with my setup issue.
If you have SharePoint issues and/or have moved your TFS databases...
I did have one significant problem trying to get the Quiescnece GDR installed. The system was complaining that one of the the SharePoint databases (I think it was STS_Content_TFS but it may have been STS_Config_TFS) was not on the data tier. It told me to reinstall SharePoint as described in the documentation. The strange thing is that the Project Portals were working fine!!!
What I didn't know is that the server had been initially installed as a single-tier configuration and later someone modified it to be a dual-tier configuration. The move had succeeded so well that I didn't even know it had happened. But there was one part... a part required by the GDR/SP1 installer that had not been fixed.
In the TFS directory under program files there is a file called "MSIProperty.INI". This file records key installation settings and is used by the new installers to determine how to handle configure themselves. In my case the following keys had to be modified...
VSTF_DB_SERVER=[ComputerName]
VSTF_DT_MACHINE_NAME_LOCAL=LOCALHOST
I changed the boldface text from these two settings to the name of my data tier server and everything started to work. If you have a similar problem I hope this helps you!
Happy Holidays!
-
-
Visual Studio 2005 Team System is a great product. If you're like me and spend most of your time work in the Team Suite version, it is easy to forget some of the idiosyncrasies with the product packaging. One of the big packaging criticisms that I've heard about VSTS is the necessity to have a copy of Team Edition for Software Testers to use your unit tests as part of the build process. The Test View window available in Team Edition for Software Developers allows interactive execution and basic management of tests, but does not allow the creation of "Test Lists."
Tests Lists are a hierarchical grouping of the tests available in a Visual Studio solution; they are created and managed using the Test Manager window from Team Edition for Software Testers. Test Lists are the mechanism required to specify which tests to run as part of a Team Build. Ekobit Online has just announced their own Visual Studio Add-In to fulfill this role... The Test Manager Add-In for Microsoft Visual Studio 2005 Team Edition for Software Developers provides the same basic functionality of the Microsoft Test Manager window without needing a license to the Team Edition for Software Testers.
Check it out!
-
-
One of my clients recently called with a Red Alert/Danger Will Robinson/[Insert high priority phrase here]. Their TFS was down! The problem appeared to be that the TFS databases were installed on the default C drive which was too small and completely out of space. They were pretty sure they knew the answer but wanted me to verify it. For everyone's benefits, I've documented the steps we used to move the TFS-related databases from the C drive to another location.
Note that they were already at a stop-work situation so things couldn't get too much worse. If you need to do something similar you should approach the process gingerly. Make sure your backups are good and realize that while you're doing this the TFS and its related services will be unavailable.
- Stop TFSServerScheduler, SharePoint Timer Service & SQL Server Reporting services..
- Right-click on "My Computer" in the start menu and select Manage.
- Drill into Services and Applications > Services.
- Locate and stop the aforementioned services.
- Stop the TFS-related Application Pools: ReportServer, TFS AppPool, TFSWSS, and TFSWSSADMIN. As an alternative, you may simply shut down IIS altogether if it isn't being used for anything else on the system. Also note that these application pools
- Still within Computer Management, drill into Services and Applications > Internet Information Services > Application Pools
- Right click on the aforementioned pools and select Stop.
- Open Microsoft SQL Server Management Studio (Start > All Programs > Microsoft SQL Server 2005 > SQL Server Management Studio) and connect to the Database Engine for your Team Foundation Server.
- Drill into the Databases node.
- Locate and Detach the TFS databases. To do this, right-click on the database and select Tasks > Detach... Click OK to detach the database. You can selectively choose the individual databases that you need to move or simply move all of the following:
- ReportServer
- ReportServerTempDB
- STS_Config_TFS
- STS_Content_TFS
- TfsActivityLogging
- TfsBuild
- TfsIntegration
- TfsVersionControl
- TFSWarehouse
- TfsWorkItemTracking
- TfsWorkItemTrackingAttachements
- Locate the database data files and transaction logs that were detached. By default they are in the following directory: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data. The following database files are candidates based on the same sort order shown in the previous list:
- ReportServer.mdf and ReportServer_log.LDF
- ReportServerTempDB.mdf and ReportServerTempDB_log.LDF
- STS_Config_TFS.mdf and STS_Config_TFS_log.LDF
- STS_Content_TFS.mdf and STS_Content_TFS_log.LDF
- TfsActivityLogging.mdf and TfsActivityLogging_log.LDF
- TfsBuild.mdf and TfsBuild_log.LDF
- TfsIntegration.mdf and TfsIntegration_log.LDF
- TfsVersionControl.mdf and TfsVersionControl_log.LDF
- TFSWarehouse.mdf and TFSWarehouse_log.LDF
- TfsWorkItemTracking.mdf and TfsWorkItemTracking_log.LDF
- TfsWorkItemTrackingAttachments.mdf and TfsWorkItemTrackingAttachments_log.LDF
- For each database, move the MDF and related LDF file from the source location to your selected destination.
- Return to Microsoft SQL Server Management Studio, reattach the database files in their new locations. You can do this as follows:
- Right-click on the Database folder and selecting Attach...
- Click the Add button.
- Browse to the new location and select the first MDF that you've moved and click OK.
- Repeat steps 2 and 3 to select all of the database files that you've moved.
- Once all of your databases are selected, click OK in the Attach Databases dialog.
- Verify that all of the original databases shown in step 5 above are displayed under the Databases folder in SQL Server Management Studio.
- Close SQL Server Management Studio.
- Restart the application pools that were shutdown in step 2. You can use the same steps from step 2 except that you select Start from the pop-up menu instead for Stop.
- As a good measure, after the application pools are restarted, I restart IIS itself. This probably isn't necessary but I am paranoid. If taking IIS down on your TFS server doesn't work in your environment, skip this step. To restart IIS, right-click on the Internet Information Services node in the computer Management console and select All Tasks > Restart IIS... If you opted to take IIS down as a whole in step 2, now is the time to restart it.
- Start the services that were stopped in step 1. This process is again the same as that given in step 1 except no you are starting services instead of stopping them.
- Bring up Team Explorer and verify that everything works. Make sure you check the work items, reports and team portals to make sure everything looks good.
- Take a peek at the Application and System event logs and make sure that nothing unusual happened during your testing of the new environment.