I setup a 3 tier TFS preprod environment that includes: an application server, a build server and one database server (SQL Server 2016).
I restored SQL Server databases from the production environment to the preprod environment, installed TFS 2017 on the app server, attached the database and tested successfully.
I then upgraded TFS 2017 to TFS2018 and tested successfully. I restored the databases from SQL Server 2016 to SQL Server 2017, updated compatibility mode on the databases to SQL Server 2017, stopped the collection in preprod environment, edited settings to point to the new SQL Server 2017 instance, clicked Test (which was successful), saved, clicked Start Collection and got an error
TF400787: The host 'DefaultCollection' cannot be started. The servicing needs to be scheduled and completed before the host can be started.
The TFS account I'm using to run TFS Admin Console is a sysadmin on all databases: TFS_Configuration, TFS_DefaultCollection and TFS_Warehouse.
How can I resolve this error and attach "DefaultCollection?"
How can I resolve this error and attach "DefaultCollection?"
The cause of this problem seems to be the loss of data in the database.
Generally, there will be backup database when using tfs or before tfs upgrade. You could use the backup of the databases to restore the database.
Here are the steps to re-configure the TFS:
Step1: Unconfigure the TFSfeature. You could use the "Remove feature" option in Administration console to remove feature or use the TfsConfig setup / uninstall：All
Step2: Restore the database from the backup.
Step3: Configure the TFS again in Administration Console.
In addition, you could go to TFS Administration Console -> the target collection -> Status tab. Then you could find the job that is failed, try to click the Rerun Job button and check the result.
Here is the ticket with a similar issue, you can refer to it
Related
I need to migrate a TFS 2013 instance to Azure DevOps Server 2019. I want to setup a new instance of Azure DevOps server with all the data migrated over from TFS 2013 and both the instances up and running at the same time. The plan is to decommission the TFS 2013 instance after a few weeks.
For testing purposes, I followed the steps below:
1. Setup a server in a completly isolated network.
2. Backed up the TFS 2013 databases using the scheduled backups from TFS admin console.
3. Restored the databases to a new instance of SQL Server 2017.
4. Started installation of Azure DevOps Server 2019 on the new server, I pointed it to the restored databases and it detected the schema and gave me two options: Production Upgrade and Pre-production upgrade testing. I chose the latter option.
The installation wizard took care of remapping the db connection strings(tfsconfig remapdbs), changing server and collection ids(tfsconfig changeserverid) and removed the scheduled backup jobs to avoid conflicts with the existing TFS 2013 instance.
The test migration completed successfully. Now, I want to setup the production instance on new servers that are within the same network as the existing TFS 2013 instance.
Shall I select "pre-production upgrade testing" again as I need to have both TFS 2013 and 2019 running at the same time?
Or Shall I select "Production Upgrade" this time? Is there anything I need to take care of during the upgrade so that the two instance don't conflict with each other?
PS: there are no backup jobs running on the TFS 2013 instance.
I tried the "Production upgrade" and understood that it will perform an in-place upgrade. In my scenario, I wanted to setup a separate new instance and the "Pre-Production Upgrade Testing" is the appropriate choice in this case as it automatically takes care of the remapping of database connection string and change server and collection identifiers.
We have TFS 2017.2 in 'Prod' and now I have to clone it on new PC to take some tests and so on.
I did DB backups with the help of TFS Scheduled Backup tool (Configuration DB, Collection, Warehouse, ReportServer, and ReportSerfer_tempDB), installed TFS 2017.2 on new PC, restore DBs.
After it I start TFSConfig ChangeServerID /SQLInstance:spbtfs01fortest /DatabaseName:Tfs_Configuration' and 'TFSConfig RemapDBs /DatabaseName:spbtfs01fortest;TFS_Configuration /SQLInstances:spbtfs01fortest and start the Server Configuration Wizard, filled in all and got this:
What wrong with it?
You have to run tfsconfig remapdbs for the analysis services database (with /AnalysisInstance), and for the warehouse database as well for the collection and configuration databases.
We have created a VM clone of our TFS server (but haven't turned on networking yet for the clone).
We have created a test SQL server that we plan on using for the test upgrade.
I'm not sure what we should do first (after populating the tfs databases on the test SQL server).
Since our test TFS server is a VM clone, TFS is installed and configured already. The Cloned TFS server is pointing to our production SQL server. Are the following steps correct:
Turn on networking for the Cloned TFS server
Remote into the Cloned TFS server
Run command TFSServiceControl quiesce
Run the command TFSConfig PrepareClone
Run the command TFSConfig ChangeServer ID
Run the command TFSConfig RemapDBS
Update the TFS URLS in the admin console
Edit Reporting to point to the new test Reporting instance
Update all service accounts
Are the steps correct? I am not sure which order to carry out the steps out after the TFS databases have been put on the test SQL server. Any help would be greatly appreciated.
I would suggest doing the following:
Unconfigure your test server. I assume you don't want to upgrade your production server yet, you just want to test the upgrade, correct? If that's the case run 'TfsConfig.exe setup /Uninstall:All' to unconfigure the new server.
(if you haven't done it already) Backup all TFS databases from production server. You'll need all DBs with the names starting with 'Tfs_' including Tfs_Configuration, Tfs_Warehouse and all collection databases.
Restore TFS backups from production on VM or some other test SQL server (using SQL server management studio)
Run tfsconfig changeserverid command (on the new server) to change the TFS server id. It's required because you want to have both TFS instances live for some time. If you don't do it, VS clients will think that it's the same server (even though the name is different) and this can cause some issues.
Run tfsconfig remapdbs command (on the new server) which will fix the old Tfs_Configuration database. This is only required because you are moving TFS to a different machine (with a different name)
Now you can start TFS management console and perform the actual upgrade which is pretty straightforward. Upgrade wizard will ask you for the new service account names and new test reporting instance location.
I plan on replacing my existing app tier (TFS 2010) when upgrading to TFS 2013. I'll quiesce the services and rename the old machine from MYTFS to MYTFS_OLD. The new app tier will have a fresh, un-configured installation of TFS 2013 and will be renamed from MYTFS_NEW to MYTFS.
My question is, will it be necessary to run the ChangeServerID or RemapDB commands if the new app tier is named the same as the old one?
If I understand your scenario correctly you will end up with:
A new server that's completely clean
The 'old' database server that contains all the TFS databases.
If that's the case, you should install TFS and select 'Upgrade'. You then point your TFS Application Tier to your database server and let TFS upgrade your databases.
You cannot have both version running on the same set of databases.
Study the ALM Ranger's Upgrade guide before doing anything.
I don't think you need to run remapdbs or changeserverid commands:
you typically need remapdbs when the server name changes which is not the case
you should use changeserverid if you plan to clone a TFS server meaning that you have restored TFS databases to a different machine and set up another TFS instance on that machine without killing the original server. Again it's not the case from what you have described here.
2 days ago I did the following test upgrade from TFS 2005 to 2010 then to 2012 (I am not configuring Reporting or Sharepoint)
Backed up the 6 TFs 2005 databases
Restored them on the Sql 2008 server used by TFS 2010
Ran TFSconfig setup uninstall:ALL on the TFS 2010 application server (as I had a test site setup)
Opened the TFS 2010 admin window and did an upgrade
Detached my TFS2010 collection and did an import process to TFS2012
Yesterday, I wanted to try the process again to make sure that I had all the steps down.
So I did some initial cleanup
Deleted all the databases on the TFS 2010 Sql server
Detached the test collection on TFS 2012 and then delete the associated database
and then I restarted the steps but it gets stuck at step #4
Backed up the 6 TFs 2005 databases
Restored them on the Sql 2008 server used by TFS 2010
Ran TFSconfig setup uninstall:ALL on the TFS 2010 application server
Opened the TFS 2010 admin window and did an upgrade
The error I get on step #4 is
TF254024: No database for Team Foundation Serer that can be upgraded were found on the following instance... Verify that you specified the correct name of the server and the instance.
I've double checked the name of the server & instance.
Made sure that the account that is running the upgrade has full permissions.
I'm not sure what else to do. My searching hasn't proved that fruitful.
I figured out the issue.
When I was testing out the deploy the first time, we were trying to do a migration instead of an upgrade. We had added 2 extended properties to the master table from the TFSIntegration database (based on another error).
I removed both those extended properties and I was able to start the upgrade.
edit 1-
I tried the process again (restore database and try to do the upgrade). The extented properties were back again.
so running this script fixed the process.
USE TfsIntegration;
GO
EXEC sp_dropextendedproperty
#name = N'TFS_DATABASE_CATEGORIES';
GO
EXEC sp_dropextendedproperty
#name = N'TFS_INSTANCE';
GO