I have a Asp.Net web application running on Windows 2008 R2 (IIS 7.5). I have two servers WWW1 and WWW2 and the DNS records are set up for round robin DNS for "www". I increased the AppPool timeout and the Session State timeout settings so users don't get logged out after 20 minutes. However I've noticed users are getting logged out randomly. I think what is happening is the user goes to www.foo.com and logs in and then afterward some time the round robin navigates them to the opposite server in the cluster (WWW1 or WWW2) where the cookie was not created and therefore prompts them for a login.
How can I get this to work and still keep my high availability solution using round robin DNS?
The issue here is each server maintains its own session state in memory and doesn't know about sesssions created on the other server.
To get around this, instead of using the default InProc session state provider you'll need to use the StateServer or SQLServer session state providers.
To do this you'll need to make sure the ASP.NET state service is running on one of your servers and then you'll need to add the following configuration item to the system.web section of your application's web.config file, replacing 'SampleStateServer' with the name of the server you are running the ASP.NET state service on:
<sessionState mode="StateServer"
stateConnectionString="tcpip=SampleStateServer:42424"
cookieless="false"
timeout="20"/>
Microsoft's documentation on this is available at http://msdn.microsoft.com/en-us/library/ms178586.aspx
Because you are running this in a web farm you'll also need to make sure the web applications on both servers are using the same encryption keys.
For this you'll need to set a machineKey entry in the web.config whic involves adding an entry like the following to the system.web section of the web.config:
<machineKey validationKey="4D0590A0E4DE163BAD0EEEB6747467D770CD5FB2EA95BF02B27787A45CA579DECB01E2A1F16563DBAB44C1C0E54C7E53D65F2A7D0FDF378F4D3702B3F2C8B165" decryptionKey="928771D7B1B8C32608F56AC428EC5902985F6FB2E6E9A78733B6EAA493FA13F5" validation="SHA1" decryption="AES" />
There are several websites which will generate keys for you. I typically use http://aspnetresources.com/tools/machineKey
If you want to use the SQLState provider instead, http://msdn.microsoft.com/en-us/library/ms178586.aspx has all the configuration information under the 'Sql Server Mode' section of the page. The setup for that is slightly more involved as you have to configure a database in which you will store the state.
Related
I follow the direction in here How to configure SQL Server to manage ASP.NET sessions to create ASPState db.
I have 2 web application in IIS 7. In IIS web application setting, i go to "Session State" and set session state as "SQL Server" and provide connection string.
In each web application web.config, i add
<sessionState
mode="SQLServer"
allowCustomSqlDatabase="false"
sqlConnectionString="data source=server;user id=user;password=password"
cookieless="false"
timeout="7200"
/>
I create a session ,
Session["Data"] = "test"
in Web App A and go to Web App B in the same browser to print it
Response.Write(Session["Data"]);
It shows NOTHING. I can see there are data in table : ASPStateTempApplications and ASPStateTempSessions under ASPState Database. Also, i dont see any error in event log. Can anyone think anything i may do wrong?
Thanks!!
You can not get session that belongs to App-A from App-B and vice versa.
The sessions are connected with the cookies, and the cookies are different between app-a and app-b, are random made. Even if set some how the same cookies then next the database connects session with the Application ID, that are also different for each applications.
So even if you have the same database, the application id is different, and the cookies are different, and you can not get session from a to b.
The only possible way to archive that is to make your custom session code, and some how knows that you have the same use on app-A and app-B, so to connected them together.
I'm working on an ASP.NET MVC web application that will be deployed across multiple load-balanced servers. With this setup, a user might have one request served by server A and the next request will be served by ServerB or ServerC.
We don't want to store Session Data in the database, as we're trying to minimise database hits where ever possible. As such, we need to have the HttpSession managed and stored on another server.
My understanding is that this is possible by using a Windows Service that will manage this for me, but I'm unfamiliar with how to implement this. Can somebody point me at some good documentation on how to do this? Or any pitfalls or other points to take into consideration? Thanks
You need to dedicate a machine that will host the Windows NT service and which must have .NET installed (well you could use one of the web servers as state server but IMHO this would be a very bad idea):
net start aspstate
And then instruct your application to use this server:
<system.web>
<sessionstate
mode="stateserver"
cookieless="false"
timeout="20"
server="127.0.0.1"
port="42424"
/>
</system.web>
where of course you would replace 127.0.0.1 with the IP address of the server hosting the NT service.
Note1: don't forget to decorate the objects you intend to store into session with the [Serializable] attribute.
Note2: this is a good solution in a load balanced environment but if you are looking for a real failover clustering you should use SQL server.
You may read more details about ASP.NET session state on MSDN.
As usual, Peter gives this issue good coverage...
http://www.eggheadcafe.com/articles/20021016.asp
Another alternative you may want to consider is Memcached Providers - it allows you to store session state in a memcached instance; optionally using SQL Server as a fallback. The best of both worlds, IMHO.
When I update an ASP.NET Website [note: it's not a Web Application] running on a customer server by overwriting it with the latest version it currently kicks all the users off.
I'd prefer to be able to deliver a new version of a site without kicking off users - is there a way to minimise the chance that users will get kicked off? [apart from the obvious one of waiting for a time of low-usage]
If I moved from InProc to Session State I guess this might do the trick - but is there any other method?
Chaning away from InProc Session State should help.
The problem now is that any time your app is reset in IIS (overwriting the web.config will cause a restart), the IIS Worker process restarts and clears your session info.
Check out this MSDN Page to read the limitations of In-Process Session State:
Session State - MSDN
I think additionally to what you are suggesting, it will be appropriate to display an "update in progress..." page instead of kicking off users. You can do that by changing your web.config file.
Session IDs are valid for the lifetime of the application pool, or until (I believe) 20 minutes following the last page request from the client in question. This is configurable in web.config:
<configuration>
<system.web>
<sessionState
cookieless="false"
timeout="20"
</sessionState>
</system.web>
</configuration>
If the application pool is recycled, files within the application are updated, etc, your session IDs will be invalidated. For this reason it is considered wise to deploy your site during off-peak hours.
Design your application to not rely on the existence of session state variables. Use cookies for authentication (or integrated auth) and check for session variables as you use them; reload them if they don't exist.
In IIS 6 (and other versions too afaik), there is a Session Timeout setting in Properties -> Home Directory Tab -> Configuration button -> Options tab. Looks like this:
And in the ASP.NET web.config there is a SessionState setting, looks like this:
<system.web>
<sessionState timeout="120" />
<!-- etc .. -->
</system.web>
Are they, by any chance, related? Do they set the same thing, or different things?
They are not the same. The IIS session timeout is for clasic ASP pages. The web.config one is for asp.net.
The IIS setting has no effect on ASP.NET sessions as far as I'm aware - these must be set in the web.config.
You should also consider Application Pool Idle Timeout. The settings for the application pool can be found by clicking Properties (IIS 6) or Advanced Settings (IIS 7.5) on the application pool that the application is assigned to.
Ensure this value is set to the timeout of your session, at a minimum, to ensure that all sessions persist for the entire session timeout period.
The reason that these two values are dependent on one another is because the session information is actually stored within the worker process of the application pool. That is to say, if the worker process is shutdown or killed for any reason, the session information will be lost.
Authentication cookies seem to timeout after a short period of time (a day or so). I am using Forms Authentication and have the timeout="10080" with slidingExpiration="false" in the web.config. With that setting, the cookie should expire roughly 7 days after the user is successfully authenticated.
This worked as advertised with IIS6, but when I moved the site to IIS7, the cookie expires much quicker. I've confirmed this behavior on multiple machines with IE and Firefox, leading me to believe it's an IIS7 setting.
Is there a hidden setting that is IIS7 specific related to authentication? All other authentication types are disabled for the website, except for anonymous user tracking.
The authentication cookie is encrypted using the machineKey value from the local web.config or the global machine.config. If no such key is explicitly set, a key will be automatically generated, but it is not persisted to disk – hence, it will change whenever the application is restarted or "recycled" due to inactivity, and a new key will be created on the next hit.
Resolving the problem is as easy as adding a <machineKey> configuration section to web.config, or possibly (preferably?) to the machine.config on the server (untested):
<system.web>
...
<machineKey
validationKey="..."
decryptionKey="..."
validation="SHA1"
decryption="AES"/>
...
</system.web>
Google generate random machinekey for sites that can generate this section for you. If your application deals with confidential information, you might want to create the keys yourself, though.
My understanding is that cookies are expired by the consuming party - the browser, which means that IIS has no say in this
Set session state configured in IIS as
In Process
Use Cookies
Time out = your required time
Use hosting identity for impersonation
Also set EnableSessionState to true (which is default too)
And most importantly run the app pool in classic mode.
Hope your problem will solve.
First of all i must say that these "guidelines" are generic and not iis-7 exclusive.
In web.config under <system.web>
you either have <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" timeout="130" cookieless="false"/> (which requires the ASP.NET Session State Server service running on localhost)
or <sessionState mode="InProc" timeout="130" cookieless="false"/>.
The main difference is that in InProc that session state data are placed in the application process itself. In the other setting a different service is doing the storage, and you application just polls it to get the required data.
Having used both (as well as sql-server session state mode) the InProc is the least reliable but the fastest. The Sql-server is the most reliable and the slowest and the StateServer mode is somewhere in the middle being unreliable only in the case of a power/system failure. Having said that, i must say that for site with a low request count the performance penalty is negligible.
Now, my experience has shown that InProc is quite unpredictable on its stability; i used to have the same problem with you. I was able to extend the stability of the application by tweaking the settings of the application pool, i removed the problem altogether by switching to SessionState (which also allows to bring down the application and not lose session state data).
The reasons that you may suffer from application/session stability:
IIS and application pooling. Each virtul directory of a website is assigned to an application pool (by default to "DefaultAppPool") which has a series of settings amongst which you define the interval that the process is "recycled" - and as such preserve system resources. If you don't change the settings the application may trigger one of the criteria for the process recycler, which means that your application is busted
Antivirus.
In a ASP.NET application if the web.config (and any child .config files the application depends on) file is touched the application is restarted. Now there are cases where an antivirus program may touch the web.config file (say once a day?) and as such the application is restarted and session data is lost.
Bad configuration
Specifically for Forms Authentication the time-related settings and behavior always where dependent on the web-session with the auth-session being under the web-session.
What i don't know is if the Forms Authentication module depends only on Session domain or if it also places data in the application domain as well. If the second is the case then you may have to disable all recycling settings in the Application Pool as well as checking again configuration/antivirus and who stores the session data.
I recently had the same problem where my site was timing out every 20 minutes even though I set the session timeout to 2 hours. I found that it was because IIS worker process was timing out every 20 minutes: http://technet.microsoft.com/en-us/library/cc783089(WS.10).aspx