Azure Virtual Desktop

Anwendungen liefern: im Abbild, angehängt oder veröffentlicht

VHD braucht zum Aushängen eines Anwendungsabbilds 1615 Millisekunden, CimFS 36 — ein Faktor von rund 45, gemessen in einem dokumentierten Testlauf. Ausgehängt wird beim Abmelden, also zu der Tageszeit, zu der es alle gleichzeitig tun. Dieses Modul behandelt, wie eine Anwendung überhaupt zum Nutzer kommt: warum RemoteApp kein Lieferweg ist, sondern eine Darstellungsform; welche drei Bedingungen erfüllt sein müssen, damit ein Nutzer eine dynamisch angehängte Anwendung erhält; warum eine Aktualisierung an Ort und Stelle eine geänderte Versionsnummer braucht und auch eine niedrigere akzeptiert; warum ein Dienstprinzipal für App Attach Zugriff auf alle Daten des Speicherkontos bekommt — und warum ein fehlender Zeitstempel am Paket Arbeit erzeugt, sobald das Signaturzertifikat abläuft.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-13

Drei Wege, eine Anwendung

Jede Anwendung in einer Sitzungsplattform braucht eine Entscheidung darüber, wie sie zum Nutzer kommt. Die Wahl bestimmt, wer bei einer Aktualisierung betroffen ist, wie schnell ein Fehler zurückgenommen werden kann und wie oft das Abbild angefasst werden muss.

Fest im Abbild
Die Anwendung ist Teil des Betriebssystemabbilds. Jede Änderung erfordert eine neue Abbildversion und einen vollständigen Erneuerungslauf.
Dynamisch angehängt
Die Anwendung liegt als Paket auf einer Dateifreigabe und wird der Sitzung bei der Anmeldung zugeordnet — auf dem Host ist sie gar nicht installiert.
Veröffentlicht
Kein Lieferweg, sondern eine Darstellungsform: Die Anwendung erscheint als einzelne Ressource statt innerhalb eines Desktops.
LernzielDu kannst für eine Anwendung den passenden Lieferweg begründen, die drei Bedingungen nennen, unter denen ein Nutzer eine dynamisch angehängte Anwendung erhält, und die Folgen der Abbildformate für Anmeldung und Abmeldung benennen.
Die Verwechslung, die alles verstelltRemoteApp ist kein dritter Lieferweg. Eine veröffentlichte Anwendung kann fest im Abbild stecken oder dynamisch angehängt sein — die Veröffentlichung entscheidet nur, ob der Nutzer sie als einzelne Ressource oder im Desktop sieht. Wer beides vermischt, diskutiert Darstellung, wenn es um Bereitstellung geht.

Was App Attach leistet

App Attach hängt Anwendungen aus einem Anwendungspaket dynamisch an eine Sitzung an. Die Anwendungen werden nicht lokal auf Session Hosts oder im Abbild installiert; sie laufen in Containern, die Nutzerdaten, Betriebssystem und andere Anwendungen voneinander trennen.

  • Berechtigungen wirken je Anwendung und je Nutzer — Desktopnutzer sehen nur die ihnen zugewiesenen Anwendungen.
  • Dasselbe Paket lässt sich über mehrere Host Pools hinweg verwenden.
  • Eine neue Version kann ohne Wartungsfenster eingeführt werden.
  • Mehrere Versionen derselben Anwendung dürfen auf demselben Session Host gleichzeitig laufen.
  • Die Anwendung läuft auf jedem Session Host in derselben Azure-Region wie das Anwendungspaket.

PaketformateApp Attach nimmt MSIX (.msix) und MSIX-Bundles (.msixbundle), Appx (.appx) und Appx-Bundles (.appxbundle) sowie App-V-Pakete (.appv). MSIX ist dabei eine Obermenge von Appx, erweitert um Funktionen für den Unternehmenseinsatz.

Der betriebliche Gewinn ist die Entkopplung: Ein Abbild, das keine Fachanwendungen mehr trägt, ändert sich seltener. Statt eines Erneuerungslaufs für jede Anwendungsaktualisierung wird nur noch ein Paket ausgetauscht.

Abbildformate — und eine Zahl, die überrascht

Vor der Nutzung wird aus dem Paket ein Abbild erzeugt, das auf einer Dateifreigabe liegt. Für MSIX- und Appx-Abbilder stehen drei Formate zur Wahl: CimFS, VHDX und VHD — wobei die Dokumentation von VHD abrät.

Einbinden
VHD 356 ms, CimFS 255 ms.
Aushängen
VHD 1615 ms, CimFS 36 ms.
Speicherbedarf
VHD 6 Prozent von 8 GB, CimFS 2 Prozent.
Prozessorlast
VHD mehrfach am Anschlag, CimFS ohne erkennbare Wirkung.
Der Faktor 45 beim AushängenDie Messwerte stammen aus einem dokumentierten Testlauf mit 500 Dateien zu je 300 MB je Format. Der Unterschied beim Einbinden ist spürbar, der beim Aushängen ist ein Faktor von rund 45 — und das Aushängen passiert beim Abmelden, also zu der Tageszeit, zu der es alle gleichzeitig tun. Die Empfehlung hat eine Bedingung: CimFS wird für Anwendungsabbilder nur empfohlen, wenn die Session Hosts Windows 11 ausführen.

Ein CimFS-Abbild ist keine einzelne Datei, sondern eine Gruppe: eine Datei mit der Endung .cim enthält die Metadaten, dazu kommen mindestens zwei weitere Dateien ohne Endung, deren Namen mit objectid_ und region_ beginnen und die eigentlichen Anwendungsdaten tragen. Wer beim Kopieren nur die .cim-Datei mitnimmt, hat nichts kopiert.

Drei Bedingungen, sonst kommt nichts an

Anwendung dem Host Pool zugewiesenNutzer in einer Desktop- oder RemoteApp-AnwendungsgruppeAnwendung dem Nutzer zugewiesen
Alle drei, sonst keine Anwendung

Damit ein Nutzer bei der Anmeldung die richtige Anwendung erhält, müssen laut Dokumentation alle drei Bedingungen erfüllt sein. Wer eine davon übersieht, sucht einen Fehler, wo keiner ist — das Verhalten ist korrekt.

  • Die Zuweisung an den Host Pool erlaubt es, eine Anwendung nur dort anzubieten, wo die passende Hardware steht — etwa eine grafikintensive Anwendung nur auf einem Pool mit GPU-optimierten Hosts.
  • Für eine RemoteApp-Anwendungsgruppe muss die App-Attach-Anwendung der Gruppe hinzugefügt werden. Für eine Desktop-Anwendungsgruppe ist das nicht nötig.
  • Die Zuweisung an den Nutzer erfolgt über ein Konto oder eine Gruppe.
Warum das so gebaut istErst die Kombination aus drei Zuweisungen macht möglich, dass zwei Menschen auf demselben Multisession-Host unterschiedliche Anwendungen vorfinden. Das ist der eigentliche Fortschritt gegenüber der Installation im Abbild — und der Grund, warum die Diagnose drei Orte prüfen muss statt einen.

Kurzcheck

Ein Nutzer sieht eine per App Attach bereitgestellte Anwendung nicht. Sie ist ihm zugewiesen, und er ist in der Desktop-Anwendungsgruppe des Pools. Was fehlt am wahrscheinlichsten?

  • Die Zuweisung der Anwendung an den Host Pool.
  • Die Anwendung muss der Desktop-Anwendungsgruppe hinzugefügt werden.
  • Das Paket muss auf jedem Session Host installiert werden.
  • Der Nutzer braucht eine eigene RemoteApp-Anwendungsgruppe.

Treffer. Richtig. Zwei der drei Bedingungen sind erfüllt; die dritte ist die Zuweisung an den Host Pool, auf dem die Sitzung läuft.

Registrierung: sofort oder bei Bedarf

App Attach bindet die Abbilder bei der Anmeldung ein; danach macht ein Registrierungsvorgang die Anwendungen verfügbar. Dafür gibt es zwei Verfahren, und die Wahl wirkt unmittelbar auf die Anmeldedauer.

On-demand
Anwendungen werden bei der Anmeldung nur teilweise registriert; die vollständige Registrierung erfolgt erst beim Start. Standard und Empfehlung — die Anmeldedauer bleibt unbeeinflusst.
Log on blocking
Jede zugewiesene Anwendung wird vollständig registriert, und zwar während der Anmeldung. Das kann die Anmeldedauer spürbar verlängern.

Die Zahl der Anwendungen ist von App Attach selbst nicht begrenzt. Die tatsächliche Grenze liegt im Netzdurchsatz und in der Zahl offener Dateihandles, die die Freigabe je Datei verträgt — beides begrenzt, wie viele Nutzer oder Anwendungen tragbar sind.

