Eduard Sepúlveda López

Hello Danvo1,

No, nothing else changed. You're right: you had already confirmed the fix for 2026.3.16.0 in the other thread, and we missed that before posting here. Sorry for the extra notification.

Thanks again for the detailed report and for testing the fix so quickly. Since all three issues are resolved, we'll consider this thread closed.

Best regards,

Hello Danvo1,

Good news: the fixes for these went out in RDM 2026.3.16.0, so they are included in the current version, 2026.3.17.0.

• New sessions now open to the right of the Navigation tab, and Navigation stays where you placed it.

• Saving an entry or the settings no longer switches you away from the Navigation tab.

Could you update to 2026.3.17.0 and let us know if all three behave as expected with your layout? If anything still jumps, just tell us which one and we will look into it again.

Best regards,

Hi sander02,

Thanks for the clear description, we were able to reproduce it. Since 2026.3.16.0, clicking into an undocked session switches the main window to that session's placeholder tab, which hides the embedded session. That's a regression, not something you can change in the settings.

Our development team has already fixed it, and the fix is planned for the next release, 2026.3.18.0. Please note that 2026.3.17.0, which is out now, does not include it yet.

Until then, there are two options:

1. Undock both sessions. The main window can still switch tabs, but both sessions stay visible in their own windows, so you can work with them side by side.

2. If you need the previous behaviour right away, you can use the current stable version, 2026.2.20.0, until 2026.3.18.0 is available.

We'll post an update here when the release is out.

Best regards,

Hello iscs-mark,

Thank you for the detailed post and screenshots.

Scroll bars when a session opens This is a known issue in the current 2026.3 versions, and other users have reported it in this thread: https://forum.devolutions.net/topics/56781/all-rdp-sessions-open-with-scroll-bars. Our development team is working on a fix. Your case is useful to them because your entry uses Smart sizing, which should never show scroll bars.

To help them reproduce it, could you tell us:

• The resolution and Windows display scaling (100%, 125%, 150%...) of the monitor where RDM is open

• Whether the RDM window is maximized or snapped to part of the screen

• If possible, an export of one affected entry (right-click the entry > Export > Export entry (.rdm), with the password removed)

Until the fix is available, toggling Smart sizing from the tab's right-click menu is the best way to clear the scroll bars.

Batch edit In the Screen sizing mode list, "Default (Smart sizing)" is the Default option. The text in parentheses only shows what Default resolves to. Picking it saves the entries as Default, not as Smart sizing. To force Smart sizing on all of them, pick the plain "Smart sizing" item instead.

The color depth not changing and the empty Entries list after saving are not expected, though. Could you tell us:

• Which workspace type you use (local, SQL Server, Devolutions Server, Devolutions Cloud...)

• If the entries show the new values after pressing F5 or restarting RDM

A short screen recording of the batch edit, from opening the dialog to the result, would help us a lot.

Best regards,

Hi joebruns,

Thanks for coming back with the result, glad 2026.3.16 sorted it out. This was a known issue with embedded RDP sessions to Windows Server 2022, where a stray "@" could be sent when the session got focus back. The fix landed in 2026.3.14, so any version from that one on has it.

Quick heads-up in case you notice it: on current 2026.3 builds, the keyboard in an embedded RDP session can sometimes act as if Alt is held down after an Alt+Tab (letters open menus instead of typing). If that happens, setting File > Settings > Entry types > Sessions > Remote Desktop (RDP) > Advanced > Enable API hooking to Disabled and restarting RDM avoids it until the fix ships in an upcoming version.

Best regards,

Hello sander02,

Thanks for confirming, we're glad 2026.3.16.0 fixed it. The Overview tab should now load large Password List entries without the freeze.

We'll mark this thread as resolved. If it happens again, or something else comes up, please open a new topic and we'll take a look.

Best regards,

Hallo Footless4468,

danke für Ihre Geduld und die genauen Antworten.

Wir konnten Ihr Verhalten jetzt mit 2026.3.16.0 nachstellen. Wenn im Eintrag keine Felder zum Ausfüllen hinterlegt sind, sondern nur die Anmelde-Schaltflächen ID, versucht RDM den Klick genau einmal, direkt nachdem die Seite geladen ist. Ihre Anmeldeseite (nach dem HTML vermutlich Azure AD B2C bzw. Entra External ID) blendet den Button "Weiter mit Microsoft" aber erst kurz nach dem Laden per JavaScript ein. Im Moment des Klicks ist der Button also noch nicht da, und RDM versucht es kein zweites Mal. Deshalb passiert nichts, auch ohne Fehlermeldung.

