Windows remoteApps: Nicht seamless?

Hallo,

ich habe diese Woche einen kleinen Testserver mit einer 2019er Evaluation aufgesetzt, um mich mit dem theoretisch sehr coolen Thema "Remote Apps" auseinander zu setzen.
Meine Erwartungshaltung war, dass ich damit in der Lage wäre, einzelne Applikationen bereit zu stellen, die dann auf Client Computern überall auf der Welt funktionieren. Diese Erwartung wurde erfüllt.
Nun steckt der Teufel ja wie immer im Detail, und mir sind da Dinge aufgefallen, die ich verwunderlich finde:

- Drag and Drop funktioniert nur innerhalb der RDS Session, soll heißen ich habe beispielsweise einen lokalen Explorer, ein remote-Wordpad und ein remote Mailprogramm offen. Ich kann nun Mails vom Mailprogramm in Wordpad ziehen, aber nicht vom Mailprogramm in den lokalen Explorer oder andere lokale targets.
- Befehle scheinen nicht nach local übergeben zu werden. Klicke ich innerhalb einer remote App einen Mailto: an, oder initiiere einen MAPI Befehl, dann wird das auf dem Remotedesktop-Server ausgeführt. Gleiches gilt für file open Operationen, die zu erwarten scheinen, dass alle Software auf dem RDS verfügbar ist.
-Wenn ein Programm hängt und ich kille das über den Task Manager, dann scheint das nicht wirklich Auswirkung zu haben. Auf dem RDS bleibt es offen und muss administrativ beendet werden?

