Configuring Reporting Services is a bear. Will this bear sh~t or emerge from the woods in Katmai?

Posted on by LSN Leave a comment

Things are beginning to settle down to a (hectic) pattern for me here at EC|Wise, so I hope I'll be blogging and writing more regularly again, soon.

This week at work, something that always seems to rear its ugly head when working with SQL Server Reporting Services … did it again.

I got ready to integrate RS into a Microsoft-technology-based solution and the installed instance was mis-configured.  Passive voice here because there's no one to blame.  Purely vanilla installations sometimes go awry, depending on what was on the server previously, I think.  And, hey, it gets even more exciting if SharePoint is involved. 

I will say that I've observed that the installation process is particularly prone to (ahem) infelicities if a named instance of SQL Server is involved, which it was in this case.  So, fortunately, I knew where to look. 

For those of you who face this problem (yes it's a problem, I won't say "issue", it's a BIG PROBLEM), and can't find anything to deal with it in the RS configuration GUI utilities, go to the folder with the installation of SQL Server that is hosting RS for you and check out both the ReportManager and ReportServer configuration tools: RSWebApplication.config and rsreportserver.config, respectively, in different directories.

I can't tell you exactly what you are going to find or what you will need to fix. I can tell you that becoming familiar with these files (which are thoroughly doc'd) will help you find the errant Thing Causing the Problem. 

Very often, especially with named instances, I find that Report Manager <UI> node does not work for me as configured in the installation.  You may see something like this:

    <UI>
        <ReportServerUrl></ReportServerUrl>
        <ReportServerVirtualDirectory>yada yada </ReportServerVirtualDirectory>
        <ReportBuilderTrustLevel>FullTrust</ReportBuilderTrustLevel>
    </UI>

… and you will have to change this to have nothing in the middle node and the top node properly filled out.  I was going to give exact instructions for this but I see this is actually a KB article, so I will send you there: http://support.microsoft.com/kb/922656 .

Beyond the specifics of this annoying item, consider all the ways you can have trouble integrating RS into your application's lifestyle:

  • authentication quirks, especially when multiple threads may be involved
  • FireFox rendering issues (still)
  • real difficulties with the ReportViewer control if you use master pages and an up-to-date doctype
  • ditto if you use Ajax
  • configuration challenges in IIS (see threads above, and look to your timeouts, your pools, your Anything to require tweaking)
  • … feel free to contribute your own examples.

Moving right along to the Next Great Thing 

Much as I love the product (and I really, really do love it), it is with some relief, mixed with exasperation, that I hear that the Reporting Services engine has been re-engineered in Katmai.  I can't tell you exactly where I heard it and I don't even know if it's true, because I read it in some unpublished notes from a "sneak preview" presentation, but what I heard is that Reporting Services isn't hosted in IIS.  It uses HTTP.SYS directly and leverages SQL Server's networking stack.

Once again: please don't go placing any bets based on what I just wrote. The information that we have officially, thus far, is a bit sparse. But if I had a server-side product that integrated with IIS in a way that causes as many headaches as this one does, and if I had an alternative, I know I might make this call.

So what happens to us ?

Gee. I'm sure glad I am not one of the people who has spent a great deal of time learning to handle these various configuration problems.

My RS experience has been more about how to leverage the RDL.  Sure, I've spent some time figuring out the Report Designer and its particular foibles as well, but I'm basically an output, rendering, run-time-results-concerned person.  I know the Report Designer will have changed, and the RDL schema will morph too, but we'll get there.

One thing that has been bothering me on the Designer end is the custom control I wrote for RDLDocumenter.  The concept of XMLRSDocs remains perfectly valid and I remain convinced of the value of what I'm doing, but I'm also almost 100% sure that I will re-write the custom designer control that makes it easy for you to enter custom data as you work on your RDL design.  Stay tuned.