Aktiv und inaktivJedes Anwendungspaket trägt einen Zustand. Nur aktive Pakete werden Nutzern bereitgestellt; inaktive ignoriert Azure Virtual Desktop und bindet sie bei der Anmeldung nicht ein. Das ist der Schalter, mit dem sich ein Paket aus dem Verkehr ziehen lässt, ohne es zu löschen.

Neue Versionen einführen

Eine neue Version entsteht durch ein neues Abbild. Zwei Wege stehen offen, und sie unterscheiden sich darin, ob die alte Version verfügbar bleibt.

Nebeneinander
Eine neue Anwendung aus dem neuen Abbild anlegen und denselben Host Pools und Nutzern zuweisen. Beide Versionen existieren parallel.
An Ort und Stelle
Ein neues Abbild mit geänderter Versionsnummer erzeugen und die bestehende Anwendung darauf umstellen.
Zwei Regeln, die man kennen mussBei der Umstellung an Ort und Stelle muss sich die Versionsnummer ändern — sie darf höher oder niedriger sein, aber eine Aktualisierung auf dieselbe Versionsnummer ist nicht möglich. Und das bestehende Abbild darf nicht gelöscht werden, solange noch Nutzer damit arbeiten. Die neue Version erreicht Nutzer bei ihrer nächsten Anmeldung; wer gerade arbeitet, behält seine laufende Version.

Dass die Versionsnummer auch niedriger sein darf, ist der eingebaute Rückweg: Eine fehlerhafte Aktualisierung lässt sich zurücknehmen, indem man wieder auf das Abbild der vorigen Version umstellt — ohne Erneuerung von Hosts und ohne Wartungsfenster.

Die Dateifreigabe darunter

App Attach verlangt eine SMB-Freigabe, die bei der Anmeldung auf jedem Session Host eingebunden wird. Eine Abhängigkeit vom darunterliegenden Speicher gibt es nicht; empfohlen wird Azure Files, Azure NetApp Files setzt eine Anbindung der Hosts an Active Directory Domain Services voraus.

  • Die Rechte gelten dem Computerkonto des Session Hosts, nicht dem Nutzer — Lesezugriff auf Freigabe und Dateisystem.
  • Abbilder werden mit dem Computerkonto eingebunden: Das ergibt ein Handle je Session Host und Abbild, nicht je Nutzer. Für die Skalierung ist das der entscheidende Unterschied.
  • Die Freigabe gehört in dieselbe Azure-Region wie die Session Hosts.
  • Anwendungsabbilder sind schreibgeschützt und gehören von der Virenprüfung ausgenommen.
  • Die Dokumentation rät davon ab, dieselbe Freigabe wie für FSLogix-Profilcontainer zu verwenden.
  • Als Anhaltspunkt je 1-GB-Abbild und Session Host: ein E/A-Vorgang im Ruhezustand, zehn beim Start, Latenz 400 ms.
Eine Warnung, die man ernst nehmen mussFür Azure Files mit Entra-eingebundenen Session Hosts muss die Rolle Reader and Data Access an zwei Dienstprinzipale vergeben werden — Azure Virtual Desktop und den ARM Provider. Die Dokumentation warnt dazu ausdrücklich: Damit erhält der Dienst Zugriff auf alle Daten in diesem Speicherkonto. Empfohlen wird deshalb, dort ausschließlich App-Attach-Anwendungen abzulegen und die Zugriffsschlüssel regelmäßig zu wechseln.

Zertifikate: die Falle mit Ablaufdatum

Jedes MSIX- und Appx-Paket braucht ein gültiges Codesignaturzertifikat — erkennbar an der Objektkennung 1.3.6.1.5.5.7.3.3. Die gesamte Zertifikatskette muss auf den Session Hosts als vertrauenswürdig gelten, sonst startet nichts.

  • Zertifikate einer öffentlichen Zertifizierungsstelle sind unter Windows standardmäßig vertrauenswürdig.
  • Bei einer internen Unternehmens-CA in einer Active-Directory-Domäne entsteht das Vertrauen automatisch; bei einer eigenständigen CA müssen Stamm- und Zwischenzertifikate per Gruppenrichtlinie verteilt werden.
  • Für Entra-eingebundene Hosts übernimmt Microsoft Intune die Verteilung der Stammzertifikate.
  • Selbstsignierte Zertifikate sind unterstützt, gehören aber ausschließlich in Testumgebungen.
