Marc-Olivier Lalonde

Thanks — that confirms what we suspected.

Both applications use the same login flow and the same token lifetimes from your server, so the difference isn't the login itself. It's that RDM can authenticate silently using Windows integrated authentication on domain-joined machines, which is why your RDM users effectively never see a login page. DPM doesn't support that yet, so when the token expires, it sends the user back to the browser.

We're going to add Windows authentication support to DPM so the behavior matches RDM. Once that's in place, your DPM users on domain-joined machines should reconnect silently in the same way.

In the meantime, increasing the token lifetime is a reasonable workaround and may want to reduce it again once this ships.

Best regards,

Marc-Olivier

Thanks for the detailed feedback — this is very helpful.

A few questions so we can pinpoint what you're experiencing:

• What do you currently have set for Server settings → Advanced → Refresh token lifetime, and what was it before you increased it? (The default is 30 days.)

• Which DVLS version are you using, and which platforms are your DPM users on (Windows, macOS, or mobile)?

• When RDM users reconnect, do they actually see a browser login page, or does it just connect silently? We're specifically wondering whether your RDM users are on domain-joined Windows machines, since RDM can complete the login silently with Windows integrated authentication in that case.

• On the DPM side, what do the affected users see — the "Disconnected / please reconnect" state, or something else?

For context: both applications actually use the same login flow and the same token lifetimes from your server. The difference you're encountering is most likely that RDM can silently re-authenticate in the background, whereas DPM currently sends the user back through the browser — which is exactly the gap we're looking into.

Best regards,

Marc-Olivier

Hi @mikkoaaltonen89,

Thanks for the detailed list. This is clear and actionable, and I appreciate you taking the time to document each issue.

We’ll create tickets for these right away and start working through them without delay. I’ll make sure each item is tracked so we can fix them properly and follow up once we have progress to share.

Best regards,

Marc-Olivier Lalonde

Hi @meta,

Can DEPLOY_CONFIG and the MSI properties be used together?

Yes. They aren't merged, though — each writes configuration independently, so avoid defining the same setting through both to prevent conflicts. Use DEPLOY_CONFIG for a full pre-built config, or the MSI properties for a few specific settings, but not the same setting in both.

Is there an order of precedence?

No formal precedence. Configuration is applied on a user's first launch, and once their config exists it won't be re-applied from the system-wide source — so coordinating your settings across the two is what avoids surprises.

On upgrade, does redeploying DEPLOY_CONFIG / changed properties update existing customizations?

No, by design. Pre-configuration applies only on a user's first launch and only when they have no existing config. Existing users keep their settings; a redeployed DEPLOY_CONFIG affects only brand-new users.

Best regards,

Marc-Olivier Lalonde

Bonjour @stephanelhotellier,

Merci pour le rapport et les captures d'écran.

Bonne nouvelle : vos données ne sont pas en cause. Elles sont stockées côté serveur (c'est pourquoi l'accès web fonctionne normalement). Le message « There was an error unlocking your Devolutions Cloud workspace » provient d'une donnée locale dans l'application Password Manager qui empêche le déverrouillage — rien n'est perdu.

Solution de contournement (à effectuer sur le poste concerné) :

1. Dans Password Manager, ouvrez la liste de vos sources de données / espaces.

2. Retirez l'espace Cloud concerné de l'application en sélectionnant le bouton "Gérer l'espace de travail" puis "Se déconnecter".

3. Réajoutez-le en vous reconnectant.

Comme toutes vos données sont sur le serveur, elles se resynchronisent automatiquement après la reconnexion — vous ne perdez aucun coffre ni aucune entrée.

Nous avons par ailleurs identifié la cause et un correctif est en cours : une prochaine version corrigera automatiquement le problème, sans intervention manuelle.

N'hésitez pas à nous tenir informés après avoir essayé, ou si vous avez des questions.

Cordialement

Hi @meta

We support Group Policy Object (GPO) in the latest version. You can view the documentation here: https://docs.devolutions.net/password-manager/kb/application-knowledge-base/application-policies/?tab=windows

Best regards,

Marc-Olivier Lalonde

Hi @Alex.kletzl,

It looks like the issue is related to your DVLS system settings enforcing locking options on Workspace. To fix this, make sure your new Workspace installation uses the same enforced settings. We’ll also look into improving how this is handled on our side.

Best regards

Hi Pepijn,

We've recently reworked the pre-configuration system and added new features that will be available in an upcoming release.

In the meantime, you can deploy default settings by placing your Config.cfg file at the following location before the user opens Workspace for the first time:

%APPDATA%\net.devolutions\Workspace\Config.cfg

This will ensure your default configuration is applied when they first launch the application.

Best regards,

Marc-Olivier Lalonde