Passwords are missing after upgrading RDM from 2024.3.16.0

The issue seems to affect only the sensitive fields. The newer version can read the SQLite connections, but it cannot display or decrypt the usernames and passwords. When I roll back to RDM 2024.3.16.0, all credentials immediately become available again. Could this be related to the DPAPI-protected .stv/.stb/.enc/.enb files or to a regression in the newer version?

My goal is to upgrade Remote Desktop Manager while keeping everything that is currently saved: all connections, usernames, passwords, credentials, settings, and other entry properties. I do not want to recreate the credentials manually one by one.

The old version, RDM 2024.3.16.0 (64-bit), displays and uses all my saved logins and passwords correctly. However, after upgrading to the newer version, the connections are visible but the usernames and passwords are missing. When I return to version 2024.3.16.0, all credentials become available again.

I need the correct and safe procedure to upgrade RDM without losing or hiding any saved credentials. Please explain which data source, configuration files, encryption files, DPAPI settings, or master key must be migrated so that the new version can read all existing logins and passwords.

Hello,

Before we investigate the cause further, could you please try the following as a workaround?

On your working 2024.3.16.0 installation:

1. Go to File → Export → Export Vault (.rdm).
2. Enable Include credentials. This option is disabled by default, which is likely why the passwords were not included in your previous export.
3. Set a master key to protect the export, then save the `.rdm` file outside the RDM configuration folder.

Then, on the newer version:

4. Go to **File → Import → Import Vault (.rdm)**.
5. Select the exported file and enter the master key when prompted.

This should transfer your connections, usernames, and passwords intact. Please let us know if this works.

Regarding your other questions:

**Master key vs. Windows profile key:**
For a standard local SQLite installation with no application password configured, sensitive data is protected using the local key stored in the `.enc` file. This key can also be protected using DPAPI and tied to your Windows user or machine. This is different from the separate "master key" concept used in Devolutions Server or Hub-style deployments.

**Migrating the SQLite workspace to Devolutions Cloud:**
Yes, migrating a local SQLite data source to Devolutions Cloud is generally a supported migration path.

**Removing duplicate entries:**
I recommend doing this only on a **copy of the data source**, rather than on the original. The duplicates created during your import test do not indicate data loss; they are simply entries that were imported more than once.

Once the credential issue has been resolved, you can batch-select and delete the duplicate entries from the copy. After verifying that all entries and credentials are present and working correctly, you can use that cleaned-up copy as your new working data source.

Best regards,

Hello,

Before we investigate the cause further, could you please try the following as a workaround?

On your working 2024.3.16.0 installation:

1. Go to File → Export → Export Vault (.rdm).
2. Enable Include credentials. This option is disabled by default, which is likely why the passwords were not included in your previous export.
3. Set a master key to protect the export, then save the `.rdm` file outside the RDM configuration folder.

Then, on the newer version:

4. Go to **File → Import → Import Vault (.rdm)**.
5. Select the exported file and enter the master key when prompted.

This should transfer your connections, usernames, and passwords intact. Please let us know if this works.

Regarding your other questions:

**Master key vs. Windows profile key:**
For a standard local SQLite installation with no application password configured, sensitive data is protected using the local key stored in the `.enc` file. This key can also be protected using DPAPI and tied to your Windows user or machine. This is different from the separate "master key" concept used in Devolutions Server or Hub-style deployments.

**Migrating the SQLite workspace to Devolutions Cloud:**
Yes, migrating a local SQLite data source to Devolutions Cloud is generally a supported migration path.

**Removing duplicate entries:**
I recommend doing this only on a **copy of the data source**, rather than on the original. The duplicates created during your import test do not indicate data loss; they are simply entries that were imported more than once.

Once the credential issue has been resolved, you can batch-select and delete the duplicate entries from the copy. After verifying that all entries and credentials are present and working correctly, you can use that cleaned-up copy as your new working data source.

Best regards,

@Carl Marien
Hello,

I followed the procedure you provided:

1. I used the working RDM 2024.3.16.0 installation.
2. I went to File → Export → Export Vault (.rdm).
3. I enabled Include credentials.
4. I protected the export with a master key and saved the .rdm file outside the RDM configuration folder.
5. I imported the file into a new empty workspace in the newer RDM version and entered the master key when prompted.

However, the passwords were still not preserved. The connections and other entry information were imported, but the usernames and passwords were missing in the newer version. When I return to RDM 2024.3.16.0, all the saved credentials are available and work correctly again.

Therefore, the issue is specifically that the credentials are not being transferred, even when Include credentials is enabled. My goal is to upgrade RDM while preserving all existing connections, usernames, passwords, and other saved information, without having to recreate the credentials manually.

Could you please advise what additional setting, key, credential source, or encryption file is required for the passwords to be transferred correctly?

Best regards,