What is the different between Session Timeout and Idle Timeout in IIS? - iis

In IIS, Select Default Web Site > Properties > Home Directory > Application Settings > Configuration > Options, the default Session timeout is 20 minutes. Also, Select Application Pools > DefaultAppPool > Properties, in the Performance tab, there is Idle timeout which is default to 20 minutes too. What is the different between those two timeouts?

The idle timeout determines if, and if so after how many minutes of idle time an AppPool is recycled. Recycling the AppPool frees resources but also means that all cached data (compiled version of ASP.NET applications etc.) of sites that run under that AppPool need to be regenerated when the site is requested again (this can take up to several minutes).
The session timeout setting determines how long a session is valid. Please note that session timeout is only applied to classic ASP (not ASP .NET).
Edit:
The session timeout setting seems to apply to ASP.NET applications as well. You can find a detailed desciption here.
Edit 2:
To clarify this: There are two session timeout settings in IIS. One setting is applied to Classic ASP applications and the other for ASP.NET apps. The former can only be set using the ASP panel if Classic ASP is installed (IIS >= 7 comes without Classic ASP by default).

Related

Why is w3wp.exe looking through my dotnetcore api path to find web.config?

Using IIS 7 with a deployed dotnetcore 2.1 or 3.1 web API alone in an application pool, we discovered while looking at Process Monitor on the server, the w3wp.exe workers were logging many errors where they were apparently looking for a web.config. They checked every route in the api's route. The expected behavior was that the w3wp.exe (an IIS worker) would "hand off" the request to the dotnetcore application's routing, which would find the endpoint, but instead, it appeared to be also checking for a web.config. The process monitor revealed w3wp.exe QueryOpen NAME NOT FOUND and PATH NOT FOUND errors.
I looked at a few articles and concluded it was a problem with web.config inheritance, and there must be some setting in IIS or a dotnetcore configuration that was dictating the behavior of checking each API route path as if it were a virtual directory folder system that might contain a new web.config. The benefit would be that you could have a different web.config in a sub-application, but we didn't want that benefit and we didn't want these IIS workers blowing up the logs with thousands of these errors throughout the day. We found an insanely simple solution that an IIS admin might say "duh" but will hopefully save someone out there some time.
We found the answer on an old blog.iis.net post about web.config inheritance (https://blogs.iis.net/steveschofield/control-web-config-inheritance-with-iis-7-asp-net-options). There is a configuration called allowsubdirconfig that directs the w3wp.exe worker to check subdirectories for a web.config file. Here's how you change it in IIS applicationhost.config that can be found through IIS Manager:
Go to configuration editor
Go to system.applicationHost => sites => virtual directory defaults
Set allowSubDirConfig to False
We also discovered that Microsoft recommends you use this setting for hosting dotnetcore applications on IIS
Skipping the additional file operations can significantly improve
performance of websites that have a very large set of randomly
accessed static content.
https://learn.microsoft.com/en-us/previous-versions//dn529134(v=vs.85)?redirectedfrom=MSDN
Keep in mind, if you use this setting, you'll need to come up with a solution to separate applications that use or don't use the setting.
Related issue with MVC:
ASP.NET MVC security and IIS allowSubDirConfig configuration

For web.config update, is an app pool cycle required on IIS 7.5?

After a web.config is updated on a Windows Server 2008 R2, IIS 7.5 site, does the app pool automatically cycle? If so, is the cycle based upon a set of time or does this happen immediately? Just want to know if I need to force an app pool cycle to see a web.config change within a minute or two.
Short answer, no... the application pool doesn't recycle when the web.config is updated.
Explanation
Application Domain is the one that gets recycled. If you check the Application Pool settings in IIS, it will list the conditions under which the pool is supposed to recycle.
Application domain recycle, on the other hand is a virtual entity. It gets recycled under various conditions. Web.config change is just one of them. Read more about it here and here

ASP Error 0223 - TypeLib Not Found, intermittent, resolved after IIS restart

I'm currently in the process of migrating an ASP platform from Windows 2003 R2 IIS 6 web servers to Windows 2012 R2 IIS 8.5 web servers. I'm at the stage where I've migrated a number of sites across to two separate 2012 web servers, all looked great, clients and developers are happy... However the following error has presented itself after a few days hosting on one of the new servers.
Active Server Pages error 'ASP 0223'
TypeLib Not Found
/jobboard/conf/constants.vbs.inc, line 1
METADATA tag contains a Type Library specification that does not match any Registry entry.
The METADATA tag is below:
<!--METADATA TYPE="typelib" NAME="Microsoft ActiveX Data Objects 2.8 Library" UUID="{2A75196C-D9EB-4129-B803-931327F72D5C}" VERSION="2.8"-->
Restarting IIS on this server resolved the issue (albeit temporarily).
Subsequently the other 2012 web server in production presented the same error a couple of days later, again, restarted IIS and works for now.
I've checked the registry and the relevant tag exists with the right UUID and correct permissions.
It doesn't affect all sites on the server, only all sites in a particular application pool.
The application pools use a domain user identity and sites are split up into a number of shared pools.
I've now determined what was causing the above problem...
Our sites on IIS run in a number of shared application pools running as a domain user. We also have a Windows scheduler job which runs a number of scripts over night which also run as the same domain user.
It seems there are cases when this scheduler job runs it interferes with the IIS worker processes. When it completes and ends its user session it unloads the registry file in memory, which the w3wp.exe processes could also using.
This error is presented in the Event log...
Windows detected your registry file is still in use by other
applications or services. The file will be unloaded now. The
applications or services that hold your registry file may not function
properly afterwards. No user action is required.
Along with references to the w3wp.exe processes currently running.
It was replicated when I terminal serviced in as the domain user and logged out again after a period of time. The event log presented the error and the sites all bombed shortly afterwards.
Running the scheduled job as a different user has fixed this issue for us.
I remember having an include file for ADOVBS.inc with all the ADO constants inside and including it as a standard ASP include inside my global include file which is included on every page on the site.
This was before I used the META way of including the file.
So maybe a last resort is to revert to that method of loading in the ADO constants.
It seems like some sort of threshold is being hit, CPU/Memory?, which then prevents IIS caching/loading the file in from the registry. This then causes the error and a recycle of the pool. As no redirect is being done to the 500.100.asp error handler page which hides the error details from the user. It would suggest the error is in IIS and related to the server.
Thanks

how to debug iis 7.5 application pool?

I'm having a problem with my IIS 7.5. problem that maybe I have caused yesterday after playing with application pools.
The problem is that website become very slow and the only way to fix it is to recycle the application pool.
When i try to access HTML file it's working fast but when i access classic ASP file it takes long time to load "Waiting for"
When i recycle the pool the problem solved for few seconds or minutes and my question is how do i debug it ? how do i know what cause the application pool to stuck ?
you always have the possibility to debug classic asp applications.
set the debug properties in your iis for your web application like so:
server-side Debugging active: true
then you can use the "stop" keyword in your classic asp files to set a "breakpoint". a popup will be raised to ask you how you want to debug your asp file (e.g.visual Studio)

Is there a way to configure the Application Pool's "Idle timeout" in web.config?

I know one can set the session timeout. But, if the application itself has received no requests for a given period of time, IIS shuts down the application.
This behavior is configurable in the IIS management console, and I know how to do this. Still, I wonder if it is possible to configure this in web.config.
Not in IIS 6. In IIS 6, Application Pools are controlled by Worker Processes, which map to a Request Queue handled by HTTP.sys. HTTP.sys handles the communication with the WWW Server to determine when to start and stop Worker Processes.
Since IIS 6 was created before .Net, there's no communication hooks between .Net and the low-level http handlers.
ASP.net is implimented as an ISAPI filter, which is loaded by the Worker Process itself. You have a chicken-before-the-egg issue if you are looking at the web.config controlling a worker process. This is primarily why MS did the major re-write of IIS 7 which integrates .Net through the entire request life-cycle, not just the ISAPI filter portion.
You can edit these settings, but not in web.config. If you have IIS7, the setting is in applicationHost.config, and the key attribute is the shutdownTimeLimit.
You can google for it, to find out how to use appcmd and other tools to set or change it.
Example
Also you can directly modify the shutdownTimeLimit by editing the applicationHost.config file, which is in the \inetsrv\config directory.
The schema for the applicationHost.config file is in the \inetsrv\config\schema\IIS_schema.xml file.
So open it in your favorite schema-aware XML editor and you'll get intellisense, etc.
You can do it with setting IdleTimeout.
BUT changes to the processModel element take effect only when the worker process is restarted—not immediately after the setting is changed, as with other configuration elements.
You can see it here:
processModel Element
You also must change machene.config to can edit machine configuration from other archive.

Resources