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>
http://support.f5.com/kb/en-us/solutions/public/8000/400/sol8482.html
If you want to really investigate the actual token size, you can use this neat tool:
Tool for discovering MaxTokenSize
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=1448
Here is the official closing email. I am including it because we did need to add/modify registry keys.
Issue:
==========
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."
Followed by:
"HTTP 400 - Bad Request"
Cause:
==========
"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.
Resolution:
==========
The "HTTP 400 - Bad Request" was resolved by the following steps:
Add the below
RegKeys to the WFE and Application Servers and Reboot:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength
Decimal
DWORD: 65534
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes
Decimal
DWORD: 16777216
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.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize
Decimal
DWORD: 65535
Adding the below
Registry Key to the Client & Server and Reboot:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxPacketSize
Decimal
DWORD: 1
"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 IIS
http://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 correctly
http://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