Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a site running on 3 web nodes. We are using SQL Server session storage.

We recently added two more only to find that users' sessions are lost when they are sent to one of those machines.

We have checked the site ID as well as the machine validation key and decryption key.


I did forget to mention that the machine in question was a cloned (VMWare) version of an existing machine in the farm.

Resolved - we simply wiped the new machine and stood up a fresh Server 08 install. Cause of this issue was still unknown.

share|improve this question
up vote 1 down vote accepted

Have you confirmed that the machine key is working? One way to do this is if you have forms authentication, you can have a few lines of code that attempts to read the authentication cookie. If the machine key is invalid, you will not be able to read the cookie, and User.Identity.IsAuthenticated will be false. The machine key is also required for SQL session state, so this is the primary suspect.

Some example code below.

If you have your key in machine.config (instead of web.config), you may want to verify you have updated the correct file. If you have both .NET 3 and 4, you may have a machine.config file in four places. I usually update all four just to be sure.


Another remote possibility is you may also want to specify the validation="xxxx" property for the machine key hashing algorithm. In .NET4, the default hashing algorithm is SHA256, but in previous versions it was SHA1. So it is usually a good idea to include this so they will all be the same.

ASP.NET 4 Breaking Changes - Default Hashing Algorithm Is Now HMACSHA256

Protected Configuration Provider. Sharing the machine key in a web farm only works with the RsaProtectedConfigurationProvider. If the web.config or machine.config specifies only the DpapiProtectedConfigurationProvider, it will not work:

Specifying a Protected Configuration Provider

Sample cookie validation code:

if (Request.Cookies[FormsAuthentication.FormsCookieName] != null)
        FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(Request.Cookies[FormsAuthentication.FormsCookieName].Value);
        Debug.WriteLine(String.Format("Cookie timeout: {0}, ticket.Expiration.ToString("yyyy-MMM-dd HH:mm:ss")));
    catch (Exception e)
        Debug.WriteLine(String.Format("Error reading cookie: {0}", e.ToString()));
    Debug.WriteLine("Cookie unavailable");
share|improve this answer
Thanks for the detailed answer. Cookies do work on the machine in question, but if a cookie is set on the new machine it does not work on other machines, and vice versa. – ItsJason Jan 4 '12 at 16:22

This is most likely due to your new servers having a different set of patches than the old ones. Even when the validation key and decryption are the same, the new servers will not generate tokens that are valid on the old ones. See this issue for precedence.

You can probably resolve this by making sure all your servers are fully updated.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.