App Attach in Azure Virtual Desktop

Mit App Attach können Sie Anwendungen aus einem Anwendungspaket dynamisch an eine Benutzersitzung in Azure Virtual Desktop anfügen. Anwendungen werden nicht lokal auf Sitzungshosts oder Images installiert, was das Erstellen benutzerdefinierter Images für Ihre Sitzungshosts erleichtert und den Betriebsaufwand und die Kosten für Ihre Organization reduziert. Anwendungen werden in Containern ausgeführt, die Benutzerdaten, das Betriebssystem und andere Anwendungen voneinander trennen, was die Sicherheit erhöht und die Problembehandlung vereinfacht.

Hier sind einige der wichtigsten Vorteile von App Attach:

Anwendungen werden mithilfe von RemoteApp oder als Teil einer Desktopsitzung bereitgestellt. Berechtigungen werden pro Anwendung und Benutzer angewendet, so dass Sie eine bessere Kontrolle darüber haben, auf welche Anwendungen Ihre Benutzer in einer Remotesitzung zugreifen können. Desktopbenutzern werden nur die ihnen zugewiesenen Anwendungen zum Anfügen der App angezeigt.
Ein und dasselbe Anwendungspaket kann in mehreren Hostpools verwendet werden.
Anwendungen können auf jedem Sitzungshost ausgeführt werden, auf dem ein Windows-Client oder ein unterstütztes Windows Server-Betriebssystem in derselben Azure-Region wie das Anwendungspaket ausgeführt wird.
Anwendungen können auf eine neue Anwendungsversion mit einem neuen Datenträgerimage aktualisiert werden, ohne dass ein Wartungsfenster erforderlich ist.
Benutzer können mehrere Versionen derselben Anwendung gleichzeitig auf demselben Sitzungshost ausführen.
Telemetriedaten für Nutzung und Integrität sind über Azure Log Analytics verfügbar.

Sie können die folgenden Anwendungspakettypen und Dateiformate verwenden:

Pakettyp	Dateiformate
MSIX und MSIX-Bundle	`.msix` `.msixbundle`
Appx und Appx-Bundle	`.appx` `.appxbundle`
App-V	`.appv`

MSIX und Appx sind Windows-Anwendungspaketformate, die Windows-Anwendungen eine moderne Paketererfahrung bieten. Anwendungen werden in Containern ausgeführt, die Benutzerdaten, das Betriebssystem und andere Anwendungen voneinander trennen, was die Sicherheit erhöht und die Problembehandlung vereinfacht. 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.

Microsoft Application Virtualization (App-V) für Windows stellt Benutzern Win32-Anwendungen als virtuelle Anwendungen bereit. Virtuelle Anwendungen sind auf zentral verwalteten Servern installiert und werden den Benutzern als Dienst in Echtzeit und bei Bedarf bereitgestellt. Benutzer starten virtuelle Anwendungen über bekannte Zugriffspunkte und interagieren mit ihnen wie mit lokal installierten Anwendungen.

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

So erhält ein Benutzer eine Anwendung

Sie können verschiedenen Benutzern im selben Hostpool oder auf demselben Sitzungshost unterschiedliche Anwendungen zuweisen. Während der Anmeldung müssen alle drei folgenden Anforderungen erfüllt sein, damit der Benutzer die richtige Anwendung zur richtigen Zeit erhält:

Die Anwendung muss dem Hostpool zugewiesen werden. Durch das Zuweisen der Anwendung zum Hostpool können Sie selektiv festlegen, in welchen Hostpools die Anwendung verfügbar ist, um sicherzustellen, dass die richtigen Hardwareressourcen für die Anwendung verfügbar sind. Wenn eine Anwendung beispielsweise grafikintensiv ist, können Sie sicherstellen, dass sie nur in einem Hostpool mit GPU-optimierten Sitzungshosts ausgeführt wird.
Der Benutzer muss sich bei Sitzungshosts im Hostpool anmelden können, d. h. er muss sich in einer Desktop- oder RemoteApp-Anwendungsgruppe befinden. Für eine RemoteApp-Anwendungsgruppe muss die App Attach-Anwendung der Anwendungsgruppe hinzugefügt werden, Sie müssen die Anwendung jedoch nicht zu einer Desktopanwendungsgruppe hinzufügen.
Die Anwendung muss dem Benutzer zugewiesen werden. Sie können ein Gruppen- oder ein Benutzerkonto verwenden.

