We have TFS server to be moved to a new Hardware please suggest the steps involved and the best approach.
The DB instance will also change will just Backing up and Restoring the Collection DBs be fine? and attaching these collections to the New TFS setup?
Thanks & Regards
Just as DaveShaw suggested in the comment, there are official tutorials in MSDN, you could simply follow the suggestion there. The steps are very clear and detail
Restore data to a different server than the current one for TFS
If you also want to do the version upgrade something you could pay attention such as :
Pre-production upgrade is just a dry run of your upgrade in a production environment.
Usually we use this to test your upgrade. This process test upgrades the databases. You can use this to simultaneously test your TFS on another hardware while continue to use your existing older TFS up.
Once you are ready for upgrade, restore the databases again and just use the Production Upgrade scenario during the server configuration wizard.
Besides, suggest you directly move the changes in the production environment later, a tutorial for In-place upgrade to for your reference.
Related
My company is considering upgrading our on prem TFS 2017 update 3 to the latest Azure DevOps Server (notably, the on prem variety).
During discussions about that possibility, one key stakeholder claimed that if you upgrade, all of your build and release pipelines would have to be rebuilt from scratch. We have a healthy number of build and release definitions in TFS 2017.
I have looked for the answer in the Microsoft documentation about what exactly gets upgraded, but unfortunately I can't get the level of granularity which would prove or disprove the above claim. On the surface it would seem like a horrible upgrade story if it were true. But I also understand that designs and architectures change and upgrades aren't always possible.
Could somebody let me know whether the build and release pipelines can survive the upgrade more or less unscathed? Knowing this would be a valuable data point as we work toward a decision.
Thanks in advance!
The vNext build definitions and the release pipeline I would expect would be pretty lift and shift. Depending on the tasks that you have defined, they might no longer be supported or there might be new versions. The UI will let you know that new versions are available.
A lot of the new focus is building out the features for the YAML build definitions. If you want to leverage those, you'd have to do a lot more rework of converting those vNext tasks into YAML. But converting is not really a hard requirement.
You mentioned that you aren't using the XAML build definitions, but if you happened to be using them, I would image that is where a lot of the rework comes in. Having done that in the past, I can say it is a pain if you have to do it.
all of your build and release pipelines would have to be rebuilt from scratch.
I've tested it and it won't lose any data after upgrading. We should use scheduled backups to ensure that we always have backups in place in case something goes wrong.
we can use that new hardware to do a dry run first, and then we will wipe everything clean and use it again for the production upgrade.
For our dry run, the steps for our upgrade will be:
Copy recent database backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use scheduled backups to restore the database backups.
Run through the upgrade wizard, being sure to use a service account which does not have any permissions in our production environment. See Protecting production in the dry run in pre-production document for more information.
Optionally configure new features which require changes to our existing projects.
The production upgrade steps will be quite similar. There the steps will be:
Take the production server offline using TFSServiceControl's quiesce command. The goal here is to ensure that the backups we use to move to our new hardware are complete and we don't lose any user data.
Take new backups of each database.
Copy the backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use the scheduled backups wizard to restore the database backups.
Run through the upgrade wizard, using our desired production service account.
Optionally configure new features which require changes to our existing projects.
You can refer to this doc for more details.
What would you recommend or what is the official recommendation of Microsoft regarding migration path after pre-production (test) upgrade?
is it to do an In-Place Upgrade? or is it to do a database migration to a new hardware? Need this information for one of my customers.
The second question is, let's say I choose the second approach and make a production upgrade moving the databases to new hard, do I have a rollback if something goes wrong? or the old environment becomes unusable once I make a production upgrade (remember I am using new hard/VMs)
Many thanks
Actually it's completely based on your requirements. If you want to use the old hardware then you can do In-Place upgrade, if your want to migrate to new hardware then just do the database migration.
In-Place upgrade:
Please note that you cannot simply rollback for In-Place upgrade if something goes wrong. So backup the databases first.
Expect the best, prepare for the worst.
While we put a lot of effort into ensuring that TFS upgrades are
highly reliable, it always makes sense to prepare for the case where
something goes wrong. The single most important step you can take here
is to ensure you have a complete and consistent set of database
backups.
If you're upgrading in place (not moving to new hardware), consider
doing a dry run of your upgrade in a pre-production
environment.
Source here: Upgrade TFS.
You can reference this article to do the upgrade:
In-place upgrade to TFS 2017 RTW (Release To Web) with Reporting and SharePoint
Migrate to new hardware:
Migration will be more flexible and safe, the old environment will still available, it will not be affected if the migration failed. So in my opinion if you have new hardware, then it should be better to do the migration.
Please see Move or Clone Team Foundation Server from one hardware to another for details.
Please note that whether it is in-place or migration, it must match the Requirements and compatibility first for each TFS version. And never forget to Backup the databases for both of them.
It appears a fair number of release management deployment tasks and templates are not in TFS 2015 on premise right now, and I'm trying to figure out if this is by design or if my installation has problems. For instance, I do not have a sql deployment task available to me. I haven't been able to find confirmation one way or the other, so does the on premise version just not have these tasks?
be aware that VSTS development is always some months ahead of on-premise TFS. Especially release management is quite new and many enhancments and tasks will probably find it's way to TFS. Either directly, as extension or you can create custom tasks by yourself.
As seen here:
https://github.com/Microsoft/vsts-tasks/issues/1674 it's a very young step and all you need to get it work on your local TFS is on github:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/SqlServerDacpacDeployment
This is by designed. It seems you are using some Extensions. You can find this in available extensions on the right top of the web portal.
Then you can find those tasks in below page and just need manually install the tasks.
DacPac deployments are part of the extention "IIS Web App Deployment Using WinRM"
https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.iiswebapp
Download and install it on your TFS server. You need to have Windows Remote Management enabled on your database servers for it to work.
I found this web site useful in getting it setup on the database server
http://www.hurryupandwait.io/blog/understanding-and-troubleshooting-winrm-connection-and-authentication-a-thrill-seekers-guide-to-adventure
I have backup of TFS databases and I want to get my code files from it. Is it possible? If so, then what exactly do I need to do? TFS Version: 11.0.61030.0 (Tfs2012.Update4)
Whatever investigation I have done so far, it seems that the only way to restore the files is to install TFS 2012 on another machine, restore the database backups on that machine. And hopefully afterwards I should be able to download the files from this new TFS. I wanted to verify my procedure because I need to know if there is something missing in my understanding before I start the task.
Yes restore is the way to go, but you must be careful at some important details. I write as I remember:
Use the same version of TFS for the new environment.
The new environment is in the same Active Directory domain. If you are in a workgroup, must add additional steps to make, at least some, accounts match.
Restore from a marked transaction (this is done by the built-in backup/restore tool)
You will have two live system with the same identifier: this may confuse clients. To avoid run the tfsconfig ChangeServerID command.
If you restore the Configuration DB, must run TfsConfig RegisterDB.
For getting code this is enough, but consider that the new environment is still pointing to existing resources: build server, lab management.
If the TFS instance was already used, more steps are necessaries, like cleaning cache on AT.
I do not remeber a complete guidance: there are many variations on this topic. Make sure to study the content of Restore a deployment to new hardware
I have installed and configured TFS 2010 on a Win 2008 server. I have tested the migration and everything seems o be working fine. I have one issue with the Domain move though.
I am trying to use TFSCONFIG IDENITIES /change command to map the Users in old domain to new domian, but unfortunately the new domain accounts have been added to the TFS group. Hence, I caanott use the Identities /change command.
I am still trying to figure out what needs to be done in order to sync up the accounts b/w two domains. What are my options in this situation? Can I just uninstall and re-install TFS 2010. Would that help me sync up the account names b/w two domains? Please advise
There is extensive guidance available on the different supported upgrade scenario's.
Probably the easiest way to do the upgrade is to install TFS2010 over the 2008 version and then do a domain migration. It looks like the issue you're facing is that you added the new account members, instead of migrated the old members to the new ones. I haven't been in that scenario before, you could try removing the new accounts and then migrating, or using the TFS integration tools to migrate all data for one user to another user.
If you still have a backup available, or if the TFS 2008 server is still there, I suggest re-doing the migration, however painful that may be, it will be the safest way to get everything to work again.
Finally there are the The TFS Integration Tools can be used to migrate from one TFS instance to another, they don't migrate everything, but will migrate the most important things.