My dry run attempt to restore a set of TFS databases failed because the admin console reports that Tfs_Configuration already exists and should be dropped before the restore:
TF400990: Database Tfs_Configuration exists on SQL instance
However, the admin console has an open connection to the Tfs_Configuration which prevents me from dropping the database. If I close the admin console, perform the drop, and try to re-launch the admin console it fails because it cannot find the Tfs_Configuration database. So I'm stuck.
I can work around by manually restoring the databases or using the tfsrestore.exe tool (but that won't include the logs -- just the full backup).
So how is restore supposed to work from the admin console? My scenario is total vanilla. Install TFS, backup, quiesce, restore... seems like that should work.
Duh. I had to uninstall the application tier first.
Related
After updating from TFS 2018 v3 to DevOps Server 2019.0.1 last weekend I now receive this authentication error when attempting to manage security:
TF30063: You are not authorized to access tfs.
I receive this error when attempting to manage security from the Server Administration Console via Application Tier > Administer Security. I also receive the error when I attempt to set permissions via tfssecurity cli tool. I am in the local administrator group and I am listed in the console administration user section.
I'm trying to set permissions because after the update I received several reports from employees that receive errors when they try to access their projects. Those errors are:
TF40049: You do not have licensing rights to access this feature: Code.
*** Edit: Update
This error reoccurred when I upgraded from 2019 to 2020 RC1. The difference is, this upgrade required a migration of the server- since server requirements changed for the new version of DevOps Server.
I spent 8 hrs working through this issue yesterday, and this is what fixed our problem:
deleted DevOps server cache. (location of cache listed in devops admin console on server)
reboot server.
I deleted the cache off the server based on an article I read with the same error, a user was having security/permissions issues with visual studio and they deleted the vs cache on their local machine and it solved their problem. I don't know if deleting the cache or the reboot would have fixed it independently because I did them both as a single troubleshooting step.
Hope this helps someone.
** Edit: Update 08/13/20 **
After upgrading again, I have ran into the same issue and this does not fix my error anymore. I've tried deleting the server cache, rebooting, reapplying permissions, configuring a new service account, reapplying changes, rebooting again, etc. I still have not found a solution for this error. I cannot schedule backups through the supplied backup scheduler without permissions to manage security settings through the configuration panel.
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.
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 have a production SQL Azure database. Is there a way to run Migrations against it remotely e.g via Powershell? I don't have access to my development machine at the moment, and through a browser inspection I realized the error below is returned:
There is already an object named 'AspNetRoles' in the database.
Normally, I would do:
Add-Migration Initial -IgnoreChanges then Update-Database
Note: I want to disable* or run migrations that are already deployed remotely, whichever will be faster. I'll appreciate any help on 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.