Hi hub303, You need to assume both of your failover server are use the same IP address and Server name, which is available all the time for your reporting Services to connect to, and the relevant database instance must be running normally without any exception, pay attention to the error message you received, which indicate that the reportServer Database is unavailable for Reporting Services to connect, you should focus on this part to audit the both clustered database instance, to check the relevant SQL Server log info or windows log info to address it. Thanks, Bill Lu Bill Lu TechNet Community Support

Thanks for the information, Bill. Since we are running the SQL cluster in active/active mode, I doubt that the IP Addresses are the same between the two servers that hosted the database instances. The database instance was only on the other server for approximately 30 minutes and then failed back to the original server. It was at this point that the Report Server was unable to reconnect to the report catalog database. It appears that when the ReportServer database was on the second server, there were successful report executions. The Windows Application logs on the Report Server indicate the inability to connect to the ReportServer database only at the point of failover and fail back of the Report Catalog database server. The only errors reported in the Report Server logs indicate the "ReportServerDatabaseUnavailableException" error as follows: e ERROR: Throwing Microsoft.ReportingServices.Library.ReportServerDatabaseUnavailableException: , Microsoft.ReportingServices.Library.ReportServerDatabaseUnavailableException: The report server cannot open a connection to the report server database. A connection to the database is required for all requests and processing. ---> System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection) at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory) at System.Data.SqlClient.SqlConnection.Open() at Microsoft.ReportingServices.Library.ConnectionManager.OpenConnection() This error is repeated from after the failback until approximately 10 hours later, when the Report Server magically started executing reports again (I'm assuming this was due to an app pool recycle). The SQL Server logs show that the ReportServer and ReportServerTempDB databases were started successfully and subsequent CHECKDB finished without errors. There were no reports of the database being unavailalbe at any time in the SQL Server logs. This is truly a mystery and unfortunately the only way that I can think of to attempt to recreate the situation would be to force a filover of the database instance again, an idea that the DBAs would most likely frown upon for obvious reasons.

It would seem that our Reporting Services installation was unable to reconnect to the ReportServer database after the SQL server instance hosting the ReportServer database failed over to another server. The server failed over to another active server, then failed back after the problem on the original server was resolved. The report server remained disconnected from the report catalog for appoximately 10 hours, then "magically" started processing reports again. Error was the typical "ReportServerDatabaseUnavailableException" that would be expected, but should have reconnected after the instance became available again. Environment is as follows: Scale-out deployment with SQL Server 2008 R2 Reporting Services, hosted on Windows Server 2008 R2. The report catalog resides on an SQL Server 2005 instance in a clustered environment, hosted on Windows 2003 Server. All deployments (Windows Server and SQL Server) are 64-bit enterprise edition. There have been no configuration changes on the Report Server that I am aware of. I have reviewed the Reporting Services logs and found the aforementioned error code repeated for each report execution attempted by a client. The Windows server application log, however, only reports two instances of a disconnection between the report server and report catalog database, one at the time of failover, and the second when the instance failed back. Would appreciate any help or insight to resolve the issue to prevent further outages due to failover.

hub303, If so, I would suggest opening a case with Microsoft Customer Support Services (CSS) (http://support.microsoft.com), so that a dedicated Support Professional can assist you in a more efficient manner. Thanks, Bill Lu Bill Lu TechNet Community Support

hub303, The problem was that the Reporting Services instance did not recover it's connection to the report catalog database after the cluster failed back Do you mean your Reporting Services (RS0 instance failed to restart after server failed back? If so you need to troubleshoot the RS log information in your RS server, and to address the root cause. Otherwise, if your problem is something relate to slow response time for SQL Server Reporting Services after restart, please refer to the article below to fix it: http://blogs.msdn.com/b/emilianb/archive/2009/04/24/slow-response-time-for-sql-server-reporting-services-after-restart-or-after-period-of-inactivity-why-does-it-happen-and-how-to-fix-it.aspx Thanks, Bill Lu Bill Lu TechNet Community Support

Hi hub303, Thanks for your post. According to your description, you want the Cluster service to failback to the original node immediately after the original node become active. If so, you can refer to the steps below: 1. Open Cluster Administrator. 2. In the console tree, click the Groups folder. 3. In the details pane, click the appropriate group. 4. On the File menu, click Properties. 5. On the Failback tab, click Allow failback and click immediately. More information about this topic, please refer to the article below: Set group failback policy Thanks, Bill LuBill Lu TechNet Community Support

Thanks Bill, but the cluter failed over and back as expected. The problem was that the Reporting Services instance did not recover it's connection to the report catalog database after the cluster failed back. There was only a 30 minute timeframe from when the server instance failed over to when it failed back, but the report server did not recover it's connection to the report catalog database until 10 hours later.

No, the Report Server was not restarted ni this instance. Perhaps a step-by-step would help to describe the incident. For the sake of this example, Server1 will be the server that hosts our Report Server, Server2 is a server in a clustered SQL Server environment, and Server3 is another server in the SQL Server clustered environment. Here is what happened: Server2 experienced a problem and failed over the SQL Server instance that hosts the report catalog database to Server3 Server1 reported that the report server could not connect to the report catalog database The problem with Server2 was resolved, which resulted in the SQL Server instance failing back to Server2 Server1 reported again that the report server could not connect to the report catalog database At this point, there were no more notifications from the report server about being unable to connect to the report server database, but the report server logs indicate that any report that attempted to execute threw the "ReportServerDatabaseUnavailableException" error. The Report Server (server1 in the example) never restarted. The problem was not slow response, the problem was that the connection between the Report Server (server1) and the report catalog database was never re-established after Server2 failed over to Server3 and then back to Server2.