I had restore TFS database 2015(SQL 2014) to 2018(SQL 2017) successfully. and remapped it. But I got this error when I try to login to TFS
TF401054: The requested service level property TFS_SERVICE_LEVEL did
not match the expected value. Team Foundation Server requires the
Dev16.M122.7 service level but the database currently implements
Dev14.M113.
I hope you have backups of your databases in a known good state; your best bet is going to be to bring back up a working TFS 2015 instance and then follow modern upgrade documentation.
The basic problem is that your team project collection databases have to be upgraded. Pointing TFS 2017 to TFS 2015 project collection databases without putting those databases through the normal process of attaching them (and thus upgrading them) isn't going to work. In a migration-based scenario, this is typically accomplished via the TFS admin console.
You may be able to go to the admin console and attach the databases, but my recommendation would be to bring up a working instance of your TFS 2015 environment and start from scratch.
Related
I'm trying to upgrade my TFS2017 Update 3 environment, to a new Azure DevOps Server (on-premise) environment.
I've created a new server for Azure DevOps Server, as I'd like a newer version of Windows Server, and in general just want a completely fresh environment. I took backups of my databases, shut down the old TFS2017, without deleting anything.
I migrated the databases to a new SQL Server instance (where I have all my other databases), as I see no need to use an SQL Server license just for source control.
Now comes the fun part. I tried to configure Azure DevOps Server to use the existing database (after the migration to the new SQL server instance was done). I had some issues with the TfsJobAgent service, but got those resolved.
I then tried to reconfigure Azure DevOps Server (as it failed the first time), but during configuration, it now tells me that data is corrupt, and that the existing database cannot be used. Good thing that I took backups :)
It should be said, that the new SQL server instance is a 2019 version, so that shouldn't be a problem.
I'm not quite sure what is happening here, and why it's giving me this error. Am I migrating in a wrong way? There's not much documentation out there describing this flow.
Please go through the documentation below before upgrade:
https://learn.microsoft.com/en-us/azure/devops/server/upgrade/get-started?view=azure-devops
And follow the steps in article Upgrade scenario walkthrough for Team Foundation Server to upgrade your TFS. Summarize the steps here:
Prepare your environment. The first step is to check the system requirements for TFS 2018. Upgrade SQL Server is
necessary for your scenario. Including SQL Server, you also need to check other system
requirements and prepare the environment.
Expect the best, prepare for the worst. You must have a complete and consistent set of database backups in case something
goes wrong.
Do the upgrade. Once the preparation is done, you'll need to install the new version of TFS to get new binaries, and then run
through the upgrade wizard to upgrade your databases.
Configure new features. Depending on what version you upgraded from, you may need to configure each team project to gain access
to some of the new features made available.
I am carrying out a dry-run of an imminent TFS 2010 migration upgrade to TFS 2013.5 on a dedicated Windows Server 2012 R2 Datacenter host, following the steps in [this YouTube tutorial] (https://www.youtube.com/watch?v=nm-WOLc-GQQ) by Mohamed Radwan.
The intention is to keep the newly-implemented TFS 2013 running simultaneously with the TFS 2010 instance for a few days while we validate the migration upgrade. Once satisfied all's gone well, we'll then complete a full switch to the TFS 2013 instance and decommission the TFS 2010 instance which is implemented on a Windows Server 2008 R2 Enterprise.
The tutorial recommends using the TFSConfig Backup and Restore utilities to backup the existing TFS 2010 databases and reporting services key and then restoring them to my SQL Server 2014 instance on the TFS 2013 host.
Following the database and reporting key restore which has also completed successfully, I sought to adhere to the TFS cloning recommendation advised by various sources including Microsoft Support, by running in the following order, these TFSConfig commands:
TFSConfig PrepareClone
TFSConfig ChangeServerID
TFSConfig RemapDB
Problem is, when I attempt running the PrepareClone command, I keep getting the TF30040 error message (as per this thread's subject title). On the few times that I've proceeded regardless and run the ChangeServerID and RemapDB commands however, they complete successfully.
I desperately need some help resolving this TF30040 error, as all attempts to apply some of the resolution steps proposed in other related incidents have failed miserably. It's important I find a resolution due to the fact we're intending to run the two instances for a few days while verifying and validating the TFS 2013 upgrade.
Another key question I have is whether it is mandatory that I successfully execute the TFS PrepareClone command, despite the fact I'm successful executing the ServerID and RemapDB commands? In other words, is it safe to ignore the PrepareClone failure and proceed with the simultaneous running of both TFS 2010 and TFS 2013 instances for those 2-3 days of validation testing?
If you don't run PrepareClone command, the original resources will be used by both the original and the new servers. If both the original and the new servers are live and point to the same SharePoint or reporting resources for any amount of time, you could end up with corrupted databases.
You may keep one server live at the same time. Or try to use a new service account that has no access to production environment to run the command:
TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:DatabaseName /notificationURL: ApplicationTierURL
I have a working TFS 2012 installation. It runs SQL Server 2008R2 and whatever version of SharePoint that comes with TFS 2012.
I would like to migrate to one of: TFS 2013 or (preferably) TFS 2015 RC. I would prefer TFS 2015 RC unless there is either a bad hurdle to migration or it is not yet safe to use by a real development team, in which case I would opt for TFS 2013.
I also need to either migrate the current VM that hosts TFS 2012 or (preferably) create a new VM to host TFS 2013/2015 RC. The current VM lives on an ESXi server that is in our office. I would like to move it to our production environment, preferably by creating a new VM and doing the necessary steps to restore the TFS database.
Finally, I would like to change the database TFS points to from itself to a more stable database server that is already in production. Its database server is 2008 R2 and I'd like to move it to our SQL Server 2012 instance.
Needless to say there are a lot of moving parts involved here, so what I'd like to know is the safest order of operations to achieve my goals, ie:
Is it a bad idea to use TFS 2015 RC?
Should I run the in-place upgrade and then clone the VM to new environment?
Should I start by backup/restore to the new database server and changing where the current TFS 2012 instance points to?
Any guidance is appreciated.
You should move to new hardware as part of the move. Setup a new box with the buys that you want, TFS 2015 (unconfigured), SQL 2014, and SharePoint 2013.
Then restore all of your old server backups to the new server. The upgrade wizard takes care of almost everything. The final part I is only for a trial run. You want clients to think that the trial is a new server so the don't follow the upgrade procedure prematurely. So once you have TFS up and running you need to call "tfsconfig setup unconfigure:all" and then run "tfssetup changeserverid" before reconfiguring as app tier only.
SharePoint is fairly easy if you follow the docs. You cant upgrade a SharePoint instance bit you can import your old site collection.
Related : Visual Studio 2013 (Professional Edition)
I am trying to create Data Migration Script to deploy the changes on Staging Server.
This works locally fine. But When I try to run the generated Script on Azure Database, I get TextPtr is not supported on Azure platform. I studied more about it & found that the newer editions of SQL Server (sply for Windows Azure (SQL 2014 may be)) has dropped some keywords/functionalities the list can be found here.
The Sql Database Project only provides the Schema Compare, but Data Compare is avilables in tools Section (where we can not set Target Project Type property).
I wonder how can I deploy/Migrate the changes made in one environment to another in such a Situation. Currently I had to overwrite the existing Database on Azure platform.
But this is not Identical also, for first time this could work but not for later, as there could be some changes made to the Staging or other environments.
I had a similar problem, when trying to migrate between a test and staging environment in Azure. As a quick fix, I got around the problem by just doing a "copy" of the dev database via the Azure dashboard.
We have just created a new Windows Server 2012 with TFS 2012 using a SQL Server 2012 db. I need to migrate the code with history from a TFS 2010 using SQL Server 2008 RS to this new server. Any suggestions?
I went down this road recently. You basically have two options:
Migrate
Upgrade
Migration
I started going down the Migration route and downloaded the TFS Integration. In short, this ended badly. I spent a total of 2 weeks running the migration and eventually gave up. The tool said that it was going to take over a month to complete the migration.
Eventually I gave up and instead tried the Upgrade route.
NB. I want to point out that whilst I had issues, I'm sure there are many people have used this tool successfully. I am only speaking from my own experience
Upgrade
You are in the same position as I was, namely you already have a new server ready to go. All you need to do to upgrade is as follows (This is not a full guide, there is a link below to a complete guide for this process.):
Open Team Foundation Administration Console on the 2010 server
Click Team Project Collections
On the General tab, select Detach Team Project Collection - a wizard opens
Follow the wizard and detach the collection.
Once detached, backup the Collection Database
If TFS 2012 is already installed then simply restore the database into the new TFS 2012 instance. If not, you need to prep the new SQL Server using TFSConfig PrepSQL.
Restore the backup into the SQL 2012 instance
Attach the collection in the Team Foundation Administration Console on TFS 2012.
The Detach and Attach processes are important as they prep TFS for the transfer process and actually perform upgrades on the database
This is not a full guide, this is just a set of pointers. I strongly recommend you read this page fully before performing any steps. http://msdn.microsoft.com/en-us/library/dd936138(v=vs.100).aspx#Backup
I figured it out!
I used this series to do the install of TFS and the migration:
http://mohamedradwan.wordpress.com/2013/01/05/upgrade-tfs-2010-to-tfs-2012-with-migration-to-a-new-hardware-series/
Answers to my comments below:
When you go to your Team Project Collections you can actually use the ChangeUrl function to reset it to what it should be. It is common that it will come up with the wrong url when doing a restore from another server. I took screen shots of the process and should have paid closer attention to the warnings that were at the finish.
As far as my second question, apparently VS keeps a config file that has the mapping settings which contains the credentials. I tried to remove and save, but for some reason this didn't work. I mapped it to a new folder, and it worked without issue.