I ran into an odd issue today, doing an in-place upgrade of SQL 2012 SP3 to SQL 2016 in prep for a SCOM upgrade that was worth noting. My customer had separate instances for the DB/DW, and that upgrade was fine. However, when doing an inplace of SSRS, we got the following failure during the SQL upgrade:
There isn’t much out there on the matter, other than noting that the SQL installer doesn’t support custom extensions. The problem, as I see it is that when SCOM reporting is installed over SSRS, it does a whole lot of crap to the RSReportServer.config file. In this case, the following lines appear to be the culprit.
To fix, we did the following.
1) Locate and backup the RSReportServer.config file
2) Open the original copy with notepad and do a search for <Authentication>. The second <Authentication> tag will take you to place where these extensions are located.
3) Remove the extensions (the entire contents from opening to closing tags). You can leave the open and close tags for <Security> and <Authentication> (note we recycled the report server service as well, but I’m not sure this is necessary). We simply pasted these items into a separate notepad document. We then saved the RSReportServer.config file. This breaks SCOM reporting at this point.
4) Perform an in-place upgrade of the SQL server.
5) Re-add the extensions. It is worth noting that the RSReportServer.config file moves to another directory during a SQL in place upgrade. You’ll need to find that new file and add the custom extensions back in there.
6) Last, but not least, there are some SCOM related files that get left behind in the old report server bin directory. Copy those files into the new SSRS location. Do not replace anything that’s already there, just copy over the files that are left behind. After this, recycle the SSRS server. This should allow reports to load. SCOM reporting was functional again at this point.