When upgrades go bad... always have a backup plan!

So, the upgrade to R2 didn't exactly go according to plan. It transpired that the server had some invalid SSL certs installed on it and the upgrade wizard threw an error before continuing with the process.

Unfortunately the service then wouldn't start again throwing errors about reserved URLs and not being able to load the default AppDomain. Nothing obvious to resolve and a repair to the installation threw similar errors.

I already knew at that point that I had a rescue point if the upgrade didn't go well. A new Reporting Services installation will happily be configured to talk to a pre-existing Reporting Services database and that was always my fall-back position - to uninstall the instance and reinstall.

Once the reinstall had completed, I had to reconfigure the ports appropriately on the instance so that the SharePoint farm knew where to find it and then had to redeploy the datasources (unfortunately whilst I'd backed up the encryption key pairing I'd neglected to note the password, so I had to delete the key and recreate it, which removes all encrypted content from the RS database, including data sources).

Data sources redeployed reports all began to function again and all was once again well with the world.

This whole process has reminded me of why I hate upgrade processes. Of course going back over things now, I see the guidance MS put out about SSL certificates, so you could quite easily accuse me of failing to do due diligence to the pre-upgrade checks recommended by MS, but given that those checks also include the oh so excellent advice to "carry out the upgrade on a test farm with an identical configuration" (oh sure, right, we all have an identical SP farm and RS setup laying about!) it's not surprising that sometimes you miss something.

My advice: if you can, treat upgrades as a migration, especially if anyone washes their hands of any responsibility regarding likely success by suggesting you should do the upgrade before you do the upgrade...

- rob

Preparation for upgrading an SQL 2008 Reporting Services server in Integrated mode to 2008 R2

This is an information post really.

First up, install and run the upgrade advisor. Always a sensible step, they build these tools for a reason...

Mine cropped up a warning that seems to be fairly common, namely:

Upgrade Advisor detected one or more custom data processing extensions on the report server. Upgrade can continue, but you must move the data processing extension assemblies to the new installation folder.

A quick search revealed that this is due to having custom entries in the config sections of the Report Server setup. In my case I think this was just a red herring, but the necessary steps for resolution can be found here:

1. Details relating to this warning
2. Information on where to find the extensions (i.e. the deployment model for custom extensions)

Following these, I checked the web.config in the ReportServer folder and found the following:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

      <dependentAssembly>

        <assemblyIdentity name="Microsoft.ReportingServices.Interfaces" publicKeyToken="89845dcd8080cc91" culture="neutral" />

        <bindingRedirect oldVersion="8.0.242.0" newVersion="10.0.0.0" />

        <bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0" />

      </dependentAssembly>

      <dependentAssembly>

        <assemblyIdentity name="Microsoft.ReportingServices.ProcessingCore" publicKeyToken="89845dcd8080cc91" culture="neutral" />

        <bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0" />

      </dependentAssembly> 

</assemblyBinding>

Based on my reading of the deployment model (second link above) this is what has caused the upgrade advisor to throw that warning. There's nothing there that was developed or deployed as a custom extension so I'm assuming it's just poor scripting not picking something up, after all, these look like pointers to later versions of existing core DLLs rather than anything that could be described as 'custom', presumably the result of a CU at some point...

In any case, from the documentation I know that what I need to do if things didn't go well is copy them across to the new installation folders and all should be well.

I will be running this upgrade within the next couple of days, so will post results after completion.

- rob