Workflow Soluiton

My Workflow question is regarding session state problems in a Workflow 7.1 environment running against an IIS 7.5 installation.  I’ve got a number of users in the field interacting with workflow sites and am receiving quite a bit of feedback of them encountering: The session id ___________ is not valid or the session has timed out. 

One of the places we seem to encounter this error frequently is during our imaging when we display a “start” screen to begin personalization of the workstation.  This screen has a refresh timer set at 5 minutes & the IIS setup states there is a 20 minute timeout assigned.  We’ve seen in our own lab instances where we hit this “start” screen and immediately attempt to interact with it only to receive the same message above.  In our lab the failure rate seems to be about 30% and we have reports from the field that they’ve had to reboot systems multiple times before getting a useable session.

I found articles on Connect with similar issues (related to ServiceDesk) where it was suggested to modify the cookieless setting of the session management headers in the web.config files.  When I set it to “true” (& restarted IIS) the workflow behavior seems to be unchanged and still results in the session timeout message.

Our normal production configuration is a cluster of 3 servers front-ended by an F5 but I have also seen this error when hitting any of the workflow servers directly (thereby removing the F5 from the equation).  What I noticed from the IIS logs is when the page works I see a “POST” followed by some number of “GET” statements – all return code 200.  When the Application Error/timeout message is thrown I see the same “POST” message (also return code 200) but never see any “GET” chatter.  I’ve come to the end of what I can think of so I need some help to make this environment rock solid.  Any input/other troubleshooting steps would be greatly appreciated as I'm new to both IIS & Workflow...

We have been working with backline on this issue.  We had been running Workflow 7.1SP1 build 82; it was determined that the session tracking logic within workflow was based on source IP.  The issue was caused by a load-balanced proxy solution we have in our environment which could not be disabled due to our corp information security group.  Whenever the proxy silently passed the user to the other node it caused the workflow session tracking logic to fail resulting in the error posted.
Working with the backline & the engineers we were provided with Workflow 7.1SP1 build 98.  This build resolved the internal tracking issues for the load balanced environment.  We are in process of restoring our production environment back to this clustered solution.  As our issue seems to be resolved I'm tossing this info out here for anyone else who may be trying to deal with the same issue.