I’m sitting next to the window, and after about an hour into the flight, I get thirsty and pull the bottle out of the pocket in front of me. I flip up the straw to get a drink and water starts spraying out all over the window and wall next to me. It looked similar to holding your finger over a water hose!!!!

After a couple seconds staring at the water spraying all over the side of the plane, I realized it would be a good idea to close the straw and stop the water works. The window and wall next to me was pretty soaked at this point. I look to my right to see if the woman next to me had seen the water show to find her staring at me with water all over her face and arm! I guess it was bouncing off the wall with pretty good force, or she got in the line of fire while I was closing the straw on the bottle. She had a look of disbelief on her face, and says to me in a deadpan voice, “I guess there was a lot of pressure in that bottle”. I cracked up laughing while trying to apologize, and she was very understanding once I told her it was only water and nothing sticky.

Lesson learned. On my way home, I bought a bottle of water at the airport with a screw on cap.

Looking at the list in SharePoint Designer would show the following in the forms section:

The external content type has all the types required for the external list to support creating and editing items, so we were initially at a loss for why the warnings and the resulting list missing the forms:

At this point, if you are using the default Diagnostic Logging settings, you’ll see the following entries to line up with the error dialog displayed in SharePoint Designer. 

10/30/2011 20:03:16.17     w3wp.exe (0x1434)                           0x189C    SharePoint Foundation             General                           fvo2    Medium     
VLPROV: Data source does not support Create, no NewForm.aspx page is being provisioned for list with ID 'e5d7abe6-84f4-4a2d-b2bc-bff5c4b9f00c', URL '/Lists/MYDB People List'.    72e37591-e309-452e-9feb-19ec93841cfc

10/30/2011 20:03:16.17     w3wp.exe (0x1434)                           0x189C    SharePoint Foundation             General                           fvo3    Medium     
VLPROV: Data source does not support Update, no EditForm.aspx page is being provisioned for list with ID 'e5d7abe6-84f4-4a2d-b2bc-bff5c4b9f00c', URL '/Lists/MYDB People List'.    72e37591-e309-452e-9feb-19ec93841cfc

Once you enable Verbose logging for the SharePoint Foundation - General category, you’ll get more details that start to point to the root cause for the behavior :

10/30/2011 20:05:14.19     w3wp.exe (0x1434)                           0x0230    SharePoint Foundation             General                           f9ca    Verbose    
Updater 'PeopleEdit' skipped because it could not be determined to be in the ViewGroup induced by SpecificFinder 'PeopleGetOne'.    276e6ba8-e00d-4ef9-b1f9-023321f3832a

10/30/2011 20:05:14.19     w3wp.exe (0x1434)                           0x0230    SharePoint Foundation             General                           f9c8    Verbose    
Creator 'PeopleCreate' skipped because it could not be determined to be in the ViewGroup induced by SpecificFinder 'PeopleGetOne'.    276e6ba8-e00d-4ef9-b1f9-023321f3832a

Mapping up the BCS specific references to SharePoint Designer, the SpecificFinder is your Read Item method on your External Content Type. The ViewGroup is the list of fields returned by the SpecificFinder. When SharePoint Designer is building out the external list, it is using the input and output parameters for the stored procedures to line up the columns. If the columns returned from the Read Item command do not match the input parameters for the Create and Update commands, the forms are not generated.  For example, given the following table named People:

The Read Item stored procedure named PeopleGetOne may look like:

The PeopleEdit stored procedure may look like the following:

Notice that PeopleGetOne returns a column named ID, but the PeopleEdit stored procedure takes in a parameter named @PersonID. This is when you hit this problem. In order to have SharePoint Designer create a New Form, you would need to change the PeopleEdit’s parameter to be @ID instead of @PersonID.

Select Datalength([ItemData]) as ItemDataLength, *
From Sessions

In my test, I had a 22MB WMV file I was attaching to my form. Before the file was attached, the ItemDataLength was close to 0.  After attaching the the file, the ItemDataLength was a little over 22MB. Saving the form resulted in the ItemDataLength,dropping close to 0. Transient data…confirmed.

Next up, what areas are impacted by this work? In order for the session data to be persisted in the database, the data is serialized. This process will use up CPU on the machine handling the web requests. The more data you store, the longer the CPU will be hit for a given request. Once the data is serialized, it is written to the State Service database.  With a larger session, and a significant number of users, you could see quite a bit of churn on the disks hosting the State Service database along with your CPU usage.

