Sessions Timing Out - SessionID Cookie Missing

[mjlocat]

Hi All,

I have an application written in VB.NET 2.0 and a legacy application written in classic ASP. The legacy app can be accessed from the .NET app (crossing application pools to do so). One client seems to be having a problem with sessions timing out unexpectedly and being thrown back to the login page. They have been using the site in this configuration without any problems for over a year. This started happening around the beginning of October.

We implemented some code that writes the cookies received by the server to a table when the timeout code is hit. It looks like one critical cookie, SessionID (not to be confused with ASP.NET_SessionId), is missing when the user hits this code. Our site uses both our own SessionID cookie as well as the ASP.NET_SessionId cookie. If either one is missing, the system won't know who the request is for and will send the user back to the login page.

Using Firefox, I logged into the site and recorded the following cookies (Names and values changed to protect the innocent):

ASP.NET_SessionId=bffmbezar555bm45nvrtynqg
ISAPPNETREQUEST=True
SessionID=8497f9de-a5eb-4c42-bd50-d73312e65b07
APPSessionTimeout=120
app=ReturnUrl=&LoginUrl=https://www.example.com/Login.aspx&TimeoutUrl=https://www.example.com/Relogin.aspx?Timeout=false
OrganizationMatchCode=Client
ASPSESSIONIDSCSAQTAB=LOLFJJBDPCBKICFFKEOCCOAG
APPCounter=0
ASILogout=0
ASPSESSIONIDAAQATSAA=MPEIICBDFOLGPIIJHHGNLCFO
ASPSESSIONIDQAQCQTAB=BPLFJJBDHANHAEOACAKLIDNK

The following is an example from table the cookies are written to on timeout:

ISAPPNETREQUEST=True
app:TimeoutUrl=https://www.example.com/Relogin.aspx?Timeout=false
app:LoginUrl=https://www.example.com/Login.aspx
app:ReturnUrl=
WarningMsg=0
OrganizationMatchCode=Client
ASP.NET_SessionId=wldaled8dkrhalx3ld9ldl23
APPCounter=1

The client is using IE6 and is sitting behind some kind of corporate proxy server. On our side, we have a load balanced web farm of 8 servers running IIS 6 and accessing a SQL Server 2005 database. The sessions are managed in the ASPState database. This may be related or not, but we were beginning to increase the size of our web farm from 3 to 8 right around the first reports of this happening, however the issue may have started before we turned any of the new servers up.

Has anyone seen anything like this before? Any pointers on where to focus my efforts? Thanks for any assistance you can provide.

--Mike