Import, Abhängigkeiten, Berechtigungen, App Attach und Bereitstellungsformate · Stand September 2026 (Server 1.0.31, Agent 1.0.36)

MSIX-Pakete verteilen

Dieses Dokument beschreibt, wie Sie MSIX-Pakete mit ZeroPortal auf Arbeitsplätze, Terminalserver und virtuelle Desktops bringen: vom Import über Abhängigkeiten und Berechtigungen bis zur Bereitstellung als App Attach. Es setzt einen laufenden Portalserver und installierte Agenten voraus (Administrationshandbuch). Wer im Portal was darf, steht in Benutzer, Rechte, Lizenzen und Protokolle; die Seite des Endgeräts in Client-Agent: Betrieb und Rollout.

1. Was ist das?

MSIX ist das aktuelle Paketformat von Windows (AppX ist der ältere Name derselben Technik). Ein MSIX-Paket ist signiert, installiert sich ohne Adminrechte in einen abgeschotteten Bereich und lässt sich sauber wieder entfernen. Viele Pakete setzen ein Framework voraus, eine Laufzeitkomponente wie Microsoft.VCLibs, die sich mehrere Anwendungen teilen.

Die Paketdatei liegt in einer Freigabe, dem Paket-Repository. Das Portal liest beim Import nur die Metadaten ein und verwaltet, wer das Paket bekommen soll (Berechtigungen) und ob es ausgeliefert wird (Status Veröffentlicht oder Zurückgezogen). Der Agent auf dem Endgerät holt den Katalog beim Abgleich ab, installiert oder registriert die Pakete und entfernt sie wieder, wenn sie zurückgezogen werden.

Was ist App Attach? Für die Bereitstellung gibt es zwei Formen. Bei der klassischen MSIX-Installation kopiert der Agent das Paket vom Repository und installiert es. Bei App Attach liegt das Paket als virtueller Datenträger (VHDX oder CIM) in der Freigabe und wird nur eingehängt; das ist für Terminalserver und virtuelle Desktops gedacht. Das Portal erzeugt diese Datenträger selbst aus dem importierten Paket, die Zuordnung zu Geräten geschieht per Richtlinie.

Die Grundregel: Ein Gerät bekommt ein Paket nur, wenn beides gilt: Das Paket ist veröffentlicht, und es gibt eine Berechtigung, die auf den Benutzer oder das Gerät passt.

2. Wozu ist das gut?

• Standardsoftware auf Arbeitsplätzen. Eine AD-Gruppe von Computern berechtigen; der Agent installiert maschinenweit.
• Fachanwendungen, die der Person folgen. Eine AD-Gruppe von Benutzern berechtigen; das Paket folgt der Person auf jedes Gerät und verschwindet, wenn sie die Gruppe verlässt.
• Terminalserver und VDI. Die Sitzungshosts hängen ein gemeinsames App-Attach-Image aus der Freigabe ein; ein Update ist ein neues Image.
• Store-Anwendungen ohne Store. Ein mit winget download geladenes Store-Paket verteilen Sie samt Lizenzdatei über das Portal.
• Versionswechsel ohne Nacharbeit. Eine neue Version übernimmt beim Import die Berechtigungen der alten; Frameworks kommen und gehen mit den Anwendungen, die sie brauchen.

Nicht geeignet ist App Attach für Notebooks, die unterwegs arbeiten: Das Image muss beim Start der Anwendung erreichbar sein. Dort bleibt die klassische Installation die Wahl.

3. Wie nutze ich das?

3.1 Voraussetzungen

• MSIX-Abgleich im Agenten einschalten. Nach der Installation ist er ausgeschaltet. Der Weg für alle Geräte ist die Gruppenrichtlinie Sync MSIX einschalten aus der ADMX-Vorlage des Agenten (C:\Program Files\NickIT\ZeroPortalAgent\admx). Auf einem Testgerät genügt lokal Enable-ZPAgentSync -Msix; Get-ZPAgentSync zeigt den Stand.
• Signaturzertifikat auf den Clients. Windows installiert nur Pakete, deren Zertifikat das Gerät als vertrauenswürdig kennt. Bei eigenen Paketen verteilen Sie das Zertifikat per GPO in Vertrauenswürdige Personen oder Vertrauenswürdige Stammzertifizierungsstellen. Geräte ohne Internet brauchen zusätzlich die Zwischenzertifikate der Kette, siehe Bekannte Fehlerbilder.
• Paket-Repository. Die Freigabe ist unter Globale Konfiguration → Konfiguration, Abschnitt Paket-Repositorys, eingetragen und für Computerkonten und Benutzer lesbar. Für Außenstellen zeigt die Agent-Einstellung Paketquellen-Stammpfad überschreiben auf eine lokale Freigabe oder einen DFS-Pfad; fehlt ein Paket dort, nimmt der Agent die zentrale Quelle.

3.2 Schritt 1: Importieren

Unter MSIX → Pakete auf Paket hinzufügen klicken, das Repository wählen, mit aktivem Haken Unterordner zur Datei navigieren und Importieren wählen. Erkannt werden .msix, .appx, .msixbundle, .appxbundle und .appinstaller. Die Datei bleibt in der Freigabe. Ein Unterordner je Anwendung hält das Repository übersichtlich.

Ein frisch importiertes Paket steht auf Zurückgezogen. Frameworks blendet die Liste aus; der Haken Frameworks anzeigen holt sie herein.

Bundles. Ein Bundle enthält dieselbe Anwendung für mehrere Prozessortypen (x64, x86, ARM64). Im Dialog Architekturen wählen wählen Sie die Varianten, die Sie verteilen wollen, für normale Windows-PCs x64. Die Wahl bestimmt auch, welche Abhängigkeiten das Portal anschließend anzeigt.

3.3 Schritt 2: Prüfen

Pakettyp. In der Kopfzeile der Paketseite steht ein Auswahlfeld mit dem Typ aus dem Manifest: Application, Framework, Modification, Optional oder Resource. Die Bereitstellungsregeln folgen ihm. Deklariert sich eine Laufzeitkomponente als Application, stellen Sie hier auf Framework um; sonst erscheint sie beim Anwender als Programm ohne Funktion.

Signatur. Die Karte Identität & Signatur zeigt unter Zertifikat & Zeitstempel, bis wann das Signaturzertifikat gültig ist und ob die Signatur einen Zeitstempel trägt (Kapitel 4.6). Ein unsigniertes Paket wird als Unsigniert markiert; Endgeräte verweigern dessen Installation.

Abhängigkeiten. Die Karte Abhängigkeiten listet die Frameworks aus dem Manifest:

Ein fehlendes oder nicht berechtigtes Framework ist die häufigste Ursache dafür, dass eine Installation auf dem Gerät abbricht, während im Portal alles richtig aussieht.

3.4 Schritt 3: Berechtigen

In der Karte AD-Berechtigungen auf Hinzufügen klicken. Der Dialog sucht in Active Directory (Gruppen und Benutzer, zwei Zeichen reichen), Entra ID, internen Portalkonten, Portalgruppen sowie Geräten und Benutzern aus der Agent-Registrierung (API-Clients).

Gerät oder Benutzer, das ist der wichtigste Unterschied:

Verwenden Sie AD-Gruppen; dann steuern Sie die Verteilung über die Gruppenmitgliedschaft. Jede Vergabe und jeder Entzug wird im Audit-Protokoll festgehalten.

Berechtigungen auf Frameworks übertragen. Der Knopf Berechtigungen übernehmen unter der Abhängigkeitsliste kopiert die Berechtigungen des Hauptpakets auf alle Frameworks im Katalog (additiv) und veröffentlicht sie gleich mit. Frameworks, die nicht im Katalog sind, meldet das Portal.

3.5 Schritt 4: Veröffentlichen

Oben auf der Paketseite Veröffentlichen wählen; Zurückziehen nimmt das Paket wieder aus der Auslieferung. In der Paketliste geht dasselbe je Zeile oder für mehrere markierte Pakete auf einmal. Beim Veröffentlichen eines Bundles veröffentlicht das Portal die im Katalog gefundenen Frameworks automatisch mit.

Nach dem nächsten Abgleich erscheint das Paket im Tray-Fenster des Agenten; Frameworks lassen sich dort einblenden.

3.6 Schritt 5 (optional): App Attach

Image erzeugen. Auf der Paketseite in der Karte Quelle & OS-Kompatibilität unter App Attach erzeugen: auf VHDX oder CIM klicken. Die Erzeugung läuft im Hintergrund; der Knopf zeigt den Fortschritt und heißt danach VHDX löschen bzw. CIM löschen. Das Image liegt neben dem Paket in der Freigabe (AppAttach\vhdx oder AppAttach\cim), der Pfad steht unter App-Attach-Disk:. Beide Formate können nebeneinander existieren. Für Pakete mit Store-Lizenz ist die Erzeugung nicht möglich.

