When moving TFS from one machine to another by restoring it to new hardware (restoration-based move), the name of the old machine gets listed under the Application Tiers tab and is visible if the "Filter out machines that have not connected in more than 3 days" checkbox is unchecked.
To upgrade hardware and TFS version in one move:
Is it necessary to always keep the same machine name?
Does TFS support machine name change during restoration-based moves? (this will be in the case that we have Machine A and Machine B. Machine A is the old production tier and Machine B is the new one, where the databases will be moved and upgraded.)
Does the name machine change have any effect if TFS has an alias name for the public URL?
Thank you
First, you should confirm one thing, do you need to use the original hardware and TFS deployment or not.
You perform a move when you plan to discontinue use of the original hardware and TFS deployment. You perform a clone when you intend to continue using the original TFS instance.
Please take a look at Move or Clone Team Foundation Server from one hardware to another
If you just restored an application-tier server, for restoring an application-tier server, the name of the old application-tier server remains there is expected (See the end of this article.).
Note: The name of the old application-tier server will still appear in
the list of application-tier servers in the administration console for
Team Foundation. If you select the Filter out machines that have not
connected in more than 3 days check box, the old server will disappear
from the list within three days.
So, to avoid showing the old App Tier machine name you need to follow the steps in above tutorial-- Move or Clone Team Foundation Server from one hardware to another.
Moreover: You must install but not configure TFS on the new data-tier
server, and then use the restore function in the Scheduled Backups
node
Related
we have a TFS server configured on a machine. Now the organization has moved the complete VM to their other location with a new IP assigned to that VM. It's a clone of that old VM and after its migration, we also pushed some code the old running TFS.
Now the query is that how can we configure Visual studio to point to the new server and how can we effectively push the new code committed on the old server meanwhile the migration was underway.
If we have the latest code on say, a certain machine, can we just add a new connection , remove the old one and check for any changes visual studio shows to be pushed to the new server ?
our concern is only the code repository and nothing else (tasks, bugs etc.)
any help appreciated
When a TFS server is cloned, you should be able to update the connection to use the new URL. Existing workspaces will automatically be remapped.
There is no easy way to push the missing checkins from one serves to another. Especially when they share the same server identity (since the Client object model assumes it's the same serves, in the same state and keeps swapping over the workspace state and caches).
You can create a single new checkin with the new state though.
Make sure you are connected to the new server. (Turn off old server if possible).
Create a workspace matching the one you have locally. Make sure it's of the "Local Workspace" variety
Get latest version
Delete all the local files, but keep the $tf folder.
Paste the most up-to-date copy of the code into your new workspace
Resolve any renamed files from within Team Explorer.
Check in your changes.
We had moved everything from TFS sever to VSTS include database, logs. Not sure if we will use it again in the feature.
For now, we have two choices: uninstall the complete application/delete database entirely and simply unconfigure TFS
What are the differences between them? I want to choose the appropriate one.
To "Unconfigure TFS", please go to the Team Foundation Administration Console on the Application Tier machine. Click on the server name and click on "Remove Feature"
By Removing the feature, we will be removing
The Application Tier configuration from the server (but we don't
remove the binaries)
Connection with Data tier (but the databases won’t be deleted)
TFS Website.
TFS Application Pools
TFS Services (The Visual Studio Team Foundation Server Job Agent)
You can do the same from command prompt, execute TfsConfig setup /uninstall:ApplicationTier command to unconfigure TFS Application Tier. (You can also use various switches to remove other features SharePointExtensions, TeamBuild and VersionControlP
roxy) from server machine.
Usually we'd like to refresh the TFS Application Tier setup to defaults in case there's an unintended change in services/IIS settings and we want to set it back to defaults. We give an option to Remove Application Tier/Features without having to uninstall the complete application.
Another usage is when you are using pre-upgrade for test, you could quickly remove Application Tier. Since everything have been migrated, if you don't need the TFS server any more, just simply uninstall the complete application and database.You could back up your database, once you want to use again. Just install a new application and restore your database.
I have seen that, there are resources available to migrate complete content from TFS to VSTS. However, i have not seen any good thread talks about the possibilities of getting it done between one TFS instance (2017) to another of same instance (again TFS 2017) hosted in different server?
First, you should confirm one thing, do you need to use the original hardware and TFS deployment or not.
You could perform a move when you plan to discontinue use of the original hardware and TFS deployment. You could also perform a clone when you intend to continue using the original TFS instance.
Please take a look at Move or Clone Team Foundation Server from one hardware to another
Note: If you want to do a colne option, you need to reconfigure server IDs and remap databases.
I wish to upgrade my current TFS 2015.3 instance to 2017. It's not going to be quite as easy as advertised, however, due to some complicating factors. My scenario appears to be undocumented.
I'll be installing a new domain controller (moving from Server Essentials 2012 R2 to Server Essentials 2016).
The current OS is Server 2012 R2; I will be upgrading this as well, to Server 2016 (a clean install to a new VM).
Both of these new VMs must retain the same NETBIOS names as before.
The current SQL Server instance is 2014; I will be upgrading this as well, to SQL Server 2016.
The SQL Server instance for the current TFS instance is on a separate VM. I would like to consolidate this and put everything on a single VM. (I'm a solo developer putting a very light load on my server and I want to shed the extra complexity and overhead.)
Is it merely a matter of installing TFS 2017 and restoring from a 2015.3-generated backup? Will 2017 automatically apply any schema changes etc. during the restore process? Could it be that simple?
The closest question I could find to this is here, but unfortunately it doesn't quite address my situation.
Instead of doing a detach/attach upgrade there is another option available to you. detach/attach upgrades have had issues in the past and though most of these issues have been fixed, it's considered a suboptimal solution.
Instead, perform an Upgrade Installation.
Take a full backup of all your TFS 2015u3 databases and restore them to the new SQL server instance. You can create the full backup using the Team Foundation Server Admin Console, or use SQL Server Management Studio after stopping all TFS services on each Application Tier (in your case there is probably only one) using
TFSServiceControl quiesce
Now install TFS 2017 and perform the "upgrade" installation and point it to your existing databases. It will ask you if you want to upgrade them and whether you have a valid backup.
And after some time (upgrades can take a while, as data is moved around the databases), your TFS server will come back online. The installation wizard usually does all the mapping work required.
There is one big caveat, and that has to do with domain changes. If you are
installing in the same Windows Active Directory domain, you're good. But if your server is running in Workgroup mode you may want to remap all the identities in your TFS database prior to running the upgrade step. So install TFS, but do not configure yet. Run the following command
TFSConfig Identities /change /fromdomain:Domain1 /todomain:Domain2
Then use the upgrade option to have TFS use your database backups. The full explanation on doing a cross domain server migration is documented on MSDN. Be sure to safeguard your pre-upgrade backup until you've verified a successful upgrade.
We face almost the same thing, as our server was created for TFS 2013 and therefore has SQL 2012 installed.
Yes, it actually is as easy as your question states. When you attach the collection that you restored form the backup all the schema changes will be applied. Before then you configure the app tier of TFS and skip
An important thing though is to detach the collection before doing the backup. This copies various configuration into the collection database so that it is self-contained and can be moved to another server. You then only move the collection database to the new server.
Here is how in list form:
Detach collection using TFS Admin Console
Backup collection database using SSMS, e.g. Tfs_YourCollection
Restore collection database on new server using SSMS
Install TFS
Configure app tier, skip creation of new DefaultCollection
Attach collection in the TFS Admin Console, might take some time depending on your collection size.
You can do 4+5 before 3.
Note: Changing domain can add complexity. SharePoint and Reporting sites are not migrated!
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.