Out-of-Process-Plug-In für Windows 365 Link (Vorschau)

Einführung

Was ist ein Remotedesktop-Plug-In?

Ein Remotedesktop-Plug-In ist eine Erweiterung oder ein Add-On, das die Funktionalität von Microsoft-Remotedesktop (RDP)-Clients verbessert, in der Regel in Anwendungen von Drittanbietern. Beispiel: Teams VDI-Plug-In , das entwickelt wurde, um die Leistung von Teams bei der Ausführung in virtualisierten Umgebungen zu optimieren. Für Windows 365 Link müssen diese Plug-Ins einer neuen Architektur entsprechen, die in diesem Dokument beschrieben wird. Wenn Sie einen ISV vertreten, der ein Remotedesktop-Plug-In benötigt, um mit Link zu arbeiten, füllen Sie bitte dieses Formular aus, und senden Sie es ab.

Dieses Feature befindet sich in Public Preview.

Was ist ein Out-of-Process-Remotedesktop-Plug-In?

Herkömmliche RDP-Plug-Ins werden in denselben Prozess wie der RDP-Client geladen. Wie im folgenden Diagramm zu sehen, lädt die RDPClientProcess.exe die verschiedenen RDP-Plug-In-DLLs. Sobald das Laden abgeschlossen ist, wird das Plug-In Teil von RDPClientProcess.exe.

Im Out-of-Process-Modell:

1. Der RDP-Clientprozess lädt die RDP-Plug-Ins out-of-Process, d.a. als unabhängiger Prozess getrennt vom RDP-Client und
2. Beschränken Sie den Zugriff des Plug-Ins auf das breitere Windows-Betriebssystem, indem Sie die Prozessisolation mithilfe von AppContainers erzwingen.

Architektur für das Laden des Out-of-Process-Plug-Ins

Das folgende Diagramm zeigt eine allgemeine Erläuterung der Interaktion der RDP-Clients mit den RDP-Plug-Ins in einem Out-of-Process-Modell.

1. Die RDP-Plug-Ins können als COM-Server und RDP-Clients als COM-Clients betrachtet werden.
2. Die RDP-Plug-Ins sind jetzt unabhängige Prozesse, die in der App-Isolation ausgeführt werden. RdPClientProcess.exeloads the plugins using COM's CoCreateInstance API.
3. Die Autoren des RDP-Plug-Ins müssen die in den DLLs enthaltene Hauptgeschäftslogik nicht ändern. Sie müssen nur das Plug-In als MSIX packen. Daher müssen Plug-In-Autoren minimale Änderungen am RDP-Plug-In-Code vornehmen.

Implementierungsdetails

Wenn Plug-Ins in einer RDP-Verbindung verwendet werden, sind drei Parteien beteiligt.

1. Der RDP-Client (z. B. Windows App).
2. Das RDP-Plug-In.
3. Die Anwendung, für die das Plug-In geschrieben wird (z. B. Teams-Anwendung).

Betrachten Sie beispielsweise eine Situation, in der ein Benutzer Azure Virtual Desktop verwendet, um eine Verbindung mit einem virtuellen Desktop herzustellen, und die Teams-Anwendung verwendet, die auf dem virtuellen Desktop ausgeführt wird. Hier ist Azure Virtual Desktop der RDP-Client (Clientanwendung), das Teams VDI-Plug-In ist das RDP-Plug-In und Teams ist die Remoteanwendung, die auf dem virtuellen Desktop ausgeführt wird, die Serveranwendung.

Wir haben hier ein vollständiges Funktionierendes Beispiel. In diesem Beispiel werden die Implementierungsdetails mithilfe eines RDP-Beispielclients, eines RDP-Plug-Ins und einer Beispielanwendung, die auf dem virtuellen Remotecomputer ausgeführt wird, erläutert.

Was müssen Plug-In-Autoren tun?

Alle RDP-Plug-Ins funktionieren über DIE COM-Kommunikation. Das RDP-Plug-In ist der COM-Server, und der RDP-Client ist der COM-Client (weitere Informationen finden Sie unter COM-Clients und COM-Server). Sowohl der COM-Client (RDP-Client) als auch der COM-Server (RDP-Plug-In) befinden sich auf dem Clientcomputer. Es gibt zwei Hauptaufgaben, die die Plug-In-Autoren ausführen müssen:

1. Definieren Sie die Funktionen der Schnittstellen, die in der tsvirtualchannels-Dokumentation deklariert sind. Plug-In-Autoren müssen nicht jede einzelne Funktion definieren, sondern nur die, die verwendet werden.
2. Packen/verteilen Sie das RDP-Plug-In als MSIX. Derzeit ist MSIX die einzige Möglichkeit zum Packen von Anwendungen, die App-Isolation, COM und Paketidentität unterstützen. Es gibt einige wichtige Details, die beim Verpacken der App beachtet werden müssen. Diese Details werden anhand eines Beispiels hier behandelt.

Was müssen die RDP-Clients tun?

Auf hoher Ebene liegt es in der Verantwortung des RDP-Clients,

1. Ermitteln und laden Sie die RDP-Plug-Ins in den Arbeitsspeicher.
2. Implementieren Sie clientseitige Schnittstellen wie IWTSWindowInfoService.

Sobald der RDP-Clientprozess gestartet wurde, sollte er über den Code für folgendes verfügen:

1. Entdecken Sie die Plug-Ins mithilfe von AppExtensionCatalog::Open("com.microsoft.rdp.plugin.wtsplugin"). Weitere Informationen finden Sie in der Dokumentation zu App-Erweiterungen.
2. Rufen Sie die COM-Klassen-ID der ermittelten Plug-Ins ab.
3. Erstellen des COM-Objekts der Plug-In-Factory mithilfe von CoCreateInstance Erstellen Sie das tatsächliche Plug-In mithilfe der -Plug-In-Factorys CreatePluginAPI (definiert im RDP-Plug-In selbst).

Was muss die RDP-Serveranwendung tun, um Daten zu senden/zu empfangen?

Die Serveranwendung kann die WTSVirtualChannelOpenEx-API verwenden, um einen dynamischen virtuellen Kanal für das RDP-Plug-In zu öffnen, das auf dem Clientcomputer ausgeführt wird, indem das WTS_CHANNEL_OPTION_DYNAMIC Flag übergeben wird. Diese API öffnet einen Duplexkanal zwischen dem RDP-Client und der Serveranwendung.

Anschließend kann es Daten mithilfe der WTSVirtualChannelWrite-API in den virtuellen Kanal schreiben und daten auf ähnliche Weise mithilfe der WTSVirtualChannelRead-API aus dem Kanal lesen. Die Voraussetzungen für das Öffnen dieses dynamischen virtuellen Kanals sind:

1. Zwischen RDP-Client und -Server muss eine RDP-Verbindung vorhanden sein.
2. Das RDP-Plug-In muss bereits auf dem Clientcomputer geladen sein.

Technologien, die verwendet/gut zu wissen sind

Da das Erstellen und Verwenden von RDP-Plug-Ins out-of-Process Kenntnisse über verschiedene Technologien erfordert, ist es besser, ein grundlegendes Verständnis dieser Plug-Ins zu haben, bevor Sie mit der eigentlichen Entwicklung und Verwendung des RDP-Plug-Ins fortfahren.

MSIX

MSIX ist ein modernes Paketformat für Windows-Anwendungen, das von Microsoft eingeführt wurde, um herkömmliche EXE-, MSI- und AppX-Installationsprogramme zu ersetzen.

AppContainer

Eine Sandbox zur Laufzeitsicherheit, die die darin ausgeführte Anwendung vom Rest des Systems isoliert und unbefugten Zugriff auf Ressourcen, vertrauliche Daten und andere Prozesse verhindert.

Paketidentität

Ein eindeutiger Bezeichner, der der AppContainer-Anwendung zugewiesen ist, mit der Windows Sicherheitsrichtlinien, Ressourcenzugriffssteuerungen und Anwendungsisolation erzwingen kann. Die Windows-Containertechnologie verwendet diese Identität als Primärschlüssel, um zu identifizieren, welche Anwendung über welche Ressourcenzugriff verfügt.

App-Isolation

1. AppContainers + Tools, die eine einfache Entwicklung ermöglichen. Windows stellt Tools wie Application Capability Profiler bereit, die die Funktionen der Anwendung automatisch angibt, anstatt sie manuell anhand des Codes zu finden.
2. Stellt COM-Funktionen innerhalb der Anwendung bereit, mit denen Anwendungsautoren ihre COM-Klassen deklarieren können, die von anderen Anwendungen genutzt werden, um eine nahtlose Interoperabilität zu ermöglichen.

App-Erweiterungen

App-Erweiterungen ähneln Plug-Ins, mit denen Entwickler die Funktionen einer vorhandenen Anwendung erweitern können.

Komponentenobjektmodell

Anwendungen können Schnittstellen plattformunabhängig verfügbar machen, ohne das "Wie" der Funktionalität verfügbar machen zu müssen. Die RDP-Plug-Ins interagieren mithilfe dieses Modells mit dem RDP-Client, indem schnittstellen verfügbar sind.

RDP-Kanal

Ein RDP-Kanal ist ein logischer Kommunikationsstream zwischen dem RDP-Plug-In und dem RDP-Server (z. B. Remotedesktopdienste-Host). Damit können benutzerdefinierte Daten zusammen mit der regulären RDP-Sitzung hin- und hergesendet werden – getrennt von Bildschirm-, Tastatur- oder Mausdaten.

Dynamische virtuelle Kanäle

Statische (herkömmliche) virtuelle Kanäle ermöglichen eine verlustfreie Kommunikation zwischen Client- und Serverkomponenten über die RDP-Hauptdatenverbindung. Dynamische virtuelle Kanäle sind eine verbesserte Version, aber die Kernfunktionalität ist identisch.

Schneller Rundown

COM Fast Rundown ist eine Einstellung in der COM-Serverregistrierung (suchen Sie COMGLB_FAST_RUNDOWNhier), die Windows angibt, wie die Lebensdauer eines OUT-of-Process-COM-Servers zu behandeln ist. Insbesondere kann das COM-Herunterfahren-Verhalten beschleunigt werden, indem die COM-Runtime den Server aggressiv beenden kann, wenn keine weiteren Clients mehr verbunden sind. Es kann immer noch bis zu 10 Sekunden dauern.

Marshalling/Entmarshalling

Ein Mechanismus zum Übertragen von Daten/COM-Objekten während einer Out-of-Process-Kommunikation zwischen COM-Client und COM-Server über Adressräume hinweg, z. B. zwischen verschiedenen Prozessen.