There is a version of the Session object that can live in its own database.
You are still going to get massive timeouts and network errors while the
service is down.  I would build a stand-alone test platform to determine how
the system behaves with the dedicated session database.  Simulate a failover
by doing a simple SQL service restart.

Thanks for the help.

I understand session state used to be stored in tempdb. However, I found the
sql file InstallPersistSqlState.sql. This file configures the session state
to be stored in the tables ASPStateTempApplications and ASPStateTempSessions
within the database ASPState. It gets around the problem of losing session
data on a failover, but still causes a General Network Error that is
difficult to spot and correct.

I know a fail over should be a rare occurrence, but surely when Microsoft
release patches manual failovers will need to be performed in order to
update the servers. The idea of the solution was to allow us to perform
these manual failovers within office hours and not have to inform users.

Clustering is a new experience to me, so I wasn't sure on my expectations. I
was hoping, with minimal code changes a failover could occur gracefully and
allow an application to continue operating even if the failover occurred
during the processing of an ASP.NET application.

Thanks for your input, all I wanted to find out was whether these problems
are by design and not because the cluster isn't quite configured correctly.
Now I can move back to our application code and re-write to fall inline with
the clustering solution.

Matt