Mit einer Verzögerung funktioniert es bei uns zuverlässig:

1. Eintrag bearbeiten > Anmelden > Automatisches Ausfüllen.

2. "Verzögerung für automatisches Ausfüllen" aktivieren und den Wert auf 3000 ms setzen.

3. Speichern, den Tab schließen und den Eintrag neu öffnen.

Braucht Ihre Seite länger zum Aufbauen, erhöhen Sie den Wert entsprechend. Wenn es klappt, können Sie ihn auch schrittweise verringern.

Zum Testen gibt es außerdem den Schlüssel-Button in der Symbolleiste des eingebetteten Browsers ("Anmeldeinformationen in aktueller Seite einfügen"). Er löst den Klick von Hand aus, sobald die Seite vollständig angezeigt wird.

Wir haben das Verhalten außerdem an unser Entwicklungsteam weitergegeben, damit RDM künftig wartet, bis der Button erscheint.

Viele Grüße,

Hallo Footless4468,

ja, das geht. Seit RDM 2026.2.7 gibt es dafür den Anmeldeinformationstyp Social-Login:

1. Den Website-Eintrag bearbeiten.

2. Unter Anmeldeinformationen den Typ Social-Login wählen und als Anbieter Microsoft auswählen.

3. Soll RDM auch die Microsoft-Anmeldeseite ausfüllen, wählen Sie in derselben Liste statt des Anbieters einen Website-Eintrag, der auf login.microsoftonline.com zeigt und Ihre Microsoft-Anmeldedaten enthält. Solche Einträge erscheinen dort automatisch.

Beim Öffnen sucht RDM dann den Button "Weiter mit Microsoft", klickt ihn und füllt auf der Microsoft-Seite die Anmeldedaten aus.

Zwei Hinweise:

• Laut unserer Dokumentation braucht Social-Login die installierte Password-Manager-Browsererweiterung: https://docs.devolutions.net/rdm/ribbon-menu-bar/edit/entry-credentials-options/

• Im privaten Modus (Inkognito) des Browsers funktioniert das automatische Ausfüllen nicht.

Falls der Button nicht erkannt wird, können Sie im Tab HTML Steuerelement ID die ID des Buttons bei Anmelde-Schaltflächen ID eintragen und Automatisch senden aktivieren. Die ID finden Sie in Ihrem Browser per Rechtsklick auf den Button > Untersuchen.

Geben Sie uns gern Bescheid, ob es klappt.

Viele Grüße

Hi NeilSmith2025,

Thank you for the report. This is a known issue in RDM 2026.3. When several SSH sessions are opened at the same time (for example with "Open selection"), only the first tab gets keyboard focus. The other tabs need a click inside the terminal before you can type. It worked correctly in 2026.2.

Our development team has already fixed it, and the fix will be in an upcoming RDM update.

Until then, you can avoid the extra click by opening the SSH sessions one at a time, or by using "Duplicate session" on an open tab. Tabs opened this way get focus correctly when you switch to them. If you prefer, you can also use the LTS version 2026.2.20.0, which does not have this problem.

Could you confirm two things so we can make sure it is the same issue?

1. Your RDM version (Help > About).

2. How you open the sessions: all at once ("Open selection") or one by one.

If it also happens when you open the sessions one by one, please tell us, because the current fix covers the batch case.

Best regards,

Hi skoupidaki,

Thanks for the screenshots. This is a bug in 2026.3.12: "Open from template" always used the first template in your list (Default Wide Screen here), no matter which one you picked. It's fixed in 2026.3.13, so updating RDM to the latest version will sort it out. I tested it here with a 1560x810 template on an external RDP entry, and the session opens at 1560x810 as expected.

Also, if you'd rather not switch templates between home and work, you can set Remote desktop size on the entry to Current work area size. RDM then sizes the session to whatever monitor it opens on, so the same entry fits both setups.

Let me know how it goes.

Best regards,

Hi Footless4468,

Quick update before you change anything else. I passed all of this on to our team, and they're now reviewing the change with the Devolutions Server team. It was made to fix a security issue, but they're looking at allowing synchronizers in the user vault again. I don't have a version or date yet, and I'll update this thread as soon as I know more.

