I’m getting hundreds of Invalid session errors in my event viewer. They all look like this:
Ice.Common.InvalidSessionException: Session with SessionID = c2ff600a-18f3-4e8c-950f-8e8c43845c79 is invalid. Session has either timed out or has been deleted. You must login again to continue.
No users have reported any issues. There seem to be 3 Session ID guids that are repeating. I’ve looked at all of the servers, and no sessions have any of the the 3 guids I keep seeing. Not that they would, or they’d be valid sessions, I guess.
There are also a handful of Invalid Token errors sprinkled in:
Ice.Common.EpicorServerException: Invalid token.
---> System.UnauthorizedAccessException: Invalid token.
at Ice.Security.Token.AuthTokenHelper.ValidateToken(String token, String userId, Boolean checkName) in C:\_releases\ICE\ICE4.2.400.13\Source\Server\Framework\Epicor.Ice\Security\Token\AuthTokenHelper.cs:line 153
Any thoughts on what might be causing this and / or how to stop it? Or maybe how to see the username associated with these Sessions? It’s ongoing, as there have been several dozen in the 3 minutes it took me to write this post.
Kevin - I checked our event viewer and we’ve got some entries but nothing on the scale you’ve shown. If you add Keywords to EV, it might reveal something. Ours all show as Classic and are either security-related (user doesn’t have access to a particular function) or Citrix (user disconnected)…so they’re legit.
Appserver health OK? Ours glitched yesterday, had to recycle the app pool as the CPU had pegged to 100% and System Agent stopped. Once recycled, all was well…
My documentation skills need work (read: are non-existent), but I think a combination of these steps got me close enough to solving the InvalidSessionExceptions. In our case, it was remote desktop connections to our server from developers not closing out of their Epicor sessions and leaving their connections open.
I believe I enabled this trace flag: . From there, the trace has the correlationID and ip address/port and pid. On the server I then did a command prompt query using this command,
netstat -aon | findstr 8080
replacing “8080” with the pid. And I was able to tie it directly back to them.
I’m sure there’s a better way to do it. I was also probably lucky in the way we have things set up. But that’s about as much as I can remember to try to assist.