Simplifying Development With Process Isolation

In earlier versions of IIS, all ISAPI applications (including ASP) shared the resources and memory of the server process. Although this increases performance, unstable components would often cause the server to crash--not an acceptable behavior for a mission-critical application like IIS. To make matters worse, in-process components couldn't be unloaded unless the server was restarted—which meant that modifying existing components would effect all sites that shared the same server, whether they were directly effected by the upgrade or not.

Thanks to close integration with Microsoft Transaction Server, IIS 4.0 applications can now be started in an isolated process. There are two reasons for doing this: component development and fault isolation.

Component Development

Rather than taking down the entire server to update a single component, process isolation allows you to stop and restart just a single application. To add an updated component to an application, or an entirely new application, you had to stop the Web server service, replace the old DLL with your new version in its shared location on the server, and restart the Web service again. Now with an isolated process, you can update a production Web site without shutting down your system.

Fault Isolation

Process isolation limits the effects of such a crash to the single application that caused it. In addition to protecting your server from the crash, the application can be configured to restart automatically as often as you like. In the case of an application fatal error, the application's process is automatically terminated. Since the application is running in the MTS system process, all transactions in progress are aborted. The system event log stores a record of the event, and MTS restarts the application. The only ones affected by the failure are clients with outstanding requests to that specific application.

An IIS application runs in the IIS process by default. If you decide to run your application as a separate process, you will need to mark your application to Run in separate memory space on the Virtual Root property page. You must first create an application for your virtual root, if you haven't already done so. Components that are to run in the new process must be installed into the appropriate MTS package. For more information, see Creating MTS Packages.

Out-of-process Components

Note that out-of-process applications are different from out-of-process components, executables that are launched from within another application. When Server.CreateObject is used to launch an EXE, the following error may occur:

Server object error 'ASP 0196'
Cannot launch out of process component
/myvroot/launch_exe.asp, line 16
 

This error is the result of a safety mechanism in ASP that prevents the unauthorized launching of executables from within ASP. Not all executables are safe to use on the server, and may pose security risks as well. Because in-process components are faster, more secure and can be hosted by MTS, they are much better suited for server-side use.

If you still want to enable the use of out-of-process components, you must first set the AspAllowOutOfProcComponents metabase property to TRUE. This metabase setting is accessible on both the IIsWebService and the IIsWebVirtualDir Admin objects.

• Take note that if you set the AspAllowOutOfProcComponents property to TRUE on the IIsWebService object, all in-process applications will be able to launch executables from script. An in-process application is a directory that has been marked as an application starting point, but which does not have the Run in separate memory space option selected.
• If you set the AspAllowOutOfProcComponents property to TRUE on the IIsWebVirtualDir object, and the application is marked to Run in separate memory space, only the affected application may launch executables from script. If the application is set to run in process, the setting will have no effect.

The following ASP code demonstrates the steps required for setting the AspAllowOutOfProcComponents parameter on the IIsWebService Admin object.

Note  You must have adequate permission to modify the metabase. If you attempt to modify the metabase from an ASP script without sufficient privileges, you may encounter an Invalid Syntax or other error. In order to modify the metabase from script, you must first require authentication as a user with administrative rights.

<%
   ' Get the IIsWebService Admin object
   Set oWebService = GetObject("IIS://LocalHost/W3svc")

   ' Enable AspAllowOutOfProcComponents
   oWebService.Put "AspAllowOutOfProcComponents", True

   ' Save the changed value to the metabase
   oWebService.SetInfo
%>
 

Important  You will need to restart the Web server service after making this change.

For more information about setting metabase properties using the Admin objects, see the section entitled IIS Adminstration in the Programmer's Reference.

Security Considerations for Out-of-Process Applications

Out-of-process applications and components, including ISAPI filters and extensions, will not be able to access metabase properties. This restriction is primarily one of security, and exists to prevent unauthorized changes to the metabase. If you want to allow out-of-process applications to access the metabase, you must do one of the following:

1. Give the IWAM_<machine> account access to the metabase (this is probably a bad idea from a system security standpoint.)
2. Change the identity of the out-of-process MTS package from the interactive user to a specific user account, and give that account access to the metabase (this is also somewhat risky, but limited to a single package.)

For more information on changing package identity, see Setting MTS Package Properties in the Microsoft Transaction Server documentation.