Showing posts with label IIS. Show all posts
Showing posts with label IIS. Show all posts

Monday, 25 October 2010

The specified request cannot be executed from current Application Pool (403.18)

So you've split your apps into seperate app pools in IIS, which works well for app isolation on your web server and all is well until you start getting 403 HTTP status responses (with a substatus in the IIS logs of 18). This error is a result of your application running your application and the custom error page you've configured within different app pools.

The solution?

I'm afraid you're going to have to edit the registry!!! So back it up first then create a registry key with the name IgnoreAppPoolForCustomErrors, of type DWORD and value 1 under the HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ folder.

Thursday, 10 June 2010

IIS 6 Application Pools for Beginners

Application pools allow you to configure one or more web applications to a worker process. An application pool is separated from other application pools by worker process boundaries. So what does this mean? ...An application in one application pool is not affected by problems caused by applications in other application pools. This along with sensible recycling of your application pools, results in your web server being more efficient and reliable.

By default IIS 6 dumps everything into one application pool. So as you add new web applications to your server you should consider logically grouping them into pools. Due to there being an overhead for each application pool it makes more sense to group the web applications into related pools rather than just create a pool for each web application.

Recycling Your Application Pools

To keep your sites working efficiently your should configure IIS to periodically recycle your application pools and recycle them when they become unstable (using too much memory/cpu etc). Recycling cleans up memory fragmentation, memory leaks, abandoned threads and other bits of unwanted clutter. Note that when an application pool recycles, ASP.Net session state information stored in-process is lost for that pool, however other pools are not affected. If this is a problem then you'll need to use another session state mechanism for your ASP.Net web applications.

Application Pool Recycling Events

It's important that you review why your application pools are being recycling. For example, if you have a pool recycling every 30 mins due to excessive memory use then you have an issue with that applcation's code and it needs looking at. Event logs for application pools are off by default, to enable them see this Microsoft KB article.

Security

When you configuring your application pools you can configure the identity of each worker process to run as a different user and should consider how to configure application pools for application security. For example, you might need to create separate application pools for applications that require a high level of security, while allowing applications that require a lower level of security to share the same application pool.

Convinced?

Hopefully with this post you can see the benefits of spending some time in setting up your application pools in IIS and you've made a step in the right direction for improving your web server's reliablility and efficiency :)

Friday, 30 April 2010

Windows 2003 IIS Returns 404 for ASP.Net Pages

Had an issue on one of my virtual servers which wouldn't process any ASP.Net documents (aspx, asmx etc), but would just return a 404. However, it would happily return other resources such as htm, txt, css. There was no web application logging, no logs in event viewer I had nothing to go on, until I remembered I hadn't checked my IIS logs.

The logs showed requests for the ASP.Net documents and that a 404 was being returned. This part wasn't helpful but the logs also provide a sub status code which was 2:

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip sc-status sc-substatus 
2008-02-27 12:39:13 W3SVC2 127.0.0.1 GET /default.aspx - 80 - 127.0.0.1 404 2

A quick Google led me to Microsofts IIS 6 pages explaining the sub status codes - bingo!

404.2 : "Web service extension lockdown policy prevents this request"

Knowing this and with the power of Google I resolved the issue in less than a minute. Just open the IIS6 interface, select the Web Service Extensions menu node, on the right you will see the web service extensions available - just select the ASP.Net extension and click the allow button.

IIS Web Extensions Menu

Thursday, 8 April 2010

Running IIS in 64 Bit Mode

