- 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
Installing Reporting Services in a Non-Default Website
The ordinary installation wizard installs Reporting Services as two virtual directories to the Default website. If you're installing to a development system on Windows XP, you don't have anything other than the Default website anyway. However, if you're installing to a server operating system such as Windows 2000 Server or Windows Server 2003, you can manually create a completely separate website on the server just for Reporting Services. This certainly makes it easier to manage, as it is separated from the Default website, and it enables you to do things like stop and start such a website independently of any others your server may be hosting. It also permits you to install an SSL certificate specifically for the Reporting Services website.
If you are using Windows 2000 Server, you'll have to perform a normal install to the Default website, and subsequently create a completely new and empty website (not virtual directory), sign it with an SSL certificate (not mandatory but it is if you want to be one of our friends), and then create two virtual directories: one called "Reports" and the other "ReportServer." At this point, you can compare all the properties of the Reports and ReportServer virtual directories and copy them over—one property at a time—to the new directories. You haven't quite finished by this stage as you must also install the ASP.NET 1.1 client-side scripts to your website by executing aspnet_regiis.exe from the correct .NET framework and with the correct parameter. At the command prompt, navigate to %windir%\Microsoft.NET\Framework\v1.1.4322 and execute aspnet_regiis –c. Once all of this is done, you can now remove the Reports and ReportServer virtual directories on the Default website. And finally, you'll need to change the URLs in the RSWebApplication.config (<ReportServerUrl>) and RSReportServer.config (<UrlRoot>) files to reflect the URL where you are putting the virtual directories. This is why we told you about those elements earlier!
Windows Server 2003 has a nice "back door" route that can simplify some of the steps. Perform an ordinary installation of Reporting Services to the Default website. Next, take backups of the Reports and ReportServer virtual directories by right-clicking on each of them, and then under All Tasks select Save configuration to a file. You can then go to your new website, and under New select New virtual directory from file, and use each of the backups to create new virtual directories. You can then remove the virtual directories from the Default website. Yes, you still need to execute aspnet_regiis –c as described above, and you still need to edit the RSWebApplication.config and RSReportServer.config files.
Installation Log Files
During installation, the install wizard records all of its actions and checks to log files it maintains in a file called RSStp_.cab in \Microsoft SQL Server\80\RS Setup Bootstrap\Log. In case there were any confusing setup issues or failure points that baffled you, these log files will be a lot more helpful and humanly readable to the average administrator than BSOD [15] dumps are.
Runtime Trace Log Files
There are three runtime trace log files that are created by default, and they all live in \Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles. They all take the name form of <logfilename><awkward US timestamp>.log. Okay, why is this so awkward? Well, it seems to be <month number>_<day of Month number>_<Year>_<Hours>_<Minutes>_<Seconds>.
Here's an example: ReportServer__01_02_2004_18_50_47.log. It would have been ever so convenient if instead an ISO date format had been used, such as yyyymmddhhnnssReportServer.log. Such a format would not have confused Europeans and Antipodeans and also would have more easily permitted sorting in the explorer and scripting programs. . . Ah well, that aside you need to know what these log files trace, how you can configure how much detail they record, and what automated maintenance is performed on them.
The logs are:
-
Report Server web service— ReportServer<datetime>.log See the <RSTrace> element in the web.config file in \Microsoft SQL Server\MSSQL\Reporting Services\ReportServer
-
Report Manager— ReportServerWebApp<datetime>.log See the <RSTrace> element in the web.config file in \Microsoft SQL Server\<instance>\Reporting Services\ReportManager
-
Report Server Windows Service— <datetime>.log See <RSTrace> in ReportingServicesService.exe.config in \Microsoft SQL Server\<instance>\Reporting Services\Bin
Within the various web.config files, you'll notice that you can configure the log filename, file size, and retention times. You'll also find a peer element to <RSTrace> called <system.diagnostics> and within that an element <switches> with an attribute of DefaultTraceSwitch set to a default of 3. While the file itself documents in a comment possible values of <!-- 1 = error, 2 = warning, 3 = info, 4 = verbose -->, you can switch off logging entirely by setting this to 0.
If you are troubleshooting, it can be quite handy to attach a debugger to the aspnet_wp.exe process as new entries are echoed to the debug output window as well as written to the file. If you've not done this before, we have a video demo for you to watch.