My task for the past week, and likely for the next week, is the migration of our production TFS 2005 server (data), to a new server, running TFS 2008, in a new domain. The process that seems to have work somewhat, is to upgrade the existing TFS server to 2008 Beta 2, then do a restore based migration using the MSDN documentation. There are a few issues to clean up, and you can read about them in my follow-up post. Preparation - Start with a clean Win2k3 R2 SP2 32bit OS. This OS is vitalized under ESX server.
- Read over the latest version of the installation guide located at: http://go.microsoft.com/fwlink/?LinkId=79226. I will be doing a single server installation, which all TFS components on the same server. At this point, I am unsure of where the build server components will go, and will be the topic of another post.
- Create service accounts for use with TFS.
- TFSService
- TFSReports
- SqlServiceInternal - Not required for TFS, but a service account for running SQL server under (vs. local system).
- Turn on Windows Firewall with Remote Desktop. I prefer to get things working with Windows Firewall running. The installation guide says that most ports will be added to Windows Firewall exception list, but some manual configuration will be necessary.
Prerequisite Installation on New Server - Install IIS as per the instructions in the installation guide.
- Do not install FrontPage server extensions 2002, this is explicitly stated in the guide.
- Do not install WSS at this time, as 3.0 can be installed with TFS.
- I also added the option for a local smtp service, such that it can handle sending emails to our primary email server, preventing individual applications from being blocked while waiting for mail to be sent.
- Install SQL Server 2005 Standard Edition as per the instructions in the installation guide
- The following components are required
- SQL Server
- Reporting Services
- Analysis Services
- SQL Browser Service
- I also installed the management components.
- IT Requests:
- Install all components to the E:\ Drive, which is the "data" drive. Some stuff is hard coded to install to the C:\Drive
- Move all log files to the F:\ drive, which is designated for logs.
- Moving Log Files
- Follow these instructions from MSDN on moving system database: http://msdn2.microsoft.com/en-us/library/ms345408.aspx. Before installing user databases, change the data base properties such that the default install locations are correct.
- Move model, msdb, and temp db using the following commands (You can run all 3 at once, then shutdown and move all 3 log files):
ALTER DATABASE model MODIFY FILE (Name=modellog, FileName='F:\SqlLogs\modellog.ldf')
ALTER DATABASE msdb MODIFY FILE (Name=msdblog, FileName='F:\SqlLogs\msdblog.ldf')
ALTER DATABASE tempdb MODIFY FILE (Name=templog, FileName='F:\SqlLogs\templog.ldf')
- Shutdown SQL, move the log files on the file system, then restart sql server.
- Verify success by querying the system database
SELECT name, physical_name AS CurrentLocation, state_desc
FROM sys.master_files
WHERE database_id = DB_ID(N'DatabaseName');
- Move the master database. Follow the instructions from the MSDN article, as it's a little more involved. Here is the command line statement I executed for the step to move the resource database.
E:\Program Files\Sql\90\Tools\Binn>sqlcmd -S 127.0.0.1 -d master -E -Q "alter database mssqlsystemresource
modify file (name=log, filename='f:\sqllogs\mssqlsystemresource.ldf')" - Make sure that when you go into single user mode, that all SQL services are stopped, otherwise they will take the single connection that is available.
- Install SQL 2005 SP2
- There is an issue with SP2, and having the ldf file for mssqlsystemresource in a different location. If possible, on a clean installation, I would install sp2, then move the ldfs. If you move the ldf's, then install sp2, copy the newly created mssqlsystemresource.ldf from your default data file location to your custom ldf location, overwriting the old ldf.
- Install QFE KB925673 from the TFS installation media
- Change to static IP
- Download and install .Net Framework 3.0
- Snapshot server so we can roll back changes if we need to do this again, either with fresh data, or because something went really bad.
Upgrade Existing TFS 2005 to 2008
- Snapshot existing server
- Backup databases for extra safety
- Turn on windows firewall to prevent access to TFS during upgrade process, although at 12:30am I don't think many people are trying to access it.
- Even though the upgrade instructions didn't tell me to do this, I shut down the TFSServerScheduler
- Install to E:, even though original installation was to C, C drive was running very low on space.
- Installation failed on first attempt. Exact failure was during the .net 3.5 beta 2. This might have been due to the fact I was down to < 250MB free space on my System drive. Reverted the snap shot to start over.
- Moved the 2GB page file to the E:\ Drive to free up some space. There was also some updates that had not been applied.
- Applied all updates, and then installed the .net 3.5 Framework by itself first.
- Checked to make sure I could still connect to TFS, but I could not. It failed with error TF30331, which is a generic can not connect error. Looking at the error details, there was mention of assembly manifests not matching. A quick Google search yielded a result indicating to try aspnet_regiis -i, which fixed the problem.
- Now was a good time to back up the databases and perform a snapshot.
- TFS upgrade went better this time, no errors.
- The virtual servers in IIS were wiped and reset, which was a bit of an issue. We were running on https port 8088. Adding the cert back was easy, as was changing the port, however, there are several places that need to be updated to point to the correct url and port. I was getting 503 and general asp.net errors.
- Edit app.config in E:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\TfsScheduler
- Edit URLs web.config in E:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Web Services
- Update TfsIntegration.dbo.tbl_subscription. There were 4 new rows for the default URL. I removed the 4 new rows.
- After updating the config files, TFS started working again.
- I noticed that there was a lack of commands available from the source explorer view on machines that only have VS 2005.This didn't seem to have an impact for the 1 day that TFS was running.
TFS Install
- Install TFS 2008 to E:\...
- Install TFS 2008 Team Explorer to E:\...
- Snapshot
- Copy TFS databases to new TFS server
- Started out by following instructions on how to move from 1 server to another server.
- Use RSKeyMgmt -l to generate Reporting Services Accounts, there was 1.
- Stopped TFS Scheduler and WSS Timer services
- Stop the SQL Server that Reporting Services was running on, which is the only sql server on the box.
- Restore TFS, ReportServer, and Sharepoint databases to SQL 2005 (I would suggest scripting this out so you can easily re-run the next time thru).
- Databases
- ReportServer
- ReportServerTempDB
- STS_Content_TFS -> WSS_Content
- TfsActivityLogging
- TfsBuild
- TfsIntegration
- TfsVersionControl
- TFSWarehouse
- TfsWorkItemTracking
- TfsWorkItemTrackingAttachments
- The only tricky one was the sharepoint content database as the name changed. I used the following T-SQL:
RESTORE DATABASE [WSS_Content] FROM DISK = N'E:\Temp\TFS\STS_Content_TFS_backup_200710201600.bak'
WITH FILE = 1, MOVE N'STS_Content_TFS' TO N'E:\Program Files\Sql\MSSQL.1\MSSQL\Data\WSS_Content.mdf',
MOVE N'STS_Content_TFS_log' TO N'F:\SqlLogs\WSS_Content_log.LDF', NOUNLOAD, REPLACE, STATS = 10
GO
- Change the connection string in %TFS%\Web Services\Services to have the name of the old data tier server name. The TFS admin tool for renaming expects this.
- Use the TfsAdminTool to execute the RenameDT function.
- Started getting errors saying that the tool could not connect to the database.
- Tried allowed named pipes, and changed the name of the database in the web.config file. Named pipes didn't work, and I got an error saying I need to use the old data tier name (as expected) with the new name in the web.config file.
- SQL Profiler showed that tfsAdminTool was not connecting.
- Event logs were clean
- Turned off windows firewall
- Tried renameDT localhost
- Using reflector to inspect TfsAdminUtil and related assemblies, it looks like it's trying to make a call to the old TFS server's Reporting Services web service so that it can update connection string info on the new service. The new TFS server does NOT have access to the old server so this obviously is not going to work.
- Using reflector, identify changes made during a RenameDT operation and make those changes manually
- Update connection strings in Reporting Services Data Sources. I'm going to wait until I am instructed to turn RS back on, then go in thru the web interface to upgrade the data sources. They are stored as binary data in the DB.
- Update the web.config file we changed above
- Grant login access to service account (which was done by the TFS setup on the new server before we even tried to rename the data tier)
- Update tables by calling stored procedure prc_update_database_servername, which I can't look at, but can manually execute by passing the old server name and new server name to. This is in the TfsIntegration database.
- When executing I got 1 row affected. I guess I could have ran sql profiler to see what it did. For sure, it update tbl_database.servername.
- TfsIntegration.dbo.tbl_subscription. Update address to http://datfsp100:8080/*
- Ran "tfsAdminTool ActivateAT newApplicationTierServerName" to "change" the name of the application tier to the new server name. This completed the first time without errors.
- I'm now up to the part that deals with user accounts for users and services. Since the new TFS server is on a completely different domain, all of the account names are different. This was one of the steps that worried me from the start. I'm not sure what I need to do to restore my server to an operational state. Adding a bunch of throw away accounts isn't appealing. I'm going to go back to Reflector to see what the TfsAdminUtil is doing for this step.
- It looks like it calls a stored procedure prc_security_update_sid, which I think updates tbl_security_identity_cache.
- I went ahead with the instructions. There was an error, but the instructions said this was to be expected.
- I didn't have a service account for reports, so I skipped that step.
- The step to remove and re-add the content database failed. This is possibly due to mis-matched schemas.
- Clean up Reporting Services
- Update DataSources
- Add tfsReports account to TfsWarehouse TfsWarehouseDataReader role.
Current Status
- TFS work items and source control are working, however all of the work items need their assigned user updated. While source control works, users and their machines that had connected to the old TFS Server, have conflicting workspaces.
- Reporting Services works, but none of the reports will run due to some type of login/permission error.
- SharePoint isn't doing so well, as the content database can not be restored.
Stay tuned for my follow up post.
Resources
|