MSIX App Attach und App Attach in Azure Virtual Desktop

  • Artikel

Wichtig

App Attach befindet sich derzeit in der PREVIEW. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Es gibt zwei Features in Azure Virtual Desktop, mit denen Sie Anwendungen aus einem Anwendungspaket dynamisch an eine Benutzersitzung in Azure Virtual Desktop anfügen können – MSIX App Attach und App Attach (Preview). MSIX App Attach ist allgemein verfügbar, aber App Attach ist in der Preview verfügbar und verbessert die administrative und die Benutzererfahrung. Mit MSIX App Attach wie auch App Attach werden Anwendungen nicht lokal auf Sitzungshosts oder Images installiert, wodurch es einfacher ist, benutzerdefinierte Images für Ihre Sitzungshosts zu erstellen und den Betriebsaufwand und die Kosten für Ihre Organisation zu reduzieren. Anwendungen werden in Containern ausgeführt, die Benutzerdaten, das Betriebssystem und andere Anwendungen trennen, was die Sicherheit erhöht und die Problembehandlung erleichtert.

Die folgende Tabelle vergleicht MSIX App Attach mit App Attach:

MSIX-Feature zum Anfügen von Apps App Attach
Anwendungen werden mithilfe von RemoteApp oder als Teil einer Desktopsitzung bereitgestellt. Berechtigungen werden durch die Zuweisung zu Anwendungsgruppen gesteuert, alle Desktopbenutzer*innen sehen jedoch alle MSIX App Attach-Anwendungen in der Desktopanwendungsgruppe. Anwendungen werden mithilfe von RemoteApp oder als Teil einer Desktopsitzung bereitgestellt. Berechtigungen werden pro Anwendung pro Benutzer*in angewendet, sodass Sie besser steuern können, auf welche Anwendungen Ihre Benutzer*innen in einer Remotesitzung zugreifen können. Desktopbenutzer*innen sehen nur die Ihnen zugewiesenen App Attach-Anwendungen.
Anwendungen dürfen nur auf einem Hostpool ausgeführt werden. Wenn Sie diese auf einem anderen Hostpool ausführen wollen, müssen Sie ein weiteres Paket erstellen. Dasselbe Anwendungspaket kann über mehrere Hostpools hinweg verwendet werden.
Anwendungen können nur auf dem Hostpool ausgeführt werden, dem sie hinzugefügt wurden. Anwendungen können auf jedem Sitzungshost ausgeführt werden, auf dem ein Windows-Clientbetriebssystem in derselben Azure-Region wie das Anwendungspaket ausgeführt wird.
Um die Anwendung zu aktualisieren, müssen Sie die Anwendung löschen und mit einer anderen Version des Pakets neu erstellen. Sie sollten die Anwendung in einem Wartungsfenster aktualisieren. Für Anwendungen kann ein Upgrade auf eine neue Anwendungsversion mit einem neuen Datenträgerimage durchgeführt werden, ohne dass ein Wartungsfenster erforderlich ist.
Benutzer*innen können nicht zwei Versionen derselben Anwendung auf demselben Sitzungshost ausführen. Benutzer*innen können zwei Versionen derselben Anwendung gleichzeitig auf demselben Sitzungshost ausführen.
Telemetriedaten zu Verbrauch und Integrität sind jetzt über Azure Log Analytics verfügbar. Telemetriedaten zu Verbrauch und Integrität sind über Azure Log Analytics verfügbar.

Sie können die folgenden Anwendungspakettypen und Dateiformate verwenden:

Pakettyp Dateiformate Verfügbarkeit von Funktionen
MSIX und MSIX-Bündel .msix
.msixbundle		 MSIX-Feature zum Anfügen von Apps
App Attach
Appx und Appx-Bündel .appx
.appxbundle		 Nur App Attach

MSIX und Appx sind Windows-Anwendungspaketformate, die eine moderne Verpackungserfahrung für Windows-Anwendungen bieten. Anwendungen werden in Containern ausgeführt, die Benutzerdaten, das Betriebssystem und andere Anwendungen trennen, was die Sicherheit erhöht und die Problembehandlung erleichtert. MSIX und Appx sind ähnlich, wobei der Hauptunterschied darin besteht, dass MSIX eine Obermenge von Appx ist. MSIX unterstützt alle Features von Appx sowie andere Features, die es für den Einsatz in Unternehmen besser geeignet machen.

