Jede vorinstallierte Microsoft Store App mit Intune Settings Catalog entfernen

Du willst Lovable von jedem Windows 11 Gerät verschwinden lassen, bevor es bei einem User landet. Vielleicht ist es bei dir eine andere App, aber die Geschichte ist dieselbe. Wenn du RemoveDefaultMicrosoftStorePackages schon einmal über Group Policy oder eine benutzerdefinierte OMA-URI konfiguriert hast, weisst du, dass das keine Fünf-Minuten-Sache ist.

Microsoft hat dieser Richtlinie im April 2026 eine dynamische App-Entfernungsliste hinzugefügt, mit der du endlich jede beliebige Microsoft Store App über ihren Package Family Name (PFN) ansprechen kannst, statt nur die fest eingebaute Checkbox-Liste zu nutzen. Der Haken war, dass es weiterhin über GPO oder ein rohes OMA-URI-Payload lief, dazu noch ein einmaliger, zwingender Registry-Eingriff auf jedem Gerät. Ich habe die aktuelle Settings-Catalog-Implementierung auf Windows 11, Version 25H2, Build 26200.8893 getestet und Lovable mit ein paar Klicks und einem einzigen PowerShell-Befehl entfernt. Kein XML, kein Registry-Key.

Table of Contents

Open Table of Contents

• Was ist die Microsoft Store App-Entfernungsrichtlinie
• Warum der OMA-URI-Ansatz mühsam war
• Was sich geändert hat: native Settings-Catalog-Unterstützung
• Den Package Family Name finden
• Test: Lovable auf Windows 11 25H2 entfernen
• Deployment mit Intune
• Testen und Verifizieren
• Punkte, die du vor dem Rollout kennen solltest

Was ist die Microsoft Store App-Entfernungsrichtlinie

RemoveDefaultMicrosoftStorePackages ist eine ADMX-basierte Richtlinie, die vorinstallierte MSIX/APPX-Apps auf Windows 11 Enterprise- und Education-Geräten deinstalliert. Ursprünglich kam sie als statische Checkbox-Liste. Du konntest Apps wie Clipchamp, Copilot oder MicrosoftSolitaireCollection ankreuzen, und Windows hat sie bei der Provisionierung oder beim nächsten Sign-in entfernt.

Im April 2026 hat Microsoft die Richtlinie um eine dynamische Entfernungsliste erweitert. Statt auf die von Microsoft vordefinierten Apps beschränkt zu sein, konntest du jede beliebige PFN hinzufügen, und Windows hat sie genauso behandelt: deinstalliert, Neuinstallation blockiert, solange die Richtlinie aktiv ist, und die zugehörigen App-Daten entfernt.

Dieser Teil war wirklich nützlich. Was noch zu wünschen übrig liess, war die Art der Konfiguration.

Warum der OMA-URI-Ansatz mühsam war

Wenn du das über eine benutzerdefinierte OMA-URI umgesetzt hast, musstest du ein komplettes XML-Payload von Hand schreiben:

<enabled/>
<data id="Clipchamp" value="false"/>
<data id="MSTeams" value="false"/>
<data id="DynamicRemovalList" value="Microsoft.BingNews_8wekyb3d8bbwe&#x0D;&#x0A;Microsoft.WindowsAlarms_8wekyb3d8bbwe"/>

Beachte das 
 im Wert der dynamischen Liste. Das ist ein HTML-kodierter Carriage Return plus Line Feed, und so trennst du mehrere PFNs innerhalb des Strings. Machst du das falsch, wendet die Richtlinie sich still und leise nicht so an, wie du erwartest.

Zusätzlich weist Microsofts eigene Dokumentation auf einen zwingenden Schritt hin: Du musst den Registry-Key der dynamischen Liste einmal auf jedem Gerät öffnen, damit sich das Format korrekt normalisiert.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages

Das lässt sich im grossen Massstab nicht sauber ohne zusätzliches Tooling skripten, und es geht während eines Rollouts leicht vergessen. Rechnest du noch den Hinweis auf CSP-Schema-Mismatches zwischen älteren und neueren Geräten dazu, bei denen eine für das neue Schema gebaute Richtlinie auf einem älteren Build nicht geparst werden kann, wurde das zu einer Richtlinie, an die ich vorsichtig herangegangen bin, statt sie schnell auszurollen.

Was sich geändert hat: native Settings-Catalog-Unterstützung

Der Settings-Catalog-Eintrag für diese Richtlinie zeigt die dynamische Entfernungsliste jetzt direkt als Einstellung an. Du suchst danach, trägst deine PFNs in das Feld ein und weist das Profil zu. Kein Zusammenbauen einer OMA-URI, kein XML-Escaping, und in meinem Test auch kein manueller Registry-Schritt.

Das ist relevant, weil es die App-Entfernung in denselben Workflow bringt wie jede andere Settings-Catalog-Richtlinie, die du bereits verwaltest. Du pflegst kein separates, benutzerdefiniertes Profil mit handgebautem XML mehr neben deiner normalen, Catalog-basierten Konfiguration.

Den Package Family Name finden

Bevor du eine benutzerdefinierte App entfernen kannst, brauchst du ihre PFN. Führe das auf einem Gerät aus, auf dem die App installiert ist:

Get-AppxPackage *Lovable* | Select-Object PackageFamilyName

Der Wildcard-Abgleich auf den App-Namen reicht aus. Die Ausgabe liefert dir den exakten PFN-String, den du in das Feld der dynamischen Liste im Settings Catalog einträgst.

Test: Lovable auf Windows 11 25H2 entfernen

Ich habe diesen Test auf Windows 11, Version 25H2, Build 26200.8893, Enterprise Edition durchgeführt. Lovable gehört nicht zu Microsofts Standard-Checkbox-Liste, deshalb ist es ein gutes Testszenario speziell für die dynamische Liste, nicht für die eingebauten Optionen.

Nach dem Zuweisen des Profils und dem Sync des Geräts wurde Lovable beim nächsten Sign-in entfernt, zusammen mit den lokalen App-Daten. Dieser letzte Teil ist wichtig einzuplanen. Wenn ein User etwas lokal in der App gespeichert hat, ist es weg, sobald die Richtlinie greift.

Deployment mit Intune

1. Gehe zu Devices > Configuration > Settings catalog > + Create.
2. Suche nach Remove default Microsoft Store packages from the system und füge sie hinzu.
3. Lasse die Standard-Checkbox-Apps so, wie es für deine Organisation passt, oder lasse sie alle deaktiviert, wenn du nur die benutzerdefinierte App entfernen willst.
4. Trage im Feld für die dynamische Liste die PFN ein, die du mit Get-AppxPackage ermittelt hast. Nutze eine PFN pro Zeile, wenn du mehr als eine benutzerdefinierte App entfernst.
5. Weise das Profil zuerst einer kleinen Testgruppe zu, nicht deiner gesamten Flotte.
6. Synce ein Testgerät und bestätige, dass die Richtlinie greift, bevor du die Zuweisung ausweitest.

Fang klein an. Diese Richtlinie löscht App-Daten bei der Entfernung, und ein falscher PFN-Eintrag oder ein ungewollter Zuweisungsbereich ist nichts, was du auf Produktivgeräten entdecken willst.

Testen und Verifizieren

Bestätige auf dem Testgerät, dass die App nach dem Sign-in verschwunden ist, und prüfe, dass sie nicht aus dem Microsoft Store neu installiert werden kann, solange die Richtlinie aktiv ist. Musst du zurückrollen, entferne die Zuweisung, und die App wird wieder installierbar - Windows stellt bereits entfernte Inhalte dabei aber nicht automatisch wieder her.

Ein paar Dinge, die Microsoft explizit nennt und die ich in der Praxis bestätigen konnte:

• Das Entfernen einer App löscht auch ihre App-Daten auf dem Datenträger. Informiere User vorher, wenn es sich um eine App handelt, die sie mit lokalen Dateien nutzen.
• Du kannst die dynamische Liste nicht verwenden, um Systemkomponenten zu entfernen. Sie ist für MSIX/APPX-verpackte Apps gedacht, nicht für Kernfunktionen von Windows.
• Entfernte Apps bleiben so lange von einer Neuinstallation blockiert, wie die Richtlinie zugewiesen ist.

Punkte, die du vor dem Rollout kennen solltest

Das wird nur auf Windows 11, Version 24H2 und 25H2, Enterprise- und Education-Editionen unterstützt. Home und Pro werden nicht unterstützt, und du brauchst mindestens das nicht-sicherheitsrelevante Update von April 2026 auf dem Gerät, damit die Funktion der dynamischen Liste überhaupt funktioniert.

Ich habe das native Settings-Catalog-Verhalten, einschliesslich des Wegfalls des Registry-Schritts, nur auf Build 26200.8893 bestätigt. Betreibst du eine gemischte Flotte mit älteren Builds, die noch den OMA-URI-Ansatz nutzen, halte diese Richtlinie separat von einer neueren, Settings-Catalog-basierten Richtlinie, statt sofort zu konsolidieren. Microsofts eigener Hinweis zum CSP-Schema-Mismatch wurde mit dem OMA-URI-Verfahren im Kopf geschrieben, teste also sorgfältig, bevor du davon ausgehst, dass Settings Catalog dieses Risiko auf jedem Build in deiner Umgebung vollständig beseitigt.

Die Unterstützung der dynamischen Liste über Settings Catalog in Intune wurde zum Zeitpunkt, als ich das geschrieben habe, noch als schrittweiser Rollout beschrieben. Siehst du beim Suchen nach der Einstellung also nur die statischen Checkbox-Optionen, hat dein Tenant das Update möglicherweise noch nicht erhalten.

Wenn du benutzerdefinierte Apps noch über eine handgebaute OMA-URI entfernst, lohnt sich der Wechsel. Zehn Minuten in Settings Catalog ersetzen ein XML-Payload, einen Registry-Workaround und das Schema-Mismatch-Risiko, das damit einherging. Teste einfach zuerst mit einer kleinen Gruppe, denn das Löschen von App-Daten lässt sich nicht rückgängig machen, sobald die Richtlinie greift.