Error

SharePoint and SSRS: The given key was not present in the dictionary

Consider this scenario. You have SharePoint with SQL Reporting Services (SSRS) running in SharePoint Integrated mode. You want to use a SharePoint list as a data source for a report.

In the SSRS Data Connection you enter the URL and credentials for the SharePoint site but when you test the connection the following error appears:

The given key was not present in the dictionary

After a bit of trial and error I discovered that this error occurs if the URL entered isn’t the default URL for the web application.

To resolve the issue, go into Central Admin and check the Alternative Access mappings on the SharePoint site used in the data source. Check that you are using the default URL.

Similar but unrelated issue

Note that there is a similar issue that occurs when added managed accounts in Central Admin. These issues are not related. Further details of that issue can be found here: https://support.microsoft.com/en-nz/help/2463865/sharepoint-2010-error-message-the-given-key-was-not-present-in-the-dic

 

 

Advertisements

SharePoint Error Tracing

Tracing the cause of errors in SharePoint can leave you wondering where to start. In this article I provide some tips on preparing your SharePoint farm with error tracing in mind.

In this example I will assume we have a SharePoint farm with two web front ends (with network load balancing) and an application server. The same method can be used on larger farms.

This method is useful for identifying problems that occur on one server in your farm but not others. The are usually intermittent issues that occur randomly for some users and not others (due to different Web Front Ends servicing the requests).

Configuring SharePoint and IIS 

Alternative Access Mappings

  • In Central Admin, configure alternative access maps for each server in the farm using the servers actual name e.g. SP_WFE1, SP_WFE2, SP_APP1
  • Test by connecting to your SharePoint servers using HTTP://servername

Configured IIS

  • Logon to each server and modify the IIS Bindings to include a host header with the servers actual name (matching the alternative access mapping)
Get ULSViewer

Download ULSviewer from MSDN and put a copy on each web front end.

Trapping errors

The trick to catching errors is to reproduce the error on a known host and capture the error with ULSviewer.

  • Choose a server e.g. SP_WFE1
  • Logon to the server and run ULSviewer
  • Reproduce the error using SP_WFE1 rather than the normal SharePoint URL
  • Copy the error correlation code from the error message
  • Create a filter in ULSviewer
  • Filter by Correlation and paste the code copied in the step above
  • If multiple errors are returned in the log, look for the words error or exception (usually)
  • Highlight the error and full details will appear in the top of ULSviewer pane.
I have used this method to identify issues with web-parts, CSS mappings and service applications.
Note that ULSviewer service can be installed on multiple servers and central monitored. Where is the fun in that…