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)"
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:
--***** BEGINUNSUPPORTED WORKAROUND *****
IF (@OwnerName= 'NTAUHTORITY\NETWORKSERVICE') BEGIN
@OwnerID = SE.OwnerID
[ReportServerTempDB].dbo.SessionData AS SE WITH (XLOCK)
END ELSE BEGIN
EXECGetUserID @OwnerSid,@OwnerName, @AuthType,@OwnerID OUTPUT
--***** ENDUNSUPPORTED WORKAROUND *****
-- Previousvalue for this section
-- EXECGetUserID @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: http://aspnetresources.com/tools/machineKey
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 followinglink 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,
Reporting Services Support Engineer