Migrate the configuration to the
system.webServer/modules section. You
can do so manually or by using AppCmd
from the command line - for example,
%SystemRoot%\system32\inetsrv\appcmd
migrate config "Default Web Site/".
Using AppCmd to migrate your
application will enable it to work in
Integrated mode, and continue to work
in Classic mode and on previous
versions of IIS.

If you are certain that it is OK to
ignore this error, it can be disabled
by setting
system.webServer/validation@validateIntegratedModeConfiguration
to false.

Alternatively, switch the application
to a Classic mode application pool -
for example,
%SystemRoot%\system32\inetsrv\appcmd
set app "Default Web Site/"
/applicationPool:"Classic .NET
AppPool". Only do this if you are
unable to migrate your application.
(Set "Default Web Site" and "Classic .NET AppPool" to your application path and application pool name)

But the problem is that I don't have access to the ISS server as I am not the owner of it. Is there any way to solve this?

This shouldn't really affect your app's security. It just turns off the warning that says you have some configuration values that won't be used.
– DavidJan 27 '12 at 22:44

17

This isn't really overly sound advice if you have settings that won't be used then you should remove them.
– SephApr 8 '12 at 12:26

32

@Seph, disagree that this isn't sound advice. Lots of NuGet installations (for example, DotLess) will add entries to sections that apply to integrated mode, and also duplicate that setting for non-integrated mode. This is called portability and allows your configuration to work regardless of whether you are using IIS7/integrated or classic. The only reason to leave this validation setting to true is so that you can leave your training wheels on and have IIS yell at you whenever you add a setting that won't work in integrated mode. This is for the inexperienced, but gets in the way.
– Kirk WollNov 1 '12 at 1:00

5

This kind of configuration is annoying. @MS: there is a better way.
– yonexbatDec 26 '12 at 9:36

Adding <validation validateIntegratedModeConfiguration="false"/> addresses the symptom, but is not appropriate for all circumstances. Having ran around this issue a few times, I hope to help others not only overcome the problem but understand it. (Which becomes more and more important as IIS 6 fades into myth and rumor.)

Background:

This issue and the confusion surrounding it started with the introduction of ASP.NET 2.0 and IIS 7. IIS 6 had and continues to have only one pipeline mode, and it is equivalent to what IIS 7+ calls "Classic" mode. The second, newer, and recommended pipeline mode for all applications running on IIS 7+ is called "Integrated" mode.

So, what's the difference? The key difference is how ASP.NET interacts with IIS.

Classic mode is limited to an ASP.NET pipeline that cannot interact with the IIS pipeline. Essentially a request comes in and if IIS 6/Classic has been told, through server configuration, that ASP.NET can handle it then IIS hands off the request to ASP.NET and moves on. The significance of this can be gleaned from an example. If I were to authorize access to static image files, I would not be able to do it with an ASP.NET module because the IIS 6 pipeline will handle those requests itself and ASP.NET will never see those requests because they were never handed off.* On the other hand, authorizing which users can access a .ASPX page such as a request for Foo.aspx is trivial even in IIS 6/Classic because IIS always hands those requests off to the ASP.NET pipeline. In Classic mode ASP.NET does not know what it hasn't been told and there is a lot that IIS 6/Classic may not be telling it.

Integrated mode is recommended because ASP.NET handlers and modules can interact directly with the IIS pipeline. No longer does the IIS pipeline simply hand off the request to the ASP.NET pipeline, now it allows ASP.NET code to hook directly into the IIS pipeline and all the requests that hit it. This means that an ASP.NET module can not only observe requests to static image files, but can intercept those requests and take action by denying access, logging the request, etc.

Overcoming the error:

If you are running an older application that was originally built for IIS 6, perhaps you moved it to a new server, there may be absolutely nothing wrong with running the application pool of that application in Classic mode. Go ahead you don't have to feel bad.

Then again maybe you are giving your application a face-lift or it was chugging along just fine until you installed a 3rd party library via NuGet, manually, or by some other means. In that case it is entirely possible httpHandlers or httpModules have been added to system.web. The outcome is the error that you are seeing because validateIntegratedModeConfiguration defaults true. Now you have two choices:

Remove the httpHandlers and httpModules elements from system.web. There are a couple possible outcomes from this:

Everything works fine, a common outcome;

Your application continues to complain, there may be a web.config in a parent folder you are inheriting from, consider cleaning up that web.config too;

