Terminalserver - Unterschiedliche Behandlung von Usern abhängig vom RDP-Client

[Sithys]

Moin zusammen,
das sind immer alles Phänomene... man man man. Ich habe die IT übernommen von einem anderen IT-Dienstleister und den Kunden anschließend mit den Mitarbeitenden auf einen Terminalserver 2025 migriert. Jetzt möchten die gerne ein ziemlich altes Programm benutzen, zu welchem keine Dokumentation oder sonstiges mehr vorhanden ist und ich bekomme es nicht zum Laufen. Das Programm verwendet irgendeine ganz alte SAP-Datenbankstruktur auf Ordnerbasis innerhalb des Programmordners. Jetzt folgendes Szenario:

Der User m.mustermann meldet sich von seinem Windows 10 Rechner über die standard RDP-App (mstsc) auf dem Terminalserver an, doppelklickt die Programm.exe und bekommt eine Fehlermeldung "Keine Verbindung zum ADS-Server, sofort Verantwortlichen informieren".
Ich melde den User ab und mache absolut genau das gleiche vom Mac mit der neuen Windows-App oder der alten RDP-App und verbinde mich mit m.mustermann mit dem Terminalserver 2025. Der User macht einen Doppelklick auf die Programm.exe und siehe da: Das Programm startet ohne Fehlermeldungen.

Ich habe mittlerweile schon rausgefunden, dass bei der Verbindung vom Mac aus z.B. explizit für den User notwendige Temp-Dateien in F:\Programm\Temp abgelegt werden, das klappt aber nur bei der Mac-Verbindung. Bei der Windows-Verbindung werden dort keine Dateien abgelegt.

Kann ich mir aktuell gar keinen Reim drauf machen, vielleicht hat ja von euch jemand eine Idee, wo ich überhaupt weiter debuggen könnte. GPOs etc. ist ja alles identisch, es ist ja der gleiche User.

 

[redjack1000]

Was passiert, wenn du bei dem Win10 einen anderen RDP-Client verwendest?


Cu
redjack

 

[VDC]

Mal UDP für RDP deaktiviert?

In beiden Fällen Verbindung über UPN bzw. SAMAccountname?

 

[Sithys]

Was passiert, wenn du bei dem Win10 einen anderen RDP-Client verwendest?

Welchen würdest du da zum Testen empfehlen?

Mal UDP für RDP deaktiviert?

In beiden Fällen Verbindung über UPN bzw. SAMAccountname?

UDP kann es nicht sein, die Verbindungen laufen ausschließlich über TCP. Anmeldung erfolgt jeweils immer über Domäne\username

 

[VDC]

UDP kann es nicht sein, die Verbindungen laufen ausschließlich über TCP.

Bist du dir sicher und hast das so konfiguriert? Im Default ist RDP immer TCP und UDP seit 2012R2.

 

[Smily]

Vielleicht werden irgendwo Temp Dateien hin geschrieben. Alte Programme haben ihre Temps oder Einstellungen gerne in den eigenen Programmordner geschrieben. Und vielleicht macht da der MAC was anders.

Du könntest vielleicht ProcMon verwenden, also den Process Monitor von Microsoft. Da kann man ganz gut sehen, welches Programm welche Dateien schreibt und liest. Das schaust du dir einmal mit Windows und 1x mit MAC an. Vielleicht ist da ein Unterschied.

 

[Sithys]

Also wenn ich netstat auf 3389 UDP mache sehe ich nur, dass der Server darauf zwar lauscht aber ich sehe keine aktiven Verbindungen. Die müssten ja da sein, wenn die User angemeldet sind, oder hab ich da gerade einen Denkfehler?

Ergänzung (1. September 2025)

Vielleicht werden irgendwo Temp Dateien hin geschrieben. Alte Programme haben ihre Temps oder Einstellungen gerne in den eigenen Programmordner geschrieben. Und vielleicht macht da der MAC was anders.

Du könntest vielleicht ProcMon verwenden, also den Process Monitor von Microsoft. Da kann man ganz gut sehen, welches Programm welche Dateien schreibt und liest. Das schaust du dir einmal mit Windows und 1x mit MAC an. Vielleicht ist da ein Unterschied.

ich habs mit handle schon analysiert, grundsätzlich hat das Programm ja seinen Temp-Ordner in welchen die Mac-Verbindung was schreiben kann aber die Windows-Verbindung nicht (identischer User). Die spannende Frage ist ja: Warum kann die Mac-Connection da schreiben und die Windows-Connection nicht. Grundsätzlich ist genau das das Problem, dass die Dateien nicht geschrieben werden können.

 

[VDC]

Die müssten ja da sein, wenn die User angemeldet sind, oder hab ich da gerade einen Denkfehler?

Kann man in einer RDP-Verbindung von einem Windowsgast sehen und ist wie gesagt im Standard einfach an.

Die Frage hört sich bescheurt an, aber m.mustermann ist kein lokal vorhandener User auf dem TS? nicht dass da noch Reste aus irgendwelchen Tests liegen.

Ergänzung (1. September 2025)

Grundsätzlich ist genau das das Problem, dass die Dateien nicht geschrieben werden können.

Einmal Rechte mit der Gießkanne auf den Ordner?

 

[redjack1000]

Welchen würdest du da zum Testen empfehlen?

Versuche es mal mit dem Client von Parallels.

CU
redjack

 

[derlorenz]

Wird bei der fehlerhaften Verbindung ggf. Irgendwas mit durchgereicht (lokale Ressourcen), was da nicht hingehört?

 

[Sithys]

Kann man in einer RDP-Verbindung von einem Windowsgast sehen und ist wie gesagt im Standard einfach an.

Die Frage hört sich bescheurt an, aber m.mustermann ist kein lokal vorhandener User auf dem TS? nicht dass da noch Reste aus irgendwelchen Tests liegen.

Anhang anzeigen 1652936

Ergänzung (1. September 2025)

Einmal Rechte mit der Gießkanne auf den Ordner?

Hm, ja, UDP ist an, das sagt die Verbindungsanzeige auf jeden Fall.

Nein, das sind alles Domänen-User und das Problem ist für ALLE Domänen-User reproduzierbar.

Gießkanne hab ich rausgeholt... das Ding ist sowas von offen, da darf mittlerweile jeder Hans und Franz alles, hat leider nicht geholfen. Es geht selbst als Domänen-Admin über RDP von Windows aus nicht

Ergänzung (1. September 2025)

Wird bei der fehlerhaften Verbindung ggf. Irgendwas mit durchgereicht (lokale Ressourcen), was da nicht hingehört?

Alles deaktiviert, wird gar nichts mit durchgereicht. Drucker etc, alles lokal installiert, Terminalserver per Site-to-Site VPN mit dem Standort des Kunden dauerhaft verbunden (mikrotik/wireguard), ist davon aber unabhängig, ging schon ohne die site-to-site verbindung nicht.

Ergänzung (1. September 2025)

Versuche es mal mit dem Client von Parallels.

CU
redjack

Habe ich versucht, aber ich glaube der faked nur eine eigene Verbindung oder? Wenn ich mich über den Client mit dem RDP verbinde habe ich oben die gleiche Kontrollleiste wie bei mstsc und auch den gleichen Fehler wieder bei den Usern, macht also keinen Unterschied.

 

[zeaK]

Mal mit dem Procmon geschaut auf was der alles zugreifen möchte beim starten der .exe?

 

[VDC]

https://learn.microsoft.com/en-us/p...ient/whats-new-windows?tabs=windows-msrdc-msi Sonst hier mal den aktuellen RDP Client laden und damit prüfen, die MAC kommen ja über die Windows App (ehemals Remote Desktop App) zum Server?

 

[Sithys]