Sollen Images automatisch entstehen, schalten Sie unter MSIX → Konfiguration die Option Disk(s) automatisch nach dem Import erzeugen ein und wählen das Format (Kapitel 6).

Geräte zuweisen. Welches Gerät ein Paket als App Attach bekommt, legt die Richtlinie MSIX-Bereitstellung fest. Legen Sie unter Richtlinien einen Richtliniensatz für die Sitzungshosts an (Geltungsbereich zum Beispiel deren OU), fügen Sie die Richtlinie MSIX-Bereitstellung hinzu und tragen Sie Regeln ein: ein Muster auf den Paketfamiliennamen (* erlaubt), optional ein Pakettyp und das Format. Eine neue Richtlinie enthält bereits die Regel * / Framework → MSIX (lokal installiert), weil Frameworks immer klassisch kommen. Darunter genügt für einen Terminalserver eine Regel * → App Attach (CIM). Richtliniensätze beschreibt Richtlinien und Vorlagen.

3.7 Pakete mit Store-Lizenz

Ein aus dem Microsoft Store exportiertes Paket (winget download) bringt eine Lizenzdatei <ProductId>_License.xml mit. Legen Sie sie neben das Bundle in die Freigabe und hängen Sie sie auf der Paketseite unter Store-Lizenz: mit Lizenz hinzufügen … an. Zwei Regeln gelten für solche Pakete:

• Immer eine Computergruppe berechtigen. Die Lizenz wird maschinenweit eingespielt; bei reiner Benutzerberechtigung überspringt der Agent das Paket und protokolliert das.
• Immer klassische Installation. App Attach hat keinen Lizenzschritt; fordert eine Bereitstellungsregel App Attach an, liefert der Agent trotzdem MSIX.

3.8 Neue Version verteilen

Importieren Sie die neue Version wie in Schritt 1. Sie übernimmt Berechtigungen und Abhängigkeitseinstellungen der bisherigen (Standard, Kapitel 4.2) und bleibt zunächst Zurückgezogen, damit Sie sie prüfen können. Sobald Sie sie veröffentlichen, wechseln die Geräte beim nächsten Abgleich. Die alte Version ziehen Sie danach von Hand zurück, oder das Portal erledigt das mit der Option Beim Aktivieren einer Version andere aktive Versionen derselben Family automatisch deaktivieren.

4. Regeln: wann wirkt was

4.1 Wann der Agent abgleicht

Der Agentdienst gleicht den Gerätekontext beim Start und danach alle 60 Minuten ab (MSIX/SyncIntervalMinutes), mit bis zu 10 Minuten Zufallsversatz (Agent/SyncJitterMinutes). Der Benutzerkontext wird bei jeder Anmeldung, beim Entsperren und im selben Intervall abgeglichen. Sofort anstoßen: Sync-ZPAgentPublishingServer oder das Tray-Symbol.

Eine Berechtigung über eine AD-Gruppe wirkt für Benutzer erst mit einem neuen Kerberos-Ticket, also nach Ab- und Anmelden, sofern nicht die Agent-Einstellung Kerberos-Tickets des Benutzers vor dem Benutzer-Sync löschen aktiv ist.

4.2 Versionswechsel

• Übernahme beim Import (Standard an): Die neue Version einer Paketfamilie erhält die Berechtigungen, Abhängigkeitsverknüpfungen und die Übertragungseinstellung der bisher neuesten Version und bleibt zurückgezogen.
• Automatisches Zurückziehen beim Veröffentlichen (Standard aus): Sobald Sie eine Version veröffentlichen, zieht das Portal alle anderen veröffentlichten Versionen derselben Familie zurück. Schalten Sie es erst ein, wenn Ihr Ablauf eingespielt ist; sonst verschwindet eine funktionierende Version, bevor die neue geprüft ist.
• Die Familie ergibt sich aus Paketname und Herausgeberzertifikat. Ein mit einem anderen Zertifikat signiertes Paket ist eine andere Familie: keine Übernahme, kein automatisches Zurückziehen, und auf dem Gerät eine zweite Installation neben der ersten.

4.3 Zurückziehen und Entfernen

