Client-Server Programme auf Terminalserver ausführen

[Harry Stahl]

Hi, ich bekomme hin und wieder die Frage, ob meine Programme, die z.T. als Client-Serverprogramm-Lösungen gestaltet sind, auch auf einem Terminalserver laufen.

Da ich keine Ahnung von Terminalservern habe, kann ich da i.d.R. nur ausweichend antworten ("sollte", "müssten Sie selber ausprobieren").

Daher hier meine Frage:

Eine Programmlösung, die aus einem Server-Programm und beliebig skalierbaren Clients besteht, und die Programme die über TCP-IP miteinander kommunizieren (jeder Client kann bei Bedarf einen anderen Port verwenden), gibt es da Dinge, die grundsätzlich Probleme erzeugen könnten?

Mein Server-Programm läuft auf dem Terminal-Server, ist schon klar. Ich gehe mal davon aus, dass auch die Client-Programme dann auch auf dem Terminalserver installiert werden. Aber werden die dort ausgeführt oder auf den Client-Geräten? Die Clients sind so programmiert, dass nur eine Instanz starten kann. Ist das ein Problem oder ist das - wenn sie auf dem Terminalserver ausgeführt werden - trotzdem möglich (weil der irgendwie die Programme in geschützten Bereichen auseinanderhält)?

Wäre für ein paar hilfreiche Anmerkungen dankbar...

Und: Könnte ich so eine Situation hier mit verschiedenen VM's nachstellen oder wird dafür bestimmte Hardware benötigt?

[mjustin]

Zitat:

Zitat von Harry Stahl (Beitrag 1406438)

Meins Server-Programm läuft auf dem Terminal-Server, ist schon klar.

Eigentlich sollte das eigene Server-Programm auf einem dafür bereitgestellten eigenen Server und nicht auf dem Terminal-Server installiert werden. Der Terminalserver soll nur die virtuellen Clients bereitstellen. In den virtuellen Clients läuft dann jeweils eine Instanz der Client-Applikation, die dann TCP/IP Verbindungen zum Server aufbauen. Port-Konflikte oder Probleme durch mehrfache Instanzen sind dann nicht zu erwarten, es sei denn, die Client öffnen selber Ports. Das geht nur, wenn alle Clients auf dem Terminalserver unterschiedliche Ports verwenden.

[Harry Stahl]

Danke für die Antwort. Was meinst Du mit die Clients öffnen selber Ports?

Hier ist es so angelegt, dass man die mit dem Programm einmal einstellt und dann verwendet.
Andere Ports nutzen die Programme dann nicht.

Als Beispiel mal der Einstellungs-Dialog Netzwerk für den Client anliegend.

[mkinzler]

Obwohl es Terminalserver heisst, laufen auf ihm die Clients. Der Server sollte auf dem (File-)Server installiert werden.
Alle Sessions uaf dem TS haben natürlich die selbe IP. Es kommt dann darauf an, ob Dein Programm das unterstützt. Die "Clients" müssen dann natürlich nicht nur anhand der IP-Adresse, sondern auch anhand des (Client-)Ports unterschieden werden.

Funktionieren mehrere Clients auf einem Rechner? Melde Dich mal mit 2 Benutzern an deinem lokalen Rechner an und Teste, ob es funktioniert.

[Schokohase]

Nicht obwohl, sondern weil es Terminalserver heißt laufen die Anwendungen auf diesem und es wird nur die Anzeige übertragen. Eben so, wie man das von ganz früher kannte, wo es für die Benutzer Terminals (ja, damals nur reiner Text) gab. Und ein Server stellt etwas zur Verfügung (z.B. Datenbanken, Dateien, Web) und hier stellt der eben Terminals zur Verfügung.

Bei dem Mutex gib es die Unterscheidung zwischen Session (local) und Machine (global). Ist der Prefix

Delphi-Quellcode:

Global\

dann kann in diesem Falle nur eine Instanz pro Maschine laufen, andernfalls eben pro Anmeldesession (und das passt dann auch für den Terminalserver).

Nutzt du von deiner Anwendung auch noch Verzeichnisse/Dateien lokal auf dem Rechner? Dann müsstest du das auch noch berücksictigen, dass ein Anwender auch mehrfach angemeldet sein könnte (das kann man aber auch abschalten, dann darf jeder Benutzer nur einmal angemeldet sein)

[Harry Stahl]

