Configure "DisallowOverLappingRotation = True" in IIS when protecting IIS with a Siteminder Web Agent
search cancel

Configure "DisallowOverLappingRotation = True" in IIS when protecting IIS with a Siteminder Web Agent

book

Article ID: 278408

calendar_today

Updated On: 05-20-2024

Products

SITEMINDER

Issue/Introduction

Occasionally,  the Siteminder Web Agent on an IIS server may be found not running, even though the w3wp.exe process for IIS is running.  A Stop/Start of the IIS instance may not resolve the issue.  A restart of the server at the OS level will resolve the issue.  

When this occurs, users will get HTTP 500 errors when they attempt to access a resource hosted on that IIS which is being protected by the Siteminder Web Agent.

Environment

[SITEMINDER]

Component: Web Agent for IIS

Web Server: IIS

Web Server OS: Windows Server

Cause

What is occurring is that  the Application Pool is recycling as part of the normal IIS functional spec.

Application Pools recycle for the following reasons:

====================
[Application Pool Recycling]

- App Pool Changes

- ISAPI Reported Unhealthy

- Manual Recycle

- Private Memory Limit Exceeded
-> (Contingent on 'Private Memory Limit' being set)

- Regular Time Interval
-> (Contingent on 'Regular Time Interval' being set)

- Request Limit Exceeded
-> (Contingent on 'Request Limit' being set)

- Specific Time
- Virtual memory Limit Exceeded (Contingent on 'Virtual Memory Limit' being set)

--------------------------------------
Private Memory Limit (KB): (default = 0 (unlimited)
Regular Time Interval (minutes): (default = 1740)
Request Limit: (default = 0 (unlimited)
Virtual Memory Limit (kb): (default = 0 (unlimited)
--------------------------------------
====================

In IIS, the web server is assigned to an Application Pool, that Application Pool dictates the configuration and behavior of the web site. Each website has its own application pool, and each application pool has its own user identity. This configuration I would normally strongly suggest.

Some of the behavior reported, is that there is an orphaned LLAWP process which is tied to the PID of a w3wp (IIS) process of which that PID no longer exists. This forces a work-around process of stopping IIS and killing the orphaned LLAWP process, or restarting the OS to recover. When this issue occurs, the web browser (user) gets HTTP 500 errors and cannot access the web resource.

What I strongly believe is occurring is as follows:

- IIS is started, then a request is sent to IIS.

- IIS matches the hostname or IP and tcp port to determine which site to hand the request too.

- The application pool tied to that site invokes the IIS 'w3wp.exe' process.

- If the siteminder web agent is configured for that web site and is enabled, then IIS invokes the web agents's 'LLAWP.exe' process as a child process of the 'w3wp.exe' process.

- NOTE: Whether in Classic or Integrated Pipeline mode, the web agent is essentially an ISAPI filter which processes the request.

- At some point, the application pool is required to recycle (see reasons above). The Application Pool Recycle process is a 'graceful' process. Rather than abruptly abending a transaction, the process completes the current transaction before recycling.

- The w3wp.exe process recycles and instructs the LLAWP.exe process to recycle gracefully. The LLAWP.exe process continues to complete its transaction.

- The new w3wp.exe process is started. Once online, invokes a new LLAWP.exe 'child' process.

- The new LLAWP process initializes and finds the previous LLAWP process running. Since Siteminder doesn't support concurrent processes, the new process goes offline.

- NOTE: w3wp.exe process only ever attempts to invoke the LLAWP process during initialization. Once the LLAWP process has failed, the w3wp process continues running.

- IIS processes a request and hands it to the appropriate w3wp.exe process. When IIS sends the request to the ISAPI filter, that filter is not running.

- IIS returns an HTTP 500 (ISAPI filter Error) back to the web browser.

- IF there are no orphaned LLAWP processes running, then stopping and starting IIS can sometimes recover the condition. When the new w3wp process starts, it then invokes the LLAWP process. Provided there are no constricts with a concurrent process, both start successfully.

-If there is an orphaned LLAWP process, then typically you would need to stop IIS. Kill the remaining LLAWP process(es)., then start IIS again. A server reboot would also clear all the processes and open PIDS.

 

Resolution

Configure the Application Pools tied to web sites protected by Siteminder to disallow overlapping rotation of processes during a recycle.

1) Log on to the IIS Web Server

2) Launch IIS Manager

3) Open Application Pools

4) Select 'DefaultAppPool', then select 'Advanced Settings'

5) Scroll to the 'Recycling' section at the bottom and set [Disable Overlapped Recycle = True]

6) 'Click' OK

7) Select 'SiteMinderAppPool', then select 'Advanced Settings'

9) Scroll to the 'Recycling' section at the bottom and set [Disable Overlapped Recycle = True]

9) 'Click' OK

10) Stop the IIS instance

11) Make sure all w3wp.exe and LLAWP.exe processes have all stopped (Kill any that will not stop).

12) Start the IIS instance.

Additional Information