Syncade MES - WFX User Session Loss - Event ID 1309 Logged on the Application Server

[AgentSmith]

Problem: In a load balanced environment the client systems occasionally have an issue with session loss. When the user attempts to establish a new connection without closing the browser the below Server Error in '/WFx' application error is displayed. If the Syncade Administrator reviews the Windows Applicaiton event logs on the application servers there is an Event ID: 1309 displayed. If that error contains a CryptographicException error there is a fix for this issue. The Syncade WFx module out of the box ships with a 60 minute session timeout. If the load balancer is not setup with a 60 minute persistence then the session can prematurely timeout and cause the below error.

Resolution: For Microsoft NLB's set the affinity to single and for folks that have load balancers such as a F5, ensure that the load balancer is setup with a 60 minute session persistence for the port that WFx is running on.

Note: There may be a few errors that occur from residual sessions that have been left open by clients with pre-existing sessions.



Windows Event Log - Application
Event ID : 1309

Exception information:
Exception type: CryptographicException
Exception message: Key not valid for use in specified state.

at System.Security.Cryptography.ProtectedData.Unprote ct(Byte[] encryptedData, Byte[] optionalEntropy, DataProtectionScope scope)
at System.IdentityModel.ProtectedDataCookieTransform. Decode(Byte[] encoded)

[GreatGoogily]

We were seeing this issue in our system as well. It was only Certain application servers--not everyone was seeing this issue at the same time. After a few phone calls with Guardian Support--our resolution was a bit different.
Guardian was convinced that there was an IIS connection dropped throughout the day which affected this process

1. Application Pool - DefaultAppPool and SyncadeCore
   1. Recycling
   2. Uncheck "Regular Time Intervals"
2. Default Web Site
   1. Advanced Settings - Change connection timeout to 3600
3. Default Web Site / HTTP Response Headers
   1. Set Common Headers - HTTP Keep Alive is selected

Curious if these two resolutions are different solutions to the same problem, or if one of our solutions just simply "masked" the issue? Thoughts?

[AgentSmith]

There are certainly multiple ways to skin a cat, I supposed its all about keeping the client session alive for the entire 60 minute duration imposed in the WFx web.config. I believe most F5's have a default session persistence of only 180 seconds out of the box and thats why we run the risk of random validation failures as the session re-establishes on a different host. I would also imagine the issue becomes even more prevalent with more hosts. There really are only 3 solutions from what I read, the persistence for the entire duration of the session to match the timeout in WFx or the use of a certificate or matching machine keys. I used the matching machine keys and it didn't work, so I guessing it would likely require a code update to support it. I would personally prefer the code update so we can have all the hosts with a matching key pass the validation and do away with the session persistence to get the most performance out of the system.

Now for your settings... The http keep alives this should be turned on to prevent port exhaustion. However, I like to keep my application pools recycling to keep my systems happy. I have rolled out my change to 10-15 environments and fixed them all at this point.

Hope all is well my friend!

Andy