Report to the principal's office

While school days might be over for this year, thank goodness, I want to talk a little about SharePoint and SQL Server™ Reporting Services. This is quite a popular feature with MOSS, but when IAG is in the picture, things don't always turn out well.

For those who don't know it, the SQL Server™ Reporting Services for SharePoint allows the user to display a Web Part that queries SQL and display reports. The Web Part (Report Viewer Web Part) allows the user to export to other rendering formats, do page navigation, search, print, and zoom within a report. The user can also create subscriptions and schedules, manage reports, models, and data sources. Fabulous.

The problem starts when you need to publish this to the outside world. When working with SharePoint, IAG has a special template called "SharePoint 2007 (With AAM)" that relies on Sharepoint's Alternative Access Mapping feature to perform link translation. For those not familiar with AAM, it's a component that "knows" when a page is requested from "outside" (as opposed to a request coming from a computer on the corporate network), and serves the page with the links in it translated to what is defined as the external name. When configured correctly, AAM allows for a nearly transparent integration of SharePoint with various publishing products like ISA and IAG.

So, configuring AAM is very important if we want to get SharePoint to be accessible properly, but unfortunately, SQL Server™ Reporting Services for SharePoint (a.k.a. SRSS) does not support AAM. This means that when a SRSS webpart is opened, it cannot use the AAM component to translate the links, and so it does not have access to the data and displays various error messages.

What can you do? Well, since AAM is out of the picture, the only way to get it to work is if the external links are identical to the internal links. In other words, if the SharePoint server is accessible from outside using the exact same links as internally. This is not impossible, but not very common. To do this, you would have to give the SharePoint server a hostname that makes sense (for example - https://sps is great, but https://pokmnsuyiwekjh08.local is not so great), and create a public DNS entry for the SharePoint server that will match it. For example, if your server's internal hostname is sps01, and it's a member of the domain contoso.com, then a public DNS entry would have to be made for sps01.contoso.com. The IP on that host record would be the external IP of the IAG Server. Another requirement here is that the same protocol (HTTP or HTTPS) will be used too, and that might complicate things with regards to getting the certificate to match the name. It's also important to note that in such a configuration, there's no need for link translation, as both internal and external links are the same, and so AAM does not need to be configured at all. You can read more about this in this blog: https://blogs.technet.com/edgeaccessblog/archive/2008/10/13/publishing-sharepoint-with-iag-2007-part-3-sharepoint-topologies.aspx

If you were able to pass all these hurdles, then the SRSS web parts should come to life and work just like they do externally. Good luck with your reports!