ASP.NET 2.0 applications on IIS 7.0 are hosted using the ASP.NET Integrated mode by default. This new mode enables a myriad of exciting scenarios including using super-valuable ASP.NET features like Forms Authentication for your entire Web site, and developing new ASP.NET modules to do things like URL rewriting, authorization, logging, and more at the IIS level. For more information about the ASP.NET Integration in IIS 7.0, see: ASP.NET Integration with IIS7.
Update: We recently launched a service that significantly helps you understand, troubleshoot, and improve production ASP.NET applications. If you regularly troubleshoot IIS errors, manage Windows Servers, or tune ASP.NET performance, definitely check out the demo at www.leansentry.com.
As you know, with great power comes great responsibility. Similarly, with making ASP.NET applications more powerful in IIS 7.0 comes the responsibility of making sure that existing ASP.NET applications continue to work. This has been a major challenge for us as we re-architected the entire core engine of ASP.NET, and in the end we were highly successful in meeting it. As a result, most ASP.NET applications should work without change.
This post lists the changes in behavior that you may encounter when deploying your ASP.NET applications on IIS 7.0 on Windows Vista SP1 and Windows Server 2008. Unless noted, these breaking changes occur only when using the default ASP.NET Integrated mode.
Using Classic ASP.NET mode
IIS 7.0 also offers the ability to run ASP.NET applications using the legacy Classic ASP.NET Integration mode, which works the same way as ASP.NET has worked on previous versions of IIS. However, we strongly recommend that you use a workaround where available to change your application to work in Integrated mode instead. Moving to Classic mode will make your application unable to take advantage of ASP.NET improvements made possible in Integrated mode, leveraging future features from both Microsoft and third parties that may require the Integrated mode. Use Classic mode as a last resort if you cannot apply the specified workaround. For more information about moving to Classic mode, see: Changing the ASP.NET integration mode.
I’ve blogged in detail about some of the breaking changes below. Those changes include links to the posts that contain additional details and workaround information. If you require more information on a particular problem, please leave a comment.
Migration errors
These errors occur due to changes in how some ASP.NET configuration is applied in Integrated mode. IIS will automatically detect this configuration and issue an error asking you to migrate your application, or move it to classic mode if migration is not acceptable (See breaking change #3 below).
1) ASP.NET applications require migration when specifying configuration in <httpModules> or <httpHandlers>.
You will receive a 500 – Internal Server Error. This can include HTTP Error 500.22, and HTTP Error 500.23: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.
It occurs because ASP.NET modules and handlers should be specified in the IIS <handlers> and <modules> configuration sections in Integrated mode.
Workaround:
1) You must migrate the application configuration to work properly in Integrated mode. You can migrate the application configuration with AppCmd:
> %windir%system32inetsrvAppcmd migrate config “<ApplicationPath>”
2) You can migrate manually by moving the custom entries in in the <system.web>/<httpModules> and <system.web>/<httpHandlers> configuration manually to the <system.webServer>/<handlers> and <system.webServer>/<modules> configuration sections, and either removing the <httpHandlers> and <httpModules> configuration OR adding the following to your application’s web.config:
<system.webServer>
<validation validateIntegratedModeConfiguration=”false” />
</system.webServer>
2) ASP.NET applications produce a warning when the application enables request impersonation by specifying <identity impersonate=”true”> in configuration
You will receive a 500 – Internal Server Error. This is HTTP Error 500.24: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.
It occurs because ASP.NET Integrated mode is unable to impersonate the request identity in the BeginRequest and AuthenticateRequest pipeline stages.
Workaround:
1) If your application does not rely on impersonating the requesting user in the BeginRequest and AuthenticateRequest stages (the only stages where impersonation is not possible in Integrated mode), ignore this error by adding the following to your application’s web.config:
<system.webServer>
<validation validateIntegratedModeConfiguration=”false” />
</system.webServer>
2) If your application does rely on impersonation in BeginRequest and AuthenticateRequest, or you are not sure, move to classic mode.
3) You receive a configuration error when your application configuration includes an encrypted <identity> section.
You will receive a 500 – Internal Server Error. This is HTTP Error 500.19: The requested page cannot be accessed because the related configuration data for the page is invalid.
The detailed error information indicates that “Configuration section encryption is not supported”.
It occurs because IIS attempts to validate the <identity> section and fails to read section-level encryption.
Workaround:
1) If your application does not have the problem with request impersonation per breaking change #2, migrate your application configuration by using AppCmd as described in breaking change #1:
> %windir%system32inetsrvAppcmd migrate config “<ApplicationPath>”
This will insure that the rest of application configuration is migrated, and automatically add the following to your application’s web.config to ignore the <identity> section:
<system.webServer>
<validation validateIntegratedModeConfiguration=”false” />
</system.webServer>
2) If your application does have the problem with request impersonation, move to classic mode.
Authentication, Authorization, and Impersonation
In Integrated mode, both IIS and ASP.NET authentication stages have been unified. Because of this, the results of IIS authentication are not available until the PostAuthenticateRequest stage, when both ASP.NET and IIS authentication methods have completed. This causes the following changes:
4) Applications cannot simultaneously use FormsAuthentication and WindowsAuthentication
Unlike Classic mode, it is not possible to use Forms Authentication in ASP.NET and still require users to authenticate with an IIS authentication method including Windows Authentication, Basic Authentication, etc. If Forms Authentication is enabled, all other IIS authentication methods except for Anonymous Authentication should be disabled.
In addition, when using Forms Authentication, the following changes are in effect:
– The LOGON_USER server variable will be set to the name of the Forms Authentication user.
– It will not be possible to impersonate the authenticated client. To impersonate the authenticated client, you must use an authentication method that produces a Windows user instead of Forms Authentication.
Workaround:
1) Change your application to use the pattern explained in Implementing a two level authentication scheme using Forms Authentication and another IIS authentication method in IIS 7.0.
5) Windows Authentication is performed in the kernel by default. This may cause HTTP clients that send credentials on the initial request to fail.
IIS 7.0 Kernel-mode authentication is enabled by default in IIS 7.0. This improves the performance of Windows Authentication, and simplifies the deployment of Kerberos authentication protocol. However, it may cause some clients that send the windows credentials on the initial request to fail due to a design limitation in kernel-mode authentication. Normal browser clients are not affected because they always send the initial request anonymously.
NOTE: This breaking change applies to both Classic and Integrated modes.
Workaround:
1) Disable kernel-mode authentication by setting the userKernelMode to “false” in the system.webServer/security/authentication/windowsAuthentication section. You can also do it by AppCmd as follows:
> %windir%system32inetsrvappcmd set config /section:windowsAuthentication /useKernelMode:false
6) Passport authentication is not supported.
You will receive an ASP.NET 500 – Server Error: The PassportManager object could not be initialized. Please ensure that Microsoft Passport is correctly installed on the server.
Passport authentication is no longer supported on Windows Vista and Windows Server 2008. NOTE: This breaking change applies to both Classic and Integrated modes.
7) HttpRequest.LogonUserIdentity throws an InvalidOperationException when accessed in a module before PostAuthenticateRequest
You will receive an ASP.NET 500 – Server Error: This method can only be called after the authentication event.
HttpRequest.LogonUserIdentity throws an InvalidOperationException when accessed before PostAuthenticateRequest, because the value of this property is unknown until after the client has been authenticated.
Workaround:
1) Change the code to not access HttpRequest.LogonUserIdentity until at least PostAuthenticateRequest
8) Client impersonation is not applied in a module in the BeginRequest and AuthenticateRequest stages.
The authenticated user is not known until the PostAuthenticateRequest stage. Therefore, ASP.NET does not impersonate the authenticated user for ASP.NET modules that run in BeginRequest and AuthenticateRequest stages. This can affect your application if you have custom modules that rely on the impersonating the client for validating access to or accessing resources in these stages.
Workaround:
1) Change your application to not require client impersonation in BeginRequest and AuthenticateRequest stages.
9) Defining an DefaultAuthentication_OnAuthenticate method in global.asax throws PlatformNotSupportedException
You will receive an ASP.NET 500 – Server Error: The DefaultAuthentication.Authenticate method is not supported by IIS integrated pipeline mode.
In Integrated mode, the DefaultAuthenticationModule.Authenticate event in not implemented and hence no longer raises. In Classic mode, this event is raised when no authentication has occurred.
Workaround:
1) Change application to not rely on the DefaultAuthentication_OnAuthenticate event. Instead, write an IHttpModule that inspects whether HttpContext.User is null to determine whether an authenticated user is present.
10)Applications that implement WindowsAuthentication_OnAuthenticate in global.asax will not be notified when the request is anonymous[M2]
If you define the WindowsAuthentication_OnAuthenticate method in global.asax, it will not be invoked for anonymous requests. This is because anonymous authentication occurs after the WindowsAuthentication module can raise the OnAuthenticate event.
Workaround:
1) Change your application to not use the WindowsAuthentication_OnAuthenticate method. Instead, implement an IHttpModule that runs in PostAuthenticateRequest, and inspects HttpContext.User.
Request limits and URL processing
The following changes result due to additional restrictions on how IIS processes incoming requests and their URLs.
11)Request URLs containing unencoded “+” characters in the path (not querystring) is rejected by default
You will receive HTTP Error 404.11 – Not Found: The request filtering module is configured to deny a request that contains a double escape sequence.
This error occurs because IIS is by default configured to reject attempts to doubly-encode a URL, which commonly represent an attempt to execute a canonicalization attack.
Workaround:
1) Applications that require the use of the “+” character in the URL path can disable this validation by setting the allowDoubleEscaping attribute in the system.webServer/security/requestFiltering configuration section in the application’s web.config. However, this may make your application more vulnerable to malicious URLs:
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping=”true” />
</security>
</system.webServer>
12)Requests with querystrings larger then 2048 bytes will be rejected by default
You will receive an HTTP Error 404.15 – Not Found: The request filtering module is configured to deny a request where the query string is too long.
IIS by default is configured to reject querystrings longer than 2048 bytes. This may affect your application if it uses large querystrings or uses cookieless ASP.NET features like Forms Authentication and others that cumulatively exceed the configured limit on the querystring size.
NOTE: This breaking change applies to both Classic and Integrated modes.
Workaround:
1) Increase the maximum querystring size by setting the maxQueryString attribute on the requestLimits element in the system.webServer/security/requestFiltering configuration section in your application’s web.config:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString=”NEW_VALUE_IN_BYTES” />
</requestFiltering>
</security>
</system.webServer>
Changes in response header processing
These changes affect how response headers are generated by the application.
13)IIS always rejects new lines in response headers (even if ASP.NET enableHeaderChecking is set to false)
If your application writes headers with line breaks (any combination of r, or n), you will receive an ASP.NET 500 – Server Error: Value does not fall within the expected range.
IIS will always reject any attempt to produce response headers with line breaks, even if ASP.NET’s enableHeaderChecking behavior is disabled. This is done to prevent header splitting attacks.
NOTE: This breaking change applies to both Classic and Integrated modes.
14)When the response is empty, the Content-Type header is not suppressed
If the application sets a Content-Type header, it will remain present even if the response is cleared. Requests to ASP.NET content types will typically have the “Content-Type: text/html” present on responses unless overridden by the application.
Workaround:
1) While this should not typically have a breaking effect, you can remove the Content-Type header by explicitly setting the HttpResponse.ContentType property to null when clearing the response.
15)When the response headers are cleared with HttpResponse.ClearHeaders, default ASP.NET headers are not generated. This may result in the lack of Cache-Control: private header that prevents the caching of the response on the client
HttpResponse.ClearHeaders does not re-generate default ASP.NET response headers, including “Content-Type: text/html” and “Cache-Control: private”, as it does in Classic mode. This is because ASP.NET modules may call this API for requests to any resource type, and therefore generating ASP.NET-specific headers is not appropriate. The lack of the “Cache-Control” header may cause some downstream network devices to cache the response.
Workaround:
1) Change application to manually generate the Cache-Control: private header when clearing the response, if it is desired to prevent caching in downstream network devices.
Changes in application and module event processing
These changes affect how the application and module event processing takes place.
16)It is not possible to access the request through the HttpContext.Current property in Application_Start in global.asax
If your application accesses the current request context in the Application_Start method in global.asax as part of application initialization, you will receive an ASP.NET 500 – Server Error: Request is not available in this context.
This error occurs because ASP.NET application initialization has been decoupled from the request that triggers it. In Classic mode, it was possible to indirectly access the request context by accessing the HttpContext.Current property. In Integrated mode, this context no longer represents the actual request and therefore attempts to access the Request and Response objects will generate an exception.
Workaround:
1) See Request is not available in this context exception in Application_Start for a detailed description of this problem and available workarounds.
17)The order in which module event handlers execute may be different then in Classic mode
The following differences exist:
– For each event, event handlers for each module are executed in the order in which modules are configured in the <modules> configuration section. Global.asax event handlers are executed last.
– Modules that register for the PreSendRequestHeaders and PreSendRequestContent events are notified in the reverse of the order in which they appear in the <modules> configuration section
– For each event, synchronous event handlers for each module are executed before asynchronous handlers. Otherwise, event handlers are executed in the order in which they are registered.
Applications that have multiple modules configured to run in either of these events may be affected by these change if they share a dependency on event ordering. This is not likely for most applications. The order in which modules execute can be obtained from a Failed Request Tracing log.
Workaround:
1) Change the order of the modules experiencing an ordering problem in the system.webServer/modules configuration section.
18)ASP.NET modules in early request processing stages will see requests that previously may have been rejected by IIS prior to entering ASP.NET. This includes modules running in BeginRequest seeing anonymous requests for resources that require authentication.
ASP.NET modules can run in any pipeline stages that are available to native IIS modules. Because of this, requests that previously may have been rejected in the authentication stage (such as anonymous requests for resources that require authentication) or other stages prior to entering ASP.NET may run ASP.NET modules.
This behavior is by design in order to enable ASP.NET modules to extend IIS in all request processing stages.
Workaround:
1) Change application code to avoid any application-specific problems that arise from seeing requests that may be rejected later on during request processing. This may involve changing modules to subscribe to pipeline events that are raised later during request processing.
Other application changes
Other changes in the behavior of ASP.NET applications and APIs.
19)DefaultHttpHandler is not supported. Applications relying on sub-classes of DefaultHttpHandler will not be able to serve requests.[M3]
If your application uses DefaultHttpHandler or handlers that derive from DefaultHttpHandler, it will not function correctly. In Integrated mode, handlers derived from DefaultHttpHandler will not be able to pass the request back to IIS for processing, and instead serve the requested resource as a static file. Integrated mode allows ASP.NET modules to run for all requests without requiring the use of DefaultHttpHandler.
Workaround:
1) Change your application to use modules to perform request processing for all requests, instead of using wildcard mapping to map ASP.NET to all requests and then using DefaultHttpHandler derived handlers to pass the request back to IIS.
20)It is possible to write to the response after an exception has occurred.
In Integrated mode, it is possible to write to and display an additional response written after an exception has occurred, typically in modules that subscribe to the LogRequest and EndRequest events. This does not occur in Classic mode. If an error occurs during the request, and the application writes to the response in EndRequest after the exception has occurred, the response information written in EndRequest will be shown. This only affects requests that include unhandled exceptions. To avoid writing to the response after an exception, an application should check HttpContext.Error or HttpResponse.StatusCode before writing to the response.
21)It is not possible to use the ClearError API to prevent an exception from being written to the response if the exception has occurred in a prior pipeline stage
Calling Server.ClearError during the EndRequest event does not clear the exception if it occurred during an earlier event within the pipeline. This is because the exception is formatted to the response at the end of each event that raises an exception.
Workaround:
1) Change your application to call Server.ClearError from the Application_OnError event handler, which is raised whenever an exception is thrown.
22)HttpResponse.AppendToLog does not automatically prepend the querystring to the URL.[M4]
When using HttpResponse.AppendToLog to append a custom string to the URL logged in the request log file, you will manually need to prepend the querystring to the string you pass to this API. This may result in existing code losing the querystring from the logged URL when this API is used.
Workaround:
1) Change your application to manually prepend HttpResponse.QueryString.ToString() to the string passed to HttpResponse.AppendToLog.
Other changes
Other changes.
23)ASP.NET threading settings are not used to control the request concurrency in Integrated mode
The minFreeThreads, minLocalRequestFreeThreads settings in the system.web/httpRuntime configuration section and the maxWorkerThreads setting in the processModel configuration section no longer control the threading mechanism used by ASP.NET. Instead, ASP.NET relies on the IIS thread pool and allows you to control the maximum number of concurrently executing requests by setting the MaxConcurrentRequestsPerCPU DWORD value (default is 12) located in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftASP.NET2.0.50727.0 key. This setting is global and cannot be changed for individual application pools or applications.
Workaround:
1) To control the concurrency of your application, set the MaxConcurrentRequestsPerCPU setting.
24)ASP.NET application queues are not used in Integrated mode. Therefore, the “ASP.NET ApplicationsRequests in Application Queue” performance counter will always have a value of 0
ASP.NET does not use application queues in Integrated mode.
25)IIS 7.0 always restarts ASP.NET applications when changes are made to the application’s root web.config file. Because of this, waitChangeNotification and maxWaitChangeNotification attributes have no effect.
IIS 7.0 monitors changes to the web.config files as well, and cause the ASP.NET application corresponding to this file to be restarted without regard to the ASP.NET change notification settings including the waitChangeNotification and maxWaitChangeNotification attributes in the system.web/httpRuntime configuration sections.
26)ASP.NET deadlock detection is not supported in Integrated mode.
ASP.NET 2.0 Classic mode supports a deadlock detection mechanism which monitors ASP.NET responses and considers the process deadlocked if no responses have been received in more then the amount of time specified in the <processModel responseDeadlockInterval> setting, and there are more than a certain number of requests outstanding. In this case, the process is marked unhealthy and a new process is eventually started. In Integrated mode, this feature is not supported. If your application is prone to deadlocks, it may lead to deadlock conditions being undetected, however it should have no effect on healthy applications that do not exhibit deadlocks.
We hope that your move to IIS 7.0’s Integrated mode is as painless as possible, so you can immediately start to take advantage of IIS 7.0’s features and the power of Integrated ASP.NET in your applications.
Let us know if you are having trouble with any of these breaking changes, or if you encounter another behavior change in your application not listed here, by posting on the http://forums.iis.net.
Thanks,
Mike
ASP.NET 2.0 applications on IIS 7.0 are hosted using the ASP.NET Integrated mode by default. This post lists the changes in behavior that you may encounter when deploying your ASP.NET applications on IIS 7.0 on Windows Vista and Windows Server 2008.
ASP.NET 2.0 applications on IIS 7.0 are hosted using the ASP.NET Integrated mode by default. This new
Mike Volodarsky has post a list of breaking changes for ASP.NET 2.0 application running in integrated
The link to “Implementing a two level authentication scheme using Forms Authentication and another IIS authentication method in IIS 7.0” is broken – it just returns a blank page.
para melhorar minhas habilitações técnicas.
Aprendizado.
Today I delivered an overview of IIS7 at the Architect Forum held at our offices in Reading. I promised
See the blog of a Microsoft IIS Program Manager on advanced IIS server deployment and development. Mike
The link for issue 4 is broken:
http://mvolo.com/tiny_mce/jscripts/tiny_mce/blank.htm#_msocom_1
Regards
I'm replacing my del.icio.us feed with posts to this blog. That way they will appear on the website
The link M1 is currently broken. We currently use a mixed authentication process on our web apps, so knowing what that pattern needs to be going forward would be very helpful.
Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials
Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials
Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials
can any one please tell me, is there any facility in IIS Server to handle URL Rewriteing without any code in asp.net like a Apache server facility
The link to this article “Implementing a two level authentication scheme using Forms Authentication and another IIS authentication method in IIS 7.0” appears broken.
Regards.
Javascript: AJSONQueryLanguage
.NET: BreakingChangesforASP.NET2.0applicationsrunnin…
Hi Ivaylo, Robert,
The link to the explanation of issue #4 will be up shortly.
Thanks,
Mike
Hi Mike,
I had a problem with URL rewriting and found you gave the solution in this thread:
http://forums.iis.net/t/1031243.aspx
Did you ever get around to create that blog post about runAllManagedModulesForAllRequests="true", if so can you please post a link to it?
Cheers,
Anders
Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials
This month, the Enhance Your Apps With the Integrated ASP.NET Pipeline article is finally out in MSDN
Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials
Hey Mike,
Ed Maurer posted a blog (http://blogs.msdn.com/ed_maurer/archive/2007/12/14/nxcompat-and-the-c-compiler.aspx) on the C# compiler changes in .NET 3.5 (and .NET 2.0 SP1) causing all assemblies to be marked with the NX flag. This is affecting components using COM interop to use native components, in the cases where those native components link to pre-ATL80, as pre-ATL80 may run illegal calls that are stopped under DEP. I am wondering if this has any impact to ASP.NET?
I know for a fact that native components linking to pre-ATL80 that worked as add-ins in VS2008 fail under DEP, since VS2008 itself is marked with the NX flag. I also know that w3wp.exe is marked with the NX flag on Vista (the system I checked this had .NET 3.5 installed, but I am not sure if w3wp.exe is installed by the .NET fwk or Vista/IIS itself). I also know that ASP.NET 1.1 apps couldn’t run on Vista/IIS7 due to DEP, but that was 1.1-specific and got fixed with .NET 1.1 SP1.
Unfortunately I have trouble verifying if my Asp.NET 2.0 app (using native components linking to ATL71) would crash under DEP as I need to do a lot of testing to ensure I covered all of the workflows, so I am wondering if you can confirm if DEP could be a problem for ASP.NET using native components or not?
Thanks,
Kima
Hi Kima,
As far as I know, the NX bit is for PE assemblies only, and enables DEP per process. The changes to the compiler sound like they simply enable DEP by default for .exe files compiled with VS 2008. This doesnt affect ASP.NET hosted in w3wp.exe.
Like you said, w3wp.exe on Vista enables DEP by default so any code executed in process will be subject to DEP. If your managed code invokes native in-process COM or DLL code that has trouble under DEP, your app will as well.
Thanks,
Mike
Another great post by Mike Volodarsky that presents some problems that migh occur when you deploy a 2
Another great post by Mike Volodarsky that presents some problems that migh occur when you deploy a 2.0
In #5 (do not send credentials on initial request), you mention that most browsers send the initial request anonymously.
What about web service calls, and use of the HttpWebRequest, and System.Net.WebClient? I always set the Credentials property on these objects to CredentialCache.DefaultCredentials when I know the resource is protected. This should be a very common scenario. I assume that means the credentials will be sent on the initial request and things will start failing.
Do I now need to write code that first checks for the rejected response, and then re-submit the request with the credentials? (yuck) Or do those framework classes I mentioned already handle that under the hood?
Mike , why cant we have a list of steps explaining how to configure am ASP.NET 2.0 application. None of the existing docs explain the end to end process
Hi geee,
Setting up an ASP.NET application on IIS 7.0 is pretty easy – install ASP.NET from Windows Setup, create an IIS application (or use the built-in one) in InetMgr.exe, and drop in your files. A common gotcha is that IIS 7.0 is a modular server, so you need to install things like ASP.NET support and other features from Windows Setup before they become available.
You can find information on IIS 7.0 componentized setup here: http://www.iis.net/articles/view.aspx/IIS7/Deploy-an-IIS7-Server/Installing-IIS7/Install-IIS7-on-Vista.
If you are looking for more ASP.NET-specific information about developing your app, you should check out the extensive web community starting with http://www.asp.net. Do a web search for “setting up an asp.net application” to find tons more info.
You can discuss any specific installation or setup issues on forums.iis.net and forums.asp.net.
Thanks,
Mike
Hi Joshua,
I believe the 2.0 HttpWebRequest and System.NET classes already handle this under the covers.
The 1.1 classes may experience problems based on what I’ve seen. The quick workaround is to disable kernel authentication if you have such clients, as shown in the workaround.
Thanks,
Mike
Can we get the link for M1 fixed? All it brings up is a blank page and the issue is currently a showstopper for me if users want to run in Integrated mode instead of Classic.
Appologies for taking so long to provide this. The link is now fixed.
You can access the post on using a two-level authentication scheme here: http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx.
Thanks,
Mike
The integration of IIS and ASP.NET authentication stages in Integrated mode applications brings a lot
Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials
I previously posted about a Community Server url encoding problem on Vista. The problem was the urls
One of my customer was running into a kerberos issue on IIS 7.0. While working on this issue, I remembered
One of my customer was running into a kerberos issue on IIS 7.0. While working on this issue, I remembered
One of my customer was running into a kerberos issue on IIS 7.0. While working on this issue, I remembered
Great post, I’m assuming MVC framework doesn’t have any new issues?
So with the “Migration Errors #2” we have to do this for every site… Is there a way of making this the default for a web server with multiple domains and more to be added?
Tim,
With the impersonation breaking change, you really should make sure that the application isnt affected by the lack of impersonation in early stages before configuring it to ignore this error, so doing it one by one makes sense. If you just bulk configure every app, you may miss those that will be affected.
However, if you have a list of those that are known not to be affected, the safest thing is to write a script that runs “appcmd migrate config” for all those apps. This way, you’ll set them to ignore this error in one shot, AND, make sure that their other configuration is migrated before you disable validation.
If you just want to disable validation globally, set the
Thanks,
Mike
As there are some questions on how to run Ajax.NET on IIS 7 (i.e. Windows Vista) in integrated mode instead
Para empezar a probar IIS 7 sobre Windows Server 2008, podemos descargar Windows Web Server 2008 , lo
Mike,
Thanks for taking the time to put this list together, great resource!
Hi – just wanted to say good design and blog – cu Frank
I just came across this great post from Mike Volodarsky (a program manager in the IIS team) about breaking
IIS7.0 : Breaking changes for .net 2.0 apps
Para empezar a probar IIS 7 sobre Windows Server 2008, podemos descargar Windows Web Server 2008 , lo
I tried to set
but the app fails with …This configuration section cannot be used at this path.
Any suggestions? + is a valid character in paths, isn’t it?
Rusty,
What are you trying to set / at what path? You may get this error if the config section is locked, as request filtering is by default in Vista prior to SP1.
> appcmd unlock config -section:requestFiltering
+ is rejected because it may lead to double dencoding of the url, which could create canonicalization vulnerabilities during application request processing. Its a good idea to keep allowDoubleEscaping = false and not use + characters in your URLs.
Thanks,
Mike
cool article
Dans le genre post qu’on ne retrouve jamais quand on en a besoin, celui-ci bien sympathique de Mike Volodarsky
If I config the application using .Net 2.0, I receive an error message as "This can include HTTP Error 500.22, and HTTP Error 500.23: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.". However, if I config the application as .NET 3.5, everything is fine without requring any change. I am using VISTA64 + VS2008. Why is that?
This quick post is for my own sake so I can find it again later. 🙂 I refer to the following link often
Great Post.
Very descriptive Good Job Done Mike Volodarsky
[原文：http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applic…
I tried using the migrate command on vista ultimate but it is not allowed due to permissons ‘cannot read from the configuration file due to permissions. I set full control access to the reporting services application directory for localhost. Still doesn’t work. What next?
1) ASP.NET applications require migration when specifying configuration in or .
You will receive a 500 – Internal Server Error. This can include HTTP Error 500.22, and HTTP Error 500.23: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.
It occurs because ASP.NET modules and handlers should be specified in the IIS and configuration sections in Integrated mode.
Workaround:
1) You must migrate the application configuration to work properly in Integrated mode. You can migrate the application configuration with AppCmd:
> %windir%system32inetsrvAppcmd migrate config “”
2) You can migrate manually by moving the custom entries in in the/ and / configuration manually to the / and / configuration sections, and either removing the and configuration OR adding the following to your application’s web.config:
Hi,
I am not able to upload a file on ftp location.
I am putting file into writeable folder fisrt, then I am putting the same file into the Attachment folder.
But the file is going to the writeable folder, however it is not going to the attachment folder.
It was working fine before 25th but started filing after that..
What could be the reason please let me know as soon as possible.
Thanks & Regards,
ss
Passport authentication is not supported??? How are we to use Windows LiveID authentication in Windows Server 2008 then? Are you scrapping Windows Live ID authentication as well? C’mon guys, there’s nothing on the web regarding this and this is a big deal… get typing…
Hi.
I am trying to run IIS on Vista Home Premium. I get “An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.” error. I tried to remove all .net installations. (I need just SQL server and Reporting Services that requires IIS).
I uninstalled .net framework from my computer.
Still getting the same error. What am I missing?
All help are greatly appreciated. Thanks.
David, please see item #1 in this post.
Thanks,
Mike
Hi Dodge,
I’ll blog about this sometime in the future. In the meantime, you’d be best off asking this at forums.iis.net.
Live ID auth should be supported in WS08 as far as I know, I believe MS has a program for supporting Passport users and getting them on the new APIs.
They should be able to direct you to the right place on the forums.
Thanks,
Mike
I am facing the 500.19 error; error code 0x80070021 (change#3 mentioned in your blog above) with one of the application. I have Vista and IIS 7.0. So far I have tried the following things-
1. Given full access control to Everyone on inetpub folder (my application is in inetpubwwwroot)
2. Tried accessing as the Vista super Administrator
3. deleting ISAPI filter entry from IIS manager
4. Giving full control to IIS_IUSRS and Users to inetpub folder.
None of these things seem to work.
The error message says it is unable to read the following part of the web.config file (requestfiltering is highlighted in red)
I have tried using the workaround you have explained, but I am not sure what Application path should be used. Please help me resolve this issue.
Thanks,
AP
Az elmúlt időszakban több alkalmazást migráltunk Windows Server 2008-ra és IIS 7-re. Volt olyan, amelyik
Thanks…. a lot.
HTTP 401 is a common error code you may see in an error page. While 401 has a few sub cases, 401.1 is
“ASP.NET Integration with IIS7” is broken.
The links seem to have changed. The new link is http://learn.iis.net/page.aspx/243/aspnet-integration-with-iis7/.
I’ll update the post.
Thanks for the note –
Mike
Hi Mike,
I had 404.15 error while trying login with windows auth. My application worked fine with certificate, username&pass and DA. Bu it failed with windows auth. I tried with next commands:
%windir%system32inetsrvappcmd set config -section:requestFiltering -requestLimits.maxAllowedContentLength:1000000
%windir%system32inetsrvappcmd set config /section:requestFiltering /requestLimits.maxQueryString:4096
Now, I cannot even run my home page to chose other type of login…
Pls heelp 🙂
Hi Mike, part of the problem is fixed… I deleted whole line with requestLimits, and of course restarted computer. But I still cannot do login with win auth. :S
IIS 7 changed fundamentally since IIS 6. Here are some links that might help you when you feel lost with
Hi Mike, I have a slightly different probem. I have a native module that should intercept requests at the BeginRequest stage (the requests are also consumed by other native and possibly managed modules). I find that if I hook in post auth stage, the requests go fine, but in earlier stages like BeginRequest, I get 503s returned. Any idea? Thanks
Absorb,
You need to get the detailed error and figure out what exactly is going wrong. It sounds like your module is causing an AV that in turn is causing the application pool to become disabled.
Run your module under a debugger to see where it happens.
Thanks,
Mike
Thanks Mike. I actually found out that it fails whenever an E_FAIL error code gets returned from the RegisterModule fn. I tried returning an E_FAIL in the RegisterModule immediately after we enter and I get the same result: no response to a request for a while and eventually a 503.
Are we supposed to only report back S_OK and above in the RegisterModule? Also note that I have not subscribed to any event notifications at the point (since i return with an E_FAIL immediately). Thanks.
Yes of course. If RegisterModule fails, the worker process will fail to start, which will eventually lead to your apppool being disabled/503 responses after start is attempted 5 times.
In general, S_FALSE and S_OK are the only success HRESULT codes you can return, and I recommend always using S_OK. IIS is very strict about failures – it doesnt subscribe to the “best effort” philosophy of ignoring error return codes and trying to load/execute anyway.
Thanks,
Mike
Thank you for submitting this cool story – Trackback from Fairfeeds.com
hi,
I just want to know one thing.
Is or isn’t possible to impersonate in IIS 7? Whatever I do a get the same result. The process is running on the system account in the classic mode and always is visible in the taskmanager. I’ve tried everithing. Im a web developer with a iis 7 issue since last week. On iis 7 and iis 6 its really possible.
Can you help me with this??
Rafael,
It is definitely possible to impersonate. IIS supports a variety of execution identity modes depending on your application.
You can configure the ASP.NET application to impersonate the currently logged on user (if Anon/Basic Auth/Windows Auth is being used). ASP applications automatically impersonate the logged on user. The Integrated mode impersonation issues have to do with the inability to impersonate in early stages of the ASP.NET pipeline, which wont be an issue unless you have custom modules that rely on impersonation.
By default, IIS worker processes run under the Network Service account, and so does all other code that doesnt impersonate (including ASP.NET if impersonation is not enabled).
Note that impersonation happens per request and is not visible in the task manager. Only the application pool identity is since thats what the IIS worker process runs as.
NOTE that you should NEVER be running your IIS application pool as the LocalSystem account. The identity of the worker process depends entirely on the configured IIS application pool identity and has nothing to do with Classic/Integrated modes.
I suggest you read the security chapter in the IIS7 resource kit book to understand this further.
Regards,
Mike
This is a great post.
Other websites use %systemroot% and I tried like so many times but still not working.
I found your blog and you use %windir% where it solved my problem immediately.
Thanks.
ASP.NET 2.0 Breaking Changes on IIS 7.0
Helpful Info !
Has anyone had the issue where integrated mode causes the / on the end of your base url (http://www.example.com/) to require authentication and redirects to your login page? And if so does anyone have a solution or workaround?
http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes- ASP.NET -2.0-applications
I did have an error in my web.config file, which when fixed worked fine.
I changed the true in ‘‘ tag with So instead I declared it with false and it worked.
Migrated this BlogEngine.net Blog to Windows Server 2008… Not Bad
Migrated this BlogEngine.net Blog to Windows Server 2008… Not Bad
Migrated this BlogEngine.net Blog to Windows Server 2008… Not Bad
Lors d’une migration d’un projet existant sur Azure, le principal stress, c’est de savoir si votre application
This was an excellent post, clear and precise. It’s very valuable even today.
Hi Mike,
We have a web application developed in vb.net ,Asp.net,XSL,XSLT,XML,SQL SERVER(framework 2.0) and it is currently working fine in
32 bit environment.
We are getting following errors when we deploy our web application in Windows Server 2008 R2 Standard Edition (64 bit environment) OR when we try to convert our web application as x64 bit application by recompiling our code base in x64 bit platform(VS2005 – x64 compiler settings).
Error found in HTTPERROR log:
2010-08-26 12:24:56 ::1%0 51679 ::1%0 80 HTTP/1.1 GET /webview5439/Default.aspx – 1
Connection_Abandoned_By_ReqQueue .Net+2.0+App+Pool
Error found in IIS Log:
2010-08-26 13:33:17 ::1 GET /webview5439/Default.aspx – 80 – ::1 Mozilla/4.0+
(compatible;+MSIE+8.0;+Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5
.30729;+.NET+CLR+3.0.30729;+.NET4.0C;+.NET4.0E) 500 22 50 1015
Also we are getting a warning msg while recompiling our code in x64 code base platform(by changing all the dll reference to framework64 path).
vbc : warning BC40010: Possible problem detected while building assembly ‘‘: Referenced assembly ‘mscorlib.dll’ targets a different processor ‘: Referenced assembly ‘System.Data.dll’ targets a different processor ‘: Referenced assembly ‘System.Web.dll’ targets a different processor
vbc : warning BC40010: Possible problem detected while building assembly ‘
vbc : warning BC40010: Possible problem detected while building assembly ‘
We are looking forward your technical advice on this.
Thanks in advance
Mike, you indicate that in Classic mode that we should still be able to use Windows/Forms auth concurrently on the same site. We have an app (currently running IIS6) in this situation that has most of the site running forms auth, but a specific subfolder enabled with Windows auth with a single page to pick up the user’s credentials. In trying to run this locally on VS 2010/Win 7, it works fine within the built-in Cassini web server, but I cannot configure IIS to use Windows auth on the subfolder, even though I put the app in the Classic app pool. Any ideas of how I can run this legacy code within the Classic app pool?
Thanks for the informative post.
Another error: Integrated Pipeline Mode does not support HttpRuntime.ProcessRequest.
You listed all the changes in behavior that you may encounter when deploying your ASP.NET applications on IIS 7.0 on Windows Vista and Windows Server 2008 which are very useful and easy to understand. Thanks for posting and sharing your knowledge with us.
http://gloriatech.com/microsoft-net-development-services.aspx
Appreciate it for helping out, excellent info .
Thanks – this article quickly solved my problem
great article
Dans son article ” Breaking Changes for ASP.NET 2.0 applications running in Integrated mode on IIS 7
You can find this week’s video here . IIS 7 has two application pool pipeline modes: Classic and Integrated
Very good article, it’s useful.
Thanks!
very useful article.
manele noi
manele noi…
[…]Breaking Changes for ASP.NET 2.0 applications running in Integrated mode on IIS 7.0 « Mike Volodarsky[…]…
Hi. Great article. By the moment I”m still trying to make my application to work in classic mode. It was running ok under II6, but my client moved to W2K8/II7 and a problem appeared.
I use FormsAuthentication. I check for the auth cookie un authenticate_request event. Get the cookie, manually decrypt it, check expiration, and get userData with serialized aditional user information. If everything is ok, I replace httpcontext Principal. If the user logs out, I perform just a simple FormsAuthentication.Signout() to destroy cookie.
Web.config is set to Authentication mode= Forms and login page set to login.aspx.
Now with II7 I get a strange behavior. First request is detected as unauthenticated user and well redirected to login.aspx. The user logs in, and everything is allright. Then the user logs out, but next request detects the user logged with Active Directory user. The system shows DOMAIN/user as logged in, no permissions and profile is loaded (the user doesn”t exists) and no login.aspx redirection happens. The user gests stacked there and can”t login anymore.
Any idea?
Thanks
GENIUS!!! Switching pools for a stupid error in the web.config? Thanks you save me from going down the wrong path.
Great info. Lucky me I came across your blog
by accident (stumbleupon). I”ve book-marked it for later!
Is there way to access HttpResponse.Headers in classic mode?
or, How to remove Server header in classic mode?
Hi, i keep getting soap exception on iis7, (net asp version 4 framework4 integrated mode) while on iis 6 on local machine everything works good.
I’m using win form client that calling this web service. The error i get is only on the client: “There was an error generating the xml document”.
Thanks
Link gives 404, should be updated to http://mvolo.com/iis-70-twolevel-authentication-with-forms-authentication-and-windows-authentication/
Lab 7: Integrated versus Classic mode | The Best C# Programmer In The World - Benjamin Perkins
[…] this article about Breaking Changes between Classic and Integrated […]