Features supported by editions are different. For understanding, without discussing all features, we will see the features that are supported only by Enterprise edition.

The following features are supported only by Enterprise edition:

Reporting Services maintain two databases: ReportServer database and ReportServerTempDB. It does not necessarily require the same edition for databases as you have used for Reporting Services. The following list shows you which editions of the Database engine can be used for specific editions of Reporting Services:

You will be able to create, deploy, and consume reports with functionalities as per the features offered by the selected edition. Not only that, but the usage of processors of the system and memory consumption are based on the edition you have selected. Processors are more relevant to database engine. The Enterprise edition will use operating system maximum, but Standard and Web can utilize only four sockets or 24 cores. If you have selected, Express edition, it is limited to one socket or four cores.

Reporting Services consume memory for various operations. If the edition is Enterprise, it can consume operating system maximum. However, if the edition is Standard or Web, it consumes only 64 GB and, Express edition consumes only 1 GB.

For more information about feature comparison between editions, visit the following URL:  https://msdn.microsoft.com/en-us/library/cc645993.aspx

It is always better to check and see whether your system is ready for Reporting Services before installing it. This check-up can be done using a tool given with the installation, which is called System Configuration Checker.

You need to make sure that you have admin rights on the system that you intend to run the installation on. For that, you need to be a member of a local administrator group, or you need to have credentials of an account that has admin rights.

During the installation, you can decide whether the installation wizard should install files and configure Reporting Services with default configurations, or only install files. If you select Install only, then you need to do the configuration later using Reporting Services Configuration Manager. Selecting the Install and configure option allows you to use Reporting Services immediately after setup is finished. However, this option will not be available if Database Engine Services is not selected as part of the instance features or the database engine is not installed on the same instance.

Let's go through the specific steps and options you select during SQL Server installation when you do the installation for Reporting Services. Note that we will not go through every page in the installation wizard, but only the pages related to this recipe. The steps are as follows:

Now you can continue with the other pages and complete the installation.

Since the installation is done with the Install and configure option, it installs the following items/features for us:

In addition to that, it configures following items too:

To verify the installation, you can access the Web Portal and see whether it works or not. The URL for the Web Portal is different based on the installation:

This image shows the Web Portal configured with a named instance:

Figure 1.05

If you open Reporting Services Configuration Manager (this will be discussed in detail in the Accessing Reporting Services Configuration Manager recipe), you will see that some of the services related to Reporting Services are not configured. Unattended Execution Account, Email Setting, Encryption Keys, Subscription Settings, Scale-out Deployment, and Power BI integration are not configured as part of the installation, and they need to be configured manually using Reporting Services Configuration Manager.

The next recipe, Installing Reporting Services-related tools, discusses the other required installations for completing a Reporting Services installation.

You can find links to download SSDT and SSMS using any search engine. But the Microsoft SQL Server team has given us an easier way of finding the relevant download page. These links are given with the SQL Server installation wizard, and this makes sure that you download the latest versions of SSDT and SSMS.

Note that the SQL Server installation page has a number of installations related to SQL Server, but we focus only on the tools related to this book. Here is the way of installing the related tools:

Once both tools are installed, SSMS can be used to connect and manage Reporting Services instances and SSDT can be used to design and deploy reporting solutions. You can launch SSMS and connect with Reporting Services. We will talk more about this tool in Chapter 10, Administering and Managing Reporting Services.

You can create Reporting Services projects using SSDT. It allows you to create a new project, and select the Reporting Services template and Report Server Project type. You will see more on this in Chapter 2, Authoring Reports with SQL Server Data Tools.

There is another useful tool called Report Builder, which is specifically available for power users. This does not mean that it cannot be used by developers, but as it is more of a Microsoft Office-like tool, it is more relevant to power users and business users. This will be discussed in detail in Chapter 4, Authoring Reports with Report Builder.

A newly added tool called SQL Server Mobile Report Publisher is available with Reporting Services 2016. See Chapter 6, Authoring Mobile Reports with the Mobile Report Publisher, for more on it.

Reporting Services Configuration Manager is installed with the default installation. It allows you to manage the following items:

In order to access either a local report server or remote report server using Configuration Manager, you need local system administrator permission of the server.

Let's see how we can open Configuration Manager and see the configuration settings. The steps are as follows:

The rsreportserver.config XML file holds most of the settings related to Configuration Manager. When you change any settings with Configuration Manager, the changes are applied to this file. You can see this file in the <installationpath>eport\Microsoft SQL Server\<instance name>\Reporting Services\ReportServer folder. You can open it and edit using any text editor or XML editor, but it is not recommended because your changes may prevent Report Server from functioning properly.

There are some settings that are not available through Configuration Manager. For example, if you need to add another Authentication Type, it has to be manually added to the rsreportserver.config file, as Configuration Manager does not provide an interface for adding Authentication Types.

Some of the settings should only change with Configuration Manager even though it is possible to change them through rsreportserver.config. For example, encrypted values that are related to some nodes should not be changed through the rsreportserver.config file manually.