Zeitstempel setzenDie Dokumentation empfiehlt ausdrücklich, Pakete mit einem Zeitstempel zu versehen, damit ihre Gültigkeit das Ablaufdatum des Zertifikats überdauert. Ohne Zeitstempel gilt: Läuft das Signaturzertifikat ab, muss jedes Paket mit einem neuen gültigen Zertifikat aktualisiert werden — und für jedes muss erneut sichergestellt werden, dass die Kette auf allen Hosts vertrauenswürdig ist. Diese Arbeit fällt zu einem Zeitpunkt an, den niemand geplant hat.

Wo App Attach nicht trägt

Microsoft Entra ID
Unterstützt.
Active Directory Domain Services
Unterstützt.
Microsoft Entra Domain Services
Nicht unterstützt.

Die dritte Zeile ist eine harte Entwurfsgrenze: Wer seine Session Hosts an Microsoft Entra Domain Services bindet, kann App Attach nicht nutzen. Zusammen mit der bereits bekannten Einschränkung, dass solche Hosts sich auch nicht mit Intune verwalten lassen, wird daraus eine Entscheidung mit weiter Wirkung.

Und was ins Abbild gehörtNicht alles lässt sich paketieren. Treiber, Systemdienste, tief integrierte Sicherheitsagenten und alles, was vor der Anmeldung laufen muss, gehören ins Abbild. App Attach ist für Anwendungen gedacht, die ein Mensch startet — nicht für Bestandteile des Betriebssystems. Wer versucht, die Grenze zu verschieben, verlagert Aufwand aus der Abbildpflege in die Fehlersuche.

App-V: Konfiguration je Nutzer oder je Maschine

Für App-V-Pakete, die über App Attach geliefert werden, lässt sich das Verhalten der Anwendung über dynamische Konfigurationsdateien anpassen. App Attach findet sie von selbst, wenn sie einer Namenskonvention folgen.

  • Die Dateien liegen im selben Ordner wie das Paket, und ihr Name beginnt mit dem Namen der .appv-Datei.
  • Zu \\share\folder\filename.appv gehören damit filename_UserConfig.xml und filename_DeploymentConfig.xml.
  • Die Benutzerkonfiguration wird auf Nutzerebene ausgewertet — verschiedene Menschen können unterschiedliche Einstellungen erhalten.
  • Die Bereitstellungskonfiguration wirkt auf Maschinenebene und gilt für alle Nutzer desselben Session Hosts.
Eine Einschränkung mit FolgenDie Benutzerkonfiguration wird derzeit nur für Desktopverbindungen unterstützt, nicht für RemoteApp-Verbindungen. Wer dieselbe Anwendung beiden Gruppen anbietet, bekommt damit zwei verschiedene Verhaltensweisen — im Desktop mit nutzerbezogenen Einstellungen, als veröffentlichte Anwendung ohne sie. Das ist erklärungsbedürftig gegenüber Fachbereichen, die beides nutzen.

Braucht eine Anwendung mehrere Benutzerkonfigurationen für verschiedene Personenkreise, müssen sie ausdrücklich per PowerShell mit dem Paket verknüpft werden. Die Zuordnung läuft dann über Gruppenmitgliedschaften: Das Feld Publisher des Abhängigkeitseintrags trägt die Objekt-ID der Entra-Sicherheitsgruppe, und bei der Anmeldung wertet App Attach die Mitgliedschaften aus. Die Dokumentation rät, davon nur Gebrauch zu machen, wenn verschiedene Nutzergruppen wirklich unterschiedliche Einstellungen brauchen.

Diagnose: die Anwendung, die nicht da ist

Ist das Paket aktiv?Ist es dem Host Pool zugewiesen?Ist der Nutzer in einer Anwendungsgruppe dieses Pools?Ist die Anwendung dem Nutzer zugewiesen?Erreicht der Host die Freigabe — mit dem Computerkonto?
Zuweisung vor Technik