With the above information there are a couple concerns:

• How big will the State Service database get?
• Will the amount of traffic to the State Service database impact other databases on the same set of disks?
• Will the spike in CPU while serializing the files negatively affect the performance of the farm?

Unfortunately, there is no magic number for this scenario, the behavior will depend on your specific scenario and environment. To fully understand the impact, you would want to start out with the following:

• What is the size of file attachments users are planning on uploading?
• How many users are planning to do this type of work?
• How often users will be performing this work?
• How long do users typically leave the form open?

Once you understand the above information, you’ll start getting an idea of the general impact. For example, if you have 1-2 users uploading a large file on an under-utilized farm at the same time, you probably won’t notice the impact. However, if you have a high volume of InfoPath form usage with large file attachments, you will notice the CPU hit. Any databases hosted on the same disks as the state service will likely notice as well.

The only way to find out what the potential impact will be is to test your scenario and analyze the results. Be sure to append your results to your current farm performance to ensure you are below your thresholds for performance.  For example, if the CPU on the web servers is running around 5%, and testing shows an increase of 10-15%, you probably don’t have much to worry about.  If testing shows a 60-70% increase, you would probably have reason for concern.

We were able to track this down to how the RSS Feed requests are cached. The RSS Viewer Web Part leverages the XmlUrlDataSource class to call the location for the RSS Feed.  This class is also responsible for handling the cache of the response from the RSS Feed. The reason this is important, is because this class creates a cache key in the following format:

      URL + tab + Name

This would indicate that for each RSS Viewer Web Part, if you set the cache for 24 hours, you will end up with a request for each distinct user back to the RSS Feed.  For example, if you have 1,000 distinct users accessing a page with the RSS Viewer web part, you would see 1,000 requests to the RSS Feed location.

To validate what I was finding, I put together a Visual Web Part that dumps out the keys in the ASP.Net Cache. This cannot be a sandboxed solution due to the code needing to execute in the application pool hosting ASP.Net, and it’s associated cache.

ASCX file has the following:

<asp:BulletedList ID=”BulletedList1” runat=”server”/>

Page load in the .cs file has the following:

   1: ArrayList keys = new ArrayList();

   2:  

   3: foreach(DictionaryEntry cacheEntry in HttpRuntime.Cache)

   4: {

   5:     keys.Add(cacheEntry.Key);

   6: }

   7:  

   8: BulletedList1.DataSource = keys;

   9: BulletedList1.DataBind();

I then added an RSS Viewer Web Part to a page pointing to an anonymous feed on TechNet. Then added my visual web part.  I logged into SharePoint with two separate accounts, and the Visual Web Part output shows two separate cache entries.  In my case, I have a domain with my account, as well as an account for Bob Smith. The cache has the following two entries:

http://www.microsoft.com/feeds/technet/en-us/TechNetNewsFeed.xml     Bob Smith

http://www.microsoft.com/feeds/technet/en-us/TechNetNewsFeed.xml     Jerry Orman

• Install and Deploy a farm level solution
• Activate a web application scoped feature
• Activate a site collection scoped feature

The tricky part with scripting this occurs when the solution is deployed [Install-SPSolution cmdlet].  The script needs to wait for the deployment to finish before activating the features.  Without waiting, the script will immediately continue, and try to activate the features that have not been deployed yet. That means evil red text will appear complaining about features not existing in the farm.