So my suggestion for now is to keep using your old setup:

• Your existing "Bitwarden Sync" in your user vault still runs, as your test showed. Keep it, and don't delete it or its "Bitwarden" folder.

• Your RDP sessions can stay on "Nach Namen suchen (Benutzer-Tresor)" with admin-rdp. They keep finding the entry that this sync creates in your user vault.

• The only limitation is that you can't edit that sync until this is sorted out.

Your new shared vault doesn't get in the way. You can keep it as a test or ask your admin to remove it. If you keep both syncs running, you'll have two copies of every item, so I'd only run one of them.

If you need to change your sync settings before then, the other options are still there: a Bitwarden credential entry named admin-rdp in your user vault, which your sessions would find by name, or "Verknüpft (tresorübergreifend)" pointing at the synced entry in your new vault.

About the filter: I'd still like to understand why E-… was synced. When you have a moment, could you reopen the sync in your new vault and send a screenshot of the Filter tab? Please also tell me whether a folder with items from "Mein Tresor" shows up after a sync.

Let me know how it goes.

Hi Footless4468,

Yes, that setup works. The new vault, with you as the only one who has access, is now where your Bitwarden sync lives.

Your RDP sessions and admin-rdp "Find by name" only searches your user vault, so it won't find the synced entries in the new vault. The good news is that you can keep your sessions exactly as they are by combining the two things you've already set up:

• The Bitwarden sync in your new vault gives you all your Bitwarden items in RDM.

• A Bitwarden credential entry named admin-rdp in your user vault, like the "Bitwarden v2" entry you tested earlier, is what your sessions find. "Find by name" also finds that entry type, and it reads the password live from Bitwarden.

So rename your "Bitwarden v2" entry to admin-rdp and link it to the admin-rdp item, as in my earlier post. Then delete the old synced admin-rdp entry from your user vault, so RDM doesn't find two entries with the same name.

You could also switch your sessions to Linked and point them at the synced entry in the new vault. I'd only do that if nobody else uses these sessions, though. Other users can't see your private vault, so the credential would stop working for them.

Duplicate check jumping back to "Stamm" Good catch, that's a bug. I reproduced it on our side: the value is overwritten every time you save. I've reported it to our team. As long as the vault only holds this sync, Stamm and Ziel give you the same result, so you can leave it for now.

The folder you unchecked The filter only imports the collections that are checked. My guess is that those entries were imported before you unchecked the folder. A new sync leaves entries it no longer imports where they are, because Aktion bei Eintragsunterschied in the Erweitert tab starts at None. Your old sync probably had it set to Delete, which is why the entry you removed in Bitwarden disappeared there. Delete that folder in RDM and run the sync again, and it shouldn't come back. If you want the new sync to clean up on its own like the old one, set that option to Delete. It only touches entries this sync created.

If the folder comes back after a fresh sync, let me know and send a screenshot of the entries it creates.

Let me know how it goes.

Hi Footless4468,

You're right on both points, and I need to correct what I said earlier. Sorry about the confusion.

The server blocks saving a synchronizer in the user vault, meaning creating a new one or changing the settings of an existing one. That's the error you got when you changed the destination folder. Your existing "Bitwarden Sync" was saved before this change. RDM runs the Bitwarden sync on your machine, so it still works, as your test showed. What you can't do anymore is edit it or create a new one in the user vault.

I've passed this on to our team, along with your point about the Add new entry dialog. It shouldn't offer the synchronizer in the user vault if it can't be saved there. I reproduced it on our side and confirmed it. I've also asked them whether existing synchronizers in the user vault are meant to keep running. I'll update this thread when I have an answer. Until then, keep in mind that this could change in a future version.

About the shared vault: regular users can't create vaults themselves. Your DVLS administrator creates them in the Devolutions Server web interface under Administration > Vaults. They can give you full access and keep everyone else out, so only you see the synced entries: https://docs.devolutions.net/server/web-interface/administration/user-and-security-management/vaults/

About the 3 entries that didn't show up at first: since the sync runs now, are they there after a new sync? If not, please tell me which Bitwarden folder or collection they're in and send a screenshot of the Filter tab of your Bitwarden Sync.

Let me know how it goes.

Hi Footless4468,

Got it, thanks for clarifying. To have all your Bitwarden items show up as entries in RDM, you need the Bitwarden synchronizer. Since the server no longer runs synchronizers in the user vault, it has to live in a shared vault:

