Terminaldienste oder Remotedesktop-Dienste wie Sie mittlerweile heißen, sind eigentlich Features, die dem Windows Server vorbehalten sind. Seit der Beta-Version von Service Pack 2 für Windows XP besteht aber die Möglichkeit ein Client-Windows zum Terminalserver aufzubohren.
War bei Windows XP noch der Griff auf Beta-DLLs vom Service Pack 2 oder eine Dritt-Herstellerlösung notwendig, so kann man bei Windows 7 mit einem Patch den Remotedesktop-Dienst von einer auf mehrere Sessions erweitern. Mit zusätzlichen Registry-Einstellungen besteht zudem die Möglichkeit RemoteApps zu nutzen.
Erfolgreich getestet habe ich Windows XP Professional x86, Windows 7 Enterprise x64 (Evaluierungsversion) und Windows 7 Ultimate x64.
Bei Windows 7 Professional funktioniert RemoteApp nicht.
Ausser bei Windows XP Professional habe ich keine 32-bit Versionen getestet.
Windows Vista und die 32-bit Versionen von Windows 7 sollten aber auch funktionieren, sofern es sich mindestens um die Edition “Business” (Vista) oder “Professional” (XP, 7) handelt.
Windows 7 zum Terminalserver patchen
Als Erstes muss in den Systemeigenschaften des Computers auf der Registerkarte Remote im Abschnitt Remotedesktop Verbindungen zugelassen werden. Ferner müssen die Benutzer, die Verbindungen herstellen dürfen ausgewählt bzw. zur Gruppe der Remotedesktopbenutzer hinzugefügt werden.
Als Zweites benötigt man das Tool Universal Termserv.dll Patch. Dieses Tool herunterladen und ausführen. Anschließend auf Patch klicken. Einmal Neu starten und schon können sich mehr als nur ein Benutzer an Windows via Remote Desktop anmelden. Somit ist es jetzt schon möglich, Desktops für Benutzer zur Verfügung zu stellen.
Hinweis: Bei diesem Vorgang wird die Systemdatei Termserv.dll im Ordner “C:\Windows\System32” verändert. Das Tool legt eine Kopie an. Allerdings sollte man zur Sicherheit noch eine zusätzliche Kopie anlegen. Ferner kann es vorkommen, das nach einem Windows Update das Tool erneut ausgeführt werden muss.
Persönliche Anmerkung: Das Systemdateien verändert werden, kennt man ja auch von anderen Tools und Software von Drittherstellern. Vorsichtshalber sollte man immer eine aktuelle Datensicherung haben, falls etwas schief geht. Das gilt nicht nur für solche “Spezialfälle” wie hier, sondern auch wegen Windows Updates. Man weiß ja nie.
Troubleshooting: Unter XP muss ggf. die Datei “xp.reg”, unter Vista/7 die Datei “vista.reg” per Doppelklick einmalig ausgeführt werden, um wichtige Registrierungseinstellungen zu setzen. Beide Dateien sind im Archiv des Patches zu finden.
RemoteApp konfigurieren
Wenn man keine vollständigen Desktops den Anwendern zur Verfügung stellen möchte, sondern nur einzelne Anwendungen, so bieten sich die Funktionalität von RemoteApp an. Hierbei wird lediglich ein einzelnes Programmfenster auf dem Client vom Terminalserver dargestellt. Die Anwendung verhält sich so, als würde sie lokal laufen.
Nachfolgend dient Notepad als Beispiel.
Um RemoteApp zu aktivieren muss folgende Änderung an der Registrierung vorgenommen werden:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList den Eintrag fDisabledAllowList auf den Wert 1 setzen.
Für jede RemoteApp muss ein Schlüssel mit dem Namen und Pfad angelegt werden:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\Notepad
Zeichenfolge namens “Name” und Wert “Notepad”.
Zeichenfolge namens “Path” und dem Wert “C:\Windows\System32\notepad.exe“.
Bei Windows XP Professional muss zusätzlich dieses Update installiert werden.
Bei Windows Vista muss zusätzlich dieses Update installiert werden. Ferner muss SP1 installiert sein.
In der *.rdp-Datei muss folgendes eingetragen werden:
remoteapplicationmode:i:1
remoteapplicationprogram:s:Notepad <- Hier den Namen der RemoteApp eingeben, wie in der Registrierung angeben.
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe
shell working directory:s:
Rechtliches
Für all’ diejenigen die jetzt gleich wieder Bemängeln, das die EULA von Microsoft die Verwendung von einem Client-Windows als Terminalserver nicht gestattet, sei gesagt, das ich das in der Vergangenheit bereits zwei mal mit der Microsoft Geschäftskunden-Betreuung abgeklärt habe. Die Sachlage dabei ist sehr einfach. Man benötigt folgende Lizenzen von Windows:
1x Windows in der Edition, die als Terminalserver verwendet wird und zusätzlich pro Benutzer eine weitere exakt gleiche Edition
Beispiel: Man hat einen Terminalserver mit fünf Benutzer so benötigt man eine Windows-Lizenz für den Terminalserver und zusätzlich fünf weitere identischen Windows-Lizenzen für die Benutzer. Macht in der Summe sechs identische Windows-Lizenzen.
Und wenn man mal darüber nachdenkt, sollte jedem auch klar sein, wenn Microsoft etwas dagegen hat, würden Sie gegen die entsprechenden Hersteller vorgehen.
Das Betriebssystem des Terminalserver-Clients ist im übrigen egal. Es spielt keine Rolle ob Windows, Linux, Mac OS etc. läuft.
Fazit
Natürlich kann ein solcher Terminalserver “Marke Eigenbau” funktional nicht mit einem echten Terminalserver mithalten, aber dennoch bieten solche Lösungen interessante und vor allem kostengünstige Möglichkeiten.
Paart man diese Lösung noch mit Stunnel, SSH-Tunnel oder einem VPN, so kann man einfach und sicher auch über das Internet eine Verbindung zum Terminalserver aufbauen.
Links
Herstellerliste
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Bedeutet das, dass bei einer RemoteDesktop-Verbindung der aktuell angemeldete Benutzer auf dem entfernten Rechner nicht mehr erst ausgeloggt wird? Das wäre in der Tat interessant. Wie sieht es mit der Legalität dieses Vorgehens (Patchen zum T-Server) aus?
gruss
Hallo Thomas,
ja, genau das heisst es. Was das rechtliche angeht, so ist das im Artikel beschrieben.
Gruß
Andy
Aha,
behebt also das einzige, was mir bei dem W7-RemoteDesktop-Tool lästig ist, bei ansonsten guter Funktionalität.
Das Rechtliche hatte ich überlesen. Ok, solange es im Rahmen des kleinen Heim-LANs bleibt, wird MS da sicher keine Faxen machen.
Besten Dank für den Tip. Dafür gibts eine Empfehlung im Google-Reader. 🙂
Gibt es nicht vielleicht doch irgend eine Möglichkeit, das mit W7 Professional zu machen?
Bei Windows 7 Professional geht ja lediglich RemoteApp nicht. Leider ist mir bislang keine Möglichkeit bekannt, wie man das nachrüsten könnte, außer man verwender jetzt Dritthersteller-Lösungen wie z.B. XPUnlimited.
Hy , welchen wert soll ichda auf 1 stellen
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList
?
bekomme immer die meldung : “Das folgende RemoteAp-Programm ist nicht inder Liste der autoriesierten Programme enthalten:
C:\program Files (x86)\VideoLAN\vlc.exe”
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList]
"LicenseServers"=hex(7):00,00
"CertificateIssuedBy"=""
"LicensingType"=dword:00000005
"fHasCertificate"=dword:00000000
"CertificateExpiresOn"=""
"CentralLicensing"=dword:00000000
"fDisabledAllowList"=dword:00000000
"CertificateIssuedTo"=""
"CustomRDPSettings"="authentication level:i:2"
@="1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\VLC]
"Name"="VLC"
"Path"="C:\\Program Files (x86)\\VideoLAN\\VLC\\vlc.exe"
Ich habe gerade nochmal ein paar kleinere Änderungen im Artikel vorgenommen. Vielleicht klappt es ja jetzt.
hallo andy,
Leider klappt das Verfahren nicht wie beschrieben, ich habe keine Ahnung mehr woran es liegen könnte.
Server: Win7Pro
Client: WinXPPro
Wenn ich in der *.rdp den Eintrag “remoteapplicationmode:i:” auf “0” setze startet eine normale RDP Sitzung. Ich bekomme das Anmeldefenster mit meinem Benutzernamen, und kann mich korrekt anmelden. Ein zweite von einem anderen Rechner ist möglich, es wird aber die erste gekappt.
Wenn der Eintrag auf “1” steht, startet kurz das Programm und verschwindet wieder.
Im Taskmanager läuft kurz “mstsc.exe”.
WO nur steckt der Detailteufel??
Bin über jede Hilde sehr dankbar.
Gruß, Mario
Hallo Mario,
du hast dir die Frage quasi selbst beantwortet:
Bei Windows 7 Professional funktioniert RemoteApp nicht.
Soll heissen, dein Win 7 Pro als TS-Server unterstützt leider kein RemoteApp.
Ich habe mir daran auch schon die Zähne ausgebissen, leider ohne Erfolg.
Da fehlen irgendwelche Komponenten.
Ich hatte mal versucht, das von Win 7 Ultimate abzuleiten (DLLs kopiert, Registry Settings kopiert, etc.).
Hat aber alles nicht geholfen.
Gruß
Andy
Das ganze funktioniert bei mir wunderbar – zumindest mit Notepad. Mit anderen Programmen geht es aber nicht, woran kann denn das liegen ?
Man muss in der Registry für jede Anwendung entsprechend die Werte “Name” und “Path” anpassen. In der RDP-Datei muss der Eintrag “Remoteapplicationprogram” angepasst werden. Dann sollte das eigentlich gehen.
Das habe ich natürlich gemacht, es kommt trotzdem die Meldung “Programm xy wurde nicht gefunden”
Ok, das war nur der erste Gedanke.
Du kannst mal versuchen, die Anwendung nicht via Registry, sondern direkt in der RDP-Datei anzugeben:
remoteapplicationname:s:NAME
remoteapplicationprogram:s:PFAD UND EXE
Dadurch ist man etwas flexibler, wie ich finde.
Parallel dazu habe ich mal versucht, dein Problem nach zu stellen. Dabei hatte ich das Problem, das unter Windows XP gar keine RemoteApp zu öffnen war (Fehlermeldung: “Der Remote Computer unterstützt keine RemoteApp”). Das Update der Remotedesktopverbindung auf Version 7.0 brachte dabei Abhilfe (RDC 7.0).
Unter Windows 7 Enterprise x64 Trial funktioniert alles ohne Probleme. Getestet mit Notepad, Calc und Media Player Classic.
Hier noch ein paar Links zum Thema RemoteApp:
WINDOWSXPSYSTEMCRASH – RemoteApp
RemoteApp for Hyper-V
How to enable RemoteApp
Bei mir lief unter Win XP bis vor 6 Wochen alles klasse.
Jetzt ist plötzlich wieder nur 1 User zur Zeit möglich, obwohl termsrv.dll immer noch die gleiche ist. Im Tastkmanager werden auch keine Benutzer mehr angezeigt.
Nach Zusammenführung der xp.reg sind sie wieder da – nach Neustart wieder weg.
Wer weiss Rat?
LG Moni
Hallo zusammen,
ich habe Probleme mit dem gleichzeitigen Zugriff auf einem WINXP Prof. x86 System.
Es hat mit diesem (oder einem anderen WinXP-System) noch nie geklappt. Die DLL ist gepatcht, die Registry ist abgeändert. Der Rechner wurde neu gestartet.
Trotzdem kann sich immer nur ein User auf den PC connecten.
Mit Win7 prof x64 funktioniert es in der gleichen Netzwerkumgebung übrigends hervorragend.
Hi Ulli,
ich kann das leider nicht nachvollziehen. Hier funktioniert es mit zwei Systemen.
Windows XP Professional ist kein Problem. Aber ich habe hier Vista Home Premium 32 Bit mit dem Service Pack 2 (SP2), da scheint es nicht mehr zu gehen, kann das sein?
Allen Home Editions von Windows, egal ob XP, Vista oder 7 fehlt die Möglichkeit, ein Remotedesktopserver zu sein. Bei Vista muss es mindestens die Business Edition und bei XP und 7 mindestens die Professional Edition sein.
Offensichtlich ging es aber mal mit Vista Home Premium (32), dazu gibt es einige Beiträge im Netz.
Die Frage ist, ob es seit dem SP2 nicht mehr geht. Aber jetzt habe ich was dazu gefunden:
http://andrewblock.net/2009/06/08/how-to-enable-remote-desktop-on-windows-vista-home-premium
Das probiere ich heute Abend mal aus…
Na gut, auf mein XP-Problem (ist übrigens prof. SP3)geht keiner ein.
Warscheinlich hat MS das weg geupdatet.
Ich habe mir Server2003 für 50 Euro ersteigert und Problem hat sich erledigt (sind übrigens 5 gleichzeitige Verbindungen möglich).
Viel Spaß also noch. Viele Grüße!
@Moni: tut mir Leid, da fällt mir nichts dazu ein. Ich habe aber auf ein paar Windows XP SP3 Rechnern eine geänderte termsrv.dll im Einsatz, das geht nach wie vor problemlos und die Rechner werden alle automatisch upgedatet.
Ich habe das aber nicht über eine Batch oder so gemacht, sondern händisch mit dieser dll, die hat 215552 Bytes und den MD5-Hash: A77219A971029DC2FB683E8513713803
Das geht schon seit ein paar Jahren damit. Nach dem SP3 musste ich natürlich wieder überspielen, aber noch kein Update hat die danach je wieder berührt.
Die DLL gibt es z.B. hier mit Anleitung und Download:
http://www.asktheadmin.com/2008/08/enable-multiple-remote-desktop-connections-to-your-xp-or-mce-machine.html
Ich habe gerade verglichen, das ist sie.
Also meine XP Pro-Systeme sind auf dem neuesten Stand und laufen. Bei den Server-Systemen brauchst du aber zusätzlich zu den CALs noch die TSCALs, andernfalls ist nach 120 Tagen Ende im Gelände mit Terminalserver-Verbindungen.
Da gibt es aber einen ganz einfachen Trick mit den Terminal Server Lizenzen auf dem Windows Server, hab ich mal gelesen und auch ausprobiert:
http://i-admin.blogspot.com/2005/06/how-to-crack-windows-terminal-services.html
das hatte auch geklappt.
Problemlos mit:
Server: Win7 Pro SP
Clients: WinXP Pro SP3 & Bodhi Linux & Android
Einfach Patch, vista.reg, reboot – Danke!
Das ist eine gute Anleitung zu einer sehr interessanten Info, jedoch funktioniert es bei mir leider auch nicht.
Server: Win Xp Pro SP3; Termserv.dll gepatcht; RDP Update auf Version 6.1.7600 somit Protokoll-Version 7.0
Client: Win XP Pro SP3; RDP Version 6.0.6001 somit Protokoll-Version 6.1
Eine normale Remote Verbindung vom Client zum Server läuft, an der Firewall liegt es somit wohl nicht.
Sehr sehr schade, habt ihr vielleicht noch weitere Tipps?
Hallo Manuel,
die Datei “xp.reg” hast du per Doppelklick in die Windows-Registry importiert? Neustart auch schon gemacht?
Hallo Andy,
die Registrierungsschlüssel (inkl. denen vom Patch) habe ich hinzugefügt und neugestartet auch schon ein paar mal.
Was mir dabei noch aufgefallen war, dass der Schlüssel/Ordner Applications nicht vorhanden war. Also habe ich den einfach erstellt und darin den Schlüssel/Ordner Notepad wie von dir angegeben.
Es ist übrigens der “The remote computer does not support RemoteApp” Fehler.
Was genau funktioniert bei dir jetzt nicht? Terminalserver allgemein oder RemoteApp im speziellen?
Wenn’s um RemoteApp geht: Hast du auch die RDP-Datei entsprechend konfiguriert?
Also es ist ja kein “richtiger” Terminalserver sondern nur ein Win XP plus Anpassungen mit Remotedesktop-Freigabe.
Die Remotedesktop-Freigabe funktioniert inklusive des Patches für Concurrent Users, die Anpassungen um RemoteApp zu nutzen funktionieren jedoch nicht.
Auf der Clientseite habe ich der RDP-Datei:
remoteapplicationmode:i:1
remoteapplicationprogram:s:c:\windows\system32\Notepad
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe
auch der versuch mit:
remoteapplicationprogram:s:Notepad
bringt immer den oben genannten Fehler, was mich (entsprechend des Textes) vermuten lässt, dass es am Server liegt.
Ich habe mal den kompletten Terminal Server Zweig der Registrierung hier gespeichert: http://paste.org/43125
Eigentlich sollten davon ja nur die letzten Zeilen relevant sein, aber wenn ich die mit denen hier genannten vergleiche kann ich einfach keinen Fehler finden.
Ich hatte das ja auch mal, da konnte man es mit dem Remote Desktop Client 7.0 beheben.
Hm, sonst weiß ich jetzt auch nicht mehr weiter.
Evtl. hat MS da mittlerweile was “weggepatcht”.
Der Artikel ist ja schon ein paar Tage alt.
Auch ein Update des RDP-Clients auf Version 6.1.7600 somit Protokoll-Version 7.0 hat leider nicht geholfen.
Wirklich schade, trotzdem vielen Dank.
Hi Andy,
in Bezug auf das Problem das unter Win7 prof remoteapp nicht geht:
Hast du mal die Reg schlüssel unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Terminal Server
zwischen professional und ultimate verglichen?
Ich habe leider keine Systeme oder die Möglichkeit das zu testen, aber vllt hönntest du das ja tun oder hast es vllt schon getan.
Eine antwort wäre nett 😉
Hab’ ich damals alles gemacht. Hatte sogar hin und her ex- bzw. importiert, Dateien die in Ultimate sind nach Professinoal kopiert usw. Hat alles nichts geholfen.
Hallo,
zuerstmal danke für die gute Beschreibung. Ich habe die obigen Schritte ausgeführt und mehrmals kontrolliert. System ist auf dem aktellsten Stand. Patch und registry ausgeführt.
Gleichzeites Anmelden unter verschieden Benutzern funktioniert. Allerdings wird bei gleichzeitigem Anmelden mit RDP mit gleichem Anmeldenamen die bestehende Verbindung gekappt.
Ich werde ehrlich gesagt wahnsinnig weil das nicht so klappt, und ich weiß das der Fehler vor dem Rechner sitzt.
Hilfe wäre Spitzenmäßig
Terminal: Win XP Pro SP3
Clients: Apple, Win 7 Ultimate, Win XP
Grüße Newton
Bin mir gerade nicht sicehr ob ich dich richtig verstehe:
> Gleichzeites Anmelden unter verschieden Benutzern funktioniert.
Ok, so soll das auch sein.
> Allerdings wird bei gleichzeitigem Anmelden mit RDP mit gleichem Anmeldenamen die bestehende Verbindung gekappt.
Du willst mit gleichem Benutzernamen mehrere Sitzungen aufmachen? Das funktioniert natürlich nicht. Benutzernamen müssen eindeutig pro Sitzung sein.
“Gleichzeites Anmelden unter verschieden Benutzern funktioniert. Allerdings wird bei gleichzeitigem Anmelden mit RDP mit gleichem Anmeldenamen die bestehende Verbindung gekappt.”
Wie Andreas schon bemerkt, geht das natürlich nicht. Wenigstens nicht unter Windows XP.
Mit einem Serversystem (Windows Server 2003 o.ä.) kannst du unter gleichem Benutzernamen über RD eine Konsolesitzung (das ist mit dem Schalter /admin) und eine Nicht-Konsolesitzung gleichzeitig haben, das wars aber dann auch.
nach dem windows 7 updates gemacht hat, funktioniert leider das ganze nicht mehr. weiss jemand eine lösung.
windows 7 pro wird verwendet.
danke zum voraus
Das hatte ich gelegentlich auch schon: Nochmals das Tool “Universal Termserv.dll Patch” ausführen und erneut patchen.
Ich habe jetzt gerade bei zwei Windows 7 Rechnern, einer 32 Bit, einer 64 Bit, beide Professional und beide gepatcht, getestet, aber obwohl sie beide up to date sind konnte ich mich problemlos in einer zweiten Sitzung (im Hintergrund) verbinden.
Kann also nicht bestätigen, dass das Problem mit Windows Updates zu tun hat, tut mir leid, bzw. gar nicht 🙂
danke für die rasche antwort.
leider kommt immer:
für den computer konnte keine verbindung mit einer anderen konsolensitzung auf dem remotecomputer hergestellt werden, da bereits eine konsolensitzung aktiviert ist.
—-
dies wie gesagt, seit windows updates gemacht hat.
Aber Port 3390 wird nicht verwendet?
Das hatte ich nämlich auch schon mal, aber die Suche nach der Fehlermeldung gibt das ja als ersten Treffer, das wird es also kaum sein.
Aber man weiß ja nie 🙂
Port ist Standart 3389
An Port 3390 habe ich auch schon gedacht, aber dennoch danke.
Das Problem besteht aber leider immer noch.
Das letzte mal habe ich PC zurück gesetzt und das Problem war gelöst. Auch da waren updates im Spiel. Aber jedes mal PC zurücksetzen kann es auch nicht sein.
Von einem anderen Rechner, namentlich mit einer anderen, älteren mstsc.exe hast du aber schon probiert?
Nur um auszuschließen, dass es nicht nur am Zielrechner liegt…
hallo. ja, es wurde immer von einem anderen rechner aus probiert.
vom selben rechner hat es nie richtig funktioniert.
seit ich nun einige updates deinstalliert habe funktioniert das ganze auch wieder.
Man lernt nie aus! Das hätte ich nicht gedacht, weil das bei mir noch nie war.
Dann ist ja alles wieder gut. Hast du herausgefunden WELCHES oder WELCHE Updates das waren?
Welche hast du denn deinstalliert?
Kleine Info am Rande, für diejenigen, die das Ganze in einer Domäne betreiben (wollen):
http://blog.bartlweb.net/2010/03/windows-xp-professional-in-einen-terminalserver-verwandeln/
Hallo!
Ist ne tolle Sache und funzt auch hat zwar ne weile gedauert bis ich alles zum laufen bekommen habe aber nun läuft erstmal alles..
TS: Win7 Ultimate
Clients: Win7 Pro und XP Pro
Nun meine Frage, was macht oder soll der Parameter
[alternate shell:s:rdpinit.exe] tun? ob der gesetzt ist oder nicht ist scheibar völlig egal..
Ich wüsste gern wo man den benutzer in der rdp festlegen kann da so wie ich das mitbekommen habe standardmäßig immer auf den user der default.rdp zurückgegriffen wird ….?
Den Parameter benötigt man bei RemoteApp.
Über den Eintrag “username:s:BENUTZERNAME” kannst du einen voreingestellen Benutzer in der RDP-Datei einpflegen.
Hallo Andy!
danke für die schnelle antwort.
ich benutze remoteapp dewegen wundert es mich ja eben das der parameter keine auswirkungen zeigt.
leider hat das mit dem benutzer nicht geklappt es wird immer der letze benutzer der in der default steht benutzt hab ich was vergessen?
screen mode id:i:2
desktopwidth:i:1680
desktopheight:i:946
session bpp:i:32
winposstr:s:0,3,0,0,800,600
compression:i:1
keyboardhook:i:2
displayconnectionbar:i:1
disable wallpaper:i:1
disable full window drag:i:1
allow desktop composition:i:0
allow font smoothing:i:0
disable menu anims:i:1
disable themes:i:0
disable cursor setting:i:0
bitmapcachepersistenable:i:1
full address:s:10.xxx.xxx.xxx
audiomode:i:0
redirectprinters:i:1
redirectcomports:i:0
redirectsmartcards:i:1
redirectclipboard:i:1
redirectposdevices:i:0
drivestoredirect:s:
autoreconnection enabled:i:1
authentication level:i:0
prompt for credentials:i:1
negotiate security layer:i:1
remoteapplicationmode:i:2
remoteapplicationprogram:s:Calc
username:s:test2
disableremoteappscheck:i:1
alternate shell:s:calc.exe
shell working directory:s: