r04

Ich habe den Fehler endlich gefunden. Spannend das sich das nur auf RDM auswählt. 2 Programme stören hier. Die Microsoft Powertoys haben hier nicht mitgespielt und auf einem anderen Rechner war es der "MuMuPlayer". Interessant, dass es in der "normalen" Verbindung keine Auswirkung hatte.

Hallo Alexis,

ich habe einige Versuche unternommen. Ich muss gleich sagen, dass es bei einem anderen Kollegen das Problem nicht gibt. Dafür habe ich einen Workaround entdeckt. Erstmal zu deinen Fragen:

1. Wird die RDP-Sitzung eingebettet (in einem Tab von Remote Desktop Manager) oder extern in einem eigenen Fenster geöffnet? Welchen Wert hat bei dem Eintrag unter "Allgemein" die Einstellung "Anzeige"? Wird der native RDP-Client oder FreeRDP verwendet?

=> Eingebettet. Hier ein Standardeintrag exportiert aus der Datenbank:

<?xml version="1.0" encoding="utf-8"?>
<RDMExport>
  <Connections>
    <Connection>
      <AppVersion>2026.3</AppVersion>
      <ConnectionType>RDPConfigured</ConnectionType>
      <CreatedBy>MUSTERPC\Max</CreatedBy>
      <CreationDateTime>2026-10-19T19:27:28</CreationDateTime>
      <ID>eb08f4f6-21ab-4104-97a5-fd36e97ae4e4</ID>
      <Name>TestWin2k22</Name>
      <OpenEmbedded>true</OpenEmbedded>
      <Url>192.168.125.108</Url>
      <RDP>
        <SafePassword>CMR3XBWUQ9M=</SafePassword>
        <UserName>Administrator</UserName>
      </RDP>
    </Connection>
  </Connections>
  <DatabaseID>11fc7162-7786-4a09-81be-a2f9440fb0ce</DatabaseID>
  <Version>2</Version>
</RDMExport>

2. Welcher Wert ist im RDP-Eintrag unter "Lokale Ressourcen" bei "Tastatur" eingestellt (Auf dem lokalen Computer, Auf dem Remotecomputer oder Nur im Vollbildmodus) und bei "Tastaturlayout"?

=> Standard (auf lokalem Computer). Die Tastatursprache auf Deutsch an dieser Stelle anpassen ändert nichts.

3. Tritt das Problem auch auf, wenn Sie dieselbe Verbindung mit dem nativen Windows-Client (mstsc.exe) öffnen? Können Sie dort das @-Zeichen eingeben?

=> Nein hier ist das Problem nicht vorhanden

4. Tritt das Problem auch mit der Version 2026.3.14.0 auf? Und mit welcher 2026.2-Version hatten Sie das Verhalten nicht?

=> Eine 2026.3.13.0 hatte ich davor und eine 2026.3.14.0 kann ich nicht finden. Derzeit habe ich viele 2026.2.x Versionen durchprobiert und konnte noch keine Version finden wo es klappt.

5. Welche Windows-Version und welches Tastaturlayout (zum Beispiel Deutsch (Deutschland) oder Deutsch (Schweiz)) verwenden Sie auf dem lokalen Rechner, auf dem Remote Desktop Manager läuft?

=> Client ist Windows 11 25H2 mit Tastaturlayout Deutsch (Deutschland)

6. Welche Windows-Version und welches Tastaturlayout hat der Remote-Server oder Remote-Client? Tritt das Problem bei allen Zielsystemen auf oder nur bei bestimmten, zum Beispiel nur bei Windows Server 2019?

=> festgestellt bei Windows Server 2019, 2022 und 2025 alles Datacenter Varianten. Ich konnte eine 2012 R2 noch installieren, hier ist es ebenfalls.

7. Wenn Sie nach dem Auftreten die ALT-Taste einmal kurz drücken und loslassen, normalisiert sich das Verhalten dann wieder?

=> nein das nicht, ABER: statt AltGr + Q funktioniert aber Strg + Alt + Q und bringt das @ Zeichen. Auch Alt-Taste gedrückt halten und auf dem Ziffernblock 64 tippen funktioniert.

8. Tritt es nur in der PowerShell auf oder auch in anderen Programmen in der Remote-Sitzung, zum Beispiel im Editor (Notepad)?

=> Es ist in allen Programmen über RDP, Notepad, Notepad++, Browser,

