Microsoft KB Archive/251027

From BetaArchive Wiki
< Microsoft KB Archive
Revision as of 13:52, 21 July 2020 by X010 (talk | contribs) (Text replacement - """ to """)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Knowledge Base

PRB: ASP Session Is Lost When You Use Cisco Local Director and SSL Session to Route

Article ID: 251027

Article Last Modified on 7/8/2005


  • Microsoft Visual InterDev 6.0 Standard Edition
  • Microsoft Active Server Pages 4.0
  • Microsoft Internet Information Server 4.0
  • Microsoft Internet Information Services 5.0

This article was previously published under Q251027


When you implement a Web farm and use a routing product such as Cisco Local Director, you may notice that Active Server Pages (ASP) session state is lost.


When you implement a Web farm that uses ASP session state, you must ensure that client requests are always routed back to the same Internet Information Server (IIS) computer so that session state is available. Currently, you cannot share session and application variables between IIS computers.

To deal with this, products such as Cisco Local Director can route client requests to the same IIS computer in a Web farm, based on either the client's Internet Protocol (IP) address or a Secure Sockets Layer (SSL) session identifier. If Local Director is behind a proxy or firewall, the client IP address may not be available, and using the SSL session identifier may be mandatory.

SSL sessions can be renegotiated at any time during a browser session. When this happens, a new "symmetric key" is generated and shared between the two computers in the conversation. Local Director sees the newly negotiated SSL session identifier, and the client requests are routed to a random server in the Web farm. If the client requests are routed to a different Web server in the farm, the existing ASP session values are lost, and a new ASP session is started.


You can use several options to overcome this limitation:

  • Place Local Director and the Web farm outside the proxy or firewall, and route based on client IP address.
  • Design the entire site to be stateless.
  • Store client state information in either a client-based cookie or server-based database that is accessible from all IIS computers in the Web farm.


The third-party products that are discussed in this article are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.

Keywords: kbwebserver kbaspobj kbsecurity kbprb KB251027