Ziehen Sie ein Paket zurück oder entfernen Sie die Berechtigung, entfernt der Agent es beim nächsten Abgleich (MSIX/AutoUninstallOnUnpublish, Standard an); MSIX/GlobalRemovalPolicy bestimmt den Zeitpunkt: Immediate (Standard), WhenIdle, OnReboot oder Disabled. Läuft die Anwendung gerade, schiebt der Agent das Entfernen auf (MSIX/DeferRemovalWhileInUse, Standard an), spätestens nach 24 Stunden (MSIX/RemovalIdleTimeoutHours) entfernt er das Paket auch bei laufender Anwendung. Frameworks bleiben ohne Fehlermeldung stehen, solange ein anderes Paket sie braucht, auch eines aus dem Store (Ereignis 2507 im Gerätekontext, 2516 im Benutzerkontext).

4.4 Ältere Version verteilen (Downgrade)

Das Ausliefern einer älteren Version über eine auf dem Gerät vorhandene neuere ist standardmäßig gesperrt: Der Agent überspringt das Paket (Ereignis 3501 Gerätekontext, 3510 Benutzerkontext), die neuere Version bleibt. Grund: Die neuere Version kann aus einer Quelle stammen, die das Portal nicht kennt (Store, Windows Update); ohne Sperre würde der Agent sie bei jedem Abgleich ersetzen.

Wollen Sie ein Downgrade, etwa nach einem fehlerhaften Update, erlauben Sie es mit der Richtlinie Paket-Downgrade-Steuerung je Paketfamilie (Muster wie Contoso.*; die erste passende Regel von oben gewinnt). Eine neue Downgrade-Richtlinie beginnt mit der Regel * → Downgrade verweigern; setzen Sie Ihre Erlaubnisregel darüber, sonst wird sie nie erreicht. Die Agent-Einstellung MSIX/AllowDowngrade erlaubt Downgrades für alle Pakete des Geräts und ist nur für Testgeräte gedacht; die Richtlinie geht ihr vor.

Ein erlaubtes Downgrade entfernt zuerst die neuere Version und installiert dann die ältere; Frameworks werden nie zurückgestuft. Testen Sie vorher: Die ältere Anwendung verlangt unter Umständen ältere Frameworks, die das Gerät nicht mehr hat.

4.5 Bereitstellungsformat: MSIX oder App Attach

Ohne Richtlinie MSIX-Bereitstellung werden alle Pakete klassisch installiert. Mit ihr gilt je Paket die erste passende Regel von oben:

Es ist eine Maschinenrichtlinie: Das Format gilt für alle Pakete des Geräts, auch für benutzerberechtigte. Gibt es kein Image im gewünschten Format oder ist die Freigabe nicht erreichbar, liefert der Agent klassisch aus (Ereignis 3620); läuft das Paket bereits aus einem Image, bleibt es dabei (Ereignis 3533). Pakete mit Store-Lizenz kommen immer klassisch (Ereignis 3504). Bei einem Formatwechsel beendet der Agent eine laufende Anwendung (MSIX/TerminateAppsForFormatSwitch, Standard an); auf aus wartet er, bis sie geschlossen ist. Eine lokal neuere Version wird nie durch eine ältere im anderen Format ersetzt (Kapitel 4.4).

VHDX oder CIM? VHDX hat die breiteste Kompatibilität mit Windows-Versionen und ist die Wahl im Zweifel. CIM ist kompakt, kann aber keine Schreibzugriffe auf den virtuellen Datenträger verarbeiten. Ein Paket, das in sein eigenes Installationsverzeichnis schreibt, scheitert daher aus einem CIM-Image; das ist eine Eigenschaft des Formats, kein Fehler von ZeroPortal. Viele Pakete, die mit dem Package Support Framework umgebaut wurden, funktionieren trotzdem, weil die Umleitungen Schreibzugriffe an eine andere Stelle lenken. Startet ein Programm aus CIM nicht oder scheitert es beim Speichern, erzeugen Sie stattdessen ein VHDX und stellen die Regel auf App Attach (VHDX) um.

Die Größe eines VHDX legt das Portal aus Paketgröße und eingestellter Reserve fest; reicht sie nicht, wiederholt es die Erzeugung mit größerem Datenträger. Ein CIM wächst von selbst.

4.6 Signaturen und Ablaufdatum