1. Ask your DVLS administrator for a shared vault (or a folder in one) where you have full access and nobody else does, if you don't have one already.

2. Create a new Bitwarden synchronizer there with the same settings as your old "Bitwarden Sync", and run it. All your Bitwarden items will be imported into that vault and only you will see them.

3. Delete the old "Bitwarden Sync" entry and the old "Bitwarden" folder from your user vault.

One thing to plan for: "Find by name (user vault)" only searches your user vault, so it won't find the synced entries in the shared vault. In your RDP sessions, change Credentials to Linked and pick the synced admin-rdp entry in that vault. If many sessions use the same credentials, select them all and use batch edit to change them at once.

Let me know how it goes.

Hi joaopnascimento,

Thanks for the screenshots, they helped a lot. The DevTools capture shows something important. On the OTP page, the code field has name="AuthenticatorCode" but its id is password. Your entry uses password as the Password ID, and the extension checks the password control before the OTP control. So on the second page it can grab that field as the password field before it gets to the OTP. Recent extension versions changed how autofill on page load works on multi-step logins, which would explain why it worked with your previous setup and stopped now.

Could you try this:

1. In the entry, go to the HTML control tab and clear the Password ID field. Leave the OTP ID as AuthenticatorCode.

2. Save, open the session again and go through the login.

The extension should still find the password field on the first page by itself. Then the OTP field on the second page won't be taken by the password ID.

If the first page stops filling the password after that, set the Password ID to the name of the password field on the first page instead, as long as it's something other than "password".

If it still doesn't work, please send us:

• The extension version from chrome://extensions.

• The full HTML of the OTP input, including its type attribute.

• Whether the OTP field stays empty or gets something typed into it (for example, your password).

Best regards,

Hi Footless4468,

You're almost there. Your RDP sessions use "Find by name (user vault)" with admin-rdp. That option looks for a credential entry in your user vault whose name is exactly admin-rdp. Until now that was the entry the Bitwarden Sync created. RDM doesn't look inside your "Bitwarden v2" entry, so you just need to give it the name your sessions already search for:

1. Edit the "Bitwarden v2" entry and rename it to admin-rdp.

2. In the General tab, click the ellipsis next to Credentials and pick the admin-rdp item from your Bitwarden vault. This ties the entry to that one item.

