IIS7 Session ID rotating with Classic ASP

I am trying to migrate a Classic ASP app onto a Windows 2008 R2 server.

The application features run fine, but I am having issue with session.

The application keeps the logged in user information in session and I am constantly getting knocked out as if the session had expired.

While debugging I have discovered the sessions are not expiring but instead I am getting 2-3 different Session IDs in use by one browser.

I am outputting Response.Write(Session.SessionID) on various pages in the application and I can sit there and hit refresh over and over and watch the number changed between these 2-3 SessionIDs randomly.

The sessions are still valid because when I refresh and get the Session ID that I logged in under the page is displayed (because the security check was successful) and when I get one of the other Session IDs I get the "you aren't logged in, you need to log in" message.

If I close and re-open the browser, same story just the set of IDs are new.

This happens with IE8, Firefox and Chrome from multiple computers.

Things I've tried:
- AppPool set to No Managed Code and Classic
- Output Caching set .asp to never cache
- ASP Session Properties enabled and disabled asp session state and confirmed it affected page (error trying to read Session.SessionID when disabled)

Things I've tried just in case but shouldn't have anything to do with ASP Session:
- Disabled compression
- Changed ASP.Net Session State properties (InProc, StateServer, SQLServer, Cookies, URI, etc) -

From serverfault ManiacZX

• Check the web garden settings for the app pool. If it's greater than 1, the site will run in more than 1 worker process. Session state in Classic ASP depends on a single instance of the in process memory. It's very rare that the web garden needs to be set to anything other than 1.

  A webfarm with round-robin load balancing would have the same issue but your post doesn't suggest that you have that.

  ManiacZX : You are correct sir! As soon as I looked at the setting and saw it was set to 3 I knew you were right and a lot of words I can't type here went through my head. I never touched that so it must be IIS default.

  MaseBase : Scott-- Thanks for this info! Does this mean that Classic ASP can never run in a web garden on IIS 7? I had an issue with this and had the Session State set to use the State Service, but I was getting the behavior of an in-process state storage. In a high traffic site, it seems Classic ASP could benefit from a web garden too.

  Scott Forsyth - MVP : MaseBase, if you are using session state (not everyone does), then a web garden with Classic ASP will cause the issues described. You mentioned the State Service, but that's only for ASP.NET, not classic ASP. The Session State Service isn't affected by web gardens. As long as you are Session State Service with ASP.NET, then a web garden is fine. It's also worth noting that there is almost never a reason to use a web garden. The only situation I know of where it may help is with long running pages that aren't CPU bound where you want extra threads running in parallel.
  From Scott Forsyth - MVP