ERROR: Execution ‘<ID>’ cannot be found (rsExecutionNotFound)


I would like to share with you usefull information to troubleshoot the following error in Reporting Serices native or integrated with SharePoint mode, in case you find it in your environment. Sometimes, the error can be random, and sometimes, caused by the use of an NLB.

Execution '<ID>' cannot be found (rsExecutionNotFound)



 1. First of all, check the following article, in case you have Exchange 2007 installed and it is causing it:

Error message when you view a report from Report Manager, ReportViewer, or a SharePoint site: "Execution '<SessionID>' cannot be found (rsExecutionNotFound)";EN-US;972328


 2. The cause of this error could be that the credentials of the user do not get correctly impersonated across to Reporting Services for one of the web method calls. This causes the stored procedure 'GetSessionData' to return no data since the user account that created the session is not the one being passed in. 

This may occur on 64bit systems. And it reproduces when the account that runs the report is the not the same as the application pool identity.
Try changing the following stored procedure: 'GetSessionData' like this:

    --***** BEGIN

    IF (@OwnerName
    = 'NT


    @OwnerID = SE.OwnerID


    [ReportServerTempDB].dbo.SessionData AS SE WITH (XLOCK)


    = @SessionID


    GetUserID @OwnerSid,
    @OwnerName, @AuthType,
    @OwnerID OUTPUT


    --***** END


    -- Previous
    value for this section

    -- EXEC
    GetUserID @OwnerSid, @OwnerName, @AuthType, @OwnerID OUTPUT


    And see if the problem disappears.

    If the problem doesn’t disappears, revert back the changes


    3. If Reporting Services is installed in an NLB. Check if the configuration of the Network load Balancer and the Session affinity of the load balancer are correct. See below:

    How to: Configure a Report Server on a Network Load Balancing Cluster


    4. Chacek the configuration of the <machinekey> tag in the configuration files of the load balancer as explained in the following article:

     Configure a Report Server on a Network Load Balancing Cluster


    How to Configure View State Validation


    To run a scale-out deployment on an NLB cluster, you must configure view state validation so that users can view interactive HTML reports. You must do this for the report server and for Report Manager.

    View state validation is controlled by the ASP.NET.
    By default, view state validation is enabled and uses the identity of the Web service to perform the validation. However, in an NLB cluster scenario, there are multiple service instances and web service identities that run on different computers. Because the service identity varies for each node, you cannot rely on a single process identity to perform the validation.

    To work around this issue, you can generate an arbitrary validation key to support view state validation, and then manually configure each report server node to use the same key. You can use any randomly generated hexadecimal sequence. The validation algorithm (such as SHA1) determines how long the hexadecimal sequence must be.


    Generate a validation key and decryption key by using the autogenerate functionality provided by the .NET Framework.

    You can also use this tool to generate validation key:


    5. Configure session affinity in the DNS of the load balancer:

    If you are using a sticky load balancer for the web farm, this requirement is not necessary. When the user connects to the balancer, it ensures that the user is always redirected to the same server during the same session. In other words, "sticky session" (or also called "session affinity") leads to that the user should be allocated to a particular server and that of its data is stored on the same server for the duration of its session.

    On the following
    link you have more information on what you meant by the term "sticky"
    under the section "persistence"



    6. Check that the value of the property EnableAuthPersistance from the RSReportServer.config file is set to False

    Additional information about this property:

    RSReportServer Configuration File



    Determines whether authentication is performed on the connection or for every request.

    Valid values are True (default) or False. If set to True, subsequent requests from the same connection assume the impersonation context of the first request.

    This value must be set to False if you are using proxy server software (such as ISA Server) to access the report server. Using a proxy server allows a single connection from the proxy server to be used by multiple users. For this scenario, you should disable authentication persistence so that each user request can be authenticated separately. If you do not set EnableAuthPersistance to False, all users will connect using the impersonation context of the first request.


    7. If you are using Reporting Services 2005, install  Service Pack 4

    Microsoft SQL Server 2005 Service Pack 4 RTM


    I hope this helps,


    Maria Esteban

    Reporting Services Support Engineer


    Comments (4)

    1. K. Abuje says:

      in impersonation, use  :                 <identity impersonate="true" userName="xxxxx" password="xxxxx" />

         instead of :                                     <!–<identity impersonate="true" />–>

      hope it helps

    2. Matt Boerger says:

      I spent a few hours troubleshooting the same error on a report being invoked through the ASP reportviewer, only to find that the value I was providing for the ServerReport.ReportPath (which came from user entered data) had a trailing space.

      Got rid of the space, and the report worked fine.

      The notable thing was that the report viewer was able to display the correct parameters for the report, so it had successfully opened and read the report definition, something just got tangled up somewhere in execution.

    3. Pedro Carbajal says:

      A client was getting the same error in his browser when running our Report Services.  Clearing his cache and deleting his cookies did the trick for us.  Weird…

    4. Eric G says:

      I was getting this error, but it was a false / misleading error message in my case. Running the offending page from another machine gave the 404 error : 404 Reserved.ReportViewerWebControl.axd not found. From there I located this page that solved my problem:…/reservedreportviewerwebcontrolaxd-not-found.html

      Basically, I installed the Microsoft Report Viewer Control Redist 2008 and related SP1  , then added the handler mapping in IIS:

      Default Web Site -> Handler Mappings

      Click Add Managed Handler

      Request Path : Reserved.ReportViewerWebControl.axd

          Type: Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

          Name: Reserved-ReportViewerWebControl-axd

          click OK

      Note – I did this at the Default Web Site level, but there was also a "Handler Mappings" setting at the top-level in IIS. Not sure if I should have done this there too / instead, but this worked for me.

    Skip to main content