ConfigMgr reporting: Users get HTTP error 400 when browsing the Reporting Point

We've been finding a few users are experiencing problems when accessing the traditional ConfigMgr Reporting Point.

Odd, as other users are accessing the Reporting Point AOK, and no errors are appearing in the default web instance HTTP log (%WINDIR%\system32\logfiles\W3SVC1). However, a quick look in the HTTPERR logs and these error 400's show up (%WINDIR%\system32\logfiles\HTTPERR).

2009-01-15 21:32:15 x.x.x.x xxxx x.x.x.x 80 HTTP/1.1 GET /smsreporting_<YOURSITECODE>/Report.asp?ReportID=xxx&NAME=<CLIENTNAME>&SITE=<SITECODE>&STATUS=&COLLECTIONID=<COLLECTIONID> 400 - RequestLength -

I've obviously obfuscated the HTTP response from IIS, stripping out IP and other identifiying information. The important part of the response is in bold, 400 and RequestLength

If you are seeing this, most likely these users are getting bounced off the reporting point due to their Kerberos ticket being too big for IIS to handle. It seems to be due to how many groups this user is a member of (including nested groups).

Here are two interesting articles to aid you in fixing this:

http://support.microsoft.com/kb/955585
http://support.microsoft.com/kb/820129

I won't suggest sizes for the registry keys, it's something you'll need to assess either by plucking values out of the air true jedi style, or follow the KB955585 articles procedure for determining the values.

Some notes:

• I refer to default web instance, obviously if you are using SMSWEB it's not the default instance you are looking for (that's two star wars references, I rock!)
• Paths may be different, depends where you install stuff
• The KB articles are not ConfigMgr specific, this issue will affect any IIS based application I believe
• It doesn't say in KB article KB955585 (which is unusual for MS), but tweaking your registry can lead to pain, make sure you know what you are doing and I reserve the right to call you a numptee if you complain to me that I didn't warn you enough ;-)