Tipp

Wählen Sie oben in diesem Artikel eine Schaltfläche aus, um zwischen MSIX App Attach (aktuell) und App Attach (Preview) zu wählen und die entsprechende Dokumentation anzuzeigen.

Sie können MSIX-Pakete von Softwareanbietern abrufen oder ein MSIX-Paket aus einem vorhandenen Installationsprogramm erstellen. Weitere Informationen zu MSIX finden Sie unter Was ist MSIX?

So erhalten Benutzer*innen eine Anwendung

Sie können verschiedenen Benutzer*innen im selben Hostpool oder auf demselben Sitzungshost unterschiedliche Anwendungen zuweisen. Bei der Anmeldung müssen alle drei folgenden Anforderungen erfüllt sein, damit Benutzer*innen die richtige Anwendung zum richtigen Zeitpunkt erhalten:

  • Die Anwendung muss dem Hostpool zugewiesen sein. Durch das Zuweisen der Anwendung zum Hostpool können Sie selektiv festlegen, auf welchen Hostpools die Anwendung verfügbar ist, um sicherzustellen, dass die richtigen Hardwareressourcen für die Verwendung durch die Anwendung verfügbar sind. Wenn eine Anwendung beispielsweise grafikintensiv ist, können Sie sicherstellen, dass sie nur auf einem Hostpool mit GPU-optimierten Sitzungshosts ausgeführt wird.

  • Benutzer*innen müssen sich bei Sitzungshosts im Hostpool anmelden können, daher müssen sie sich in einer Desktop- oder RemoteApp-Anwendungsgruppe befinden. Bei einer RemoteApp-Anwendungsgruppe muss die App Attach-Anwendung der Anwendungsgruppe hinzugefügt werden, Sie müssen die Anwendung jedoch nicht einer Desktopanwendungsgruppe hinzufügen.

  • Die Anwendung muss den Benutzer*innen zugewiesen werden. Sie können eine Gruppe oder ein Benutzerkonto verwenden.

Wenn alle diese Anforderungen erfüllt sind, erhalten die Benutzer*innen die Anwendung. Dieser Prozess bietet Kontrolle darüber, wer eine Anwendung auf welchem Hostpool erhält, und wie es möglich ist, dass Benutzer*innen innerhalb eines einzelnen Hostpools, oder sogar Benutzer*innen, die bei demselben Sitzungshost mit mehreren Sitzungen angemeldet sind, verschiedene Anwendungskombinationen erhalten können. Benutzer*innen, welche die Anforderungen nicht erfüllen, erhalten die Anwendung nicht.

So erhalten Benutzer*innen eine Anwendung

Sie können verschiedenen Benutzern*innen im selben Hostpool unterschiedliche Anwendungen zuweisen. Mit MSIX App Attach fügen Sie MSIX-Pakete zu einem Hostpool hinzu und steuern die Zuweisung von Anwendungen mithilfe von Desktop- oder RemoteApp-Anwendungsgruppen. Bei der Anmeldung müssen die folgenden Anforderungen erfüllt sein, damit Benutzer*innen die richtige Anwendung zum richtigen Zeitpunkt erhalten:

  • Benutzer*innen müssen sich bei Sitzungshosts im Hostpool anmelden können, daher müssen sie sich in einer Desktop- oder RemoteApp-Anwendungsgruppe befinden.

  • Das MSIX-Image muss dem Hostpool hinzugefügt werden.

Wenn diese Anforderungen erfüllt sind, erhalten die Benutzer*innen die Anwendung. Durch das Zuweisen von Anwendungen mithilfe einer Desktopanwendungsgruppe werden sie dem Startmenü der Benutzer*innen hinzugefügt. Benutzer*innen, welche die Anforderungen nicht erfüllen, erhalten die Anwendung nicht.

Anwendungsimages

