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
Related
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 have set two websites in my IIS 8.5. I have one for production version and one for development (need this for the team work purposes). The structure is simple. Website is simple static page using BackboneJS and API calls to get all the data. All virtual paths and applications were set at the beginning manually by my self. For some reason some API calls didn't worked in dev site. I found out the physical path to the API project has changed. Do you have any idea, where can be the problem? Actually some of my collegues face this issue too.
Only think that cames to my mind is that when bdebugging the API, I use "Attach to process" in Visual Studio, where I connect to the correct IIS process - w3wp.exe with user name IIS APPPOOL\Dev or IIS APPPOOL\Prod according to the site I'm debugging.
Nevertheless I don't think the path should change itself. Where can be the problem? Does anyone have any idea how to prevent this strange behaviour?
In short, I have three servers in a web farm, one of which is configured as a State Server. Two of the servers (including the State Server) are correctly sharing session state, but the other server is holding it's own session still.
Here's what I've done:
I have modified the web.config.comments file on all three servers so that they have the same machineKey entry.
On the State Server, I have changed the AllowRemoteConnections registry entry to 1. I then set the ASP.Net State Service to start automatically and switched it on.
The web site is configured on all three servers and the root site shares the same Identifer in IIS. Each configuration is identical. The website itself is contained on a network share, so the same web.config file is used on all three servers. I changed the sessionState entry in the web.config to point to Web3.
So Web2 and Web3 are able to set/modify/destroy the same session, but Web1 is still running with it's own.
I'm at a loss here after hours of Googling, so any help is greatly appreciated.
This application is configured a few subdirectories into the root site. Is there a separate AppID at this level? If so, how can I find it?
Thanks,
Aaron
http://support.microsoft.com/kb/325056
To maintain session state across different Web servers in the Web farm, the application path of the Web site (for example, \LM\W3SVC\2) in the Microsoft Internet Information Services (IIS) metabase must be the same for all of the Web servers in the Web farm. The case also needs to be the same because the application path is case-sensitive.
On one Web server, the instance ID of the Web site where the ASP.NET application is hosted may be 2 (where the application path is \LM\W3SVC\2). On another Web server, the instance ID of the Web site may be 3 (where the application path is \LM\W3SVC\3). Therefore, the application paths between Web servers in the Web farm are different. For additional information about how to check the application path of the Web site, click the following article number to view the article in the Microsoft Knowledge Base:
240225 Description of Adsutil and MetaEdit Used to Modify the Metabase
This is not really answering your question, but in my experience the ASP.NET session state service is not something you should scale to more than one server. It doesn't perform very well (especially under load) and is difficult to configure. I found that a distributed cache such as memcached is much simpler and faster for this purpose.
Have a look at this project.
matthewk's answer actually turned out to be almost the correct one. Over a year later I've returned to this and found the answer. Though probably correct, I felt that if the answer above had been more specific I would have solved this!
I searched through the MetaBase.xml file (C:\WINDOWS\system32\inetsrv) for the web application. After a game of spot the difference I noticed that there was a slight difference in the following line:
<IIsWebVirtualDir Location ="/LM/W3SVC/103071637/root"
AccessFlags="AccessRead | AccessScript"
AppFriendlyName="Default Application"
AppIsolated="2"
AppRoot="/LM/W3SVC/103071637/Root"
...
Specifically, the AppRoot (not the Location) on Server 1 had a Proper-Case "Root" whereas Server's 2 and 3 had "ROOT" all in caps. I updated Server 1 to match and restarted IIS and it works a treat.
ie.
AppRoot="/LM/W3SVC/103071637/Root"
AppRoot="/LM/W3SVC/103071637/ROOT"
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.
So I figured out that by adding the ResetWebServer="FALSE" attribute to the solution manifest prevents SharePoint from recycling any app pools.
However, when upgrading a solution that originally did not specify ResetWebServer="FALSE" or when retracting a solution that does specify ResetWebServer="FALSE", the application pools are still being recycled. Is there a way to prevent any auto-recycling of app pools?
This does not seem possible given the document on MSDN (see below), note that I included Deploying a Solution over Upgrading a solution as underneath it is effectively doing a file replacement. I believe the restart/recycling is necessary as a result of how IIS functions. An option to explore if you wanted to manage when this occurs is to ensure that all deployments are done via timer jobs and execute when their impact will be minimized.
Deploying a solution
Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).
Retracting a solution
On each front-end Web server, the following occurs:
Microsoft Internet Information Services (IIS) is disabled.
Files are removed from the system.
IIS is re-enabled and Windows SharePoint Services is reloaded when
a user browses to a page.
You might also take a look at the "-local" switch. Didn't try it yet but it seemed that it allowed deployment server per server when you are in a load balanced situation.
Might be a good lead.