Emergency 10.2.300.12 install, customer was hit with ransomware now installing on new servers.
I have installed SSRS 2017 many a time, yet this completing stopping me.
SQL 2016 SSRS is not working need to be at SSRS 2017
Installing SSRS 2017 , moves to the point of asking for license key.
Launch 2016 install media and copy license key as MS instructions state
BUT it doesnt work, have tried copy paste and type in.
I honestly don’t think you can use the 2016 engine key on a 2017 SSRS install. Can you install the 2017 engine and take the volume key from that?
Thanks Dan I was thinking the same but had to ask. I have set the SSRS execution to use the service account, totally out of ideas
What does your reporting services log show?
Maybe using 2016’s keys only work for 2017 when doing an upgrade. Try installing 2016, then installing 2017 over it. I’m just spitballing here, I’m no server admin guy.
Customer is upgrading to 2017 , so I cannot get at the errors logs. Have tried 2017 over 2016 and it fails.
@bnixon I got something like the packing slip error when I cloned a server. The datasource was in different location than the original. Rather than fixing all of the reports I just made a SharedReportDataSource where the reports thought it was.
Also the account running the reports needs to be a local admin on the SSRS server.
Ben have you verified that the Shared Data Source is pointing to your new environment for the reports?
Thank you to everyone on your responses. The moral of this one is the moving of SSRS reports from Server 1 to Server 3 is not simple. First issue discover was the service account I was using was not adequate as stated. Once we had SSRS 2017 installed and redeployed app servers, it fell in place. Lot of steps and it is not a point and click move.
Nice, one point I want to make so it may help others. (Related to SSRS, Moving Servers)
Be careful how you do your sub-reports check the .rdls make sure you arent putting in “absolute paths” /MyFolder/reports/CustomReports/MyCustomizedReport/MySubReport.rdl
I’ve found somehow my SSRS Designer tends to do that, so once I clean it up to be merely “MySubReport.rdl” I can move the .RDL across servers, folders etc.
I also I do not use a Direct SQL Datasource, only the Shared one and do everything via RDD. 
I don’t recall the exact specifics, but when setting up a new environment (new App nd SQL servers), whenever I deployed my TEST or DEVEL App, it would break SSRS printing on all the other Apps.
This was because I was specifying a different Report Database Name each time I deployed. It would create the SharedReportDataSource with a new connection string
Then after deploying the UAT_102300 App with Report Database name RPT_UAT_102300, it would change the above to ...Init Catalog=RPT_UAT_102300;....
I believe that if I had also specified a different SSRS Reports Root Folder it would have been fine, as there would have been a unique SharedReportDataSourcefor each App’s SSRS.
