Skip to content

Day: December 10, 2014

Reporting Services Web Part Error After SharePoint Upgrade

Published December 10, 2014

I recently completed an upgrade of SharePoint 2010 to 2013 for a customer that was using Reporting Services integrated mode fairly heavily. After the initial upgrade however, I was getting the following error whenever I tried to access a page that contained a Reporting Services report viewer web part:

Web Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type Microsoft.ReportingServices.SharePoint.UI.WebParts.ReportViewerWebPart,Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 could not be found or it is not registered as safe.

The version of Reporting Services on the originating SharePoint 2010 farm was from SQL Server 2008 R2 (version 10) and the version in the new farm was SQL Server 2012 SP1 (version 11). The message pretty clearly indicates that it was having trouble loading a version 10 instance of the web part assembly, so I opened up the web.config file for my application, and sure enough, while there was a safecontrols entry for version 11 of the assembly, there was none for version 10. There was a binding redirect for the assembly itself (redirecting from version 10 to 11), so this was pretty clearly a bug in the installation process (SQL server install team take note!).

This would only affect content brought forth from an older SSRS system which is what I had. One solution would be to re-add all of the web parts onto the relevant pages. That would explicitly use new assembly references, but would also take a great deal of time. Another would be to directly edit the web.config files of all of the farm applications. While not generally considered best practice, this would solve the problem, especially since it corrects an oversight.

Hunting around, I came across my friend Chris O’Connor’s blog post on this very topic. Chris had this exact issue, and a rather large farm with multiple applications to deal with, so he built some PowerShell script to add these entries back in. The complete script is in Chris’ post.

In any event, regardless of the method used, adding the safe controls entry into the web.config file(s) fixes this particular issue. On to the next problem…..

4 Comments

Error 1603 Installing Reporting Services Add-In onto a New SharePoint Server

Published December 10, 2014

I had an interesting (annoying) error this week at a customer site. I was adding a new server to an existing SharePoint farm. This was a relatively new farm, installed a couple of months previously. This farm has SQL Server Reporting Services (SSRS) installed. The new server wasn’t running the SSRS service application, but as with any WFE server, it needed the SSRS SharePoint add-in installed.

Although the SQL Server Reporting Services add-in is included as part of the SharePoint Server prerequisites install, it’s an older version. Since in this case I was using SSRS 2012 SP1, so I needed to manually install it. However, attempting to do so resulted in a rather nasty failure error 1603, and the add-in simply refused to install. I hadn’t seen this one before.

Poking around a bit, I found that you can get this error when the installed version of the bits on a SharePoint server don’t match with what has been applied. This is the state of a server after a Cumulative Update or Service Pack has been installed, but PSConfig (the Products Configuration Wizard) has not yet been run. I then ran the configuration wizard on the new server, and it did in fact indicate that a upgrade was needed. This was a bit confusing, as I had only just installed the SharePoint bits on this machine. How did this happen?

Well, as has been my practice for some time, whenever I install SharePoint bits on a server, I immediately run Windows update to make sure that everything is nice and new. It’s a new server, that’s the worst that could happen, right? Wrong. As I was aware (but had forgotten about), in September, Microsoft started delivering SharePoint updates along with regular Windows updates. This, in my opinion, is not a good thing, and is why as pointed out by Todd Klindt, you should no longer enable auto update on your SharePoint servers. You should apparently be careful of doing manual updates as well.

My little Windows update had snuck in some SharePoint updates causing the upgrade requirement, and the problem with the SSRS add-in. In addition, since this was a multi server environment, it put this server out of step with the other servers. After bringing the rest of the servers up to the latest update level, and running PSConfig on all of them, I was able to install the SSRS add-in on the new server. All was right with the world again.

6 Comments