@VDC Der kann das doch gar nicht, oder? Für Windows war mein Stand, dass die neue App nicht geht, da soll weiterhin MSTSC genutzt werden. Ja, die Mac-Clients kommen über die Windows App

 

[VDC]

Edith: Blödsinn von mir, das tickt anders als zuletzt, ich schaue mal eben ob ich den alten Client noch finde. Bzw mit einem sauberen RD-Gateway/Broker klappt das wahrscheinlich schon.

Es gibt ja nicht umsonst dort Windows Downloads und ich meine den Client, nicht die App.

 

[Sithys]

Hmm... ich stocher immer noch im Trüben irgendwie. Es muss irgendwas mit temp-pfaden oder dateien oder sowas zu tun haben glaube ich die auf mac nicht erzeugt werden oder sowas, aber so richtig eine Idee habe ich nicht.

 

[Sithys]

Freunde... ich hasse das ja immer, wenn man irgendwo was postet oder fragt und am Ende findet das hier in 2 Jahren jemand und keiner hat sich mehr gemeldet, wie man es gelöst hat.

Ich kann es selbst kaum glauben: Es funktioniert jetzt! Wie viel Stunden hab ich da reingepulvert... nun denn, die Lösung ist relativ simpel. Das Programm verwendet eine (wohl sehr alte) SAP ADS Datenbank. Für diese ADS-Datenbank existiert eine ads.ini im Programmverzeichnis und in diese ads.ini muss ganz oben:

[Settings]
mtier_local_connections=1

eingefügt werden. Damit wird der ads-db wohl signalisiert, dass die Möhre auf einem Terminal/Tenant-System läuft bzw. das lokale Verbindungen eben zulässig sind (über die DLL, nicht über TCP/IP). Ich habs ja selbst nicht geglaubt als ich die exe angeklickt und sich das Programm fehlerfrei geöffnet hat, unfassbar.

Wie bin ich drauf gekommen?
Ich habe nochmal mit procmon einmal eine mac und eine windows session gecaptured und exportiert als CSV und Claude (Opus) auf Unterschiede prüfen lassen (das waren ein paar 10.000 Einträge...). Allerdings schon gestern... nach 30 Minuten hab ich das dann abgebrochen und dicht gemacht. Jetzt wollte ich vorhin weitermachen und mach den alten Chat von Claude wieder auf und sehe in der letzten Nachricht die Claude geschrieben hat irgendwas von einem 5185 Error den Claude wohl als Differenz ausgemacht hat. Tjoa,... dann hab ich gegoogelt, ads 5185 und bin irgendwo gelandet wo dann stand, den Befehl einfügen und fertig.

 

[redjack1000]

Top Beschreibung, vielen Dank für die Rückmeldung.

Cu
redjack

 

[Skysnake]

Danke für das Update. Von so was lebt das Netz.

Warum aber ne AI damit beschäftigen? Hat das kein vernünftiges Format wo man die entsprechenden Spalten des Logs auswählt und dann ein Diff drüber jagt? Das sollte doch binnen Sekunden gemacht sein mir Befehlen nachschauen binnen Minuten.

So Logvergleiche mache ich öfters.

 

[Evil E-Lex]

Hat das kein vernünftiges Format wo man die entsprechenden Spalten des Logs auswählt und dann ein Diff drüber jagt?

CSV und XML stehen zur Auswahl. Spalten auswählen kannst du nicht. Wobei ich mir nicht sicher bin, ob der Export sich an den aktuell angezeigten Spalten orientiert. Du kannst zudem Filter definieren und dort auswählen, ob das Log mit oder ohne Filter exportiert werden soll.

Das wird vermutlich hier der Fehler gewesen sein. procmon nutzt man normalerweise so, dass man zunächst auf das zu überwachende Programm filtert "If process name is meinprogramm.exe then include". Alles andere lässt man weg. Dann bekommt man ein Log, das ein paar dutzend bis ein paar hundert Zeilen lang ist.