Terminalserver

[nmndoc]

Hallo,

ist T2Med denn Terminalserver-fähig? Verwendet das Jemand?
Habe mich beim Betrachten div. Screenshots gefragt, ob die vielen bunten Bildchen, Farbverläufe etc. das Ganze im TS-Betrieb nicht verlangsamen...?

[McLeod]

Geht bescheiden bis gar nicht. Siehe:
viewtopic.php?f=70&t=5662&p=34075&hilit=F%C3%BCr+WAN+Betrieb+%C3%BCber+RDP+unbrauchbar.#p34075
Und außerdem braucht sowas auch kein Mensch (sagt zumindest der T2med-Propagandaminister).

[nmndoc]

Geht bescheiden bis gar nicht. Siehe:
viewtopic.php?f=70&t=5662&p=34075&hilit=F%C3%BCr+WAN+Betrieb+%C3%BCber+RDP+unbrauchbar.#p34075

danke! Eigentlich sollte es hier ein "Skin" für TS-Betrieb geheb - nicht so schön, weniger Bilder/mehr Text aber dafür schnell (und gut komprimierbar).

Und außerdem braucht sowas auch kein Mensch (sagt zumindest der T2med-Propagandaminister).

... wir eigentlich schon
Es sei denn, das direkte (via VPN) Arbeiten Client/Server wäre schnell möglich / wenig Bandbreite. Aber das kann ich mir kaum vorstellen (ggf. testen).
Alternativ wäre ja auch eine Synchronisation zw. Standorten denkbar, ist aber m.E. bisher nicht vorhanden. (pro: Arbeiten bei Ausfall einer/mehrerer Leitungen; con: Schätze ich programmiertechnisch als mind. anspruchsvoll ein).

[McLeod]

Eigentlich sollte es hier ein "Skin" für TS-Betrieb geheb - nicht so schön, weniger Bilder/mehr Text aber dafür schnell (und gut komprimierbar).

Ich befürchte mit 'nem Skin alleine wäre es nicht getan. Für volle Performance müsste man wohl die Windows-spezifischen Zeichenbefehle benutzen. (WPF und Co.) Also quasi einen neuen Client basteln...

Es sei denn, das direkte (via VPN) Arbeiten Client/Server wäre schnell möglich / wenig Bandbreite. Aber das kann ich mir kaum vorstellen (ggf. testen).

Ich denke, daß direktes Arbeiten per VPN schon ziemlich gut möglich sein sollte, v.a. in Anbetracht der guten Performance des Internet-Testservers. Mit 'ner SQL-Datenbank als Backend kann man da schon recht effektiv sein. Gibt auch WaWi-Programme, die über WAN-VPN nur minimal langsamer arbeiten als im LAN.

Alternativ wäre ja auch eine Synchronisation zw. Standorten denkbar, ist aber m.E. bisher nicht vorhanden. (pro: Arbeiten bei Ausfall einer/mehrerer Leitungen; con: Schätze ich programmiertechnisch als mind. anspruchsvoll ein).

Nee, sowas gibt's nicht. Das ist nützliche Technik und somit "böse" oder zumindest "no priority". Bunt und hübsch und Wörterbücher und Chat und EIfön-Client sind viieeel wichtiger...
Wer diese Funktionalität möchte bzw. benötigt muß sich bei Indamed bzw. Doc Cirrus umsehen.

[DrHJvdB]

In der Tat arbeitet es sich per VPN ganz prima. Ich mach das von zu Hause aus mit meiner Praxis: es ist sauschnell. Und es stimmt: der DemoServer ist absolut vergleichbar.
Zu Hause bei mir per VPN ist es genauso schnell wie in meiner Praxis selbst. Es ist absolut so, als säße ich in der Praxis. Ich persönlich finde das viel echter und natürlicher als über die anderen genannten Möglichkeiten

Zur Synchronisation bei Leitungsausfall etc.:
Nun, es ist ja noch nicht aller Tage Abend. Ich kann mir das sehr gut vorstellen. Ich denke wir bauen das auch, auch wenn die Notwendigkeit angesichts der immer besser werdenden Internetgeschwindigkeit und Verfügbarkeit abnimmt.

Aber eins ist klar: die Ätzerei hört dann auch nicht auf. Dann schreibt jemand halt zu irgendeinem anderen Thema:

Nee, sowas gibt's nicht. Das ist nützliche Technik und somit "böse" oder zumindest "no priority". Bunt und hübsch und Wörterbücher, Chat, EIfön-Client und Sünchronisation sind viieeel wichtiger...