Ich habe das Ganze mit der in W10 mitgelieferten mstsc.exe getestet. Ein Test mit der Store-APP (https://www.microsoft.com/.../microsoft.../9wzdncrfj3ps) ) war mir nicht möglich, da man die Work Ressources nicht einbinden konnte, da der Okay Button grau blieb. Da sind die Work Resources aber schon im Win10 eingebunden gewesen, weshalb ich stark enttäuscht war, dass er die nicht benutzen konnte. Der Link war funktional, man kann ihn im Browser aufrufen, und er hat für die Implementierung der work ressources im Win10 funktioniert.

Daher nun mal final die Fragen:
- Was mache ich falsch?
- Ist das wirklich so unausgegoren?
- Falls dieses Verhalten der per remoteApp bereitgestellten Applikationen korrekt so ist, wo liegt dann der Vorteil zu einer richtigen RDS Session? Rein von der User Experience finde ich es nämlich verwirrender, lokal Programme zu haben, und remote-Programme, denen man das aber nur bei genauem hinsehen an Details ansieht, und dass man sich dann merken müsste, welche Programme mit welchen Programmen interagieren können, und welche nicht. Das kriegt man doch nie in normale User rein....
- Gehts mit der Store-App anders/besser? Im Netz stand sowas in der Art. Falls ja, wie erwartet er die Einbindung des Workspaces?

Danke im Voraus

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 664904

Url: https://administrator.de/contentid/664904

Ausgedruckt am: 26.11.2024 um 02:11 Uhr

11 Kommentare

Neuester Kommentar

Hi.

Das Verhalten ist normal und zu erwarten.
Vorteil von RemoteApps gegenüber Vollsitzung: sie sind seamless (du benutzt den Begriff falsch). Seamless bedeutet lediglich, dass Du ihre Fenster wie lokale Fenster nutzen kannst in Punkto vergrößern und verkleinern.

Die Interaktion von lokalen und remote-Programmen ist nicht so gedacht, wie du es dir erhoffst. Die RemoteApp schaut sich nicht auf deinem PC um "hm, was haben wir denn da alles schönes..." und kann keine Daten an die lokalen Anwendungen übergeben mit Ausnahme der Zwischenablageinhalte (Text) oder Dateien, wenn man sie in einem Remote-Explorer oderr Remote-Datei-öffnen-Dialog kopiert und dann lokal einfügt oder umgekehrt.

Was jedoch geht, ist ein zuordnen einiger lokaler Dateitypen zu remote-Programmen. Du kannst also sagen: "mach mir .docx mit der RemoteApp Word auf" - was funktioniert, wenn ein Netzwerkpfad für das .docx verwendet wird, den dein Nutzer auf dem Remoterechner ebenso vorfindet/erreichen kann.

Vielen Dank, das habe ich mir fast gedacht. Aber gut, dass Du das noch mal klar stellst, dann kann ich meine Tests mit dieser für den Büroalltag nutzlosen, verwirrenden Technologie ja beenden.
Ich werde mich für Kiosk-Systeme und sowas dran erinnern, aber sonst weiterhin komplette Desktops bereit stellen.

Wie ist denn die genaue Definition des Wortes in dem Bereich? Seamless = Nahtlos hat für mich eigentlich bedeutet, dass ich damit eben auch nahtlos arbeiten können muss. Und mit arbeiten meine ich "Klick auf Mailadresse öffnet das Mailprogramm", "Klick auf Tel: öffnet die CTI", "Explorer öffnen bezieht sich auf den lokalen Explorer", etc.

So, wie das technisch gelöst zu sein scheint kann ich ehrlich gesagt keinen Mehrwert erkennen, außer für solche Insellösungen wie oben angesprochen. Mir wäre es ja tatsächlich um eine Client-Server Applikation mit Datenbankanbindung gegangen, die man extern nicht sauber nutzen kann. Dafür haben wir aktuell halt auch RDP im Einsatz, und ich wollte ggf. diese eine App verfügbar machen.
Aber da sie eben DMS, CTI, Mail und flglich auch viele fileopen Operationen mit tausend Dateitypen beinhaltet müsste ich den Remotedesktopserver ja dann trotzdem soweit mit Programmen und Ressourcen aussstatten, dass alles funktioniert. Und dann kann man die User auch ordentlich auf dem Server arbeiten lassen, dann trennt sich das auch schöner im Kopf.

Grüße, und vielen Dank noch mal für die rasche und kompetente Antwort.
Hab ein schönes WE!

mit dieser für den Büroalltag nutzlosen, verwirrenden Technologie

You made my day. My friday 😎

Manuel, willst Du mir etwa sagen, dass Deine User das hin bekommen würden im Kopf zu separieren, was wo funktioniert, und auf welche Ressourcen sie wann zugreifen können?

Wie ich schon sagte, ich lerne gern mehr dazu. Erklär mir doch mal, wozu das Ganze da ist, wenn keine Interaktionen mit lokal möglich sind.

Grüße

Manuel, willst Du mir etwa sagen, dass Deine User das hin bekommen würden im Kopf zu separieren, was wo funktioniert

Ja, schon...
Im wesentlichen hat mich aber amüsiert, wie du mit deiner Einzelmeinung eine Technik die 1.000.000-fach im Einsatz ist als

für den Büroalltag nutzlose, verwirrende Technologie

hinzustellen versuchst.

Jede Technologie hat ihren Einsatzbereich!

Manuel

Du Glücklicher

Meine würden nie verstehen, warum sie innerhalb einer auf ihrem eigenen Rechner gestarteten Applikation nicht alle Aktionen durchführen können, die sie lokal auch können. Warum sie eine Drag and Drop Operation von einem Fenster ins andere nicht durchführen können.

Ich meine, ich hatte vorher schon befürchtet, dass sowas nicht gehen würde. Aber da das Serverbetriebssystem, die Userverwaltung, das Clientbetriebssystem, und die für den Zugriff verwendete Software vom gleichen Hersteller kommt hätte man ja auch erwarten können, dass das Ganze geht. Gerade wenn es doch "nahtlos" ist

Bitte erklär mir doch mal sinnvolle Einsatzbereiche. Mir fällt echt außer so Single App Deployment Dingen nichts ein, wo das besser/sinniger wäre als ein "echter" Remote Desktop. Ich habe bestimmt etwas übersehen...

MfG Maik

Bitte erklär mir doch mal sinnvolle Einsatzbereiche.

Gerne.

Du kannst bspw. die User komplett auf dem TS arbeiten lassen. Der lokale Client ist entweder nur ein Terminal oder lediglich ein PC mit Windows oder Linux. Sonst nichts. Alles was der User braucht befindet sich auf dem Terminalserver. In den meisten Fällen wird der User dann aber nicht mit RemoteApps sondern mit einem veröffentlichten Desktop arbeiten.
Etwas anderes sind Anwendungen wie bspw. ERP oder andere Branchensoftware. Die wird gerne mal als RemoteApp auf einem TS veröffentlicht. So lange der User darin nicht mit lokalen Daten arbeiten muss überhaupt kein Thema.
Was die lokalen Daten angeht haben unsere User strikte Anweisung nichts lokal zu speichern sondern alles in den entsprechenden Shares. Und die sind dann auch per RemoteApp greifbar. Macht der User also bspw. einen Export aus dem ERP in eine XLS, dann speichert er die in seinem persönlichen Netzwerkshare. Von da kann er die Datei dann verzugslos auf seinem Client in Excel öffnen.

Im großen und ganzen funktioniert das problemlos. Ab und an kommt mal ein User der sich wundert, dass er etwas unter Desktop gespeichert hat, aber die Datei auf seinem Client nicht finden kann. In der Regel sind das dann neue Kollegen die nicht richtig zugehört haben.
Der große Vorteil bei Anwendungen auf Terminalserver liegt hat im der deutlich geringeren Aufwand bei Updates. Wenn ich jedes Mal (mindestens monatlich) die Updates unseres ERP auf alle Client installieren und testen müsste hätte ich viel zu tun. So wird das genau einmal abends auf dem TS gemacht. Je nach Umfang des Updates vorher einen Snapshot der VM erzeugt für den Fall der Fälle und das Thema ist in 60-90 Minuten gegessen. Und das war jetzt nur das ERP ohne alles was sonst noch so im Einsatz ist.

Gerade aktuell wird ja viel Homeoffice gemacht. Da reduziert so ein TS auch ganz deutlich die mindestens notwendige Bandbreite beim User zu Hause. Es wird ja sozusagen nur die Bildinformation übertragen sowie Mausbewegung und Tastatureingaben. Der ganze Rest wie bspw. Datei vom Fileserver öffnen und wieder speichern findet nur zwischen den beteiligten Servern statt. Wenn dein ERP auf dem Client installiert ist wird das innerhalb des Büros kein großes Problem sein. Das LAN ist schnell genug. Wenn der ERP-Client aber seine ganze (Datenbank)-Zugriffe über ein vielleicht nicht wirkliches schnelles VPN jubeln muss macht das arbeiten ganz schnell keinen Spaß mehr.

Manuel

In den meisten Fällen wird der User dann aber nicht mit RemoteApps sondern mit einem veröffentlichten Desktop arbeiten.

Jetzt bin ich doch etwas verwundert. Ich hatte die ganze Zeit nach den Vorteilen der Remote Apps gefragt gegenüber einer richtigen RDP Verbindung gefragt. Das ist ja genau das, was ich sinnfrei finde, dass es sich verhält wie innerhalb einer RDP, man das aber nicht gut sieht.

Wie ich schon schrub haben wir schon einige RDP Server im Einsatz, die für die Bereitstellung von kompletten Desktops benutzt werden.
Ich weiß quasi auch, wie die funktionieren, und dass die für HO ganz nutzvoll sind. Ich fand halt nur die Idee charmant, nur die eine Software, die es überhaupt notwendig macht, per RDP zu arbeiten auf den Clients "seamless" bereit zu stellen. Aber eben das ist nicht in der Art möglich, dass alles funktioniert was normal auch gehen würde.

Soll das Ding Mails ansprechen muss auch das Mailprogramm angesprochen werden, und remote verfügbar sein. Soll TAPI genutzt werden muss die TAPI Software remote verfpügbar sein. Es muss quasi alles vollständig installiert werden, wie bei einem vollwertigen Remote Desktop auch.
Und nun noch mal die Frage: Wo liegt der Vorteil/use Case zwischen der Bereitstellung von allen Applikationen, die genutzt werden sollen über einen vollwertigen Remote Desktop ggü 10-30 remote-Apps, die man dann ja braucht? Der Installationsaufwand ist ja quasi der gleiche, nur die Bereitstellung ist etwas komplizierter, und meiner Meinung nach ist die Nutzung für den Enduser dann auch verwirrender.

Mfg Maik

Jetzt bin ich doch etwas verwundert. Ich hatte die ganze Zeit nach den Vorteilen der Remote Apps gefragt

Meine Aussage bezog sich darauf, dass User evtl. "nur" Terminals nutzen oder PCs die nur Windows haben. Dann arbeiten die halt auf einem RemoteDesktop statt mit RemoteApps.

Aber eben das ist nicht in der Art möglich, dass alles funktioniert was normal auch gehen würde.

Kommt auf die Software an die auf dem TS läuft.

Soll das Ding Mails ansprechen muss auch das Mailprogramm angesprochen werden

Kommt drauf an. Wenn die RemoteApps direkt SMTP können um bspw. Mails zu verschicken, dann nicht.

Soll TAPI genutzt werden muss die TAPI Software remote verfpügbar sein.

Wo liegt der Vorteil/use Case zwischen der Bereitstellung von allen Applikationen

Es sieht für den User aus wie eine lokale Anwendung. Es muss ihn nicht interessieren wo die Anwendung wirklich läuft.

Der Installationsaufwand ist ja quasi der gleiche, nur die Bereitstellung ist etwas komplizierter

Was ist daran komplizierter? Der Unterschied besteht doch nur in der Anwendungsveröffentlichung?!

Es wird ja niemand gezwungen RemoteApps zu verwenden. Wer die nicht leiden kann veröffentlicht hat einen Desktop. Und wer beides nicht mag spart sich die TS-Lizenzen und installiert alles lokal.

Es sieht für den User aus wie eine lokale Anwendung. Es muss ihn nicht interessieren wo die Anwendung wirklich läuft.

Und eben DAS ist falsch. Die remoteApps verhalten sich ja eben anders, als lokale Applikationen. Lokale Anwendungen können auf lokale Ressourcen zugreifen. Sie können andere Appliaktionen ansprechen. Sie können Schnittstellen wie MAPI oder eben TAPI ansprechen, anwendungsübergreifend. Remote Apps sind keine validen Drag and Drop Targets/Sources, außer für andere remote Apps.
So muss der User eben doch wissen, dass er von remoteApp A auf localApp B keine Inhalte ziehen kann. Dass er nicht aus der ERP RemoteApp Mails generieren kann, die dann in seinem Mailprogramm aufgehen, usw.
Es ist eben kein sinnvoller "Mischbetrieb" möglich, weshalb ich halt keinen sinnvollen Use Case erdenken kann.

Und Du kannst mir ja auch keinen sagen, bisher. Man muss sich halt dann entscheiden, alles auf dem remote Desktop ans laufen zu bekommen, weshalb man halt gleich ganze Desktops deployen kann.

Was ist daran komplizierter? Der Unterschied besteht doch nur in der Anwendungsveröffentlichung?!

Also falls ich bei der Installation nichts falsch gemacht habe, oder die falsche Anleitung hatte ist die Installation der RDP Rolle umfangreicher, man bekommt einen für full Remote Desktop unnötigen IIS, den man mit Zertifikaten ausstatten darf (die zu pflegen sind), man muss Work Resources anlegen, die man deployt, etc. etc. Ich finde das schon komplizierter.