I want to upgrade a SQL Server 2016 to 2019 by performing an in-place upgrade and also upgrade SSRS.
Microsoft documentation instructs me to migrate the SSRS databases.
To upgrade from Reporting Services 2016 and older versions to Reporting Services 2017 and later, follow the Migrate a Reporting Services Installation (Native Mode) article, with Reporting Services 2017 or later as your destination instance.
Is a migration necessary? If so, does that mean I should do a side-by-side upgrade of the SQL Server engine? I hoped that I could:
Clone the entire server as a backup. Run the Database server upgrade
(in-place).
Run the SSRS 2019 standalone installer.
Restore the SSRS encryption keys.
Configure SSRS to use the existing (and newly upgraded) databases.
I don't understand why I would need to follow the migration procedure? Is it just that in-place database engine upgrades are not recommended? I have some dependencies that make me reluctant to create a new server or install 2019 next to 2016.
No, the migration was not necessary. Yes, the in-place SQL Server upgrade worked.
We uninstalled SSRS 2016 and then performed the SQL Server upgrade
to 2019.
Then we installed SSRS 2019 (a separate installer, apart from SQL Server).
We restored the SSRS encryption keys. Here, we ran into an issue.
Unexpected error: This edition of reporting services doesn't support
scale out, but the database has other servers registered. We'll need
to remove those to continue. Do you want to remove the other
registered servers?
I was able to find a solution here and here. I had to delete the 2016 SSRS instance from the table dbo.keys.
The last step was to complete the SSRS configuration, and SSRS was
available.
Configuration included pointing SSRS at the existing 2016 databases
(reportserver and reportservertempdb) by selecting Change Database and choose an existing database.
The database upgrade did not change the compatibility level of the two databases.
Related
I have both test and production enviroments with a TFS 2017 update 1 on premises running in a windows server 2012 virtual machine. In the same virtual machine is running SQL Server 2014 as TFS database. I used this configuration for 3 years without problems.
Now I want to upgrade to Azure DevOps Server 2019 update 1.1 on premises. Furthermore I want to change architecture with two virtual machines with windows server 2016: one for database tier with SQL Server 2016 and one for application tier with Azure DevOps Server 2019 update 1.1.
What is the best practice to perform upgrade above described. Maybe the correct way is to leave the original single virtual machine with TFS 2017, prepare two new virtual machine both with windows server 2016 (one for SQL Server 2016 and other for DevOps 2019) and finally perform a "move project collection" from SQL Server 2014 to SQL Server 2016. Does the move project collection works even if the source comes from TFS 2017 and the destination is Dev 2019?
Is there any official documentation provided by Microsoft about the scenario of upgrade described above?
think best approach is to setup the new VM´s (with TFS2017 and stuff), then create DB dumps of old one and integrate these in the "new" TFS2017. After i would recommend to update to TFS2018, then 2019 (AzDo Server).
Why? => In most updates there were also done some updates in TFS Warehouse DB´s and stuff.
In the past we also updated from e.g. 2015 to 2017 but had better feeling doing the updates "piece by piece" to be sure that all the Warehouse changes were done "in a clean way".
This question already has answers here:
TFS 2010 Upgrade to TFS 2013 - Can Window Server 2019 Standard Support the Upgrade?
(3 answers)
Closed 2 years ago.
I have a client requirement to upgrade the existing TFS (Azure DevOps Server) 2010 instance as follows:
Upgrade TFS 2010 to TFS 2013
Upgrade TFS 2013 to TFS 2019
Migrate TFS 2019 to Azure DevOps Services (using the Data Migration Tool)
The immediate focus for now is only on the first upgrade and so the final two migrations can be ignored for now.
Our entire TFS implementation (application and data tiers) is hosted on a single server - Windows Server 2008 R2 Enterprise. This server also runs a SQL Server 2008 R2 instance for the TFS databases.
For the TFS 2010 to TFS 2013 upgrade, we intend to use the following hardware:
A separate dedicated server for the application tier - Windows Server 2012 (Enterprise I guess)
A separate, dedicated server for the data tier - SQL Server 2012 or 2014
As this is going to be a Migration-Upgrade as opposed to an In-Place upgrade, is there a reliable or good set of instructions and/or document that I could refer to get me over the line successfully for this activity?
The general process for upgrading an existing deployment of Team Foundation Server is to:
Prepare your environment. Such as upgrade your SQL sever (required),
operating system...
Expect the best, prepare for the worst. The single most important
step you can take here is to ensure you have a complete and
consistent set of database backups. Note:Detach collection before your back up
Do the upgrade! Restore SQL database from #2 Attach collection
Configure new features.
For a more detail progress, you could take a look at our official tutorial here-- Upgrade from TFS 2005 to TFS 2015 Same for TFS2010~ TFS2013.
Besides, since you have used different hardware during the upgrade, you could also pay attention to the notice in this doc-- TFS Application Tier will use different hardware than it’s using right now
Here is how I would do it,
You need to upgrade from TFS 2010 to TFS 2013 first then to Azure DevOps Server 2019 and finally to the cloud with the migration tool.
In order to migrate to TFS 2013, you need a minimum of Windows Server 2012 and SQL 2014. You first detach the TFS 2010 collection and take a backup of your 2010 db. You need to migration from SQL Standard to SQL Standard but you can go from 2008 to 2014. You can also go from Enterprise to Standard but you need to make sure you db is not compressed in 2008. If it is you'll need to uncompress it first before you take a backup. You can do this like this after you install TFS 2013 (you don't need to have the db there to do that, you can install but not create a defaultcollection) restore the db and attach it from the TFS management console. It will upgrade automatically.
Then to migrate to Azure DevOps 2019, you need a minimum of Windows Server 2012 (so no need to change VM) but you'll need to upgrade to SQL 2016 SP1 which is the minimum for AzDo 2019. You just need to run the installation of AzDo 2019 and it will upgrade 2013 to 2019 inplace.
In order to make sure you don't have clash, make sure you change the Server SID in TFS 2013 with this,
In AzDo 2019, do a non-production upgrade and it will take care of that for you.
Finally once you upgraded to 2019 (in-place) you can run the migration wizard and go to the cloud
All the requirements are available here
Our current Reporting and analysis server for TFS 2015 is SQL 2012 Standard. I would like to upgrade to SQL 2016 Enterprise (Join our current 2016 Enterprise environment). What would that process be and will there be any historical data loss?
Is it as simple as remove the configuration for Standard and the point it to the new Enterprise server and then let it rebuild the warehouse and the cube?
outside of the time it takes to rebuild, will I loose anything?
First, check your versions.
TFS 2015 RTM does not support SQL Server 2016.
TFS 2015 Update 3 and beyond does support SQL Server 2016.
Assuming your reporting databases (TFS_Analysis and TFS_Warehouse) are on a totally separate instance of SQL server than your TFS operational databases (TFS_Configuration and TFS_<ProjectCollection>), or are going to be moved to a totally separate database instance, there should be minimal risk. You just update the reporting configuration to point to the new SSRS/SSAS servers and databases and everything will rebuild, no historical data will be lost.
If your intent is to totally migrate your TFS databases to a new SQL server version, it's a more involved process with a higher degree of risk -- downtime will be required and it's wise to do a test migration first.
Regardless, no data will be lost.
Should I expect any problems installing a SQL Server Analysis Services 2016 tabular instance next to a SQL Server 2014 database engine? (e.g. due to an update of some shared components)
I'm mostly worried about any issues related to the running database engine, since this is a production server.
Thanks.
This is supported by Microsoft.
side-by-side install
I'm planning to migrate all the SSRS reports from 2008R2 server to new sql server 2014 environment. As far as migration is concerned, I was asked to take the backup of 2008R2 report server database and restore it in 2014 server.
I was not convinced with this since there may be new tables available in 2014 Report server.
The new features of 2014 cant be utilized if the old report server database is restored.
Please let me know if this thought is correct.
Are there any new tables available in 2014 report server database?
What is the best option to migrate ssrs reports from 2008 r2 to 2014 server?.
Your question is a bit confusing, I will assume you want to move the database from a Server A with SQL Server 2008R2 + SSRS 2008R2 to a Server B with SQL Server 2014 + SSRS 2014.
Are there any new tables available in 2014 report server database?
There is no official communication on it.
If you really want to know it you could do a schema compare between the 2 versions.
But do not forget to compare everything, not only tables:
Columns
Stored Procedures, Functions
...
Database structure is not the only thing to take into account, what about:
All the configuration files
Encryption Keys
...
What is the best option to migrate ssrs reports from 2008 r2 to 2014
server?.
Short answer:
My recommended way of doing it would be to use RS Scripter and generate a script on Server A with all the objects (reports, datasources, subscriptions, ...) you want to move.
Then you can restore it on Server B.
Long answer:
If you really want to migrate the full database like you were asked to do, there is no officially supported way to move the database to another SQL instance and upgrade the version at the same time.
You could try to follow the steps to Backup and Restore Operations for Reporting Services, and apply it to a newer SQL Server instance with another SSRS version, but it will be at your own risk.
The supported ways to do would be to either:
Upgrade from SSRS 2008R2 to SSRS 2014 on Server A
Move from Server A to Server B
or
Move from Server A to Server B
Upgrade from SSRS 2008R2 to SSRS 2014 on Server B
Here are the related MSDN articles for these operations:
Migrate a Reporting Services Installation (Native Mode)
Upgrade to SQL Server 2014
Again, I would advise using a tool to migrate the reports and other items instead of trying to migrate the full database.
I do not think restore 2008R2 reportserver db on 2014 will work, because the report definition schema is totally different.
I did a migration task to move 2008R2 reports to 2012. Because there are hundreds of reports on the 2008R2 server, I found the easiest way is to write some codes to read report definition, and then create on 2012 server.
From: https://msdn.microsoft.com/en-us/library/ms143747.aspx
There are two general approaches to upgrading a Reporting Services
deployment:
Upgrade: You upgrade the Reporting Services components on
the servers and instances where they are currently installed. This is
commonly called an “in place” upgrade. In-place upgrade is not
supported from one mode of Reporting Services server to another. For
example, you cannot upgrade a Native Mode report server to a
SharePoint mode report server. You can migrate your report items from
one mode to another. For more information, see the ‘Native to
SharePoint Migration’ section later in this document.
Migrate: You
install and configure a new SharePoint environment, copy your report
items and resources to the new environment, and configure the new
environment to use existing content. A lower level form of migration
is to copy the Reporting Services databases, configuration files, and
if you are using SharePoint mode, the SharePoint content databases.
If you do an in-place upgrade from SQL Server 2008R2 to SQL Server 2014, then everything should work as expected.