Internet Information Services (IIS) 6.0 supports both the 32-bit mode and the 64-bit mode (as long as your OS is 64-bit too!). However IIS 6.0 does not support running both modes at the same time.

  • ASP.NET 1.1 runs only in 32-bit mode (but who's still using this?!)
  • ASP.NET 2.0 (and up) runs in 32-bit mode or in 64-bit mode
  • To run ASP.NET 1.1 and ASP.NET 2.0 web applications at the same time, you're stuck with IIS in 32-bit mode unfortunately

So here's how I setup IIS and ASP.Net to run in 64-bit mode:

  1. Go to command prompt
  2. Disable the 32-bit mode in IIS using the command line argument: cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
  3. Install the 64-bit version of ASP.NET 2.0 on IIS using the command line argument: %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i
  4. Make sure that the status of ASP.NET version 2.0.50727 is set to Allowed in the Web service extension list in IIS Manager. If you had been using ASP.Net in 32-bit mode before, you may need to Prohibit that version ASP.NET version 2.0.50727 (32 bit) first.

Tuesday, 6 April 2010

Getting IIS to Forward All Requests to ASP.Net

Setting up IIS to send all requests to ASP.Net (e.g. for a HttpHandler for a ReST service or for an ASP.Net MVC web app) is straight forward with .Net and IIS.

1) First ensure that your web application can handle all requests

This is already done for you in an ASP.Net MVC web app. But if you are creating a custom HttpHandler to handle all requests you'll need to go to the httpHandlers section of your web.config file add a reference to your HttpHandler for all HTTP verbs and extensions:

<system.web>
   <httpHandlers>
      <add verb="*" path="*" type="your.assembly.reference"/>
   </httpHandlers>
</system.web>

2) Setup IIS to route all request to your handler

a) IIS 5/5.1 (Win XP)

  • Open the website properties in IIS
  • Select the Home tab
  • Click the Configuration button
  • In new window select the Mappings tab
  • Click the Add button
  • In new window's executable field Browse to the ASP.Net ISAPI dll (usually something like C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll)
  • In the Extension field type .*
  • Untick the Check that file exists box and click OK
N.B. There is a bug that if your OK button is not active you need to click the executable field text box, you should see the middle section of the text in the box change from /.../ to the full file path this should now make the OK button active.

b) IIS 6 (XP x64 & Windows Server 2003)

  • Open the website properties in IIS
  • Select the Home tab
  • Click the Configuration button
  • In new window select the Mappings tab
  • Insert an entry in to the Wildcard application maps with the ASP.Net ISAPI dll (usually something like C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll)
  • Untick the check that file exists box and click OK

You should now see all requests being handle via your handler. If you are having issues, you may want to look at your IIS logs - but where are my IIS logs?. Good luck!

IIS Returning 404s for ASP.Net Requests

This is a common error with new developer/server installs, where IIS (5 & 6) won't process any ASP.Net documents (aspx, asmx etc), but just return a 404. However, it would happily return other files such as htm, txt, css. Typically you won't get any application or event viewer logging, but just the often forgotten and rarely used IIS logs (see my article on Where Are My IIS logs? to find yours :)

The IIS logs show the requests for the ASP.Net documents and record a response status of 404 being returned. This part clearly isn't helpful, but the logs also provide a sub status code which were 2:

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip sc-status sc-substatus 
2008-02-27 12:39:13 W3SVC2 127.0.0.1 GET /default.aspx - 80 - 127.0.0.1 404 2

A quick Google led me to Microsofts IIS 6 pages explaining the sub status codes - bingo!

404.2 : "Web service extension lockdown policy prevents this request"

With the power of Google I managed to resolve the issue in less than a minute. Just open the IIS interface, select the Web Service Extensions menu node, on the right you will see the web service extensions available - just select the ASP.Net extension and click the allow button.

IIS Web Extensions Menu

Where Are My IIS Logs?

Although you may have bucket loads of logging taking place in your web applications/sites, the IIS logs can be helpful in certain circumstances. Use the following steps to track down these tucked-away log files:

  1. Open Internet Information Services (IIS)
  2. Right-click the desired web site and select properties
  3. On the Web Site tab, at the bottom is the Active Log Format; select the properties button next to it
  4. You'll now have a box that contains the log file directory and the log file name. Together they make the full log path.

In this window you can also change useful settings like what request/response details are recorded in the logs. Some useful options not selected by default are bytes sent, bytes received and referrer (useful for tracking 404s in certain cases).

Extracting useful info from these log files is another blog post all together ;)