After frustrating myself to no end with how little this problem is discussed on the web, I took it upon myself to give back to the <BR><BR>community all I&#039;ve learned:<BR><BR>=========================<BR>Probl em<BR>=========================<BR>Trying to use ASP.NET&#039;s Session object to implement application security (i.e., redirect to login page if session object is null) <BR><BR>fails when using In Process Session state management. This is especially true in a hosted environment. <BR><BR>Assume your Web.Config file has something like this:<BR><BR>&#060;sessionState mode="InProc" cookieless="false" timeout="40" /&#062;<BR><BR>Here&#039;s What I&#039;ve learned if you are using InProcess session state management:<BR>ASP.NET drops the session object randomly for many reasons:<BR>1) Client does not allow cookies (use cookieless option if you can&#039;t get users to turn on cookies)<BR>2) On Windows 2003 Server, Worker Processes are pooled and depending on virtual memory available on the server (and other settings), <BR><BR>these processes get restarted, killing the session object. Nothing you can do about it in a hosted environment.<BR>3) The application instance, web server service or the whole server is restarted.<BR><BR>=========================<BR>Sol ution<BR>=========================<BR>Don&#039;t use In-Process session state management. Use either a State Server (the ASP Session State Service) or SQL Server to store <BR><BR>session information (obviously, but there are some nuances, read on).<BR><BR>=========================<BR>Using State Server in a Hosted Environment<BR>=========================<BR>Using the state server requires the NT service "ASP.NET State Service" to be running on your web server (or any server at the hosting <BR><BR>company that you know the name/ip of). I had my ISP turn on this service for my domain. <BR><BR>Use the following Web.Config settings in a hosted environment:<BR><BR>&#060;sessionState mode="StateServer" stateConnectionString="tcpip=" cookieless="false" timeout="40" /&#062;<BR><BR>The loopback IP is important here. You technically could use some other known web server at your hosting company to store session <BR><BR>state information but I don&#039;t know how the ISP would like that. Using another machine would mean your session information would <BR><BR>survive a web server restart (but not a restart of the server running the state service).<BR><BR>=========================<BR>Usin g SQL Server to store session state information *in a hosted environment*<BR>=========================<BR>Here things get complicated. To set this up you neet to run a SQL script to create the neccessary database objects. This script wants <BR><BR>to create a new database (called ASPSTATE) and requires sys admin access to the database server. This obviously won&#039;t work in a <BR><BR>hosted environment. You don&#039;t want ALL sites that use SQL Server storage to hit the same database for session information. This is a <BR><BR>big bottleneck (see below). To get around that issue, you want the ASP.NET server to use a database of your chosing to store session <BR><BR>state information. But, there is a problem in telling ASP.NET which database to use to store session state information. To configure <BR><BR>SQL Server storage you must use a Web.Config entry like this:<BR><BR>&#060;sessionState mode="SQLServer" cookieless="false" timeout="400" stateNetworkTimeout="15"<BR>sqlConnectionString="S;User ID=mylogin;Password=mypass"/&#062;<BR><BR>Notice how no database is specified? ASP.NET hard codes the ASPSTATE database name into the connection string so you can&#039;t get ASP to <BR><BR>use your own session state database. If the sqlConnectionString was an actual vanilla connection string specification, you should be <BR><BR>able to add a database attribute to the connection string like this:<BR><BR>&#060;sessionState mode="SQLServer" cookieless="false" timeout="400" stateNetworkTimeout="15"<BR>sqlConnectionString="S;database=mysessi ondb;User ID=mylogin;Password=mypass"/&#062;<BR><BR>However, doing so will produce the following error:<BR>"The sqlConnectionString attribute cannot contain the connection options &#039;Database&#039; or &#039;Initial Catalog&#039;."<BR><BR>There is good news! Microsoft knows about this problem and has a hot fix. See but getting <BR><BR>your ISP to actually implement the hot fix is another issue. Crystaltech was going down the road to implementing the hot fix, but I <BR><BR>solved my problem by using State Server instead of SQL Server to store session information so I aborted trying the SQL Server route. <BR><BR>(By the way, you have to hack up the Script Microsoft provides (see reference link below) to get the database objects all in your own <BR><BR>database instead of the ASPSTATE db the script wants to create.<BR><BR>=========================<BR>Final Thoughts<BR>=========================<BR>Use State Service in a hosted environment. If you really really really need session information to survive a web server reboot, use <BR><BR>the State Server service a machine other than your web server (&#060;sessionState stateConnectionString=tcpip=someknownispserver:424 24). <BR><BR>If both the web server and the server running the ASP Session State service go down, you&#039;d lose the session information. If you <BR><BR>really really really really really need your session state information to survive that scenario, get the hot fix applied to your web <BR><BR>server, hack up the SQL script microsoft supplies (see references link below) and add the database attribute to your connection <BR><BR>string in your Web.Config file (and good luck to you). If someone replies to this wanting the hacked up SQL Script, I&#039;ll post it here <BR><BR>as a reply.<BR><BR><BR>References:<BR><BR><BR>