- Installation Pathways and Preparation
- Step by Step: Installing Reporting Services on a Server with IIS
- Installing Reporting Services in a Non-Default Website
- After InstallationTuning and Reconfiguring
- Testing the Installation
- Installing Reporting Services on a Web Farm
- Removing Reporting Services
- Reporting Services Documentation Refresh
- Reporting Services Service Pack 1
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
After Installation—Tuning and Reconfiguring
After you've completed the Setup wizard, you might find it necessary to go back and change some of the settings. One approach you might consider is to uninstall and reinstall Reporting Services to make some of these changes. However, we don't encourage that as there are a number of splinters left behind that make this problematic. See the section later in this chapter on uninstalling before taking that route. You can change the configuration files as described here—if you're careful.
In any case, if you're using SSL security as we suggested, we recommend that you change both the RSReportServer.config and RSWebApplication.config files to include the correct URL and SecureConnectionLevel settings. These changes are described in detail below.
The Reporting Services Configuration Files
RSReportServer.config
We've already talked quite a bit about the configuration items in the RSReportServer.config file—its default location is \Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer. We should mention a few more elements before discussing the other configuration files.
You can control which instance of SQL Server the Report Server web and Windows services uses through the <InstanceId>MSSQL.1</InstanceId> element—MSSQL.1 is, of course, the default instance. When the Report Services file is created, a GUID <InstallationID> is created to uniquely identify an instance of the installation. This same GUID is used to index the encryption keys table we spoke of earlier. You may need to adjust other entries in the RSReportServer.config file—for example, when you want to create custom extension assemblies. However, we'll cover those elsewhere in the book.
SSL Configuration After Install
Ah! So you didn't listen to us about how to install SSL, or you installed oblivious to the importance of SSL and now want to be able to reconfigure to use SSL without having to take the pain of uninstall followed by reinstall. Well, you are in luck because this is controlled in the RSReportServer.config file by the entry: <Add Key="SecureConnectionLevel" Value="3"/> where the Value can be set as follows:
-
3 is the most secure— use SSL for absolutely everything
-
2, secure— use SSL for rendering but don't insist on it for all SOAP calls
-
1, basic security— accept HTTP but reject any calls that might be involved in the passing of credentials
-
0, the least secure— don't use SSL at all
The Report Server redirects the browser to HTTPS as needed, depending on the value of SecureConnectionLevel.
RSWebApplication.config
The Report Manager's main configuration file is RSWebApplication.config. By default, you'll find this file in the \Program Files\Microsoft SQL Server\MSSQL_\Reporting Services\ReportManager folder. The most important thing this file contains is the URL configuration used by the Report Manager to contact the Report Server. If you change the address name of the Report Server, you'll have to come here to hook up the Report Manager. The entry you'll be looking for is
<ReportServerUrl>http://rs1.boost.net/ReportServer</ReportServerUrl>
(Replace rs1.boost.net with your own server name!)
Reporting Services BOL [16] version 1 tells you not to modify this setting.
Another entry in this file determines the maximum number of requests that can come from each user at a given point in time. With the <MaxActiveReqForOneUser> element the default is 20 concurrent requests per user. There is a similar entry in the RSReportServer.config file too.
When the Report Manager encounters an error, it can display an error message with a link off to the Microsoft website for further updated information. You can control whether your users are presented with the link to this Microsoft site by adjusting the <DisplayErrorLink> element. The default is "true."
RSReportDesigner.config
The Report Designer also has a configuration file: RSReportDesigner.config. This is located in the \Program Files\Microsoft SQL Server\80\Tools\Report Designer folder. For the most part, this file lists the custom data, designer, and render extensions. The entries that it contains are generally related to any custom extensions that you would like to run.
The Policy Configuration Files
In the Report Manager, Report Server, and Report Designer main configuration files, we studiously avoided mentioning the "policy level" keys so that we could deal with them here. There are three XML-like policy files: rspreviewpolicy.config for the Designer, rsmgr policy.config for the Report Manager, and rssrvpolicy.config for the Report Server. These configuration files determine how Reporting Services manages Code Access Security (CAS). For the most part, this is how Reporting Services implements security and trust in the CLR code assemblies that it's prepared to load and execute. We'll provide more detail on CAS when we deal with writing a custom extension and how you can declare what permission features your assembly needs—such as registry access, file system access, or network access. CAS also determines how someone installing your assembly can determine how much trust they want to give your assembly, and prevent it from doing unapproved things. This is all governed by the contents of the aforementioned policy files.
Policy Files Are Not XML Files
Policy files might look like hierarchical XML files, but they don't contain XML headers and, indeed, they certainly don't support XML comments <!- - - ->
If when you end up editing them (as we will) you enter comments or (heaven forbid) change the case on something like "Url="$CodeGen$/*"" to "Url="$CODEGEN$/*"" you can expect trouble. The problem is that when things come tumbling down, you can get messages telling you that there are fatal errors in Machine.config, which you probably haven't touched. So if you get there, you won't have to suffer the pain we did, and boy did it hurt—two days of ripping ASP.NET to bits with Machine.config, and all because of a measly XML comment we'd put in a policy file to remind us what the previous value was.
The Reporting Services Command-Line Utilities
In some cases, you might need to tune or reconfigure the Reporting Services installation using one of the command-line tools. Each of these are provided to address one or more issues that can crop up in "off-the-beaten-path" (non-typical) installations.
Activation. . rsactivate.exe
No, this is not some new-fangled license-related activation spy-ware scheme; it is a clever way to protect credentials. You don't normally need to be concerned about activation unless you are manually configuring a web farm, but you might need it to complete a problematic installation if you're using a non-default IIS configuration or if other required components are configured in a way that Setup does not expect. (This is a known issue with the first release and is high on the agenda to be addressed in future releases.) In most single-system installations, the installer takes care of activation for you, but we're still going to tell you what it is all about here so that you'll be aware of what goes on.
Reporting Services encrypts (both Windows and SQL) credentials that it uses in Reports and Data Sources. The technique is a reversible encryption using a symmetric key. Yes, it needs to be reversible—because how else is it going to be able to use those credentials if it can't work out what they are? During the installation, the Reporting Services Windows service co-operates with the Reporting Services web service and generates the symmetric keys, which can be inspected in the Report Server Database Keys table. You should be able to see at least two entries there; one for the web service and one for the Windows service. If you create a web farm, you'll see further entries in the Keys table for each Windows service and web service in the farm. Until the web service and Windows service have been activated, neither can make use of content that has encrypted credentials. Reporting Services activates (which means that it shares between all the web and Windows services involved in the web farm the symmetric key) on first use of the web service. That said, sometimes things don't quite work out for some reason, and you may have to do surgery with the Reporting Services command-line tool rsactivate.
Key Management. . rskeymgmt.exe
Microsoft provides an administrator's command-line utility, rskeymgmt.exe, to manage the symmetric key. For example, it's possible to use the rskeymgmt tool to back up the symmetric key to an encrypted file. To achieve this, rskeymgmt enlists the help of the Windows Reporting Service—so you have to make sure that the service and the SQL Server are both running. You can store the 52-byte backup key file on floppy or other removable media. Don't forget to ensure you also securely retain the password you use to encrypt the file—otherwise it's all a bit pointless.
You can also use rskeymgmt.exe to rip out all encrypted content from the Report Server by calling rskeymgmt.exe –d. Just before you do, be aware that this not only removes each encrypted copy of the symmetric key from the Keys table, but it also removes all encrypted credentials that shared Data Sources and reports use, and you are going to have to put them all back in. Note that subscriptions retain a pointer to encrypted credentials specified for the managed report's Data Source. After you run –d (and respecify your stored credentials), you have to manually open each subscription and resave it.
To "restore" a symmetric key using rskeymgmt.exe, you call it with the "apply" parameter, -a, and supply the backup file and password you used. If you removed encrypted content using rskeymgmt.exe –d, reapplying the symmetric key from a backup will restore only the key—it can't restore the deleted credentials; they're gone forever. However, if it is your desire to only temporarily remove access to encrypted credentials, you could directly delete all rows in the SQL Server Keys table where the Client column is greater than or equal to 0. This will effectively remove the key, and as such the encrypted credentials will not be able to be unencrypted until you reapply the backup copy of the key.
Tips for rskeymgmt.exe and rsactivate.exe
We experimented quite extensively with the Reporting Service command-line utilities. One thing we found helpful (when things were a little more challenging than usual) was to restart IIS (which can be done with the command-line IISRESET) and also to restart the Report Server Windows service.
What Is rsconfig.exe?
Well, we know that the Report Server web and Windows services must access the Report Server database, and to do that these services must use some form of Windows or SQL Login credentials. Those credentials are stored in an encrypted format in an XML-like configuration file called RSReportServer.config, which you'll find in the \Program Files\Microsoft SQL Server\MSSQL\ReportingServices\ReportServer folder.
The rsconfig.exe command-line tool provides a one-way mechanism to encrypt and store any updated credentials in the configuration file. It's also used to specify credentials used for unattended processing for reports that do not use credentials. As you know, you can choose "No credentials" for a report definition or managed report's Data Source. This creates a security hole because the Report Server had to log on to the remote database server using its own credentials. This has been fixed by the introduction of a requirement for credential information—users must now run rsconfig with the –e option to specify a –u user name and –p password that the Report Server uses to log on to a remote data server.
Report Server Windows Service Polling
Scheduled Jobs, be they subscriptions or snapshots, are managed by the SQL Server Agent. However, it's the Report Server Windows service that processes these reports. On the off chance that there is some processing to do, the Report Server Windows service polls the database every 10 seconds (by default). Okay, so you might think that the Microsoft development team has taken a shortcut here, as polling instinctively feels like the wrong approach. You could be forgiven for thinking that all the Microsoft developers needed to do was to put the Windows service to sleep and wake it up with a signal. For example, by creating a signaling procedure with the COM invoking the sp_OACreate stored procedure, or with an extended procedure. That might seem simple enough, but what if the Report Server's web components are on a server that does not host the Reporting Services database? In this case, you not only have to cross process boundaries, you've got to get onto another machine. Ah, DCOM? .NET Remoting? A bespoke IP message? (What about firewalls?) Notification Services? Or MSMQ? This is more apparent if you consider the web farm scenario, in which none of the machines know about other machines in the farm. Any machine in the farm can pull an event from the database queue. Who decides which machine gets the event? What if a machine goes down? Does the controller ping them to see if they want the event? So this seemingly simple situation becomes more complicated to program and more complicated to install and troubleshoot, and the polling solution that we have for now is probably the best compromise. We agree that a pull model works best in this scenario.
However, if you don't like the idea of polling every 10 seconds, then there is something you can do about it. In the RSReportServer.config file, you can change the polling element by editing <Polling-Interval>10</PollingInterval>.