Bevor Sie Ihre Anwendungspakete mit Azure Virtual Desktop verwenden können, müssen Sie mithilfe des MSIXMGR-Tools ein MSIX-Image aus Ihren vorhandenen Anwendungspaketen erstellen. Anschließend müssen Sie jedes Datenträgerimage auf einer Dateifreigabe speichern, auf die von Ihren Sitzungshosts zugegriffen werden kann. Weitere Informationen zu den Anforderungen für eine Dateifreigabe finden Sie unter Dateifreigabe.

Datenträgerimagetypen

Sie können Composite Image File System (CimFS), VHDX oder VHD für Datenträgerimages verwenden, die Verwendung von VHD wird jedoch nicht empfohlen. Das Einbinden und Aufheben der Einbindung von CimFS-Images ist schneller als VHD- und VHDX-Dateien und verbraucht auch weniger CPU und Arbeitsspeicher. Die Verwendung von CimFS für Ihre Anwendungsimages wird nur dann empfohlen, wenn Ihre Sitzungshosts Windows 11 ausführen.

Ein CimFS-Image ist eine Kombination aus mehreren Dateien: Eine Datei verfügt über die .cim-Dateierweiterung und enthält Metadaten, zusammen mit mindestens zwei anderen Dateien, eine beginnend mit objectid_ und die andere beginnend mit region_, welche die tatsächlichen Anwendungsdaten enthalten. Die Dateien, welche die .cim-Datei begleiten, verfügen nicht über eine Dateierweiterung. In der folgenden Tabelle finden Sie eine Liste mit Beispieldateien, die Sie für ein CimFS-Image finden könnten:

Dateiname Größe
MyApp.cim 1 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 27 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 20 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 42 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 428 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 217 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 264.132 KB

In der folgenden Tabelle finden Sie einen Leistungsvergleich zwischen VHDX und CimFS. Diese Zahlen waren das Ergebnis einer Testausführung mit jeweils 500 Dateien von je 300 MB pro Format, und die Tests wurden auf einer DSv4-Azure-VMdurchgeführt.

Metrik VHD CimFS
Durchschnittliche Einbindungszeit 356 ms 255 ms
Durchschnittliche Zeit zum Aufheben der Bereitstellung 1615 ms 36 ms
Arbeitsspeicherverbrauch 6 % (von 8 GB) 2 % (von 8 GB)
CPU (Zählerspitze) Mehrfaches Erreichen des Maximums Keine Auswirkungen

Anwendungsregistrierung

App Attach bindet Datenträgerimages, die Ihre Anwendungen enthalten, während der Anmeldung von einer Dateifreigabe in die Sitzung von Benutzer*innen ein, anschließend stellt ein Registrierungsprozess die Anwendungen den Benutzer*innen zur Verfügung. Es gibt zwei Möglichkeiten der Registrierung:

MSIX App Attach bindet Datenträgerimages, die Ihre Anwendungen enthalten, während der Anmeldung von einer Dateifreigabe in die Sitzung von Benutzer*innen ein, anschließend stellt ein Registrierungsprozess die Anwendungen den Benutzer*innen zur Verfügung. Es gibt zwei Möglichkeiten der Registrierung:

  • On-Demand: Anwendungen werden nur teilweise bei der Anmeldung registriert, und die vollständige Registrierung einer Anwendung wird zurückgestellt, bis Benutzer*innen die Anwendung starten. On-Demand ist der Registrierungstyp, den wir Ihnen empfehlen zu verwenden, da er sich nicht auf die Zeit auswirkt, die für die Anmeldung bei Azure Virtual Desktop benötigt wird. On-Demand ist die Standardregistrierungsmethode.

  • Anmeldeblockierung: Jede Anwendung, die Sie Benutzer*innen zuweisen, ist vollständig registriert. Die Registrierung erfolgt, während sich Benutzer*innen bei ihrer Sitzung anmeldet, was sich auf die Anmeldezeit bei Azure Virtual Desktop auswirken kann.

Wichtig

