Licenses not being returned when application quits when using Remote Desktop
A number of users are complaining licenses are 'often' not being returned when working remotely. They are connecting to their "work" Windows desktop over RDC. They exit the software normally but the server is still holding the license. If they do not use RDC ( i.e. they are physically at their work computer) they don't see the issue.
The server version is 11.16.1 running on Windows. I have looked at the server logs and I see licenses being checked out, but not being returned as the users report. We are not using "linger" or any unusual flex settings.
@andrewcflex , it may be observed in case the client message for 'license checkin' is not received at the server end - due to network congestion OR the timeout (threshold within which it should had reached server) and even though clients have released the licenses, server doesn't know about it.
A viable solution against such an environment would be to place "TIMEOUTALL X<seconds>" in the options file with license server - which will account for licenses being checked back in if the duration of "x" seconds have passed without any heartbeat from client.
On further investigation, it appears that the user description was not 100% clear. They are starting the application from a RDC session, leaving the application running, logging out of RDC, then going to the physical computer and logging in again. The application is still running of course. We allow , via setting of DUP_GROUP=UHD in the license file to run multiple copies on the same machine. When they launch another copy of the app while at the physical machine, they consume licenses they would not expect. Clearly the 'old' RDC session is seen as different to the physically-at-the-computer session when it comes to licenses and DUP_GROUP
@andrewcflex , that would be an expected observation as the DUP_GROUP setting is an "exclusive AND" operation i.e. all the parameters should match.
When logged in through the RDP, there are chances that the username and display could be taken from the RDP session, which changes when we return back to the physical system. For such an environment, i would advise to override the USER,HOST and DISPLAY info in the client application - which can be customized through FNP attributes.