Does an accumulation of old sessions (displayed in the Admin Console) indicate anything that needs to be looked into?
For example, the screen shot below shows user cfuentes with 6 inactive sessions.
Is this something that might indicate a problem waiting to rear its ugly head?
Also - We run the client via a Web App Not the Epicor Web Access Extension. Our’s is like Citrix, but not Citrix,
Zombie sessions are usually when someone does not logout. It could be because they have not touched their box in forever and someone else stole their license ticket. Otherwise it could be due to signed in on laptop and unplug from network / crash on close, etc.
They don’t count against licenses, they take up a couple hundred bytes each in the db so really are not an issue. They will be cleaned up in 72 hours. (So people can leave their boxes on over the weekend and keep their session).
Thanks for the info.
As I said, our users run it as an RD App. So it is most likely that their RD session times out, leaving the E10 client session (on the RD App server) orphaned.
One other related question. All users - but one - have a session type of “DefaultUser”. The one exception is a user whose sessions vary between “DefaultUser” and “EnterpriseProcessing” (see pict below)
This user isn’t anything special, and doesn’t run any processes like MRP , Capture COS/WIP, PO Suggestions, etc…
And what is an “Enterprise Processing” session?
Calvin
It just means the user has multiple concurrent sessions enabled.
Let me give you my post first cup of coffee answer. If a user is logged in and launches and program and then changes companies they will switch their licensing type to this.
Hmmm … That raises more questions, as we have only one company setup. Would switching sites/plants within a company possibly do that?
Yes, switching plants would also change the licensing type
The EAC help has information regarding the different session types in the Session List Fields topic.
Additionally (and, perhaps most importantly) Enterprise Processing session types don’t consume a license from your license pool. For userA if there is one defaultuser session and userA also has 20 enterprise processing sessions, there is only one concurrent office user license being consumed.
This is normal and happens to most users, but it does have some implications. There are certain things stored in sessions that can cause problems in the interim before they expire after about 3 days. One example: if a user’s session is still open, but they are not active after attempting to retrieve a batch of AR invoices from shipments, those invoices will be locked and will only appear in their target group after the session is manually terminated or it expires.
Therefore, while other responders are absolutely correct that it does not go against your license count, it can be important to maintain these sessions if this might happen to you. Epicor support will provide a program fix in these cases, or you can wait out the 3 days, or you can kill the session in the admin console.
I can infer from watching the admin console that an Epicor process checks for expiring sessions every few seconds in the table that holds the sessions to systematically terminate sessions and resolve these locks. For some reason, this date is something like 3 days after the listed expiration. If I worked for Epicor, I would recommend putting a configurable setting for the duration of client expiration so that users would not be tempted to update the expiration date in this table, perhaps using a BPM.
We run the clients via RDP App, so disconnected sessions are quite frequent. But when that user starts anew RDP session, that E10 session is left orphaned.
Why isn’t the orphaned E10 session recovered (either resumed or deleted) when that user starts a new RDP session?
Presumably users may intentionally want to create distinct sessions to operate simultaneously in different companies, etc, and the system does not necessarily know that a session is terminated vs inactive because it doesn’t appear that these fields are actually updated frequently during the session. You can see the plumbing was in place to put such a system in place, though it is incomplete. I feel that this SHOULD automatically happen for users who have “allow multiple sessions” disabled, though I do not believe it does.
I purposely enable “allow multiple sessions” out of fear that a session that was disconnected from a RDP timeout might not be resumed when that user reconnects, and the user would be denied access. That used to happen in V8.
That 3 day limit being configurable is already in the queue 
If you feel strongly, put in a ticket. It ‘up votes’ the item to bump it up in the sequence of issues being worked upon.
If we killed off old sessions we’d end up irritating some who wanted to keep them running. When we did this before I received a lot of ‘enthusiastic feedback’ on not touching how it has worked for decades. The configurable approach mentioned above is probably the way to go to ensure backwards compatibility and give people the power to control their domain how they like.
Vote it up 
There is some new logic put in place in … ?10.1.500? that deals with ‘single session’ a little more ruthlessly. We will kill off zombie sessions more often - not as many code paths to get you the warning you are only allowed one session at a time.