9. Funktioniert das @-Zeichen sofort nach dem Verbindungsaufbau nicht oder erst nach einer bestimmten Aktion, zum Beispiel nach dem Einfügen mit der rechten Maustaste oder nach einem Wechsel zwischen Fenstern?

=> sofort nach dem Aufbau der Verbindung

10. Könnten Sie uns die genauen Schritte beschreiben, mit denen Sie das Verhalten auslösen, damit wir sie im Labor identisch nachstellen können?

=> habe ein Recording erstellt

Ich denke das die AltGr Taste in Kombination mit Q nicht richtig funktioniert.

Mit AutoHotKeyV2 mit diesem Skript habe ich die KeyCodes versucht in der RDP Sitzung aufzuzeichnen:

#Requires AutoHotkey v2.0
#SingleInstance Force

; Tastaturereignisse erfassen
InstallKeybdHook()

; Die letzten 100 Ereignisse speichern
KeyHistory(100)

; Mit F8 den Tastenverlauf anzeigen
F8::KeyHistory()

Ergebnis:

The oldest are listed first. VK=Virtual Key, SC=Scan Code, Elapsed=Seconds since the previous event. Types: h=Hook Hotkey, s=Suppressed (blocked), i=Ignored because it was generated by an AHK script, a=Artificial, #=Disabled via #HotIf, U=Unicode character (SendInput).

VK  SC	Type	Up/Dn	Elapsed	Key	
-----------------------------------
## ALTGR+Q
A2  01D	 	d	0.91	LControl       	
A5  138	 	d	0.00	RAlt           	
51  010	 	u	0.55	q              	
A2  01D	 	u	0.47	LControl       	
A5  138	 	u	0.00	RAlt           	

## STRG+ALT+Q
A2  01D	 	d	2.27	LControl       	
A4  038	 	d	0.03	LAlt           	
51  010	 	d	0.45	q              	
51  010	 	u	0.06	q              	
A4  038	 	u	0.34	LAlt           	
A2  01D	 	u	0.03	LControl       	

Bei AltGr + Q fehlt das KeyDown-Ereignis (d) der Q-Taste. Komisch. Über den "normalen" Remotedesktopmanager kommt das @ aber normal.

RDP Version ist: Aktuellste

Ich habe es aufgezeichnet. Meine Navigation ist automatisch ausgeblendet. Ich befinde mich am Startpunkt in der Liste und im Tab Dashboard.

Wenn man "zu langsam" im Filter der Navigation etwas eingibt oder kurz absetzt, dann schreibt man nicht im Filter weiter, sondern in der Suchleiste der Werkzeugleiste. Das sieht man am Anfang des Videos. Das passiert wenn man in der Navigation ganz oben den Ordner nutzt. Ist man auf einem anderen Eintrag kommt dies nicht.

Filtert man und scrollt mit den Pfeiltasten nach unten und kommt dabei über einen Ordner, dann schaltet im Hintergrund die Werkzeugleiste um und man blättert die Werkzeuge durch.

Hallo. Kann von euch jemand prüfen, ob folgendes ebenfalls passiert?

Wenn ich im "Remote Desktop Manager 2026.3.15.0" in einer RDP Sitzung zu einem Windows Server oder Client eine Verbindung aufbaue, kann ich in dieser das @ Zeichen nicht mehr eingeben. In allen anderen Sitzungen funktioniert dies.

Dazu kommt ein weiteres Phänomen, dass beim lokalen Kopieren und Einfügen auf der Remoteseite in der Powershell dann das Verhalten so ist, wie wenn die ALT Taste ständig gedrückt wird. Zum Beispiel bei diesem Code in einer Powershell auf einem Windows Server 2019. Wenn ich in der Powershell dies mit einem Klick auf die rechte Maustaste normalerweise einfüge, erscheint nicht immer der Text. Aber gleichzeitig ist die ALT Taste aktiv:

$Anmeldungen = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 6272, 6273
} -MaxEvents 100 | ForEach-Object {
    $Ereignis = $_
    $Daten = @{}

    ([xml]$Ereignis.ToXml()).Event.EventData.Data | ForEach-Object {
        $Daten[$_.Name] = $_.InnerText
    }

    [pscustomobject]@{
        Zeitpunkt    = $Ereignis.TimeCreated
        Ergebnis     = if ($Ereignis.Id -eq 6272) { 'Erlaubt' } else { 'Abgelehnt' }
        Benutzer     = $Daten['SubjectUserName']
        Domaene      = $Daten['SubjectDomainName']
        RadiusClient = $Daten['ClientName']
        ClientIP     = $Daten['ClientIPAddress']
        GeraeteMAC   = $Daten['CallingStationID']
        AP_SSID      = $Daten['CalledStationID']
        Richtlinie   = $Daten['NetworkPolicyName']
        Grundcode    = $Daten['ReasonCode']
        Grund        = $Daten['Reason']
    }
}

