I have worked with several customers who were experiencing strange behavior when viewing a SharePoint Dashboard containing multiple Excel Services Web Parts.
In one support case, a customer had 16 Excel Web Access Web Parts. Some users would see all 16 Web Parts and others would only see 15.
The question was, "Why do some users see all 16 Excel Web Access Web Parts and others see only 15"?
After many days, we were able to determine (via Fiddler) that the HTTP Header, for some users, exceeded the F5 "Maximum Header Size" threshold. The reason why this happened for some users and not others, is because when you are using Kerberos, the HTTP Header contains; a Kerberos Token (which contains Active Directory information about this user) and the Header also contains Cookies (each Web Part is a Session). So, some users had big Kerberos Tokens and the Header reach 32k sooner that others, therefore they were not able to see the 16th Excel Web Access Web Part (Session).
To fix this, you need to increase the F5 "Maximum Header Size" (we doubled it):
Here is the F5 article explaning this:
Error Message: HTTP header exceeded maximum allowed size of <value>
If you want to really investigate the actual token size, you can use this neat tool:
Tool for discovering MaxTokenSize
Here is the official closing email. I am including it because we did need to add/modify registry keys.
When viewing a dashboard with 16 “Excel Web Access Web Parts” the following message is thrown by the 16th Web Part:
"An error has occurred trying to perform the requested action. Please try again."
"HTTP 400 - Bad Request"
"HTTP 400 - Bad Request" was caused by Token Bloat.
"An error has occurred trying to perform the requested action. Please try again." was caused by the HTTP Headers growing over 32,768 bytes. This was caused by a combination the Cookie Collection and the Kerberos Ticket. F5 was stopping all session once the HTTP Header surpassed 32,768 bytes and the above error was thrown.
The "HTTP 400 - Bad Request" was resolved by the following steps:
Add the belowRegKeys to the WFE and Application Servers and Reboot:
IMPORTANT:Changing these registry keys can be considered extremely dangerous. These keys allow larger HTTP packets to be sent to IIS, which in turn may cause Http.sys to use more memory and may increase vulnerability to malicious attacks.
Adding the belowRegistry Key to the Client & Server and Reboot:
"An error has occurred trying to perform the requested action. Please try again." was resolved by increasing the “Maximum Header Size” from 32,768 bytes to 45,600 bytes in F5 (see F5 article sol8482).
Related Knowledgebase Articles:=========================== Http.sys registry settings for IIShttp://support.microsoft.com/kb/820129 New resolution for problems with Kerberos authentication when users belong to many groups http://support.microsoft.com/kb/327825 How to force Kerberos to use TCP instead of UDP in Windows http://support.microsoft.com/kb/244474
IIS 6.0 MaxFieldLength parameter not set correctlyhttp://technet.microsoft.com/en-us/library/aa996475(v=EXCHG.80).aspx
"HTTP 400 - Bad Request (Request Header too long)" error in Internet Information Services (IIS)http://support.microsoft.com/kb/2020943
Thanks for this great post that helped me. A little added info. This happens in load balancers other than F5 as well. We have ACE and we do not have Kerberos (we have plain NTLM). Still we faced the problem.
The resolution for ACE was to set the maximum parse length to 8192 bytes for both http header and content.