Alle MSIX-und Appx-Anwendungspakete enthalten ein Zertifikat. Sie müssen sicherstellen, dass die Zertifikate in Ihrer Umgebung vertrauenswürdig sind. Selbstsignierte Zertifikate werden mit der entsprechenden Vertrauenskette unterstützt.

App Attach beschränkt nicht die Anzahl der Anwendungen, die Benutzer*innen verwenden können. Sie sollten den verfügbaren Netzwerkdurchsatz und die Anzahl der geöffneten Handles pro Datei (jedes Image) berücksichtigen, die ihre Dateifreigabe unterstützt, da sie die Anzahl der Benutzer*innen oder Anwendungen einschränken kann, die Sie unterstützen können. Weitere Informationen finden Sie unter Dateifreigabe.

Wichtig

Alle MSIX-Anwendungspakete enthalten ein Zertifikat. Sie müssen sicherstellen, dass die Zertifikate in Ihrer Umgebung vertrauenswürdig sind. Selbstsignierte Zertifikate werden unterstützt.

MSIX App Attach beschränkt nicht die Anzahl der Anwendungen, die Benutzer*innen verwenden können. Sie sollten den verfügbaren Netzwerkdurchsatz und die Anzahl der geöffneten Handles pro Datei (jedes Image) berücksichtigen, die ihre Dateifreigabe unterstützt, da sie die Anzahl der Benutzer*innen oder Anwendungen einschränken kann, die Sie unterstützen können. Weitere Informationen finden Sie unter Dateifreigabe.

Status der Anwendung

Ein MSIX- und Appx-Paket wird als aktiv oder inaktiv festgelegt. Pakete, die auf aktiv festgelegt sind, machen die Anwendung für Benutzer*innen verfügbar. Pakete, die auf inaktiv festgelegt sind, werden von Azure Virtual Desktop ignoriert und nicht hinzugefügt, wenn sich Benutzer*innen anmelden.

Ein MSIX-Paket wird als aktiv oder inaktiv festgelegt. MSIX-Pakete, die auf aktiv festgelegt sind, machen die Anwendung für Benutzer*innen verfügbar. MSIX-Pakete, die auf inaktiv festgelegt sind, werden von Azure Virtual Desktop ignoriert und nicht hinzugefügt, wenn sich Benutzer*innen anmelden.

Neue Versionen von Anwendungen

Sie können eine neue Version einer Anwendung hinzufügen, indem Sie ein neues Image bereitstellen, das die aktualisierte Anwendung enthält. Sie können dieses neue Image auf zwei Arten verwenden:

  • Nebeneinander: Erstellen Sie eine neue Anwendung mit dem neuen Datenträgerimage, und weisen Sie diese den gleichen Hostpools und Benutzer*innen wie die vorhandene Anwendung zu.

  • In-Place: Erstellen Sie ein neues Image, bei dem sich die Versionsnummer der Anwendung ändert, und aktualisieren Sie dann die vorhandene Anwendung so, dass sie das neue Image verwendet. Die Versionsnummer kann höher oder tiefer sein, aber Sie können eine Anwendung nicht mit derselben Versionsnummer aktualisieren. Löschen Sie das vorhandene Image erst, wenn keine Benutzer*in es mehr verwendet.

Nach der Aktualisierung erhalten Benutzer*innen die aktualisierte Anwendungsversion bei der nächsten Anmeldung. Benutzer*innen müssen die Verwendung der vorherigen Version nicht anhalten, um eine neue Version hinzuzufügen.

Neue Versionen von Anwendungen

Mit MSIX App Attach müssen Sie das Anwendungspaket löschen, und dann erstellen Sie eine neue Anwendung mit dem neuen Datenträgerimage und weisen es denselben Hostpools zu. Sie können nicht In-Place aktualisieren, wie dies mit App Attach möglich ist. Benutzer*innen erhalten das neue Image mit der aktualisierten Anwendung bei der nächsten Anmeldung. Sie sollten diese Aufgaben während eines Wartungsfensters ausführen.

Identitätsanbieter

Hier sind die Identitätsanbieter, die Sie mit App Attach verwenden können:

Identitätsanbieter Status
Microsoft Entra ID Unterstützt
Active Directory Domain Services (AD DS) Unterstützt
Microsoft Entra Domain Services Nicht unterstützt

