Upgrading SSRS 2016 to SSRS 2019 in place
-
Server A has SSRS 2016 on it and I would now like to upgrade to SSRS 2019
As I go through the upgrade wizard, I come upon the attached print screen..which I mostly understand besides to 4th bullet point "Migrate your reports"
If Im doing a in place upgrade, dont I uninstall SSRS 2016, install SSRS 2019 and then point to the existing Report database on Server A ?
Do I need to export all my reports and then re-import them, even though its the same database server ?
Any other tidbits when doing this upgrade that you can throw in, would be greatly appreciated.
Thank you
- This topic was modified 7 months, 2 weeks ago by koln.
-
This was removed by the editor as SPAM
-
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
-
Your reports are NOT stored inside the SQL database if I remember right. It is metadata and jobs that is in the database side. So if you don't back up your reports prior to upgrade, the reports will be lost when SSRS is uninstalled as indicated by the upgrade assistant. That is why it is telling you to migrate your reports to a standalone SSRS 2019 instance or back things up before you upgrade. If I remember right (been a while since I looked into it), you can upgrade from SSRS 2016 to SSRS 2019 in place, but I'd still want to do a backup of everything just so I don't hose anything and if I do, I have a way to roll things back.
The reason I am fairly confident reports are NOT stored in the database side is that I am fairly confident that your SSRS database doesn't need to be the same version of SQL as the SSRS instance. What I mean is that you can have SSRS 2016 with a SQL Server 2012 database for the metadata. As long as the database is older or the same as SSRS, you should not have any issues. Newer is a "MAYBE". It MAY work, or it MAY give you errors. I've read about people having a 2014 SSRS with a 2017 database on it and had no issues, but that doesn't mean it will work for you or continue to work for them. An update could hose their system.
What I would do on a test system - back up all the stuff it tells you to in the above screenshot, stop SSRS 2016, install SSRS 2019, restore everything to SSRS 2019 and point to the SQL 2016 DB, test reports (performance, output, export, etc.) and if you are 100% happy, then upgrade SQL to 2019 from 2016. Anything breaks or doesn't work as expected, turn 2019 SSRS off and 2016 SSRS back on until you have time to upgrade the reports to work properly in 2019. Alternately, back everything up, upgrade SSRS 2016 to SSRS2019 in place, restore encryption keys (optional, but if you can't see data in SSRS, it may be required). Downside with in-place upgrade is rollback is a bigger pain in the butt as you have to uninstall and restore from backup. Migration install, if it fails, you just turn the old system back on and you are done.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Brian, thank you for the detailed answer. If I have 50 reports, do I need to manually export each individual one, so I have a backup...and once I install SSRS 2019, I need to manually upload each one individually ?
Alternatively, can I export a folder of 50 reports..and then upload that folder of 50 reports to 2019?
-
Personally, I would test. If you to to your SSRS instance, can you "export" or "download" a folder? I cannot, but I'm also not on 2016 (I'm on 2012... I know... I need to upgrade, but just haven't had time). I don't know for sure if 2016 lets you export a folder.
My approach is to have all my reports in git. That way if my server explodes (ransomware, botched upgrade that requires a reinstall, disk failure, etc.), I have a secondary location for all my data. PLUS I have revision control that way.
BUT assuming you don't have it in a code repository (which I strongly encourage you to do), I'd use powershell to dump the data from the test system to disk, delete the data from the test system, and restore from the data dump. Failing that, restore the data dump to a new folder on the server and see what breaks. I say "powershell" as it has a nice commandlet ready to go for that. A quick and dirty script:
#Output will be to the folder C:\SSRS. Create this folder prior to running this script
#pre-req
#Uncomment the Install-Module line IF you have never run this script on this machine before
#Otherwise, leave it commented out
#Install-Module -name ReportingServicesTools
import-module ReportingServicesTools
$sourceRsUri = 'https://sourceURI/reportserver'
$destinationRsUri = 'https://destinationURI/reportserver_SSRSTEST'
$proxyDown = New-RsWebServiceProxy -ReportServerUri $sourceRsUri
$proxyUp = New-RsWebServiceProxy -ReportServerUri $destinationRsUri
$fileLocation = 'C:\SSRS'
Out-RsFolderContent -proxy $proxyDown -RsFolder / -Destination $fileLocation -Recurse
#ONLY run the below line IF you are trying to deploy changes to the report server.
#This WILL overwrite everything from the $destinationRsUri variable
#Write-RsFolderContent -proxy $proxyUp -path $fileLocation -RsFolder / -RecurseThings to note:
1- make sure to update all variables above to make sure you are exporting what you think you are exporting
2- review the out-RsFolderContent command to make sure the parameters make sense for your setup (ie do you want to export the root and everything in it, or just a specific folder)
3- only uncomment the last line if you are SURE you want to write the content back to a server.
4- do NOT run this on production unless you have tested it worked on the test system and caused no harm. The OUT-RsFolderContent should be safe to run on production as it is just exporting everything with the current folder structure. The WRITE-RsFolderContent will update data and will overwrite any file/folder conflicts it finds, so be careful running that one, especially on prod.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply