So stellen Sie WinGet-Apps mit Intune bereit: 4 Methoden, die funktionieren

Wenn Sie WinGet-Apps mit Intune bereitstellen möchten, sollte das ein unkomplizierter Prozess sein. Schließlich kennt WinGet bereits die Installer-URL, die Version und die Silent-Switches für Tausende von Windows-Apps, also sollten Sie Intune doch einfach auf den Katalog verweisen und die Bereitstellung starten können, oder?

Nun, es gibt einen Haken. Intune hat keinen App-Typ, der direkt aus dem WinGet-Community-Repository bereitstellen kann, sondern nur Apps aus dem Microsoft Store. Um die Sache noch komplizierter zu machen, wird das WinGet-Befehlszeilentool nicht unterstützt, wenn ein Skript als SYSTEM ausgeführt wird – also in dem Kontext, den Intune verwendet, wenn das Installationsverhalten einer App auf System festgelegt ist.

Vor diesem Hintergrund: Wie können Sie WinGet mit Intune bereitstellen? Wir haben vier Methoden identifiziert, die die Bereitstellung vereinfachen können. Sehen wir uns also an, welche das sind, was jede kostet, wie sie eingerichtet werden und wie Sie Probleme beheben, auf die Sie möglicherweise stoßen.

Kann Intune WinGet-Apps nativ bereitstellen?

Teilweise. Der App-Typ Microsoft Store app (new) von Intune verwendet Windows Package Manager, um Apps aus dem Microsoft Store zu finden und zu installieren. Er kann nicht auf das WinGet-Community-Repository zugreifen, den öffentlichen Katalog, den die meisten WinGet-Anleitungen verwenden, und kein Intune-App-Typ stellt Apps daraus bereit. Um Apps aus dem Community-Repository bereitzustellen, benötigen Sie einen Skript-Wrapper oder ein Win32-Paket.

Diese Lücke ist darauf zurückzuführen, wie WinGet organisiert ist. Es bezieht Apps aus zwei Hauptquellen: dem Microsoft Store (msstore) und dem WinGet-Community-Repository auf GitHub. Die Store-Integration von Intune, die den eingestellten Microsoft Store for Business ersetzt hat, stellt nur eine Verbindung zur ersten her.

Möglicherweise sehen Sie in Diskussionen zu Intune WinGet auch Microsofts Enterprise App Catalog erwähnt. Dabei handelt es sich um eine separate Bibliothek von Win32-Apps, die von Microsoft vorbereitet und gehostet wird, und Microsoft gibt an, dass dafür nicht WinGet verwendet wird. Dafür ist außerdem ein Abonnement erforderlich, das über Intune Plan 1 oder Plan 2 hinausgeht.

Vier Möglichkeiten, WinGet mit Intune zu nutzen

Wenn Sie WinGet-Apps mit Intune bereitstellen möchten, gibt es dafür nach wie vor Möglichkeiten. Dies sind die vier gängigsten Möglichkeiten, WinGet mit Intune zu verwenden, einschließlich ihrer besten Einsatzbereiche und ihrer Einschränkungen:

So funktioniert jede Methode Schritt für Schritt.

Methode 1: Microsoft Store-Apps mit dem App-Typ „Microsoft Store-App (neu)“ bereitstellen

Die erste (und wohl einfachste) Möglichkeit, Apps bereitzustellen, erfolgt über die Microsoft Store-App. Das können Sie in wenigen schnellen Schritten tun:

1. Gehen Sie im Intune Admin Center zu Apps → All Apps → Create und wählen Sie dann unter Store app die Option Microsoft Store app (new) aus.

2. Wählen Sie „In der Microsoft Store-App suchen“ und suchen Sie nach der gewünschten App anhand von Name, Herausgeber oder Store-App-ID. Die Ergebnisse zeigen, ob es sich bei jeder App um Win32 oder UWP handelt.

3. Überprüfen Sie die vorausgefüllten App-Informationen, legen Sie das Installationsverhalten auf System oder Benutzer fest (beachten Sie, dass einige Apps nur eines von beiden unterstützen), und legen Sie die Optionen für das Company Portal fest (z. B. hervorgehobene App und Kategorie).

4. Weisen Sie die App als Erforderlich, Verfügbar für registrierte Geräte oder Deinstallieren zu und legen Sie Benachrichtigungen für Endbenutzer, die Neustart-Nachfrist und die Installationsfrist fest.

5. Überprüfen und erstellen Sie. Intune hält die App auf dem neuesten Stand, sobald neue Versionen erscheinen.

Allerdings gibt es einige Einschränkungen und Voraussetzungen, die Sie beachten sollten. Diese können den Prozess komplizierter machen und bedeuten möglicherweise, dass Sie eine andere Methode ausprobieren müssen:

1. Geräte benötigen die Intune Management Extension, mindestens zwei Prozessorkerne und Netzwerkzugriff auf den Store sowie auf die Inhalte des Herausgebers.

2. Win32-Apps im Store befinden sich noch in der Vorschau, und nicht jede Win32-App ist durchsuchbar. Ebenso werden kostenpflichtige Apps und ARM64-Installer nicht unterstützt.

3. Win32-Apps aus dem Store bleiben nur aktualisiert, solange sie in Intune zugewiesen bleiben.

4. Bei in Entra registrierten Geräten muss das Installationsverhalten „System“ verwendet werden (daher ist „Benutzer“ keine Option).

Methode 2: Einen WinGet-Befehl in eine Win32-App einbetten

Wenn die Microsoft Store-App für Ihre Anforderungen nicht geeignet ist, können Sie WinGet über Intune bereitstellen, indem Sie einen WinGet-Befehl in eine Win32-App verpacken. In diesen Fällen ist eine Win32-App zuverlässiger als ein einfaches Plattformskript, da sie Statuserkennung, Rückgabecodes und einen Deinstallationsbefehl umfasst – Dinge, die Bereitstellungen mit Einzeilenskripten fehlen.

Warum WinGet fehlschlägt, wenn Intune als SYSTEM ausgeführt wird

Wenn das Installationsverhalten einer Win32-App auf System festgelegt ist, führt Intune den Installationsbefehl als SYSTEM aus – und genau hier funktioniert WinGet nicht mehr. Die WinGet CLI wird im SYSTEM-Kontext nicht unterstützt, da sie in App Installer enthalten ist, einer paketierten (MSIX) App, die pro Benutzer registriert wird. Daher schlägt der Aufruf von WinGet nach Namen in einem SYSTEM-Skript in der Regel fehl, weil SYSTEM es nicht finden kann.

Es gibt einige Workarounds. Community-Skripte beheben dieses Problem in der Regel, indem sie winget.exe unter C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe auflösen, aber dies ist keine von Microsoft unterstützte Methode. Die von Microsoft unterstützte Option ist das PowerShell-Modul Microsoft.WinGet.Client, das im Systemkontext für systemweit installierte Apps funktioniert.

Installationsskript schreiben

Um das Installationsskript zu schreiben, sollten Sie zuerst die Paket-ID ermitteln und es dann anhand genau dieser ID aus dem Community-Repository installieren. Sie können die ID mit winget search <app name> nachschlagen oder ohne Kommandozeile auf winstall, Splashtops kostenlosem WinGet-Katalogbrowser. Sobald Sie die ID haben, sieht der Installationsbefehl etwa so aus: winget install --id Git.Git -e --source winget --silent --accept-package-agreements --accept-source-agreements

Bei SYSTEM-Installationen sollten Sie --scope machine einschließen. Beachten Sie, dass Microsoft darauf hinweist, dass EXE-Installer den Geltungsbereich nicht einheitlich handhaben.

Für Microsoft Intune kann der Installationsbefehl ein PowerShell-Skript mit bis zu 50 KB sein. Die Verwendung von powershell.exe im Befehlsfeld startet die 32-Bit-Version, während die Verwendung des Sysnative-Pfads 64-Bit-PowerShell ermöglicht.

Ein Erkennungsskript hinzufügen

Stellen Sie sicher, dass Sie ein Skript hinzufügen, das erkennt und bestätigt, wann die App ordnungsgemäß installiert ist. Intune zählt die App nur dann als installiert, wenn das Skript mit Code 0 beendet wird und eine Ausgabe in STDOUT schreibt; jede STDERR-Ausgabe wird als nicht installiert gelesen. Das Skript prüft in der Regel den Installationsordner der App, die Dateiversion oder den Registrierungsschlüssel für die Deinstallation. Wenn Sie mit winget list prüfen, stoßen Sie auf dasselbe SYSTEM-Problem. Daher ist es besser, Datei- oder Registrierungsprüfungen zu verwenden.

Paketieren Sie die Skripte und laden Sie die Win32-App hoch

Abschließend verpacken Sie die Skripte mit dem Microsoft Win32 Content Prep Tool, um die Datei .intunewin zu erstellen. Datei. Sie können diese Datei dann unter Apps → Alle Apps → Hinzufügen → Windows-App (Win32) hinzufügen, das Installationsverhalten auf System festlegen und den Deinstallationsbefehl, das Erkennungsskript und die Anforderungen hinzufügen. Verwenden Sie im Deinstallationsbefehl vollständige Pfade, da Intune dort keine Umgebungsvariablen erweitert.

Beachten Sie, dass jede App ein eigenes Skript-Set und eigene Updates benötigt und dass WinGet auf jedem Gerät, auf dem es installiert ist, vorhanden sein und funktionieren muss. Daher kann diese Methode einen höheren Wartungsaufwand verursachen als die anderen.

Methode 3: Halten Sie WinGet-Apps mit Intune Remediations auf dem neuesten Stand

Mit Intune Remediations können Sie ein Erkennungsskript mit einem Bereinigungsskript kombinieren. Für WinGet prüft Ihr Erkennungsskript, ob für eine installierte App eine neue Version verfügbar ist; wenn ja, führt das Bereinigungsskript winget upgrade für diese Paket-ID aus. Dies funktioniert als Aktualisierungsmethode in Kombination mit Methode 2 und 4, übernimmt jedoch nicht die Erstinstallation.

Die Lizenzierung kommt zuerst. Für Intune Remediations sind Windows Enterprise E3 oder E5 (enthalten in Microsoft 365 F3, E3 oder E5) oder Windows Education A3 oder A5 erforderlich, und die Geräte müssen von Intune verwaltet oder gemeinsam verwaltet werden und Windows Enterprise, Professional oder Education ausführen.

Damit Apps mit Intune Remediations auf dem neuesten Stand bleiben, folgen Sie einfach ein paar einfachen Schritten:

1. Gehen Sie im Intune Admin Center zu Geräte → Geräte verwalten → Skripts und Korrekturen.

2. Erstellen Sie ein Skriptpaket mit einem Erkennungsskript, das die Paket-ID auf ein verfügbares Upgrade prüft.

3. Fügen Sie ein Behebungsskript hinzu, das das Upgrade für diese ID mit --silent und beiden --accept -Flags ausführt.

4. Weisen Sie sie einer Gerätegruppe zu und legen Sie einen Zeitplan für die Suche nach Updates fest.

Stellen Sie sicher, dass Sie die spezifischen Paket-IDs auswählen, die Sie aktualisieren möchten. Sie können zwar winget upgrade --all verwenden, aber dadurch wird jede App aktualisiert, die WinGet erkennt, einschließlich solcher, die die IT nicht genehmigt oder getestet hat. Beachten Sie außerdem, dass WinGet die neueste Version aus dem Repository installiert, sodass Updates möglicherweise eingeführt werden, bevor das IT-Team Gelegenheit hat, sie zu testen. Wenn das Remediation-Skript als SYSTEM ausgeführt wird, stößt es auf dieselbe WinGet-Einschränkung, die in Methode 2 behandelt wird.

Methode 4: Verpacken Sie das Installationsprogramm als native Win32-App

Es ist auch möglich, das Installationsprogramm als native Win32-App neu zu paketieren. In diesem Fall dient WinGet als Quelle für App-Informationen statt für die App selbst. Indem Sie das WinGet-Manifest verwenden, um das Installationsprogramm und seine Silent-Schalter zu finden, können Sie das Installationsprogramm als standardmäßige Win32-App bereitstellen.

Das bedeutet, dass Geräte die App ohne einen funktionierenden WinGet-Client bereitstellen können, das Problem mit dem SYSTEM-Kontext nicht zutrifft und Sie Zugriff auf den vollen Win32-Funktionsumfang von Intune haben.

Sie können das Installationsprogramm in wenigen Schritten als Win32-App paketieren:

1. Ermitteln Sie die Paket-ID mit winget search (oder schlagen Sie sie auf winstall nach) und prüfen Sie das zugehörige Manifest auf Installer-Typ, Download-URL und Silent-Schalter. (WinGet erfordert, dass jeder aufgeführte Installer eine unbeaufsichtigte Installation unterstützt.)

2. Laden Sie das Installationsprogramm mit WinGet oder vom Anbieter herunter.

3. Bestätigen Sie den Befehl für die stille Installation für diesen Installertyp. In unseren Leitfäden zu stillen MSI-Installationen und stillen EXE-Installationen finden Sie die Schalter für jeden Installertyp.

4. Verpacken Sie das Installationsprogramm mit dem Microsoft Win32 Content Prep Tool, um die .intunewin- Datei zu erstellen.

5. Fügen Sie sie als Windows-App (Win32) hinzu, einschließlich Installations- und Deinstallationsbefehlen, einer Erkennungsregel (nach MSI-Produktcode, Datei oder Registrierung), Anforderungen und Rückgabecodes.

6. Testen Sie auf einem sauberen Testgerät, wie gut sich die App installieren lässt, eine abgeschlossene Installation erkannt wird und die Deinstallation funktioniert, bevor Sie sie auf weitere Geräte ausrollen.

7. Sobald eine neue Version veröffentlicht wird, müssen Sie den Build wiederholen und Supersedence verwenden, um die alte App zu ersetzen.

Diese Option bietet IT-Teams die meisten Anpassungsmöglichkeiten und die größte Kontrolle, bedeutet aber auch, dass sie den Prozess für jede App und jedes Update wiederholen müssen. Daher kann es für Teams mit großen App-Katalogen schwierig sein, mit dem Arbeitsaufwand Schritt zu halten.

Welche Methode ist also am effektivsten? Wir können sie aufschlüsseln und sehen, wann sich der Kompromiss lohnt und wann andere Methoden besser sind.

WinGet vs. Win32-App in Intune: Welcher Ansatz passt?

Die zentrale Entscheidung ist, ob Geräte WinGet bei der Installation ausführen oder eine Win32-App erhalten, die Sie im Voraus paketiert haben. So unterscheiden sich die beiden:

Beim Vergleich der Optionen sehen wir einige wichtige Details. Für eine Handvoll risikoarmer Dienstprogramme können WinGet-Skripte schnell sein und weniger Aufwand im Vorfeld erfordern. Für Business-Apps, regulierte Geräte oder große Kataloge ist eine paketierte Win32-App zuverlässiger, weil sie vorhersehbare Versionen und Tests vor Rollouts bietet.

Wenn die App im Microsoft Store aufgeführt ist, ist Methode 1 in der Regel die schlankste Option.

Häufige Probleme bei der Bereitstellung von WinGet-Apps mit Intune

Selbst mit der richtigen Methode bringt die Bereitstellung von WinGet-Apps mit Intune ihre Herausforderungen mit sich. IT-Teams können bei der Bereitstellung von Apps auf häufige Probleme stoßen, diese jedoch erkennen und beheben.

Häufige Probleme sind:

1. WinGet wird in einem Intune-Skript nicht erkannt

Wenn Ihr Skript meldet, dass winget nicht erkannt wird, wird das Skript höchstwahrscheinlich als SYSTEM ausgeführt, wo die WinGet-CLI nicht unterstützt wird, da sich App Installer pro Benutzer registriert. Dies lässt sich beheben, indem winget.exe über seinen vollständigen Pfad aufgelöst wird oder indem das Microsoft.WinGet.Client PowerShell-Modul verwendet wird, wie in Methode 2 erwähnt.

2. Die App wird für den falschen Benutzer oder am falschen Ort installiert

Wenn die App am falschen Ort oder für den falschen Benutzer installiert wird, liegt das am Installationsbereich. Bei SYSTEM wird der Benutzerbereich zum eigenen Profil von SYSTEM aufgelöst, während EXE-Installer den Unterschied zwischen Benutzer- und Computerbereich uneinheitlich handhaben. Um das zu beheben, verwenden Sie --scope machine für SYSTEM-Installationen (testen Sie das unbedingt zuerst, bevor Sie die App breiter ausrollen).

3. Der Download schlägt mit einem 403-Forbidden-Fehler fehl

Wenn der Download einen 403 Forbidden-Fehler zurückgibt, blockiert der Softwareanbieter möglicherweise den User Agent von WinGet auf seinen Download-Servern. Wenn das Installationsprogramm in einem Browser problemlos heruntergeladen wird, ist das wahrscheinlich die Ursache. In diesem Fall können Sie das Installationsprogramm direkt herunterladen und es als paketierte Win32-App bereitstellen, wie in Methode 4 beschrieben.

4. Eine Store-App wird in der Intune-Suche nicht angezeigt

Wenn eine Store-App bei der Suche nicht angezeigt wird, kann das einen von drei Gründen haben: 1. Sie ist in Ihrer Region nicht verfügbar, 2. es handelt sich um eine kostenpflichtige App, was bedeutet, dass sie nicht unterstützt wird, oder 3. ihre Plattform wird nicht unterstützt. Unabhängig von der Ursache sollten Sie zunächst den App-Eintrag überprüfen, und wenn er nicht zugänglich ist, verwenden Sie Methode 2 oder 4, um die App zu installieren.

5. Eine UWP Store-App meldet "nach der Installation nicht erkannt" (0x87D1041C)

Wenn Sie diesen Hinweis erhalten, bedeutet das, dass einer UWP-App mit dem System-Installationsverhalten ein Gerät zugewiesen ist, auf dem sie bereits vorhanden ist. Machen Sie sich in diesem Fall keine Sorgen; die App ist weiterhin korrekt installiert. Microsoft empfiehlt außerdem, Benutzer- und Systemkontexte nicht für dieselbe App zu mischen.

6. Finden Sie heraus, warum eine WinGet-Installation fehlgeschlagen ist

Wenn eine WinGet-Installation fehlgeschlagen ist und Sie nicht sicher sind, warum, können Sie die Ursache untersuchen, um sie zu ermitteln und zu beheben. Wenn Sie --verbose-logs zum Befehl hinzufügen, erhalten Sie vollständige Protokolle, und Sie können winget error <code> ausführen, um einen Exit-Code in eine Beschreibung zu übersetzen. Beachten Sie, dass dies WinGet-, MSIX- und MSI-Codes abdeckt, viele EXE-Installer jedoch nicht standardisierte Codes verwenden können. Unser Leitfaden zur stillen EXE-Installation erklärt, wie Sie diese finden.

Wie Splashtop Agentic Packr WinGet-Apps in getestete Intune-Pakete verwandelt

Die Bereitstellung von WinGet-Apps mit Intune kann kompliziert sein, muss es aber nicht. Mit der richtigen Automatisierung können Teams Installer schnell und effizient paketieren, ohne IT-Ressourcen zu binden.

Damit kommen wir zu Splashtop Agentic Packr, einem KI-gestützten Tool für Anwendungspaketierung und -bereitstellung für moderne IT-Teams. Agentic Packr kann Anwendungen über Microsoft Intune, SCCM und mehr paketieren, validieren und bereitstellen – mit deutlich weniger manuellem Aufwand.

Splashtop Agentic Packr bietet mehrere Funktionen und Vorteile, darunter:

1. WinGet als Quelle, ohne WinGet-Client auf den Geräten

Splashtop Agentic Packr kann Apps aus einem verifizierten WinGet-Katalog, anhand der Paket-ID von WinGet oder Chocolatey oder aus Ihren eigenen Installationsprogrammen paketieren. Es erstellt eine Intune-native Win32-App, sodass Sie sich keine Gedanken über die Probleme mit WinGet und dem SYSTEM-Kontext machen müssen, auf die Benutzer häufig stoßen.

2. Erkennungsregeln schreiben und testen, bevor etwas ausgeliefert wird

Wenn der KI-gestützte Agent das Installationsprogramm liest, schreibt er Erkennungsregeln und testet den Build auf einer sauberen virtuellen Maschine. Diese Tests prüfen, ob Installation, Erkennung und Deinstallation funktionieren, führen einen Malware-Scan durch und erstellen eine QA-Bewertung sowie Protokolle, die IT-Administratoren überprüfen können, bevor die App Intune erreicht und auf Geräten bereitgestellt wird.

3. Veröffentlichung und neue Versionen ohne manuelle Neuerstellungen

Splashtop Agentic Packr macht es überflüssig, Pakete bei jedem neuen Update manuell neu zu erstellen. Mit seiner Express-Verbindung per Klick zum Intune-Mandanten und automatischen Versionsupdates erkennt Agentic Packr neue Updates, paketiert sie, testet sie und rollt das aktualisierte Paket aus, ohne dass Admins jedes Update manuell bearbeiten müssen.

4. Kontrolle darüber, was Benutzer sehen

Mit Splashtop Agentic Packr hat die IT die Kontrolle darüber, wie Installationen und Updates für Benutzer angezeigt werden. Teams können Benachrichtigungen für Endbenutzer, Aufschuboptionen, Neustartaufforderungen und Karenzzeiten anpassen, sodass erforderliche Installationen und Updates die Nutzer seltener mitten bei der Arbeit unterbrechen.

Stellen Sie WinGet-Apps in Intune bereit, ohne Skripte pflegen zu müssen

WinGet ist eine starke Quelle für App-Informationen, und Intune eignet sich hervorragend für die Bereitstellung von Apps, aber Intune kann nicht direkt aus dem WinGet-Community-Repository bereitstellen. Die skalierbare Methode besteht darin, WinGet-Einträge in getestete Win32-Pakete umzuwandeln.

Mit Splashtop Agentic Packr können Sie App-Pakete mit deutlich weniger manueller Arbeit erstellen, testen und veröffentlichen. Agentic Packr macht die Paketierung schneller und einfacher, indem es eine einzige Konsole zum Paketieren, Bereitstellen und Aktualisieren von Apps nutzt und Admins dabei die Kontrolle behält.

Sie möchten WinGet-Apps mit Intune ganz ohne Aufwand bereitstellen? Sehen Sie, wie Splashtop Agentic Packr Ihnen schon heute helfen kann.