Automatically Disconnect Session`s

Hello,

Yes. You can centrally configure the timeout from the DVLS web interface under:
Administration → Server Settings → Advanced

The Idle logout setting disconnects an inactive DVLS web session after the specified period. If the policy must also affect clients such as Remote Desktop Manager, configure the Refresh token lifetime on the same page. This setting applies centrally to DVLS authentication tokens used by all clients.

Best regards,

Hello,

Thanks for the information! I’ve already implemented the change.

However, the change won't take effect until the token is reissued.
Is there anywhere I can check the remaining validity period for individual user or device tokens?

According to the menu, the tokens should have a minimum validity of 30 days.
I’d like to reduce this to one week; is there any reason not to do that?


Best regards,

Hello,

Good question. A few things to clarify:

On checking remaining token validity: there isn't a built-in view in the DVLS admin interface that shows remaining validity per user or per device token — that level of detail isn't exposed today. The practical way to gauge where things stand is to look at each user's last activity/login time, since a token only keeps renewing while the user stays active; once inactive, the countdown to expiry starts from that last-active point using whatever lifetime was in effect at the time.

That's also why your change "hasn't taken effect" yet — two things need to happen:

1. The Devolutions Server needs to be restarted (Stop Server/Start Server in the DVLS Console) for the new setting to be read at all.
2. Even after that restart, tokens that were already issued under the old 30-day setting will keep auto-renewing at 30 days until they naturally expire from inactivity or the user fully re-authenticates. The new value only governs tokens issued/refreshed after the restart.

On reducing to one week: there's no technical reason not to. The setting doesn't enforce a minimum — it's just a number of minutes, so 7 days is a perfectly valid value. Shortening it is a legitimate hardening move (reduces the exposure window if a token were compromised). The only trade-off is that users and devices will need to fully re-authenticate more often once a token lapses from inactivity, which could mean more sign-in prompts if some workstations sit idle over a weekend, for example. If that's an acceptable trade for your organization, go ahead.

Best regards,