Configuring SharePoint 2010 FBA

I have not been making good acquaintance with SharePoint 2010. Time to strengthen my relationship with my old pal…

Just few days back I were tasked to estimate some effort in building a simple extranet website. SharePoint 2010 is one of the option considered. But the user login database has to be separate from the organisation’s AD. Therefore, Form Based Authentication will be required. Now, setting up FBA in in SharePoint 2010 is different from MOSS 2007. So a refresh on that skill is required, by trying it out myself on my SharePoint 2010 test servers.

First step is to start with getting FBA to work in the most simplest form possible. That means making use of the good old ASP.NET Membership database which comes with .NET 2.0. That part of the work are still the same, but the similarity ends there. After reading a few blogs that doesn’t help me much, I found this blog entry from Donal Conlon, which provided me the best step-by-step I saw so far, which allow me to successfully get the FBA work on my SharePoint test servers. Thanks a lot!

Also, I found that CodePlex has some webparts for FBA user management.

And, some more in-depth Membership, Role and Profile stuff from 4GuysFromRolla, which provide some good foundation refresh for me as well.

Prevent SSRS Parameter Auto Postback, again…

In my last entry (wow, that was over a year ago...), I was troubleshooting some SSRS parameter post back bug that was never fixed in SSRS 2005, and manage to worked around it.

In my new assignment, me and my team are building SSRS 2008 R2 reports. The new version of SSRS 2008 R2 now has better control on whether changing a parameter causes postbacks to the server or not. This can be set at per report parameter level, via the advanced properties:

However, long time enemy came back again to haunt me and my team. Even if the above option were set to Never refresh, the postback is still happening. After some pocking around on and off for several days, finally we found out the reason.

We discovered that some other reports which has some parameters that does not have default values set, does not perform postback when its value were modified. The default values were set directly by typing in the default value, as per below screenshot.

Question is, should we enter the “Label” name here, or the “Value” value here? (Label is what the user sees, Value is what is used as the parameter value at the back to pass into SELECT statement). Anyway, it doesn’t matter. As long as you set a default value like this, it will perform a postback.

To solve this problem, we can up with a workaround (yes, another one. When will MS solve this once and for all?). We create a Dataset to return desired single default value (e.g. DefaultCountry Dataset). The Dataset doesn’t even need to query the database, as long as it returns the default value that you want (e.g. SELECT ‘MY’ as CountryName). Then, use it to set the value to the Parameter as the default value.

With that, no more auto postbacks when selecting report parameters.