views:

189

answers:

2

Having moved our ASP.NET site from 32-bit Windows Server 2003/IIS6 to 64-bit Windows Server 2008/IIS7 (classic mode), certain active directory operations are intermittently experiencing huge delays.

Specifically, DirectorySearcher.FindOne() and DirectoryEntries.Children.Add() sometimes take up to 40 minutes to complete. These problems seem to be triggered by app pool recycles after periods of inactivity, and go away once the site has been in use for a while.

The site goes through phases where these active directory operations work for all users, and then where they fail for all users - i.e. the problem isn't client-specific, it's a server issue.

A: 

Please setup ASP.NET 2.0 Classic mode for the Application Pool you are using or create new one and apply that, we had similar problem as IIS 7 has new pipelined mode for request processing that is quite new and still there is no clarity of how it will affect existing web apps that use internal session variables and some other custom modules.

IIS 7's new Pipelined app pool does have problem with custom modules and we had to turn it off till we could find any more information.

It seems that pipelined architecture will only work for absolute stateless pages, that uses no session and application variables.

EDITED: Another problem could be IIS 7 has different timeout values because they need to be specified in different tags, in web.config you will see new system.webserver tag that is only specific to IIS 7. Try exploring them.

Unfortunately current MSDN doesnt list any of them, we also had connection timeout issues which was set only for 120 seconds, but we came to know that when users do long uploads the session breaks because the timeout reaches sooner for bigger files.

Akash Kava
Thanks, but I should have mentioned that we are already running in Classic mode, sorry.
kasey
Another problem could be IIS 7 has different timeout values because they need to be specified in different tags, in web.config you will see new system.webserver tag that is only specific to IIS 7. Try exploring them.
Akash Kava
Can you find any information in the Event Logs?
Akash Kava
There's nothing in the event logs, unfortunately. I'm not sure if timeouts are likely to be the culprit because when it works, the user logs in within a couple of seconds, but when it fails, it takes a good several minutes before giving up. But I will spend some more time looking at the various new settings.
kasey
A: 

This sounds like the Forms Auth Ticket Timeout and the Session Timeout are being treated as one in the same. They are not. If your forms auth is valid it doesn't mean your session state is. Here is an example of someone having the same problem:

I have a site that relies on Session State to store a couple of small bits of information and uses Forms Authentication. I was getting errors (Not an instance of an Object) in places I thought was impossible. It seemed that the Session was invalid in places where it should not be.

Turns out that I had used the default Forms Login timeout that VS.NET provided (30 minutes) and the person who set up the Web server (or perhaps this is a default) set the session timeout in IIS to 15 minutes. I had assumed that both were set to 20 minutes as a default. This seems to have been the cause of this sporadic problem (which cropped up only when people were logged in and did nothing for between 16 and 29 minutes).

rick schott
Thanks for the suggestion, but I think the problem you describe is different from mine because my users cannot log on in the first place - it's not that an existing session is timing out. It's like the actual authentication process is failing in some way.
kasey