IIS has web sites, which are containers for virtual applications which contain virtual directories. The application in a site can be accessed through one or more IIS binding.IIS bindings provide two pieces of information – binding protocol and binding information. Binding protocol defines the scheme over which communication occurs, and binding information is the information used to access the site.
Problem: Only certain users complained of inability to access web site, getting the message HTTP Error 400 Bad Request. User with issue tried on other computer known to work for another user and still did not work. User without issue tried on computer of user with issue and they got in fine.
This shows it’s not a client problem and must be related to the user account. The web server uses NTLM authentication with kernel-mode enabled (Kerberos in use in network environment). As part of this authentication, all of the domain user’s active directory memberships are sent to the web server as part of the request. Users with too many AD memberships result in a request with exceeds one or more of the default limit that IIS sets.
To verify this was the issue, the user unchecked “Enable Integrated Windows Authentication” in IE options / Advanced / Security. With that off, the client would not transmit all of the AD memberships as part of the request. The user was able to access the web site.
To fix universally on the server, without the need for clients to change their IE settings, several IIS and LSA registry settings needed to be created and / or modified.
These increase limit amounts allowed for the large http authentication requests that come from users with a high number of AD memberships.
Command-line Tools Included in IIS
IIS administrators often need to configure multiple IIS servers or make frequent changes to IIS configurations. IIS application developers might also need to configure an IIS server to test an application and then restore the previous configuration after they are done. IIS provides command-line tools to make these tasks faster than using IIS Manager or writing custom administration scripts.
MS Deploy Basics
This message being spewed-forth by an asp.net application means that the DLL concerned has been compiled as a specific “bitness”, but one that doesn’t match that which IIS is running at. The most usual reason for this is an assembly marked as “x86″ deployed to an “x64″ server. If the assembly doesn’t P/Invoke out to any 32-bit DLLs, change the platform target to “AnyCpu”.
As far as the .net framework is concerned, the x86/x64 categorisation is only used as an indicator of requirements, thus if no P/Invoke is going on it’s not needed, as the JIT compiler takes the assembly and JIT compiles it to the relevant instruction set at runtime anyway.
This is the error that faced me the first time I deployed a .net Framework 3.5 web site to IIS via Visual Studio 2010 and then tried to run it. After a couple of hours of digging I traced it back to the application pool but I thought it worthy of a write-up.
Attempting to run a .net framework 3.5 web site hosted in IIS 7.5 (deployed via Visual Studio 2010) gives the following error information:
There is a duplicate ’system.web.extensions/scripting/scriptResourceHandler’ section defined
The error points to sections in the web.config file that ships with the site, a clearer view of which is here:
This is strange because:
- The site runs fine in Visual Studio 2010.
- It works when deployed into IIS via Visual Studio 2008 (on a different development machine and in live).
- This site works if you alter the framework target to be .net 4.0 and then deploy to IIS and run as normal.
This web site was originally developed in Visual Studio 2008 but desperate to try 2010, I followed the procedure below:
- Installed 2010 on a clean machine (nothing in IIS).
- Converted the 2008 solution but kept the framework target as 3.5.
- Ran from Visual Studio.
- Deployed to IIS and attempted to run from there.
My first thoughts were:
- That IIS thinks this is a .net Framework 4 site rather than a 3.5. I find this hard to check as aspnet_regiis –lk does not work on Windows 7 (my development OS) and finding anything in IIS 7 is a pain in the neck.
- Visual Studio 2010 has messed something up.
Confirming the versions of the target assemblies for the site was problematic however. When the site was built as .net 4 and so worked, I was able to view the Handler Mappings for the site. When it was built for .net 3.5 and so broke, I couldn’t view the mappings as IIS displayed the same error as at run-time:
It turned out that IIS was confused about the .net framework to use after all, or at least about the application pool version to use.
Viewing the application pools in IIS showed that I had the following:
As you can see, my application was sitting with the default web site inside the DefaultAppPool, which is configured to target .net 4. Moving the site into the Classic.NET AppPool fixed the issue and worked a treat.
It would have been nice for this to have worked out of the box but you live and learn.
This entry was posted on Tuesday, April 20th, 2010 at 19:02 and is filed under .Net Framework, ASP.Net, Errors, IIS, Misc. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.