Here’s a copy of the script.  There are some things hard coded in this sample.  The name of the solution package on the Install-SPSolution line, and the Feature ID’s on the Enable-SPFeature lines.

   1: param($wspPath, $url)

   2:  

   3: "`r`nBegin : Installing and deploying solution package from $wspPath"

   4:  

   5:  

   6:     "`r`n`tBegin : Adding Solution to farm solution store"

   7:  

   8:         #Add the WSP to the solution store

   9:         Add-SPSolution "$wspPath" | Out-Null

  10:  

  11:     "`tEnd : Adding Solution to farm solution store"

  12:  

  13:  

  14:     "`r`n`tBegin : Deployng the solution package"

  15:  

  16:         #Deploy the solution

  17:         Install-SPSolution MySolutionPackage.wsp -GacDeployment

  18:  

  19:         #Wait for the solution to deploy prior to continuing

  20:         while((Get-SPSolution MySolutionPackage.wsp).Deployed -eq $false)

  21:         {

  22:             Start-Sleep -seconds 30

  23:         }

  24:  

  25:     "`tEnd : Deployng the solution package"

  26:  

  27:  

  28:  

  29:     "`r`n`tBegin : Enabling Web Application Feature"

  30:  

  31:         #Enable Web Application Feature

  32:         Enable-SPFeature 316883d1-01f8-4474-8e0d-e5e32cecfc2c -url $url -force

  33:  

  34:     "`tEnd : Enabling Web Application Feature"

  35:  

  36:  

  37:     "`r`n`tBegin : Enabling Site Collection Feature"

  38:  

  39:         #Enable Site Collection Feature

  40:         Enable-SPFeature b47afc1d-3369-4399-9fde-15ff0ade7316 -url $url -force

  41:  

  42:     "`tEnd : Enabling Site Collection Feature"

  43:  

  44:     #"`tBegin : Setting Web Application Properties"

  45:     #

  46:     #    #Set the property "MyProperty"

  47:     #    Get-SPWebApplication $url | %{$_.Properties["MyProperty"] = "Some Value"; $_.Update()}

  48:     #    

  49:     #    #Retrieve the property "MyProperty"

  50:     #    Get-SPWebApplication $url | %{$_.Properties["MyProperty"] }

  51:     #

  52:     #"`tEnd : Setting Web Application Properties"

  53:  

  54:  

  55: "`r`nEnd : Installing and deploying solution package from $wspPath`r`n"

In my test farm, when a user named BobSmith browses, he sees the following:

If bobsmith clicks on the link for http://teams.jormanvmas.com, he is able to browse through the folder structure of the site collection.  If he ever finds a report [RDL file], he could click on the RDL file and the report would try to render. Users may also discover URLs that they didn’t know existed, and the person that owns the site may not want them to know the site exists.

For example, in the above output, BobSmith sees a link for http://teams.jormanvmas.com/sites/cqwp.  However, if he clicks that link he gets:

If he browses the URL directly in the browser, as opposed to going through Report Server, he gets the following:

This is odd, the Report Server page should return sites that BobSmith has permissions to, but for some reason, he’s unable to browse the URL returned.  To track down why this is occurring, I turned to the Debugging Tools for Windows.  I attached windbg to ReportingServicesService.exe, and broke in on managed exceptions [command : sxe clr].  This revealed that Report Services has an HttpHandler, that eventually calls OpenWeb for each site collection in the farm.