In addition to the rsreportserver.config file, there are two more configuration files: rsreportserverservices.exe.config and rsreportdesigner.config. You can read more about them at https://msdn.microsoft.com/en-us/library/ms157273.aspx and https://msdn.microsoft.com/en-us/library/bb630448.aspx .

You can see the current assigned account using Reporting Services Configuration Manager. Once connected to the instance, you can click on the Service Account page to see the current account set or to set a new account for the service:

Figure 1.09

As you can see, there are two options for setting it. You can either select a built-in account or a user-defined (local or domain) account. If you have accepted the default during account selection, you should see the selected account as Virtual Service Account.

When selecting an account, either during installation or later using Configuration Manager, it is important to remember that the account you select has no excessive privileges. Not only that, but also you must make sure that it is a dedicated account for Reporting Services.

There are different types of account that you can select for Reporting Services:

In order to manage the assigned account, follow these steps:

Reporting Services Configuration Manager performs a few operations to apply your changes successfully:

Note that if you add a new service account to Reporting Services, the old account will not be removed from the database instance. See the next screenshot. It shows both accounts under the Users node; NT AUTHORITY\NETWORK SERVICE is the new account and NT SERVICE\ReportServer$SQL2016_M is the old account. Therefore, it should be manually removed if it is not required by the database engine:

Figure 1.12

If you need to create or configure URLs using Reporting Services Configuration Manager, you need to understand how default URLs are created during the installation. This table explains how URLs are set by default:

You can see this in the rsreportserver.config file located in the <installationpath}\Microsoft SQL Server\<instancename}\Reporting Services\ReportServer folder:

Figure 1.13

As mentioned before, you should not use any other tool to create or configure URLs, including the rsreportserver.config file.

In order to create or configure them, you need to make sure that you are a member of local administrator group of the server. In addition to that, if IIS is running in the same server, make sure that there are no virtual directories already configured with the names you have planned for Reporting Services virtual directories for applications.

Reporting Services Configuration Manager has two pages for managing URLs, one for web service applications, and another for web portal applications. It is shown in the following screenshot:

Figure 1.14

If you need to configure the Web Service URL, select the page and make the necessary changes:

As we discussed before, Reporting Services Configuration Manager creates URL reservations in HTTP.SYS when changes are applied. If you open the rsreportserver.config file, you will see how changes are applied to the file.

As we set an additional port to the web service application, we can set additional IP addresses or hostnames for forming new URLs. One advantage with additional URLs is that you can provide different URLs for different audiences, as shown here:

Figure 1.19

When accessing either web service or web portal in the local server, you can use localhost instead of an IP address or server name. You can simply call applications using http://localhost/reportserver and http://localhost/reports . The http://localhost URL is interpreted as http://127.0.0.1 . However, if you have configured URLs to the computer name or a single IP address, this will not work unless you have added an additional reservation for 127.0.0.1.

Similar to Reporting Services URLs discussed in the previous recipe, if you selected Install and Configure during the installation, these two databases are created automatically as a part of the installation. If you selected Install only, then you need to use Reporting Services Configuration Manager to create databases. You can host these databases either in a local database engine instance or in a remote database engine instance. Reporting Services supports the following database engine versions for hosting its databases:

However, you need to make sure that the Reporting Services database is hosted in the correct edition:

You can use Reporting Services Configuration Manager to create and configure the report server database. Or you can use it to view or modify settings related to the database that is already configured. Use the following steps to create or modify the report server database:

The wizard creates both ReportServer and ReportServerTempDB in the selected SQL Server instance. It uses codes stored in the <installationpath>\Microsoft SQL Server\<instance name>\Reporting Services\ReportServer folder to create these databases. Once the report server databases are created, report server uses the credentials stored for accessing report databases. During the configuration, it creates the encryption keys required and adds the necessary permissions for accessing the database.

Reporting Services stores the connection for report database in the rsreportserver.config file in an encrypted format. Depending on the authentication type selected, some of the nodes related to the connection may be empty. As an example, if the authentication type selected is Service Credentials, then LogonDomain, and LogonCred are empty:

Figure 1.24

In order to verify the report database configuration, log in to the SQL Server instance that hosts the databases. You should see two databases configured with the names you used:

Figure 1.25

Remember, Microsoft does not recommend using these databases directly to query or modify data. It is an internal database for report server and should not be accessed and modified.

As mentioned before, Reporting Services uses three databases when the mode is SharePoint integrated mode. Read more about SharePoint integrated mode in Chapter 9, SharePoint Integration.

There are a few key tasks you should perform after installation and configuration:

The required tasks can be performed using standard techniques and available tools:

The key thing to understand is how quickly you respond to an issue, troubleshoot an issue, or how you can recover your reporting environment in a disaster. There are a few standard recovery strategies for reporting environments, but these post installation tasks will definitely help you to recover in most situations. As an example, if you make a mistake while changing the rsreportserver.config file manually, you can simply restore it to the previous stage if you have a backup copy of it. If, for some reason, your ReportServer database becomes corrupted, you can get it recovered using the database backup. Therefore, post installation tasks should not be ignored and must be a part of the installation and configuration process.

You can secure your reporting server more by configuring a High Availability and Disaster Recovery strategy. Considering the demand, requirements, and the budget, a proper HA and DR should be implemented.