Reporting Services Really Hates Alternatives

I was aghast to discover this week that SSRS integrated with SharePoint doesn't support alternate access mappings, and the problem persists even in SQL Server 2008. This puzzles me, is AAM really that complicated that even the SQL team throws up their hands in despair?

My current project consists of several FBA enabled web applications. There are five zones for each web application, mainly to handle a problem where the client had given users many different links to the sites, and we are trying to cover all the possibilities. The zones looks something like this:

Internal URL                            Zone 
http://myportal                        Default
http://internal.myportal.com    Intranet 
https://client.myportal.com      Internet
http://ext.myportal.com           Internet
http://client.myportal.com        Internet


You will notice that the Default zone means nothing to both my active directory and FBA users - they are using the Intranet and Internet zone urls to access the site. Reporting Services, however, is only interested in my default zone. So, when attempting to publish a report, or edit a report, or click on a report to view it, I receive the following error:

"The specified path refers to a SharePoint zone that is not supported. The default zone path must be used. --> Microsoft.ReportingServices.Diagnostics.Utilities.SecurityZoneNotSupportedException"

I can upload and modify reports if I use the default zone url, but that is not a very good solution for my client editors who will need to be able to work with the reports. However, for client viewers, there is a work around of sorts using the SQL Server Reporting Services Report Viewer webpart.

If I add the webpart to a SharePoint page, and then link to my published report (while on the default url) the SSRS Report Viewer webpart will then render the reports for users on any of my zones. This is good news, as now I know that I can edit my default zone to be my Intranet zone, allowing my client's windows users to be able to edit reports as needed, while my client FBA users can still view the reports from the Internet zone URLs.

Note that so far, I have only found the SSRS Report View webpart to work in this manner. Linking to the reports via a links webpart, or Content Editor webpart will not produce the same results.

Custom Content Type Loses its Mind

Been working on a MOSS project that makes extensive use of InfoPath 2003 (gag) forms. One of the tricks with these if that you can publish the 03 forms as custom content types if you do so from InfoPath 2007. We used this "trick" to publish a couple forms and it worked well. Now I'm coming back in to do some modifications, and the fun begins.

While attempted to create a new site in the SharePoint hierarchy, the following error message occurred: "a duplicate name "BusinessCase" was found" and the site creation would fail. It turned out that when I had last updated the custom content type, I had assigned it a site column that conflicted with another site column. The "BusinessCase" column had been redeployed as a type "Multiple lines of text" from "Single line of text" and when I deployed the new content type, the two columns conflicted with each other on the form library.

The fix for this was to republish the content type while only selecting the "BusinessCase" column with the "Multiple lines of text" type, and then removing the site column for the "BusinessCase" with the "Single line of text" type. And the moral to the story is to really watch those site columns when you publish multiple times.