Hier sind die Identitätsanbieter, die Sie mit MSIX App Attach verwenden können:

Identitätsanbieter Status
Microsoft Entra ID Nicht unterstützt
Active Directory Domain Services (AD DS) Unterstützt
Microsoft Entra Domain Services (Azure AD DS) Nicht unterstützt

Dateifreigabe

App Attach erfordert, dass Ihre Anwendungsimages in einer SMB-Dateifreigabe gespeichert werden, die dann während der Anmeldung auf jedem Sitzungshost eingebunden wird. App Attach ist nicht von der Art der Speicherstruktur abhängig, welche die Dateifreigabe verwendet. Wir empfehlen die Verwendung von Azure Files, da es mit Microsoft Entra ID oder Active Directory Domain Services kompatibel ist und einen hohen Wert zwischen Kosten und Verwaltungsaufwand bietet.

Sie können auch Azure NetApp Files verwenden, aber dies erfordert, dass Ihre Sitzungshosts mit Active Directory Domain Services verknüpft werden.

MSIX App Attach erfordert, dass Ihre Anwendungsimages auf einer SMB Version 3-Dateifreigabe gespeichert werden, die dann während der Anmeldung auf jedem Sitzungshost eingebunden wird. Das MSIX-Feature zum Anfügen von Apps ist nicht vom Typ des von der Dateifreigabe verwendeten Speicherfabrics abhängig. Wir empfehlen die Verwendung von Azure Files, da es mit den unterstützten Identitätsanbietern kompatibel ist, die Sie für MSIX App Attach verwenden können, und es bietet einen hohen Wert zwischen Kosten und Verwaltungsaufwand. Sie können auch Azure NetApp Files verwenden, aber dies erfordert, dass Ihre Sitzungshosts mit Active Directory Domain Services verknüpft sind.

In den folgenden Abschnitten finden Sie einige Anleitungen zu Berechtigungen, Leistung und Verfügbarkeit, die für die Dateifreigabe erforderlich sind.

Berechtigungen

Jeder Sitzungshost bindet Anwendungsimages aus der Dateifreigabe ein. Sie müssen NTFS- und Freigabeberechtigungen konfigurieren, um jedem Computerobjekt im Sitzungshost Lesezugriff auf die Dateien und die Dateifreigabe zu ermöglichen. Wie Sie die richtige Berechtigung konfigurieren, hängt davon ab, welchen Speicheranbieter und welchen Identitätsanbieter Sie für Ihre Dateifreigabe und Sitzungshosts verwenden.

  • Um Azure Files zu verwenden, wenn Ihre Sitzungshosts mit Microsoft Entra ID verknüpft sind, müssen Sie die Azure-RBAC (rollenbasierte Zugriffssteuerung)-Rolle Leser und Datenzugriff den Dienstprinzipalen von Azure Virtual Desktop und Azure Virtual Desktop ARM-Anbieter zuweisen. Diese RBAC-Rollenzuweisung ermöglicht Ihren Sitzungshosts den Zugriff auf das Speicherkonto mithilfe von Zugriffsschlüsseln. Das Speicherkonto muss sich im gleichen Azure-Abonnement wie Ihre Sitzungshosts befinden. Informationen zum Zuweisen einer Azure RBAC-Rolle zu Azure Virtual Desktop-Dienstprinzipalen finden Sie unter Zuweisen von RBAC-Rollen zu den Azure Virtual Desktop-Dienstprinzipalen.

    Weitere Informationen zur Verwendung von Azure Files mit Sitzungshosts, die mit Microsoft Entra ID, Active Directory Domain Services oder Microsoft Entra Domain Services verknüpft sind, finden Sie unter Übersicht über identitätsbasierte Azure Files-Authentifizierungsoptionen für den SMB-Zugriff.

    Warnung

    Das Zuweisen des Azure Virtual Desktop ARM-Anbieter-Dienstprinzipals zum Speicherkonto gewährt dem Azure Virtual Desktop-Dienst Zugriff auf alle Daten innerhalb des Speicherkontos. Es wird empfohlen, nur Apps für die Verwendung mit App Attach in diesem Speicherkonto zu speichern und die Zugriffsschlüssel regelmäßig zu drehen.

  • Für Azure NetApp Files können Sie ein SMB-Volume erstellen und NTFS-Berechtigungen konfigurieren, um Lesezugriff auf das Computerobjekt jedes Sitzungshosts zu gewähren. Ihre Sitzungshosts müssen mit Active Directory Domain Services oder Microsoft Entra Domain Services verknüpft sein.

Sie können überprüfen, ob die Berechtigungen korrekt sind, indem Sie PsExec verwenden. Weitere Informationen finden Sie unter Überprüfen des Dateifreigabezugriffs.

Leistung

Die Anforderungen können stark variieren, je nachdem, wie viele paketierte Anwendungen in einem Image gespeichert sind, und Sie müssen Ihre Anwendungen testen, um Ihre Anforderungen zu verstehen. Für größere Images müssen Sie mehr Bandbreite zuordnen. Die folgende Tabelle enthält ein Beispiel für die Anforderungen, dass ein einzelnes 1 GB MSIX-Image, das eine Anwendung enthält, pro Sitzungshost Folgendes erfordert:

Ressource Anforderungen
IOPS im stabilen Zustand Ein IOP
Anmeldung beim Starten des Computers 10 IOPs
Latency 400 ms

Um die Leistung Ihrer Anwendungen zu optimieren, empfehlen wir Folgendes:

  • Ihre Dateifreigabe sollte sich in derselben Azure-Region wie Ihre Sitzungshosts befinden. Wenn Sie Azure Files verwenden, muss sich Ihr Speicherkonto in derselben Azure-Region wie Ihre Sitzungshosts befinden.

  • Schließen Sie die Datenträgerimages, die Ihre Anwendungen enthalten, aus Antivirenscans aus, da sie schreibgeschützt sind.

  • Stellen Sie sicher, dass Ihre Speicher- und Netzwerkstruktur eine angemessene Leistung bieten kann. Sie sollten vermeiden, dieselbe Dateifreigabe mit FSLogix-Profilcontainern zu verwenden.

Verfügbarkeit

Alle Pläne zur Notfallwiederherstellung für Azure Virtual Desktop müssen das Replizieren der MSIX App Attach-Dateifreigabe an Ihren sekundären Failoverspeicherort beinhalten. Sie müssen ebenfalls sicherstellen, dass auf Ihren Dateifreigabepfad am sekundären Speicherort zugegriffen werden kann. Sie können beispielsweise Namespaces für verteiltes Dateisystem (Distributed File System, DFS) mit Azure Files verwenden, um einen einzelnen Freigabenamen für unterschiedliche Dateifreigaben bereitzustellen. Weitere Informationen zur Notfallwiederherstellung für Azure Virtual Desktop finden Sie unter Einrichten eines Plans für Business Continuity & Disaster Recovery.

Azure Files

Azure Files hat Beschränkungen für die Anzahl der geöffneten Handles pro Stammverzeichnis, Verzeichnis und Datei. Bei Verwendung von MSIX App Attach oder App Attach werden VHDX- oder CimFS-Datenträgerimages mithilfe des Computerkontos des Sitzungshosts bereitgestellt, d. h. ein Handle wird pro Sitzungshost pro Datenträgerimage und nicht pro Benutzer*in geöffnet. Weitere Informationen zu den Grenzwerten und Anleitungen zur Dimensionierung finden Sie unter Azure Files – Skalierbarkeit und Leistungsziele und Azure Files – Richtlinien für die Dimensionierung für Azure Virtual Desktop.

MSIX- und Appx-Paketzertifikate

Für alle MSIX- und Appx-Pakete ist ein gültiges Codesignaturzertifikat erforderlich. Um diese Pakete mit App Attach zu verwenden, müssen Sie sicherstellen, dass die gesamte Zertifikatkette auf Ihren Sitzungshosts vertrauenswürdig ist. Ein Codesignaturzertifikat weist den Objektbezeichner 1.3.6.1.5.5.7.3.3 auf. Sie können ein Codesignaturzertifikat für Ihre Pakete von folgenden Stellen erhalten:

  • Einer öffentlichen Zertifizierungsstelle (ZS).

  • Einer internen Unternehmens- oder eigenständige Zertifizierungsstelle, z. B. Active Directory-Zertifikatdienste. Sie müssen das Codesignaturzertifikat, einschließlich seines privaten Schlüssels, exportieren.

  • Einem Tool wie das PowerShell-Cmdlet New-SelfSignedCertificate, das ein selbstsigniertes Zertifikat generiert. Sie sollten selbstsignierte Zertifikate nur in einer Testumgebung verwenden. Weitere Informationen zum Erstellen eines selbstsignierten Zertifikats für MSIX- und Appx-Pakete finden Sie unter Erstellen eines Zertifikats für die Paketsignierung.

Nachdem Sie ein Zertifikat erhalten haben, müssen Sie Ihre MSIX- oder Appx-Pakete digital mit dem Zertifikat signieren. Sie können das MSIX-Pakettool verwenden, um Ihre Pakete zu signieren, wenn Sie ein MSIX-Paket erstellen. Weitere Informationen finden Sie unter Erstellen eines MSIX-Pakets mit einem Desktopinstallationsprogramm.

Um sicherzustellen, dass das Zertifikat auf Ihren Sitzungshosts vertrauenswürdig ist, müssen Ihre Sitzungshosts der gesamten Zertifikatkette vertrauen. Wie Sie dies erreichen, hängt davon ab, wo Sie das Zertifikat erhalten haben und wie Sie Ihre Sitzungshosts und den von Ihnen verwendeten Identitätsanbieter verwalten. Die folgende Tabelle enthält einige Anleitungen, um sicherzustellen, dass das Zertifikat auf Ihren Sitzungshosts vertrauenswürdig ist:

  • Öffentliche ZS: Zertifikate einer öffentlichen ZS sind in Windows und Windows Server standardmäßig vertrauenswürdig.

  • Interne Unternehmens-ZS:

    • Für Sitzungshosts, die mit Active Directory verbunden sind und die mit AD CS als interne Unternehmens-ZS konfiguriert sind, sind sie standardmäßig vertrauenswürdig und im Konfigurationsbenennungskontext von Active Directory Domain Services gespeichert. Wenn AD CS als eigenständige Zertifizierungsstelle konfiguriert ist, müssen Sie die Gruppenrichtlinie so konfigurieren, dass die Stamm- und Zwischenzertifikate an Sitzungshosts verteilt werden. Weitere Informationen finden Sie unter Verteilen von Zertifikaten an Windows-Geräte mithilfe von Gruppenrichtlinien.

    • Für Sitzungshosts, die mit Microsoft Entra ID verbunden sind, können Sie Microsoft Intune verwenden, um die Stamm- und Zwischenzertifikate an Sitzungshosts zu verteilen. Weitere Informationen finden Sie unter Vertrauenswürdige Stammzertifikatprofile für Microsoft Intune.

    • Für Sitzungshosts, die die Microsoft Entra-Hybridverbindung verwenden, können Sie je nach Ihren Anforderungen eine der vorherigen Methoden verwenden.

  • Selbstsigniert: Installieren Sie den vertrauenswürdigen Stamm im Speicher Vertrauenswürdige Stammzertifizierungsstellen auf jedem Sitzungshost. Es wird davon abgeraten, dieses Zertifikat mithilfe von Gruppenrichtlinien oder Intune zu verteilen, da es nur für Tests verwendet werden sollte.

Wichtig

Sie sollten Ihr Paket mit einem Zeitstempel versehen, damit die Gültigkeit des Zertifikats das Ablaufdatum des Zertifikats überdauern kann. Andernfalls müssen Sie das Paket nach Ablauf des Zertifikats mit einem neuen gültigen Zertifikat aktualisieren und erneut sicherstellen, dass es auf Ihren Sitzungshosts vertrauenswürdig ist.

Nächste Schritte

Erfahren Sie, wie Sie App Attach-Anwendungen in Azure Virtual Desktop hinzufügen und verwalten.