$Anmeldungen | Format-Table -AutoSize -Wrap

Danach wenn ich F4 drücke schließen sich die Fenster im Windows

Mit den 2026.2.x Versionen hatte ich das Verhalten nicht.

Zur Info: Mit dem Remote Desktop Manager 2026.3.15.0 64-bit wurde das Problem mit den Pfeiltasten noch nicht vollständig behoben (oder ein neues Problem dazu gebaut :-)).

Grundsätzlich kann man mit den Pfeiltasten nun navigieren. Aber kommt in der Liste ein Ordner, dann wird beim erreichen des Ordners im Hintergrund die Werkzeugleiste geändert und man blättert dann mit den Pfeiltasten die Befehle durch. Man sieht zwar die Navigationsleiste noch, aber der Fokus ist im Hintergrund.

Zur Info: Mit dem Remote Desktop Manager 2026.3.12.0 64-bit wurde das Problem mit den Pfeiltasten noch nicht behoben.

Dieser Fehler ist der aktuellen Version behoben.

Die Filterleiste ist jetzt zu sehen und verschwindet aktuell nicht von selbst. Auch das wieder öffnen funktioniert nun wie vorher.

Die Navigation mit den Cursortasten in der gefilterten Liste wurde scheinbar noch nicht in diesem Release behoben.

Die Werkzeuge für die ausgewählte Verbindung müssen weiterhin mit einem Doppelklick gestartet werden.

Danke für die Info. Ich habe auch erst einmal einen Rollback gemacht und warte die nächste Version ab.

Die 2026.3.9.0 ist leider noch schlimmer, weshalb der Rollback auf die 2026.2 die aktuell beste Option war.

Ich habe hier noch einen weiteren Fehler in der 2026.3.8. gefunden. Wenn man die Datenquelle anklickt und wieder an der gleichen Stelle klickt ohne zu wechseln, schließt sich die Navigation. Aber das kann auch sein das es in der nächsten Version schon behoben ist.

Hallo Devolutions-Team,

seit dem Update auf Remote Desktop Manager 2026.3.9.0 ist mir ein Problem mit der automatischen Einblendung der Navigationsleiste aufgefallen.

Sobald eine Sitzung geöffnet ist, wird die Navigationsleiste nicht mehr automatisch eingeblendet, wenn man mit der Maus in den entsprechenden Bereich fährt. Vor dem Update hat dies noch wie gewohnt funktioniert.

Ich habe einen kurzen Clip erstellt, in dem das Verhalten zu sehen ist.

Könnt ihr euch das bitte einmal anschauen und mir sagen, ob es sich dabei um ein bekanntes Problem handelt oder ob sich mit der neuen Version eventuell eine Einstellung geändert hat?

Vielen Dank für eure Unterstützung!

Viele Grüße

Hallo Maxim,

danke für die Info. Jetzt habe ich wieder die Statuszeile als Popup unten am Rand. So gefällt mir das besser. Damit kann man arbeiten.

Jetzt ist dafür die Navigationsleiste defekt, dafür mache ich ein neues Ticket.

In der aktuellen RDM-Version scheint sich bei der Browser-Darstellung etwas in Bezug auf die Statusleiste geändert zu haben.

Es gibt Webseiten, die verschiedene Elemente abhängig von der verfügbaren Fenstergröße berechnen und positionieren. Grundsätzlich ist es natürlich praktisch, die Statusleiste auszublenden – schließlich gewinnt man dadurch ein paar Pixel mehr Platz für die eigentliche Webseite.

Problematisch wird es allerdings, wenn die Statusleiste erst dann eingeblendet wird, sobald man mit der Maus über einen Link fährt. Dadurch ändert sich kurzzeitig die verfügbare Fenstergröße und manche Webseiten reagieren darauf mit einer Neuberechnung des Layouts.

