May 14, 2020 at 6:08 am
HI,
Recently We migrated SSRS from SQL 2008 to SQL 2017 using backup and restore of report database.Currently both SQL 2008 and SQL 2017 reports are running on same database server.
Now we are not able to access the reports on SQL 2017. I have checked the SSRS log and found unhandled exception 'failed to listen on prefix 'http://+80/reports 'because it conflict with an existing registration on the machine.
Please suggest any action to fix the issues
May 14, 2020 at 9:42 pm
The post is very confusing. Did you do an inplace upgrade or did you do a migration? I am not sure what an "inplace migration" is. I am also confused how "SQL 2008" and "SQL 2017" are running on the same database server... SQL Server is the database server. I am guessing you mean you have SSRS 2008 and SSRS 2017 running with them both pointing back to the same database server which to me also sounds like a dangerous setup.
But you also said that you did a backup and restore of the report database.
My GUESS as to what you did is you did a migration install on the same physical server (or VM). So the single server (physical or VM) is running SQL Server 2008 and SQL Server 2017 as named instances. You did a backup and restore of the 2008 SSRS database onto 2017 (presumably changed the comparability mode and updated statistics and such). On top of that, on that same server (physical or VM) you installed both SSRS 2008 and SSRS 2017.
Am I on track so far? If not, stop me here as the rest is assuming the above is correct.
You are able to successfully start SQL Server 2008, SQL Server 2017 and SSRS 2008, but when you go to start the SSRS 2017 you get an error. The error is pretty clear to me - the service failed to start because it cannot listen on http://+80/reports because it is in use. Lets assume your server name is "reportserver". End users accessing the reports would go to http://reportserver/reports previously to see the SSRS 2008 reports. Currently that still works (right?). So you go to start SSRS 2017 and it fails. What URL do you expect it to use? It is trying to use http://reportserver/reports and that is in use. If you stop SSRS 2008 and start SSRS 2017 it will likely start up no problem.
Does the above make sense? If not, can you provide more details about what you did as to me it sounds like a migration install onto the same server which works fine as long as you shut down SSRS 2008 before turning on SSRS 2017.
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.
May 15, 2020 at 4:54 am
Thanks Brian for quick reply and sorry for the confusion. What i did is, migrated\upgraded SQL 2008 SSRS to SQL 2017 and Both instances are running on same Host\VM. Once the testing is done SQL 2008 server will be planned for decommission.
So I have taken backup of SSRS db's from 2008 server and restore it on SQL 2007 db server. Post that configured reporting servers with existing database. While opening the 2017 SSRS url, ssrs report are not visible and just showing report list and SSRS report version details on report URL. Attached screen shot for same.
I found MS article, SSRS URL port should be different if 2 SSRS running on one machine.
Normally, In SSRS url we used see folder of ssrs report and that is visible in SQL 2008 but not in SQL 2017.
Please suggest
Thanks you in advance!
May 15, 2020 at 2:22 pm
Did you restore the encryption keys using the SSRS configuration tool? Without that, it won't be able to decrypt any encrypted data.
I would recommend checking out this post:
https://stackoverflow.com/questions/46876442/ssrs-migration-from-2008-to-2016/46879292#46879292
and make sure you did all of those steps but skip the "detach and attach" steps as you did a backup-restore method. You are basically doing what they did with the exception of moving the files; you are using the backup.
It was for 2008 to 2016, but I expect to 2017 it should be similar if not identical.
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 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply