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.
Related
In order to update our IIS Site we delete then replace contents of the associated physical path. However, sometimes we are not able to dele some files and/or folders as they are "being in use".
How should we proceed in such cases?
It depends on the application you used.
If you use asp.net application, you can replace the content of sites directly. When asp.net application was deployed on IIS at beginning, IIS will load it firstly and create a shadow copy in temp file. All requests will be handled by the shadow copy. When you update the files, it creates a new AppDomain to service any new requests, and signals the previous AppDomain to shut down as soon as it has finished servicing any current requests.
If you use asp.net core application, you need to stop application, then update it. Asp.net core application is different from asp.net application. It actually runs in kestrel. IIS just acts as a proxy to forward requests to kestrel.
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
[I'm posting this to record what I actually found out after hours of painful trial-and-error.]
I have a website that I need to be "always running" (because in this case it has a Hangfire job that's responsible for kicking off a scheduled task every 5 minutes), and by default, websites are only started up when the first request is received.
So, how can I ensure that the website is started automatically? And, how can I configure this via the TFS release management tool?
[This answer isn't specific to Hangfire, but see the Hangfire documentation's discussion of this issue for details of how it affects Hangfire, but note that the recommended work-around is somewhat involved, and much more complex than the solution below. See also a separate and quite comprehensive discussion on the Hangfire support forum that gives several alternative solutions.]
In IIS, each website is associated with an Application Pool (App Pool). You can configure your App Pool to start automatically via IIS Manager by changing the "Start Mode" to AlwaysRunning in "Advanced Settings" for the App Pool:
However, starting the App Pool doesn't start the website (or websites) associated with it. The website does not get loaded until the first request is received.
In IIS8 (or IIS7.5 with an extension), a new setting was added that allows us to work around this. You can ensure that the website gets sent a request as soon as the App Pool starts by setting "Preload Enabled" to True in "Advanced Settings" for the website:
The combination of these settings ensure that the website will automatically start up when IIS starts, and immediately after the App Pool is recycled, etc.
But, how can you get those settings applied automatically as part of a TFS release pipeline, rather than having to remember to set them manually?
In your release definition, you presumably have an "IIS Web App Management" task, which sets up the App Pool and the website. In the configuration panel for this step, there should be an "Advanced" box with an "Additional AppCmd.exe Commands" entry field. You can use AppCmd to apply the settings described above.
AppCmd has the most confusing command-line syntax I've yet seen outside of code-golf competitions, but here's the incantation that worked for me:
set config /section:applicationPools -[name='myAppPoolName'].startMode:AlwaysRunning
set app "mySiteName/" /preloadEnabled:true
Note that if you have configuration variables defined for your App Pool name and website name, then you can use those rather than hard-coding the name, such as:
set config /section:applicationPools -[name='$(appPoolName)'].startMode:AlwaysRunning
I hope this helps somebody... Thanks for listening :-)
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
I need to determine WHY the application pool is recycling. (its for no obvious reason)
Is there any way to determine this inside of the application_end sub in the global.asax file?
I have put some basic logging in there, so I know WHEN its shutting down, but I cannot tell why.
(and its nothing obvious... it just seems like every couple of requests certain operations cause the application to end. I have turned off every normal reason for recycling such as time outs, memory checks, etc, etc, etc. Same code is working fine on a different server, so I am sure its something wrong with this setup, but what?...)
You don't have to incur overhead to add custom logging, ASP.NET 2.0 health monitoring does the job for you. You can add the following configuration which will log events in the eventlogs with information why Application pool is restarted.
To turn ASP.NET health monitoring ON, you can edit the "master" web.config file, normally found in %systemroot%\microsoft.net\framework\v2.0.50727\config.
First, look for <healthMonitoring> in the master web.config
Inside the healthMonitoring node, find the <rules> node
Inside rules, add the following:
<add name="Application Lifetime Events Default"
eventName="Application Lifetime Events"
provider="EventLogProvider"
profile="Default"
minInstances="1"
maxLimit="Infinite"
minInterval="00:01:00"
custom="" />
Reproduce the issue and look in the Application event log fpr a source of ASP.NET 2.0. This should log why application pool is recycled.
Try looking in the EventLog. When the app pool recycles, there is an entry written to the log along with the reason.
The following link describes the errors codes you'll see in the eventlog for IIS 7.5
http://technet.microsoft.com/en-us/library/dd349270(WS.10).aspx
If there are not already log entries in your troubled machine's event viewer, you can modify IIS to log all app pool recycles.
Article from Microsoft on how to do it is found below
http://support.microsoft.com/kb/332088