Das Ergebnis kann durchaus unterhaltsam aussehen: Die Buttons fangen plötzlich an zu „hüpfen“. 😄 Weniger lustig wird es dann, wenn man versucht, genau diesen Button anzuklicken und er im entscheidenden Moment wieder ausweicht.

Meiner Meinung nach wäre es daher sinnvoll, wenn die Statusleiste entweder dauerhaft sichtbar bleibt oder alternativ über eine Option vollständig ausgeblendet werden kann, ohne beim Überfahren von Links wieder zu erscheinen.

Ich meine, dass dieses Verhalten in einer vorherigen RDM-Version noch nicht aufgetreten ist.

Der Focus springt auf die "Nadel" der Navigation, da mit der Leertaste dann das Fenster andocken könnte.

Danke für die Rückmeldung! Vielleicht wird es ja wieder so umgesetzt wie vorher. :-)

Soweit ich mich erinnere, musste ich bei den Werkzeugen die Buttons bisher keinen Doppelklick machen, damit sie gestartet werden.

Dabei ist mir noch etwas aufgefallen: Im Dashboard werden die Werkzeuge bei mir nur beim ersten Öffnen der Navigation angezeigt. Wenn ich die ausgeblendete Navigation anschließend erneut öffne, ohne den Host zu wechseln, ist die Werkzeugleiste verschwunden. Es wirkt so, als hätte dann kein Host mehr den Fokus.

Hallo zusammen,

ich habe ein Update auf die Version 2026.3.8.0 durchgeführt und dabei einige Änderungen im Bedienverhalten festgestellt, die meinen bisherigen Workflow leider deutlich umständlicher machen.

Direkt nach dem Update waren zunächst verschiedene Fenster anders eingestellt. Unter anderem waren meine bisherigen Einstellungen des Filterfensters inklusive der konfigurierten Spalten nicht mehr vorhanden. Ich könnte mir vorstellen, dass viele Anwender ihre individuell vorgenommenen Einstellungen nach einem Update gerne beibehalten würden. Vielleicht könnte geprüft werden, ob sich dieses Verhalten vermeiden lässt.

Eine weitere Änderung betrifft die Werkzeuge für einen ausgewählten Host. Bisher war mein gewohnter Ablauf sehr einfach:

Host einmal anklicken → rechts erscheinen die Werkzeuge → gewünschten Befehl auswählen.

Am häufigsten benötige ich dort beispielsweise „Verbinden“, sofern diese Funktion verfügbar ist.

Aktuell muss ich zunächst auf den Tab „Favoriten“ wechseln und anschließend den gewünschten Befehl per Doppelklick ausführen. Dadurch sind aus einem Klick nun mehrere geworden. Gibt es eventuell eine Möglichkeit oder Einstellung, mit der sich das bisherige Verhalten wiederherstellen lässt?

Am meisten stört mich allerdings das geänderte Verhalten der Filterfunktion.

Meine Filterleiste ist so eingestellt, dass sie automatisch ausgeblendet wird. Früher hatte das Suchfeld beim Öffnen der Filterleiste automatisch den Fokus. Ich konnte also die Filterleiste öffnen und direkt anfangen zu tippen.

Seit dem Update ist das leider nicht mehr der Fall. Nach dem Öffnen der Filterleiste muss ich das Suchfeld zunächst zusätzlich anklicken, bevor ich meinen Filter eingeben kann. Auch das macht den bisher sehr schnellen Ablauf unnötig umständlicher.

Hinzu kommt eine weitere Änderung: Nachdem ich einen Filterbegriff eingegeben hatte, konnte ich bisher mit den Pfeiltasten direkt durch die gefilterten Einträge navigieren. Gerade wenn viele Einträge mit unterschiedlichen Funktionen wie SSH, Web, SCP usw. vorhanden sind, war das für mich eine sehr schnelle und komfortable Arbeitsweise.

Seit dem Update navigieren die Pfeiltasten stattdessen durch die zuletzt verwendeten Suchbegriffe bzw. die Filterhistorie. Um anschließend in die Ergebnisliste zu gelangen, hilft leider auch die TAB-Taste nicht direkt weiter.

Daher meine Frage: Ist dieses Verhalten so beabsichtigt oder gibt es eventuell bereits eine Option, mit der sich das frühere Verhalten wieder aktivieren lässt?

Falls nicht, würde ich mich freuen, wenn geprüft werden könnte, ob man die bisherige Bedienung wieder ermöglichen kann – beispielsweise optional über eine Einstellung. Ideal wäre aus meiner Sicht:

