Reporting Services Databases on Availability Groups

In my current job as a DBA, one of my missions is making everything as automated as possible and making sure that when things go wrong(trust me, they will), the applications that are using my environment can smoothly continue to run with less intervention possible.

You will make mistakes which is part of the job, learning from those mistakes is what makes you grow. Today I want to share with you a few tips that will make your experience with SSRS Databases and Availability Groups less painful.

Setup the SSRS databases to use the Listener

The very first step to do is to create the Reporting Services Databases in the Database Engine. One important point is to make sure the SQL Server Name used to create the databases is the listener name of the Availability Groups.

image

As you can see in the above picture, the Report Server Database was created pointing to a listener, which makes our SSRS databases to be accessible in case of a failover.

In this point of time, it is already possible to access your Reporting Services instance, but the same it is not High Available yet.

Adding the SSRS Databases to the Availability Groups

Adding the SSRS DB’s to AG is the same process of adding any other user database, so here you can choose if you want to do backup/restore, seeding, etc..

After you have added the same, you can just check the status of it.

image

Removing the sysadmin permissions

By default the Service Account used for running the Reporting Services Service, is granted the sysadmin privileges in the instance, which most of the times facilitates the management, but it brings another account with too much permissions. In my environment, I prefer for SSRS to remove the sysadmin permissions of the Reporting Service service account.  The code to execute is below and should be executed in all the cluster nodes.

https://gist.github.com/marcosfreccia/18c8c3e9bd8d6e9dc3600c29aec6da4b.js

Permissions and Roles

When both SSRS Databases are deployed as the first time in the instance, some objects are created outside the SSRS Database scope. Those objects are created in non High Available Database such as: master and msdb. By removing the sysadmin permissions, we need to make sure the Service Account has proper permissions to perform the normal activities.

The following table describes where and which permissions the account should have.

 

Database Service Account Role
master [DOMAIN\SQLSSRSAccount] RSExecRole
msdb [DOMAIN\SQLSSRSAccount] RSExecRole; SQLAgentOperatorRole;SQLAgentReaderRole;SQLAgentUserRole
ReportServer [DOMAIN\SQLSSRSAccount] db_owner;RSExecRole
ReportServerTempDB [DOMAIN\SQLSSRSAccount] db_owner;RSExecRole

Roles

As noted above, the RSExecRole plays an important part in the whole process and it is vital to the Reporting Services functionality, when the same doesn’t have sysadmin permissions. The following scripts helps to generate the proper script for creating RSExecRole in the other nodes of the cluster.

https://gist.github.com/marcosfreccia/2d12e4e550aaf748c03b93518b089929.js

This script above you should execute in the node of your cluster where the Reporting Services Database has been created for the first time. The results that you get from it, you should execute in the secondary node of your cluster, doing this guarantees that after failovers, SSRS can still continue to work properly.

I don’t have a complex SSRS deployment and this has been working in production for quite some time. We have subscriptions that performs the following activities.

  • Send Email
  • Create XML files in shares
  • Create html files in shares
  • KPI’s
  • Shared Data Set’s
  • Shared Data Sources

Failover of the SSRS Databases

If you have completed the steps before, failovers are just normal as failing over any other user database. This also includes the SSRS jobs for Subscriptions and KPi’s to be recreated in the new primary node. For removing the jobs from the secondary, I use a PowerShell script that takes care of this cleaning up activity.

In this documentation created by Microsoft: Reporting Services with Always On Availability Groups (SQL Server), they have a different set of approaches for failing over the Databases and post failover activities. I honestly never had to do something like that, but make sure to read it and test in your environment.

I hope you enjoyed this blog post. If you do something different and would like to share with me, leave a comment in this post.

Marcos Freccia
Data Platform MVP

About Marcos Freccia

MVP em SQL Server (Data Plataform) , especialista em SQL Server, e atualmente trabalhando com Microsoft Azure!

Posted on June 25, 2018, in Availability Groups, Dicas, GitHub, Reporting Services, Scripts, SQL Server, VirtualPass and tagged , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: