0
votes

In short, I have three servers in a web farm, one of which is configured as a State Server. Two of the servers (including the State Server) are correctly sharing session state, but the other server is holding it's own session still.

Here's what I've done:

I have modified the web.config.comments file on all three servers so that they have the same machineKey entry.

On the State Server, I have changed the AllowRemoteConnections registry entry to 1. I then set the ASP.Net State Service to start automatically and switched it on.

The web site is configured on all three servers and the root site shares the same Identifer in IIS. Each configuration is identical. The website itself is contained on a network share, so the same web.config file is used on all three servers. I changed the sessionState entry in the web.config to point to Web3.

So Web2 and Web3 are able to set/modify/destroy the same session, but Web1 is still running with it's own.

I'm at a loss here after hours of Googling, so any help is greatly appreciated.

This application is configured a few subdirectories into the root site. Is there a separate AppID at this level? If so, how can I find it?

Thanks, Aaron

3
Did you change web.config.comments or web.config? Are you on a 64bit server?Schwarzie2478

3 Answers

2
votes

http://support.microsoft.com/kb/325056

To maintain session state across different Web servers in the Web farm, the application path of the Web site (for example, \LM\W3SVC\2) in the Microsoft Internet Information Services (IIS) metabase must be the same for all of the Web servers in the Web farm. The case also needs to be the same because the application path is case-sensitive.

On one Web server, the instance ID of the Web site where the ASP.NET application is hosted may be 2 (where the application path is \LM\W3SVC\2). On another Web server, the instance ID of the Web site may be 3 (where the application path is \LM\W3SVC\3). Therefore, the application paths between Web servers in the Web farm are different. For additional information about how to check the application path of the Web site, click the following article number to view the article in the Microsoft Knowledge Base:

240225 Description of Adsutil and MetaEdit Used to Modify the Metabase

0
votes

This is not really answering your question, but in my experience the ASP.NET session state service is not something you should scale to more than one server. It doesn't perform very well (especially under load) and is difficult to configure. I found that a distributed cache such as memcached is much simpler and faster for this purpose.

Have a look at this project.

0
votes

matthewk's answer actually turned out to be almost the correct one. Over a year later I've returned to this and found the answer. Though probably correct, I felt that if the answer above had been more specific I would have solved this!

I searched through the MetaBase.xml file (C:\WINDOWS\system32\inetsrv) for the web application. After a game of spot the difference I noticed that there was a slight difference in the following line:

<IIsWebVirtualDir   Location ="/LM/W3SVC/103071637/root"
    AccessFlags="AccessRead | AccessScript"
    AppFriendlyName="Default Application"
    AppIsolated="2"
    AppRoot="/LM/W3SVC/103071637/Root"
...

Specifically, the AppRoot (not the Location) on Server 1 had a Proper-Case "Root" whereas Server's 2 and 3 had "ROOT" all in caps. I updated Server 1 to match and restarted IIS and it works a treat.

ie.

AppRoot="/LM/W3SVC/103071637/Root"
AppRoot="/LM/W3SVC/103071637/ROOT"