24.1.1 TM Update - Kartenterminals anmelden [GELÖST]

[Docker]

Das Update hat geklappt (Server + 4 Stationen).
Ist jmd der Grund bekannt, warum beim ersten Start nach einem Update die Kartenterminals/SMC-B erneut in TM registriert werden müssen? Das ist lästig, weil sonst alle Update-Arbeiten remote erledigt werden und die Kartenterminals vor Ort im Fehlermodus bleiben.
Ansonsten sind Remote-Updates enorm entlastend, erst recht, wenn Updates so spät kommen .

[FortiSecond]

@Docker
Wie ist das gemeint mit der Registrierung in TM?
Die KT kommen per Infomodell.

Was mir spontan einfällt:
Wie läuft die Remote-Installation? Direkt auf die Station per Remote-Tool (TeamViewer, Splashtop, MeshCentral etc.)?
Oder per VPN und RDP bzw. Verbindung zum Server und von dort RDP?

Bei RDP mit der mstsc.exe gibt es das Problem, dass IMMER der Client-PC-Name übermittelt wird. D.h. das TM auf der Station läuft nicht mit dem lokalen PC-Namen. So bekommt es auch nur das KT, was im Infomodell für den Remote-Rechner hinterlegt ist - falls eines hinterlegt ist.
Wenn also PC-ANMELDUNG per RDP vom SERVER16 per RDP gewartet wird, hat das TM (in dieser Sitzung bis zum Abmelden der Sitzung) den Stationsnamen SERVER16 und somit dessen Druckerzuordnung, Kartenterminal, Einstellungen usw.
Und falls man per VPN+RDP auf den Server geht und dann per RDP auf den Client, dann hat man das TM mit "LOKALERPCNAME" gestartet. Argh!

Alternative:
Direktzugriff auf Zielgerät mit einem Nicht-RDP-Client. Und sei es VNC.
ODER aber (Windows) den alten 2X-RDP-Client installieren und nutzen und dort jeweils den Stationsnamen in der RDP-Verbindung angeben. Damit trickst man das alles aus.
Mit Linux per RDP fernwarten, ist einfacher: Remmina und FreeRDP können den Clientnamen ebenfalls abweichend einstellen.

[Docker]

Super, die Infos, danke!
Bei uns ist es VPN (Wireguard) und RDP. Das erklärt es gut.
Ich werde die Alternativen testen.

Guten Rutsch an Alle in diesem hilfreichen Forum, auf ein Überleben nach TM .

[Landarzt21]

Ich hatte es in einem anderen Beitrag schonmal erwähnt - evtl. Rust Desk mal anschauen, als lokale Installation natürlich. Habe das im Einsatz und bin recht zufrieden. Schneller als VNC, nur der erste Bildaufbau dauert etwas...

[FortiSecond]

Super, die Infos, danke!
Bei uns ist es VPN (Wireguard) und RDP. Das erklärt es gut.
Ich werde die Alternativen testen.

Guten Rutsch an Alle in diesem hilfreichen Forum, auf ein Überleben nach TM .

Ja, die Gemeinschaft hier ist einfach klasse.

Eben noch eingefallen: Im Prinzip ist es für die reinen Updates nicht erforderlich, sich um die Stationsnamen zu scheren. Also kein Problem mit RDP und Update. Denn wenn die Station nach dem Remote-Update wieder lokal ("normal") gestartet wird, arbeitet sie wie vorher mit dem eigenen Hostnamen, bekommt die richtigen Terminals und Drucker. Wichtig: Am Ende möglichst von der Sitzung abmelden, damit die nächste Anmeldung 100% lokal läuft und TM den richtigen Stationsnamen hat. -> Nicht mit offenem TM trennen. Sonst wird die laufende Sitzung mit falschem Stationsnamen später weitergeführt.

Bei RDP-Zugriff einfach die falschen Drucker und Kartenleser nicht weiter beachten. Und nichts verstellen. Denn das meiste, was verstellt wird, gilt dann für den PC, mit dem man zugreift. Wenn man also vom Server aus per RDP auf einen Client geht und einen Drucker einstellen will, dann ist diese Einstellung hinterher (nur) auf dem Server verstellt. Ärgerlich, wenn man Drucker auswählt, die der Server nicht kennt.

Wenn man damit leben kann, dann einfach weitermachen wie bisher.

[Docker]

Bei den RDP Sitzungen sind Drucker-Umleitungen abgeschaltet. Das Problem haben wir also nicht.
Und ja, man kann alles per RDP machen, muss dann nach dem Update den ersten Programmstart aber lokal durchführen, um den Kartenleser Fehler zu vermeiden.
Danke und guten Rutsch!

[FortiSecond]

Bei den RDP Sitzungen sind Drucker-Umleitungen abgeschaltet. Das Problem haben wir also nicht.

Das hat nichts mit Umleitungen zu tun. Die würde TM erst einmal ignorieren.

STATION 1 hat z.B. A5 rosa auf "Brother Anmeldung Fach 2".
STATION 2 hat A5 rosa auf "Brother Sprechzimmer Fach 3".
Wenn Station 2 per RDP auf die Station 1 geht und TM aufruft, wird man in den STRG+E bei einer Überweisung den Brother Sprechzimmer finden. Stellt man dies nun um, weil man sich an Station 1 wähnt und korrigieren möchte, dann ändert man in Wirklichkeit die Druckereinstellung von Station 2. Die hat danach lokal das Problem, den Drucker gar nicht zu kennen.

Gleiches gilt für Kartenleser, die via Infomodell zugeordnet werden. In der o.g. RDP-Sitzung wird man auf Station 1 den Kartenleser ansprechen, der für Station 2 eingerichtet ist.

Problem: Nicht alles geht über die Datenbank. Konnektor ja/nein läuft über die local.ini des PC, auf dem TM tatsächlich läuft und gilt für alle User/Hostnamen. Wenn z.B. Station 2 Konnektorzugriff (Grundeinstellungen / local.ini!) und Kartenleser (Infomodell) hat, aber die zugreifende Station 1 keinen Konnektorzugriff, dann treffen "Station mit Konnektor verbinden" (local.ini der Station 1) auf fehlenden Eintrag im Infomodell (für den Stationsnamen STATION 2, der ja in der Session gilt). Dann gibt´s eine Fehlermeldung aus dem 4.000er-Bereich. 4015 oder so.