3. Save. Delete the old admin-rdp entry that the sync created in your "Bitwarden" folder (or delete the whole folder if you don't need it anymore). Otherwise RDM finds two entries with the same name and asks you which one to use, and the old one has a password that won't update anymore.

Your RDP sessions don't need any change. They keep searching for admin-rdp and now find the entry that reads the password live from Bitwarden.

If your sessions use other names too, create one Bitwarden entry for each name the same way.

Let me know how it goes.

Hi perler,

Glad that sorted it! It's an easy one to miss, since "Auto-focus dashboard" stays available in the settings even when the Dashboard pane is off, it just has nothing to bring forward.

If anything else comes up, feel free to open a new topic.

Regards,

Hi Danvo1,

My pleasure! We will keep you posted about the bugs.

Best regards,

Hi perler,

Thanks for the details. What you describe should work with "Auto-focus dashboard" set to "Always", so it's not the expected behaviour.

That setting only does something when the Dashboard pane itself is turned on. Could you check under Window > Layout that Dashboard is enabled? You can also toggle it with Alt+F6. If it was off, turn it on, then click an entry with no open session while another session tab is active. The dashboard should now come forward.

If the Dashboard option is already on, or the Auto-focus dashboard option looks greyed out or missing in some places, your administrator may manage it through a policy. In that case, let us know whether your RDM is connected to Devolutions Server or uses any group policies.

If it still doesn't switch after that, a short screen recording showing the click and the result would help us see what's going on.

Regards,

Hi Footless4468,

Thanks for the screenshots, they make it clear what is happening.

This is an intended change on the Devolutions Server side rather than a bug. For security reasons, synchronizers are no longer allowed in the user vault. A synchronizer connects out to an external service with stored credentials, and that kind of outbound connection has to live in a vault an administrator controls. This also explains your missing entries: your existing "Bitwarden Sync" sits in your user vault, so the server now refuses to run it, and nothing new is imported. Changing its destination folder fails for the same reason.

You have two options:

1. Move the synchronizer to a shared vault. Recreate the Bitwarden synchronizer in a shared vault where you have full access, ideally inside a folder with permissions restricted to you. The imported entries will then land there, and only you will see them. If you don't have a suitable vault, your DVLS administrator can create one for you.

2. Use the Bitwarden credential entry instead. If you only need your Bitwarden credentials in your sessions, you can use the Bitwarden credential entry type, which you can keep in your user vault. It looks up your Bitwarden credentials when you need them, so nothing has to be synchronized. Both entry types are described here: https://docs.devolutions.net/rdm/knowledge-base/knowledge-base-articles/entry-settings/bitwarden/

Once that is done you can delete the old "Bitwarden Sync" entry from your user vault, since it can no longer run there.

Let me know how it goes.

Hi victortrouillot,

Thanks for the report. This is how RDM currently behaves with shortcuts. A shortcut is the same entry placed in more than one folder. When RDM checks whether the entry is already open, it also looks at which folder you opened it from. So opening it from a second folder is treated as a new session, even with "Allow opening multiple connections" set to No.

There's no setting at the moment that makes all shortcuts of an entry count as one. The closest workaround for your host scenario is to always open that sub-entry from the same place, for example a single folder or your Favorites. RDM will then switch to the existing tab instead of opening a second one.

If you'd like shortcuts to count as the same entry, please post it as a feature request here: https://forum.devolutions.net/forums/17/feature-request. That way the product team can review it and other users can upvote it.

Best regards,

Hi joaopnascimento,

Thanks for the report. We checked what changed in RDM 2026.3.13 and the way RDM hands the OTP to the browser extension is the same as in the previous version, which fits with the manual fill still entering the right code. A recent browser extension update changed how the automatic fill behaves on pages where the username or password fields configured in the entry aren't present, so we'd like to check whether that's what you're hitting.

Could you tell us:

1. The extension version shown in chrome://extensions (and edge://extensions).

2. Whether the OTP field appears on the same page as the password, or on a separate step after you log in.

3. In the website entry, which control IDs are filled in (username, password, OTP).

Also, as a quick test: if the OTP control ID isn't set in the entry, try setting it to the ID of the OTP field and let us know if the automatic fill picks it up.

Best regards,

Hi Danvo1,

Thanks for the detailed report and the screenshot, the steps made this easy to follow.

We reproduced all three on our side with 2026.3.13 using the same layout as yours (Navigation docked as a document tab, Dashboard hidden): new sessions open to the left of the Navigation tab, and saving an entry or the settings switches to another tab instead of staying on Navigation. We've sent this to our developers.

There's no setting today that controls where new tabs open, so for now the only way around it is keeping Navigation docked on the side. We'll update this thread when we have news on a fix.

We keep bugs and feature requests in separate threads, so we've moved your request to pin the Navigation tab into its own post, using your text: https://forum.devolutions.net/topics/56892/option-to-pin-the-navigation-tab-when-it-is-docked-as-a-document-tab

You can subscribe to that thread to get updates on it.

Best regards,

Posted on behalf of: Dan

vo1

"I prefer using the Navigation panel as a tab in the main workspace instead of keeping it docked on the left side.

This allows me to maximize the available screen space for remote sessions. I also don't need the Dashboard, so ideally the Navigation tab should act as my main starting point.

The Navigation tab should remain the leftmost tab, with new sessions opening to its right.

Ideally, there should be an option to pin the Navigation tab in a fixed position.

Desired Workflow

My preferred layout is:

- Navigation displayed as a tab in the main workspace.

- Navigation remains the leftmost tab.

- New sessions open to the right of the Navigation tab.

- Editing entries does not change the currently active tab.

- No Dashboard required.

This layout provides significantly more usable screen space while still allowing quick access to the Navigation tree.

Request: Please consider allowing the Navigation tab to remain fixed in position and retain focus after editing entries."

Hi Deas,

As promised, here's the update from our development team.

On SQL Server workspaces this is the intended behaviour. Removing or resetting a user's MFA is reserved for administrators, and the "Users: Custom" system permission doesn't include it. It's not something that broke in a recent version. It's how these permissions are designed for SQL workspaces.

Right now there's no way to give that right to a non-admin user on a SQL workspace. For now, a full administrator has to remove the MFA in Administration > Users.

If you'd like delegated user admins to be able to do this, it would be worth posting it in the Feature Requests section of the forum. That way the product team sees it and other users can vote for it.

Thanks again for your patience and all the details you sent.

Best regards,