Bei dynamischer Bereitstellung lautet die erste Frage nicht, warum eine Anwendung abstürzt, sondern ob sie in dieser Sitzung überhaupt angehängt wurde. Die Reihenfolge oben geht von der billigsten zur teuersten Prüfung — und die ersten vier Schritte kosten nur Blicke ins Portal.

  • Trifft es alle Nutzer einer Anwendung? Dann liegt es am Paketzustand, an der Zuweisung zum Pool oder an der Freigabe.
  • Trifft es alle Anwendungen eines Hosts? Dann erreicht dieser Host die Freigabe nicht — Rechte des Computerkontos prüfen.
  • Trifft es eine Person? Dann fehlt ihre Zuweisung oder ihre Mitgliedschaft in der Anwendungsgruppe.
  • Startet die Anwendung, bricht aber ab? Dann ist sie angehängt, und erst jetzt lohnt der Blick auf die Zertifikatskette und die Anwendung selbst.
Der Sonderfall, der wie ein Defekt aussiehtNach einer Aktualisierung an Ort und Stelle arbeiten Menschen unterschiedlich lange mit unterschiedlichen Versionen — wer angemeldet bleibt, behält seine, wer sich neu anmeldet, bekommt die neue. Zwei Kollegen nebeneinander sehen dann verschiedene Oberflächen derselben Anwendung. Das ist kein Fehler, sondern das dokumentierte Verhalten, und es endet mit der nächsten Anmeldung.

Die Wahl in der Praxis

Vier Anwendungen, vier Entscheidungen

Szenario

Für einen neuen Pool sind vier Anwendungen zu liefern: ein Virenschutzagent, eine Office-Suite für alle, eine Fachanwendung für zwölf Personen mit monatlichen Aktualisierungen und ein grafikintensives Werkzeug für drei Personen.

Anforderungen

  • Die Abbildpflege soll so selten wie möglich anfallen.
  • Aktualisierungen sollen so wenige Menschen wie möglich betreffen.

Schritte

  1. Der Virenschutzagent gehört ins Abbild — er läuft als Systemdienst und muss vor jeder Anmeldung wirken.
  2. Die Office-Suite gehört ins Abbild: Sie betrifft alle, ändert sich selten und würde als Paket auf jedem Host bei jeder Anmeldung eingebunden.
  3. Die Fachanwendung gehört an App Attach: zwölf Betroffene, monatliche Aktualisierung ohne Wartungsfenster, Rückweg über die vorige Abbildversion.
  4. Das grafikintensive Werkzeug ebenfalls an App Attach — und zusätzlich nur dem Host Pool mit GPU-optimierten Hosts zugewiesen.
  5. Beide App-Attach-Anwendungen als RemoteApp veröffentlichen, falls die Betroffenen sie ohne vollen Desktop brauchen.

Merksatz: Die Leitfrage ist nicht, was technisch möglich ist, sondern wie viele Menschen eine Aktualisierung trifft. Was alle brauchen und selten wechselt, gehört ins Abbild; was wenige brauchen und oft wechselt, gehört daneben.

Der Preis der EntkopplungApp Attach nimmt Last aus der Abbildpflege und legt sie auf eine Dateifreigabe, die jetzt an jeder Anmeldung beteiligt ist. Damit wächst die Zahl der Abhängigkeiten: Freigabe, Rechte über Computerkonten, Zertifikatsketten, Paketversionen. Ein Abbild mit allem darin ist starr und hat wenige bewegliche Teile — die entkoppelte Variante ist beweglich und hat viele. Wer sie wählt, tauscht seltene, große Wartungsfenster gegen laufende, kleine Pflege ein. Das ist meist der bessere Handel, aber es ist einer.

Eine letzte Abgrenzung, die in Projekten Zeit spart: App Attach löst die Frage der Bereitstellung, nicht die der Lizenzierung. Lizenzmodelle unterscheiden regelmäßig zwischen Installation und Nutzung, und eine Anwendung, die auf zwanzig Hosts eingebunden wird, kann lizenzrechtlich anders zählen als eine, die auf zwanzig Hosts installiert ist. Diese Frage gehört vor die technische Entscheidung — beantworten kann sie nur der Hersteller.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →
Quellen & Aktualität5 Primärquellen · zuletzt geprüft:
  1. 01learn.microsoft.com/en-us/azure/virtual-desktop/app-attach-overview
  2. 02learn.microsoft.com/en-us/azure/virtual-deskto…plication-group-type
  3. 03learn.microsoft.com/en-us/azure/virtual-desktop/terminology
  4. 04learn.microsoft.com/en-us/azure/virtual-desktop/prerequisites
  5. 05learn.microsoft.com/en-us/azure/virtual-desktop/session-host-update