Ja, die Ausführung unter unterschiedlichen User-Accounts funktioniert auf demselben PC, erwartungsgemäß muss ich auf dem anderen Benutzer / Client die Port-Nummer ändern, aber dann gehts...

[Harry Stahl]

Zitat:

Zitat von Schokohase (Beitrag 1406443)

Nutzt du von deiner Anwendung auch noch Verzeichnisse/Dateien lokal auf dem Rechner? Dann müsstest du das auch noch berücksictigen, dass ein Anwender auch mehrfach angemeldet sein könnte (das kann man aber auch abschalten, dann darf jeder Benutzer nur einmal angemeldet sein)

Ja, aber die sind alle auf den jeweiligen Benutzername bezogen erstellt, sollte also kein Problem sein.

[Harry Stahl]

Zitat:

Zitat von Schokohase (Beitrag 1406443)

Bei dem Mutex gib es die Unterscheidung zwischen Session (local) und Machine (global). Ist der Prefix

Delphi-Quellcode:

Global\

dann kann in diesem Falle nur eine Instanz pro Maschine laufen, andernfalls eben pro Anmeldesession (und das passt dann auch für den Terminalserver).

Also falls Du die Prüfung über doppelt gestartete Anwendungen über Erzeugung eines Mutexes meinst, das habe ich bei den Client-Programmen anders gelöst, als bei Programmen, die nur solo laufen, irgendwelche Mutex-Stopps sollten daher nicht entstehen.

[mjustin]

Zitat:

Zitat von Harry Stahl (Beitrag 1406441)

Danke für die Antwort. Was meinst Du mit die Clients öffnen selber Ports?

Hier ist es so angelegt, dass man die mit dem Programm einmal einstellt und dann verwendet.
Andere Ports nutzen die Programme dann nicht.

Als Beispiel mal der Einstellungs-Dialog Netzwerk für den Client anliegend.

Das sieht im Screenshot so aus als ob der Client auch (zum Empfangen von Daten) einen eigenen Port öffnen, d.h. der Client agiert auch als Server. Daher muss jeder Client zum Empfangen einen noch freien Port öffnen. Auf einem Terminalserver müssen daher alle Clients jeweils ihren eigenen Port zum Empfangen öffnen.

Was ich allerdings nicht verstehe: sendet der Server Daten an den Client über diesen zweiten Port? Falls ja, warum verwendet der Server nicht den Port mit dem sich der Client zum Senden verbindet, auch in die Gegenrichtung? Bei TCP/IP sind Ports bidirektional, der Server kann Daten über den gleichen Port auch an den Client senden, parallel zum Empfangen von Daten des Clients. (Genau wie man mit einer Telefonleitung Sprechen und Hören kann)

[TigerLilly]

RDP ist da auch ein Stichwort, wenn du das testen möchtest.

Mutex ist schon erwähnt worden. Das Schreiben/Lesen aus der Registry ist am Terminalserver in anderen Zweigen untergebracht, wenn ich das richtig im Kopf habe, als auf einem normalen Rechner.

Drucken + lokale Laufwerke bzw alle lokalen Ressourcen muss man sich auch ansehen, weil "lokal" am TS ja was anderes bedeutet.

Wenn es mehrere TS gibt (Loadbalancing) sind lokale Daten ein Problem, weil die je nach TS dann auf einem anderen Rechner liegen können.

[Harry Stahl]

Zitat:

Zitat von mjustin (Beitrag 1406447)

Was ich allerdings nicht verstehe: sendet der Server Daten an den Client über diesen zweiten Port? Falls ja, warum verwendet der Server nicht den Port mit dem sich der Client zum Senden verbindet, auch in die Gegenrichtung? Bei TCP/IP sind Ports bidirektional, der Server kann Daten über den gleichen Port auch an den Client senden, parallel zum Empfangen von Daten des Clients. (Genau wie man mit einer Telefonleitung Sprechen und Hören kann)

Aber der Server kann doch nicht auf demselben Port senden und empfangen zur gleichen Zeit, oder? Geht doch nur: Client sendet auf Leitung und Server sendet (u.U.) etwas zurück. Der Server managt den Zugriff mehrerer Clients auf einen Datenbestand und verwaltet Locks auf bearbeitete Daten oder sendet auch andere allgemeine Daten, die für die Clients relevant sind. Daher habe ich hier letztlich zwei Datenverbindungen. Der Client kann allerdings auch nur mit einer Verbindung arbeiten, wenn z.B. der Zugriff auf einen Server im Internet stattfindet und der Client in einem Netzwerk hinter einem Router ohne Port-Weiterleitung zurecht kommen muss (sog. Polling Mode).