#McLeod: Glückwunsch, ist doch prima, dass Sie gleich zwei bessere Alternativen gefunden haben! Schlagen Sie doch dort zu, sollten Sie Ihr Altprogramm wechseln wollen.

[DrHJvdB]

Noch mal kurz zu VPN bzw. rein Internet:

Ich mache es so, dass ich auf meinem PC zu Hause T2med ständig zweimal laufen lasse (man könnte es auch 3 oder 4 mal separat starten):

das erste T2med ist ständig über VPN mit meiner Praxis verbunden. alles blitzschnell
das zweite T2med geht ganz normal übers Internet in die DemoPraxis: wie ich finde, ebenfalls außerordentlich flott, obwohl da ganz Deutschland und die Welt bedient wird

[nmndoc]

@DrHJvdB: danke für die Ausführungen.

Wenn es über VPN flüssig ist UND ebenso wenig Bandbreite (!) belegt könnte man TS evtl. auch weglassen, wobei hier ja ggf. noch weitere Anwendungen laufen, aber ok.
Welches Protokoll verwenden Sie denn zwischen Client und Server bzw. was für Daten werden da generell ausgetauscht? Greift der Client direkt auf die DB zu?

Zur Synchronisation bei Leitungsausfall etc.:
Nun, es ist ja noch nicht aller Tage Abend. Ich kann mir das sehr gut vorstellen. Ich denke wir bauen das auch, auch wenn die Notwendigkeit angesichts der immer besser werdenden Internetgeschwindigkeit und Verfügbarkeit abnimmt.

wie gesagt: es geht hier primär um die Verfügbarkeit im Sinne von Ausfallsicherheit. Und auch wenn "nur" 2x im Jahr halt kein Internet ist, oder 5x im Jahr für einige Std. - dann wäre das wohl keine Option, da dann einfach nicht arbeiten zu können. Abgesehen davon, dass bei einer Konstellation Haupt-BS und x NBS das Risiko, dass mind. ein Standort nicht arbeiten kann entspr. größer.

Nee, sowas gibt's nicht. Das ist nützliche Technik und somit "böse" oder zumindest "no priority". Bunt und hübsch und Wörterbücher, Chat, EIfön-Client und Sünchronisation sind viieeel wichtiger...

na, das würde ich nicht ganz so wörtlich bzw. persönlich nehmen

[DrHJvdB]

Ja, das würde ich einfach mal versuchen. Also nur VPN und dann auf Ihrem PC T2med im Original starten. Und dann einfach die IP Ihres T2med-Servers eingeben. Sie sehen dann ja ganz schnell, wie gut das funktioniert. Und ich behaupte mal, dass Ihnen das viel besser gefallen wird als der Terminalserver-Betrieb. Bin auf eine Rückmeldung sehr gespannt!

Zum Protokoll: das ist natürlich keinesfalls einsehbar. Die Daten, die vom T2med-Server an Ihr lokales T2med (=der Client) übertragen werden, sind ja hochverschlüsselt. Das muss ja sein, sonst könnte ja jemand anderes den Datentransfer mitlesen.
Viele Praxen sind ja mit Ihrem T2med-Server auch gar nicht per Draht, also Netzwerkleitung, verbunden, sondern die nutzen einfach Wlan. Und das Wlan bzw. der drahtlose Datenverkehr muss natürlich hochgradig geschützt sein.

Zu den Datenmengen: die sind nicht sonderlich hoch. Wenn bspw. eine neue Karteizeile angelegt wird, ist der Datenverkehr geradezu lächerlich gering. Schauen Sie sich hingegen ein Bilddokument eines Patienten an, geht das natürlich über die (drahtlose oder Kabel-) Leitung. Erfahrungsgemäß reicht VPN auch hier völlig aus.

Ich hatte bis vor paar Monaten in der Praxis nur DSL 6000 (in Wirklichkeit war das gemessen eher 3000) und habe vor paar Monaten bei meinem Provider upgegradet auf DSL 50000. Aber selbst mit dem DSL 6000 war es perfekt und mit dem jetzigen DSL 50000 merke ich zu Hause überhaupt nicht, dass ich nicht in der Praxis bin. Es ist echt genau so flott wie in der Praxis. Das ist schon ein tolles Gefühl: man sitzt zu Hause und es fühlt sich so an, als säße man in der Praxis.

[Forti]

Mal in der Kiste gebuddelt und einen seit 46 Monaten brachliegenden Thread hervorgeholt...

´n Abend,

wie sieht es "heute" aus mit Terminalbetrieb?

Zwei Aspekte machen in zwei wechselwilligen Praxen einen Terminalbetrieb zwingend erforderlich:

- Lokal nur "dumme" Clients mit Ausnahme der Arbeitsplätze, an denen GDT, mobiles KT, LZ** o.ä. laufen.
EIN zwingender Grund: Praktisch wartungsfrei, in Minuten ersetzbar, kein Risiko durch z.B. zugängliche USB-Ports usw.
Ansonsten ist natürlich auch eine wirtschaftliche Frage bei Umstellung auf Fat Clients (Strom, Lizenzen, Updates usw.)

- Im Home Office geht´s mit VPN+RDP im Zuge von "Use your own Device" für MFA und LE mit privat motivierter XL-Ausstattung (30"-Monitore usw.)
DER zwingende Grund für RDP: Benutzer jederzeit komplett aussperrbar, ohne dass Daten auf dem lokalen Client liegen bleiben (Anforderung Datenschutz und Erfahrungen)

Mir sind die Vorteile echter Clients und auch die Möglichkeiten der Verschlüsselung der Clients klar, und sicherlich ließe sich auch noch eine verschlüsselte VM für das HomeOffice mit "VPN-basierter Aktivierung der verschlüsselten VM" erzeugen, ja...
Ist aber nicht gewünscht. Es ließe sich sonst auch noch Zugriff per Teamviewer auf einen dedizierten Client (argh!) oder eine Windows-10-VM (teuer!) realisieren.

Also Butter bei die Steaks: Geht´s?

Grüßle
Forti

[nmndoc]

@Forti: will die Antwort nich vorweg nehmen - aber eher: nein. (oder vielleicht auch deutlich nein).

Mir widerstrebt auch irgendwie die Vorstellung, an einem remote Client die Anwendung direkt zu starten und alles über die Leitung zu schaufeln. Das kann doch nicht wirklich performanter sein? Und spätestens wenn man noch nebenher mit anderen Anwendungen arbeitet (Office, Arztbrief o.ä.) hätte RDP sicher Vorteile - außer was die Lizenzierung (zB o365) angeht.

[Lars.Huebner]

Hallo
T2med auf Terminalservern wird auch von einzelnen Kunden eingesetzt. Unsere Benutzeroberfläche benötigt allerdings Hardware-Beschleunigung, ansonsten geht das zu Lasten der CPU, was im Zweifelsfall wiederum zu Lasten der generellen Performance des gesamten Systems geht. Und ein Alleinstellungsmerkmal von T2med ist ja gerade die sehr hohe Geschwindigkeit. Deswegen sind Clients für T2med prinzipiell die bessere und einfachere Lösung. Es muss im Einzelfall mit dem lokalen T2med-Partner geprüft werden hinsichtlich Anzahl der Terminals und Ausstattung/Grafikleistung der Terminalserver.
Ohne so eine genaue Überprüfung würden wir bei einer pauschalen Anfrage nach TS eher "nein" sagen wollen, denn nichts ist ärgerlicher, wenn ein neues System womöglich nicht mindestens 100% schneller läuft, als bspw. das bisherige, alte System. Andererseits sollte man auch auf die Systemanforderungen schauen - die sind wirklich nicht arg hoch... - und damit läuft T2med wirklich sehr, sehr "hurtig"...
Viele Grüße aus Kiel,
T2med GmbH & Co. KG
Lars Hübner

[Macros]

Moin,

in meinen Augen gibt es noch ein paar andere Punkte die T2Med für mich nicht Terminalserver tauglich machen:
[list=]
[*] Installation erfolgt im Userverzeichnis
[*]Programmdateien sind also X mal auf dem Server vorhanden
[*]Anforderungen an Grafikkarte (hat Herr Hübner bereits genannt
[*]Gleichzeitige Schreiblast auf den Festplatten (java)
[/list]

Wenn ich in die Richtung denken müsste, würde ich wahrscheinlich eher VDI denken.

[nmndoc]

Moin,

in meinen Augen gibt es noch ein paar andere Punkte die T2Med für mich nicht Terminalserver tauglich machen:
[list=]
[*] Installation erfolgt im Userverzeichnis
[*]Programmdateien sind also X mal auf dem Server vorhanden
[*]Anforderungen an Grafikkarte (hat Herr Hübner bereits genannt
[*]Gleichzeitige Schreiblast auf den Festplatten (java)
[/list]

Wenn ich in die Richtung denken müsste, würde ich wahrscheinlich eher VDI denken.

naja, aber VDI nur um das PVS laufen zu lassen ... außerdem wäre da vermutl. die Frage, was letztlich effektiver ist betr zB Daten die remote übertragen werden müssen.
Ich denke bei MS hat sich in der Richtung ja auch Einiges getan gegenüber klassisch TS ... aber da fehlen mir im Moment noch die Erfahrungswerte