Sind alle diese Voraussetzungen erfüllt, erhält der Benutzer die Anwendung. Dieser Prozess ermöglicht die Kontrolle darüber, wer eine Anwendung auf welchem Hostpool erhält und wie es Benutzern innerhalb eines einzelnen Hostpools oder sogar der Anmeldung beim selben Host mit mehreren Sitzungen möglich ist, unterschiedliche Anwendungskombinationen zu erhalten. Benutzer, die die Anforderungen nicht erfüllen, erhalten die Bewerbung nicht.

Anwendungsimages

Bevor Sie MSIX-Anwendungspakete mit Azure Virtual Desktop verwenden können, müssen Sie ein MSIX-Image aus Ihren vorhandenen Anwendungspaketen erstellen. Alternativ können Sie stattdessen ein App-V-Paket verwenden. Anschließend müssen Sie jedes MSIX-Image oder App-V-Paket auf einer Dateifreigabe speichern, auf die Ihre Sitzungshosts zugreifen können. Weitere Informationen zu den Anforderungen für eine Dateifreigabe finden Sie unter Dateifreigabe.

Typen von Datenträgerimages

Für MSIX- und Appx-Datenträgerimages können Sie das Composite Image File System (CimFS),VHDX oder VHD verwenden, die Verwendung von VHD wird jedoch nicht empfohlen. Das Ein- und Aushängen von CimFS-Images ist schneller als VHD- und VHDX-Images und verbraucht auch weniger CPU und Arbeitsspeicher. Wir empfehlen die Verwendung von CimFS für Ihre Anwendungsimages nur, wenn auf Ihren Sitzungshosts Windows 11 ausgeführt wird.

Ein CimFS-Image ist eine Kombination aus mehreren Dateien: Eine Datei hat die .cim Dateierweiterung und enthält Metadaten sowie mindestens zwei weitere Dateien, von denen eine mit objectid_ und die andere mit region_ den eigentlichen Anwendungsdaten beginnt. Die Dateien .cim haben keine Dateierweiterung. Die folgende Tabelle ist eine Liste der Beispieldateien, die Sie für ein CimFS-Image finden würden:

Dateiname	Size
`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

Die folgende Tabelle enthält einen Leistungsvergleich zwischen VHDX und CimFS. Diese Zahlen waren das Ergebnis eines Testlaufs mit 500 Dateien à 300 MB pro Format, und die Tests wurden auf einem virtuellen DSv4 Azure-Computer durchgeführt.

Metrik	VHD	CimFS
Durchschnittliche Bereitstellungszeit	356 ms	255 ms
Durchschnittliche Zeit zum Aufheben der Bereitstellung	1615 ms	36 ms
Arbeitsspeicherbelegung	6 % (von 8 GB)	2 % (von 8 GB)
CPU (Anzahlspitze)	Mehrfaches Ausreizen	Kein Effekt

Anwendungsregistrierung

App Attach bindet Datenträgerimages oder App-V-Pakete, die Ihre Anwendungen aus einer Dateifreigabe enthalten, während der Anmeldung in die Sitzung eines Benutzers ein, und ein Registrierungsprozess stellt die Anwendungen dann dem Benutzer zur Verfügung. Es gibt zwei Arten von Registrierungen:

On-Demand: Anwendungen werden bei der Anmeldung nur teilweise registriert, und die vollständige Registrierung einer Anwendung wird verschoben, bis der Benutzer die Anwendung startet. On-Demand ist der Registrierungstyp, den wir empfehlen, da er sich nicht auf die Anmeldezeit bei Azure Virtual Desktop auswirkt. On-Demand ist die Standardregistrierungsmethode.
Blockieren von Anmeldungen: Jede Anwendung, die Sie einem Benutzer zuweisen, ist vollständig registriert. Die Registrierung erfolgt, während sich der Benutzer bei seiner Sitzung anmeldet. Dies kann sich auf die Anmeldezeit bei Azure Virtual Desktop auswirken.

Wichtig

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

Durch App-Anlagen wird die Anzahl der Anwendungen, die Benutzer verwenden können, nicht eingeschränkt. Sie sollten den verfügbaren Netzwerkdurchsatz und die Anzahl der geöffneten Handles pro Datei (jedes Bild) berücksichtigen, die von Ihrer Dateifreigabe unterstützt werden, da dies die Anzahl der Benutzer oder Anwendungen einschränken kann, die Sie unterstützen können. Weitere Informationen finden Sie unter Dateifreigabe.

Anwendungszustand

Anwendungspakete werden als aktiv oder inaktiv festgelegt. Pakete, die auf "active" festgelegt sind, stellen die Anwendung Benutzern zur Verfügung. Azure Virtual Desktop ignoriert Pakete, die auf inaktiv festgelegt sind und nicht hinzugefügt werden, wenn sich ein Benutzer anmeldet.

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 Bild auf zwei Arten verwenden:

Nebeneinander: Erstellen Sie eine neue Anwendung mit dem neuen Datenträgerimage und weisen Sie sie denselben Hostpools und Benutzern wie die vorhandene Anwendung zu.
Direkt: Erstellen Sie ein neues Image, wenn sich die Versionsnummer der Anwendung ändert, und aktualisieren Sie dann die vorhandene Anwendung, um das neue Image zu verwenden. Die Versionsnummer kann höher oder niedriger sein, aber Sie können keine Anwendung mit derselben Versionsnummer aktualisieren. Löschen Sie das vorhandene Bild erst, wenn alle Benutzer es nicht mehr verwenden.

Nach der Aktualisierung erhalten Benutzer bei der nächsten Anmeldung die aktualisierte Anwendungsversion. Benutzer brauchen die Verwendung der vorherigen Version nicht zu beenden, um eine neue Version hinzuzufügen.

Identitätsanbieter

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

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

App Attach erfordert, dass Ihre Anwendungsimages auf einer SMB-Dateifreigabe gespeichert werden, die dann während der Anmeldung auf jedem Sitzungshost bereitgestellt wird. App Attach weist keine Abhängigkeiten von dem Typ der Speicher-Fabric auf, die die Dateifreigabe verwendet. Wir empfehlen die Verwendung von Azure Files, da es mit Microsoft Entra ID oder Active Directory Domain Services kompatibel ist und ein hervorragendes Preis-Leistungs-Verhältnis zwischen Kosten und Verwaltungsaufwand bietet.

Sie können auch Azure NetApp Files verwenden, aber das setzt voraus, dass Ihre Sitzungshosts mit Active Directory Domain Services verbunden sind.

In den folgenden Abschnitten finden Sie einige Anleitungen zu den Berechtigungen, der Leistung und der 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 Objekt des Sitzungshostcomputers Lesezugriff auf die Dateien und Dateifreigaben zu gewähren. Wie Sie die richtige Berechtigung konfigurieren, hängt davon ab, welchen Speicher- und Identitätsanbieter Sie für Ihre Dateifreigabe und Sitzungshosts verwenden.

Um Azure Files zu verwenden, wenn Ihre Sitzungshosts Microsoft Entra ID beitreten, müssen Sie die Rolle Leseberechtigung und Datenzugriff Azure rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) sowohl den Dienstprinzipalen Azure Virtual Desktop als auch Azure Virtual Desktop ARM-Anbieter zuweisen. Diese RBAC-Rollenzuweisung ermöglicht Ihren Sitzungshosts den Zugriff auf das Speicherkonto mithilfe von Zugriffsschlüsseln oder Microsoft Entra.
Informationen zum Zuweisen einer Azure RBAC-Rolle zu den Dienstprinzipalen von Azure Virtual Desktop finden Sie unter Zuweisen von RBAC-Rollen zu den Dienstprinzipalen von Azure Virtual Desktop. In einem zukünftigen Update müssen Sie den Dienstprinzipal des Azure Virtual Desktop-ARM-Anbieters nicht mehr zuweisen.

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 Azure Files Identitätsbasierte Authentifizierungsoptionen für den SMB-Zugriff.

Warnung

Durch das Zuweisen des Dienstprinzipals des Azure Virtual Desktop-ARM-Anbieters zum Speicherkonto wird der Azure Virtual Desktop-Dienst für alle Daten im Speicherkonto gewährt. Es wird empfohlen, nur Apps zur Verwendung mit App Attach in diesem Speicherkonto zu speichern und die Zugriffsschlüssel regelmäßig zu rotieren.
Für Azure Files mit Active Directory Domain Services müssen Sie der SMB-Freigabeleser für Speicherdateidaten Azure rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) als Standardberechtigung auf Freigabeebene zuweisen und NTFS-Berechtigungen so konfigurieren, dass Lesezugriff auf die Computerobjekte der einzelnen Sitzungshosts gewährt wird.

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 Azure Files Identitätsbasierte Authentifizierungsoptionen für den SMB-Zugriff.
Für Azure NetApp Files können Sie ein SMB-Volume erstellen und NTFS-Berechtigungen konfigurieren, um Lesezugriff auf die Computerobjekte jedes Sitzungshosts zu gewähren. Ihre Sitzungshosts müssen mit Active Directory Domain Services oder Microsoft Entra Domain Services verbunden sein.

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

Benutzer- und Bereitstellungskonfigurations-Files

Für App-V-Pakete, die über App Attach bereitgestellt werden, können Sie dynamische App-V-Konfigurationsdateien verwenden, um das Anwendungsverhalten anzupassen. App Attach erkennt automatisch Standardkonfigurationsdateien, die der erwarteten Namenskonvention entsprechen. Wenn sie sich im selben Ordner wie das App Attach-Paket befinden und dem XML-Code der Name der App-V-Datei vorangestellt ist, werden diese Dateien während der Verarbeitung automatisch mit dem Anwendungspaket verknüpft. Wenn der Dateipfad \share\folder\filename.appv lautet, werden die folgenden Beispiele automatisch erkannt und mit dem Paket verwendet.

\share\folder\filename_UserConfig.xml
\share\folder\filename_DeploymentConfig.xml

$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

$dependencyType = $a.GetType().Assembly.GetTypes() |
    Where-Object {
        $_.Name -eq 'MsixPackageDependencies' -and
        $_.Namespace -like '*DesktopVirtualization*'
    } |
    Select-Object -First 1

$newDependency = [System.Activator]::CreateInstance($dependencyType)
$newDependency.DependencyName = "FilePathToUserConfig"
$newDependency.Publisher = "Group Object Id"
$newDependency.MinVersion = 1
$dependencyList = $a.ImagePackageDependency
$dependencyList += $newDependency
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

# Remove logic
$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage
$dependencyList = $a.ImagePackageDependency
$dependencyList  = $dependencyList | where-Object {$_.DependencyName -ne "FilePathToUserConfig"}
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

Benutzerkonfigurationsdateien werden auf Benutzerebene ausgewertet, sodass unterschiedliche Benutzer unterschiedliche Anwendungseinstellungen erhalten können. Bereitstellungskonfigurationsdateien hingegen werden auf Computerebene angewendet und von allen Benutzern auf dem Sitzungshost gemeinsam genutzt. Derzeit wird die Benutzerkonfiguration nur für Desktopverbindungen und nicht für Remote-App-Verbindungen unterstützt.

Erweiterte Szenarien erfordern möglicherweise mehrere Benutzerkonfigurationsdateien für dieselbe Anwendung. In diesen Fällen müssen die zusätzlichen Benutzerkonfigurationsdateien dem Anwendungspaket mithilfe von PowerShell explizit zugeordnet werden.

App-Anlage prüft das Abhängigkeitsobjekt

Im Feld DependencyName ist ein Dateipfad angegeben, der mit UserConfig.xml endet
Enthält ein Herausgeberfeld, das die Microsoft Entra-Sicherheitsgruppe identifiziert, die diese Konfiguration erhalten soll. Der Wert des Felds Publisher des App-Pakets muss auf die Objekt-ID der Zielsicherheitsgruppe festgelegt sein.

Während der Anmeldung wertet App Attach die Gruppenmitgliedschaften des Benutzers aus und wendet die entsprechende Benutzerkonfiguration basierend auf der zugeordneten Gruppe an.

Administratoren sollten nur dann mehrere Benutzerkonfigurationsdateien verwenden, wenn unterschiedliche Benutzerpopulationen unterschiedliche Anwendungseinstellungen erfordern. Standardbereitstellungen können sich weiterhin auf die automatisch erkannte Einzelbenutzerkonfigurationsdatei stützen.

Leistung

Die Anforderungen können stark variieren, je nachdem, wie viele Anwendungspakete in einem Image gespeichert sind, und Sie müssen Ihre Anwendungen testen, um Ihre Anforderungen zu verstehen. Für größere Bilder müssen Sie mehr Bandbreite zuweisen. Die folgende Tabelle enthält ein Beispiel für die Anforderungen, die für ein einzelnes 1-GB-Image oder App-V-Paket mit einer Anwendung pro Sitzungshost erforderlich sind:

Ressource	Anforderungen
Steady state IOPs	Ein IOP
Anmeldung beim Computerstart	10 IOPS
Latency	400 ms

Um die Leistung Ihrer Anwendungen zu optimieren, wird Folgendes empfohlen:

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 Disk-Images, die Ihre Anwendungen enthalten, von Antivirenscans aus, da sie schreibgeschützt sind.
Stellen Sie sicher, dass Ihre Speicher- und Netzwerkfabric eine angemessene Leistung bereitstellen können. Sie sollten es vermeiden, dieselbe Dateifreigabe mit FSLogix-Profilcontainern zu verwenden.

Verfügbarkeit

Alle Notfallwiederherstellungspläne für Azure Virtual Desktop müssen das Replizieren der Dateifreigabe an Ihren sekundären Failoverspeicherort umfassen. Außerdem müssen Sie sicherstellen, dass am sekundären Speicherort auf den Pfad der Dateifreigabe zugegriffen werden kann. Sie können beispielsweise DFS-Namespaces (Distributed File System, DFS) mit Azure Files verwenden, um einen einzigen Freigabenamen für verschiedene Dateifreigaben bereitzustellen. Weitere Informationen zur Notfallwiederherstellung für Azure Virtual Desktop finden Sie unter Einrichten eines Plans für Geschäftskontinuität und Notfallwiederherstellung.

Azure Files

Für Azure Files gilt eine Beschränkung hinsichtlich der Anzahl der geöffneten Handles pro Stammverzeichnis, Verzeichnis und Datei. VHDX- oder CimFS-Disk-Images werden mit dem Computerkonto des Sitzungshosts gemountet, d. h. ein Handle wird pro Sitzungshost pro Disk-Image und nicht pro Benutzer geöffnet. Weitere Informationen zu den Grenzwerten und Größenempfehlungen finden Sie unter Skalierbarkeits- und Leistungsziele für Azure Files und Azure Files Größenleitfaden für Azure Virtual Desktop.

MSIX- und Appx-Paketzertifikate

Alle MSIX- und Appx-Pakete erfordern ein gültiges Codesignaturzertifikat. Um diese Pakete mit App Attach zu verwenden, müssen Sie sicherstellen, dass die gesamte Zertifikatskette auf Ihren Sitzungshosts vertrauenswürdig ist. Ein Codesignaturzertifikat verfügt über den Objektbezeichner 1.3.6.1.5.5.7.3.3. Sie können ein Codesignaturzertifikat für Ihre Pakete erhalten von:

Eine öffentliche Zertifizierungsstelle.
Eine interne Unternehmens- oder eigenständige Zertifizierungsstelle, z. B. Active Directory-Zertifikatdienste. Sie müssen das Codesignaturzertifikat einschließlich des privaten Schlüssels exportieren.
Ein 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 mit dem Zertifikat digital signieren. Sie können das MSIX Packaging Tool verwenden, um Ihre Pakete zu signieren, wenn Sie ein MSIX-Paket erstellen. Weitere Informationen finden Sie unter Erstellen eines MSIX-Pakets über ein beliebiges Desktopinstallationsprogramm.

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

Öffentliche Zertifizierungsstelle: Zertifikate von einer öffentlichen Zertifizierungsstelle werden in Windows und Windows Server standardmäßig als vertrauenswürdig eingestuft.
Interne Unternehmenszertifizierungsstelle:
- Für Sitzungshosts, die mit Active Directory verbunden sind und für die AD CS als interne Unternehmenszertifizierungsstelle konfiguriert ist, werden standardmäßig als vertrauenswürdig eingestuft und im Konfigurationsnamenskontext von Active Directory Domain Services gespeichert. Wenn AD CS als eigenständige Zertifizierungsstelle konfiguriert ist, müssen Sie die Gruppenrichtlinie konfigurieren, um die Stamm- und Zwischenzertifikate an Sitzungshosts zu verteilen. Weitere Informationen finden Sie unter Verteilen von Zertifikaten auf Windows-Geräten 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 Profile für vertrauenswürdige Stammzertifikate für Microsoft Intune.
- Für Sitzungshosts, die Microsoft Entra Hybrid Join verwenden, können Sie je nach Ihren Anforderungen eine der oben beschriebenen Methoden verwenden.
Selbstsigniert: Installieren Sie den vertrauenswürdigen Stamm im Speicher der vertrauenswürdigen Stammzertifizierungsstellen auf jedem Sitzungshost. Es wird nicht empfohlen, dieses Zertifikat mithilfe von Gruppenrichtlinien oder Intune zu verteilen, da es nur zu Testzwecken verwendet werden sollte.

Wichtig

Sie sollten Ihr Paket mit einem Zeitstempel versehen, damit seine Gültigkeit das Ablaufdatum Ihres Zertifikats überdauern kann. Andernfalls müssen Sie nach Ablauf des Zertifikats das Paket mit einem neuen gültigen Zertifikat aktualisieren und erneut sicherstellen, dass Sitzungshosts der Zertifikatskette vertrauen.

Nächste Schritte

Erfahren Sie, wie Sie Anwendungen zum Anfügen von Apps in Azure Virtual Desktop hinzufügen und verwalten.

Feedback

War diese Seite hilfreich?

Last updated on 2026-08-26