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.
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.
Paketformate — App 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.
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
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.
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 inaktiv — Jedes 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.
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.
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.
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.
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.appvgehören damitfilename_UserConfig.xmlundfilename_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.
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
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.
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
- Der Virenschutzagent gehört ins Abbild — er läuft als Systemdienst und muss vor jeder Anmeldung wirken.
- 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.
- Die Fachanwendung gehört an App Attach: zwölf Betroffene, monatliche Aktualisierung ohne Wartungsfenster, Rückweg über die vorige Abbildversion.
- Das grafikintensive Werkzeug ebenfalls an App Attach — und zusätzlich nur dem Host Pool mit GPU-optimierten Hosts zugewiesen.
- 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.
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:
- 01learn.microsoft.com/en-us/azure/virtual-desktop/app-attach-overview
- 02learn.microsoft.com/en-us/azure/virtual-deskto…plication-group-type
- 03learn.microsoft.com/en-us/azure/virtual-desktop/terminology
- 04learn.microsoft.com/en-us/azure/virtual-desktop/prerequisites
- 05learn.microsoft.com/en-us/azure/virtual-desktop/session-host-update