1

Recently had an issues with a server upgrade from IIS 6 on Windows 2003 to IIS 7.5 on Windows 2008 R2 64 bit.

We have a number of websites running on Classic ASP. All the sites sit under a particular site, e.g. www.example.com/foo and www.example.com/foobar.

On IIS 6 each site was set up as a virtual directory and things worked fine. Since moving to the new set up, a lot of websites seem to have mixed Sessions. To be clear, this is not a app pool recycling issue; rather the sessions are populated with information when the user hits the site and while browsing they get sessions from different sites.

We've determined this based on - a few customers called up and reported having their shopping cart with items with names of items belonging to a different site - also our own testing showed that some queries being run would try to bring products in from a different site

We've tried - disabling dynamic caching - converting each site to be a virtual application (if I understand correctly, the virtual directory/application concepts were changed/refined somewhat in IIS 7 although to be honest, I'm not clear what the difference is) - various application pool changes (using .NET 2 framework), classic and integrated modes, changing the Process model to NetworkIdentity), all to no avail.

The only thing we haven't tried is changing it to run as a 32 bit application.

We're not using http only cookies, so when I open up a browser and type

document.cookie

into the dev console in Firefox/Chrome/IE that there will be multiple ASPSESSIONID=... values whereas previously I believe there was only one.

Finally, we use server side JScript for the classic ASP pages, not VBScript, so we have code similar to the below.

//the user's login account as a jscript object Session("user") = { email : "foo@foobar.com", id : 123 };

and if we execute a line of code like below:

Response.Write( typeof(Session("user")) );

When things are running correctly, we get "object" - as expected. When the Session gets trashed, the output is "unknown" and we are also unable to access the fields within the JScript object (e.g. the .email or .id fields).

Much appreciated if anyone can provide any pointers about how to resolve this, everything on google seems to point to different issues.

Marcin
  • 21
  • 3

1 Answers1

1

This still sounds remarkably like an application pool/recycling issue. Are you sure you were actually using the ASPSESSIONID cookies under IIS6 or is there a custom session management solution with its own cookie?

Chris McKeown
  • 7,128
  • 1
  • 17
  • 25
  • Thanks for the response Chris. No we weren't using any custom Session management solution, just plain old ASP Sessions, and it appears to be happening randomly (as far as we can tell). We've tried disabling recycling events too(based on a fixed time, # of page loads etc.) and it doesn't make a difference; the problem can appear 2 minutes into the Session and there's not enough traffic on these sites to be hitting any RAM limits or anything. – Marcin Mar 25 '12 at 06:06
  • Bizarre. Is there any evidence of application pool recycling in the event logs, perhaps due to a process serving the pool crashing? – Chris McKeown Mar 27 '12 at 09:00
  • Yeah, we thought it was pretty bizarre too. Good idea about the event log. The system log has an entry: The following fatal alert was generated: 10. The internal error state is 1203. The source is "SCHANNEL", event ID : 36888. We're going to try and rebuild the server with a 32bit app pool to see if that helps. Although appreciate your efforts Chris. Let me know if any further ideas. – Marcin Mar 30 '12 at 01:19
  • I've seen that SCHANNEL error before and I don't think it's anything to worry about - It's logged when someone tries to connect to an SSL port using a plain HTTP connection (`http://yoursite:443/`). You can turn off the error events by tweaking the registry. – Chris McKeown Mar 30 '12 at 07:48