December 15, 2016 at 7:08 am
Recently, we cloned a VM Reporting Server that was MSSQL 2012 Enterprise. On this clone (We will call SSRS02) was the SSRS services. The original SSRS Server contained just the SSRS services while the Report Server lived on a clustered server. SSRS Server was not on that clustered node and was a stand alone VM. I then created a new Report Server on SSRS02 using SSRS configuration Manager so as to point the soon to be upgraded server to 2016. Once the new Report Server was created (temporarily native, until we upgraded the clustered node and pointed SSRS back to the original ReportServer Database), I then upgraded the SSRS services on SSRS02 to MSSQL 2016 Enterprise. During this upgrade process on SSRS02, the upgrade process reached out to the original ReportServer database and not the new ReportServer I created and changed the table stating that SSRS was now 2016, thus breaking our reports.
Have I lost you all yet???
Why did the 2016 upgrade the old ReportServer database when I specifically created a new ReportServer Database and pointed the Services to it prior to the upgrade, thus breaking our production SSRS server (lets call it SSRS01, the cloned server)
Is there a hidden configuration file that I needed to manually update from the VM cloning that was still pointing to the production SSRS?
Clear as mud?
December 15, 2016 at 3:05 pm
randy.moodispaugh (12/15/2016)
Recently, we cloned a VM Reporting Server that was MSSQL 2012 Enterprise. On this clone (We will call SSRS02) was the SSRS services. The original SSRS Server contained just the SSRS services while the Report Server lived on a clustered server. SSRS Server was not on that clustered node and was a stand alone VM. I then created a new Report Server on SSRS02 using SSRS configuration Manager so as to point the soon to be upgraded server to 2016. Once the new Report Server was created (temporarily native, until we upgraded the clustered node and pointed SSRS back to the original ReportServer Database), I then upgraded the SSRS services on SSRS02 to MSSQL 2016 Enterprise. During this upgrade process on SSRS02, the upgrade process reached out to the original ReportServer database and not the new ReportServer I created and changed the table stating that SSRS was now 2016, thus breaking our reports.Have I lost you all yet???
Why did the 2016 upgrade the old ReportServer database when I specifically created a new ReportServer Database and pointed the Services to it prior to the upgrade, thus breaking our production SSRS server (lets call it SSRS01, the cloned server)
Is there a hidden configuration file that I needed to manually update from the VM cloning that was still pointing to the production SSRS?
Clear as mud?
I'm not 100% sure, but I suspect that what you did was in the category of "you can't do that", but as I'm not sure, I'm happy as a clam to be edumacated on what's actually true. I'm wondering why not stand up a new ReportServer database VM and migrate things to it? Just seems to me that the risk is lower and the opportunity to test things before a go-live date would put everyone in a much better position where confidence in the results is concerned.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply