ERROR: Execution '' 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)
TROUBLESHOOTING:
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)"
https://support.microsoft.com/default.aspx?scid=kb;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
UNSUPPORTED WORKAROUND *****
IF (@OwnerName
= 'NT
AUHTORITY\NETWORKSERVICE') BEGIN
SELECT
@OwnerID = SE.OwnerID
FROM
[ReportServerTempDB].dbo.SessionData AS SE WITH (XLOCK)
WHERE
SE.SessionID
= @SessionID
END ELSE BEGIN
EXEC
GetUserID @OwnerSid,
@OwnerName, @AuthType,
@OwnerID OUTPUT
END
--***** END
UNSUPPORTED WORKAROUND *****
-- 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
https://technet.microsoft.com/en-us/library/cc281307(v=sql.100).aspx
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
https://msdn.microsoft.com/en-us/library/cc281307(v=SQL.100).aspx#ViewState
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: https://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 following
link you have more information on what you meant by the term "sticky"
under the section "persistence"
(https://en.wikipedia.org/wiki/Load_balancing_(computing)
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
https://msdn.microsoft.com/en-us/library/ms157273.aspx
EnableAuthPersistance
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
https://www.microsoft.com/download/en/details.aspx?id=7218
I hope this helps,
Maria Esteban
Reporting Services Support Engineer
Comments
Anonymous
February 06, 2013
in impersonation, use : <identity impersonate="true" userName="xxxxx" password="xxxxx" /> instead of : <!--<identity impersonate="true" />--> hope it helpsAnonymous
August 08, 2013
The comment has been removedAnonymous
March 10, 2014
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...Anonymous
February 04, 2016
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: ericphan.net/.../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=9.0.0.0, 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.