Microsoft.SharePoint.Library.SPRequest.OpenWeb(…)
Microsoft.SharePoint.SPWeb.InitWeb()
Microsoft.SharePoint.SPWeb.get_Description()
Microsoft.ReportingServices.SharePoint.Objects.RSSPImpWeb.get_Description()
Microsoft.ReportingServices.SharePoint.Utilities.CatalogItemUtilities.CreateCatalogItem(Microsoft.ReportingServices.SharePoint.ObjectModel.RSSPWeb)
Microsoft.ReportingServices.SharePoint.Server.SharePointDBInterface.InternalFindObjects(…)
Microsoft.ReportingServices.SharePoint.Server.SharePointDBInterface.FindObjectsNonRecursive(…)
Microsoft.ReportingServices.Library.ListChildrenAction.PerformActionNow()
Microsoft.ReportingServices.Library.RSSoapAction`1[[System.__Canon, mscorlib]].Execute()
Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.RenderFolder()
Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.RenderPageContent()
Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.RenderPage()
Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.ProcessRequest(System.Web.HttpContext)

I confirmed that when this call fails, the link will not render.  This means that BobSmith’s account is able to call OpenWeb on the Site, even though BobSmith is unable to browse the site. I then browsed the CQWP site as another account that has full access, and used the Check Permissions functionality to determine what permissions BobSmith has on the site.  This showed that BobSmith has Limited Access, which was granted via the Style Resource Readers group.

I then checked the Limited Access Permission Set and found that the following are granted:

• View Application Pages  -  View forms, views, and application pages. Enumerate lists.
• Browse User Information  -  View information about users of the Web site.
• Use Remote Interfaces  -  Use SOAP, Web DAV, the Client Object Model or SharePoint Designer interfaces to access the Web site. 
• Use Client Integration Features  -  Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes. 
• Open  -  Allows users to open a Web site, list, or folder in order to access items inside that container.

There we are, the link shows up because BobSmith has Open permissions, which is enough for Reporting Server to render the link.  I wanted to confirm why BobSmith was in the Style Resource Readers group. This group is added by the Publishing Features, and the group contains the NT Authority\Authenticated Users group.  For some information on Style Resource Readers group and the authenticated users group, see the following article http://technet.microsoft.com/en-us/library/cc262690.aspx

HTTPModule

From the above, we know that any site with the Publishing Features enabled will show up in the list of links when a user browses /ReportServer/, and if a user has read access, they can probe into the directory structure of your site.  There’s not an out of the box way to disable that view, so if you want to disable it, you’re looking at writing some code. I put together an HttpModule that will block incoming requests that will render that view.  The trick is that the Report Viewer control also makes requests to the /ReportServer URL to render reports, so you can’t block all requests.  I went with the following to determine if a request should be blocked:

• Request has rs:Command QueryString set to ListChildren

OR

• There is not an rs:Command and the request is to /ReportServer or /ReportServer/

The first scenario covers users sending a ListChildren command to the ReportServer.  The second scenario covers a user sending a GET to the ReportServer url in a browser, as well as users sending a POST request via PowerShell or some other language to the root.  These filters will still allow other rs:Command values as well as calls to the ASMX web services in the /ReportServer URL.

Here’s the code for a sample HttpModule.  There are 3 methods:

• Init – hook up the BeginRequest event to your Application_BeginRequest method
• Application_BeginRequest – This is where the URL is checked out
• FailRequest – This clears and ends the response

 1: using System;

 2: using System.Web;

 3:  

 4: /// <summary>

 5: /// HttpModule that checks incoming URLs and blocks HTTP GET requests to /ReportServer or /ReportServer/. This

 6: /// prevents users from browsing the Report Server URL to click through links to try and find reports.

 7: /// 

 8: ///

 9: /// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF

 10: /// ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO

 11: /// THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A

 12: /// PARTICULAR PURPOSE.

 13: /// </summary>

 14: /// 

 15:  

 16: namespace Sample.SharePoint.ReportServer

 17: {

 18:     public class ReportServerBlocker : IHttpModule

 19:     {

 20:         public void ReportServer()

 21:         {

 22:         }

 23:  

 24:         public void Dispose()

 25:         {

 26:             

 27:         }

 28:  

 29:         //When the module is initialized, hook the BeginRequest event

 30:         public void Init(HttpApplication context)

 31:         {

 32:             context.BeginRequest += new EventHandler(this.Application_BeginRequest);

 33:         }

 34:  

 35:         //When a new request comes in, check the URL. If the request is a GET request to /ReportServer or /ReportServer/, then clear and end the response.

 36:         private void Application_BeginRequest(Object source, EventArgs e)

 37:         {

 38:             HttpApplication application = (HttpApplication)source;

 39:             HttpContext context = application.Context;

 40:  

 41:             //Pull the HttpMethod and the URL from the request

 42:             string httpMethod = context.Request.HttpMethod.ToLower();

 43:             string path = context.Request.Url.AbsolutePath.ToLower();

 44:  

 45:             //Pull the rs:Command querystring

 46:             string command = context.Request.QueryString["rs:Command"];

 47:  

 48:             //if the rs:Command querystring has ListChildren, fail out the request

 49:             if (command != null)

 50:             {

 51:                 if (command.ToLower() == "listchildren")

 52:                 {

 53:                     FailRequest(context);

 54:                 }

 55:                 else

 56:                 {

 57:                     return;

 58:                 }

 59:             }

 60:             //if there is no querystring, and the request is to /reportserver or /reportserver/, fail the request

 61:             else if (command == null && (path.EndsWith("reportserver") || path.EndsWith("reportserver/")))

 62:             {

 63:                 FailRequest(context);

 64:             }            

 65:         }

 66:  

 67:         private void FailRequest(HttpContext context)

 68:         {

 69:             context.Response.Clear();

 70:             context.Response.End();

 71:         }

 72:  

 73:     }

 74: }

Once you build out the HttpModule, you add it to the <httpModules> section of the web.config for Report Server, then restart the SQL Server Reporting Services service.  By default, the web.config is found at :

C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\web.config

For example, if you build the above code into an assembly named Sample.SharePoint.ReportServer.dll, you would add the following to the <httpModules> section of the web.config [after the <clear/> tag]:

<add name="ReportViewerBlocker"
     type="Sample.SharePoint.ReportServer.ReportServerBlocker,
     Sample.SharePoint.ReportServer,
     Version=1.0.0.0, Culture=neutral,
     PublicKeyToken=263da74b91424116" />

In order to tackle this scenario, we created a PowerShell script that will send an web request with the appropriate cookie to allow for validating multiple SSL terminated URLs against all the machines in a farm.  In order to do the test, you need a few pieces of information:

• The URLs to test.
• The name of the cookie used for sticky sessions.  You’ll typically have one cookie name per unique URL
• The value of the cookie.  You’ll typically have one cookie value per server handling requests

The key to being able to pull this off via script is to us an HttpWebRequest object.  This object allows you to add cookies to a request, as well as get the response status code and the data contained in the response.  There is a sample PowerShell script attached to the post that will perform the test.  In general, the script loops through the URL’s, then loops through each server and validates the response from each server.  If the URL is considered a failure, the request is retried up to a total of 5 times.  If all the retries fail, the URL-server combo is added to a collection of bad servers.  The bad servers can then be sent via email, or you could do some remediation, like recycle an application pool. 

Here’s a rundown of the major parts of the script:

• Storage for the required data is done with hashtables.  This will need to be updated to match your environment.  The script can currently handle testing two environments.  In my example, I have a set of values for a production environment, and a set of values for a test environment.
  
• $prodServers  -  Associate a server name with a cookie value.
• $prodCookieNames  -  Associates the URL to a cookie name.
• $testServers and $testCookieNames  -  the same as above, but for a test environment.

   1: #Associate a servername to a cookie value

   2: $prodServers = @{"ServerName01" = "0000000001.20480.0000";

   3:                     "ServerName02" = "0000000002.20480.0000";

   4:                     "ServerName03" = "0000000003.20480.0000";

   5:                     "ServerName04" = "0000000004.20480.0000";}

   6:                     

   7:  

   8: #Associate a URL to a cookie name

   9: $prodCookieNames = @{    "https://teams.contoso.com" = "BIGipServerpl_teams_80"; 

  10:                         "https://mysite.contoso.com" = "BIGipServerpl_sp_mysite.contoso.com_80"; 

  11:                         "http://apps.contoso.com" = "BIGipServerpl_sp_apps.contoso.com_80"}

  12:  

• TestUrl function.  This function makes the web request, then does an initial test of the status code and content length.  The content length check was to rule out requests that don’t fit our failure content.  We were testing for the error response described here, as any status code 400 or higher.
  
• TestResponse function.  This function runs validation on the response from TestUrl.  In order to test for the HTML for the “An unexpected error has occurred.”, I replace the carriage return/line feeds, tabs and spaces, then do a match against the response for the text “<body>anunexpectederrorhasoccurred.</body>”.  I also check if the response is empty which should only occur when a response status code is 400 or larger.
  
• SendEmail function.  This function sends email with the server-URL combinations that failed.

As it turns out, SharePoint only uses the SafeControl entries when rendering customized pages.  When the master page is deployed using the solution and a feature, the file is uncustomized at that point, and the control will render just fine.  Once you touch the page with SharePoint Designer, or in this case use export/import on a site, the master page gets customized and the SafeControl entries are in play, resulting in the site failing to render.  Here’s some documentation for your perusal, highlighting was added to point out the important bits.

http://msdn.microsoft.com/en-us/library/bb964680.aspx

“Safe Controls

Safe mode processing goes a step beyond protecting against in-line script by also considering what controls a user might place on a customized page. For example, imagine a scenario in which a site administrator tries to mount an attack by adding a server-side control to a site page and parameterizing it in a certain way. Safe mode allows the farm administrator to determine which controls can be used in pages that are processed in safe mode.

Customized pages can only contain server-side controls that are explicitly registered as safe controls. Registering a control as a safe control is accomplished by adding a SafeControl entry into the web.config file for the hosting Web application.”

Just for completeness, here’s the error and a screenshot of what you get when the SafeControl entry is missing.

“The base type ‘TestControl.DemoMaster’ is not allowed for this page. The type is not registered as safe.”

Connection failed.
Unable to connect to the server that is specified in the URL, ‘http://teams.jormanvmas.com/’.
Make sure that the server is running, the URL is correct, and you have permission to use the server.

I was on my lab environment, so I asked myself if I have permission to use the server.  I told myself I can use the server, but it still didn’t work :-)  I started digging into things, and I have the following configuration:

• Web application is configured for Kerberos based claims. 

• SQL Server Reporting services is configured for Windows Authentication in Central Admin. 

When you have SharePoint 2010 and Reporting Services setup this way, reporting services should fall back to using Trusted Account for the Authentication Mode.  In this mode, Reporting Services will connect using the application pool account configured for the SharePoint web application.  There was a bug in the initial release of the Reporting Services add-in, that installs with the SharePoint 2010 Prerequisite Installer, in which Reporting Services tries to delegate your claims credentials to Reporting Services.  You can tell if you are hitting this by checking the Reporting Services log.  When you get the above error in Report Builder, you will see the following entry in the Report Server log:

library!ReportServer_0-1!1784!07/26/2011-19:02:01:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: , Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: The permissions granted to user 'i:0#.w|jormanvmas\jerry' are insufficient for performing this operation.;

The interesting piece is that the user in the log entry is a claims identity, when it should be the application pool account for the web application. If you really dig into the issue and attach Windbg.exe to the ReportingServicesService.exe process, the stack when the exception is thrown looks like the following.  The function at the top of the stack is actually comparing the account name that was received against the application pool accounts configured on the web applications in SharePoint.  If the accounts don’t match, you get the above error logged.

0:017> !clrstack
Microsoft.ReportingServices.SharePoint.Server.SharePointTrustedUserVerification.CheckProcessAccount(Microsoft.ReportingServices.SharePoint.Administration.ObjectModel.RSSPWebApplicationCollection, System.String)
Microsoft.ReportingServices.SharePoint.Server.SharePointTrustedUserVerification.VerifyTrustedUserAccessToWssContent(System.String, System.String, System.String)
Microsoft.ReportingServices.Library.TrustedAccountVerification.VerifyTrustedAccountAccess(System.String, System.String)
Microsoft.ReportingServices.WebServer.WebServiceHelper.ExtractWebUserInfo(Microsoft.ReportingServices.WebServer.TrustedUserHeader, System.String)
Microsoft.ReportingServices.WebServer.RsSoapBase.Init(System.String, Boolean)
Microsoft.ReportingServices.WebServer.ReportingService2010.Initialize(System.String, Boolean)
Microsoft.ReportingServices.WebServer.ReportingService2010.Initialize(System.String)
Microsoft.ReportingServices.WebServer.ReportingService2010.ListItemTypes()
System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo, Boolean)
System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)

If you’re hitting this issue, and need to use Kerberos for authentication, you will want to install the SP1 update for the reporting services add-in on all your SharePoint 2010 boxes [you want the rsSharePoint.exe download].  This has a fix that will let Kerberos based claims fallback to Trusted Account when connecting to Reporting Services.  If you need a quick workaround, you can switch the authentication mode on the web application to NTLM.

For information on how Reporting Services works with claims authentication, see Claims Authentication and Reporting Services.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken

If you make the change in the Web Application, instead of the Security Token Service, you’ll get the following entry in the ULS logs when you try to logon :

05/17/2011 17:43:19.96 w3wp.exe (0x189C)                      
SharePoint Foundation                
Claims Authentication                   
fsq7      
High   
Request for security token failed with exception: System.ServiceModel.FaultException: The security token username and password could not be validated.    
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.ReadResponse    
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue
at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext

Some items to be aware of if you’re making this type of change :

• There is only one Security Token Service per farm.  This would mean that you can only have one hashAlgorithmType setting per farm.  If you need to have multiple web apps with multiple hash algorithms, you’ll end up building a custom membership provider.
• Depending on your membership provider, if you try to logon too many times, you’ll get a locked out account. Now you’re troubleshooting your provider configuration along with a locked out account.

If you’re looking for some walkthroughs on setting up forms authentication in SharePoint 2010, Mirjam van Olst has some very good blogs on setting up both SQL and LDAP providers :

• Configuring claims and forms based authentication for use with a SQL provider in SharePoint 2010
• Configuring claims and forms based authentication for use with an LDAP provider in SharePoint 2010