• Beim Öffnen der Filterleiste erhält das Suchfeld automatisch den Fokus.

• Nach Eingabe des Filters kann man mit den Pfeiltasten direkt durch die gefilterten Ergebnisse navigieren.

• Die bisherige schnelle Bedienung der Werkzeuge eines ausgewählten Hosts bleibt erhalten bzw. kann optional wieder aktiviert werden.

Vielen Dank fürs Prüfen und viele Grüße

Falls ich euch hier etwas helfen kann, dann gerne bescheid sagen.

Vielen Dank, ich werde es dann gleich testen wenn es verfügbar ist :-)

Ja funktioniert. Geht auch an dieser Stelle mit Platzhalter:

document.querySelector('#usr').value = '2';
// oder:
document.querySelector('#usr').value = $USERNAME$;

Hallo Min,

verwendet wird die Version 2025.3.28.0 und als Datenquelle habe ich hier beide SQLite und XML getestet. Auch bei beiden älteren Versionen 2023.2.27.0 und 2024.1.32.0 ist das Verhalten identisch. Wenn man in einer SSH Verbindung einen VPN/Tunnel/Gateway mit SSH Verbindung einstellt, dann wird der dort angegebene Hostname (und Port) nach dem Speichern in den Hostnamen der Allgemeinen Einstellung der Verbindung kopiert.

Bei den Portforwardings habe ich bisher nur Webbrowser oder WinSCP gebraucht. Bei größeren Themen brauche ich dann sowieso die VPN Verbindung, um mehrere Dienste/Geräte zu erreichen. In diesem Fall war dies ein neuer Versuch für einen unkomplizierten Zugriff.

Ein weiterer Unterschied beim Portforwarding im Gegensatz zum SSH Gateway ist, dass ich Agent Forwarding nicht benötige und auch zwei verschiedene SSH-Keys benutzen kann mit unterschiedlichen Benutzern. In dem Fall fand ich es somit zum ersten mal heraus, dass der PuttyAgent beim SSH Gateway nicht einstellbar ist.

Hallo Min. Der Webbrowser ist embedded. Verwenden tue ich aktuell die 2025.3.28.0. Wie ein Wunder konnte ich noch zwei alte Versionen bei mir finden: 2023.2.27.0 und 2024.1.32.0. Bei beiden funktioniert das beschriebene mit der Dropdownliste und dem "name" Attribut.

Ich habe hier schon viel Erfahrung mit dem RDM und nun ist mir bei einer einfachen Sache aufgefallen, dass das Ausfüllen nicht mehr wie in der Vergangenheit funktioniert. Bei den HTML-Steuerelementen kann man "Benutzername-ID" und "Passwort-ID" hinterlegen. Das funktioniert auch mit Formularfeldern die keine ID hinterlegt hatten und dafür aber das Attribut "name".

Nehmen wir das Beispiel:

<input type="password" name="pwd" size="10" maxlength="20" value="" class="lg" style="background: rgb(173, 216, 230);">

Trägt man bei den HTML-Steuerelementen unter "Passwort-ID" den Text "pwd" ein, so funktioniert dies ohne Probleme und der Text wird ausgefüllt. Bei einem Dropdownfeld funktioniert diese funktion nur noch mit einer hinterlegten ID, aber nicht mit name="".

Nehmen wir dieses Beispiel:

<select size="1" name="usr" length="10" style="background: rgb(173, 216, 230);">
	<option value="0">Nutzer&nbsp;0</option>
	<option value="1">Nutzer&nbsp;1</option>
	<option value="2">Nutzer&nbsp;2</option>
	<option value="3">Nutzer&nbsp;3</option>
</select>

Trägt man bei den HTML-Steuerelementen unter "Benutzername-ID" den Text "usr" ein, so funktioniert dies nicht. Es wird nichts in der Dropdown Liste umgeschaltet.

In einem Versuch mit einer lokalen Seite habe ich den gleichen HTML Code genommen und eine ID hinzugefügt, also so:

<select size="1" id="usr" name="usr">

Dann wird das Dropdownfeld wie gedacht beim Wert 2 direkt auf "Nutzer 2" umgeschaltet. Die Webseite bei der mir es aufgefallen ist, ist eine Heizungssteuerung bei der ich leider die Webseite der Heizungsfirma nicht umprogrammieren kann :-).

