is there a (simple) way to move a single TeamProject from one server to another? Including source code, work items, documents, project site...
We don't want to move our server from one machine to another. Just a single project from server A to server B.
You have two options
You can use the TFS to TFS migration tool: Click Here. This doesn't include the WSS project site.
Or you can backup your TFS db and restore on a new TFS instance, then use the TFSDeleteProject.exe tool to remove the projects you don't want.
The latter option is the easiest, but will not merge the backed up projects with any existing projects on the target instance. Existing projects will be lost. WSS sites can also be moved in this manner as well. See How to: Back Up a Team Foundation Server
The TFS to TFS migration tool is obsolete. The features you are looking for is part of TFS Integration Platform.
Goto http://tfsintegration.codeplex.com/ for more info.
In TFS 2010 you can detach the Project Collection database using the TFS Admin Console and then re-attach it to another TFS Server.
http://msdn.microsoft.com/en-us/library/dd936138.aspx
If you want an entire Project Collection to be moved from one TFS server to another:
1) Detach the collection via Admin Console.
2) Backup the Tfs_SomethingCollection database using SSMS, then restore it to the other database server.
3) On the second TFS Admin Console, attach the project collection. It will show up as an available collection to attach just because it has been restored in the second sql server instance.
I did not migrate the Tfs_Configuration database. In my case I was not utilizing reporting services, build services, or sharepoint.
I hadn't installed the second TFS server and was wondering, what options to choose when installing, and if you should install it after or before restoring the migrated DB(it doesn't really matter): Install TFS on the second machine. If TFS and its database instance will be on seperate servers, then choose Advanced configuration and specify the name of the DB server instance. When you have an opportunity to create a DefaultCollection, then opt to skip that step. The install will create a new Tfs_Configuration DB on the new server. Then follow the above steps to migrate the collection DB to the new DB server instance and attach it.
Programmers will need to add the new server to Team Explorer, and hit Change Source Control... twice in a row for each solution. Make sure the local path mappings are correct, and then Bind each solution/project.
Related
My company is using a TFS 2013 (Update 4 = 12.0.31101.0) server for development. I was tasked with migrating the TFS server to VSTS but realized I had to update to TFS2018 to be able to use the current migration tool.
My boss obviously didn't like the idea of performing "open heart surgery" on our productive environment so we created a back-up of the SQL Collection-Database (by creating a dump using Management Studio) installed a Trial Version of TFS/SQL Server in a VM (VirtualBox) and tried importing the back-up.
Using the built-in import tool (TFS\Tools\TfsRestore.exe) I imported the old DB into the SQL Server, which actually worked really well, looking at the DB in ManagementStudio everything that needs to be there seems to be there.
However, trying to attach the Team Project Collection in the Team Foundation Server Administration Console I simply can't find it. I List Available Databases and the only one it finds is the DefaultCollection that was created during installation of the server.
I made sure that the versions are the exact same version, only difference is the License which is a real License on our production environment and a Dev License on the VM.
Anyone got an idea why this is happening? Maybe some way to get a more detailed Exception?
Edit: Trying to use the TfsConfig registerDB command throws an expection:
TFS30040: The database is not correctly configured. Contact your Team Foundation Server administrator
First, please make sure you are a member of the Team Foundation Administrators security group and a member of the sysadmin security group for any SQL Server databases that the new Team Foundation Server uses.
Usually this kind of issue should be solved after giving proper database permissions to the user.
Besides, after the configuration you can try RemapDBs to redirect TFS to its databases.
Back to the error: TF30040: The database is not correctly configured. Contact your Team Foundation Server. Here is a similar thread for your reference: TF30040: The database is not correctly configured
Moreover, you could also check the event view on your VM, if there are some more detail error message for troubleshooting.
Did you detach the collection in the TFS admin console before taking the backup on your 2013 server?
When you detach the collection is moves all of the relevant data from the TFS configuration database in to the collection database. You can then take a backup of the collection database and restore it to the new SQL server instance.
Note that detaching the collection will take it offline until the backup is complete and you re-attach the collection.
Then the new version of TFS should be able to see the collection and attach it. This will copy the configuration data to the new configuration database and you'll be able to bring the collection online.
So steps are
Detach collection in TFS 2013
Take backup of the TFS 2013 collection DB
Re-attach the TFS 2013 collection so that users can continue to use the collection whilst you test your upgrade
Copy the backup to the 2018 server
Restore the backup
In the TFS 2018 Admin console attach the collection
Once you're happy that the upgrade will go smoothly repeat the process but skip step 3.
Managed to do it by following this guide : https://cromwellhaus.com/2013/08/restoring-tfs-2012-to-sandbox/
Short Version: I was missing the config database, it was quite easy once I was using the old config.
I have 2 different tfs servers, on different machines. Both of them is not in any domain. Each of them has their own project collections and team projects.
What I wanna do is merge them on a new server. What I believe this is called consolidation.
I have been researching for this job, but documents I have found were a little uncomprehensive for me. But I planned a path afterall. Lets say I have servers A, B, and C. A and B are the old ones, and C will be the new one.
Server A: 2015.4
take full backup of the db via TFS administration console, to \\backups\tfsA
Server B: 2015.4
take full backup of the db via TFS administration console, to \\backups\tfsB
Server C:
install the TFS 2015.4 - do not configure
restore database via TFS administration console, from \\backups\tfsA
restore database via TFS administration console, from \\backups\tfsB
configure TFS
My question here is
"Would this path actually work?", restoration from 2 different paths seems a little scary to me, but can't be sure. Or;
Should I have the db backups on the same path like \\backups\tfsAB and run restore from that path?
After this process is completed, I need to make an environment migration too and have this new tfs work with an Active Directory, but that should be another question after I make this work I guess.
You cannot merge the two servers directly as you mention, as some of the configuration would be in the database for each server.
What you can do is move one Team Project Collection at a time, by detaching it from the old server (will copy needed configuration from the common configuration database into the collection database), make a backup of that particular Team Project Collection database, restore it on the new server and finally attaching it (will copy configuration back to the common configuration database).
You do need to think of the naming as the Team Project Collection needs to have a unique name on the new merged server. Renaming is done by changing the name upon restore.
Question is similar to this question.
We've lost our TFS and domain servers. TFS was configured to use domain accounts. We could resotre only the TFS Project Collection databases and thanks to the "TFSConfig repair" command, we finally attached them to a new TFS instance.
But all of the default security groups for repaired projects are lost (except the administrators). For example we don't have "Contributors" group anymore.
Now we want to restore these standard groups. Maybe it's possible to fix it by applying the default TFS "project proccess templates" on all existing projects and collections again.
Is there any way to address it?
As you lost the Domain server you have to follow the Move User and Service Accounts chapter of the "Move Team Foundation Server from One Environment to Another" procedure.
By the way, there's no such feature as reapplying a process template on an existing Team Project.
Have you tried to recreate at least one group that you lost? Only to know if that is working (maybe TFS will return an error because the group still exists in the database but it's not shown for whatever reason) ?
One last thing: check the TFS Scheduler Windows Service is running on the TFS Server and look for errors in the Windows Event Log.
Is there a way to backup just the source control component of a team project and restore it into a different TFS server? We setup a TFS 2010 server for RND, but decided to use it's source control manager for a development project. We did this so the developers can learn how to work with it before we use it on a much bigger project. Now, we need to blow away the server since it is a VM for RND. We're going to setup a new TFS server for production. I don't want to lose the source code history.
Yes, you can use the TFS Integration Tools to migrate source with history for one or more Team Projects to another server. It is very easy to use.
TFS Integration Tools Download
I hope this helps
Mike
Use the features built into the product. In Dev10, collections were added so artifacts (including source) would be portable between TFS servers - leverage that. Pilot projects were a key scenario for portable artifacts and a justification for collections.
Dettach the collection from the VM TFS instance. It's available from the collection node of the admin console.
Backup the database from the database you dettached.
Deploy the new real server (non-VM).
Restore that collection database to the sql server used for the production instance.
Using the administration console collections node, attach the collection to the newly deployed TFS server.
Now you have the source available from the prototype period and you have a new production collection available for the new production instance.
BTW, in Dev 11 (you can get build conference CTP or beta soon) TFS upgrades the collection on attach so if you deploy a Dev11 TFS server, you can attach that prototype collection and pull it forward.
I have recently moved our TFS 2010 server to new server, I'm trying to create a backup plan but TFS tells me that A backup plan already exists for this Tfs configuration.
How can I overwright the existing backup plan?
Any Ideas?
This is an intresting one. The tool has a feature to prevent multiple backup plans from being created for the same TFS databases (because they might interfere). It works by setting an extended attribute in the TFS Configuration SQL database (called TFS_BACKUP_PLAN_CONTROLLER) that identifies a configured backup plan. You can't configure another backup plan from a different machine. To do it, you will need to delete this extended attribute using SQL Server Management Studio.
You can use the following command to delete the attribute by,
Use Tfs_Configuration
EXEC sp_dropextendedproperty #name = 'TFS_BACKUP_PLAN_CONTROLLER'
HTH.
Cheers, Tarun