[Hobbycoder]

Ein tatsächlicher Test auf einem richtigen Terminalserver ist zwingend Notwendig, da die lokalen Rechte der User sich etwas anders Darstellen, als das bei "richtigen" Clients der Fall ist.

Zweitens sollten die DB's, Server-Anwendungen, usw. niemals auf dem Terminalserver selbst laufen. Grundsätzlich sollte man bei nämlich bei Einsatz von Terminalserverlösungen nicht nur einen Terminalserver betreiben, sondern um die Verfügbarkeit zu sichern einen Cluster aus mehreren Terminalserver bilden (Ansonsten steht bei Terminalserver-Ausfall nämlich alles). Und oft werden diese auch mit Netzwerklastenausgleich installiert, so dass der User gar nicht bestimmen kann, auf welchem er landet.

Um aber auf der Entwicklungsmaschine erst mal grundsätzlich Fehler (wie zum Beispiel die Ports) zu testen, reicht es aus auf dieser Maschine einfach mehrere Instanzen gleichzeitig (möglicherweise auch mit einer weiteren Sitzung eines anderen lokalen User) zu starten. Wenn das Problemlos möglich ist, dann wird das auch auf einem Terminalserver funktionieren.

[Harry Stahl]

Zitat:

Zitat von Hobbycoder (Beitrag 1406452)

Um aber auf der Entwicklungsmaschine erst mal grundsätzlich Fehler (wie zum Beispiel die Ports) zu testen, reicht es aus auf dieser Maschine einfach mehrere Instanzen gleichzeitig (möglicherweise auch mit einer weiteren Sitzung eines anderen lokalen User) zu starten. Wenn das Problemlos möglich ist, dann wird das auch auf einem Terminalserver funktionieren.

Also wie gesagt, mehrere Instanzen gleichzeitig laufen nicht unter dem gleichen User. Aber das ist doch auch nicht erforderlich, oder?
Ich würde doch mal annehmen, dass jeder Client eine eigene User-Zuordnung hat, oder?

[Hobbycoder]

Zitat:

Zitat von Harry Stahl (Beitrag 1406455)

Also wie gesagt, mehrere Instanzen gleichzeitig laufen nicht unter dem gleichen User. Aber das ist doch auch nicht erforderlich, oder?
Ich würde doch mal annehmen, dass jeder Client eine eigene User-Zuordnung hat, oder?

Das ist Korrekt. Ist genauso, wie bei Win 7/8/10. Nur das ein lokaler User eines Win7/8/10 auf seiner Maschine doch noch etwas mehr Rechte hat, als ein Domänen-User auf einen Terminal-Server. Natürlich kann er auf sein Profil genauso zugreifen wie auf jedem anderen Windows-Rechner auch. Außer es ist durch den Domänen-Admin in irgendeiner Form eingeschränkt. Und das kann auf einem Terminalserver schon mal der Fall sein.
Während ein User eines normalen Client lediglich seine Maschine kaputtspielt, würde das im Falle eines Terminalservers schon etwas größeren Schaden anrichten. Deswegen schränken viele Admins das stark ein (gerne wird z.B. C: aus dem Explorer komplett ausgeblendet). Deswegen unbedingt auch mal auf einem Terminalserver (vielleicht sogar auf dem Zielsystem, wenn das geht) testen.

[mjustin]

Zitat:

Zitat von Harry Stahl (Beitrag 1406449)

Zitat:

Zitat von mjustin (Beitrag 1406447)

Was ich allerdings nicht verstehe: sendet der Server Daten an den Client über diesen zweiten Port? Falls ja, warum verwendet der Server nicht den Port mit dem sich der Client zum Senden verbindet, auch in die Gegenrichtung? Bei TCP/IP sind Ports bidirektional, der Server kann Daten über den gleichen Port auch an den Client senden, parallel zum Empfangen von Daten des Clients. (Genau wie man mit einer Telefonleitung Sprechen und Hören kann)

Aber der Server kann doch nicht auf demselben Port senden und empfangen zur gleichen Zeit, oder?

Ein Port ist keine Verbindung oder ein "Kanal" über den Daten gesendet werden, das ist ein Mißverständnis. Die Portnummer ist nur ein Bestandteile der Verbindungsidentifikation.

Die Verbindung ist definiert über vier Bestandteile, die IP-Adresse von Server und Client und die Portnummern beider Seiten. Der Serverport ist dabei konstant und muss dem Client bekannt sein wie die IP Adresse, der Client-Port wird automatisch vom Betriebssystem zugewiesen.

Beispiel: Server "10.2.12.8:80" <-> Client "10.2.12.13:65535" identifiziert eine Verbindung zwischen den Netzwerkadaptern mit IP 10.2.12.8 und 10.2.12.13 wobei der Server den Port 80 (HTTP) verwendet und der Client den vom Betriebssystem dynamisch zugewiesenen Port 65535. (Link)

Man muss dem Client also für das das Empfangen von Daten keinen weiteren Port zuweisen. Dies ist eine grundlegende Eigenschaft von TCP/IP: sobald die Verbindung hergestellt ist, sind beide Seiten (Peers) völlig gleichberechtigt. Die Verbindung hat zwei Streams, einen aus dem gelesen werden kann und einem in den geschrieben werden kann. Je nach Client-Bibliothek, z.B. Indy, geht das problemlos auch aus zwei verschiedenen Threads - der Lesethreads liest kontinuierlich aus dem Input-Stream, der Schreibthread schreibt falls neue Daten vorhanden sind in den Output Stream.

(p.s. ich hoffe ich habe den Konfigurationsbildschirm nicht falsch interpretiert: ich nahm an, dass der Port zum Empfangen für einen TCP Server, der im Client läuft, benutzt wird.)

[Harry Stahl]

Zitat:

Zitat von mjustin (Beitrag 1406458)

Man muss dem Client also für das das Empfangen von Daten keinen weiteren Port zuweisen. Dies ist eine grundlegende Eigenschaft von TCP/IP: sobald die Verbindung hergestellt ist, sind beide Seiten (Peers) völlig gleichberechtigt. Die Verbindung hat zwei Streams, einen aus dem gelesen werden kann und einem in den geschrieben werden kann. Je nach Client-Bibliothek, z.B. Indy, geht das problemlos auch aus zwei verschiedenen Threads - der Lesethreads liest kontinuierlich aus dem Input-Stream, der Schreibthread schreibt falls neue Daten vorhanden sind in den Output Stream.

(p.s. ich hoffe ich habe den Konfigurationsbildschirm nicht falsch interpretiert: ich nahm an, dass der Port zum Empfangen für einen TCP Server, der im Client läuft, benutzt wird.)

Ja, das hast Du richtig interpretiert.

D.h. ich kann sowohl für meine TidTCPClient-Komponente als auch für die TidTCPServer-Komponente (die also beide in einem Programm, auf einer Form liegen) denselben Port verwenden?

Auf den Server im Client-Programm kann ich ja nicht verzichten, da der Client zwar direkt nach dem Senden empfangen kann, aber eben kein Ereignisevent für vom Server (irgendwann) gesendete Daten hat.

Ergänzung: Das Serverprogramm sendet dann in Konsequenz seine Direkt-Antworten von Clientanfragen an die Clientcomponente und Eigen-getriggerte Informationen an die Server-Componente im Clientprogramm, ebenfalls mit der gleichen Port-Nr.

Das würde das Handling zwar erleichtern, aber es gibt ja Notwendigkeiten, evtl. einen anderen Port für den Client zum Empfangen wählen zu müssen (wie hier eben mehrere Instanzen auf unterschiedlichen User-Accounts oder eben Serverprogramm und Clientprogramm auf einer Maschine).

[mensch72]

Die Frage ist, laufen in einem ganz normalen Win-Installation (völlig egal ob WinDesktop oder WinServer) das Server-Programm und mehrere zeitgleich gestartete identische Client-Programme?

Wenn ja, alles super, dann passenen sowohl Netzwerk als auch "TempFile" Handling.
Wenn es Netzwerk/Portprobleme gibt, dann diese zuerst lösen.
Wenn alles was mit Netzwerk zu tun hat funktioniert, aber es Probleme mit den z.B. gelockten "globalen" Einstellungsdateien gibt, sollte man das so angehen, das es auch in einer solchen multiplen lokalen Installation läuft.

Ein Termnalserver trennt zwar die UserKontexte und Tempverzeichnisse virtuell "bestmöglich", aber es hängt vom Programmierer ab, ob man nicht doch irgendwo/irgendwie "gemeinsame" lokale Dateien "exclusiv" öffnet... gut bewährt hat sich, das ein Client-Programm beim Start sinc eine selbst UUID erzeugt und die als Präfix/Unterverzeichnis für alles nutzt, was im weiterem Programmablauf temporär/lokal erzeugt und bearbeitet wird.


So gerüstet und getestet, kann man sich dann durchaus ein 99% "ja Terminalserverfähig zutrauen":)

[Schokohase]

Ja, so ist das richtig. Immer schön per Salamitaktik die Information nur scheibchenweise preisgeben.

Dann wird man so in ca. 75+ Beiträgen auch evtl. zu einem Ende kommen. Gut, das hätte man auch in 15 schaffen können - wenn man alle relevanten Informationen auf den Tisch legt - aber wer will das denn schon.

Also um bewerten zu können, ob und welche Probleme es da gibt, zeig doch eine vereinfachte Version der Anwendung und dann können wir dir helfen, schnell, kompetent ohne Geschwafel, Interpretiere und Herumgestochere.

[Harry Stahl]

Zitat:

Zitat von Schokohase (Beitrag 1406461)

Ja, so ist das richtig. Immer schön per Salamitaktik die Information nur scheibchenweise preisgeben.

Dann wird man so in ca. 75+ Beiträgen auch evtl. zu einem Ende kommen. Gut, das hätte man auch in 15 schaffen können - wenn man alle relevanten Informationen auf den Tisch legt - aber wer will das denn schon.

Also um bewerten zu können, ob und welche Probleme es da gibt, zeig doch eine vereinfachte Version der Anwendung und dann können wir dir helfen, schnell, kompetent ohne Geschwafel, Interpretiere und Herumgestochere.

Ich habe ja (im Moment) gar kein Problem, mir ging es nur um die generelle Funktionsweise des Terminal-Servers um allgemein einschätzen zu können, ob meine Programme darauf laufen würden. Im Rahmen des gezeigten Einstellungsdialogs kam dann über eine Anmerkung zum 2. verwendeten Port eine Diskussion auf, bei der man (ich) etwas zusätzlich über Ports gelernt habe.

Also alles OK, mir wurde mit den Ausführungen zum Terminalserver schon ausreichend geholfen, wir können die Diskussion hier auch beenden.

[Pfaffe]

Je nach verwendetem Datenbanksystem sollte man die Lizenzrechte beachten. Z.B. Bei der guten alten ADS (Advantage Database Server) :cry: ist es nicht erlaubt die lokal Variante kostenfrei auf einem Terminalsystem laufen zu lassen.

[taveuni]

Zitat:

Zitat von Harry Stahl (Beitrag 1406459)

D.h. ich kann sowohl für meine TidTCPClient-Komponente als auch für die TidTCPServer-Komponente (die also beide in einem Programm, auf einer Form liegen) denselben Port verwenden?

Auf den Server im Client-Programm kann ich ja nicht verzichten, da der Client zwar direkt nach dem Senden empfangen kann, aber eben kein Ereignisevent für vom Server (irgendwann) gesendete Daten hat.

Ergänzung: Das Serverprogramm sendet dann in Konsequenz seine Direkt-Antworten von Clientanfragen an die Clientcomponente und Eigen-getriggerte Informationen an die Server-Componente im Clientprogramm, ebenfalls mit der gleichen Port-Nr.

Das würde das Handling zwar erleichtern, aber es gibt ja Notwendigkeiten, evtl. einen anderen Port für den Client zum Empfangen wählen zu müssen (wie hier eben mehrere Instanzen auf unterschiedlichen User-Accounts oder eben Serverprogramm und Clientprogramm auf einer Maschine).

Das verstehe ich nicht. Ein Client braucht definitiv nur (TCP-,HTTP- oder was auch immer) Client zu sein. Der Server kann natürlich auch gezielt jeden einzelnen Client über diesen Socket (welcher notabene der Client geöffnet hat) bei Ereignissen individuell informieren. Und so ist auch der Terminalserver Betrieb unbedenklich.

[himitsu]

Zitat:

Nicht obwohl, sondern weil es Terminalserver heißt laufen die Anwendungen ...

Jupp, TerminalServer kann man es sich grundsätzlich ganz einfach wie "MultiUser auf einem PC" vorstellen, kombiniert mit TeamViewer/Skype/..., welches den Benutzer wo anderes anzeigt.


Aufpassen muß man bei Grafikausgaben
* nicht jeder TerminalServer hat eine gute Grafikkarte und er stellt diese auch nicht unbedingt den TerminalUsern zur Verfügung
* und viele/häufige Updates/Zeichenoperationen können den TerminalServer (für den jeweiligen User) lahm legen, also so auslasten, dass er kaum noch was machen kann (ein gutes Beispiel sind die DelphiIDE und FinalBuilder, die das oft genug schaffen)

Und natürlich bei globalen Ressourcen, ala Ports, Mutexen usw., falls dein Programm nicht darauf ausgelegt ist, dass es mehrmals gleichzeitig auf dem selben System laufen soll.
(es gibt auch Programma ala MS Office, welche bei billigen User-Lizenzen den Programmstart absichtlich im TerminalServer sperren)

[Hobbycoder]

Zitat:

Zitat von himitsu (Beitrag 1406493)

Aufpassen muß man bei Grafikausgaben
* nicht jeder TerminalServer hat eine gute Grafikkarte und er stellt diese auch nicht unbedingt den TerminalUsern zur Verfügung
* und viele/häufige Updates/Zeichenoperationen können den TerminalServer (für den jeweiligen User) lahm legen, also so auslasten, dass er kaum noch was machen kann (ein gutes Beispiel sind die DelphiIDE und FinalBuilder, die das oft genug schaffen)

Das ist so nicht ganz richtig. Die im physikalischen Terminalserver eingebaute Grafikkarte spielt für die Anzeige der Terminalserversitzung eine geringe Rolle. Selbst senn diese z.B. nur 1280x1080 schafft, kann der Client auch z.B. 4k ohne Probleme. Allerdings kann es zu Problemen kommen, wenn die Software explizit und zwingen auf die Hardwarebeschleunigung der Grafikkarte zugreifen will. Ich hatte schon CAD-Anwendungen wo ich für den Betrieb im Terminalserver bestimmte Grafikroutinen von Hardware auf Software umstellen musste (Allerdings sind CAD-Anwendungen auch eher schlecht für den Einsatz auf Terminalservern geeignet).

Native Controls werden über RDP sehr schnell übertragen, das das Zeichnen diese der RDP-Client selbst übernimmt und sie sich somit recht gut komprimieren lassen (im Gegensatz zum Beispiel zu VNC, wo selbst manch ein normales Fenster scheibchenweise beim Verschieben neu aufgebaut wird). Anders sieht das den Controls aus, die z.B. auf den Canvas zeichnen. Diese werden als Bitmap übertragen, was eine Komprimierung schlechter werden lässt. Idealerweise verzichtet man entweder ganz auf diese oder man zeichnet diese komplett im Hintergrund und gibt wie erst bei kompletter Fertigstellung aus. Letzteres wirkt sich aber genauso negativ bei dem Verschieben aus. Zwar versucht der RDP-Client dieses durch Zwischenspeichern vom Bitmaps zu verbinden, was aber nur klappt, wenn die gleiche Bitmap (wobei das auch eine Teilbitmap sein kann), an der gleichen Position unverändert neu gezeichnet wird.

[Real Thunder]

Nun kommt von mir auch noch mal Senf dazu:

1. Es kann pro Netzwerkadapter nur ein mal ein Port abgehört werden (Server). Also Clients können häufiger gestartet werden. Serverkompinenten aber nicht (die beschweren sich dann dass der Port schon belegt ist)

2. Häufig definiert sich die Terminalserverfähigkeit bei Anwendungen an der Registry (HKLM bzw HKCU) und den Pfaden (%programdata% / %appdata%)
Wenn mehrere Benutzer eine Software ausführen sollte die Konfiguration etc. in eigenem Benutzerverzeichnis (%appdata% liegen und nicht irgendwo Zentral (%programdata) abgelegt werden. Sonst kann es dazu führen das 2 Instanzen mal auf die gleiche Datei schrieben wollen und zack... knallt es.
ähnlich bei der Registry wenn deine Software dorrt brav ich HKCU Baum schreibt sollte es dort keine Probleme geben.

Bei der Installation oder erstkonfiguration der Software wäre es noch anzuraten sich als admin die console zu öffnen und

Code:

Change user /install

aufzurufen, und nach Fertigstellung

Code:

Change user /execute

Wenn Weiter keine Hardware direkt angesprochen wird (ausgenommen Drucker) dann sollte der Terminalserver Fähigkeit nichts im Wege stehen.