You grow tired of removing the httpHandlers and httpModules that NuGet packages keep adding to system.web, hey do what you need to.

If those options do not work or are more trouble than it is worth then I'm not going to tell you that you can't set validateIntegratedModeConfiguration to false, but at least you know what you're doing and why it matters.

+1 only solution is a not answer of your problem but solution with explanation that is perfect answer. What it is and why we need to change this, these questions of answer given by @Jeremy cook answer.
– Rikin PatelJan 8 '16 at 5:28

This explanation led me to fixing the issue for a small test site hosted in IIS 7.5 in Integrated mode. When I created a new MVC project, it added the httpModule, Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule in my Web.config. This is because I left the "Add Application Insights to project" option checked when creating a new ASP.NET Web Aapplication project. When I removed the httpModule from Web.config, the site worked without the error. Setting validateIntegratedModeConfiguration to false worked, but that was just a bandaid approach.
– iCodeAug 26 '16 at 13:08

2

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode. This is yet another useless Microsoft error message. ASP.net has thousands of settings but Microsoft did not think to include the one causing the error in the error text. MS is being run by marketeers rather than engineers so don't expect things to improve any time soon. :-(
– Paul McCarthyApr 13 '17 at 15:08

I think HttpModules property in system.web is for ASP 3.5 or before. For ASP 4 or above use modules in system.webserver
– Hoy CheungJan 1 '15 at 1:34

1

@HoyCheung its actually a matter of using Integrated or Classic pipeline, not what version of .Net, which decides whether to use system.web/httpModules or system.webServer/modules.
– Pauli ØsterøMar 30 '16 at 21:29

Agreed - this is the better option rather than just hiding the error! Make sure you're using the correct App Pool - should be Classic not Integrated
– SwombleJan 23 '13 at 10:09

1

I am using visual studio 2012, how can i change app pool to classic.
– Hammad Ali RazaJan 31 '14 at 11:01

9

This isn't a good solution if you want to be using all the new features available in Integrated Pipeline. This is like saying reverting to .NET 2.0 from 4.0 because of a problem.
– Trevor de KoekkoekSep 8 '14 at 12:29

To do this in IIS Manager, go to Application Pools in the tree on the left, double-click on the pool you want to change, and choose the pipeline mode.
– Steve SmithJul 12 at 15:49

Seems like something went south when I originally created the site. I hate solutions that are similar to "Restart your machine, then reinstall windows" without knowing what caused the error. But, this worked for me. Quick and simple. Hope it helps someone else.

I ran into this problem and inspired by @Jeremy Cook's answer, I bit the bullet to find out what the heck caused IIS 7 Integrated mode to not like my web.config. Here's my scenario:

Web API (version 4.0.030506.0 aka the old one)

.NET 4.0

Attribute Routing 3.5.6 for Web API [spoiler alert: it was this guy!]

I wanted to use attribute routing in a project that (unfortunately) had to use .NET 4 and hence could not use Web API 2.2 (which needs .NET 4.5). The well meaning NuGet package added this section under the <system.web> section:

[I say well meaning, because this part is required on older versions of IIS]

Removing this section got me past the HTTP 500.23!!

Summary:
I second Jeremy's words that it is important to understand why things don't work rather than just "masking the symptom". Even if you have to mask the symptom, you know what you are doing (and why) :-)

Thanks. I added AttributeRouting, including the Api Controller add-on NuGet package, and removing the section you indicated from web.config solved the problem. However, I am a little concerned because my MVC web app was already using .NET framework 4.5.
– Robert OschlerJul 16 '15 at 2:00

2

@RobertOschler if you are on .NET 4.5, you already have attribute routing built in AFAIK - you shouldn't need this NuGet?
– dotnetguyJul 16 '15 at 2:17

Thanks and crap. There went a few hours today getting the AttributeRouting package running NuGet. I pulled it out and undid all the code "fixes" I added to make it work, and substituted the Web API 2 Route() attribute for the GET() attribute. Worked great. We really need an expert system these days just to help us with all these packages.
– Robert OschlerJul 16 '15 at 3:44

It took me few hours to solved this because all off the settings that I found here about this error were the same but it still didn't work.
The problem was tha I had a folder in my web service from which the file should be send to WinCE device, after converting that folder to an application with Classic.NetAppPool it started to work.