Ob ein Zertifikat vertrauenswürdig ist, prüft nicht das Portal, sondern Windows auf dem Gerät bei der Installation. Importieren Sie deshalb nur Pakete aus Quellen, denen Sie vertrauen.

Abgelaufenes Zertifikat, was dann? Entscheidend ist der Zeitstempel der Signatur. Trägt die Signatur einen Zeitstempel, prüft Windows, ob das Zertifikat zum Zeitpunkt der Signatur gültig war, und installiert das Paket auch nach dem Ablauf weiter. Fehlt der Zeitstempel, lässt sich das Paket nach dem Ablauf nicht mehr installieren und muss neu signiert und erneut importiert werden. Bereits installierte Pakete laufen in jedem Fall weiter. Die Einstellung Signatur-Warnschwelle (Tage vor Cert-Ablauf) (Standard 14) legt fest, ab wann die Paketseite das Ablaufdatum rot markiert.

4.7 Selbstinstallation durch Benutzer

Windows erlaubt Standardbenutzern das Installieren signierter MSIX-Pakete per Doppelklick, auch am Portal vorbei; ZeroPortal kann das nicht unterbinden. Die Windows-Richtlinie BlockNonAdminUserInstall hilft nicht: Sie blockiert auch den Benutzerabgleich des Agenten (Zugriff verweigert, 0x80070005); nur maschinenweit berechtigte Pakete kämen noch an. Verwenden Sie stattdessen eine AppLocker- oder WDAC-Regel auf Herausgeberbasis: fremde Herausgeber sperren, die Zertifikate der eigenen Pakete erlauben. Der Agent liefert dann weiter aus.

5. Betrieb und Fehlersuche

Wo Sie nachsehen

Auf dem Gerät (PowerShell, Modul des Agenten):

Get-ZPAgentSync                  # Ist der MSIX-Abgleich eingeschaltet?
Get-ZPAgentStatus                # Dienst, Server, letzter Abgleich
Sync-ZPAgentPublishingServer     # Abgleich sofort anstoßen
Get-ZPAgentPackage               # Vom Agenten verwaltete Pakete
Get-ZPAgentMountedPackage        # Eingehängte App-Attach-Images
Get-ZPAgentConfiguration         # Alle Schalter mit Wert und Herkunft

Wichtige Ereignisse im Agent-Log

Fehlersuche

6. Anhang: Technische Referenz

Einstellungen unter MSIX → Konfiguration

Die Werte gelten für alle Server eines Clusters; Einstellungen zurücksetzen stellt die Standardwerte wieder her. Die Einstellungen, die Sie üblicherweise anpassen:

Agent-Einstellungen für MSIX

Per Gruppenrichtlinie (ADMX), per ZeroPortal-Richtlinie Agent-Konfiguration oder lokal mit Set-ZPAgentConfiguration -<Schalter> <Wert>. Rangfolge: Gruppenrichtlinie vor ZeroPortal-Richtlinie vor lokalem Wert. Get-ZPAgentConfiguration zeigt alle Schalter mit Wert und Herkunft; die Schalter aus Kapitel 4 sind dort mit ihren Standardwerten genannt.

PowerShell-Modul des Portals

Die Cmdlets des Moduls ZeroPortal decken denselben Weg wie die Weboberfläche ab:

Get-MsixZeroPortalPackage               # Katalog abfragen (-Name, -Family, -Id, -EnabledOnly)
Import-MsixZeroPortalPackage            # Paket importieren (-PackagePath, bei Bundles -Architecture)
Set-MsixZeroPortalPackage               # Veröffentlichen oder zurückziehen (-Id, -Enabled $true/$false)
Remove-MsixZeroPortalPackage            # Katalogeintrag löschen
Get-MsixZeroPortalPackageEntitlement    # Berechtigungen eines Pakets anzeigen
Grant-MsixZeroPortalPackage             # AD-Gruppe berechtigen (-Id, -GroupName, -AutoDependencies)
Copy-MsixZeroPortalPackageEntitlement   # Berechtigungen auf die Frameworks übertragen
Revoke-MsixZeroPortalPackage            # Berechtigung entziehen

Import-MsixZeroPortalPackage -PackagePath '\\files01\Packages\MSIX\Contoso.App.msixbundle' -Architecture x64
Grant-MsixZeroPortalPackage -Id 42 -GroupName 'APP-Contoso-Users' -AutoDependencies
Set-MsixZeroPortalPackage -Id 42 -Enabled $true