Mit Umwegen über Javascript kann ich mir sicher das Feld wieder anders auswählbar machen. Schöner ist es, wenn es auch einfach geht. Leider kann ich nicht mehr die alten RDM Versionen laden, weshalb ich nicht mehr prüfen kann, seit wann dieses Verhalten so ist.

Ist das Verhalten ein Bug in der Vergangenheit oder jetzt neu? :-)

Ich vermute, dass ich hier ein Verständnisproblem habe und hoffe auf einen Hinweis.

In einigen Fällen möchte ich mir ein separates VPN für den Zugriff auf einen SSH-Server hinter einem Gateway sparen.

Für HTTP/HTTPS sowie SFTP (WinSCP) funktioniert das problemlos über eine SSH-Verbindung mit Port-Forwarding, auch in Kombination mit dem PuTTY-Agent. Dabei baut RDM zunächst die SSH-Verbindung auf, nutzt den PuTTY-Agent zur Authentifizierung, vergibt einen dynamischen lokalen Port und startet anschließend z. B. den Browser auf localhost:<dynamischer Port>. Das ist sehr komfortabel, da keine festen Ports gepflegt werden müssen.

Mit WinSCP funktioniert dieses Vorgehen ebenfalls, allerdings nur ohne dynamischen Port, da $DYNAMIC_PORT$ dort nicht unterstützt wird (wäre aus meiner Sicht ein Feature-Request):

Für eine reine SSH-Verbindung bin ich davon ausgegangen, dass der Ablauf identisch sein müsste – hier verhält sich RDM jedoch anders. Ob es unbedingt ein Portforwarding sein muss steht auf einem anderen Blatt:

• Wird eine Verbindung über VPN/Tunnel/Gateway konfiguriert, wird der im eigentlichen SSH-Eintrag hinterlegte Host durch die Gateway-Einstellungen überschrieben. Der Sinn dieses Verhaltens erschließt sich mir nicht, da damit die Zieladresse faktisch ignoriert wird.

• Alternativ habe ich versucht, das SSH Gateway (Jump Host) zu verwenden. Dort können jedoch nur Verbindungen angelegt werden, ohne den PuTTY-Agent nutzen zu können. Benutzername/Kennwort ist keine Option.

• Hinterlege ich stattdessen den SSH-Key direkt, muss ich am Key zwingend einen Benutzernamen angeben. Das ist für mich nicht nachvollziehbar, da der SSH-Key an sich nicht benutzerspezifisch ist.

  • In meinem Szenario melde ich mich z. B. am Gateway mit Benutzer User1 an und anschließend am Zielserver mit User2.

  • Lege ich den Benutzernamen im Key nicht fest, wird dieser interaktiv abgefragt.

  • Lege ich ihn fest (z. B. User1), funktioniert die Anmeldung am Zielserver mit User2 nicht mehr.

  • Verwende ich denselben Key für weitere Server mit anderen Benutzern (z. B. User3), müsste ich den Key mehrfach anlegen, was unnötig komplex ist.

  • Auch Variablen wie $PARENT_USERNAME$ lassen sich an dieser Stelle offenbar nicht verwenden, da die Nutzer unterschiedlich sein können

Daher meine Frage:

Übersehe ich in diesem Ablauf eine grundlegende Einstellung oder ein Konzept in RDM?

Das Öffnen einer Webseite oder einer WinSCP-Verbindung über SSH-Portforwarding ist sehr einfach wie man oben sieht, während sich eine einfache SSH-Verbindung über Gateway deutlich komplizierter darstellt.

Vielen Dank für jeden Hinweis oder Erfahrungswert.

Wann steht diese zu Verfügung :-)

Hallo Zachery.

das Video habe ich unter dem dafür vorgesehenen Link aus der Mail hochgeladen.

Ergänzend, da man es nicht sieht ist ein frisches Debian 11 als Client gewesen mit Zugriff über ein neues Windows 11 mit portablen RDM Free. Die Debian Version ist dabei nicht wirklich entscheidend, da es bei allen Versionen auftritt.

Gruß Ronny

Hallo Samuel,

die Logdatei mit der Einstellung "Verbose 2" habe ich hochgeladen. Da steht meiner Meinung nach nicht wirklich etwas brauchbares drin was sie sicher besser beurteilen können.

Falls noch etwas benötigt wird, kann ich es gerne erledigen.

Gruß Ronny