SQL Server 2008: Reporting Services Configuration Changes

One of the benefits of SQL Server 2008 Reporting Services is the removal of the dependency on IIS. This architectural change is huge because it opens the door to Reporting Services for those IT shops that wouldn’t allow installations of SQL Server components on a Web server. Plus it removes one more layer of potential configuration problems to troubleshoot when connectivity issues arise. This architectural change also affects the steps we normally follow to configure the server. So I decided today to do a little exploring to see what’s different.


Now, it’s important to note the Juy CTP doesn’t provide the complete configuration and management experience, because after all Katmai is still a work in progress. But enough is there for me to start poking on the parts to see what’s new and different. After installing Katmai on a Windows Server 2003 server, the Reporting Services Windows service is running under the Network Service account. I have not installed IIS (and won’t) but the default installation sets up my report server databases so I should be good to go. No dependency on IIS means I don’t have to set up application pool identities. As an initial test, I try to access Report Manager using the standard URL (localhost/reports) and see that it displays the Home page so everything is working under the default configuration. So far, so good.


Next, I want to peruse the Reporting Services Configuration to see what the current settings are, so I open the configuration tool and connect to the local report server instance. I can immediately see a difference in the configuration tool layout (including the absence of little green or red buttons to indicate whether that page has been configured):



I only need to have one service account configured for the Reporting Services service, rather than configure one for its Windows service and another for the Web service. On the Service Account page of the configuration tool, I can change to a different built-in account (which I don’t recommend) or to a domain account (which I do recommend).


Although IIS is no longer required, you still need to configure an IP address, TCP port, a URL, a virtual directory, and optionally an SSL certificate to create a URL reservation. A URL reservation is the mechanism by which http.sys – the operating system API required to run the Web service without IIS – allows users to access a specific URL. You can configure these settings on the Web Service URL page. An Advanced button on this page displays a dialog box that I can use to configure a variety of IP addresses, ports, host headers, and SSL ports if necessary. (I’ll delve into your options with URL reservations in more detail in a future blog.) When you apply the configuration settings, the applicable URL reservations are created.  If you’re curious about how http.sys enables applications to run without IIS, see this article from MSDN Magazine.


The Database page of the configuration tool does what it always did. You can create a new report server database or connect the current report server instance to a different existing report server database or even switch to a different mode (native or SharePoint integrated). The main thing different here is the interface. Configuring the database now is a series of pages in a wizard. I’m not sure whether this is a good thing or not – no opinion, really – but for one thing. One you walk through the wizard, there’s no option to save the database script. I hope this is fixed in a future CTP as I have a current client that always has one group build the report server and the database needs to be built on a separate server to which that server-building group doesn’t have permissions needed to execute the script. So we generate the script and hand it off to the DBAs. This omission is pretty big in the product, but as I mentioned earlier, Katmai is a work in a progress. I’ll keep my eye on this one.


The next page is the Report Manager URL which you use to set the virtual directory for, well, Report Manager. I’m not sure why this isn’t positioned after the page for the Web Service URL. It doesn’t matter in the grand scheme, but it feels out of place here to me. This page also includes an Advanced button allowing you to set up IP address, ports, host headers, and SSL ports if needed.


The Email Settings page hasn’t changed from SQL Server 2005’s configuration tool. All it does is allow you to put in a sender address and set up a SMTP server, so I wouldn’t expect a change here. However, if I could submit a wish, it would be nice to have other configurable settings for SMTP on this page. Currently in SQL Server 2005 – and it appears this won’t change in Katmai – you have to change the configuration file for important properties like SendUsing or SMTPAuthenticate (see RSReportServer Configuration file for other SMTP-related properties).


The Execution Account settings page hasn’t changed either, but I can live with that. There’s nothing I would change. J Similarly, the Encryption Keys page hasn’t changed functionally, but the UI has been modified to include test to better explain each option (Backup, Restore, Change, Delete).

The Scale-out Deployment page is the new name for SQL Server 2005’s Initialization page and, in my opinion, is a better name for it. I don’t currently have an environment set up to test setting up a report server farm, so I can’t comment on what differences you might find here, but I would not expect much different from the SQL Server 2005 experience. If I find otherwise in the future, I’ll blog about it.

Setting the authentication method no longer occurs in IIS, obviously. Now authentication configuration happens only in configuration files which I’ll be exploring in much greater detail in a forthcoming blog (because it’s near and dear to my heart at the moment since I’m speaking on SSRS and authentication configuration next week at SQL Server Magazine Connections – I need to find out what changes in that presentation once Katmai releases!). For now, you should be aware the default configuration of Reporting Services requires users to have a Windows domain account. Authentication is set to Negotiate, much like IIS, which will use Kerberos if it’s enabled or NTLM if Kerberos is not enabled. You can force Kerberos only or NTLM only by changing the report server configuration. Alternatively, you can use Basic authentication (although this feature will come in a future CTP) or Anonymous authentication if you’re adding in custom security like forms authentication. Note that the report server will reject anonymous authentication unless you are explicitly using custom security. Also, Single Sign-On (SSO), Passport, and Digest authentication will not be supported. More to come soon! –Stacia

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.