Origin machine: TFS 2017 update 3 & SQL Server 2014
Destination machine: TFS 2018 update 2 & SQL Server 2017
Steps followed for a Dry-Run:
Followed the "Move or Clone Team Foundation Server from one hardware to another" and "Do a dry run of your upgrade". All databases are successfully restored on the same server (TFS_configuration, Tfs_collections, Tfs_Warehouse, ReportServer, ReportServerTempDB, Tfs_Analysis).
ChangeServerId and RemapDBs executed successfully.
When running the wizard to use the "Pre-production Upgrade Testing" we noticed the following:
When using "< nameofserver >\SSRS" (this is the default instance name for Reporting Services in SQL Server 2017) on "Reporting Services Instance" and the correct URLs are selected, these errors appear on the Readiness Checks:
It appears that the following best practices for this scenario have
not been implemented: VS403144: The warehouse database is currently pointing to the same database that was being used on your production deployment.
VS403140: The specified Analysis Services database is the same one being used in your production deployment.
When using "< nameofserver >" (this has been used in the past successfully with tfs2017) on "Reporting Services Instance" the following message pops up:
TF255186: The following SQL Server Reporting Services Instance could not be found: MSSQLSERVER. The server name is: "< nameoftheserver >"
Is the change of the instance name from "MSSQLSERVER" to "SSRS" causing this issue?
Thank you
This is most likely because you don't need to use ChangeServerID and ReMapDBs with the
Pre-production Upgrade Testing scenario. That scenario does those operations for you.
I'd reset the test instance, restore the databases, and try again without running changeserverID/remapDBs.
Related
Id like to confirm this with you.
We are upgrading our TFS 2017 environment to use SQL 2016 SP2 in preparation of the TFS 2018 upgrade.
Our SQL Team will do this using new hardware.
I currently already use DNS aliases in my connection strings to the databases.
Can you confirm this would be the steps in short?
Run TfsServiceControl quiesce
Migrate the database to the new server
Update the DNS Aliases to point to the new host
Run TfsServiceControl unquiesce
Should it be that simple ? or should i take other steps to ensure the application is aware of the SQL Upgrade ?
I was only able to find an old article about this subject
https://blogs.msdn.microsoft.com/tfssetup/2014/05/15/migrating-team-foundation-server-databases/
I am taking over the TFS 2015 a previous employee set up.
When trying to access the webapp I am getting an HTTP 500 error "The website is under maintenance".
When trying to open the Team Foundation Server Administration Console I am getting the "... TF246017: Team Foundation Server could not connect to the database..."
When looking at the SQL Server ERRORLOG I am seeing the "SQL Server evaluation period has expired."
It seems to me previous employee setup the trial version of TFS 2015.
How could I verify this is true and how can I upgrade the version to a purchased license?
Thanks
The root cause is "SQL Server evaluation period has expired."
You can try testing the SQL Server instance in TFS Administration Console (Generally the test connection should be failed if the SQL license expired) :
Select specific Collection --> Stop the collecion --> Edit Settings --> Test
To activate the SQL Server again, you need an edition upgrade for SQL Server . To upgrade, you need to have installation media of the destination version. SQL Server evaluation edition can be upgraded to standard, developer, enterprise editions.
Here are the steps:
From SQL Server installation media, launch setup.exe.
From the SQL Server Installation Center click Maintenance, and then
select Edition Upgrade
It would launch Wizard where you need to keep on pressing next, next
and finally “Upgrade”. Make sure that edition shown in the license
terms screen is what you purchased.
Please refer to SQL SERVER – Evaluation Period Has Expired – How to Activate SQL Server? for details.
When doing Application Tier only installation on TFS, I received the following error at the Configure section of the Application Tier Only Wizard.
TF255356: The following error occurred when configuring the Team Foundation databases: TF246083: The configuration of Team Foundation Server is not valid. You must remap the databases in order to fix the configuration. The following error was received from the server: TF400673: Unable to find any compatible SQL Analysis Services database within the specified instance.
'2' hosts have been given updated connection strings.
.. For more information, see the configuration log.
How do I resolve this error?
Image Link for Application Tier Only Wizard
This problem usually occurs when Move or Clone Team Foundation Server from one hardware to another.
Based on the error message, seems you have not restored the TFS_Analysis database or somthing wrong with the restored TFS_Analysis database.
So, you can try to restore the TFS_Analysis database, then check it again. If the issue still exists there, then you can refer to below thread and following the steps to fix that:
TFS Configuration
Cloning Your TFS Server Part 02 – Prepare Restored Databases
UPDATE:
You have to restore the TFS_Analysis database first, you can not configure the AT without the DB. Alternatively you can do a complete new installation and create a new TFS deployment. See Install TFS on a single server for details.
I'm doing both a hardware and a domain migration, as well as upgrading my TFS instance from 2015.3 to 2017.1. I first discussed this project (and received some VERY helpful suggestions) here.
Here’s the infrastructure I’ve got right now:
Hostname Operating System
SERVER1 Hyper-V Host 2012 r2
SERVER2 Server Essentials 2012 R2
SERVER3 Server 2012 R2 (TFS 2015.3)
DB Windows 10 (SQL 2014)
...and here’s what’s planned:
Hostname Operating System
SERVER1 Hyper-V Host 2016
SERVER2 Server Essentials 2016
SERVER3 Server 2016 (TFS 2017.1 & SQL 2016)
The old and new domains carry the same descriptive name (e.g. DOMAIN). For the purposes of this Q&A, henceforth I'll refer to any VM on the old domain with a leading underbar (e.g. _SERVER3).
My problem is that the guidance for the hardware migration doesn't indicate whether the TFS Restore action can be run on a machine with a different NETBIOS name than the name of the machine on which the backup was taken.
I've set up a temporary _SERVER4 for this project, which I will join to the new domain as SERVER4 as part of the domain migration, but I don't know whether this will work. _SERVER3 has a different machine/domain SID, of course, which may confuse TFS if I restore to _SERVER4.
I'll then build up a new, clean SERVER3 on the new domain and restore from the backup taken on SERVER4. Same issue.
Is this really a problem—restoring a backup to a different machine name, same domain—or am I being too cautious and simply imagining a problem where one doesn't exist?
OK, this can work.
I'm now running a restored TFS instance error-free on _SERVER4, from a backup that was taken on _DB. It didn't come without a few hitches, though:
TFS backup/restore doesn't touch the Analysis Services database, so we have to manage that manually
RS configuration by default requires a secure connection, a requirement which must be disabled:
In Windows Explorer, locate the ReportServer directory. The following path is the default path of this directory: C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer
Right-click RSReportServer.config, click Open With, click Notepad and then click OK.
Locate the following Add Key entry: <Add Key="SecureConnectionLevel" Value="2"/>
Change the Value setting from 2 to 0
When the database server name changes as well, we must perform a bit of a hack:
DELETE FROM [ReportServer].[dbo].[Keys] WHERE MachineName = 'YourSourceServerName'
None of these requires an OS or service restart. Just apply the changes and try again.
As #jessehouwing indicates, there are some stops along the way in the Configuration Wizard where we have to update the server name. But all in all, other than the few little bumps listed above, the process went pretty smoothly. (And frequent checkpoints were absolutely vital to this success.)
Now for the domain migration... extra thanks to Jesse for all of his help with this.
We have had an automatic Active Directory/Windows password change thrust upon us, and consequently our TFS2008 build server has broken. I have changed the password for the TFSERVICE account it runs under, and updated the Visual Studio Team Foundation Task Scheduler Service to use the correct password, and checked that the underlying Sql Server is running okay. However attempts to connect to TFS are now met with the message '..HTO Status 503: Service unavailable'.
What else needs to be started to get this up and running again?
You need to always change the password using the tools in the box. You can use the TFS Administration Console that you can launch from the start menu. Or you can use the tfsconfig.exe located in the TFS install folder.
This applies to all versions of TFS from 2010 on.
If you have TFS 2008/2005 you will need to use the tfsadminutil command: http://msdn.microsoft.com/en-us/library/bb552178(v=vs.90).aspx
Note: You need to upgrade your TFS server as soon as possible. Both the OS, SQL, and TFS pre-2010 is not well supported.